Các bài viết ngắn – phần 6

Viết commit message, dễ mà khó A commit message shows whether a developer is a good collaborator Một commit message thể hiện người lập trình viên có phải là một người cộng tác tốt hay không Trong cùng một dự án thì commit message nên thống nhất với nhau về: – Style: như nội dung

Viết commit message, dễ mà khó

A commit message shows whether a developer is a good collaborator

Một commit message thể hiện người lập trình viên có phải là một người cộng tác tốt hay không

Trong cùng một dự án thì commit message nên thống nhất với nhau về:

– Style: như nội dung bằng tiếng Anh, viết hoa chữ cái đầu tiên, …

– Content: nội dung của message

– Metadata: ticket id, pull request id, …

Luôn luôn “Keep it simple” khi viết một commit message.

Có 7 nguyên tắc giúp bạn viết một commit message tốt hơn:

– Tiêu đề(subject) cách với nội dung một dòng trống

– Tiêu đề tối đa 50 ký tự

– Viết hoa chữ đầu tiên của tiêu đề

– Không viết dấu . cuối tiêu đề

– Sử dụng câu mệnh lệnh khi viết tiêu đề(bắt đầu bằng động từ) Create, Do, Clean, Refactor, Fix, …

– Body nên tối đa 72 ký tự

– Body nên giải thích cho why and how

Mời bạn đọc thêm chi tiết và ví dụ ở bài này.

Viết README thế nào cho chuẩn

README là tập tin đầu tiên được đọc trong dự án phần mềm, chứa các nội dung quan trọng nhất của dự án như mục đích của dự án, các tính năng tính, các công nghệ được áp dụng, …

Để viết một file README cho chuẩn, gợi ý đến bạn 7 vấn đề mà bạn nên quan tâm:

  1. Viết một đoạn ngắn giới thiệu và mục đích của dự án

  2. Sắp xếp các nội dung sao cho dễ truy cập (mục lục, phân nội dung theo từng phần, link liên kết, …)

  3. Thông tin chung của dự án bổ sung thêm thông tin sau đoạn ngắn giới thiệu ở trên (dự án giải quyết vấn đề gì, dùng kỹ thuật gì: framework, database, …)

  4. Hướng dẫn người dùng chạy dự án lên (các phần mềm tiên quyết, cách tải và chạy dự án)

  5. Hướng dẫn cách kiểm thử (run tests) nếu có

  6. Mô tả về các bugs, vấn đề của dự án đã biết (know issues)

  7. Cung cấp các môi trường đã deploy để người dùng trải nghiệm (staging, prod environment)

  8. Thường xuyên update README để cập nhật thông tin mới nhất

  9. Cuối cùng, một điểm mình hay thấy là “Nhớ đóng vai người dùng để chạy dự án theo cách bạn đã hướng dẫn, và đảm bảo những gì bạn hướng dẫn là chính xác”.

(Ref)

Chân Lê – Techie Story

Nếu học cách quan sát và lắng nghe, chắc chắn sẽ đi nhanh hơn từ những câu chuyện của những người đi trước, hay đơn giản là không bị mắc kẹt vào mớ kiến thức hạn hẹp của bản thân mình.

Câu chuyện của anh Chân Lê – Engineer Manager tại Truera (Ex Snapchat, Meta & Asana) đã làm mình hiểu thêm những điều thú vị anh đã trải qua, qua đó mình học thêm:

– Hàn Quốc là nơi tốt để phát triển học thuật nhưng có vẻ sẽ kìm hãm sự phát triển cho những người thích tự do.

– Nếu cần thì phải lên tiếng, chưa hỏi sao biết là không được.

– Cuộc đời đâu phải đơn giản như Google Map, nhập điểm đầu điểm cuối là tới đích đâu. Mà ngay cả Google cũng có nhiều con đường để đến cùng một đích, không đi đường thẳng thì đi đường vòng, không sao cả, huống chi là cuộc đời mình.

– Không cần thiết phải gắn chặt bản thân mình vào cái gì cả, khi mà mình luôn thay đổi mỗi ngày mà cuộc sống mình cũng vậy.

– Take it easy.

(Bài viết chi tiết ở đây)

Dev self-learning

Tất cả lập trình viên đều cần có khả năng “tự học” ngay từ ngày đầu tiên bạn bước vào nghề này. Trong suốt quá quá trình làm việc, bạn sẽ cải thiện dần khả năng tự học của mình sao cho có hiệu quả nhất

Một vài kỹ thuật / mẹo giúp bạn tự học lập trình hiệu quả:

– Học mỗi ngày với kế hoạch được vạch ra sẵn. Bạn có thể sử dụng reminder của lịch để nhắc bản thân.

– Nghỉ ngơi hợp lý. Thường xuyên nghỉ giữa các khung giờ làm việc để nạp lại năng lượng, đó có thể là 15-20 phút sau khi làm việc 2-3 giờ, và nhất là khi bạn đang bí với một con bug, nghỉ ngơi là cách tốt nhất để não có thể tự tìm cách giúp bạn.

