Mình đã giới thiệu MyPy trong bài viết “Giới thiệu một số công cụ hỗ trợ lập trình Python“, bài này sẽ đề cập chi tiết hơn về MyPy. Bất kỳ ngôn ngữ nào cũng phải trải qua quá trình dài để phát triển. Việc thiếu một vài tính năng ngay từ đầu cũng không có gì lạ, vì nguyên tắc thiết kế của Python là đặt sự đơn giản lên hàng đầu.

The Zen of Python (import this):

• Beautiful is better than ugly.
• Explicit is better than implicit.
• Simple is better than complex.
• Complex is better than complicated.
• Flat is better than nested.
• Sparse is better than dense.
• Readability counts.
• Special cases aren’t special enough to break the rules.
• Although practicality beats purity.
• Errors should never pass silently.
• Unless explicitly silenced.
• In the face of ambiguity, refuse the temptation to guess.
• There should be one– and preferably only one –obvious way to do it.
• Although that way may not be obvious at first unless you’re Dutch.
• Now is better than never.
• Although never is often better than right now.
• If the implementation is hard to explain, it’s a bad idea.
• If the implementation is easy to explain, it may be a good idea.
• Namespaces are one honking great idea — let’s do more of those!

Tuy nhiên, sự cần thiết của kiểm tra kiểu dữ liệu là rất quan trọng, dù nó đã không được hỗ trợ ngay từ lúc ban đầu. Hoặc cũng không là bắt buộc ở hiện tại. Không biết ông Guido hối hận gì không vì đã không đưa type-checking vào Python trước đây :D.

MyPy là gì

Ngày nay, nhiều công cụ để kiểm tra kiểu dữ liệu, nhưng MyPy trước đây được tạo ra bởi anh JukkaL, thì bây giờ đã được đưa chính thức vào chung với Python: https://github.com/python/mypy. Đó là một sự thừa nhận sự phát triển và trưởng thành của MyPy.

Type Annotation

Type checking (kiểm tra kiểu dữ liệu) là xác định rõ kiểu dữ liệu của biến, giúp phát hiện lỗi sớm hơn trong quá trình phát triển. MyPy là công cụ được sử dụng để kiểm tra các lỗi liên quan đến loại dữ liệu dựa trên type annotations.

Ví dụ:

def add(x, y):    
    return x + y

add("hai", "ba")
=> "haiba" # Kiểu string
add(2, 3)
=> 5 # Kiểu integer

add("hai", 3)
hoặc 
add(2, "ba")
=> chúng ta sẽ bị lỗi `TypeError` lúc Runtime

Vậy thì với cách viết thêm kiểu dữ liệu như dưới đây:

def add(x: int, y: int) -> int:    
    return x + y

Khi dùng MyPy để kiểm tra, thì chúng ta sẽ phát hiện ngay được lỗi trong lúc lập trình mà không sợ sẽ bị lỗi lúc runtime nữa. Python khá dễ viết nếu mã nguồn đơn giản, ngắn gọn và còn mới. Nhưng khi mã nguồn dự án trải qua thời gian dài, và lượng code phình to ra thì nếu không có xác định, kiểm tra loại dữ liệu thì sẽ gặp rất nhiều khó khăn khi debug hoặc khó hiểu khi đọc code.

Type T

Sử dụng với các kiểu dữ liệu

Kiểu dữ liệu cơ bản

Bạn có thể dùng tất cả các kiểu dữ liệu cơ bản để diễn giải kiểu dữ liệu như int, float, str, dict, tuple, set, list…, hoặc kết hợp như Tuple[int, str], Iterator[int]…

def gcd(a: int, b: int) -> int:
    while a:
        a, b = b % a, a
    return b

Ở đây mình dùng VSCode, đưa trỏ chuột vào b sẽ biết b có kiểu dữ liệu gì

Hay với ví dụ của trang chủ mypy:

from typing import Iterator

def fib(n: int) -> Iterator[int]:
    a, b = 0, 1
    while a < n:
        yield a
        a, b = b, a + b

Loại biến gọi hàm (Callable)

from typing import Callable

def twice(i: int, next: Callable[[int], int]) -> int:    
    return next(next(i))

def add(i: int) -> int:
    return i + 1

print(twice(3, add))  # 5

Với ví dụ trên, bạn có thể xác định biến đưa vào có thể gọi hàm, rất tường minh.

Kiểu dữ liệu nâng cao

Sử dụng MyPy tuy dễ nhưng cũng cần thời gian để thành thạo, bạn có thể cải thiện Type-Annotation từng bước nhỏ một. Không nhất thiết phải làm 1 lúc cho toàn bộ mã nguồn của dự án. Như vậy sẽ không bị ngán và lười.

Tuy nhiên với dự án mới thì hãy sử dụng Type-Annotation càng nhiều càng tốt. Vừa lập trình vừa có trợ lý MyPy thật là sướng biết bao.

https://mypy.readthedocs.io/en/latest/

MyPy cho Django: https://github.com/machinalis/mypy-django

The post Python: Sự cần thiết của MyPy appeared first on Fullstack Station.

Khái niệm Serverless AI

Serverless là gì

Nếu bạn là người mới về Serverless thì có thể đọc thêm bài Serverless là gì để hiểu rõ thêm. Nói đơn giản, Serverless giống như môi trường thực thi một tác vụ nào đó, ví dụ như API, mà bạn chỉ cần triển khai xong là có thể sử dụng được. Bạn không cần quan tâm đến các hạ tầng, cấu hình mạng, bộ nhớ…

Điểm mạnh của Serverless là giúp cho bạn tập trung vào giải quyết vấn đề, hơn là dành thời gian cho những tác vụ không mấy vui vẻ như cập nhật hệ thống, kiểm tra khả năng lưu trữ server, kiểm tra nhật ký hệ thống (log) xem có ai tấn công không…Quan trọng hơn hết là chỉ trả tiền cho những khi mình sử dụng!

Serverless AI là gì

Serverless AI là hạ tầng máy chủ có bộ xử lý đồ họa GPU mạnh mẽ, có thể tích hợp sẵn các model AI (Llama2, Llama3, GPT3, ResNes, StableDiffusion, Whisper…)

Tại sao Serverless AI rất quan trọng cho những người nghiên cứu AI

Chi phí, chính xác là điều chúng ta quan tâm nhất đối với serverless AI. Để đầu tư một hệ thống GPU mạnh mẽ thường sẽ tốn khá nhiều chi phí ban đầu, cũng như chi phí vận hành thường xuyên. Hoặc nếu dùng cloud, bạn cũng sẽ tốn nhiều chi phí khác để vận hành, và mất thêm thời gian để quản lý. Với serverless AI, bạn có thể chỉ trả tiền cho những lúc chúng ta gọi API.

Về cơ bản thì serverless AI cũng là API được sử dụng như API để tương tác với OpenAI chẳng hạn, và OpenAI thì đã tích hợp sẵn một số model như GPT-3, GPT-4…

Một số nhà cung cấp

Cloudflare

Website: https://ai.cloudflare.com/

Danh sách các model

Text Generation @cf/meta/llama-3-8b-instruct

Text Generation @cf/mistral/mistral-7b-instruct-v0.1

Text to Image @cf/bytedance/stable-diffusion-xl-lightning

Speech Recognition @cf/openai/whisper

Image Classification @cf/microsoft/resnet-50

Text Classification @cf/huggingface/distilbert-sst-2-int8

Text Embedding @cf/baai/bge-base-en-v1.5

Translation @cf/meta/m2m100-1.2b

Runpods

Website: https://www.runpod.io/serverless-gpu

Fermyon

Website: https://www.fermyon.com/

Fullstack Station Tips

Với CloudFlare là nhà cung cấp hạ tầng khá nổi tiếng, với việc hỗ trợ nhiều model và cách sử dụng khá là dễ dàng. Chỉ cần tạo token key là bạn có thể thao tác được với các model trong CloudFlare. CloudFlare có gói miễn phí dùng thử khá hấp dẫn, được khởi tạo lại theo ngày, chứ không phải theo tháng. Nên với các ứng dụng đơn giản, thì hoàn toàn có thể sử dụng trên CloudFlare miễn phí

Với Serverless AI, bạn có thể nhanh chóng tìm hiểu và kiểm tra tính thực tiễn của các model. Thực nghiệm các ý tưởng để bắt xu hướng AI nhanh hơn!

The post Bắt kịp xu hướng AI với serverless AI appeared first on Fullstack Station.

Đã sử dụng Laravel thì có lẽ mọi người cũng biết đến laravel-query-detector, một thư viện nho nhỏ để phát hiện N+1 Query. Tuy nhiên, vì nhiều lý do thì trong quá trình phát triển, chúng ta chưa chú ý giải quyết vấn đề “N+1 Query” này. Đến một lúc nào đó, khi lượng truy vấn nhiều lên (mức sử dụng database) thì vấn đề N+1 Query lại trở thành chủ đề cần giải quyết càng sớm càng tốt.

