Browse by Category or Tag


Fintech là gì?

Fintech là gì ?

Fintech = Finance + Technology

Cùng với sự tiến bộ của internet và kĩ thuật, các hệ thống ngân hàng, tiền tệ cũng xảy ra những sự thay đổi lớn.

Fintech không bắt nguồn từ những hệ thống tiền tệ hiện có. Fintech đánh dấu sự xâm lấn của IT vào những hệ thống tiền tệ đó.

Fintech là xu thế tất yếu và các hệ thống tiền tệ hiểu điều đó, ở đây không phải sự thù địch mà là sự hợp tác giữa cái mới và cái cũ.

Comment  Read more

Cài đặt môi trường Python

Cấu hình

  • Mac osx Sierra 10.12.3

Có nhiều cách để cấu hình môi trường Python. Lúc đầu mình định để tất cả trong docker, nhưng vì còn dùng camera, GPU, … nên việc config docker sẽ mất thời gian. Vì thế mà môi trường python sẽ được dùng trực tiếp trên local.

Mình sẽ dùng brew, pyenvconda để cấu hình môi trường.

Comment  Read more

GitFlow trong thực tế

Tiền đề

  • Dựa trên mô hình của GitHub Flow. Về mô hình GitHub Flow, có thể xem bản hướng dẫn gốc của GitHub ở đây .
  • Dựa vào yêu cầu của mỗi dự án, skill của các members trong dự án mà mô hình này có thể được sửa lại cho phù hợp với từng dự án.
    • Ví dụ các dự án quá cũ, có cách vận hành gitflow khác thì không cần phải chuyển qua mô hình này.
  • Không có 1 mô hình tuyệt đối chính xác hay đúng đắn. Tất cả chỉ là tương đối.

Nội dung bài viết này dựa vào kiến thức cá nhân và tổng hợp từ các nguồn public, nên bản quyền thuộc về tác giả.

Dự án trong giai đoạn develop

Vai trò của các branch

  • master
    • Luôn ở trạng thái có thể deploy.
    • Không bị fail auto test (nếu dự án có yêu cầu dùng auto test)
      • nếu có vấn đề gì thì phải ưu tiên fix đầu tiên
    • Không được commit/push trực tiếp vào branch này. Branch master phải được bảo vệ bằng chức năng protected branchs của GitHub.
  • feature-XXX
    • tách ra từ branch master
    • XXXlà id của backlog ( hoặc redmine, github issue, … tuỳ theo dự án)
    • Dù chỉ có 1 commit cũng phải tạo pull request. Các pull request khi tạo phải có tiền tố [WIP] ở trước. Sau khi được hoàn thiện và sẵn sàng review thì bỏ tiền tố này đi. Các pull request phải hướng về master.
  • feature-XXX-YYY
    • Được tách ra từ branch feature-XXX
    • YYY là tên người làm.
    • Chỉ dùng trong trường hợp có nhiều hơn 1 người cùng dev 1 chức năng.
    • Dù chỉ có 1 commit cũng phải tạo pull request. Các pull request khi tạo phải có tiền tố [WIP] ở trước. Sau khi được được hoàn thành và sẵn sàng review thì bỏ tiền tố này đi. Các pull request phải hướng về feature-XXX.

github-flow

Review

  • Khi tạo 1 branch mới và có commit mới thì bắt buộc phải tạo pull request và thêm prefix [WIP].
  • Tất cả các pull request phải được review.
    • Sau khi hoàn thiện xong chức năng và sẵn sàng review thì bỏ [WIP]đi và assign lại cho leader.
  • Sử dụng các công cụ chatwork/slack để yêu cầu được review.
  • Sau khi review xong thì leader merge vào và xoá branch đó đi.
    • Nếu có yêu cầu phải sửa thì comment vào và assign ngược lại cho member.
    • Leader sau khi review xong cần phải comment lại để cho members được biết. Ví dụ như LGTM, :+1:, …

Deploy

  • Nếu có thay đổi trong master thì tự động deploy.
    • Quản lý bằng Jenkins / CircleCI
    • Bên web/server : sử dụng các tools deploy tự động như capistrano để tiết kiệm thời gian và giảm rủi ro.
    • Về app thì sử dụng các tools như deploygate, testflight để deploy.

Có nhiều dự án sử dụng chức năng tự động deploy của CircleCI rất hiệu quả. Cách làm này tiết kiệm thời gian và cải thiện workflow trong team.

Deploy lên production

  • Sử dụng branch release chuyên để deploy lên production.
  • Khi deploy lên prd, tạo pull request từ branch master vào branch release. Branch release phải được bảo vệ bằng chức năng protected branchs của GitHub.
  • Xác nhận sự thay đổi, nếu không có vấn đề gì thì merge vào release.
  • Sau khi merge xong thì deploy lên server prd. Khuyến khích dùng deploy tự động.

release-branch.png

Fix lỗi khẩn cấp

Các lỗi khẩn cấp này không muốn gặp nhưng đôi lúc vẫn xuất hiện. Lý do vì môi trường production thường khác môi trường staging. Prd thường có ELB, S3, biến môi trường khác biệt, …

Các lỗi này cần phải fix ngay lập tức, thường thì không có thời gian để trải qua đủ các quy trình deploy.

  • hotfix-XXX
    • Tách ra từ branch release
    • XXXlà ID của backlog hoặc redmine, …
    • Sau khi làm xong thì gửi pull request vào release, merge và deploy lên.
    • Gửi pull request vào master và merge.

hotfix-branch.png

Mô hình git cho phase 2nd