– Chuyển đổi giữa các chủ đề khác nhau. Vì học hoài 1 chủ đề kéo dài sẽ dẫn đến chán, chuyển đổi chủ đề giúp giảm sự nhàm chán này lại, nhưng đừng chuyển nhiều chủ đề quá.

– Kiên định với mục tiêu những không quá cứng nhắc. Bạn không nhất thiết phải học từ a-z một khoá học, mà có thể xem trước nội dung toàn khoá, rồi chọn những phần thích để học trước, … Tuy nhiên đừng nên học quá nhiều khoá một lúc.

– Tìm niềm vui. Học điều mới thì luôn không dễ dàng, bạn có thể bị bí bất cứ khi nào. Để giữ lửa vượt qua những lúc khó khăn như vậy, bạn hãy nghỉ ngơi thường xuyên, giải trí bằng một bản nhạc yêu thích, … rồi sau đó có thể tiếp tục.

– Ôn lại kiến thức đã học để có thể nhớ và hiểu sâu hơn. Dành ra vài chục phút để ôn tập hay hướng dẫn người khác cũng là một cách rất hay để có thể ôn lại kiến thức.

– Xem xét quá trình học của bản thân và điều chỉnh cho phù hợp.

– Ghi chép bằng tay những điều quan trọng có thể giúp bạn nhớ sâu hơn.

– Hiểu vấn đề, lý thuyết đằng sau thay vì nhớ ví dụ hay code sẽ giúp bạn dễ dàng tìm được những kiến thức chung được áp dụng cho nhiều loại ngôn ngữ như design patterns hay các concepts cơ bản.

(Mời bạn đọc thêm ở đây)

Git commands should know

Git sẽ đi cùng bạn suốt thời gian làm dev, vì cứ hễ code là phải commit lên repository của github, gitlab cá nhân hay của dự án, công ty.

Làm chủ Git CLI với 30 câu lệnh mà lập trình viên nên biết với bài viết ở link.

Mình sẽ tóm tắt một số câu lệnh hay sử dụng và quan trọng theo cách mình nhìn nhé.

– Setup usernane và email với “git config”. Câu lệnh này quan trọng khi bạn có nhiều repository khác nhau cần commit với tên và email khác nhau, ví dụ như repo cá nhân và công ty, dự án.

– Clone một dự án về với “git clone”, chuyển branch với “git checkout <tên branch>”

– Tạo branch mới với “git branch”, tạo mới và checkout qua luôn với “git checkout -b <tên branch>”

– Xem các branch với “git branch”, xem cả cho remote thì thêm option “-a”

– Kiểm tra code changes với “git status”

– Thêm file thay đổi lên staged với “git add”

– Commit một dòng với “git commit -m <message>”

– View commit history với “git log”, thêm option -3 sẽ xem 3 commits gần nhất, thêm -p sẽ xem thay đổi trên commit. Xem log đẹp dạng graph thì sử dụng “git log –graph –oneline –decorator”

– Xem một commit với “git show <id>”, với id có thể là 6 số đầu của một commit id

– Bỏ thay đổi của file chưa lên staged với “git checkout”, nếu lên staged rồi thì dùng “git reset”

– Rollback commit gần nhất với “git revert”

– Xoá branch đã merge với “git branch -d”, nếu có lỗi tức là branch này chưa được merge vào main branch, lúc nãy vẫn muốn xoá cần dùng option “-D”

– Xoá branch ở remote với “git push origin –delete <branch-name>”

– Merge hai branch với “git merge”, nếu cần commit merge thì thêm option “–no-ff”

Hook Pattern

Hook pattern giúp sử dụng function để tái sử dụng các trạng thái(state) xuyên suốt nhiều components trong app.

React 16.8 giới thiệu Hooks, một cách mới vẫn có thể sử dụng state và lifecycle methods mà không cần dùng cú pháp class của ES2015.

Vì sao lại thay thế class component?

Để hiểu vì sao thì cần phải hiểu về class component. Trước đây, có hai cách để tạo một component là sử dụng function (stateless component) và class (stateful component). Class sẽ sử dụng nếu component cần làm việc với các trạng thái (state).

Việc này dẫn tới một vấn đề về code sẽ thay đổi nhiều lên rất nhiều khi một function component muốn chuyển sang class component vì syntax khác nhau. Class component cần có constructor để khởi tạo state, hàm render, các hàm khác, …

Thêm vào đó, việc chia sẻ state qua nhiều component có thể sử dụng HOC hay Render Props pattern, và khi có nhiều component lồng vào nhau sẽ sinh ra vấn đề component wrapper hell (có thể hiểu tương tự callback hell)

Ngoài ra, việc kiểm soát một component ở lifecycle methods như componentDidMount, … sẽ càng làm cho code base của một component gia tăng, và lặp lại ở nhiều component.

Hooks ra đời giúp giải quyết các vấn đề trên như thế nào?

– Hooks cho phép quản lý state trong một function component, nên không cần đổi code base nhiều khi sử dụng state nữa.