Câu truy vấn N+1 (N+1 Query) là gì

Nói ngắn gọn là Laravel sinh ra nhiều câu query hơn mức cần thiết. Chính xác hơn là 1+N, tức là khi ta truy vấn 1 query, mà query đó có quan hệ 1-nhiều (1-n), nhiều-nhiều (n-n) sẽ làm nảy sinh thêm n (nhiều) câu query khác. Lý do là Laravel cho phép chúng ta viết code cho model dễ đọc, mà không cần phải hiểu cách hoạt động đằng sau của chúng.

Tất nhiên, vấn đề này nảy sinh không phải chỉ do Eloquent hay chỉ đối với mỗi mình Laravel, mà trong cả ngành công nghiệp lập trình khi mà chúng ta sử dụng các framework vì sự tiện dụng của chúng.

Trong nội dung bài viết này, sẽ không đề cập đến cách giải quyết vấn đề này trong Laravel, bạn có thể tìm kiếm trên các bài viết khác nhé.

Phát hiện câu truy vấn có vấn đề N+1 Query

Khi sử dụng laravel-query-detector, bạn sẽ phát hiện N+1 Query và dựa theo cấu hình tương ứng để nắm thông tin N+1 Query.

Trong từng API (dùng clockwork):

Trong từng màn hình (dùng cấu hình Alert):

Trong từng màn hình (sử dụng debugbar, kết hợp cấu hình Log):

Danh sách các thiết lập thì bạn có thể xem thêm tại đây: https://beyondco.de/docs/laravel-query-detector/usage

    /*
     * Define the output format that you want to use. Multiple classes are supported.
     * Available options are:
     *
     * Alert:
     * Displays an alert on the website
     * \BeyondCode\QueryDetector\Outputs\Alert::class
     *
     * Console:
     * Writes the N+1 queries into your browsers console log
     * \BeyondCode\QueryDetector\Outputs\Console::class
     *
     * Clockwork: (make sure you have the itsgoingd/clockwork package installed)
     * Writes the N+1 queries warnings to Clockwork log
     * \BeyondCode\QueryDetector\Outputs\Clockwork::class
     *
     * Debugbar: (make sure you have the barryvdh/laravel-debugbar package installed)
     * Writes the N+1 queries into a custom messages collector of Debugbar
     * \BeyondCode\QueryDetector\Outputs\Debugbar::class
     *
     * JSON:
     * Writes the N+1 queries into the response body of your JSON responses
     * \BeyondCode\QueryDetector\Outputs\Json::class
     *
     * Log:
     * Writes the N+1 queries into the Laravel.log file
     * \BeyondCode\QueryDetector\Outputs\Log::class
     */
    'output' => [
        \BeyondCode\QueryDetector\Outputs\Log::class,
        \BeyondCode\QueryDetector\Outputs\Alert::class,
    ]

Hệ thống của bạn có bao nhiêu câu truy vấn có vấn đề N+1 Query?

Vì nhiều lý do, trong 1 dự án có nhiều người với peer-review yếu, hoặc chưa quan tâm lắm đến vấn đề N+1 Query, thì khả năng bỏ qua vấn đề N+1 Query khá là cao. Vì vậy đến một lúc nào đó khi bạn trở thành người quản lý dự án đó, chịu trách nhiệm nâng cao hiệu suất sử dụng database bạn sẽ rất vất vả để tìm ra các điểm nghẽn đó.

Ý tưởng cũng khá đơn giản: viết toàn bộ testcase cho tất cả router, khi chạy test thì sử dụng laravel-query-detector ghi log các câu truy vấn có vấn đề N+1 Query ra 1 file riêng, dùng các lệnh về xử lý file để tìm kiếm và thống kê.

Viết toàn bộ testcase cho tất cả router

Nếu bạn có viết testcase rồi thì tốt, không có thì cũng chỉ cần viết cái testcase đơn giản là gọi đến toàn bộ route rồi cho skip cũng được . Làm sao đảm bảo là gọi hết đến tất cả các route thì mới phát hiện được hết được. Không có thời gian thì viết cho mấy cái route quan trọng cũng được

Cấu hình laravel-query-detector

php artisan vendor:publish --provider="BeyondCode\QueryDetector\QueryDetectorServiceProvider"

Ta sẽ có được file config/querydetector.php

...
/* Chú ý dòng này, nếu bạn có file phpunit.xml, cần thiết lập QUERY_DETECTOR_ENABLED=true */
'enabled' => env('QUERY_DETECTOR_ENABLED', null),
...
/* Tùy theo tính chất khắt khe mà đặt chốt chặn phù hợp */
'threshold' => (int) env('QUERY_DETECTOR_THRESHOLD', 1),
...
'log_channel' => env('QUERY_DETECTOR_LOG_CHANNEL', 'querydetector'),
...
'output' => [
      ...
        \BeyondCode\QueryDetector\Outputs\Log::class,
      ...
    ]

Chúng ta sẽ ghi log vào channel ‘querydetector’, vậy nên phải cấu hình channel trong file config/logging.php

'querydetector' => [
            'driver' => 'single',
            'path' => storage_path('logs/querydetector.log'),
            'level' => env('LOG_LEVEL', 'debug'),
            'days' => 14,
        ]

Như vậy toàn bộ kết quả của laravel-query-detector sẽ được ghi vào file storage/logs/querydetector.log

Thống kê

grep "Detected N+1 Query" storage/logs/querydetector.log | wc -l

Ok, như vậy là ta sẽ ra được 1 con số, được hiểu là số vấn đề N+1 Query đang tồn tại trong hệ thống. Con số này có thể không chính xác vì nhiều lý do:

• Một route được viết testcase nhiều lần – nói 1 cách khác là được gọi nhiều lần.
• Trong một route, số vấn đề N+1 Query là số nhiều

Nhưng nếu kết quả là số 0 thì chúc mừng bạn, hệ thống của bạn không có vấn đề (mặc dù còn phụ thuộc số lượng testcase)

Sử dụng CI: GithubAction để thống kê

Nếu bạn có sử dụng CI với GithubAction, thì với kết quả của phpUnit, bạn làm thêm 1 vài thao tác nữa sẽ được kết quả như thế này:

316 – con số thật khủng khiếp phải không nào :D, điều tuyệt vời là bạn đã biết được con số đó, và mỗi khi giải quyết N+1 Query được push lên, GithubAction sẽ comment con số cuối cùng.

File cấu hình ci.yml sẽ được chỉnh sửa thêm vào như sau:
//ci.yml
on: [ pull_request ]
jobs:
  phpUnit:
      - name: chạy phpunit
     .... "./vendor/bin/phpunit --stop-on-failure"
      - name: N+1 Query Report #Đọc kết quả querydetector, thống kê và lưu vào file n-1-query-summary.log
        run: |
          grep "Detected N+1 Query" storage/logs/querydetector.log | wc -l > storage/logs/n-1-query-summary.log
        working-directory: ${{env.working-directory}}
      - name: Read coverage summary #Đọc nội dung file n-1-query-summary.log
        id: n-1-query-summary
        uses: juliangruber/read-file-action@v1
        with:
          path: ./app/laravel/storage/logs/n-1-query-summary.log
      - name: Comment N+1 Query Summary # Comment kết quả vào PR
        uses: marocchino/sticky-pull-request-comment@v2
        with:
          recreate: true
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          header: n-1-query
          message: |
            ## N+1 Query Summary
            Number of N+1 queries: ${{ steps.n-1-query-summary.outputs.content }}
      - name: Archive N+1 query detector results # Lưu log của querydetector vào Artifact của github
        uses: actions/upload-artifact@v2
        with:
          name: n+1-query-report
          path: ./app/laravel/storage/logs/querydetector.log

File querydetector.log sẽ được upload lên artifacts của Github

Như vậy ở góc độ quản lý dự án, bạn không cần phải chạy test trên máy của mình mà vẫn đảm bảo chất lượng dự án ngày càng cải thiện, ít nhất là phải biết hiện trạng của dự án.

Fullstack Station Tips

• Khi bạn đã biết số vấn đề còn tồn tại , có thể đưa vào CI (ci.yml chẳng hạn) để đảm bảo con số đó không tăng lên khi phát triển thêm chức năng.
• Có thể dựa vào danh sách file có vấn đề N+1 Query trong querydetector.log để so sánh với danh sách file được thêm/sửa. Nếu nằm trong querydetector.log thì không cho pass CI

The post Dùng CI:GithubAction để phát hiện toàn bộ câu truy vấn N+1 trong Laravel appeared first on Fullstack Station.

Tại sao nên xài docker