Phần này mình sẽ giải thích về mô hình git của dự án sau khi đã release phase 1st. Mỗi dự án thường chia thành nhiều phase. Mỗi phase có những tính năng độc lập với nhau. Vì sự độc lập này mà mô hình git cũng có ít nhiều thay đổi cho phù hợp.

Vai trò của các branch

  • master
    • Là version mới nhất cho phase 2nd
    • Ngoài ra tất cả đều giống như phần trên.
  • release
    • Tại thời điểm kết thúc phase 1st thì được tạo branch release từ branch master
      • Sau khi kết thúc phase 2nd thì merge vào master
  • feature-XXX (branch thực hiện các chức năng của phase 2nd)
    • Tách ra từ branch master
    • Ngoài ra tất cả đều giống như phần trên.
  • bug-fix-XXX (branch fix bugs cho phase 1st)
    • Tách ra từ branch release
    • XXXlà ID của backlog, redmine, …

2nd-develop.png

Comment  Read more

Sử dụng apipie để viết document cho rails

[apipie] GitHub - Apipie/apipie-rails: Ruby on Rails API documentation tool

apipie là gem hỗ trợ viết document cho RESTful API. Các ưu điểm của gem này là :

  1. Viết document mà như code bằng Ruby =)). Đỡ tốn công học thêm các syntax khác.
  2. Reusing rất dễ dàng.
  3. Việc quản lý document cũng khá đơn giản. Có thể gộp chung cùng source code để quản lý bằng git.

Việc dùng gem này như thế nào bạn có thể tham khảo github của gem. Mình ở đây chỉ nói về các tricks khi dùng apipie.

Cấu trúc folders

Trong hướng dẫn trên github, document được viết luôn trong controller. Nhưng mình thấy như thế rất tệ. Lý do vì :

  1. controller phình to ra, khó quản lý, rối mắt.
  2. Khi review thì document và code không tách bạch nhau ra. Gây khó khăn cho review.

Cách giải quyết của mình là sử dụng include. Ví dụ :

# app/controllers/api/v1/lists_controller.rb
module Api::V1
  class ListsController < ApiController
    include ListsDoc
    ...
    end
end

Mình thường đặt toàn bộ document trong thư mục app/docs. Như vậy ListsDoc sẽ được định nghĩa trong file app/docs/lists_doc.rb.

# app/docs/lists_doc.rb
module ListsDoc
  extend Apipie::DSL::Concern

  api :GET, '/lists/:id', '(Done) Get lists'
  param :id, :number, required: true
  param :page, :number
  param :limit, :number
  error :code => 401, :desc => "Unauthorized"
  error :code => 404, :desc => "Not Found"
  def show
  end
    
end

Như vậy controller chỉ thêm vào 1 dòng duy nhất. Tất cả các thay đổi document đều được thực hiện trong thư mục app/docs.

Tất cả các file trong thư mục app được được Rails autoload.

Show db schema

Việc thay đổi DB trong quá trình làm dự án là điều khó tránh khỏi. Mỗi lần như thế lại phải update lại ER diagram, mà các file diagram này thường được share qua Google Driver hay Dropbox, giờ muốn đọc document và xem ER thì cũng phiền phức :D.

Trong rails có file db/schema.rb để define các table. File này được cập nhật mỗi khi chạy migration, vì thế nó luôn đảm bảo là DB mới nhất.

Giờ ta sẽ đọc file này và show lên document :

module DbDoc
  extend Apipie::DSL::Concern
  api :GET, '/db/', 'DB schema.'
  description "DB schema."
  example <<-EXAMPLE
  #{File.read('db/schema.rb') if File.exist?('db/schema.rb')}
  EXAMPLE
  def db_schema
  end
end

Tạo resource là common

Mình thường tạo thêm 1 resourcecommon để cho các document khác vào đây. Ví dụ như :

  • Authentication
  • DB schema

Phải sửa document và cho vào PR

1 quy ước nhỏ để đảm bảo document luôn được làm cẩn thận và cập nhật. Mình có thêm 1 label need document, sau khi review và code đã sẵn sàng merge, mình sẽ dùng label này để các bạn update document mới nhất lên.

1 số vấn đề của apipie

Sau 1 thời gian dùng apipie, mình thấy có 1 số vấn đề sau :

  1. Không order được các resources. Các resources luôn được sắp xếp theo thứ tự ABC.
  2. Không order được các element. Phần params lẽ ra phải đặt trước phần example, nhưng vì bắt đầu là p nên luôn bị xếp dưới cùng.
  3. Không có chức năng mock server.
Comment  Read more

Vài điều về API documents

Viết document cho API luôn là phần bị “phân biệt đối xử” theo kiểu : “để cuối cùng làm” hay “làm cho có”.

Vấn đề này xuất phát từ 1 vài lý do sau :

  1. Tâm lý thích code hơn thích viết document.
  2. Phần document thường không được estimate trong hợp đồng, nên dành thời gian để viết document là “tốn công vô ích”.
  3. Giữa thiết kế và thực hiện luôn có sự khác biệt. Mỗi 1 thay đổi như thế cần phải cập nhật lại document, nên gây tâm lý “để cuối cùng làm”.

Tuy nhiên cần phải khẳng định rằng document là bộ mặt của 1 project. Thử tưởng tượng có ai thả bạn giữa Hà Nội mà không có bản đồ xem :D.

Về cách tiếp cận document, mình chia thành 2 loại :

  1. Document có trước, code sau.
  2. Vừa code vừa viết document.
Comment  Read more