– Hooks cho phép quản lý component lifecycles mà không cần viết các hàm như componentDidMount, … như trước

– Hook cho phép tái sử dụng state xuyên suốt app

Mời bạn đọc thêm ở bài này nhé, thú vị lắm ấy!

Bạn chia sẻ file qua internet như thế nào?

Có thể bạn gửi qua email(với giới hạn 25MB), trực tiếp qua slack(cả workspace có dung lượng tói đa 5GB), messenger(giới hạn 25MB), hoặc tải lên drive rồi gửi link chia sẻ, …

Giới thiệu thêm hot trend vô cùng mạnh mẽ, Wormhole (wormhole.app)

Vậy tại Wormhole có gì đặc biệt?

– Đơn giản và nhanh chóng Bạn sẽ không cần đăng ký tài khoản hay đăng nhập, không yêu cầu địa chỉ email của bạn. Chỉ cần mở web/app lên, chọn file tải lên và thế là xong, trong chưa đầy 2 phút! Bạn có ngay một đường dẫn để chia sẻ trực tiếp hoặc qua email, mã QR code.

– Tùy chọn để xóa tập tin Bạn có thể tùy chọn sau một thời gian hay số lượt tải nhất định tập tin sẽ bị xóa.

– Thời gian xóa là từ 60 phút đến tối đa là 24 giờ. Số lượt tải từ 1 đến tối đa là 100. Điều này giúp bạn kiểm soát được dữ liệu của mình, tránh tình trạng lạc trôi trên internet.

– Tập tin được mã hóa đầu cuối. Tập tin của bạn sẽ thực sự được mã hóa đầu cuối(end-to-end encryption) giúp cho dữ liệu của bạn được bảo mật (đọc thêm ở đây).

– Phát trực tiếp các tệp tức thì, không yêu cần phải tải hết lên xong rồi mới phát đi

– Không có quảng cáo

Hi vọng công cụ này sẽ giúp bạn chia sẻ file một cách nhanh chóng và bảo mật hơn nhé.

Điều gì xảy ra khi một chương trình JavaScript được thực thi?

Mọi thứ trong JavaScript diễn ra bên trong một ngữ cảnh thực thi, hay “Execution Context”. Có hai giai đoạn trong “Execution Context” là “Memory Creation””Code Execution”

Khi chương trình JS khởi chạy, một execution context ở global sẽ được tạo. Ở giai đoạn “Memory Creation Phase”, bộ nhớ được cấp cho tất cả các biến và các hàm.

Ở giai đoạn “Code Execution”, code sẽ được thực thi từng dòng một theo thứ tự trên xuống dưới.

Nếu có một hàm được gọi, một Execution Context dành riêng cho hàm đó sẽ được tạo và thực hiện tương tự với hai giai đoạn trong Execution Context mới này. Khi một hàm kết thúc thực thi, thì Execution Context này sẽ được xóa đi.

Và cứ thế, chạy cho đến hết chương trình.

Quá trình ở trên thường được gọi là call stack

Mỗi execution context được tạo sẽ được bỏ vào(push) vào ngăn xếp(stack)

Mỗi execution context bị xóa sẽ được lấy ra khỏi(pop) ngăn xếp(stack)

Đây chính là cách JS Engine thực thi code.

Mời bạn đọc chi tiết về quá trình này kèm ví dụ và hình ảnh minh họa ở blog post này nhé.


Nội dung này thuộc BeautyOnCode’s short posts là các bài viết ngắn tóm tắt nội dung và ý kiến cá nhân từ các nguồn như các slack channels (công ty, cộng đồng), các new letters, …

Các bài viết này cũng được đăng ở:

👉 BeautyOnCode trên Careerly (lời hứa với Careerly) Trên đây có gần 900 người theo dõi, và là trang tin công nghệ khá hay, bạn có thể tải app rồi theo dõi mình nhé.

👉 Blog BeautyOnCode, chuyên mục “Short Posts”

👉 Fanpage BeautyOnCode

👉 Trang notion này tổng kết các bài viết

Nếu bạn thích đọc hàng ngày thì hãy follow các trang trên nhé. Chúc bạn đọc vui ^^

Nguồn: viblo.asia

Bài viết liên quan

Thay đổi Package Name của Android Studio dể dàng với plugin APR

Nếu bạn đang gặp khó khăn hoặc bế tắc trong việc thay đổi package name trong And

Lỗi không Update Meta_Value Khi thay thế hình ảnh cũ bằng hình ảnh mới trong WordPress

Mã dưới đây hoạt động tốt có 1 lỗi không update được postmeta ” meta_key=

Bài 1 – React Native DevOps các khái niệm và các cài đặt căn bản

Hướng dẫn setup jenkins agent để bắt đầu build mobile bằng jenkins cho devloper an t

Chuyển đổi từ monolith sang microservices qua ví dụ

1. Why microservices? Microservices là kiến trúc hệ thống phần mềm hướng dịch vụ,