Thú thật, mình cũng từng như bạn, không chịu rời bỏ cái môi trường lập trình đang chạy ngon lành trên máy của mình, cho đến một ngày…Đơn giản là đời làm lập trình có nhiều dự án, mỗi dự án yêu cầu môi trường, cấu hình khác nhau, rồi môi trường lập trình trên máy cũng khác. Ví dụ, trên máy dùng VSCode dùng phần rộng PHP đòi phải PHP 7, nhưng dự án A chỉ chạy trên 5.6, dự án B chỉ chạy trên PHP 7.2. Ngoài ra còn có nhiều tổ hợp công nghệ như kết hợp với Mysql hay Postgres, Elasticsearch…không phải mọi thứ đều cài lên máy chạy cùng lúc rất cực để quản lý và không hiệu quả.

Ngoài ra, một số thư viện cài đặt thỉnh thoảng có trục trặc với máy vì phải build lại, việc các thư viện chỉ chạy trên một vài version tương thích thường xuyên xảy ra. Điều này khiến cho bạn mất khá nhiều thời gian cho việc quản lý môi trường lập trình của mình, đây là điều nên tránh, hãy tập trung năng lượng cho công việc chính, còn môi trường phát triển hãy để docker lo.

Giới thiệu Lando

Lando là một nền tảng miễn phí, mã nguồn mở, đa nền tảng dựa trên docker dành cho lập trình viên, cải thiện môi trường làm việc bằng cách gom tổ hợp công nghệ bạn sử dụng thành 1 file cấu hình, thiết lập môi trường lập trình dễ dàng hơn bao giờ hết.

Homepage: https://devwithlando.io

Nói một cách ngắn gọn, nếu bạn biết WAMP hoặc MAMP, thì Lando là ông nội của 2 thằng này. Ví dụ lập trình

Các tổ hợp, ngôn ngữ đã được hỗ trợ

Ngôn ngữ

Các ngôn ngữ sau đã được hỗ trợ:

• dotnet
• go
• node
• php
• python
• ruby

Tổ hợp

Các tổ hợp đã được cấu hình sẵn:

• Backdrop
• Drupal 6
• Drupal 7
• Drupal 8
• Joomla
• Laravel
• MEAN
• LAMP
• LEMP
• Pantheon
• WordPress

Các dịch vụ

Các dịch vụ sau cũng được hỗ trợ:

• apache
• elasticsearch
• mailhog
• mariadb
• memcached
• mongo
• mssql
• mysql
• nginx
• phpmyadmin
• postgres
• redis
• solr
• tomcat
• varnish

Tại sao nên dùng Lando

Nếu bạn tìm thấy một trong các công nghệ, dịch vụ, ngôn ngữ lập trình được hỗ trợ và liệt kê ở trên “quen thuộc” với công việc hàng ngày của mình, thì bạn đã có lý do sử dụng Lando.

