• KT_Tuấn_Anh KT_Tuấn_Anh

    {
        "lvs": [ // list level
            {
                "i": 28, // id level
                "n": "1", // name level
                "th": "", // thumb level
                "o": 24, // order level
                "cs": [  // category
                    {
                        "i": 15838, // id category
                        "n": "Greetings 1", // name category
                        "o": 1, // order category
                        "the": "", // thumb category
                        "lv_i": 28, // level Id
                        "us": [ // list unit
                            {
                                "i": 1, // id unit
                                "t": "Hello!", // (name, title) unit
                                "o": 1, // order unit
                                "c_i": 15838, // category id
                                "l_i": 28, // level Id
                                "ls": [ // list lesson
                                    {
                                        "i": 300043, // id lesson
                                        "t": "Lesson 1", // (name, title) lesson
                                        "a": 1, // age lesson
                                        "ty": 7, // type lesson
                                        "o": 1, // order lesson
                                        "u_i": 1, // unit id
                                        "f": 0, // free
                                        "as": [ // list activity 
                                            {
                                                "i": 1503139, // id activity 
                                                "l_i": 300043, // lesson id
                                                "g_i": 1000091, // game id
                                                "u_i": 1, // unit id
                                                "g_c_i": 15838, // category id
                                                "o": 1, // order activity
                                                "f": "App/zip/activity/1503139-44737-lul.zip", // path download activity
                                                "p": 9428,
                                            }
                                        ]
                                    }
                                ]
                            }
                        ]
                    }
                ]
            }
        ],
        "d": {
            "ac": "https://vnmedia2.monkeyuni.net/", => "Link download Act"
            "w_b": "https://vnmedia2.monkeyuni.net/App/zip/hdr/word_bundle/" => "Link download Word"
        },
        "d_l": {
            "ac": "https://vnmedia2.monkeyuni.net/",
            "w_b": "https://vnmedia2.monkeyuni.net/App/zip/hdr/word_bundle/"
        }
    }
    

    posted in MJ read more
  • KT_Tuấn_Anh KT_Tuấn_Anh

    • GET: được sử dụng để lấy thông tin từ sever theo URI đã cung cấp.
    • HEAD: giống với GET nhưng response trả về không có body, chỉ có header
    • POST: gửi thông tin tới sever thông qua các biểu mẫu http( đăng kí chả hạn..)
    • PUT: ghi đè tất cả thông tin của đối tượng với những gì được gửi lên
    • PATCH: ghi đè các thông tin được thay đổi của đối tượng.
    • DELETE: xóa tài nguyên trên server.
    • CONNECT: thiết lập một kết nối tới server theo URI.
    • OPTIONS: mô tả các tùy chọn giao tiếp cho resource.
    • TRACE: thực hiện một bài test loop - back theo đường dẫn đến resource.

    posted in Backend read more
  • KT_Tuấn_Anh KT_Tuấn_Anh

    1xx Informational

    • 100 Continue: Chỉ một phần của Request được nhận bởi Server (có thể là header và Client cần gửi tiếp body), nhưng miễn là nó không bị loại bỏ, Client nên tiếp tục với Request.
    • 101 Switching Protocols: Requester đã hỏi Server về việc thanh đổi Protocol và Server đã chấp nhận điều đó

    2xx Success

    • 200 OK: Request đã được tiếp nhận và xử lý thành công. Các Response thực tế trả về sẽ phụ thuộc vào phương thức HTTP của Request. Trong một GET Request, Response sẽ chứa một thực thể tương ứng với các tài nguyên yêu cầu, trong một POST Request, Response sẽ chứa một thực thể mô tả hoặc chứa các kết quả của các action.
    • 201 Created: Request đã được xử lý, kết quả của việc xử lý tạo ra một resource mới.
    • 202 Accepted: Request được chấp nhận cho xử lý, nhưng việc xử lý chưa hoàn thành.
    • 203 Non-authoritative Information (Xuất hiện từ HTTP/1.1): Server là nơi chuyển đổi proxy (ví dụ một Web accelerator) đã nhận được 200 OK nhưng nó trả về một phiên bản thay đổi (có thể là header) của Response nguyên gốc.
    • 204 No Content: Server đã xử lý thành công request nhưng không trả về bất cứ content nào.
    • 205 Reset Content: Server đã xử lý thành công request nhưng không trả về bất cứ content nào. Không giống với 204 No Content Response này yêu cầu phía Client phải thiết lập lại document view.
    • 206 Partial Content: Server chỉ trả về một phần của resouce(dạng byte) do một range header được gửi bởi phía Client. Các Range Header được sửa dụng bởi Client để cho phép nối lại các phần của file download bị dán đoạn hoặc chia thành nhiều luồng download.

    3xx Redirection

    • 300 Multiple Choices: Một danh sách các link. Người sử dụng có thể chọn một link và tới vị trí đó. Tối đa 5 địa chỉ. Ví dụ: List các file video với format khác nhau
    • 301 Moved Permanently: Request hiện tại và các request sau được yêu cầu di chuyển tới một URI mới.
    • 302 Found: Đây là một ví dụ cho thấy sự mâu thuẫn giữa thực tiễn và quy chuẩn. Ở phiên bản HTTP/1.0 nó có nghĩa là yêu cầu Client chuyển hướng đến một URL tạm thời (tương tự như là 301 Moved Permanently) nhưng phần lớn các browser lại thực hiện nó với ý nghĩa của * 303 See Other(sẽ nói sau đây). Do đó từ phiên bản HTTP/1.1 có thêm hai mã 303 và 307 để phân biệt rõ hành vi, nhưng một số ứng dụng web và framework vẫn sử dụng 302 như thể là 303.
      303 See Other (Xuất hiện từ HTTP/1.1): Response trả về của Request có thể tìm thấy ở một URL khác bằng cách sử dụng phương thức GET.
    • 304 Not Modified: Đây là Status-Code tới một If-Modified-Since hoặc If-None-Match header, nơi mà URL không được chỉnh sửa từ ngày cụ thể.
    • 305 Use Proxy: Tài nguyên yêu cầu chỉ có sẵn thông qua một proxy, địa chỉ mà được cung cấp trong các Response. Nhiều HTTP Client (như Mozilla và Internet Explorer) không xử lý một cách chính xác phản ứng với mã trạng thái này, chủ yếu là vì các lý do an ninh.
    • 306 Switch Proxy: Mã này hiện không còn được sử dụng, ý nghĩa ban đầu của nó là "Các Request tiếp theo nên sử dụng các proxy được chỉ định".
    • 307 Temporary Redirect (xuất hiện từ HTTP/1.1): Trong trường hợp này, Request hiện tại cần được lặp lại một URI khác nhưng các Request trong tương lai vẫn sử dụng URI gốc.

    4xx Client Error

    • 400 Bad Request: Server không thể xử lý hoặc sẽ không xử lý các Request lỗi của phía client (ví dụ Request có cú pháp sai hoặc Request lừa đảo định tuyến ...)
    • 401 Unauthorized: Tương tự như 403 Forbidden nhưng được sử dụng khi yêu cầu xác thực là bắt buộc và đã không thành công. Các Response bắt buộc phải có thành phần WWW-Authenticate chứa các thách thức với tài nguyên được yêu cầu. Một số trang web vấn đề HTTP 401 khi một địa chỉ IP bị cấm từ các trang web (thường là các tên miền trang web) và địa chỉ cụ thể là từ chối quyền truy cập một trang web.
    • 402 Payment Required: Hiện tại mã này chưa được sử dụng và nó được dự trữ cho tương lai. Mục đích ban đầu là mã này có thể được sử dụng như là một phần của đề án tiền mặt hoặc micropayment kỹ thuật số, nhưng điều đó đã không xảy ra, và mã này thường không được sử dụng. Google API sử dụng Status-Code này nếu một nhà phát triển đặc biệt đã vượt quá giới hạn số lần yêu cầu.
    • 403 Forbidden: Request là hợp lệ nhưng server từ chối đáp ứng nó. Nó có nghĩa là trái phép, người dùng không có quyền cần thiết để tiếp cận với các tài nguyên.
    • 404 Not Found: Các tài nguyên hiện tại không được tìm thấy nhưng có thể có trong tương lai. Các request tiếp theo của Client được chấp nhận.
    • 405 Method Not Allowed: Request method không được hỗ trợ cho các tài nguyên được yêu cầu. Ví dụ Một GET request đến một POST resource, PUT Request gọi đến một tài nguyên chỉ đọc.
    • 406 Not Acceptable: Server chỉ có thể tạo một Response mà không được chấp nhận bởi Client.
    • 407 Proxy Authentication Required: Bạn phải xác nhận với một Server ủy quền trước khi Request này được phục vụ.
    • 408 Request Timeout: Request tốn thời gian dài hơn thời gian Server được chuẩn bị để đợi.
    • 409 Conflict: Request không thể được hoàn thành bởi vì sự xung đột, ví dụ như là xung đột giữa nhiều chỉnh sửa đồng thời.
    • 410 Gone: Các resource được yêu cầu không còn nữa và sẽ không có sẵn một lần nữa, khi gặp mã lỗi này Client không nên có gắng tìm kiếm các tài nguyên này ở những lần sau.
    • 411 Length Required: Content-Length không được xác định rõ. Server sẽ không chấp nhận Request nào không có nó.
    • 412 Precondition Failed: Server sẽ không đáp ứng một trong những điều kiện tiên quyết của Client trong Request.
    • 413 Payload Too Large: Server sẽ không chấp nhận yêu cầu, bởi vì đối tượng yêu cầu là quá rộng. Trước đây nó gọi là "Request Entity Too Large".
    • 414 URI Too Long: URI được cung cấp là quá dài để Server xử lý, thường là kết quả của quá nhiều dữ liệu được mã hóa như là một truy vấn chuỗi của một GET Request, trong trường hợp đó nó phải được chuyển đổi sang một POST Request. Trước đây được gọi là "Request-URI Too Long"
    • 415 Unsupported Media Type: Server sẽ không chấp nhận Request, bởi vì kiểu phương tiện không được hỗ trợ. Ví dụ khi Client upload một ảnh có định dạng image/svg+xml, nhưng server yêu cầu một định dạng khác.
    • 416 Range Not Satisfiable: Client yêu cầu một phần của tập tin nhưng server không thể cung cấp nó. Trước đây được gọi là "Requested Range Not Satisfiable"
    • 417 Expectation Failed: Máy chủ không thể đáp ứng các yêu cầu của trường Expect trong header.

    5xx Server Error

    • 500 Internal Server Error: Một thông báo chung chung, được đưa ra khi Server gặp phải một trường hợp bất ngờ, Message cụ thể là không phù hợp.
    • 501 Not Implemented: Server không công nhận các Request method hoặc không có khả năng xử lý nó.
    • 502 Bad Gateway: Server đã hoạt động như một gateway hoặc proxy và nhận được một Response không hợp lệ từ máy chủ nguồn.
    • 503 Service Unavailable: Server hiện tại không có sẵn (Quá tải hoặc được down để bảo trì). Nói chung đây chỉ là trạng thái tạm thời.
    • 504 Gateway Timeout: Server đã hoạt động như một gateway hoặc proxy và không nhận được một Response từ máy chủ nguồn.
    • 505 HTTP Version Not Supported: Server không hỗ trợ phiên bản “giao thức HTTP”.

    posted in Backend read more
  • KT_Tuấn_Anh KT_Tuấn_Anh

    Tác dụng screen:

    – Mở nhiều cửa sổ shell trong duy nhất một cửa sổ lệnh (terminal command).
    – Giữ shell hoạt động trên máy chủ ngay khi cả kết nối từ máy trạm tới máy chủ bị ngắt (mất điện hoặc bị rớt mạng).
    – Có thể ngắt và kết nối lại cửa sổ shell từ nhiều nơi khác nhau (từ máy cá nhân khác có kết nối với máy chủ).
    – Có thể chạy ẩn shell với một chương trình mất nhiều thời gian.
    Cài đặt screen:

    yum install screen
    

    Sử dụng screen:

    Sau khi cài đặt screen thành công, bạn có thể khởi tạo một cửa sổ screen bên trong một terminal như sau:

    screen
    

    Nếu bạn muốn gắn tên cho cửa sổ screen để tiện quản lý, bạn sử dụng lệnh sau

    screen -S name
    

    Thoát khỏi screen:

    Command: “Ctrl-a” “d”

    Liệt kê screen:

    Sau khi thoát khỏi screen, để muốn biết có bao nhiêu cửa sổ screen đang chạy. Từ cửa sổ terminal bạn sử dụng lệnh sau:

    screen -ls
    

    Truy cập screen:

    Có hai cách để truy cập lại screen

    • Trong trường hợp đơn giản, bạn chỉ sử dụng một cửa sổ screen, thì bạn có thể sử dụng lệnh sau:
    screen -r
    
    • Trong trường hợp có nhiều cửa sổ lệnh, bạn có thể sử dụng lệnh sau:
    screen -x name1
    

    Ngắt screen:

    Có hai cách để tắt screen

    • Nếu bạn đang ở trong screen bạn có thể sử dụng tổ hợp phím “Ctrl-a” “k”.
    • Còn trong trường hợp bạn đang ở ngoài screen, thì trong cửa sổ terminal bạn sử dụng lệnh:
    screen -S name1 -X quit
    

    posted in DevOps read more
  • KT_Tuấn_Anh KT_Tuấn_Anh

    • PHP 7.2
    • Apache
    • Mysql 5.7.37
    • Mysql Workbench
    • Mongo
    • Redis
    • Docker
    • PhpStorm
    • GoLand
    • Potman

    posted in Backend read more
  • KT_Tuấn_Anh KT_Tuấn_Anh

    Kiến thức cần có Laravel :

    • Controler
    • Model
    • Repository
    • Services
    • Router
    • Middleware
    • Queue
    • Migrations
    • Seeds

    posted in Backend read more
  • KT_Tuấn_Anh KT_Tuấn_Anh

    Kiến thức cần có Angular :

    • Component
    • Data Binding (Binding , To-way binding)
    • Event Binding
    • Service
    • Service Http
    • Router
    • Module
    • Form (cần tìm hiểu kỹ về Form Control , Form Group , Form Array, Form validation)

    posted in Backend read more
  • KT_Tuấn_Anh KT_Tuấn_Anh

    Toàn bộ dự án của monkey được viết theo chuẩn psr2 . Việc theo 1 chẩn format code sẽ giúp team có 1 sự thống nhất và giúp review code dễ dàng hơn và tiện cho quá trình support chéo và maintain tính năng của người
    https://www.php-fig.org/psr/psr-2/

    1. Cách đặt tên

    1.1 Chuẩn cơ bản
    Tên Classes và Namespaces: Namespaces và tên classes phải tuân theo quy chuẩn "autoloading" của PSR:
    Tên class: Tên class phải được viết dưới dạng StudlyCaps, tức là các chữ cái đầu từ viết hoa, viết liền.
    Tên Method: Tên Method phải được viết dưới dạng camelCase, tức là từ đầu tiên viết thường, các từ tiếp theo viết hoa chữ cái đầu.
    Tên biến: Tên biến phải có nghĩa, không đặt kiểu $p, $num1, $num2,...
    Hằng số const: Constants của class phải được viết hoa toàn bộ và sử dụng gạch dưới ngăn cách giữa các từ. Ví dụ:
    const DATE_APPROVED = '2014-03-04';
    Keywords: Những keywords của PHP phải được viết thường. (không viết hoa); constants của PHP là true, false, và null cũng cần phải viết thường.
    1.2 Đặt tên trong Laravel
    Dựa trên chuẩn PSR standards
    Ghi chú:

    • singular: Số ít
    • plural: Số nhiều
    • snake_case: Sử dụng dấu gạch dưới giữa các từ, tất cả các từ viết thường.
    • camelCase: Từ đầu tiên viết thường, các từ tiếp theo viết hoa chữ cái đầu
    • dot notation: Sử dụng dấu . phân cách
    • singular model names in alphabetical order: Tên model số ít và thứ tự theo bảng chữ cái
    • snakecase without model name: snake_case không bao gồm tên Model
    • descriptive: Định nghĩa
    • adjective: Tính từ
    • noun: Danh từ
    Đối tượng Chuẩn đặt tên Tốt Chưa tốt
    Controller Singular ProductController ProductsController
    Route Plural products/1 product/1
    Tên route snake_case + dot notation products.write_review products.write-review, write-review-products
    Model Singular + UpperCase Product Products
    hasOne or belongsTo relationship Singular + camelCase productComment productComments, product_comment
    Các quan hệ khác Plural + camelCase productComments productComment, article_comments
    Tên bảng Plural + snake_case product_comments product_comment, productComments
    Tên bảng trung gian singular model names in alphabetical order article_user user_article, articles_users
    Tên cột trong bảng snake_case without model name meta_title MetaTitle, article_meta_title
    Thành phần trong Model snake_case $model->created_at $model->createdAt
    Khóa ngoại singular model name + _id suffix article_id ArticleId, id_article, articles_id
    Khóa chính - id custom_id
    Migration - 2017_01_01_000000_create_articles_table 2017_01_01_000000_articles
    Tên phương thức camelCase getAll get_all
    Phương thức trong resource controller tên bảng store saveArticle
    Phương thức trong test class camelCase testGuestCannotSeeArticle test_guest_cannot_see_article
    Tên biến camelCase $articlesWithAuthor $articles_with_author
    Collection descriptive, plural $activeUsers = User::active()->get() $active, $data
    Object descriptive, singular $activeUser = User::active()->first() $users, $obj
    Config and language files index snake_case articles_enabled ArticlesEnabled; articles-enabled
    Tên file View snake_case show_filtered.blade.php showFiltered.blade.php, show-filtered.blade.php
    Tên file config snake_case google_calendar.php googleCalendar.php, google-calendar.php
    Contract (interface) adjective or noun Authenticatable AuthenticationInterface,IAuthentication
    Trait adjective Notifiable

    2. Chuẩn về bố cục file code
    2.1 Tab - indent
    Code không dùng tab, mà phải sử dụng 4 dấu cách làm indent.
    2.2 Độ dài dòng
    Không có hard limit về độ dài của một dòng; soft limit phải là 120 chữ. Một dòng nên có không quá 80 chữ.
    2.3 Dòng trống
    Cần phải có một dòng trống ở sau phần khai báo namespace. Ngoài ra cũng cần có một dòng trống phía sau phần khai báo use.
    Mọi file phải kết thúc bằng một dòng trống.
    Một dòng không trống không được phép có trailing whitespace (dấu cách ở cuối dòng)
    Dòng trống có thể được thêm vào để code có thể được dễ đọc hơn và để phân cách những đoạn code.
    Không được có quá 1 dòng trống liền nhau
    Nếu trước return có logic code thì phải có dòng trống phía trước nó, còn nếu không có logic code thì không có dòng trống phía trước.
    2.4 Khoảng trắng (whitespace)
    Cần phải có một dấu cách phía sau những từ khoá Control structure (như if, else, for ...).
    Không được có dấu cách phía sau tên của method khi gọi hàm.
    Một dòng không trống không được phép có trailing whitespace (dấu cách ở cuối dòng)
    Ngoài các indent tab thì không được có quá 1 khoảng trắng liền nhau
    Cần có 1 space trước và sau các toán tử như +, -, *, /, ., >, <, == ...
    Không được có khoảng trắng dư ở cuối các dòng.
    Khi gọi một method hay một function, không được phép có khoảng trắng giữa tên của method hay function và dấu mở ngoặc tròn. Không được phép có khoảng trắng sau dấu mở ngoặc tròn. Và không được phép có khoảng trắng trước dấu đóng ngoặc tròn.
    Trong danh sách argument, không được phép có khoảng trắng trước mỗi dấu phẩy, và phải có một khoảng trắng sau mỗi dấu phẩy.
    Danh sách argument có thể được tách ra thành nhiều dòng, trong đó mỗi dòng theo sau được indent một lần. Khi làm như vậy thì argument đầu tiên phải được đặt trên một dòng mới, và mỗi dòng chỉ được phép chứa một argument.
    2.5 Khối lệnh
    Khai báo Class: Dấu mở ngặc nhọn dùng khi khai báo class phải được viết ở dòng mới (không viết cùng dòng với phần khai báo tên class), và dấu đóng ngoặc nhọn của một class phải được viết ở dòng mới sau khi kết thúc body của class.
    Khai báo Method: Dấu mở ngặc nhọn dùng khi khai báo method phải được viết ở dòng mới (không viết cùng dòng với phần khai báo tên method), và dấu đóng ngoặc nhọn của một method phải được viết ở dòng mới sau khi kết thúc body của method.
    Khai báo use:
    Những phần khai báo use phải được đặt phía sau phần khai báo namespace
    Phải dùng một từ use cho mỗi khai báo.
    Phải có một dòng trắng phía sau đoạn code use.
    Control structures:
    Dấu mở ngoặc nhọn cho control structures (như if, else, for ...) phải được viết cùng dòng, trong khi đó đấu đóng ngoặc phải được viết ở dòng mới.
    Cần phải có một dấu cách phía sau những từ khoá Control structure (như if, else, for ...). Không được có dấu cách phía sau tên của method khi gọi hàm.
    Không được có một khoảng trắng sau dấu mở ngoặc tròn hoặc trước dấu đóng ngoặc tròn
    Phải có một khoảng trắng sau đấu đóng ngoặc tròn và trước dấu mở ngoặc nhọn
    Phần thân của structure phải được indent một lần
    Từ khoá elseif nên được dùng thay cho else if, để mọi control keywords chỉ là một từ đơn.
    Phần case phải được indent một lần so với switch, và break keyword (hay các keyword ngắt khác) phải được indent giống với phần thân của case. Phải có một comment kiểu như // no break nếu phần thân của case không trống, và được cố tình cho qua (không có break)
    Phải luôn khai báo tính visibility (public, protected hay là private) của properties cũng như methods, abstract và final phải được khai báo phía trước tính visibility và staticphải được khai báo sau tính visibility.
    Nếu trước return có logic code thì phải có dòng trống phía trước nó, còn nếu không có logic code thì không có dòng trống phía trước.

    posted in Backend read more
  • KT_Tuấn_Anh KT_Tuấn_Anh

    Feature sẽ được checkout từ branch develop => sau khi hoàn thiện được create pull request về develop và assign cho người review code (ky tạo pull request cần ghi rõ chức năng giải thích các tính năng phát triển)=> người review check OK sẽ confirm lại để merge lên dev để bên QA test => Sau khi bên QA test xong chủ động tạo pull request merge lên live khi task đã ok

    Hotfix sẽ được checkout từ master => sau khi fix ok sẽ được pull request về master assign cho người review code (ky tạo pull request cần ghi rõ chức năng giải thích các tính năng phát triển) => người review code ok sẽ confirm lại để merge lên live và báo cho người hotfix check lại => nếu tính năng được fix thành công quản lý sẽ chủ động merge ngược lại về develop

    Cách đặt tên :
    feature/username_timeday_taskname -> feature/tuananh_2_2_2020_forgot_licence
    hotfix/username_timeday_bugname -> hotfix/tuananh_2_2_2020_forgot_licence

    Note
    Tính năng của ai sẽ phải chủ động test , trước khi đẩy sang cho bên thứ 3 test và nhận sản phẩm.

    posted in Backend read more