Như ví dụ mình có nói ở trên, việc có nhiều dự án quả thật là rất phức tạp để quản lý môi trường lập trình. Mình đảm nhiệm các dự án trong công ty từ nhỏ đến lớn với các ngôn ngữ như Go, Python, Nodejs, PHP thì Go và Python là ít gặp trục trặc nhưng PHP thì nhiều, và nhiều nhất là Nodejs vì Nodejs ra phiên bản mới liên tục. Dự án cũ 2,3 năm trước thì xài công nghệ, phiên bản cũ tới lúc mình cập nhật máy và thư viện liên quan thì khi quay lại dự án cũ nó không chạy :((. Và mất thời gian chỉnh sửa môi trường làm việc như vậy vài lần, đến mức độ mình thấy sợ. Từ khi có Lando, khi muốn chạy dự án nào, chỉ cần: `lando start` là xong.

Các tính năng nổi bật của Lando:

• Sao chép tương tự môi trường production cho máy bạn
• Quy chuẩn hoá mọi trường lập trình của đội ngũ đa nền tảng OSX, Window, Linux
• Tuỳ chỉnh hoặc mở rộng công cụ, cấu hình triển khai
• Chạy CI test trên máy của bạn.
• Sử dụng môi trường duy nhất cho tất cả các dự án
• Tích hợp với nhà cung cấp dịch vụ hosting như Pantheon

Mặc dù bạn có thể nhận ra là Docker Compose cũng có tính năng tương tự, tuy nhiên có một vài sự khác biệt:

• Lando là một lớp trừu tượng đã làm giảm bớt tính phức tạp khi cấu hình các container bằng cách sử dụng “công thức” (recipes) cho một số stack phổ biến.
• Lando cung cấp nhiều phương thức giúp lập trình viên chạy những dòng lệnh phức tạp, các bước build, … và tự động hoá các dịch vụ mà không cần tinh chỉnh Dockerfiles
• Lando quản lý một số tác vụ cài đặt phức tạp được yêu cầu để có một Docker Composer tốt như proxy, nice urls, cross-application netwroking.
• Ngoài ra, bạn vẫn có thể tuỳ biến dễ dàng Docker Compose.

Nói 1 cách khác, Lando đã giúp đơn giản hoá Docker Compose cho một số tác vụ, stack phổ biến. Chỉ cần 1 câu lệnh, các dịch vụ đi kèm đều được khởi tạo, mất chưa đầy 2 phút là bạn có thể chạy được stack.

Bắt tay vào thực hành Lando

Mình không muốn nói phần này nhiều, chỉ cần sau khi bạn cài đặt Docker, Lando thì bạn chỉ mất 5 phút để tạo 1 dự án WordPress, Laravel, Drupal, Joomla hay LAMP, LEMP bất kỳ chỉ việc sử dụng công thức đã liệt kê ở trên.

5 phút đơn giản chỉ là tạo cái file .lando.yml, đây là file mẫu dùng cho WordPress (dùng với Bedrock/Sage sẽ được giới thiệu ở bài khác)

name: seikeidenron
recipe: wordpress
proxy:                
  nginx:              # Tuỳ chọn: nếu bạn bỏ qua cấu hình này thì Lando sẽ chạy ở seikeidenron.lndo.site
    - seikeidenron.localhost
  theme:              # Tuỳ chọn: ở đây mình phát triển thêm theme của wordpress thì sẽ cần tới node
    - localhost:3000
config:
  php: '7.2'
  via: nginx
  webroot: web
  database: mariadb
  xdebug: true

# Đoạn này cần để thiết lập node
services:
  theme:
    type: node
    services:
      ports:
        - 3000:3000
tooling:
  yarn:
    service: theme

Xong file trên thì chỉ cần lando start là mọi thứ chạy, quá nhanh quá nguy hiểm.

Fullstack Station Tips

Các công thức có sẵn đa phần đều có phần database riêng lẻ, tuy nhiên nếu các dự án của bạn đều sử dụng mysql chẳng hạn, thì hãy sử dụng database server của máy bạn, chứ không phải database server của docker. Như vậy thì việc sử dụng Lando sẽ trở nên nhanh chóng hơn, nhất là đối với các dự án đang giai đoạn lập trình. Ở phần kết nối db thì thay vì bạn dùng localhost thì hãy đổi thành host.docker.internal, đây chính là máy host, máy chính của bạn.

The post Docker thực chiến: môi trường phát triển appeared first on Fullstack Station.

Các công cụ hỗ trợ kiểm tra kiểu dữ liệu

Kiểm tra kiểu dữ liệu là gì?

Đối với các ngôn ngữ lập trình kiểu động, thông dịch như Python, Javascript (Xem thêm Flow: type-checker cho Javascript), Php thì kiểu dữ liệu không bị ràng buộc dẫn đến việc 1 biến, 1 hàm có thể nắm giữ/trả về các kiểu dữ liệu khác nhau trong quá trình thực thi. Mặc dù đây là đặc tính của những ngôn ngữ này, chứ không hẳn là 1 điểm yếu, tuy nhiên để nâng cao khả năng hạn chế lỗi thì chúng ta vẫn cần nâng cao khả năng viết code và sự hỗ trợ của các công cụ.

Ví dụ:

def add(x, y):    
    return x + y

add("hai", "ba")
=> "haiba" # Kiểu string
add(2, 3)
=> 5 # Kiểu integer

add("hai", 3)
hoặc 
add(2, "ba")
=> chúng ta sẽ bị lỗi `TypeError`

Điều này thường dẫn đến các lỗi chương trình mà có xác suất xảy ra thấp và chỉ phát hiện trong lúc thực thi, khiến cho việc gỡ lỗi rất khó khăn.Tầm quan trọng của việc kiểm tra kiểu dữ liệu (type checker) khá cao, và cũng được nói rõ PEP 484 (https://www.python.org/dev/peps/pep-0484/), dựa vào PEP 484 ta sẽ sửa lại như sau:

def add(x: int, y: int) -> int:    
    return x + y

Như vậy, mã nguồn có tính dễ đọc dễ hiểu ngay đầu vào và kết quả trả về của hàm, mã nguồn có tính dễ bảo trì và sẽ hạn chế lỗi không mong muốn. Trong mã nguồn chỉ cần bạn viết theo cấu trúc đó là bạn đã hoàn thành nhiệm vụ của bạn, phần còn lại hãy để các công cụ hỗ trợ bạn.

Ưu và khuyết điểm

Ưu điểm:

• Nâng cao khả năng hạn chế lỗi lúc thực thi vì có thể phát hiện được lỗi trong quá trình lập trình.
• Nâng cao khả năng dễ đọc của mã nguồn vì tính rõ ràng của dữ liệu, giúp các lập trình viên dễ dàng nắm rõ chương trình hơn.
• Khả năng hiểu cấu trúc của chương trình tốt hơn khi bạn nắm vững luồng dữ liệu lúc thực thi.

Khuyết điểm:

• Giống như hướng tiếp cận TDD (Test-driven development) thì việc viết code theo hướng có chú giải sẽ mất nhiều thời gian hơn 1 chút, và code nặng hơn 1 tí.
• Mặc dù có type-checker nhưng bản chất Python là dynamic typed, vì vậy kiểu dữ liệu vẫn được tự do bất chấp bạn có viết diễn giải (annotation) kiểu dữ liệu.
• Cần sử dụng cách viết trong toàn bộ mã nguồn để đạt hiệu quả. Giả sử hàm trên addđược gọi từ 1 hàm khác, và dữ liệu truyền vào không xác định được, thì các công cụ type-checker cũng không kiểm tra được.

Static typing. Sure “real” developers may not need static typing, but if you end up in a situation where a system needs a critical bug fix and the core developers aren’t around anymore or on vacation, and the fix needs to roll out to millions of users, any static analysis ahead of runtime is extremely useful.

Wolfgang Grieskamp, Google Inc.
Tạm dịch: Rõ ràng là đối với lập trình viên thực thụ sẽ không cần quan tâm kiểu dữ liệu, nhưng một lúc nào đó bạn đối mặt với hoàn cảnh là hệ thống cần sửa lỗi nghiêm trọng, và lập trình viên chính không ở đó hoặc đang trong kỳ nghỉ, và việc sửa lỗi ảnh hưởng đến hàng triệu người dùng, thì việc phân tích kiểu dữ liệu trước khi thực thi là cực kỳ cần thiết.

Pyre và Mypy, Pyright

Pyre: https://pyre-check.org/

Mypy: http://mypy-lang.org

Mypy là công cụ được tạo ra trước, nhưng Pyre do Facebook tạo ra, và do cũng được kỳ vọng do đã thành công với các ngôn ngữ khác như Flow cho Javascript hay Hack cho PHP nên Pyre có thể được ưu chuộng hơn. Cá nhân mình sử dụng Mypy là chính, nhưng cũng có cài thêm Pyre để sử dụng cả 2 thì cũng không ảnh hưởng gì. Mặc dù Pyre được quảng cáo là chạy nhanh, nhưng do tính chất chạy nền của các loại công cụ này nên việc nhanh hơn thực sự không quan trọng lắm.

Pyright: https://github.com/Microsoft/pyright

Pytype

Mặc dù Pytype cũng là 1 công cụ type-checker nhưng với khả năng kiểm tra kiểu dữ liệu không cần type-annotations nghĩa là bạn không cần phải viết chú thích (tuy nhiên đó không phải là mục tiêu của Pytype), đồng thời có thể kiểm tra nhiều kiểu lỗi khác.

Điểm đặc biệt của Pytype là có thể cải tạo các mã nguồn không có type-annotations thành có, tuy nhiên hiện tại chỉ mới dừng ở mức độ từng file, nên nếu dự án có lượng mã nguồn lớn thì cũng tốn nhiều công sức chuyển đổi.

Pycharm

Bạn đang dùng Pycharm thì chúc mừng bạn là type-checker đã được hỗ trợ tích hợp sẵn công cụ type-checker. Tuy nhiên, mình không dùng Pycharm vì phải trả phí cho bản Pro (bản Community khá hạn chế) trong khi hiện tại mình dùng VSCode khá tốt.

Các công cụ hỗ trợ format code

Nếu bạn dùng Pycharm, bạn có thể không cần suy nghĩ nhiều về format code, nhưng trong khía cạnh này có rất nhiều công cụ: autopep8, yapf của Google, Black, isort

Mình thì sử dụng Black, xài rất tốt và hiện tại cũng đạt hơn 8500 stars ở Github gần bằng Yapf, mặc dù được phát triển sau này nhưng Black cũng đạt được tiếng vang tốt, mình nghĩ dùng Black là ổn.

Các công cụ về Linting

Linting thì đa phần các IDE, hay các Text Editors có hỗ trợ Python thì đều có cài đặt sẵn các công cụ lint như Pyflakes, Pylint, pycodestyle, pydocstyle

Các công cụ về Linting ở đây và các công cụ về type-checker, format code có nhiều điểm tương đồng và chồng chéo lẫn nhau, nhưng ở đây Linting xét về tính logic như sử dụng dư thừa thư viện, biến, hoặc các biểu thức logic dư thừa …

Trong khía cạnh này thì `pycodestyle` có phần chiếm ưu thế vì tốc độ thực thi nhanh và khả năng bắt lỗi tốt. Phần linting được trình bày sau bởi vì nếu bạn sử dụng type-checker và format code tự động thì phần linting còn lại sẽ chỉ tập trung vào tính logic của mã nguồn, mặc dù có thể có trùng lắp tính năng nhưng không sao, thà thừa hơn thiếu.

Fullstack Station Tips

Việc tuân thủ coding-standard là cực kỳ quan trọng đảm bảo tính nhất quán theo chuẩn của dự án và hạn chế các lỗi phát sinh ngoài ý muốn. Trong đó viết code theo type-annotations là quan trọng nhất vì có nhiều hiệu quả, còn các thứ khác đa phần là được giải quyết tự động thông qua việc format code và sửa theo gợi ý của các công cụ Linting.

Mỗi khi mình viết code, mà không có type-annotations thì chắc chắn 1 điều là mình hiểu chưa tốt các kiểu dữ liệu của các bộ thư viện đang sử dụng hoặc chính mã nguồn của dự án. Điều này xảy ra khi mình học thêm các thư viện bên mảng Machine Learning như Numpy, Pandas, Pytorch, dẫn tới là 1 áp lực phải học, hiểu rõ các kiểu dữ liệu của các thư viện này.

Bộ công cụ mà mình sử dụng là: mypy, Black và pycodestyle, pytype.

(Pyright là công cụ mới nổi lên từ cuối tháng 3/2019, mình sẽ sử dụng xem như thế nào và báo cáo mọi người sau)

Tham khảo

https://realpython.com/python-code-quality/

https://medium.com/@CodingZen/codingzen-static-typing-in-python-no-way-afb643c334f

The post Giới thiệu một số công cụ hỗ trợ lập trình Python appeared first on Fullstack Station.

Grep

Thường thì “grep” được dùng để tìm kiếm text trong file, rất hay được dùng khi kiểm tra log hoặc tập tin văn bản.

$ grep 'keyword' /var/log/path.log

Một số tuỳ chọn hữu ích

$ grep -A 5 -B 6 --color 'keyword' /var/log/path.log

Lệnh trên sẽ làm nổi bật `keyword` bằng màu sắc với --color, và -A 5hiển thị 5 dòng sau (A: After) dòng có chứa keyword, tương tự với -B 6 là hiển thị 6 dòng trước (B: Before) dòng có chứa keyword, nếu dùng -C 7 thì nghĩa là trước 7 dòng và sau 7 dòng.

Kết hợp wc

Chúng ta sẽ kết hợp với wc (wordcount) để đếm số dòng, số byte, số ký tự mà chúng ta cần

$ grep 'keyword' /var/log/path.log | wc -l

Với lệnh trên, thì sẽ đếm xem có bao nhiêu dòng chứa `keyword`, hoặc thay thế tuỳ chọn -l bằng -m sẽ đếm xem có bao nhiêu ký tự, hoặc -c sẽ đếm byte, thường dùng nhất vẫn chỉ có -l.

Kết hợp awk

$ cat access.log | awk '{print $1}'

Nâng cao thêm 1 chút bằng printf

$ cat access.log | awk '{printf ("Nội dung là %s %s", $1, $2)}'

Ứng dụng vào việc tìm IP có số lượng gởi yêu cầu vào máy chủ nhiều nhất

$ cat access.log | awk '{print $1}' | sort -n | uniq -c | sort -nr | head -20

Giả sử $1 ở đây là IP (file log thông thường của server), thì lệnh awk sẽ lấy danh sách IP, và được sắp xếp và lấy duy nhất không trùng lặp bằng lệnh sort -n | uniq -c sau đó sắp xếp đảo ngược với sort -nr và kết thúc là lấy 20 kết quả đầu tiên bằng head -20

Tìm kiếm tập tin, thư mục bằng Find

Lệnh find cũng ít khi sử dụng, nhưng tầm quan trọng và tính hữu dụng thì rất cao.

find -type f -name ‘*.log’ -mtime +15

Câu lệnh trên cơ bản tìm trong thư mục hiện hành tất cả các tập tin có đuôi .log với thời gian cập nhật mtime hơn 15 ngày (+15) hoặc có thể tìm theo thời gian tạo bằng ctime

Lệnh này được sử dụng khi cần xoá các tập tin khi dung lượng ổ cứng bị đầy, hoặc là cần lập lịch tự động xoá file backup sau 15 ngày chẳng hạn.

Kết hợp xoá tập tin

find -type f -name ‘*.log’ -mtime +15 -exec rm {} \;

hoặc

find -type f -name ‘*.log’ -mtime +15 | xargs rm

Tìm thư mục có dung lượng cao

du -h | sort -hr | head -5

Câu lệnh trên cho phép tìm 5 thư mục có dung lượng cao nhất trong thư mục hiện hành, nếu ta thêm --max-depth=1 thì lệnh chỉ giới hạn ở thư mục con cấp 1.

Fullstack Station Tips

Có hằng hà sa số câu lệnh cần thiết, nhưng mấy lệnh này mình hay sử dụng nhất. Từ các lệnh cơ bản này, bạn có thể xem phần `help` của mỗi lệnh để có thêm tuỳ chọn.

The post Một số lệnh hữu ích cho xử lý tập tin, thư mục bằng command line appeared first on Fullstack Station.

Cập nhật 04/2024: Serverless AI là gì?

Serverless là gì?

Serverless là môi trường, nền tảng thực thi ứng dụng và dịch vụ mà không phải quan tâm đến máy chủ. Ứng dụng serverless không cần phải  quan tâm việc phân bổ, quản lý tài nguyên của hệ điều hành, và bỏ qua các vấn đề về nâng cấp và bảo mật. Với khái niệm là chỉ cần tập trung phát triển sản phẩm, việc còn lại về vận hành sẽ để nền tảng này đảm nhiệm.

Điều quan trọng và khác biệt nhất trong serverless là bạn chỉ trả tiền khi và chỉ những phần bạn sử dụng. Giả sử bạn có một máy chủ ảo, thì thường sẽ được tính tiền trọn gói bao gồm thời gian chạy 24/7 trong 1 tháng, CPU và RAM, băng thông, lưu trữ. Bạn vẫn sẽ phải trả tiền hàng tháng đều đặn cho dù cái máy chủ ảo đó không chạy, hoặc chỉ sử dụng 5~10% công suất thì bạn vẫn phải trả trọn gói. Hiểu một cách nôm na, thì serverless như gói cước điện thoại được tính theo block giây, gọi bao nhiêu tính tiền bấy nhiêu, còn máy chủ ảo thường thì phải trả tiền thuê bao hàng tháng dù có phải sử dụng hay không.

Ưu và nhược điểm của serverless

Ưu điểm

Xây dụng ứng dụng serverless đồng nghĩa với việc bạn chỉ tập trung vào sản phẩm cốt lõi thay vì phải lo lắng về việc quản lý và vận hành nhiều máy chủ hoặc thời gian chạy, dù trên nền tảng đám mây hay tự xây dựng hệ thống máy chủ. Sự cắt giảm công sức tổng thể này sẽ giúp cho các nhà phát triển dành thời gian và năng lượng để tập trung vào việc xây dựng các sản phẩm tuyệt vời có quy mô linh hoạt và ổn định cao.

Không cần quản lý máy chủ: Bạn sẽ không cần cung cấp hay duy trì bất kỳ máy chủ nào. Sẽ không cần phần mềm hoặc thời gian chạy để cài đặt, nâng cấp hoặc quản trị.

Thay đổi quy mô một cách linh hoạt: Ứng dụng của bạn sẽ có khả năng thay đổi quy mô tự động hoặc bằng cách điều chỉnh dung lượng thông qua việc chuyển đổi đơn vị sử dụng (ví dụ: thông lượng, bộ nhớ) thay vì với máy chủ độc lập thì sẽ phức tạp hơn.

Độ sẵn sàng cao: Ứng dụng serverless có độ sẵn sàng tích hợp và dung sai cao. Bạn sẽ không cần tạo kiến trúc cho các khả năng này do các dịch vụ chạy ứng dụng đã cung cấp cho ứng dụng theo mặc định. Ngoài ra, có để chọn trung tâm dữ liệu (một hoặc nhiều nơi) để triển khai sản phẩm một cách dễ dàng.

Tiết kiệm chi phí: chi phí gần như bằng 0 sau khi triển khai nếu bạn không có request nào (hoặc không có hành động gọi hàm), còn sử dụng bao nhiêu thì tính tiền bấy nhiêu.

Khuyết điểm

Serverless là một ý tưởng tuyệt vời nhưng không hoàn hảo, serverless có những vấn đề riêng mà bạn cũng phải suy nghĩ trước khi quyết định sử dụng:

Độ trễ: Hiệu suất có thể là một vấn đề, chính bản thân mô hình này có thể gây ra độ trễ lớn hơn trong quá trình các nguồn tài nguyên điện toán phản ứng lại với lệnh của các ứng dụng. Nếu khách hàng yêu cầu hiệu suất cao thì việc sử dụng các máy chủ ảo được phân bổ sẽ là một lựa chọn ưu việt hơn.

Gỡ lỗi (Debug): Công việc giám sát và gỡ lỗi của serverless computing cũng khá khó khăn. Việc bạn không sử dụng một nguồn tài nguyên máy chủ thống nhất làm cho cả hai hoạt động này gặp nhiều trở ngại. (Tin tốt là công cụ này sẽ dần được để cải thiện xử lý giám sát và gỡ lỗi tốt hơn trong môi trường không máy chủ.). Ngoài ra, để giám sát thường cần có 1 thêm các công cụ tương ứng nền tảng đó, chi phí có thể phát sinh thêm.

Giới hạn về bộ nhớ, thời gian: các nhà cung cấp đều giới hạn tài nguyên ở các mức cố định về bộ nhớ và thời gian thực thi (timeout). Giả sử timeout tối đa là 5 phút, nếu bạn chạy quá 5 phút, quá trình thực thi sẽ bị ngắt. Về bộ nhớ, thì sẽ thiết lập mỗi mức khác nhau tuỳ nhà cung cấp, AWS có memory là 3008MB (sẽ được cấp CPU cao tương ứng), nếu ứng dụng yêu cầu bộ nhớ lớn thì sẽ không đáp ứng được. Liên quan đến vấn đề bộ nhớ này, thì cũng cần phải lưu tâm lúc lập trình nên tối ưu tốt, để tiết kiệm chi phí.

Phụ thuộc nhà cung cấp: bạn không thể muốn chạy phiên bản của phần mềm, nền tảng chính xác như bạn muốn. Ví dụ Nodejs bạn cần 10.x nhưng nhà cung cấp chỉ hỗ trợ đến 8.x, thì bạn sẽ không sử dụng được nền tảng này. Như vậy, trước khi sử dụng, bạn cần cân nhắc các nền tảng được hỗ trợ.

Chi phí ngầm: tuỳ nhà cung cấp có tính hay không, nhưng cơ bản là sẽ phát sinh chi phí lưu trữ mã nguồn, băng thông, và chi phí về lưu trữ dữ liệu (tuỳ ứng dụng có sử dụng hay không, ví dụ DynamoDB, RDMS … thì sẽ được tính riêng). Mặc dù, tuy không nhiều nhưng nếu không tối ưu, các phần chi phí ngầm sẽ còn cao hơn cả chi phí cho serverless.

Thời gian để nghiên cứu: trước đây bạn phải học cách sử dụng, quản lý máy chủ thì giờ đây bạn cũng cần thời gian để học để quản lý các tài nguyên trong serverless, mặc dù ko phải quá khó như quản lý máy chủ, nhưng không thể không tính. Ví dụ bạn sẽ mất thời gian để hiểu về cách sử dụng CloudFormation, IAM policies, quản lý cấu hình về stage, region, memory của Functions…

Khi nào nên sử dụng serverless

Có rất nhiều trường hợp có thể ứng dụng được serverless, điểm chung là tất cả những ứng dụng không dính dáng đến điểm yếu của serverless

Websites và APIs: hoàn toàn có thể xây dựng 1 website hoặc API, website có thể là động hoặc là bán tĩnh (bán tĩnh nghĩa là nguồn gốc file là tĩnh, nhưng dùng route động). Thường thì người ta hay xây dựng Restful API với serverless, nhưng mình thích áp dụng cho Graphql hơn, vì Restful có thể trả về dữ liệu không dùng tới nhưng mình phải trả tiền băng thông (Xem thêm Graphql là gì).

Xử lý đa phương tiện: các thao tác xử lý hình ảnh, video với yêu cầu không quá cao như cắt, nén, định dạng kích thước ảnh, tạo ảnh thumbnail, hoặc chuyển đổi bộ mã của video để phù hợp với thiết bị tương ứng.

Xử lý sự kiện: có thể đóng vai trò như 1 công tắc cầu giao để thực hiện một loạt các hành động khác khi được kích hoạt tuỳ theo sự kiện.

Xử lý dữ liệu: tuỳ theo ngữ cảnh mà có thể ứng dụng như chatbot, IoT,… lý do mà serverless thích hợp với mảng này vì với chatbot hay IoT chúng ta không biết khi nào dữ liệu sẽ tới, khi nào sẽ cần xử lý dữ liệu nên chúng ta không cần phải xây dựng máy chủ luôn luôn chạy và lãng phí ở thời gian chờ.

So sánh một số nhà cung cấp hàng đầu

Hiện nay có rất nhiều nhà cung cấp dịch vụ giúp bạn tạo ra các functions sử dụng mô hình serverless một cách khá dễ dàng:

• AWS Lambda: nói về thị phần cung cấp hạ tầng cloud hiện nay thì AWS vấn đang dẫn đầu và họ cũng đưa ra dịch Lambda để người dùng có thể sử dụng và tạo ra các functions trên mô hình serverless. Khi kết hợp với các dịch vụ khác như API Gateway, S3,.. thì có thể tạo được một API server hay một hệ thống tự động xử lí khi có file upload lên S3. AWS Lambda hỗ trợ khá nhiều ngôn ngữ như Node.js, Java, C#, Python,…
• Google Cloud Function: hỗ trợ ngôn ngữ khá đa dạng (Nodejs, Go, Python, Java, PHP, .NET Core)
• Azure Functions: hàng của Microsoft, hỗ trợ C#, JavaScript, F#, Python, Batch, PHP, PowerShell

Còn nhiều nhà cung cấp khác như Kubeless, Fn,… tuy nhiên 3 ông ở trên có lẽ có thị phần lớn nhất và được quan tâm hơn. Ở dưới là chi tiết so sánh 1 số thông số giữa AWS Lambda, Google Cloud Function và Azure Function

Xây dựng hệ thống để trở thành nhà cung cấp serverless

Vì sự nổi trội về ưu điểm của serverless, nên hiện nay cũng đã có một số mã nguồn mở để xây dựng thành nền tảng cung cấp serverless

https://www.serverless.com/

OpenFaaS – Serverless Functions Made Simple

https://github.com/openfaas/faas

FireCracker – Secure and fast microVMs for serverless computing

https://github.com/firecracker-microvm/firecracker

Mình thì chỉ quan tâm tới việc xài thôi, nên không tìm hiểu được ở mảng này.

Fullstack Station Tips

Ngày nay khi mà các công cụ hỗ trợ lập trình viên tập trung vào việc xây dựng sản phẩm càng nhiều, thì rõ ràng chính lập trình viên chính là những người hưởng lợi nhất. Serverless là tương lai của những lập trình viên độc lập, khi không còn phụ thuộc vào phần cứng, máy chủ nữa.

Serverless giúp cho chúng ta không còn lo về chi phí duy trì máy chủ, không còn lo khi sản phẩm chưa có doanh thu đã phải trả tiền duy trì. Cho dù serverless là không hoàn hảo, nhưng với những ưu điểm nhiều hơn khuyết điểm và khả năng ứng dụng rộng lớn, serverless là một mảnh đất màu mỡ cho bạn phát triển.

Bạn không cần phải cân nhắc nhiều giữa các nền tảng, hãy chọn nền tảng nào bạn đã có kiến thức, hoặc được khuyến mại – giảm chi phí sử dụng. Các nhà hạ tầng luôn luôn phát triển, nên ngoại trừ về đặc điểm ngôn ngữ, các nhà cung cấp đều tương đương nhau. Hãy tập trung vào sản phẩm của mình là tốt rồi, khi có rào cản – tức là đã đạt giới hạn của sản phẩm – cũng có nghĩa là đã có thể có doanh thu, lợi nhuận thì lúc này mới nên tìm hiểu thêm để chuyển qua hệ thống cung cấp serverless khác là ổn nhất.

Quan điểm của Fullstack Station là đa năng, gọn nhẹ và không phụ thuộc, muốn trở thành lập trình viên độc lập thì càng nên học và ứng dụng serverless.

Tham khảo:

http://tech.vtijapan.co.jp/serverless-gioi-thieu-chung-chung/

https://serverless.com/learn/use-cases/

https://www.alibabacloud.com/blog/4-use-cases-of-serverless-architecture_593862

https://epsagon.com/the-best-5-use-cases-for-the-serverless-beginner/

The post Serverless là gì? Hãy sẵn sàng với serverless! appeared first on Fullstack Station.

Python đáng yêu như thế nào

So sánh một chút với Javascript

Một số kinh nghiệm

Cài đặt python

Python 2 đã ngưng phát triển và sẽ ngưng hỗ trợ từ 2020, chỉ còn 2 năm nữa thôi nên mọi thứ bây giờ bạn nên bắt đầu với Python 3, không cần phải suy nghĩ.

Nếu bạn dùng Window thì cứ vào trang chủ Python.org(https://www.python.org/downloads/windows/) tải về, nhưng với MacOS thì do đã được cài đặt Python 2 nên nếu bạn cài đặt từ Package Installer của Python sẽ phức tạp hơn 1 chút để chuyển sử dụng mặc định python 3. Mình từng sử dụng Package Installer và sau khi cài là không biết đã được cài python ở đâu

Mình đề nghị sử dụng homebrew để cài đặt, sẽ đơn giản hơn, hướng dẫn cài đặt ở đây.

Trước lúc cài đặt bằng homebrew thì mình cũng thử cài bằng Anaconda, nhưng thấy không thuận tiện bằng do máy đã có sẵn homebrew.

(Bài viết này mình dùng MacOS, nên nếu bạn dùng Window có thể sẽ có nhiều ý về thiết lập môi trường sẽ không đúng.)

Virtualenv

Chỉ với Python và PIP thì chúng ta cần cài đặt ở mức hệ thống, nhưng sau đó tất cả những gì bạn cần làm tiếp theo là phải dùng virtualenv (Môi trường ảo). Virtualenv rất quan trọng, nó ảnh hưởng hầu như các bước đi tiếp theo có trôi chảy hay không.

Bởi vì khi dùng PIP của hệ thống nó dính tới phân quyền, lúc nào cũng phải dùng sudo pip install XYZ thì sẽ phức tạp và có rủi ro bảo mật, bạn chỉ cài PIP không phải từ Virtualenv với những thứ liên quan trong hệ thống máy tính của mình.

Với Virtualenv thì bạn có thể hình dung như node_modules của Nodejs và vendor trong composer của PHP, mọi thư viện đều được cài đặt tách biệt với hệ thống và chỉ sử dụng trong nội bộ dự án.

Sử dụng

pip install virtualenv

Giả sử thư mục của dự án là /path/to/my_project/

virtualenv venv

# nếu máy bạn có cả python2, thì phải chỉ rõ đường dẫn đến python thông qua tham số `-p`

virtualenv venv -p `which python3`

Với venv là thư mục chứa python và các package. Xem giải thích về việc chọn thư mục venv ở phần VSCode

Sau khi có virtualenv, bạn cần kích hoạt:

source ./venv/bin/activate

Sau khi không dùng nữa thì dùng lệnh deactivate để thoát khỏi môi trường ảo. Thường mình không dùng lệnh này, cứ bật tab khác của Terminal thôi, vả lại mình không shutdown máy bao giờ :D, chỉ sleep rồi bật lên là xài tiếp nên không cần deactivate.

Text Editor/IDE

Mình có nghe giới thiệu tốt về Pycharm, nhưng không dùng vì phải trả phí, vả lại mình dùng VSCode đã lâu cho các dự án liên quan đến Javascript, Nodejs, PHP và bây giờ là Python đều thấy tốt (riêng đối với PHP thì khá tệ nếu so sánh với PHPStorm).

Sử dụng VSCode

Cài đặt extension Python

Mọi thứ cần thiết chỉ là cài đặt extension Python cho VSCode là xong, biến VSCode thành IDE cho Python thực thụ. Với những thiết lập mình đưa ra bên dưới, bạn sẽ chiến bất kỳ dự án nào mà ko sợ ảnh hưởng đến các dự án khác. Nói chung, cách đơn giản là thiết lập có giá trị cho từng dự án riêng biệt dựa trên VirtualEnv.

Thiết lập cài đặt cho dự án

Lý do mình dùng thư mục `venv` ngay trong thư mục của dự án, một phần là để phối hợp với VSCode tốt hơn, trong `Workspace Settings` của VSCode:

bạn thêm dòng

"python.pythonPath": "${workspaceRoot}/venv/bin/python"

Với ${workspaceRoot} là thư mục gốc của dự án.

Như vậy, kể từ lúc này, các package liên quan đến VSCode được sử dụng để hỗ trợ sẽ được cài đặt trong thư mực venv như pylintdùng để phân tích mã nguồn hay autopep8 hỗ trợ format code python tự động theo chuẩn pep8, hay để autocomplete, code definition, navigation các thư viện được sử dụng trong dự án rất dễ dàng.

 

Cách này có thêm điểm lợi là cấu hình đi theo dự án, không phụ thuộc vào cài đặt python của máy, dù mình có cài máy lại, hay code trên nhiều máy thì cấu hình không thay đổi.

Trong trường hợp sử dụng ở máy cá nhân hay ở máy chủ, thì vì môi trường “venv” là đường dẫn tương đối, nên nếu 2 dự án khác nhau nhưng chung python 3.6 chẳng hạn, thì python được sử dụng chung nhưng `site-packages` thì độc lập.

Ví dụ:

# tại /path/to/projectA
source venv/bin/active
pip install packageA

# chuyển thư mục qua dự án B
cd /path/to/projectB

# trở thành (venv)/path/to/projectB
# chú ý là không cần deactive môi trường vẫn có thể cài đặt package cho projectB được.
pip install packageB

=> 2 package A và B được cài đặt cho 2 dự án hoàn toàn độc lập.

Cấu hình pylint

Trong thư mục gốc của dự án tạo file: .pylintrc

[MASTER]
load-plugins=pylint_common, pylint_django

[FORMAT]
max-line-length=120

[MESSAGES CONTROL]
disable=missing-docstring,invalid-name

[DESIGN]
max-parents=13

Trong file trên, mình có sử dụng  pylint_django, là do mình dùng Django, nếu bạn dùng Flask thì cài và thay bằng pylint_flask chẳng hạn, tuỳ theo framework bạn dùng để cài plugin tương ứng. Mặc định thì pep8 quy định 1 dòng 80 ký tự, mình thấy mức này khá ngắn cho một file bình thường, với mình thì để ở mức 120 thì thoải mái hơn.

Tài liệu, thực hành

Nếu bạn đã có kiến thức ở ngôn ngữ khác rồi, thì nên sử dụng tài liệu LearnXinYminutes, có cách nhìn tổng quan về Python3 một cách nhanh nhất.

Nếu bạn cũng từng làm về PHP thì có thể đọc cuốn “Python rất là cơ bản” của bạn Võ Duy Tuấn – người có kinh nghiệm 10 năm lập trình PHP chuyển sang Python. Cuốn này thì bạn chỉ cần đọc từ chương 1 đến chương 5 là đủ, các chương khác tuỳ theo nhu cầu bạn có thể đọc sau.

Thực hành thì mình dùng LeetCode (http://leetcode.com/) hoặc HackerRank(http://hackerrank.com), vì để giải quyết các vấn đề ở LeetCode, HackerRank chúng ta cần các kiến thức cơ bản của python (ví dụ xử lý số, chuỗi hay xử lý mảng), cũng như cấu trúc dữ liệu khiến cho kiến thức python sâu hơn.

Khi làm dự án về Django thì giúp mình có kiến thức về class trong python, cách thừa kế, khai báo hàm static, method, …Vì vậy, nếu bạn có kiến thức về web rồi thì cũng nên chọn Django để bắt đầu để tận dụng kiến thức web của bạn.

Python Shell: cứ gõ python trong command line rồi bắt đầu quậy thôi. Mình lúc nào cũng bật thêm cửa sổ này để tìm hiểu 1 số lệnh cơ bản, khi chưa dùng VSCode với cấu hình ở trên thì bạn có thể dùng lệnh dir ví dụ dir(className) để liệt kê các phương thức của class đó, hoặc help ví dụ import os rồi help(os) sẽ biết được module os bao gồm những gì. Với VSCode thì chỉ cần Ctrl+Click hoặc Alt+Click là sẽ đến tập tin khai báo module os, thì bạn sẽ đọc được tài liệu về module này.

Bạn có thể sử dụng thêm MyPy để tăng hiệu quả của code, xem thêm tại Mypy 

Fullstack Station Tips

Dù thích python trước đây nhưng mình cũng từng ghét python chỉ vì có khi bị lỗi khi cài đặt qua pip mà không hiểu nguyên nhân. Kinh nghiệm mình đúc kết được ở đây cũng tốn kha khá thời gian tìm hiểu lúc mới bắt đầu lập trình Python, hi vọng sẽ có ích cho các bạn mới bắt đầu lập trình python khác. Python khá dễ học, kết hợp thêm những kinh nghiệm này sẽ khiến cho quá trình học trở nên trôi chảy hơn.

The post Kinh nghiệm dành cho người mới bắt đầu lập trình Python appeared first on Fullstack Station.

Vấn đề

Mình tiếp quản một số máy chủ test/development chứa gần 20 repo cho mỗi máy chủ, với thiết lập tự động (cronjob) fetch & pull mỗi phút một lần, điều này tạo áp lực không nhỏ cho server khiến nó gần như bị tê liệt mỗi lần chạy.
Nhất là khi gặp trường hợp xung đột/conflict (vì có thể ai đó upload file thông qua FTP *_*), phải chạy `git reset` thì thôi đơ luôn. Nhiệm vụ được giao là tìm kiếm cách thức nào đó để hạn chế vấn đề này, và mình đã tìm hiểu 2 công cụ:

• https://github.com/logsol/Github-Auto-Deploy
• https://github.com/olipo186/Git-Auto-Deploy

Mình chọn cái đầu tiên Github-Auto-Deploy để áp dụng và sau một thời gian dài hoạt động trơn tru mình khá hài lòng vì mức độ đơn giản, tiện dụng, cứ mỗi lần `git push`, thì máy chủ sẽ tự động fetch code mới về và thực hiện một số lệnh deploy tùy theo dự án, ví dụ với Nodejs thì chạy `yarn install` với PHP thì `composer install`, cần thiết thì thêm hook gởi thông tin qua Slack chẳng hạn, hoặc gởi vào hệ thống Huginn để thực hiện thêm các chức năng liên kết hệ thống phức tạp khác (email, sms…n web hooks khác).

Cái thứ 2 là Git-Auto-Deploy kia thì nhiều chức năng hơn, vì vậy mà code nó cũng phức tạp hơn thiết nghĩ ko cần thiết. Hoặc giả sử cần nâng cấp hay tối ưu (ví dụ Basic Auth, Secret Key, Limit IP,..) cái công cụ này cũng khó khăn hơn cái của logsol.

Thời gian chuột bạch thử nghiệm đã hơn 1 năm thành công, hi vọng cũng sẽ giúp ích cho các bạn, bắt đầu thôi!

Thiết lập hệ thống tự động pull/deploy git

Cài đặt SSH để connect Git

Ở bước này, bạn xem ở đây https://help.github.com/articles/connecting-to-github-with-ssh, bước này khá đơn giản, chỉ cần tạo SSH key của server và thêm vào Github là xong, mục đích là không cần phải gõ mật khẩu để pull repo private – phù hợp cho chương trình tự động.

Clone repo bạn muốn tự động deploy

Đơn giản là clone vô cái thư mục chứa code trên server của bạn.

cd /path/to/directory
git clone git://github/your_name/your_repo.git

Cài đặt Github-Auto-Deploy

cd /path/to/directory
git clone git@github.com:logsol/Github-Auto-Deploy.git
cd Github-Auto-Deploy

Sau khi vào thư mục bạn sẽ thấy file `GitAutoDeploy.conf.json.example`, copy nó ra và chỉnh sửa

cp  GitAutoDeploy.conf.json.example  GitAutoDeploy.conf.json

{
 "port": 8001,
 "repositories":
 [
     {
        "url": "https://github.com/{NAME}/{REPOSITORY_NAME}",
	"path": "/path/to/directory/{DIRECTORY}",
	"deploy": "git pull origin master && echo deployed {REPOSITORY_NAME_OR_WHATEVER}"		
     }
 ]
}

port: port thì nên set cao hơn 1024, dưới 1024 thì phải đòi hỏi có quyền root

url: đường dẫn tới repo có thể dùng git hoặc https

path: đường dẫn tới thư mục đã được cài đặt phía trên

deploy: deploy này thì cơ bản chỉ cần `git pull origin master` – điều chỉnh theo remote/branch tương ứng trường hợp của bạn. Cái lệnh `echo deploy successful` không quan trọng đơn giản là báo hiệu việc pull đã thành công.

Bạn có thể thiết lập bao nhiêu repo cũng được, theo format json như trên là ok.

Chạy hệ thống tự động pull/deploy

cd /path/to/directory/Github-Auto-Deploy
nohup python -u GitAutoDeploy.py  --daemon-mode --quiet &
tail -f nohup.out  # kiểm tra log

Mở đường dẫn http://SERVER_NAME_OR_IP:8001 để kiểm tra server đã hoạt động, nếu bạn thấy hình sau  nghĩa là server đã hoạt động ok. Hệ thống chỉ hỗ trợ phương thức POST, nên khi truy cập bằng GET sẽ bị ăn lỗi :D.

Thiết lập webhook

Phần này thì cũng đơn giản thôi, vào tài khoản Github, vô Repo mà bạn muốn thiết lập -> Settings -> Webhook -> Add webhook

Đường dẫn sẽ là: https://github.com/your_name/your_repo_name/settings/hooks, nó ra màn hình:

Payload URL thì để tên/ip server của bạn và nhớ thêm port, ví dụ: `http://123.456.789.111:8001`

Content Type : chọn `application/json`, mấy thứ khác để nguyên.

Nếu sau khi tạo xong mà có dấu check màu xanh lá cây vậy là server hoạt động ok rồi.

Nâng cao/ Tùy chọn

Cho phép tự khởi động khi server restart

crontab -e

Thêm nội dung như sau

@reboot cd /path/to/directory/Github-Auto-Deploy/ && nohup /usr/bin/python -u GitAutoDeploy.py --daemon-mode --quiet &

Ở đây mình sử dụng lệnh nohup, để không bị tắt chương trình Github-Auto-Deploy khi kết thúc phiên làm việc ssh với server, cũng như lưu lại tất cả các log từ stdout của chương trình.

Xử lý khi pull thành công hay thất bại

Xem lại ở phần config:

“deploy”: “git pull origin master && echo deployed {REPOSITORY_NAME_OR_WHATEVER}”

Ở câu lệnh deploy, thì chỉ đơn giản là echo, mình sẽ tối ưu thêm 1 chút để có thể gởi thông báo pull thành công hay thất bại. Tạo thêm 2 script chứa lệnh curl đơn giản đến api nào đó của Chatwork hay Slack, cái này cũng đơn giản thôi.

# notify_success.sh 
curl -X POST -H "X-ChatWorkToken: e12321ef233d8a92deb1cc15bc09b79e" \
    -d "body=Success&self_unread=0" \
    "https://api.chatwork.com/v2/rooms/11111178/messages"

và

# notify_failed.sh
curl -X POST -H "X-ChatWorkToken: e12321ef233d8a92deb1cc15bc09b79e" \
    -d "body=Failed&self_unread=0" \
    "https://api.chatwork.com/v2/rooms/11111178/messages"

Lúc đó lệnh deploy sẽ đổi thành:

“deploy”: “git pull origin master &&/path/to/notify_success.sh || /path/to/notify_failed.sh“

Tùy theo repository mà sửa nội dung phù hợp, là push notification ngon lành thôi.

Kiểm tra

Đến đây thì phần cài đặt đã xong, bạn hãy thử commit & push và kiểm tra xem repo ở server có được cập nhật không. Kiểm tra log ở file /path/to/directory/nohup.out

Fullstack Station Tips

• Thay vì ở cấu hình mỗi repo ở file cấu hình `GitAutoDeploy.conf.json`, mục deploy, bạn dùng lệnh trực tiếp, thì có thể gọi tập lệnh từ file khác ví dụ: /path/to/directory/script.sh, thì file config sẽ đơn giản và dễ nhìn hơn. Nhất là đối với các repo phức tạp đòi hỏi thêm việc chạy migration database, cài đặt package và restart dịch vụ gì đó.
• Nên chạy với quyền user bình thường, vì có thể bạn sẽ cần cài đặt thêm các package từ yarn hoặc composer, pip

Mình biết rằng có không nhiều bạn sử dụng Continuous Integration (CI) cho việc lập trình các dự án đơn giản, hoặc chỉ là dự án cá nhân. Đây là chương trình tự động pull/deploy đơn giản mà hiệu quả, hi vọng sẽ giúp ích nhiều cho các bạn.

The post Hướng dẫn sử dụng hệ thống tự động Pull/Deploy Git Code appeared first on Fullstack Station.

Những ngôn ngữ dưới đây được xem là dễ kiếm việc nhất, nhưng có thể không phải là ngôn ngữ lập trình được trả lương cao nhất. Và quan trọng hơn hết là mấy ngôn ngữ này thông dụng, gần gũi với chúng ta hơn với cộng đồng đông đảo.

PHP 7

Một năm 2016 bận rộn của cộng đồng PHP sau khi PHP 7 chính thức phát hành. Các framework khẩn trương chỉnh sửa để có thể chạy được trên môi trường PHP 7 một cách hoàn thiện, hầu hết các php framework hiện nay đã chạy ổn định trên PHP 7, ngay cả những extension đặc biệt cho Mongodb. Vì vậy, đừng ngần ngại cài đặt PHP 7 lên máy chủ của bạn để cảm nhận sự khác biệt, cũng như viết những dòng mã của bạn với tính năng của PHP 7 mang lại.

Năm 2017 sẽ không có gì đặc biệt cho cộng đồng lập trình viên PHP, khi hầu hết các framework đã hỗ trợ PHP 7 rồi (Laravel 5, Yii 2, Symfony 3, CakePHP 3, WordPress 4). Điều quan trọng còn lại là bạn có tham gia vào xu hướng này hay không?

Swift 4

Sau khi Swift 3 phát hành (09/2016) chưa nguội thì Apple đã rục rịch chuẩn bị kết hoạch cho phiên bản Swift 4, dự kiến là cuối năm nay 2017. Khi mà giờ đây Swift có thể viết được mã chạy ở phía server (Tham khảo Perfect), thì cộng đồng lập trình viên sử dụng Swift có thể tự do sáng tạo và khởi nghiệp chỉ bằng ngôn ngữ Swift.

Javascript/Typescript

Javascript ES2015  rõ ràng là sự thách thức với Typescript, mặc dù điểm cuối đều là javascript, nhưng đã được tách biệt thành hai hướng đi cho dù có sự tương đồng nhất định về cú pháp, cách viết. Typescript là sự cải thiện cho javascript tương tự như cách PHP 7 cải thiện PHP ở việc kiểm tra cú pháp, loại dữ liệu. Với Javascript thuần ta có thể sử dụng Flowtype

Go/Golang

Kể từ lúc mình dùng Go để viết bot lấy dữ liệu (crawler, scrapper) thì thực sự rất kết ngôn ngữ lập trình có tốc độ cao này. Hơn nữa, còn có thể kết hợp với ReactReact để tạo ra Universal Web App nữa (Go starter kit).

Go là ngôn ngữ mới có tuổi đời 7 năm, nên vẫn còn trong giai đoạn hoàn thiện (hiện tại đang 1.7), chính vì vậy mục tiêu trong năm 2017 này là hoàn thiện một số tính năng đưa lên phiên bản 1.8, 1.9. Có lẽ phiên bản 2.0 sẽ cần 1 sự đột phá hơn do vậy phải chờ qua 2018.

Một số ngôn ngữ lập trình khác

Java, Rust, Ruby, Hack, Rust, Julia, Scala, Dart… quá chừng luôn, mỗi ngôn ngữ đều có độ trùm nhất định trong một số lĩnh vực, tuy nhiên vì không có kiến thức liên quan cũng như nhận thấy xu hướng không thực sự cao nên mình không quan tâm.

Frontend Framework

Đây có lẽ là cuộc chiến khốc liệt nhất trong những năm vừa qua, vì vậy mình tách riêng rành phần riêng. Mặc dù có thể gọi là nấm mọc sau mưa nhưng hiện tại có thể gọi tên 3 framework thực sự cạnh tranh với nhau là AngularJS[2], ReactJS và VueJS.

Điểm cơ bản là đều có sao cao ở Github, mặc dù repo Angular chỉ đạt 21k so với 45k của Vue, 61k của React tại thời điểm viết bài, tuy nhiên không thể nói Angular thua về mức độ được sử dụng và phổ biến (dự án thực tế, bài viết).

Chỉ có thể khẳng định một điều, cho dù bạn chọn hướng đi nào thì bạn vẫn không hề tụt hậu trong vòng 2-3 năm tới.

Mobile Javascript Framework

Ionic đã ra mắt bản 2 từ 01/2017, sử dụng Angular 2.

React Native vẫn sẽ tiếp tục thống trị ở phân khúc Mobile Javascript Framework.

Xu hướng mới với Javascript

Virtual Reality (VR)

Thực tế ảo https://github.com/facebookincubator/react-vr

Augmented Reality (AR)

Tương tác thực tế với tốc độ 60fps

https://github.com/jeromeetienne/AR.js

Progressive Web Apps (PWA)

Kết

The post Xu hướng lập trình: Chờ đợi gì trong năm 2017? appeared first on Fullstack Station.