1. Đây là một sân chơi mới, mà chúng ta là những developer, những người chưa có kinh nghiệm về quản lý dự án đang tập tành bước vào.

2. Biết "mình", biết "người", vì thế chúng ta cần chuẩn bị sẵn những vũ khí a.k.a nền tảng kiến thức của quản lý dự án. Chứ không phải dựa vào kinh nghiệm làm team leader, làm developer, hoặc những người đi trước để quản lý dự án.

Các kiến thức nền tảng

Quản lý dự án là gì?

Quản lý Dự án là quá trình lập kế hoạch, tổ chức, thực hiện và kiểm soát các nguồn lực, thời gian và chi phí để đạt được các mục tiêu cụ thể của dự án.

Một Project Manager cần phải nắm vững quy trình quản lý dự án, từ việc khởi tạo, lập kế hoạch, triển khai, giám sát đến kết thúc dự án.

Các bước cơ bản của quy trình quản lý dự án bao gồm:

1. What?

   1. Khởi tạo: Xác định mục tiêu, phạm vi và các bên liên quan của dự án.

   2. Lập kế hoạch: Phát triển kế hoạch dự án chi tiết, bao gồm các mốc thời gian, nguồn lực và ngân sách.

   3. Thực hiện: Triển khai kế hoạch, phối hợp các nguồn lực và quản lý các hoạt động của dự án.

   4. Giám sát và kiểm soát: Theo dõi tiến độ dự án, điều chỉnh kế hoạch khi cần thiết và đảm bảo rằng dự án đang đi đúng hướng.

   5. Kết thúc: Đánh giá kết quả và hoàn tất các thủ tục kết thúc dự án.

Kỹ năng quản lý thời gian và nguồn lực

1. What?

2. Why?

   1. Đảm bảo rằng tất cả các nhiệm vụ được hoàn thành trong khoảng thời gian đã định.

3. How?

   1. Phân bổ nguồn lực đúng lúc, đúng nơi

   2. Kỹ thuật quản lý thời gian: Áp dụng các kỹ thuật như Pomodoro, Eisenhower Matrix để tối ưu hóa hiệu quả làm việc

4. Tools?

   1. Các công cụ như Microsoft Project, Asana, hay Trello giúp Project Manager theo dõi tiến độ công việc, phân bổ nhiệm vụ và quản lý nguồn lực.

   2. Hay đơn giản nhất: Excel!

Kỹ năng giao tiếp và làm việc nhóm

1. What?

2. Why?

   1. Giao tiếp hiệu quả là chìa khóa để một dự án thành công

   2. Có những thống kê như sau: 90% công việc của PM là communicate

3. How?

   1. Lắng nghe chủ động: Luôn lắng nghe để hiểu rõ các vấn đề và nhu cầu của nhóm

   2. Sử dụng ngôn ngữ rõ ràng: Tránh các thuật ngữ phức tạp và luôn cố gắng truyền đạt thông tin một cách dễ hiểu nhất

   3. Xây dựng mối quan hệ: Tạo dựng sự tin tưởng và khuyến khích tinh thần làm việc nhóm trong nhóm dự án

4. Tools?

5. Should?

   1. Project Manager cần biết cách truyền đạt thông tin rõ ràng và hiệu quả giữa các thành viên trong nhóm, các bên liên quan và lãnh đạo

   2. Khả năng lắng nghe, đàm phán và giải quyết xung đột cũng là những kỹ năng quan trọng

Hiểu biết về công cụ và phương pháp quản lý dự án

1. What?

   1. Agile: Phù hợp với các dự án yêu cầu sự linh hoạt và thay đổi liên tục

   2. Waterfall: Một phương pháp truyền thống, thường được áp dụng trong các dự án có yêu cầu nghiêm ngặt về quy trình

   3. Scrum và Kanban: Hai phương pháp được sử dụng rộng rãi trong quản lý dự án phần mềm, giúp tăng cường khả năng cộng tác và tối ưu hóa quy trình làm việc

2. Why?

   1. Tools và phương pháp chính là nòng cốt để PM có thể tracking, flowing dự án hiệu quả

   2. Vì thế, chúng ta cần phải thành thạo các tools và phương pháp quản lý dự án khác nhau

   3. Tùy thuộc vào loại dự án và ngành nghề, các công cụ và phương pháp có thể khác nhau, nhưng những phương pháp phổ biến như Agile, Waterfall, Scrum, hay Kanban đều là những kiến thức nền tảng mà một Project Manager cần phải nắm rõ.

3. Tools?

4. How?

5. Should?

Kỹ năng giải quyết vấn đề và ra quyết định

1. What?

   1. Trong quá trình thực hiện dự án, sẽ không tránh khỏi những vấn đề phát sinh. Một Project Manager giỏi cần có khả năng nhận diện, phân tích và giải quyết vấn đề một cách nhanh chóng và hiệu quả

   2. Việc ra quyết định chính xác trong những tình huống khẩn cấp cũng là yếu tố quan trọng quyết định sự thành bại của dự án.

2. Why?

3. How?

   1. Nhận diện vấn đề: Xác định rõ nguyên nhân gốc rễ của vấn đề (Root Cause Analysis)

   2. Xem xét các lựa chọn và cân nhắc lợi ích cũng như rủi ro của từng giải pháp

   3. Chọn phương án tối ưu và thực hiện quyết định đó

4. Tools?

   1. 5whys?

   2. fishbone?

5. Should?

Kết luận

Trở thành một Project Manager thành công đòi hỏi sự kết hợp của nhiều kỹ năng và kiến thức. Việc hiểu rõ quy trình quản lý dự án, kỹ năng quản lý thời gian và nguồn lực, khả năng giao tiếp và làm việc nhóm, cùng với việc nắm vững các công cụ và phương pháp quản lý dự án sẽ giúp bạn khởi đầu một cách suôn sẻ trên con đường trở thành một Project Manager chuyên nghiệp.

Hy vọng rằng bài viết này đã cung cấp cho bạn cái nhìn tổng quan và những kiến thức cần thiết để bắt đầu hành trình của mình. Hãy tiếp tục học hỏi và trau dồi kỹ năng, vì quản lý dự án là một lĩnh vực không ngừng phát triển và đổi mới.

Nếu bạn cần thêm thông tin hoặc muốn tìm hiểu chi tiết hơn về bất kỳ phần nào trong bài viết, đừng ngần ngại để lại bình luận.

Để câu chuyện dễ theo dõi hơn, mình sẽ làm rõ một vài quan điểm sau

1. Project manager (PM) mình đang nhắc đến là trong lĩnh vực IT.

2. Đây là góc nhìn cá nhân của mình (từ một DEV quèn, đang học, hành làm PM). Nên rất mong các bạn đọc hoan hỉ, và góp ý để mình cải thiện thêm.

3. Mình chưa có nhiều kinh nghiệm quản lý dự án (như (2) - mình đang học, và rất may mắn đang được thử sức ở một dự án quan trọng của công ty).

Mở đầu

Xuất phát từ câu hỏi muôn thuở (thường là của các lập trình viên a.k.a dev): Sau senior thì mình làm gì tiếp theo, hay sau team leader thì mình làm gì nữa nhỉ?

Câu trả lời cho vấn đề trên là: Tuỳ theo từng tổ chức, sẽ có các chức danh, vai trò, nhiệm vụ khác nhau. Nhưng tựu chung, sẽ thường chia thành 2 hướng chính.

1. Theo hướng kỹ thuật: Khi các bạn đi theo hướng kỹ thuật, thì mục tiêu các bạn có thể hướng đến là các Software Architecture, sau đó là Technical Consultant, xa hơn nữa, và thường là đích đến sẽ là Chief Technology Officer (a.k.a CTO)

2. Theo hướng quản lý: Một hướng khác so với hướng kỹ thuật, sẽ là quản lý. Các mục tiêu (về mặt chức vụ) có thể kể đến như là: Project Manager (quản lý dự án), hoặc có thể là Product Manager, Product Owner, sau đó có thể hướng đến các chức vụ quản lý cấp cao như Division Manager, Director Manager, ... xa hơn là có thể là các cấp quản lý C-level

Và mình - xuất thân từ DEV, đã chọn lựa theo hướng quản lý, và bước đi đầu tiên (phù hợp với tổ chức mình đang làm việc) đó là Project Manager (PM).

Nếu các bạn thắc mắc, tại sao mình theo hướng quản lý - thì xin gặp lại bạn ở bài viết sau nhé!

Hành trình

Cuộc hành trình ngàn dặm đều bắt đầu bằng một bước chân đầu tiên nhỏ bé

Step 1: Chuẩn bị

Để làm được, hay đạt được một điều gì đó, chúng ta cần phải biết nó là gì? Để trở thành PM cũng thế, chúng ta cần phải biết PM là gì?

Project Manager là người quản lý dự án, đảm bảo rằng dự án được hoàn thành đúng thời hạn, trong ngân sách và đạt được mục tiêu được đề ra.

Vậy, làm cách nào để có thể trở thành PM?

Nếu bạn search câu hỏi trên ở google, thì sẽ ra khoảng 600k kết quả ~ 0.54(s). Điều đó đồng nghĩa với việc có không ít cách, hoặc không ít người chỉ cho bạn cách để có thể trở thành một PM. Mình sẽ không nhắc đến nó ở bài viết này. Điều mình muốn nhắc đến ở đây đó chính là Mindset (tư duy).

1. Bạn cần chuẩn bị một tư duy phát triển - Grownth Mindset: Nó giúp bạn tập trung vào việc học hỏi, cải thiện và phát triển khả năng của mình, thay vì chỉ tập trung vào việc tránh những thách thức và thất bại

2. Tư duy tổng thể: Cần nhìn nhận mọi vấn đề, mọi việc dưới góc độ toàn diện. Rất khác so với khi bạn đang làm dev (hoặc tester, BrSE) - nhìn nhận dự án dưới một góc độ nhất định. Việc quan sát tổng thể này sẽ thay đổi rất nhiều khi bạn chuyển sang role PM

3. Tư duy làm việc từ TÂM: Thực ra không chỉ mỗi PM, mà bất kể vị trí nào cũng cần có tư duy này, làm việc xuất phát từ tâm, từ sự mong muốn của bản thân, sẽ giúp cho công việc của bạn có một kết quả cực kì mãn nhãn. Đồng thời, cũng sẽ giúp cho bạn có trách nhiệm. Đối với PM - người có toàn quyền trong dự án, nếu bạn làm việc hời hợt, đơn thuần chỉ là công việc thì bạn sẽ không thể tận dụng hết quyền - trách nhiệm của mình cho chính dự án mình đang dẫn dắt, và đương nhiên, bạn sẽ không thể trở thành một người PM tuyệt vời!

STEP 2: Hành động

Cách nhanh nhất và tốt nhất để bạn có thể trở thành PM trong tổ chức của chính mình, là nói chuyện với cấp lãnh đạo của bạn. Bạn cần bày tỏ nguyện vọng của bản thân mình với các cấp trên của mình. Và sẽ nhận lại được những lời khuyên, sự support từ phía công ty. Và điều này, mình nghĩa là quan trọng nhất!

Đương nhiên, chúng ta vẫn cần phải đảm bảo đủ một vài điều kiện (cần) trước đó.

1. Kinh nghiệm là việc: Nếu bạn là một junior dev, bạn cần phấn đấu lên senior dev. Nếu bạn là một senior, cần phấn đấu lên vị trí TL, ...

2. Kết quả công việc: Nếu công việc hiện tại của bạn chưa tốt (hoặc xuất sắc) thì trước tiên, bạn cần hoàn thành điều đó. Bạn nghĩ sao khi một DEV code chức năng nhỏ nhỏ, nhưng lại nhiều bug - muốn làm PM?

3. Ảnh hưởng: Lãnh đạo nói chung, hay quản lý nói riêng suy cho cùng là việc bạn có ảnh hưởng (hoặc có thể ảnh hướng đến các thành viên khác) và hướng dẫn, giúp đỡ họ đạt được các mục tiêu (cá nhân, tổ chức, ...). Vì thế, việc bạn có mức độ ảnh hưởng nhất định trong team, trong phòng, hay thậm chí toàn công ty - cũng là một trong những yếu tố không thể thiếu!

Sau đó là các điều kiện đủ

1. Kiến thức: Tập trung nâng cao kỹ năng, kiến thức. Đảm bảo cover đủ các vùng đó. Output có thể là các chứng chỉ chẳng hạn. Cách tốt nhất là xin lời khuyên của các PM đi trước. Nếu không, thì cần tham khảo các khoá học, tài liệu uy tín.

   1. Ví du: Như ở tổ chức mình đang làm việc, có các khoá học cho các key-member muốn trở thành PM

   2. PMP - chứng chỉ hành nghề uy tín cho PM. Hiện tại ở VN có khác trung tâm đào tạo để chúng ta có thể đạt được!

   3. ...

2. Môi trường: Cần có môi trường để chúng ta có thể được học hỏi, và làm! Đây là điều rất quan trọng (đó là lý do vì sao mình đã nói là chúng ta cần sự ủng hộ của tổ chức). Nếu bạn chưa có mội trường, cần tạo ra môi trường đó bằng cách nhờ sự giúp đỡ của PM hiện tại, hoặc trưởng phòng, hoặc thậm chí là Giám đốc của chính tổ chức của bạn.

   Nên ghi nhớ rằng: Tố chức của bạn phải có chức danh PM nhé. Nếu không có thì có 2 hướng: một là tạo ra chức danh PM ở tổ chức hiện tại. Hai là đi tìm tổ chức khác!

Cuối cùng đó chính là Massive Action!

Massive action là việc thực hiện một lượng công việc lớn trong một khoảng thời gian ngắn nhằm đạt được mục tiêu đặt ra. Thay vì chỉ làm những việc cần thiết để hoàn thành công việc, người thực hiện massive action sẽ làm tất cả những gì có thể để đạt được mục tiêu của họ. Điều này bao gồm việc đưa ra kế hoạch chi tiết, đặt ra các mục tiêu cụ thể, tập trung vào những việc quan trọng và tối ưu hóa thời gian và tài nguyên để đạt được hiệu quả cao nhất.

Những khó khăn, lầm tưởng

Lầm tưởng

1. Project manager không cần biết về kỹ thuật: Mình không biết đã nghe câu này bao nhiêu lần rồi nữa, mọi người thường nghĩ việc làm Project mananger (quản lý dự án) chẳng cần phải biết quá nhiều về kỹ thuật. Chỉ cần quản lý tốt là được. Nhưng vấn đề là, quản lý dự án trong lĩnh vực IT là một điều hoàn toàn khác. IT là một ngành, nghề thay đổi theo từng ngày, thậm chí là từng giờ! Việc bạn nắm được kỹ thuật, và có kiến thức tốt về chúng, là một lợi thế rất lớn để giúp bạn là một người PM xuất sắc!

2. Project manager chỉ làm việc dự án: Trong thực tế, PM là người kết nối dự án với các bên liên quan (stakeholder) nhằm đảm bảo cho dự án diễn ra thuận lợi nhất.

3. Project manager chỉ là người quản lý dự án: Theo định nghĩa thì đúng, họ chỉ là quản lý dự án. Nhưng trên thực tế, một người PM được cho là xuất sắc thì họ cũng cần phải là người leader giỏi. Họ cần phải thúc đẩy được tiềm năng của các thành viên trong dự án, tạo được môi trường, động lực cho thành viên phát triển tốt nhất có thể.

Khó khăn

1. Bạn là một người hướng nội: Để trở thành PM, bạn cần có một kỹ năng giao tiếp, đàm phán tốt - và điều đó diễn ra hàng ngày. Rất khó khăn nếu bạn cảm thấy việc giao tiếp là khó khăn

2. Bạn là dev (tester, ...): Như mình, một người làm về kỹ thuật, khi chuyển sang hướng đi PM, bạn không làm việc với các dòng code, các vấn đề kỹ thuật nữa. Thay vào đó là làm việc với con người! Nó sẽ không chỉ đơn giản như việc bạn tìm thấy solution cho một bài toán, bạn áp dụng, nó chỉ có đúng hoặc sai. Nhưng với con người hoàn toàn khác. Mỗi người mỗi tính, mỗi mục tiêu, mỗi cách giao tiếp, trò chuyện khác nhau. Và mình thực sự gặp khá nhiều khó khăn trong vấn đề này!

Tổng kết

Nhìn chung, việc trở thành PM (theo hướng quản lý) sẽ có vô vàn khó khăn, nhưng bên cạnh đó cũng có rất nhiều sự thú vị. Để tiện cho bạn đọc (lười đọc như mình), mình sẽ tổng kết một vài ý chính như sau

1. Sau Team Leader, Senior thì chúng ta sẽ làm gì?

   1. Tech: Solution Architecture -> Technical Consultant -> CTO

   2. Manager: PM (Project Manager, Product Manager) -> Division Manager -> C-level Manager

2. Để trở thành PM cần làm (có) gì?

   1. Tư duy

   2. Kiến thức

   3. Môi trường

   4. Chú ý:

      • Cần nói chuyện với lãnh đạo (để có thể support tốt nhất cho bạn)

      • Cần tìm được môi trường có thể đáp ứng được mong muốn của bạn

      • Trước đó, cần nhìn nhận lại bản thân xem đã đủ các điều kiện để có thể bước tiếp trở thành PM chưa?

3. Một vài lầm tưởng, khó khăn

   1. Lầm tưởng

      1. PM chỉ quản lý dự án, chỉ làm việc trong dự án

      2. PM không cần biết về kỹ thuật

   2. Khó khăn

      1. Làm việc với con người!

Cuối cùng, bài viết dự trên quan điểm cá nhân, nên sẽ có sự sai sót. Rất mong các bạn để lại ý kiến, comment cho mình!

Hôm nay, chúng ta cùng nhau thảo luận một chút về việc thư giãn của bản thân nhé.

Một thời gian dài, mình có khá nhiều việc cá nhân cản trở việc viết của mình (do lười không viết thì có). Thì hôm nay, với một chút coldbrew nhẹ nhàng, yên ả kết hợp với việc tiết trời mát mẻ, đôi lúc se se lạnh, và một chút nắng cuối tuần. Tất các các dư vị công lại đã khiến cho con tim nhẹ nhàng này lại phải thốn thức, đôi tay thô kệch này lại phải gõ phím không nguôi.

Quay trở lại với tiêu đề, thư giãn là gì?

Đôi lúc chúng ta thường lầm tưởng khái niệm này với việc buông thả, hưởng thụ. Để làm rõ, chúng ta cùng đi vào khái niệm của thư giãn.

Relaxation in psychology is the emotional state of a living being, of low tension, in which there is an absence of arousal, particularly from negative sources such as anger, anxiety, or fear

Tạm dịch ra theo tiếng việt, nôm na là

Thư giãn trong tâm lý là trạng thái cảm xúc của một sinh vật (sống), ít căng thẳng, trong đó không có sự kích thích, đặc biệt là từ các nguồn tiêu cực như tức giận, lo lắng hoặc sợ hãi

Vậy ích lợi của việc thư giãn là gì? Ngay bản thân cụm từ thư giãn, cũng đã khiến cho chúng ta có một mường tượng gì đó rất nhẹ nhàng, thư thả, thoải mái rồi nhỉ. Về ích lợi của nó thì rất nhiều (tạm thời mình sẽ không bàn đến ở đây)

Quay lại với câu nói lúc đầu rất nhiều người nhầm lẫn giữa thư giãn và việc buông thả, hưởng thụ. Hãy hiểu đơn giản rằng, thư giãn không có nghĩa là không kiểm soát bản thân, thư giãn là cách chúng ta nạp lại năng lượng thể chất và tinh thần cho bản thân mình. Chúng ta cần ý thức được việc bản thân chúng ta cần thư giãn. Và chúng ta xứng đáng với điều đó.

Thư giãn, hiểu đơn giản như một trong những trạm sạc năng lượng, để cho chuyến xe hành trình cuộc đời của chúng ta có thể đi một cách tốt nhất, êm ả nhất.

Mình đã từng là một người rất bức bối về việc cần phải phát triển bản thân mạnh mẽ, cần phải phát triển công việc nhanh chóng, cần phải hardwork, etc, ... Nhưng rồi cho đến bây giờ, mình nhận thấy thư giãn là một phần chúng ta không thể thiếu, mình coi đó như một sự trưởng thành trong suy nghĩ, trưởng thành trong cách nhìn nhận bản thân, nhìn nhận cuộc sống.

Tổng kết

1. Thư giãn - theo mình nghĩ là điều cần thiết của mỗi người, chúng ta cần nó, để có thể phát triển được bền vững hơn.
2. Thư giãn - có nhiều cách khác nhau, cũng tuỳ vào từng người sẽ có các trải nghiệm khác nhau.
3. Thư giãn, chứ không phải buông thả, hưởng thụ.

Trong phần này, chúng mình sẽ điểm qua, và nhắc lại nhanh một vài khái niệm cơ bản trong internet

• Network: Một nhóm các máy tính và các thiết bị kết nối với nhau
• Internet
  • Global
  • Networks của networks

• IP: Mỗi thiết bị trong internet sẽ có 1 địa chỉ IP khác nhau, và đây cũng chính là cách mà một máy tính (thiết bị) có thể nói chuyện với một máy tính (thiết bị) khác

  

• DNS: Domain Name System: là một hệ thống giúp phân giải từ domain name (tên miền), sang địa chỉ IP

  

How DNS works

Trên đây là tổng quan về việc tìm kiếm IP từ domain.

Tìm kiếm ở máy client

Khi truy cập vào một domain bất kì (mở trình duyệt và nhập đường dẫn).

1. Việc tìm kiếm sẽ được bắt đầu từ Browser Cache - nếu trước đó trình duyệt đã truy cập domain đó, thì địa chỉ IP sẽ được trả về ngay. và thực hiện thao tác request tới server tương ứng.
2. Nếu Browser Cache không có dữ liệu tương ứng. Việc tìm kiếm sẽ được đi tiếp sang tầng DNS Cache (lưu ở máy client), và Hosts File (được định nghĩa trong file hosts ở máy client)
3. Nếu Toàn bộ các phần trên không có. Chúng sẽ bắt đầu tìm kiếm ra ngoài máy client.

Tìm kiếm ở ngoài máy client

1. Nơi đầu tiên được tìm đến là Recursive DNS Servers (thường là các ISP - Internet Service Provider, ví dụ như Viettel, FPT, …). Các ISP này không lưu trữ IP của các domain, mà nó sẽ có cache - ví dụ một user khác truy cập vào trang web tương tự, thì địa chỉ IP và domain tương ứng sẽ được cache lại.
2. Và nếu không tìm thấy, từ Recursive DNS Servers sẽ gọi đến Root DNS Servers, ở đây sẽ lưu trữ Top Level Domains (TLDs), ví dụ như .com, .vn, .net. Từ đây sẽ trả về địa chỉ IP của TLD server tương ứng với domain mà user đang truy cập (ở ví dụ đang là .com)
3. Recursive DNS Servers sau khi có được địa chỉ IP của TLD server, chúng sẽ gọi vào đây để lấy thông tin của authoritative name server (NS) - là nơi lưu trữ lại thông tin chính xác của server chứa thông tin domain.
4. Sau khi có được địa chỉ IP của Authoritative Name Server, Recursive DNS Servers sẽ gọi vào đây để lấy thông tin của địa chỉ IP tương ứng với domain (ở ví dụ là google). Và thông tin này có thể được cache lại tại Recursive DNS Servers. Sau đó sẽ trả về cho browsers của người dùng (đương nhiên, cũng có thể được browsers cache lại)

Domain Info

Ở phần này, chúng ta cùng tìm hiểu sâu hơn về Domain Info, nơi chứa các DNS records, hoặc Zone files.

DNS records, hoặc Zone files được phân thành các loại như sau

1. A record - Address record: là record dùng để trỏ tên miền sang địa chỉ IP tương ứng

   Như ở ví dụ bên dưới, giả sử website là https://hoangpn.com

   Chúng ta thấy

   • @ naked domain, tượng trưng cho hoangpn.com sẽ được trỏ đến IP là 76.76.21.21
   • app hoặc bất kì tên miền nào khác - sẽ là sub domain: app.hoangpn.com được trỏ đến địa chỉ IP là 76.76.21.21
   • Note: TTL = Time To Live: đây là khoảng thời gian mà DNS cache lưu trữ tương ứng name tương ứng với địa chỉ IP

2. CNAME record - Canonical Name record là bản ghi quy định alias cho một domain nào đó, được chỉ đến domain, hoặc sub domain nào đó

   Như ví dụ bên dưới, chúng ta alias việc truy cập www.hoangpn.com sẽ trỏ sang domain hoangpn.com. Hoặc có thể truy cập fb.hoangpn.com sẽ được trỏ sang fb.com/hoangpn

   

3. MX record - Mail Exchange record: là record xác định mail server mà email sẽ được gửi tới

   Như ví dụ bên dưới, chúng ta có thể thấy được những mail đuôi @hoangpn.com, ví dụ như admin@hoangpn.com, user_a@hoangpn.com sẽ được gửi về mail server là mail.example.com mail-2.example.com , với trọng số là 10, và 20 - đây chính là độ ưu tiên xem sẽ ưu tiên gửi vào mail server nào trước.

   

4. TXT record - Text record: giúp chứa các thông tin dưới dạng text của 1 tên miền. Chủ yếu dùng cho server bên thứ 3 xác định xem domain có đáng tin cậy hay không.

5. NS record - Name Server record: giúp xác định thông tin của một tên miền cụ thể được khai báo và quản lý trên máy chủ nào.

   

Tổng kết

Qua các phần trình bày bên trên, chúng ta đã nắm được cơ bản về domain name services là gì và cách nó hoạt động ra sao. Hy vọng các kiến thức trên sẽ giúp ích cho các bạn ít nhiều.

Nhưng mọi khi, tuy đã rà soát lại, nhưng cũng sẽ không tránh khỏi việc có sai sót. Mong các bạn để lại góp ý, và cùng giúp nhau tiến bộ nhé.

Quay trở lại một chút với các kiến thức cơ bản. Chúng ta đã biết được rằng, để các máy tính có thể giao tiếp được với nhau, chúng cần phải biết địa chỉ IP. Việc chúng ta - con người, có thể nhớ được một chuỗi địa chỉ IP dài khác nhau là điều rất khó khăn. Vậy làm thế nào để khắc phục điều này.

Từ khó khăn đó, Domain Name, hay còn gọi là tên miền ra đời. Chúng thay thế cho việc nhớ các con số (địa chỉ IP), bằng cách nhớ các tên dễ hơn, ví dụ như: google.com, hoangpn.com.

Tóm lại, nôm na chúng ta có thể hiểu Domain Name = ánh xạ của địa chỉ IP

Ai quản lý Domain Name?

Các domain names được quản lý bởi các công ty đăng ký tên miền - các công ty này được uỷ quyền tạm thời là chủ sở hữu của tên miền. Bất kỳ ai muốn tạo một trang web với tên miền nào đó, có thể đăng ký với các công ty nói trên. Ở việt nam có một vài công ty nổi tiếng như: Mắt Bão, HostVN, hay một số công ty khác như godaddy.com

Bạn sẽ cần phải trả phí hàng năm (hoặc hàng tháng) để có thể duy trì tên miền. Ví dụ như hoangpn.com Khi tên miền sắp hết hạn, các công ty quản lý tên miền sẽ có nhiệm vụ thông báo cho các bạn gia hạn tên miền của mình, để đảm bảo rằng bạn sẽ không bị mất đi tên miền của mình vào tay người dùng khác.

Các thành phần của một Domain Name

Domain names are typically broken up into two or three parts, each separated by a dot. When read right-to-left, the identifiers in domain names go from most general to most specific. The section to the right of the last dot in a domain name is the top-level domain (TLD). These include the ‘generic’ TLDs such as ‘.com’, ‘.net’, and ‘.org’, as well as country-specific TLDs like ‘.uk’ and ‘.jp’.

Domain names thường sẽ được tách thành 2, 3 phần khác nhau, được ngăn cách bởi dấu .

Khi đọc từ phải sang trái, tên được ngăn cách đầu tiên bởi dấu . được gọi là TLD - Top Level Domain, lần lượt các tên tiếp theo được gọi là 2LD, 3LD, … ví dụ như: hoangpn.com ⇒ có TLD là .com , 2LD là hoangpn

Domain Name vs URLs

Đôi khi chúng ta thường nhầm lẫn 2 khái niệm này với nhau. Ở phần này, chúng ta sẽ cùng tìm hiểu và so sánh về 2 khái niệm là Domain Name và URL.

Dưới đây là cấu trúc đầy đủ của một URL

Như chúng ta đã thấy, thì Domain Name chỉ là 1 phần của URL. Chúng ta sẽ cùng đi qua các phần của URL

1. Scheme: đây là phần cho biết giao thức mà trình duyệt sẽ dùng để gửi đi request, thường sẽ là http, hoặc https. Trong một vài trường hợp có thể là mailto: ⇒ dùng để gửi mail.
2. Domain Name: Phần này chính là tên miền (mà mình vừa trình bày ở phía trên)
3. Port: Đây là cổng để gói tin (browsers request) có thể đến được đúng nơi mà nó muốn truy cập. Mỗi một ứng dụng khác nhau sẽ có một port tương ứng khác nhau. Một vài port thường gặp như
   1. 80 ⇒ đại điện cho http
   2. 443 ⇒ đại diện cho https
   3. 3306 ⇒ đại diện cho MySQL database
   4. …
4. Path to the file: /path/to/myfile.html là đường dẫn đến tài nguyên (resources) trên server.
5. Parameters: ?key1=value1&key2=value2 là các tham số bổ sung được truyền lên cho server để xác định các tài nguyên cụ thể hơn. Được biểu hiện là các cặp key-value, được phân tách bằng dấu ?
6. Anchor: #SomewhereInTheDocument là phần neo đến phần nào đó trong trang web được trả về. Lưu ý rằng phần này sẽ không được gửi lên trên server, mà sẽ chỉ xử lý ở browsers.

Tổng kết

Qua các phần trình bày bên trên, chúng ta đã nắm được cơ bản về domain name là gì, và tránh sự nhầm lẫn giữa domain name với Urls.

Hy vọng các kiến thức trên sẽ giúp ích cho các bạn ít nhiều.

Nhưng mọi khi, tuy đã rà soát lại, nhưng cũng sẽ không tránh khỏi việc có sai sót. Mong các bạn để lại góp ý, và cùng giúp nhau tiến bộ nhé.

Các trình duyệt chúng ta có thể điểm qua như

• Internet Explorer
• Chrome
• Firefox
• Safari
• Opera
• …

Đương nhiên, cũng có các trình duyệt khác trên mobile nữa, nhưng tôi sẽ không quá đi sâu vào nó.

Vào cái thời mà IE (Internet Explorer) còn thống trị, làm mưa làm bão thì chúng ta gần như không thể biết được bên trong IE là gì, chúng ta buộc phải coi nó là một “black box”. Nhưng thời thế đã thay đổi IE giờ đã bị khai tử, và thay vào đó là hàng loạt các trình duyệt phát triển dựa trên open source (mã nguồn mở). Và đây là thời điểm để chúng ta đi sâu vào bên trong chúng, để xem thực sự thì bên trong trình duyệt có gì, và cách chúng hoạt động như thế nào??

Chức năng chính của browsers

Chức năng chính của trình duyệt là hiển thị tài nguyên web bạn truy cập, bằng cách request tài nguyên đó từ server và hiển thị trong cửa sổ trình duyệt. Tài nguyên thường là tài liệu HTML, nhưng cũng có thể là PDF, hình ảnh hoặc một số loại nội dung khác. Vị trí của tài nguyên được chỉ định bởi người dùng bằng cách sử dụng URI (Uniform Resource Identifier - Định danh tài nguyên đồng nhất).

Cách trình duyệt diễn giải và hiển thị các tệp HTML được chỉ định trong thông số kỹ thuật HTML và CSS. Các thông số kỹ thuật này được duy trì bởi tổ chức W3C (World Wide Web Consortium), là tổ chức tiêu chuẩn cho web. Trong nhiều năm, các trình duyệt chỉ tuân theo một phần thông số kỹ thuật và phát triển các tiện ích mở rộng (extensions) của riêng chúng. Điều đó gây khó khăn cho các nhà phát triển web (web developer). Nhưng cho đến thời điểm hiện tại, điều này gần như là không còn.

Browsers tuy có nhiều bên phát triển khác nhau, nhưng nhìn chung, chúng đều có các thành phần sau

1. Nơi gõ địa chỉ web - URI
2. Các nút Back và forward
3. Tuỳ chọn bookmarking
4. Refresh và stop buttons dùng để tải lại, hoặc dừng tải trang.
5. Home button
6. …

Giao diện của các browsers được hình thành và phát triển qua nhiều năm dựa trên những feedback, đánh giá của người dùng. Các đặc tả HTML chỉ là một phần bên trong, chúng không ảnh hưởng tới các thành phần kể trên.

Kiến trúc của browsers

Browsers nói chúng, có kiến trúc cơ bản gồm các thành phần sau

1. The user interface: bao gồm thanh địa chỉ, nút back/forward, bookmarking, v.v.. Mọi phần của browser trừ cửa sổ nơi bạn nhìn thấy trang web được load.
2. The browser engine: đây là phần quan trọng nhất của trình duyệt, nó chịu trách nhiệm kết nối, đối ứng các thao tác của người dùng với tầng rendering engine.
3. The rendering engine: chịu trách nhiệm hiển thị nội dung trang web được truy cập. Ví dụ: nếu nội dụng bạn request là HTML, rendering engine sẽ phân tích HTML và CSS, sau đó sẽ hiển thị nội dung đã được phân tích, xử lý ra ngoài màn hình.
4. Networking: chịu trách nhiệm quản lý việc call networks bằng các giao thức tiêu chuẩn như HTTP hoặc FTP. Nó cũng xem xét các vấn đề bảo mật liên quan đến giao tiếp internet.
5. UI backend: thành phần này sử dụng các phương pháp giao diện người dùng của hệ điều hành cơ bản. Nó chủ yếu được sử dụng để vẽ các thành phần cơ bản như (window và boxes).
6. JavaScript interpreter: chịu trách nhiệm phân tích và thực thi mã JavaScript
7. Data storage: web browser cần lưu trữ nhiều loại dữ liệu khác nhau ở ngay tại trình duyệt, chẳng hạn như cookies. Các trình duyệt cũng hộ trợ việc lưu trữ các dữ liệu khác như localStorage, IndexedDB, WebSQL và FileSystem.

NOTE: Các trình duyệt như Chrome chạy nhiều phiên bản của rendering engine: một phiên bản cho mỗi tab, nghĩa là mỗi tab chạy trong một quy trình riêng biệt.

Quá trình lấy Server response

Navigation

Người dùng nhập trên trang web muốn truy cập lên trình duyệt, và bấm nút enter, hoặc nút truy cập (tuỳ theo mỗi trình duyệt sẽ có giao diện khác nhau). Sẽ tuỳ vào từng trang web, mà latency (độ trễ) để hiển thị trang web sẽ khác nhau ⇒ đây cũng là một điểm mà các web developer cần chú ý.

DNS lookup

Từ tên miền (mà người dùng truy cập). sẽ qua một quá trình gọi là phân giải tiên miền. Mục đích là để tìm được địa chỉ IP của server (muốn truy cập). Qua quá trình này, tên miền, sẽ được phân tích thành địa chỉ IP (của server) tương ứng.

https://hoangpn.com => 76.76.21.21

TCP Handshake

Khi browser đã biết được IP của server. Giữa chúng sẽ thực hiện một quá trình để có thể kết nối với nhau được gọi là TCP handshake, hay còn gọi là bắt tay 3 bước

Cơ chế này được thiết kế để cả 2 bên (server và browser) có thể thương lượng các tham số của việc kết nối (thông qua TCP socket) trước khi truyền dữ liệu (gửi và nhận) cho nhau.

Kỹ thuật bắt tay ba bước thường được gọi là "SYN-SYN-ACK" - hay chính xác hơn là SYN, SYN-ACK, ACK. Điều này có nghĩa là có thêm request qua lại giữa browser và server mà request web vẫn chưa được thực hiện.

TLS Negotiation

Đối với các kết nối an toàn được thiết lập thông qua HTTPS, cần có một "handshake" khác. Sự bắt tay này, hay đúng hơn là TLS negotiation, xác định mật mã nào sẽ được sử dụng để mã hóa giao tiếp, xác minh server và thiết lập kết nối an toàn trước khi bắt đầu truyền dữ liệu thực tế. Điều này yêu cầu thêm 3 request qua lại đến server trước khi request web thực sự được gửi.

⇒ Sau 8 request qua lại, thì web request sẽ được thực thi.

Response

Khi web request được gửi đi, server sẽ phẩn hồi bằng cách trả về các response, thường là các file HTML.

<!DOCTYPE html>
<html lang="en-US">
  <head>
    <meta charset="UTF-8" />
    <title>My simple page</title>
    <link rel="stylesheet" src="styles.css" />
    <script src="myscript.js"></script>
  </head>
  <body>
    <h1 class="heading">My Page</h1>
    <p>A paragraph with a <a href="https://example.com/about">link</a></p>
    <div>
      <img src="myimage.jpg" alt="image description" />
    </div>
    <script src="anotherscript.js"></script>
  </body>
</html>

Response cho request ban đầu này chứa byte dữ liệu đầu tiên nhận được. Time to First Byte (TTFB) là khoảng thời gian từ khi người dùng đưa ra yêu cầu — chẳng hạn bằng cách nhấp vào liên kết — đến khi nhận được gói (packet) HTML đầu tiên này. Phần gói (packet) đầu tiên thường là 14KB.

TCP Slow Start / 14KB rule

Response đầu tiên sẽ là 14KB. Đây là một phần của TCP slow start, một thuật toán cân bằng tốc độ của kết nối mạng (network connection). Khởi động chậm dần dần làm tăng lượng dữ liệu truyền cho đến khi xác định được băng thông tối đa của mạng.

Trong TCP slow start, sau khi nhận được gói (packet) ban đầu, server sẽ tăng gấp đôi kích thước của packet tiếp theo lên khoảng 28KB. Các packet tiếp theo sẽ tăng kích thước cho đến khi đạt đến ngưỡng xác định trước hoặc xảy ra hiện tượng tắc nghẽn.

Rendering basic flow

Khi trình duyệt nhận được phần dữ liệu đầu tiên (first chunk) từ server, chúng sẽ không hiển thị ngay lên được trên giao diện web, mà sẽ trải qua một quá trình để xử lý dữ liệu (nhận được từ server) đó.

Các bước cơ bản bao gồm:

1. Trang HTML yêu cầu được rendering engine phân tích cú pháp thành nhiều phần (các chunks), bao gồm các file CSS riêng và trong file HTML. Các phần tử HTML sau đó được chuyển đổi thành các DOM nodes để tạo thành “content tree” hoặc “DOM tree.”
2. Đồng thời, trình duyệt cũng tạo ra một render tree. Render tree này bao gồm cả thông tin tạo kiểu (CSS) cũng như các hướng dẫn trực quan xác định thứ tự mà các phần tử sẽ được hiển thị. Render tree đảm bảo rằng nội dung được hiển thị theo thứ tự mong muốn.
3. Render tree sẽ phải trải qua quá trình bố trí hiển thị (layout process). Khi render tree được tạo, các giá trị vị trí hoặc kích thước không được gán ngay và render tree, mà phải trải qua một quá trình tính toán các giá trị để đánh giá vị trí mong muốn, quá trình này được gọi là bố trí hiển thị (layout process). Trong quá trình này, mọi node đều được gán tọa độ chính xác. Điều này đảm bảo rằng mọi node đều xuất hiện ở một vị trí chính xác trên màn hình
4. Bước cuối cùng là vẽ lên màn hình, trong đó render tree được duyệt qua toàn bộ và phương thức paint() được gọi để vẽ từng node trên màn hình bằng cách sử dụng lớp UI backend layer.

NOTE: mỗi trình duyệt đều có rendering engine riêng của nó, và đây chính là điều khó khăn đối với các web developers - sẽ cần phải coding sao cho tương thích với mọi trình duyệt. Đồng thời việc kiểm thử của các tester cũng sẽ cần phải đáp ứng trên nhiều trình duyệt khác nhau. Nhưng nhìn chung, việc này đã đơn giản hơn rất nhiều vào thời điểm hiện tại.

Parsing

Parsing - phân tích cú pháp là bước mà trình duyệt sẽ thực hiện để chuyển đổi dữ liệu nhận được (từ server) thành DOM - Document Object Model và CSSOM - CSS Object Model, đây là bước đầu tiên để trình duyệt có thể hiển thị dữ liệu lên giao diện người dùng.

DOM cũng được hiển thị và có thể được điều khiển thông qua các API khác nhau trong mã Javascript

Ngay cả khi HTML của trang lớn hơn packet 14KB ban đầu, trình duyệt vẫn sẽ bắt đầu parsing và cố gắng hiển thị trải nghiệm dựa trên dữ liệu mà nó có. ⇒ Đây là một điều cần lưu ý cho các web developers nếu muốn tối ưu hoá hiệu suất của trang web. Nhưng tất cả mọi thứ đó, chúng ta cần ghi nhớ rằng HTML, CSS và JavaScript phải trải qua quá trình phân tích cú pháp (parse).

Building DOM tree

Bước đầu tiên là xử lý HTML markup và xây dựng DOM tree. Phân tích cú pháp HTML liên quan đến mã hóa và xây dựng tree. HTML code bao gồm thẻ bắt đầu và thẻ kết thúc, cũng như tên và các giá trị thuộc tính. Nếu tài liệu được định dạng tốt, việc phân tích cú pháp nó sẽ đơn giản và nhanh hơn.

DOM tree là bản mô tả nội dung của tài liệu. Phần tử là thẻ đầu tiên và là root node của cây tài liệu. Cây này sẽ phản ánh các mối quan hệ và phân cấp giữa các thẻ khác nhau. Các thẻ được lồng trong các thẻ khác là các node con. Số lượng DOM node càng lớn thì thời gian xây dựng DOM tree càng mất nhiều thời gian.

Khi trình phân tích cú pháp tìm thấy các tài nguyên non-blocking, như hình ảnh, trình duyệt sẽ yêu cầu các tài nguyên đó và tiếp tục phân tích cú pháp.

Việc phân tích cú pháp có thể tiếp tục khi gặp phải file CSS, <script> - đặc biệt là những thẻ không có thuộc tính async hoặc defer (chặn quá trình hiển thị và tạm dừng phân tích cú pháp HTML). Việc phân tích cú pháp có thể bị dừng lại nếu gặp các thẻ đặc <script>, đặc biệt là các thẻ không có thuộc tính như async, defer.

Mặc dù trình quét tải trước của trình duyệt đẩy nhanh quá trình này, nhưng quá nhiều tập lệnh vẫn có thể ảnh hưởng tới việc hiển thị trang web.

Preload scanner

Preload scanner là một quá trình chạy ngầm (background), chạy độc lập với quá trình browsers xây dựng DOM tree. Preload scanner sẽ phân tích cú pháp thông qua nội dung có sẵn, và sẽ request các tài nguyên có độ ưu tiên cao như CSS, JS, web fonts ⇒ nhằm giảm tốc độ load trang.

<link rel="stylesheet" src="styles.css" />
<script src="myscript.js" async></script>
<img src="myimage.jpg" alt="image description" />
<script src="anotherscript.js" async></script>

Ở ví dụ trên, trong khi luồng chính đang phân tích cú pháp HTML và CSS, preload scanner sẽ tìm các tập lệnh (scripts) và hình ảnh, đồng thời bắt đầu tải chúng xuống.

Để đảm bảo scripts không block quá trình parsing, hãy thêm thuộc tính async hoặc thuộc tính defer nếu thứ tự thực thi và phân tích cú pháp JavaScript là quan trọng.

Việc chờ để có CSS sẽ không block việc parsing HTML, nhưng nó sẽ block JS vì JS thường được sử dụng để truy vấn tác động của thuộc tính CSS lên các phần tử (Element).

Building the CSSOM

Bước quan trọng tiếp theo trong việc xử lý rendering là xử lý CSS và xây dựng cây CSSOM - CSS Object Model. CSSOM tương tự như DOM. DOM và CSSOM đều là tree. Chúng là các cấu trúc dữ liệu độc lập. Trình duyệt chuyển đổi các quy tắc CSS thành một bản đồ các style mà nó có thể hiểu và hoạt động. Trình duyệt duyệt qua từng bộ quy tắc trong CSS, tạo một cây gồm các nodes với các mối quan hệ cha (parent), con (child) và anh chị em (sibling) dựa trên các bộ chọn CSS (selectors).

Giống như với HTML, trình duyệt sẽ phải chuyển đổi các quy tắc CSS thành một thứ mà nó có thể hiểu được. Do đó, nó sẽ lặp đi lặp lại quá trình CSS-to-object.

Việc áp dụng CSS sẽ được xếp chồng (ghi đè lên nhau) từ việc phân tích CSSOM.

Nhìn chung, việc áp dụng, hiển thị CSS sẽ rất nhanh, tổng thời tian để tạo CSSOM thường ít hơn thời gian cần cho một lần phân giải DNS thành IP.

Các web developers có thể trực tiếp chỉnh sửa CSS trên công cụ nhà phát triển (developer tool) trên mỗi trình duyệt tương ứng.

JavaScript Compilation

Trong khi CSS được xử lý phân tích cú pháp và hình thành CSSOM, các nội dung khác, bao gồm các file JavaScript sẽ được tải xuống (nhờ preload scanner). JavaScript được thông dịch, biên dịch, phân tích cú pháp và thực thi. Các tập lệnh được phân tích cú pháp thành cây cú pháp trừu tượng (abstract syntax trees). Một số công cụ trình duyệt lấy abstract syntax trees và chuyển toàn bộ vào một trình thông dịch, xuất ra mã bytecode - được thực thi trên luồng chính. Đây được gọi là biên dịch JavaScript.

Render

Rendering là bước bao gồm:

• style
• layout
• paint
• một số trường hợp sẽ có thêm compositing

CSSOM và DOM được tạo trong bước phân tích cú pháp được kết hợp thành một cây kết xuất (render tree). Render tree được sử dụng để tính toán bố cục của mọi phần tử hiển thị, sau đó sẽ vẽ chúng lên màn hình. Trong một số trường hợp, nội dung có thể được nâng cấp lên các lớp riêng của chúng và được tổng hợp, cải thiện hiệu suất bằng cách vẽ các phần của màn hình trên GPU thay vì CPU, giải phóng luồng chính.

Style

Sau khi hình thành Render Tree. Browsers sẽ duyệt qua từng node (có thể hiển thị) bắt đầu từ DOM root. Các thẻ sẽ không được hiển thị:

• <head> và các thẻ con của nó
• bất kì thẻ nào với thuộc tính display: none
• nodes với thuộc tính visibility: hidden ⇒ chú ý là thẻ này vẫn được đưa vào render tree.

Mỗi nodes hiển thị có các quy tắc CSSOM được áp dụng cho chúng. Render tree chứa tất cả các nodes hiển thị có nội dung và kiểu được tính toán dựa trên CSS cascade.

Layout

Layout là quá trình lần đầu tiên kích thước và vị trí của các nodes được xác định. Các lần sau được gọi là Reflow.

Layout là quá trình

• Xác định chiều rộng
• Xác định chiều cao
• Xác định vị trí của tất cả các nodes trong Render Tree
• Xác định kích thước và vị trí của từng đối tượng trên trang

Reflow là quá trình bất kỳ xác định kích thước và vị trí tiếp theo của phần từ trên trang, hoặc toàn bộ documents.

Khi render tree được xây dựng, quá trình layout sẽ bắt đầu. Render tree sẽ xác định các nodes nào được hiển thị (và nodes không hiển thị) cùng với style của chúng, nhưng sẽ không xác định kích thước, hoặc vị trí của mỗi nodes. Để xác định kích thước và vị trí chính xác của từng nodes, browsers duyệt hết Render Tree, bắt đầu từ root của nó.

Trên trang web, gần như mọi thứ đều là một box. Các thiết bị (devices) khác nhau sẽ có các định dạng kích thước khác nhau. Các định dạng kích thước này sẽ là cơ sở để quá trình layout diễn ra.

Paint

Bước cuối cùng trong việc rendering là pain - vẽ các nodes riêng lẻ lên trên màn hình.

Trong giai đoạn này, browsers chuyển đổi từng box ( đã được tính toán ở bước layout) thành các pixel trên màn hình. Mọi nodes sẽ để được chuyển đổi thành pixel tương ứng, bao gồm: text, colors, borders, shadows, và các phần tử khác như buttons, images. Và browsers cần thực hiện việc này một cách nhanh chóng.

Để đảm bảo scrolling và animation một cách mượt mà, mọi thứ sẽ được thực hiện ở luồng chính (main thread), bao gồm cả tính toán style, reflow và paint.

Ví dụ ở màn hình iPad 2048 X 1536, có hơn 3.145.000 pixel được vẽ trên màn hình. Để bước paint, reflow + paint diễn ra một cách nhanh chóng, các bản vẽ sẽ được chia thành nhiều lớp chồng chéo lên nhau ⇒ nếu điều này cần thiết phải thực hiện thì sẽ xuất hiện bước tiếp theo là compositing

Painting có thể chia nhỏ các nodes trong Render tree thành các lớp khác nhau. việc chia các lớp trên GPU (thay vì luồng chính trên CPU) sẽ giúp cải thiện hiệu suất của việc paint và re-paint. Nhưng điểm trừ của nó là sẽ tốn kém khi quản lý memory. Vì vậy chúng ta cần cân nhắn để sử dụng chúng một cách hiệu quả.

Compositing

Khi các tài liệu được vẽ ở các layers khác nhau, chúng cần được tổng hợp lại để đảm bảo rằng có thể hiển thị đúng (theo đúng thứ tự + nội dung chính xác)

Khi trang tiếp tục load các nội dung khác (assets), reflows có thể xảy ra, và chúng sẽ tạo ra một quá trình re-paint và re-composite.

Interactivity

Main thread (luồng chính) có thể sẽ phải đợi để xử lý hoàn tất nếu trong trường hợp chúng ta load file JS (sau events onload )

Time to Interactive (TTI) là thời gian tính từ request đầu tiên, tra cứu DNS và kết nối SSL đến thời điểm trang tương tác (interactive)

Interactive là thời điểm sau lần Painting toàn bộ nội dung đầu tiên - khi trang có responds tương tác của người dùng trong vòng 50ms. Nếu luồng chính bị chiếm dụng để parsing, compiling, và thực thi JavaScript, nó sẽ không khả dụng và do đó không thể đáp ứng các tương tác của người dùng trong thời gian này (dưới 50 mili giây).

Chúng ta cùng xét ví dụ dưới đây.

Trong ví dụ này, quá trình load nội dung DOM mất hơn 1,5s và luồng chính bị chiếm hoàn toàn trong toàn bộ thời gian đó, không phản hồi với các sự kiện click chuột (hoặc chạm vào màn hình cảm ứng). Chúng ta có thể thấy hình ảnh được tải nhanh, nhưng do file anotherscript.js có dung lượng 2MB và kết nối mạng bị chậm, do đó người dùng có thể nhìn thấy trang cực nhanh, nhưng không thể thao tác mà không bị giật, lag cho đến khi file JS trên được tải xuống, parsing, và executing. Và đương nhiên, đó sẽ không phải là một trải nghiệm người dùng tốt.

Tổng kết

Qua các phần trình bày bên trên, chúng ta đã nắm được cơ bản về Browsers, và cách chúng hoạt động. Tưởng chừng như đơn giản và hiển nhiên, nhưng việc chúng ta có thể truy cập website như ngày này, đã trải qua rất nhiều công đoạn để có thể giúp cho chúng ta có trải nghiệm mượt mà

Hy vọng các kiến thức trên sẽ giúp ích cho các bạn ít nhiều.

Nhưng mọi khi, tuy đã rà soát lại, nhưng cũng sẽ không tránh khỏi việc có sai sót. Mong các bạn để lại góp ý, và cùng giúp nhau tiến bộ nhé.

HTTP là một giao thức để tìm nạp các tài nguyên như tài liệu HTML.

Nó là nền tảng của bất kỳ trao đổi dữ liệu nào trên Web và nó là một giao thức máy khách-máy chủ (client - server), có nghĩa là các yêu cầu được khởi tạo bởi người nhận, thường là trình duyệt Web.

Một tài liệu hoàn chỉnh được tạo lại từ các tài liệu con khác nhau được tìm nạp, chẳng hạn như văn bản, mô tả bố cục, hình ảnh, video, tập lệnh và nhiều thành phần khác nữa

Client và server giao tiếp bằng cách trao đổi các thông điệp riêng lẻ (trái ngược với một luồng dữ liệu). Các thông điệp được gửi từ client (thường là một trình duyệt Web), được gọi là yêu cầu (request) và các thông báo được gửi bởi server dưới dạng câu trả lời được gọi là phản hồi (response).

Được thiết kế vào đầu những năm 1990, HTTP là một giao thức có thể mở rộng đã phát triển theo thời gian. Nó là một giao thức ở tầng ứng dụng (application layer) được gửi qua TCP hoặc qua kết nối TCP được mã hóa bằng TLS. Mặc dù về mặt lý thuyết, bất kỳ giao thức truyền tải đáng tin cậy nào cũng có thể được sử dụng.

Do khả năng mở rộng của nó, nó được sử dụng để không chỉ tìm nạp các tài liệu siêu văn bản, mà còn cả hình ảnh và video hoặc để đăng nội dung lên servers, ví dụ như các kết quả của HTML form. HTTP cũng có thể được sử dụng để tìm nạp các phần của tài liệu nhằm cập nhật các trang Web theo yêu cầu.

Components of HTTP-based systems

HTTP là một giao thức client-server: các yêu cầu được gửi bởi một thực thể, user-agent (hoặc một proxy thay mặt cho nó). Hầu hết thời gian user-agent là một trình duyệt Web, nhưng nó có thể là bất cứ thứ gì, ví dụ, một robot thu thập thông tin trên Web để điền và duy trì chỉ mục của công cụ tìm kiếm (search engine index).

Mỗi request riêng lẻ được gửi đến một server, server sẽ xử lý nó và cung cấp một response. Giữa client và server có rất nhiều thực thể, được gọi chung là proxy, thực hiện các hoạt động khác nhau. Ví dụ như gateways, hoặc caches

Trong thực tế, có nhiều máy tính hơn giữa trình duyệt và server để xử lý request: có bộ định tuyến (routers), modem, v.v. Nhờ thiết kế phân lớp của Web, chúng được ẩn trong network và các tầng truyền tải (transport layers). HTTP ở trên cùng, ở tầng ứng dụng (application layers). Mặc dù quan trọng đối với việc chẩn đoán các sự cố mạng, nhưng các lớp bên dưới hầu như không liên quan đến thiết kế của HTTP.

Client: the user-agent

• user-agent là bất kỳ công cụ nào hoạt động thay mặt cho người dùng. Vai trò này chủ yếu được thực hiện bởi trình duyệt Web, nhưng nó cũng có thể được thực hiện bởi các chương trình được các kỹ sư và nhà phát triển Web sử dụng để gỡ lỗi cho các ứng dụng của họ.
• Trình duyệt luôn là thực thể khởi tạo request. Không bao giờ là server (mặc dù một số cơ chế đã được thêm vào trong nhiều năm để mô phỏng các thông báo do server khởi tạo).
• Để hiển thị một trang Web, trình duyệt sẽ gửi một request ban đầu để tìm nạp tài liệu HTML đại diện cho trang đó. Sau đó, nó phân tích cú pháp tệp này, đưa ra các yêu cầu bổ sung tương ứng với các tập lệnh thực thi, thông tin bố cục (CSS) để hiển thị và các tài nguyên phụ có trong trang (thường là hình ảnh và video). Sau đó, trình duyệt Web kết hợp các tài nguyên này để trình bày tài liệu hoàn chỉnh, trang Web. Các tập lệnh do trình duyệt thực thi có thể lấy thêm tài nguyên trong các giai đoạn sau và trình duyệt Web sẽ cập nhật trang Web cho phù hợp.
• Trang Web là một tài liệu siêu văn bản (hypertext document). Điều này có nghĩa là một số phần của nội dung được hiển thị là các liên kết, có thể được kích hoạt (thường bằng cách nhấp chuột) để tìm nạp một trang Web mới, cho phép người dùng điều hướng user-agent của họ và điều hướng qua Web. Trình duyệt chuyển các hướng dẫn này thành các HTTP requests và diễn giải thêm các HTTP responses để cung cấp cho người dùng một response rõ ràng.

The Web server

• Server phục vụ theo request của client. Một server hầu như chỉ xuất hiện dưới dạng một máy duy nhất; nhưng nó thực sự có thể là một tập hợp các servers chia sẻ tải (cân bằng tải - load balancing) hoặc một phần mềm phức tạp liên kết đến các máy tính khác (như bộ nhớ cache, database server, hoặc e-commerce servers), tạo toàn bộ hoặc một phần tài liệu theo yêu cầu.
• Một Server không nhất thiết phải là một máy duy nhất, nhưng một số phiên bản phần mềm máy chủ có thể được lưu trữ trên cùng một máy. Với HTTP / 1.1 và Host header, chúng thậm chí có thể chia sẻ cùng một địa chỉ IP.

Proxies

Giữa trình duyệt Web và server, có nhiều máy tính tiếp các thông điệp HTTP. Do cấu trúc phân lớp của ngăn xếp Web, hầu hết chúng hoạt động ở tầng transport, tầng network hoặc tầng physical, và trở nên trong suốt ở tầng HTTP, có khả năng có tác động đáng kể đến hiệu suất (performance).

Những gì hoạt động ở các tầng ứng dụng (application layers) thường được gọi là proxy. Chúng có thể minh bạch, chuyển tiếp các request chúng nhận được mà không thay đổi chúng theo bất kỳ cách nào hoặc không minh bạch, trong trường hợp không minh bạch, chúng sẽ thay đổi request theo một cách nào đó trước khi chuyển nó đến server. Proxy có thể thực hiện nhiều chức năng:

• caching (bộ nhớ cache có thể công khai hoặc private, ví dụ như cache của trình duyệt)
• filtering (như chống vi-rut, hoặc các kiểm soát của phụ huynh)
• load balancing (cho phép nhiều máy chủ thực hiện các request khác nhau)
• authentication (kiểm soát quyền truy cập đến các tài nguyên khác nhau ở server)
• logging (cho phép lưu trữ thông tin lịch sử truy cập)

Basic aspects of HTTP

1. HTTP rất đơn giản: Việc đơn giản đến từ thiết kế của HTTP (thậm chí cả HTTP/2, HTTP/3), rất dễ dàng tiếp cận cho các lập trình viên mới, hoặc thậm chí là bất kỳ ai
2. HTTP dễ dàng mở rộng: HTTP headers giúp cho giao thức HTTP dễ dàng được mở rộng, hiện nay đã có các phiên bản HTTP/2, HTTP/3, .v.v..
3. HTTP là stateless, nhưng không phải sessionless
   1. stateless: không có kết nối giữa 2 request được thực hiện liên tiếp trên cùng một connection.
   2. không phải sessionless: bản thân HTTP cookies cho phép sử dụng các phiên trạng thái để giúp các HTTPS request chia sẻ cùng một ngữ cảnh, một trạng thái (ví dụ cùng một user đang thao tác)
4. HTTP và các kết nối: ⇒ bổ sung

What can be controlled by HTTP

Do tính chất có thể mở rộng của HTTP, nên theo thời gian, HTTP được phép kiểm soát nhiều hơn và chức năng của Web được mở rộng. Cache và authentication là các chức năng được xử lý sớm trong lịch sử HTTP. Chúng ta cùng đi qua một vài thứ mà HTTP có thể kiểm soát:

• Caching: Cách HTTP lưu trữ response của server tại client, và tái sử dụng cho các request tiếp theo (nếu có thể). Trong thực tế, ngoài HTTP cache (client cache) còn có rất nhiều cách caching khác nhau (tôi sẽ không trình bày thêm ở đây, để tránh đi quá xa khỏi nội dung của chủ đề)
• Giảm bớt origin constraint: Để ngăn chặn việc theo dõi và các hành vi xâm phạm quyền riêng tư, các trình duyệt Web thực thi sự tách biệt nghiêm ngặt giữa các trang web với nhau. Chỉ các trang từ cùng một nguồn gốc mới có thể truy cập tất cả thông tin của trang web đó (có thể hiểu là cùng đường dẫn, cùng port). HTTP header có thể giảm bớt sự phân tách nghiêm ngặt này ở phía server, cho phép một tài liệu trở thành một tập hợp thông tin có nguồn gốc từ các tên miền khác nhau.
• Authentication: Một số trang có thể được bảo vệ để chỉ những người dùng cụ thể mới có thể truy cập chúng. Xác thực cơ bản (basic authentication) có thể được cung cấp bởi HTTP, sử dụng WWW-Authenticate và các headers tương tự hoặc bằng cách thiết lập một phiên cụ thể bằng cách sử dụng cookie HTTP.
• Proxy và tunneling: Client hoặc Server thường được đặt trên mạng nội bộ và ẩn địa chỉ IP thực của chúng với các máy tính khác. Các HTTP request sau đó đi qua proxy để đến được server (và ngược lại). Không phải tất cả proxy đều là HTTP proxy. Ví dụ, giao thức SOCKS hoạt động ở cấp độ thấp hơn. Các giao thức khác như ftp, có thể được xử lý bởi các HTTP proxy.
• Sessions: Sử dụng HTTP cookie cho phép bạn liên kết các requests với trạng thái của server. Điều này tạo ra các phiên (sessions), mặc dù HTTP cơ bản là một giao thức state-less.

HTTP flow

Khi client giao tiếp với server, hoặc ngay cả với một proxy trung gian, nhìn chung nó sẽ thực hiện các bước sau:

1. Mở kết nối TCP: Kết nối TCP được sử dụng để gửi một hoặc nhiều request và nhận lại response. Client có thể mở một kết nối mới, sử dụng lại kết nối hiện có, hoặc mở một số kết nối TCP tới các servers khác.

2. Gửi HTTP message: Các HTTP messages (trước HTTP/2) chưa được đóng gói, nghĩa là chúng ta có thể nhìn thấy và đọc được các messages này. Từ HTTP/2 trở đi, các tin nhắn được đóng gói trong các khung (frames) ⇒ khiến cho chúng ta không thể đọc trực tiếp, nhưng các nguyên tắc gửi và nhận thì vẫn như cũ.

3. Nhận và đọc response từ server

4. Đóng, hoặc sử dụng lại các connection cho các request khác.

HTTP messages

HTTP messages, từ phiên bản HTTP/1.1 trở về trước chưa được đóng gói, và chúng ta có thể đọc được một cách dễ dàng

Từ HTTP/2 trở lên, những thông điệp này được nhúng vào một cấu trúc nhị phân (binary structure), một khung (frame), cho phép tối ưu hóa như nén header và multiplexing. Ngay cả khi chỉ một phần của thông báo HTTP ban đầu được gửi trong phiên bản HTTP này, ngữ nghĩa của mỗi thông báo là không thay đổi và server sẽ dịch lại (gần như toàn bộ) sang định dạng của HTTP/1.1.

Có 2 loại HTTP messages: requests và responses. mỗi loại sẽ có từng định dạng khác nhau.

HTTP request

Request bao gồm các thành phần sau

1. HTTP methods, thường là một động từ như GET, POST hoặc một danh từ như OPTIONS hoặc HEAD xác định hoạt động mà ứng dụng client muốn thực hiện. Thông thường, client đơn giản muốn lấy thông tin trang web (sử dụng GET), hoặc gửi biểu mẫu thông tin (form) lên server (sử dụng POST). Trong thực tế, bên cạnh POST và GET sẽ có các phương thức khác nữa như PUT/PATCH (chúng ta sẽ tìm hiểu sau)
2. Đường dẫn của tài nguyên để truy cập tới server. Một đường dẫn sẽ bao gồm các thông tin như protocol (http, https), hay TCP port (như 80, hoặc 443), nhưng chúng thường sẽ được lược bỏ (sử dụng default) ví dụ như: hoangpn.com
3. Phiên bản HTTP đang sử dụng (ở hình là HTTP/1.1).
4. Phần mở rộng Headers: để truyền tải thông tin cho server, giúp lấy thông tin chính xác để hoàn thiện trang web
5. Body, đối với một số phương thức như POST, bao gồm các tài nguyên được gửi đi

HTTP response

Response thường bao gồm các thành phần sau

1. Phiên bản HTTP đang sử dụng (ở hình là HTTP/1.1).
2. Status code: chỉ ra request có thành công hay không?
3. Status message: thông báo mô tả ngắn gọn về trạng thái của request
4. HTTP headers (giống như request)
5. Tuỳ chọn khác: ví dụ như body trả về (chứa thông tin và client mong muốn nhận được từ server)

Basic HTTP/3 vs HTTP/2 vs HTTP/1.1 comparison

Hiện tại đang có 3 version chính của HTTP đó là

1. HTTP/1.1
2. HTTP/2
3. HTTP/3

Tôi sẽ không đi quá sâu vào phần này, đồng thời giải thích chi tiết các khái niệm, liên quan. Nhưng sẽ có một vài lưu ý như sau

• HTTP/2 đã cải tiến được việc thông tin được truyền đi sẽ biến đổi thành các binary, đóng gói thông tin (HPACK, server push). Một phần nào đó giúp cải tiến tốc độ truy cập, và tính bảo mật của thông tin
• Sang đến HTTP/3, chúng ta đã thay thế TCP thành UDP + QUIC, thay thế HPACK thành QPACK, giúp cho tốc độ truyền tải nhanh hơn cũ rất nhiều lần.

Tổng kết

Qua các phần trình bày bên trên, chúng ta đã nắm được cơ bản về HTTP, và một vài khái niệm, kiến thức đằng sau nó. Hy vọng các kiến thức trên sẽ giúp ích cho các bạn ít nhiều.

Nhưng mọi khi, tuy đã rà soát lại, nhưng cũng sẽ không tránh khỏi việc có sai sót. Mong các bạn để lại góp ý, và cùng giúp nhau tiến bộ nhé.

What is IP - the Internet Addresses

• Chúng ta có thể hiểu, IP như là địa chỉ "nhà" của chúng ta vậy, để đến được nhà ai đó, thì chúng ta cần biết địa chỉ của họ, tương tự như vậy, để có thể "nói chuyện" với một máy tính nào đó, chúng ta cần biết địa chỉ IP của máy tính đó
• Vì Internet là một mạng toàn cầu gồm các máy tính nên mỗi máy tính được kết nối với Internet phải có một địa chỉ duy nhất
• Địa chỉ này có dạng xxx.xxx.xxx.xxx trong đó xxx phải là một số từ 0 - 255. Địa chỉ này được gọi là địa chỉ IP
• IP = Internet Protocol

Hình bên dưới minh họa hai máy tính được kết nối Internet; máy tính của bạn có địa chỉ IP 1.2.3.4 và một máy tính khác có địa chỉ IP 5.6.7.8. Internet được biểu diễn như một đối tượng trừu tượng ở giữa.

Nếu bạn kết nối với Internet thông qua Nhà cung cấp dịch vụ Internet (ISP), ví dụ như Vietel, FPT, …, bạn thường được chỉ định một địa chỉ IP tạm thời trong suốt phiên truy cập của mình. Nếu bạn kết nối Internet từ mạng cục bộ (LAN), máy tính của bạn có thể có địa chỉ IP cố định hoặc có thể lấy địa chỉ IP tạm thời từ máy chủ DHCP (Giao thức cấu hình máy chủ động). Trong mọi trường hợp, nếu bạn được kết nối với Internet, máy tính của bạn có một địa chỉ IP duy nhất.

Protocol Stacks and Packets - Ngăn xếp giao thức và gói

Làm thế nào để nó 'nói chuyện' với các máy tính khác được kết nối Internet?

Chúng ta cùng đi vào ví dụ cụ thể:

• Giả sử địa chỉ IP của bạn là 1.2.3.4 và bạn muốn gửi tin nhắn đến máy tính 5.6.7.8. Thông báo bạn muốn gửi là "Xin chào máy tính 5.6.7.8!".
• Rõ ràng, thông điệp phải được truyền qua bất kỳ loại dây nào kết nối máy tính của bạn với Internet.
• Giả sử bạn đã gọi đến ISP của mình từ nhà và tin nhắn phải được truyền qua đường dây điện thoại.
• Do đó, thông điệp phải được dịch từ văn bản chữ cái thành tín hiệu điện tử, truyền qua Internet, sau đó dịch ngược lại thành văn bản chữ cái.
• Làm thế nào điều này được hoàn thành? Thông qua việc sử dụng một ngăn xếp giao thức (protocol stack). Mỗi máy tính cần một giao thức để giao tiếp trên Internet và nó thường được tích hợp sẵn trong hệ điều hành của máy tính (tức là Windows, Unix, v.v.). Ngăn xếp giao thức (protocol stack) được sử dụng trên Internet được gọi là ngăn xếp giao thức TCP / IP vì hai giao thức truyền thông chính được sử dụng.
• Giao thức TCP/IP được miêu tả như sau

• Như vậy thông báo "Xin chào máy tính 5.6.7.8!" lấy từ máy tính của chúng ta đến máy tính có địa chỉ IP 5.6.7.8, nó sẽ xảy ra một như sau:

1. Thông báo sẽ bắt đầu ở đầu ngăn xếp giao thức trên máy tính của bạn và hoạt động theo chiều hướng xuống dưới.
2. Nếu tin nhắn được gửi dài, mỗi lớp ngăn xếp mà tin nhắn đi qua có thể chia tin nhắn thành những phần dữ liệu nhỏ hơn. Điều này là do dữ liệu được gửi qua Internet (và hầu hết các mạng máy tính) được gửi theo các phần có thể quản lý được. Trên Internet, những phần dữ liệu này được gọi là packets.
3. Các packets sẽ đi qua Application Layer và tiếp tục đến TCP layer. Mỗi packets được gán một port number. Các ports sẽ được giải thích sau, nhưng đủ để nói rằng nhiều chương trình có thể đang sử dụng TCP/IP stack và gửi thông báo. Chúng ta cần biết chương trình nào trên máy tính đích cần nhận thông báo, vì nó sẽ lắng nghe trên một port (cổng) cụ thể.
4. Sau khi đi qua TCP layer, các packets tiến tới IP layer. Đây là nơi mỗi packet nhận được địa chỉ đích của nó, 5.6.7.8.
5. Bây giờ các packets (gói tin nhắn) của chúng ta đã có số cổng và địa chỉ IP, chúng đã sẵn sàng để gửi qua Internet. Hardware layer đảm nhận việc chuyển các gói tin chứa văn bản chữ trong tin nhắn của chúng ta thành các tín hiệu điện tử và truyền chúng qua đường dây mạng.
6. Ở đầu bên kia của đường dây mạng ISP của bạn có kết nối trực tiếp với Internet. ISPs router (bộ định tuyến) kiểm tra địa chỉ đích trong mỗi gói và xác định nơi gửi nó. Thông thường, điểm dừng tiếp theo của gói tin là một bộ định tuyến khác. (Chúng ta sẽ nói về router ở phần sau)
7. Cuối cùng, các gói tin đến được máy tính có địa chỉ IP là 5.6.7.8. Tại đây, các gói bắt đầu ở cuối TCP/IP stack của máy tính đích và đi lên.
8. Khi các gói tin đi lên trên qua ngăn xếp, tất cả dữ liệu định tuyến mà ngăn xếp của máy tính gửi được thêm vào (chẳng hạn như địa chỉ IP và port number) sẽ bị loại bỏ khỏi các gói.
9. Khi dữ liệu lên đến đỉnh của ngăn xếp, các gói tin đã được tập hợp lại thành dạng ban đầu, "Xin chào máy tính 5.6.7.8!”

Networking Infrastructure - Cơ sở hạ tầng mạng

Sơ đồ bên trên là chi tiết của sở đồ ban đầu, chúng ta đã thấy từng thành phần rõ ràng hơn. Dưới đây là một số giải thích chi tiết hơn cho sơ đồ trên

• ISP duy trì các modems cho khách hàng trong quá trình kết nối của họ. Điều này được quản lý bởi một số dạng máy tính (thường là máy tính chuyên dụng) điều khiển luồng dữ liệu từ modem pool đến đường trục (backbone) hoặc bộ định tuyến (router) đường truyền chuyên dụng. Thiết lập này có thể được coi là một port máy chủ, vì nó phục vụ quyền truy cập vào mạng. Thông tin thanh toán và sử dụng cũng thường được thu thập ở đây.
• Sau khi các gói của bạn truyền qua mạng và thiết bị cục bộ của ISP, chúng được chuyển đến đường trục (backbone) của ISP hoặc đường trục mà ISP mua băng thông. Từ đây, các gói thường sẽ di chuyển qua một số bộ định tuyến và qua một số đường trục, đường dây chuyên dụng và các mạng khác cho đến khi chúng tìm thấy đích của chúng, máy tính có địa chỉ 5.6.7.8. Và trong thực tế có nhiều cách để có thể kiểm tra đường di chuyển của các gói tin qua các ứng dụng đặc thù.

Internet Infrastructure - Cơ sở hạ tầng của Internet

• Đường trục Internet được tạo thành từ nhiều mạng lớn kết nối với nhau.
• Các mạng lớn này được gọi là Nhà cung cấp dịch vụ mạng - Network Service Providers (NSP). Một số NSP lớn là UUNet, CerfNet, IBM, BBN Planet, SprintNet, PSINet, cũng như các NSP khác.
• Các mạng này ngang hàng với nhau để trao đổi lưu lượng packet. Mỗi NSP được yêu cầu kết nối với ba Điểm truy cập mạng - Network Access Points(NAP). Tại các NAP, lưu lượng gói có thể nhảy từ đường trục của NSP này sang đường trục của NSP khác. Các NSP cũng kết nối với nhau tại các Metropolitan Area Exchanges (MAEs).
• MAE phục vụ cùng mục đích như NAP nhưng thuộc sở hữu tư nhân. NAP là điểm kết nối Internet ban đầu. Cả NAP và MAE đều được gọi là Điểm trao đổi Internet hoặc IXs. NSP cũng bán băng thông cho các mạng nhỏ hơn, chẳng hạn như ISP và các nhà cung cấp băng thông nhỏ hơn

Sơ đồ bên trên không phải là sự trình bày thực sự của một phần thực tế của Internet. Sơ đồ trên chỉ nhằm chứng minh cách các NSP có thể kết nối với nhau và các ISP nhỏ hơn.

Không có thành phần mạng vật lý nào được thể hiện trong sơ đồ trên. Điều này là do cơ sở hạ tầng đường trục (backbone) của một NSP đơn lẻ là một bản vẽ phức tạp. Hầu hết các NSP xuất bản bản đồ về cơ sở hạ tầng mạng của họ trên các trang web của họ và có thể được tìm thấy dễ dàng. Để vẽ một bản đồ thực tế của Internet gần như không thể do kích thước, độ phức tạp và cấu trúc luôn thay đổi của nó.

The Internet Routing Hierarchy - Hệ thống phân cấp định tuyến internet

Vậy làm thế nào để các gói tin tìm đường qua Internet? Mỗi máy tính kết nối Internet có biết các máy tính khác đang ở đâu không? Các gói tin có đơn giản được 'phát sóng' (broadcast) tới mọi máy tính trên Internet không? Câu trả lời cho cả hai câu hỏi trước là 'không'. Không máy tính nào biết bất kỳ máy tính nào khác đang ở đâu và các gói tin không được gửi đến mọi máy tính. Thông tin được sử dụng để đưa các gói đến đích của chúng được chứa trong các bảng định tuyến được giữ bởi mỗi bộ định tuyến kết nối với Internet.

Routers are packet switches - Bộ định tuyến là bộ chuyển mạch gói. Một bộ định tuyến thường được kết nối giữa các mạng để định tuyến các packets giữa chúng. Mỗi bộ định tuyến biết về các mạng con của nó và địa chỉ IP nào chúng sử dụng. Bộ định tuyến thường không biết địa chỉ IP nào nằm trên nó.

Nhìn hình bên dưới, chúng ta có thể thấy các hộp đen kết nối các đường trục (backbone) là các bộ định tuyến. Các đường trục (backbone) NSP lớn hơn ở trên cùng được kết nối với một NAP. Dưới chúng là một số mạng con và bên dưới chúng là nhiều mạng con hơn. Ở dưới cùng là hai mạng cục bộ có gắn máy tính.

Khi một gói tin đến một bộ định tuyến, bộ định tuyến sẽ kiểm tra địa chỉ IP được đặt ở đó bởi IP protocol layer trên máy tính gốc.

Bộ định tuyến sẽ kiểm tra bảng định tuyến của nó. Nếu mạng chứa địa chỉ IP được tìm thấy, gói tin sẽ được gửi đến mạng đó. Nếu mạng chứa địa chỉ IP không được tìm thấy, thì bộ định tuyến sẽ gửi gói tin trên một tuyến đường mặc định, thường là theo hệ thống phân cấp đường trục (backbone) đến bộ định tuyến tiếp theo.

Hy vọng rằng bộ định tuyến tiếp theo sẽ biết nơi để gửi gói tin. Nếu không, gói tin lại được chuyển hướng lên trên cho đến khi nó đến đường trục (backbone) NSP. Các bộ định tuyến được kết nối với đường trục (backbone) NSP giữ các bảng định tuyến lớn nhất và tại đây gói tin sẽ được chuyển đến đường trục (backbone) chính xác, nơi nó sẽ bắt đầu hành trình 'đi xuống' qua các mạng nhỏ hơn và nhỏ hơn cho đến khi nó tìm thấy điểm đến.

Domain Names and Address Resolution - Tên miền và cách phân giải địa chỉ

Nhưng điều gì sẽ xảy ra nếu bạn không biết địa chỉ IP của máy tính bạn muốn kết nối? Điều gì xảy ra nếu bạn cần truy cập vào một máy chủ web được gọi là https://hoangpn.com/ Làm thế nào để trình duyệt web của bạn biết máy tính này sống ở đâu trên Internet? Câu trả lời cho tất cả những câu hỏi này là Domain Name Service - DNS. DNS là một cơ sở dữ liệu phân tán theo dõi tên máy tính và địa chỉ IP tương ứng của chúng trên Internet

Nhiều máy tính được kết nối với Internet lưu trữ một phần cơ sở dữ liệu của DNS và phần mềm cho phép người khác truy cập nó. Những máy tính này được gọi là máy chủ DNS. Không có máy chủ DNS nào chứa toàn bộ cơ sở dữ liệu; chúng chỉ chứa một tập hợp con của nó. Nếu máy chủ DNS không chứa tên miền được yêu cầu bởi máy tính khác, máy chủ DNS sẽ chuyển hướng máy tính yêu cầu đến máy chủ DNS khác.

Dịch vụ tên miền được cấu trúc dưới dạng phân cấp tương tự như phân cấp định tuyến IP. Máy tính yêu cầu phân giải tên sẽ được chuyển hướng 'lên' hệ thống phân cấp cho đến khi tìm thấy máy chủ DNS có thể phân giải tên miền trong yêu cầu.

Ở hình trên, minh họa một phần của hệ thống phân cấp. Ở ngọn cây là các domain roots. Một số tên miền cũ hơn, phổ biến hơn được nhìn thấy ở gần đầu. Ngoài ra con có vô số máy chủ DNS trên khắp thế giới tạo thành phần còn lại của hệ thống phân cấp - những tên miền khác ví dụ như xyz, dev, ….

Khi kết nối Internet được thiết lập (ví dụ: đối với mạng LAN hoặc Mạng Dial-Up trong Windows), một máy chủ DNS chính và một (hoặc nhiều) máy chủ DNS phụ thường được chỉ định như một phần của quá trình cài đặt.

Bằng cách này, bất kỳ ứng dụng Internet nào cần phân giải tên miền sẽ có thể hoạt động chính xác. Ví dụ: khi bạn nhập địa chỉ web vào trình duyệt web của mình, trước tiên trình duyệt sẽ kết nối với máy chủ DNS chính của bạn. Sau khi có được địa chỉ IP cho tên miền bạn đã nhập, trình duyệt sẽ kết nối với máy tính mục tiêu và yêu cầu trang web bạn muốn.

Application Protocols: HTTP and the World Wide Web

• Một trong những dịch vụ được sử dụng phổ biến nhất trên Internet là World Wide Web (WWW).
• Giao thức ứng dụng làm cho web hoạt động là Giao thức truyền siêu văn bản - Hypertext Transfer Protocol(HTTP).
• Đừng nhầm lẫn điều này với Ngôn ngữ đánh dấu siêu văn bản (HTML). HTML là ngôn ngữ được sử dụng để viết các trang web. HTTP là giao thức mà trình duyệt web và máy chủ web sử dụng để giao tiếp với nhau qua Internet.
• Nó là một giao thức ở tầng ứng dụng vì nó nằm trên TCP layer trong ngăn xếp giao thức và được sử dụng bởi các ứng dụng cụ thể để giao tiếp với nhau. Trong trường hợp này, các ứng dụng là trình duyệt web và máy chủ web (web browsers and web servers)
• HTTP là một giao thức dựa trên văn bản không kết nối (connectionless). Máy khách (trình duyệt web) gửi yêu cầu đến máy chủ web cho các phần tử web như trang web và hình ảnh. Sau khi yêu cầu được phục vụ bởi máy chủ, kết nối giữa máy khách và máy chủ trên Internet sẽ bị ngắt kết nối. Một kết nối mới phải được thực hiện cho mỗi yêu cầu. Hầu hết các giao thức được định hướng kết nối. Điều này có nghĩa là hai máy tính giao tiếp với nhau giữ cho kết nối mở qua Internet. HTTP thì không.

Khi bạn truy cập một URL trên trình duyệt web:

1. Nếu URL chứa tên miền, trước tiên trình duyệt kết nối với DNS và truy xuất địa chỉ IP tương ứng cho máy chủ web.
2. Trình duyệt web kết nối với máy chủ web và gửi một request HTTP (thông qua ngăn xếp giao thức) cho trang web mong muốn.
3. Máy chủ web nhận yêu cầu và kiểm tra trang web muốn truy cập. Nếu trang tồn tại, máy chủ web sẽ trả về tương ứng dữ liệu. Nếu máy chủ không thể tìm thấy trang được yêu cầu, nó sẽ gửi thông báo lỗi HTTP 404. (404 có nghĩa là 'Không tìm thấy trang' như bất kỳ ai đã lướt web có thể biết.)
4. Trình duyệt web hiển thị trang web tương ứng, và kết nối bị đóng.
5. Sau đó, trình duyệt web phân tích cú pháp qua trang web và tìm kiếm các phần tử trang web khác mà nó cần để hoàn thành. Chúng thường bao gồm hình ảnh, text, v.v.
6. Đối với mỗi phần tử cần thiết, trình duyệt tạo kết nối bổ sung và các request HTTP đến máy chủ cho mỗi phần tử.
7. Khi trình duyệt tải xong tất cả hình ảnh, text, v.v., trang web sẽ được hiển thị hoàn toàn trong cửa sổ trình duyệt.

Hầu hết các giao thức Internet được chỉ định bởi các tài liệu Internet được gọi là Yêu cầu Nhận xét - Request For Comments (RFC). RFC có thể được tìm thấy ở một số địa điểm trên Internet.

HTTP version 1.0 được chỉ định bởi RFC 1945.

Application Protocols: SMTP and Electronic Mail

Một dịch vụ Internet thường được sử dụng khác là thư điện tử. Thư điện tử sử dụng một giao thức cấp ứng dụng được gọi là Giao thức truyền thư đơn giản - Simple Mail Transfer Protocol (SMTP). SMTP cũng là một giao thức dựa trên văn bản, nhưng không giống như HTTP, SMTP là định hướng kết nối. SMTP cũng phức tạp hơn HTTP. Có nhiều lệnh và quy tắc trong SMTP hơn trong HTTP.

Khi bạn mở ứng dụng email khách (mail client) để đọc e-mail, đây là điều thường xảy ra:

1. Ứng dụng email khách (Netscape Mail, Lotus Notes, Microsoft Outlook, v.v.) mở một kết nối với mail server mặc định của nó. Địa chỉ IP hoặc tên miền của mail server thường được thiết lập khi ứng dụng email khách được cài đặt.
2. Mail server sẽ luôn truyền thông điệp đầu tiên để nhận dạng chính nó.
3. Máy khách sẽ gửi một lệnh SMTP HELO mà máy chủ sẽ trả lời bằng một thông báo 250 OK.
4. Tùy thuộc vào việc máy khách đang kiểm tra mail, gửi mail,… mà các lệnh SMTP thích hợp sẽ được gửi đến máy chủ, các lệnh này sẽ được phản hồi tương ứng.
5. Các request/response này sẽ tiếp tục cho đến khi khách hàng gửi lệnh SMTP QUIT. Sau đó kết nối sẽ bị đóng.

Chúng ta cùng tìm hiểu một ví dụ sau để hiểu rõ hơn: Một cuộc trò chuyện đơn giản giữa máy khách SMTP và máy chủ SMTP được hiển thị bên dưới. R: biểu thị các thông điệp được gửi bởi máy chủ (người nhận). S: biểu thị các thông điệp được gửi bởi máy khách (người gửi).

Ví dụ về SMTP này hiển thị thư do Smith gửi tại máy chủ USC-ISIF, tới
Jones, Green và Brown tại máy chủ BBN-UNIX. Ở đây chúng tôi giả định rằng
máy chủ USC-ISIF trực tiếp lưu trữ BBN-UNIX. Green - không có hộp thư tại máy chủ BBN-UNIX.
-------------------------------------------------------------

R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
S: HELO USC-ISIF.ARPA
R: 250 BBN-UNIX.ARPA

S: MAIL FROM:<Smith@USC-ISIF.ARPA>
R: 250 OK

S: RCPT TO:<Jones@BBN-UNIX.ARPA>
R: 250 OK

S: RCPT TO:<Green@BBN-UNIX.ARPA>
R: 550 No such user here

S: RCPT TO:<Brown@BBN-UNIX.ARPA>
R: 250 OK

S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah...
S: ...etc. etc. etc.
S: .
R: 250 OK

S: QUIT
R: 221 BBN-UNIX.ARPA Service closing transmission channel

SMTP được chỉ định bởi RFC 821

Transmission Control Protocol - Giao thức điều khiển truyền dẫn

• Dưới Application Layer trong ngăn xếp giao thức là TCP layer.
• Khi các ứng dụng mở kết nối với một máy tính khác trên Internet, các thông điệp mà chúng gửi đi (sử dụng một giao thức ở application layer cụ thể) sẽ được chuyển xuống ngăn xếp đến TCP layer.
• TCP layer chịu trách nhiệm định tuyến các giao thức ứng dụng đến đúng ứng dụng trên máy tính đích. Để thực hiện điều này, số cổng (port number) được sử dụng.
• Các cổng (ports) có thể được coi là các kênh riêng biệt trên mỗi máy tính. Ví dụ, bạn có thể lướt web trong khi đọc e-mail. Điều này là do hai ứng dụng này (trình duyệt web và ứng dụng mail) đã sử dụng số cổng khác nhau. Khi một gói tin đến máy tính và đi lên ngăn xếp giao thức, TCP layer sẽ quyết định ứng dụng nào nhận gói tin dựa trên số cổng.

TCP hoạt động (định tuyến dữ liệu qua các layer trong ngăn xếp giao thức đến đúng ứng dụng) như sau:

• Khi TCP layer nhận được dữ liệu từ application layer, nó phân đoạn nó thành các đoạn (chunks) có thể quản lý được và sau đó thêm TCP header với thông tin TCP cụ thể vào từng đoạn. Thông tin có trong TCP header bao gồm số cổng của ứng dụng mà dữ liệu cần được gửi đến.
• Khi TCP layer nhận được một gói từ IP layer (bên dưới nó), TCP layer sẽ tách dữ liệu TCP header khỏi gói đó, thực hiện một số cấu trúc lại dữ liệu nếu cần và sau đó gửi dữ liệu đến ứng dụng chính xác bằng cách sử dụng số cổng lấy từ TCP header.

TCP không phải là một giao thức dạng văn bản. TCP là một dịch vụ luồng byte, định hướng kết nối, đáng tin cậy. Hướng kết nối có nghĩa là hai ứng dụng sử dụng TCP trước tiên phải thiết lập kết nối trước khi trao đổi dữ liệu. TCP đáng tin cậy vì đối với mỗi gói nhận được, một xác nhận được gửi đến người gửi để xác nhận việc gửi. TCP cũng bao gồm một tổng kiểm tra trong header của nó để kiểm tra lỗi dữ liệu đã nhận. TCP header chi tiết như sau:

Lưu ý rằng không có chỗ cho địa chỉ IP trong TCP header. Điều này là do TCP không biết gì về địa chỉ IP. Công việc của TCP là lấy dữ liệu ở application layer từ ứng dụng này sang ứng dụng khác một cách đáng tin cậy. Nhiệm vụ lấy dữ liệu từ máy tính sang máy tính là công việc của IP.

Internet Protocol - Giao thức internet

Không giống như TCP, IP là một giao thức không có kết nối, không đáng tin cậy. IP không quan tâm liệu một gói có đến đích hay không. IP cũng không biết về các kết nối và số cổng. Công việc của IP là gửi và định tuyến các gói đến các máy tính khác. Các gói IP là các thực thể độc lập và có thể đến không đúng thứ tự hoặc không đến. Công việc của TCP là đảm bảo các gói tin đến và theo đúng thứ tự. Về điểm chung duy nhất IP với TCP là cách nó nhận dữ liệu và thêm thông tin IP header của chính nó vào dữ liệu TCP. IP header chi tiết như sau:

Ở trên chúng ta thấy địa chỉ IP của máy tính gửi và nhận trong IP header. Dưới đây là một gói tin trông như thế nào sau khi đi qua Application layer, TCP layer, và IP layer. Dữ liệu ở Application layer được phân đoạn trong TCP layer, TCP header được thêm vào, gói tin tiếp tục đến IP layer, IP layer được thêm vào và sau đó gói tin được truyền trên Internet.

Tổng kết

Ở tất cả phần trên, tôi đã trình bày cách internet hoạt động. Sẽ chẳng thể nói trước được điều gì, liệu rằng trong tương lai internet sẽ phát triển ra sao, nhưng chúng ta cần công nhận lợi ích của internet là vô cùng lớn. Để bạn chắc chắn về các kiến thức, tôi sẽ note lại một vài phần chúng ta cần chú ý dưới đây

1. What is IP
2. Protocol Stacks and Packets
3. Networking Infrastructure
4. Internet Infrastructure
5. The Internet Routing Hierarchy
6. Domain Names and Address Resolution
7. Application Protocols
   1. HTTP and the World Wide Web
   2. SMTP and Electronic Mail
8. Transmission Control Protocol (TCP)
9. Internet Protocol (IP)

Vậy để cho dễ nắm bắt được hơn, chúng ta sẽ cùng đi vào tìm hiểu một số câu hỏi cơ bản sau đây?

1. Internet là gì?
2. Ai tạo ra internet?
3. Ai điều hành, quản lý internet?
4. Tổng kết.

Internet là gì?

The Internet, dịch sang tiếng việt hiểu đơn giản là "mạng máy tính". Chúng ta cùng đi sâu hơn một chút vào các khái niệm.

• Internet là một mạng toàn cầu gồm các máy tính được kết nối với nhau giao tiếp thông qua một tập hợp các giao thức được tiêu chuẩn hóa. Nó bắt đầu như một dự án nghiên cứu hàn lâm vào năm 1969, và trở thành một mạng lưới thương mại toàn cầu vào những năm 1990. Ngày nay nó được sử dụng rộng rãi bởi gần như toàn bộ người dân trên thế giới.
• Internet đáng chú ý vì tính phi tập trung của nó. Không ai sở hữu Internet hoặc kiểm soát những người có thể kết nối với nó. Thay vào đó, hàng nghìn tổ chức khác nhau vận hành mạng lưới của riêng họ và thương lượng các thỏa thuận kết nối tự nguyện.
• Phần lớn mọi người truy cập internet bằng browsers (trình duyệt web) ⇒ nhưng đây chỉ là một phần nhỏ của internet, bên cạnh nó còn có các ứng dụng khác như mail, …

Không phải như mọi người lầm tưởng nó là một thứ gì đó như một đám mây internet Mà trên thực tế, chúng ta có thể hiểu đơn giản, internet là một DÂY CÁP (một chuỗi kết hợp các dây cáp), kết nối các máy tính với nhau (như hình dưới). Và các dây cáp này, nếu kết nối xa, sẽ thường được đi dưới lòng đất, thậm chí là đi qua biển. Vậy nên mới xuất hiện hiện tượng là cá mập cắn cáp quang => dẫn đến mạng internet bị chậm

Ai tạo ra internet?

• Internet bắt đầu với tên gọi ARPANET, một mạng lưới nghiên cứu học thuật được tài trợ bởi Cơ quan Dự án Nghiên cứu Tiên tiến của quân đội (ARPA, nay là DARPA). Dự án được dẫn dắt bởi Bob Taylor, một quản trị viên ARPA, và mạng được xây dựng bởi công ty tư vấn của Bolt, Beranek và Newman. Nó bắt đầu hoạt động vào năm 1969.
• Năm 1973, các kỹ sư phần mềm Vint Cerf và Bob Kahn bắt đầu nghiên cứu thế hệ tiêu chuẩn mạng tiếp theo cho ARPANET. Các tiêu chuẩn này, được gọi là TCP / IP, đã trở thành nền tảng của Internet hiện đại. ARPANET chuyển sang sử dụng TCP / IP vào ngày 1 tháng 1 năm 1983.
• Trong những năm 1980, nguồn tài trợ cho Internet chuyển từ quân đội sang Quỹ Khoa học Quốc gia (National Science Foundation - NSF). NSF tài trợ cho các mạng đường dài đóng vai trò là đường trục (backbone) của internet từ năm 1981 đến năm 1994. Năm 1994, Chính quyền Clinton đã chuyển quyền kiểm soát đường trục internet cho khu vực tư nhân. Nó đã được tư nhân vận hành và tài trợ kể từ đó.

Vậy tóm gọn lại chúng ta có thể hiểu cơ bản, internet bắt đầu là một dự án phục vụ cho quân đội Mỹ, sau đó Vint Cerf và Bob Kahn bắt đầu nghiên cứu và phát triển thế hệ tiêu chuẩn mạng (TCP / IP) => và chúng ta công nhận 2 kỹ sư trên chính là cha đẻ của internet

Ai điều hành, quản lý internet?

• Không ai điều hành Internet.
• Nó được tổ chức như một mạng lưới phi tập trung.
• Hàng nghìn công ty, trường đại học, chính phủ và các tổ chức khác vận hành mạng riêng của họ và trao đổi lưu lượng truy cập với nhau dựa trên các thỏa thuận kết nối tự nguyện.
• The Internet Corporation for Assigned Names and Numbers (ICANN) đôi khi được mô tả là chịu trách nhiệm quản lý internet. Đúng như tên gọi của nó, ICANN phụ trách phân phối tên miền (như https://hoangpn.com) và địa chỉ IP. Nhưng ICANN không kiểm soát ai có thể kết nối với Internet hoặc loại thông tin nào có thể được gửi qua đó.
• Chúng ta nên lưu ý rằng, ở mỗi quốc gia, chúng ta sẽ chịu sự kiểm soát của luật định ở các quốc gia đó, và cũng có các luật định về việc sử dụng internet tương ứng. Tuy rằng ICANN không kiểm soát ai có thể kết nối với Internet hoặc loại thông tin nào có thể được gửi qua đó, nhưng chúng ta cũng cần tuân thủ theo luật định hiện hữu.

Tổng kết

Vậy chúng ta đã cũng nhau đi qua một chút lịch sử về internet, và giải đáp một số hiểu lầm thường thấy. Cho đến ngày nay, chúng ta không thể phủ nhận được tầm quan trọng của internet. Thử hỏi một ngày không có internet, chúng ta sẽ sống và làm việc ra sao?

#bettereveryday #hoangpn

Hôm nay mình muốn chia sẻ một vấn đề theo mình là khá cần thiết cho các bạn trẻ, cũng như các bạn già như mình khi đi phỏng vấn.

Và dưới đây là Những điều ít ỏi mà tôi biết đến từ sự ngu dốt của tôi.

Phù hợp

Người phỏng vấn sẽ tìm người phù hợp với môi trường, không phải người giỏi nhất, không phải người chăm chỉ nhất, mà là người phù hợp với môi trường công việc hiện tại. Mình xin nhắc lại một lần nữa, đó là phù hợp.

Đã bao giờ các bạn thắc mắc rằng:

• Bạn mình học kém hơn mình, không giỏi bằng mình, mọi thứ mình có trội hơn hẳn bạn mình. Nhưng tại sao cùng phỏng vấn, bạn không được nhận. Và bạn của bạn thì lại là người được nhận.
• Hay, nếu cả 2 bạn cùng được nhận, nhưng mức offer của bạn mình lại cao hơn mình ???
• ... rất nhiều vấn đề khác nữa

Cái mình muốn nhắc đến ở đây chính là sự phù hợp, đương nhiên, qua 1h, 2h phỏng vấn không nói lên được liệu rằng bạn có phù hợp với công ty thật hay không. Nhưng cũng đã đủ dữ kiện để đánh giá tương đối. Việc phù hợp ở đây được thể hiện ở nhiều điều, nhưng theo bản thân mình nhận thấy thì có một số mục sau:

1. Kiến thức, kinh nghiệm của bạn cho vị trí hiện tại bạn muốn phỏng vấn.

   • Kiến thức Bạn hãy lưu ý tới vị trí hướng tới, và rà soát, hệ thống lại các kiến thức mình có để có thể đảm nhận được vị trí đó. Bạn không thể mang kiến thức của việc đi làm sale, để phỏng vấn vị trí của một luật sư được. Đương nhiên thực tế thì sẽ không có như ví dụ trên. Nhưng mình mong muốn các bạn hiểu rằng, hãy tập trung kiến thức vào vị trí ứng tuyển.
   • Kinh nghiệm Để ý rằng kinh nghiệm, không phải là số năm bạn làm việc trong lĩnh vực đó. Đừng lầm tưởng. Đối với mình khi đi phỏng vấn, mình sẽ không thường quan tâm tới số năm kinh nghiệm ghi trên CV, mà mình nhìn vào các dự án bạn đã làm, bạn đã trải qua, kể cả đó có thể là các dự án bạn thất bại.

2. Định hướng của bạn đối với môi trường công ty hiện tại đang có, hoặc sẽ có hướng phát triển.

   • Nếu bạn chủ động đi phỏng vấn ở bất kỳ môi trường nào, hãy dành chút thời gian để tìm hiểu định hướng của công ty sắp phỏng vấn. Điều này sẽ là điểm cộng trong mắt các nhà tuyển dụng.
   • Đương nhiên, cũng cần nhìn nhận lại xem định hướng của bản thân có phù hợp với công ty hay không, và ngược lại. Điều này sẽ giúp các bạn có cơ hội phát triển tốt nhất.

3. Mindset (tư duy), tính cách của bạn đối với môi trường công ty hiện tại => Đây là một phần khá quan trọng, mà nhiều bạn không chú ý đến khi đi phỏng vấn. Bản thân mình khi phỏng vấn rất coi trọng vấn đề này.

   • Đối với mình, đây có lẽ là điều quan trọng nhất của một ứng viên khi mình đi phỏng vấn. Mindset nhìn chung nó rất rộng. Tựu chung mình mong muốn nhìn thấy ở các bạn một growth mindset.
   • Kinh nghiệm, kiến thức thiếu, có thể học, nhưng tư duy không có, hoặc không đầy đủ, sẽ rất khó để thay đổi. Hãy nghiêm túc nhìn nhận lại tư duy đang có của mình.

4. Quyền lợi bạn mong muốn có phù hợp đối với môi trường hiện tại.

   • Đương nhiên, đối với các bạn đi phỏng vấn, phần lớn là chúng ta bán thời gian, chất xám của mình để đổi lấy quyền lợi. Nên chúng ta cũng cần phải có quyền lợi xứng đáng, mà chúng ta có thể chấp nhận được trong môi trường mới.
   • Theo mình, quyền lợi nên được sắp xếp theo thứ tự như sau (Đương nhiên, mỗi người sẽ có những mong muốn, góc nhìn khác nhau)
     1. Môi trường của công ty có phù hợp với bản thân, có giúp ích cho sự học hỏi, thăng tiến của bản thân hay không?
     2. Lương
     3. Các đãi ngộ khác như chăm sóc bản thân, du lịch, khám sức khoẻ, ...
   • Mình luôn đề cao các bạn có sự mong muốn phát triển bản thân, vì theo mình: bản thân bạn phát triển, thì tiền và các lợi ích khác chắc chắn sẽ đi theo sau. Mình thấy khá nhiều bạn nhảy công ty chỉ vì lương thấp. Hoặc đơn giản bạn muốn lương cao hơn, và thấy các công ty khác có vị trí phù hợp với mức lương cao hơn hiện tại. Ý kiến của mình rằng bạn nên nhìn ra xa hơn một chút. Đừng vì vài đồng lương thay đổi trước mắt mà có thể bỏ lỡ đi cơ hội của mình.

Tiềm năng

Các nhà tuyển dụng, người phỏng vấn các bạn sẽ nhìn vào thêm một khía cạnh khác của các bạn nữa. Đó chính là tiềm năng của các bạn nữa.

Tuyển dụng nhân sự, như một cuộc đầu tư vậy. Mà đầu tư thì sẽ đồng nghĩa với việc rủi ro càng lớn, lợi ích càng cao. Tuyển dụng, chính là đầu tư vào nhân sự phỏng vấn. Liệu rằng tương lai nhân sự này có thể mang lại lợi ích to lớn cho công ty không? Đó cũng là một câu hỏi mà các bạn phải tìm cách để giải đáp, chứng minh mình với các nhà tuyển dụng.

Một vài lưu ý

Phần dưới đây là một vài lưu ý mà mình nghĩ các bạn nên chuẩn bị trước khi đi phỏng vấn ở bất kì nơi nào.

1. Hãy chuẩn bị thật kỹ về hệ thống kiến thức mình đang có cho vị trí phỏng vấn.
2. Hãy tìm hiểu thật kỹ về vị trí, công ty mình đang muốn vào làm việc. => Việc này không tốn quá nhiều thời gian nhưng sẽ thể hiện cho nhà tuyển dụng rằng bạn nghiêm túc với công việc này. Và mình thấy gần như không có ai làm được điều này khi phỏng vấn.
3. Hãy tham khảo thị trường về mức đãi ngộ tương ứng => Để có thể có được quyền lợi tốt nhất.
4. Cuối cùng là: hãy ăn mặc chỉnh tề và đến đúng giờ đã hẹn.

Goodluck! 🍀🍀

Đương nhiên, tất cả những chia sẻ dưới đây

• Đều là ý kiến cá nhân, kinh nghiệm của mình tích luỹ được khi tham gia phỏng vấn các ứng viên.
• Được tham khảo từ nhiều nguồn như
  • Sách
  • Những người có kinh nghiệm hơn
  • ...

Cho nên tóm lại nó vẫn là ý kiến từ bản thân mình, nên rất mong các bạn để lại comment góp ý, để chúng ta cùng có những góc nhìn khác, và có thể cùng nhau phát triển.

Suốt hơn 15 năm, Robin Sharma đã thầm lặng chia sẻ với những công ty trong danh sách Fortune 500 và nhiều người siêu giàu khác một công thức thành công đã giúp ông trở thành một trong những nhà cố vấn lãnh đạo được theo đuổi nhiều nhất thế giới.

Đây là lần đầu tiên Sharma công bố công thức độc quyền này với bạn, để bạn có thể đạt được những gì tốt nhất, đồng thời giúp tổ chức của bạn có thể có những bước đột phá đến một cấp độ thành công mới trong thời đại thiên biến vạn hóa như hiện nay.

Notion - Nhà lãnh đạo không chức danh

🤔 Ý kiến, cảm nghĩ của bản thân mình về sách

Cuốn sách mang đến cho mình cái nhìn khá mới mẻ về việc lãnh đạo. Mình cứ nghĩ lãnh đạo là một cái gì đó cao siêu, nhưng mình đã nhầm. Việc cung cấp cái nhìn nhiều góc cạnh, từ những điều nhỏ nhất đã mở ra cho mình rất nhiều câu hỏi tự vấn về bản thân trong suốt thời gian vừa rồi.

Bên cạnh đó, việc lãnh đạo cũng có nghĩa cho chính bản thân mình. Từ những việc như suy nghĩ, cho đến các hành động. Một bước chuyển biến không phải là quá lớn đối với mình (vì cơ bản mình đã đặt bản thân vào các quy tắc, thói quen tốt trước đó), nhưng mình nghĩ rằng với các bạn - nó sẽ là một bước chuyển biến lớn.

Tuy nhiên, có một điểm trừ mà mình không thích. Đó chính là cách truyền đạt xuyên suốt quyển sách của tác giả. Bằng việc kể một câu chuyện như cổ tích - mình hiểu tác giả có ý muốn truyền đạt một cách thân thiện nhất có thể, nhưng đối với mình dường như điều đó phản tác dụng.

✴️ Tổng kết

NHÀ LÃNH ĐẠO KHÔNG CHỨC DANH là một quyển sách đáng để các bạn thử một lần đọc hết nó. Theo bản thân mình nghĩ nó sẽ phù hợp với mọi đối tượng, từ các bạn học sinh, sinh viên cho đến các bạn đã đi làm như mình. Hãy cảm nhận nó, và quay lại đây để chúng ta cùng thảo luận nhé!

Đầu tiên tôi phải thú nhận rằng, trong mọi việc làm của mình, nó đều mang một mục đích gì đó. Dù ít, dù nhiều, dù tốt, dù không tốt - nó đều chứa đọng trong mỗi việc tôi làm, từ những việc nhỏ nhất, tới những việc giúp tôi có được miếng cơm để ăn, manh áo để mặc.

Việc viết - blog cũng vậy. Nhưng trước khi đi vào mục đích của việc viết, thì tôi xin trình bày một vài khó khăn của chính bản thân mình trước đã nhé

Khó khăn của bản thân

1. Tôi tự nhận thấy mình không có năng khiếu với văn học nói chung, viết lách nói riêng. Thể hiện cụ thể nhất là từ hồi còn đi học, tôi luôn luôn không qua nổi 6.5 điểm (một điểm số khá tệ) Văn
2. Lời ăn, tiếng nói cũng không trau truốt, mượt mà như những gì mọi người biết về tôi ở thời điểm
3. Thói quen từ thời còn nhỏ là rất ít đọc sách + với việc chỉ chăm chú vào các con số khô khan toán học => Khiến tôi càng ghét việc viết lách hơn rất nhiều

Mục đích

Vậy, với xuất phát điểm đó, làm thế nào để tôi có thể viết được... Tôi cũng chẳng biết nữa, việc khó khăn nhất của làm bất kì một việc gì đó luôn là bước đi đầu tiên. Và may thay, tôi đã bước được bước đó, cho dù nó có rất tệ hại đi chẳng nữa.

Quay lại với mục đích của việc viết, thì có vài đầu dòng sau đây, mà tôi nghĩ nó đúng với hiện tại (tương lai - chưa biết)

1. Viết cho bản thân mình
   • Đầu tiên, tôi là dân kỹ thuật, tôi viết, chỉ đơn giản là lưu lại các bài học cho chính bản thân mình sau này. Lưu lại những kiến thức mà mình đã tích góp được qua một thời gian làm việc
   • Sau đó, tôi nhận ra rằng, viết - cũng là một cách để giảm tải stress, chia sẻ cảm xúc của chính mình
   • Cuối cùng, tôi chỉ đơn giản là muốn viết, muốn có một thói quen hàng tuần, thậm chí là hàng ngày. Viết cho thoả nỗi niềm
   • Đôi khi, viết - cũng là một cách tôi tâm sự với chính bản thân mình. Nó giúp tôi nhìn lại được quãng đường đã đi qua, và lý trí hơn cho quãng đường sắp tới.
2. Viết cho mọi người
   • Chẳng dám nhận là người tài giỏi, vì thật sự, tôi khá kém trong đám bạn của mình. Nhưng tôi nghĩ, những kiến thức, kinh nghiệm của mình, sẽ thật tốt nếu có thể giúp ích gì cho người khác
   • Gần đây, nếu các bạn có theo dõi bài viết của tôi, thì nó mang hơi hướng về life-style nhiều hơn là về công nghệ. Tôi muốn truyền chút động lực, chút cách sống tích cực của mình cho mọi người. Và thật vui khi tôi nhận được những lời quan tâm từ đồng nghiệp của mình về chiếc blog nhỏ nhắn của tôi.

Kết

Chẳng rõ từ bao giờ, việc viết lách đã khá quen tay cho dù tôi không chuyên như các tác giả, nhà văn, nhà báo, ... Còn rất nhiều điều thiếu sót - tôi hiểu nó. Nhưng có sao đâu nhỉ, hãy học từ những điều đó, thua ở đâu, đứng lên ở đó (không phải gấp đôi ở đó).

Hãy học từ chính thất bại của mình.

PS: Để cải thiện được, rất mong nhận được sự góp ý, bình luận của các bạn ❤️

Mình biết là nhiều bạn không thích phần này, vì nó khá nhiều chữ nghĩa, vì thế, mình sẽ cố gắng viết đơn giản nhất nhé.

Chúng ta cùng đi qua lịch sử một chút

Vào thế kỷ 19, một nhà kinh tế người Ý tên là Vilfredo Pareto đã quan sát thấy hàng năm, khoảng 20% số cây đậu Hà Lan ông trồng trong vườn nhà cho ra đến 80% hạt đậu thu hoạch được. Cùng thời điểm đó, khi nghiên cứu về kinh tế vĩ mô, Pareto lại phát hiện ra rằng 80% của cải và thu nhập của nước Ý được kiểm soát chỉ bởi 20% dân số. Nhận ra sự đặc biệt của tỷ lệ 80/20, Pareto cùng với hàng loạt nhà nghiên cứu sau đó đã lục tìm các số liệu trong kinh doanh, sản xuất kinh tế, xã hội và kết quả đều cho ra một những con số xấp xỉ với tỷ lệ 80/20

Đó, về cơ bản là ông ý nhận định thấy điều đó thông qua thực tế, hoàn toàn là số liệu, và từ đó đưa ra được cái quy luật gọi là 80/20. Về cơ bản thì

80% output (đầu ra/kết quả) được tạo bởi 20% input (đầu vào/hành động)

2. Cách tôi nhìn nhận về 80/20 trong cuộc sống

Trên thực tế, gần như hành động, sự việc nào cũng có thể áp dụng được quy luật này, đối với tôi, có vài ý chính như sau, và nó đã giúp tôi khá nhiều trong cuộc sống

2.1 Công việc, học tập

Tôi là một người khá tryhard trong công việc, nên hiển nhiên, nó sẽ được đề cập đầu tiên rồi. Đối với tôi thì

• 80% kết quả của một ngày làm việc tốt, được làm trong 20% thời gian trong ngày đó. Thật vậy, việc bạn plan công việc cho một ngày, việc bạn chọn lọc công việc nào quan trọng cần dành thời gian, việc nào không quan trọng, để xuống cuối, hoặc thậm chí không cần làm là rất quan trọng. Hãy tập cách bỏ bớt các việc không quan trọng, ưu tiên cho việc quan trọng của bạn. Đương nhiên, mỗi người sẽ có một hoàn cảnh khác nhau. Ý tôi ở đây là bạn cần điều chỉnh nó sao cho phù hợp với bản thân mình.
• Vậy học tập thì sao? Đương nhiên, để làm tốt một việc, bạn cần lên plan, chuẩn bị cho nó, và việc học cũng thế, chẳng khác gì cả. Cách bạn plan, chuẩn bị, và dành thời gian suy nghĩ xem mình học gì, học như thế nào, sẽ quyết định output đầu ra của bạn là tốt hay không tốt. Hiển nhiên rằng, bạn cần phải học, chứ không chỉ lên plan, nhưng ý tôi muốn nói ở đây rằng việc lên plan tốn bao nhiêu thời gian của bạn nhỉ 👀 - 20%

2.2 Bạn bè, đồng nghiệp

Cuộc sống sẽ nhàm chán biết bao nếu thiếu đi mối tương tác với bạn bè, đồng nghiệp của mình nhỉ? Vậy cách tôi áp dụng 80/20 vào khía cạnh này như thế nào?

• Đương nhiên rằng trong một môi trường văn phòng, hoặc đại học, lớp học, việc bạn phải giao tiếp với các "đồng nghiệp" xung quanh là điều không thể tránh khỏi được. Nhưng hãy để ý rằng, chỉ có 20% số đồng nghiệp thực sự quan tâm bạn hơn 80% những người còn lại, vì thế, hãy chọn cho mình những người đồng nghiệp tốt, và dành thời gian cho họ nhé
• Đến bạn bè thì sao nhỉ. Trước khi đi vào sâu hơn, bạn giúp tôi trả lời một câu hỏi nhỏ nhé. Bạn có bao nhiêu bạn thân tất cả? ... Đối với tôi, tôi có không nhiều, chắc chỉ vài người trên đầu ngón tay (maybe cả chân nữa 😂😂). Nhưng tựu chung lại khá ít. Và họ chính là 20% số người bạn mà bạn nên dành thời gian cho họ, không phải 80% số bè còn lại nhỉ.

2.3 Khác

Thực ra ngoài 2 góc nhìn trên, thì còn rất rất nhiều góc nhìn khác mà mình muốn chia sẻ với bạn. Nhưng, bài cũng đã quá dài rồi, thiết nghĩ, nên để bạn nhìn nhận vấn đề này vào chính cuộc sống của bạn, thì nó sẽ có ý nghĩa hơn rất nhiều...

Túm váy lại

Nhắc lại một lần nữa

80% output (đầu ra/kết quả) được tạo bởi 20% input (đầu vào/hành động)

Lời khuyên của bản thân mình là: Try it, hãy thử nó xem, bạn sẽ thấy có hiệu quả bất ngờ - cuộc sống của bạn sẽ chất lượng hơn rất nhiều...

P/S 1: Mình đã dọn dẹp lại phòng, và bỏ đi khá nhiều quần áo mình không còn dùng đến nữa => Thực sự giúp cho mình khá nhiều, vì phòng mình bé, và số lượng quần áo thì ngày một tăng lên. Và hi vọng rằng số quần áo mình bỏ đi đó, có thể giúp ích cho người khác

1. Chuẩn bị đầy đủ tài liệu cho công việc mình cần làm
2. Chuẩn bị không gian, môi trường làm việc phù hợp
3. Cần thời gian để não bộ có thể khởi động làm quen với công việc của mình, ví dụ như: để giải toán => cần thời gian để hiểu đề toán, ...
4. Thời gian thực sự bạn sẽ làm việc tập trung
5. Kết thúc. Đôi khi đây chưa phải là lúc bạn finish công việc, mà chỉ đơn giản là kết thúc một phần nào đó của công việc mà thôi.

Vậy với một mớ hỗn độn các thứ như bên trên, thì chúng ta cần một khoảng thời gian liên tục để có thể hoàn thành một công việc nào đó. Vậy sẽ thế nào nếu chúng ta có khoảng thời gian khoảng 10, 15 phút ?

Để tận dụng khoảng thời gian đó, chúng ta cần chuẩn bị tốt ở bước (1), hoặc thậm chí là bước (3). Thật vậy, đã bao giờ bạn đi đường mà cứ nghĩ mãi về một vấn đề nào đó, đã bao giờ bạn ăn cơm mà cứ ngẩn ngơ về công việc của mình?

Đối với tôi, tôi thường dùng khoảng thời gian đó để

1. Draft ý tưởng cho các bài viết của mình
2. Học tiếng anh, có thể là vocab, hoặc 1 cụm từ nào đó, ...
3. Đọc sách ngắn, những mẩu truyện ngắn

Chính bài post này được hình thành vào khoảng thời gian khoảng 10, 15 phút. Vì là #TIL nên tôi sẽ không trau truốt nó quá nhiều. Chỉ đơn giản là note lại.

Give it try, don't be shy!

Vấn đề gặp phải

Tại 1 web (giấu tên), prod báo về là bị CPU nhảy do chạy job => Điều tra nguyên nhân + hướng khắc phục

Các dữ kiện được cung cấp

1. Về việc phát sinh nhảy CPU là sau ngày x, trước ngày x các tác vụ vẫn bình thường
2. Phân tích log cho thấy slow-query ở 1 câu query Y => nhưng khi xử lý chạy câu query ở môi trường local không vấn đề gì cả
3. Khi job của mình chạy, thì có các job khác cũng chạy đồng thời

Giải quyết vấn đề

Dự đoán ban đầu: Việc tăng CPU khả năng cao là do việc query vào database lâu => từ đó dẫn đến CPU tăng đột ngột, nhưng tại sao, lại chỉ sau ngày x mới bị hiện tượng này, mà không phải bị từ đầu??

Điều tra

1. Từ (3) => thử cô lập tắt job của mình đi, xem còn có hiện tượng tăng CPU không => kết quả không còn tăng. Tương tự, thử tắc các job khác đi, giữ nguyên job của mình => thấy CPU vẫn tăng. Từ đó rút ra kết luận => Vấn đề xuất phát từ job của bên mình

2. Kiểm tra coding tương ứng (xem có thay đổi gì không), thì chỉ có 1 sự thay đổi: Bỏ 1 chiếc index ở bảng xử lý (nhưng index đó đã không dùng nữa) => không có sự phát sinh coding ảnh hưởng tới phần logic, query mình xử lý ở job

   # (1, 2, 3, 4, 5) là dynamic, phụ thuộc vào một vài điều kiện khác - truy vấn lấy id ở bảng khác theo thời gian phù hợp
    ...
    a INNER  JOIN b
      where b.column1 IN (1, 2, 3, 4, 5)
    ...
   

3. Từ (1), (2) => Lấy lại câu query gây slow => để kiểm tra chi tiết

   • Explain => thì thấy bảng b đang sử dụng partrition => khả năng dẫn đến chậm => nhưng vì nếu chậm thì phải chậm từ đầu => nên khả năng này bỏ ra khỏi nguyên nhân chính

   • Debug từng dòng, từng column1 IN => thì thấy phát sinh hiện tượng, rất lâu ở 1 ID, nhưng ngoài ID đó thì chạy vẫn bình thường => dự đoán khả năng là do phát sinh vấn đề ở đây

4. Kiểm tra lại điều kiện sinh ra (1, 2, 3, 4, 5) thì thấy phát sinh 1 bản ghi (bị chậm) mới được thay đổi điều kiện để có thể chạy job (tức là xuất hiện ở trong tệp column1 IN)

   => Kết luận: Bản thân câu query đã chậm rồi, nhưng vì việc lấy dữ liệu ban đầu chưa gặp phải column1 IN nào có dữ liệu lớn => do đó chưa phát sinh vấn đề, nhưng nếu có dữ liệu lớn vào => slow query ngay lập tức

5. Kiểm tra lại kết luận, thật vậy, thử update lại điều kiện để không sinh ra ID lớn trong column1 IN => thì thấy job chạy bình thường, CPU không nhảy đột biến.

Kết: Chúng ta cần phải khoanh vùng vấn đề, sau đó từ từ loại bỏ các dữ kiện không hợp lý => Sau đó cuối cùng, chúng ta cần confirm lại kết quả điều tra 1 lượt, để khẳng định tính đúng đắn. (Cách khắc phục update sau)

Hi các bạn, cũng lâu rồi mới ngoi lên đây viết vài dòng tâm sự chia sẻ chuyện đời, chuyện dev. Không biết bác nào giống mình không, càng già càng ngại viết lách :smiley:

Đây ra seri bài viết xung quanh vấn đề review code, rất mong các bạn đón đọc. Nói là seri, nhưng cũng chẳng có thứ tự, hãy tận hưởng nhé

• Phần 1: Trách nhiệm đến từ hai phía (P1)
• Phần 2: Trách nhiệm đến từ hai phía (P2)

Tiếp theo phần trước, chúng ta tiếp tục bàn về trách nhiệm của PR author's

Trách nhiệm của PR author’s

Như đã trình bày ở trên với các bạn, trách nhiệm đến từ 2 phía, vậy PR author's cần làm điều gì để giúp ích cho việc review code diễn ra thuận lợi hơn.

Cần có một description tốt

=> Hãy đọc nội dung này ở phần 1 nhé :hand:

Các PR nhỏ thì tốt hơn

Tại sao PR cần nhỏ?

• Review sẽ nhanh hơn: Reviewer sẽ dễ dàng dành 5, 10 phút review nếu PR nhỏ thì dễ hơn là 30 phút cho một PR lớn.
• Xem xét PR kĩ lưỡng hơn: Với những thay đổi lớn, reviewer và authors thường sẽ có xu hướng cảm thấy nản vì các comment chi tiết chuyên qua chuyển lại. Đôi khi các điểm quan trọng sẽ bị bỏ sót
• Ít khả năng xảy ra bugs: Vì bạn đang thực hiện ít thay đổi hơn, nên bạn và reviewer sẽ dễ dàng suy luận một cách hiệu quả về tác động của PR và xem liệu có thể xảy ra bugs hay không một cách tốt hơn.
• Đỡ tốn effort hơn nếu PR bị reject: Nếu bạn tạo 1 PR lớn, sau đó bị reject vì đang sai hướng đi, sẽ rất tốn công sức để làm lại
• Dễ dàng merge hơn: Làm việc trên một PR lớn tốn rất nhiều thời gian, vì vậy bạn sẽ có nhiều conflict khi merge code, và bạn sẽ phải fix conflict nhiều hơn.
• Không cần phải chờ đợi review quá lâu để có thể xử lý tiếp: Đôi lúc, 1 task của bạn rất lớn, và tách ra làm nhiều phần khác nhau. Bạn thử nghĩ xem, nếu phần PR bạn nhờ review to => tổn thời gian để chờ. Và bạn lại cần merge gấp để có thể start việc coding của mình. Quả thật là toanggg.
• Dễ dàng quay lại fix nếu có comments: Đôi lúc, bạn đang code task 3, 4 mà cần phải quay lại để fix review của task 1. Nếu PR quá lớn, sẽ rất mất thời gian để bạn nắm lại spec cũng như check lại tính đúng đắn của PR.

Chú ý rằng, reviewer có quyền reject hoàn toàn PR của bạn vì lý do duy nhất là PR quá lớn. Thông thường, vì lịch sự, họ sẽ cảm ơn đóng góp của bạn, nhưng yêu cầu bạn bằng cách nào đó tách nó thành các PR nhỏ hơn. Đương nhiên, có thể nó sẽ tốn nhiều thời gian và công sức. Vậy nên tốt nhất là hãy tách các PR đủ nhỏ ngay từ đầu.

Thế nào là PR nhỏ

Nhìn chung, PR vừa đủ để tiện cho việc review thường là sẽ thực hiện một chức năng duy nhất, riêng biệt. Điều đó có nghĩa là:

• PR thực hiện một chức năng duy nhất. Đây thường chỉ là một phần của một task thay vì toàn bộ task đó. Nếu có thể, hãy làm việc với reviewer trước để có thể đi đến thống nhất.
• PR nên bao gồm cả UnitTest
• Mọi thứ mà reviewer cần để hiểu về PR của bạn như description, codebase hiện tại, hoặc các PR khác tương tự, ...
• Các PR cũng không nên quá nhỏ, khi đó nó sẽ rất khó hiểu. Nếu được, bạn hãy đính kèm documents để tiện cho việc review.

Thực sự thì không có quy tắc cố định nào quy định về việc một PR thế nào là đủ nhỏ. hoặc quá lớn. Nhưng có một vài số liệu chung như

• 100 lines change thường là kích thước hợp lý
• 1000 lines change thường là kích thước quá lớn.
• 200 lines change trong một file thường không sao, nhưng nếu có nhiều files như vậy thì sẽ là quá lớn.

Khi nào PR to có thể được chấp nhận

Trong một vài trường hợp, PR to có thể chấp nhận được như

• Bạn có thể coi rằng việc xóa files nào đó là 1 line change, vì thường thì reviewer sẽ không mất nhiều thời gian để xem xét chúng
• Đôi khi, bạn có các PR về việc refactoring code mà được xử lý tự động bằng 1 vài tools có thể tin tưởng được. Mặc dù là PR lớn, nhưng chúng ta có thể chấp nhận điều này, đương nhiên, cho dù vậy, chúng ta vẫn cần các bước y hệt 1 PR bình thường như testing.

Refactoring nên là 1 PR riêng biệt

Thông thường, chúng ta nên tách riêng PR cho việc xử lý spec mới, và refactoring nếu chúng đủ to để tách. Đừng nên quá cứng nhắc trong việc này. Ví du như các bước bỏ như sửa tên biến trong phạm vi nhỏ, hay chính sửa logic cũ cần thiết để có thể đáp ứng được spec thì cũng không cần thiết phải tách ra. Đừng để việc refactoring ảnh hưởng tới tiến độ của task.

PR nên có đẩy đủ cả UnitTest

Hãy nhớ rằng, PR nhỏ ở đây có nghĩa là nên tập trung vào một hoặc vài chức năng liên quan được chấp thuận, chứ không phải chỉ là vài dòng thay đổi thì được gọi là nhỏ.

Hãy luôn bảo đảm rằng code của mình đã có UnitTest, cho dù đó là thay đổi nhỏ nhất.

Phải làm gì nếu không thể tách nhỏ PR?

Đôi khi bạn gặp phải một vài tính huống dẫn đễn việc PR bắt buộc phải lớn. Điều này rất hiếm khi xảy ra. Các developer hầu như luôn có thể tìm ra cách để tách nhỏ các PR

Trước khi xử lý một PR lớn. hãy xem xét đến việc refactoring trước có giúp cho việc triển khai PR tốt hơn không? Hoặc đơn giản hơn là nói chuyện trao đổi với reviewer hoặc đồng nghiệp của bạn để tìm giải pháp

Nếu tất cả những điều trên không thể thực hiện, thì ít nhất hãy thông báo cho reviewer của bạn để có được sự đồng ý từ họ, cũng như giúp cho họ chuẩn bị đễ review 1 PR lớn. Nếu điều này xảy ra, hãy hiểu rằng, PR của bạn sẽ được review trong một thời gian dài.

Xử lý feedback, comments của reviewer

Đương nhiên, đã review thì thường sẽ có comment, mà đã có comment thì sẽ phải giải quyết. Dưới đây là một số điều hữu ích cần biết về việc xử lý comments của reviewer

Đừng coi việc review là công kích cá nhân.

Nên nhớ rằng, mục tiêu của việc review code là làm cho codebase tốt lên. Khi reviewer review và đưa ra comments về code của bạn. Hãy hiểu rằng đó hoàn toàn là vấn đề công việc. Không có ý công kích cá nhân gì ở đây cả. Hãy hạ cái tôi của mình xuống, luôn đón nhận với tâm thế học hỏi.

Đừng bao giờ trả lời, hay phản ứng review code một cách tức giận !

Fix the Code

Đương nhiên, phần lớn chúng ta đều phải fix comments code. Không ai tránh khỏi việc này. Nên hãy chắc chắn rằng

1. Đừng bao giờ lặp lại lỗi tương tự như vậy nữa.
2. Hãy cố gắng làm code của bạn dễ hiểu nhất đối với reviewer => Vì chúng ta cần hiểu rằng, code của chúng ta sẽ sử dụng lại vào thời điểm sau này bởi bất kì ai.
3. Hãy chắc chắn rằng mình chạy lại UnitTest, hay self-test, hoặc check lại PR ít nhất 1 lần trước khi gửi lại cho reviewer.
4. Hãy nhớ rằng, không phải tất cả các comment cần phải fix, hay kiểm chứng lại, hoặc hỏi lại reviewer của mình để cùng đưa ra hướng đi tốt nhất.

Tổng kết

Qua bài viết này chúng ta rút ra được những điều gì?

1. Tách nhỏ các PR nếu có thể, tránh để PR quá to và nhờ người khác review.
2. Hãy mang tâm thế học hỏi, đừng coi việc comment code là công kích cá nhân.
3. Đừng trả lời comment trong khi tức giận.

Thực sự thì, việc review code là một cách tốt nhất để học hỏi kinh nghiệm từ ai đó. Bạn nên mang trong mình tâm thế học hỏi khi nhờ người khác review, và có comment lại, cho dù đó là người có level cao hơn hay thấp hơn mình.

Hãy chờ đón phần tiếp theo nhé. Nêu có bất kì thắc mắc gì cần giải đáp, hoặc góp ý cho mình, thì hãy comment ở dưới nhé. Cảm ơn các bạn đã đọc bài viết đến đây.

@hoangpn - Better every day!

Hi các bạn, cũng lâu rồi mới ngoi lên đây viết vài dòng tâm sự chia sẻ chuyện đời, chuyện dev. Không biết bác nào giống mình không, càng già càng ngại viết lách :smiley:

Đây ra seri bài viết xung quanh vấn đề review code, rất mong các bạn đón đọc. Nói là seri, nhưng cũng chẳng có thứ tự, hãy tận hưởng nhé

• Phần 1: Trách nhiệm đến từ hai phía (P1)
• Phần 2: Trách nhiệm đến từ hai phía (P2)

Xuất phát từ tâm lý chung, mà phần lớn các dev đều có suy nghĩ là, thôi cứ code xong, đẩy PR cho ông senior nào đấy review, ổng comment, mình sửa, ezz game. Miễn sao mà code cho chạy đúng là được.

Chuẩn không cần chỉnh, mà chỉnh càng chuẩn. Nói chứ mình cũng 1 thời mang suy nghĩ như thế, chắc do là dev lâu nên tính xấu tích tụ, suy bụng ta ra bụng người. Không biết có bác nào như mình không? :sweat_smile:

Thực tế thì, trách nhiệm cần đến từ 2 phía, cả từ tạo PR, và cả người review. Tại sao lại thế? Trước khi đi vào câu hỏi trên, hãy cũng mình ôn lại 1 số khái niệm cơ bản nhé.

Tổng quan về review code

Đầu tiên, các bạn cũng mình lướt qua 1 vài khái niệm chính nhé

Review code là gì?

• Là quá trình mà các lập trình viên xem xét và đánh giá code của một thành viên khác trong nhóm
• Đồng thời cũng là quá trình thảo luận, đưa ra những góp ý nhằm giúp các đoạn code thêm chất lượng hơn.

Đương nhiên rồi, qua 2 gạch đầu dòng nhỏ bên trên (hoặc chẳng cần :cry: ) Chúng ta có thể hiểu rằng, review code là 1 bước trong quá trình phát triển phần mềm, mà ở đó, chúng ta cùng xem xét 1 đoạn code, và làm cho nó tốt lên.

Vậy câu hỏi đặt ra ở đây, tại sao chúng ta lại thường xuyên mất thời gian vào đó?

Lợi ích của review code

Review code có rất nhiều lợi ích, mình chỉ tóm gọn lại vài ý chính như sau:

Về cá nhân:

1. Nâng cao trình độ bản thân của mỗi cá nhân
2. Học cách truyền đạt và góp ý cho người khác, cũng như kiểm chứng lại kiến thức của chính mình.

Về dự án:

1. Các member nắm bắt được những gì diễn ra trong dự án
2. Là một bước quan trọng để giảm thiểu lỗi phát sinh
3. Đương nhiên, giúp cho chất lượng của code tốt lên => làm cho codebase tốt lên, chất lương dự án tốt hơn

Trách nhiệm của PR author’s

Như đã trình bày ở trên với các bạn, trách nhiệm đến từ 2 phía, vậy PR author's cần làm điều gì để giúp ích cho việc review code diễn ra thuận lợi hơn.

Cần có một description tốt

Đầu tiên, chúng ta cần hiểu rằng, PR cần được mô tả về những gì nó làm, và tại sao nó lại làm như thế. Nó sẽ được lưu lại, và sẽ được hàng trăm developer khác xem sau đó.

Các bạn nên nhớ và có ý niệm về việc mình không chỉ code cho 1 mình mình, không chỉ code cho 1 mình ông reviewer, mà là code cho các developer sau đó nữa - người mà có khi bạn còn chẳng biết là ai. Nên hãy hiểu rằng, từng PR, từng description sẽ là thông tin rất quan trọng để thông báo cho họ rằng, PR của mình làm cho spec A, B, C, ...

First Line

• Tóm tắt ngắn gọn về những gì đang thực hiện
• Câu hoàn chỉnh, được viết như một khẳng định
• Dưới nó nên là một break line

Dòng đầu tiên của PR nên là một bản tóm gọn lại những gì PR đnag thực hiện, nên có một break line ngay sau đó, giúp cho người đọc có thể nắm được ý chính nhanh nhất có thể

Cố gắng giữ cho dòng đầu tiên ngắn gọn, tập trung đi vào trọng tâm. Tránh dài dòng, vòng vo, hoặc quá tối nghĩa.

Ví du:

# Bad
Deleting filter in users

# Good
Delete filter in users

Body is Informative

Trái ngược với first line - ngắn gọn súc tích. Thì phần nội dung còn lại của description cần phải mô tả thông tin chi tiết và bao gồm bất ký thông tin bổ sung nào mà người đọc cần để hiểu tổng thể về PR.

Nó có thể bao gồm một mô tả ngắn gọn về vấn đề đang được giải quyết và lý do tại sao đây là cách tiếp cận tốt nhất. Nếu có bất ký thiếu sót vào đối với cách tiếp cận của bạn thì chúng cần được đề cập tới. Nếu được hãy note thêm các trạng thái trước đó như số bugs, kết quả benchmark, và link đến design documents.

Nếu bạn có đính kèm các link bên ngoài, hãy cân nhắc rằng chúng có thể không hiển thị với người đọc trong tương lai do nhiều lý do. Nếu có thể hãy cố gắng trình bày sao cho người đọc sau có thể hiểu được.

Cần chú trọng điều này ngay cả cho các PR nhỏ

Bad PR Descriptions

Dưới đây là một vài ví dụ về bad descriptions

“Fix build.”

“Add patch.”

“Moving code from A to B."

“Phase 1.”

“Add convenience functions.”

“kill weird URLs.”

Good PR Descriptions

Dưới đây là một vài ví dụ về good descriptions

Functionality change

rpc: remove size limit on RPC server message freelist.

Servers like FizzBuzz have very large messages and would benefit from reuse. Make the freelist larger, and add a goroutine that frees the freelist entries slowly over time, so that idle servers eventually release all freelist entries.

Refactoring

Construct a Task with a TimeKeeper to use its TimeStr and Now methods.

Add a Now method to Task, so the borglet() getter method can be removed (which was only used by OOMCandidate to call borglet’s Now method). This replaces the methods on Borglet that delegate to a TimeKeeper.

Allowing Tasks to supply Now is a step toward eliminating the dependency on Borglet. Eventually, collaborators that depend on getting Now from the Task should be changed to use a TimeKeeper directly, but this has been an accommodation to refactoring in small steps.

Continuing the long-range goal of refactoring the Borglet Hierarchy.

Small PR cũng cần có description hoàn chỉnh

Create a Python3 build rule for status.py.

This allows consumers who are already using this as in Python3 to depend on a rule that is next to the original status build rule instead of somewhere in their own tree. It encourages new consumers to use Python3 if they can, instead of Python2, and significantly simplifies some automated build file refactoring tools being worked on currently.

Generated PR descriptions

Hẫy cân nhắc đến việc generate tự động các description bằng cách sử dụng các tools. Bằng cách nào cũng nên tuân thủ các quy tắc ở bên trên.

Review the description before submitting the PR

Các PR có thể thay đổi đáng kể qua quá trình review, fix bug, ... Vì vậy, bạn nên xem lại description một lần trước khi submit PR, hoặc có bất kì commit gì đó thay đổi. Mục đích để đảm bảo rằng description mô tả đúng những gì PR thực hiện

Tổng kết

Qua bài viết này chúng ta rút ra được những điều gì?

1. Trách nhiệm của PR đến từ cả 2 phía, đừng phụ thuộc, ỉ lại quá nhiều vào reviewer.
2. Mục đích chung của Review code là giúp cho codebase tốt hơn (đương nhiên là sẽ đi theo PR phải thực hiện đúng chức năng mong muốn)
3. Hãy có một description tốt.

Hãy chờ đón phần tiếp theo nhé. Nêu có bất kì thắc mắc gì cần giải đáp, hoặc góp ý cho mình, thì hãy comment ở dưới nhé. Cảm ơn các bạn đã đọc bài viết đến đây.

@hoangpn - Better every day!

Hi các bạn, mình là Hoàng đây, vẫn là mình sau 1 thời gian ăn no ngủ kĩ sau tết. Giờ ngoi lên xem công nghệ thế giới chuyển biến thế nào rồi

Chẳng là, mình có 1 con blog viết bằng Rails, nhưng vì nghèo, nên không có tiền chạy vps => Đã đến lúc phải làm điều gì đó cho đứa con tinh thần của mình rồi Okay, let start :grinning::grinning:

Đầu tiên, đối với mình hiện tại, thì tiêu chí của mình đối với 1 con blog là

1. Chi phí chạy nó rẻ nhất có thể(dành cho bác nào nghèo như mình)
2. Tốc độ truy cập trang nhanh
3. Viết thêm một bài mới đơn giản

Ý nghĩ đầu tiên lóe lên trong đầu mình là github pages, vâng, github pages - Cái thứ mà ít nhất mỗi dev đều thử nó một lần, thấy được một cái trang web của mình làm ra nhanh chóng, tiện lợi thì đều rất thích thú mà :heart_eyes::heart_eyes:

Đối với thằng github pages thì thậm chí bạn chẳng phải mất tiền thuê vps hay hosting nữa, trang github pages của bạn sẽ bất tử(cho đến khi nào github bỏ tính năng này thì thôi :) )

Ok đã xong được thằng tiêu chí 1 rồi. Khổ nỗi, mình lại là thằng chúa lười(may mà vẫn có người yêu). Giờ nghĩ, lại code lại như con rails blog trước thì thôi cũng quá tôi => Nhanh trí nghĩ ngay ra dùng các theme mà github pages hỗ trợ. Việt Nam nói là làm, nhanh tay lấy cuộn giấy bàn phím gõ gõ vào việc ngay. Sau 1 hồi tìm kiếm thì thấy thằng github pages nó chỉ support luôn Jekyll thôi, mà mấy cái template của thằng này lại xấu xí quá trong khi đó tính mình yêu cái đẹp, thích màu hồng nên phải đi đường khác rồi.

Tiếp tục công cuộc tìm với tiêu chí 2. Mình nghĩ ngay đến mấy cái static pages đang thịnh hành cho việc viết blog đơn giản. Nhanh tay, tìm ngay vài thằng cộm cán như sau

1. HUGO
2. GatsbyJS
3. Vuepress

Còn vài thanh niên nữa nhưng nổi lên nhất là 3 cháu này, xịn xò, theme thì không thiếu. Nhưng cá nhân mình lại là con nghiện của VueJS thế mới chết, nên đành ngậm ngùi chia tay 2 em HUGO và Gastby mà chọn Vuepress thôi. Nói thật ra là quen tay dùng VueJS nên có gì còn có thể kịp trở tay được :).

Note: Bạn nào quen dùng react thì nên dùng GatsbyJS. Thằng này cũng khá xịn xò tay to các thứ các thứ đấy

Qua quá trình tìm kiếm qua thằng bạn thân google, thì mình chốt được 2 cái

1. Dùng github pages
2. Dùng Vuepress

Loanh quanh 1 hồi thì đúng là vuepress không làm mình thất vọng, template của thằng này thì nói thật không thiếu, bạn chỉ cần chọn cái thích hợp với mình thôi. Việc còn lại để vuepress lo :joy::joy:

Note: Các bạn có thể tham khảo thêm các theme của vuepress ở đây nhé

Thêm nữa là việc viết 1 bài mới đối với những thằng kể trên là dùng markdown nhé, rất quen thuộc với mọi dev, và có thể tha hồ đăng bài ở các diễn đàn khác nhau(vì cơ bản giờ toàn dùng md để viết mà). Đối với bản thân mình thì khá dễ sử dụng :heart_eyes::heart_eyes:

Okay, bắt tay vào xây dưng blog của mình thoai nào(Sau khi đã chọn đươc vuepress làm điểm tựa :) )

1. Instal Vuepress
2. Chọn theme
3. Kiểm tra thành quả
4. Deploy to Github Pages
5. Setup Auto build
6. Các vấn đề khác

Instal Vuepress

Các bạn cứ tham khảo trang chủ của nó là ra ngay ý mà

// https://vuepress.vuejs.org/guide/getting-started.html#prerequisites

yarn create vuepress-site

OK chạy thử phát xem nó dư nào nào

yarn install
yarn run dev

Kết quả luôn

Ra luôn, vâng ra luôn, rất nhanh ae ạ, nói chung là hịn hò

Chọn theme

Mình là người yêu cái đẹp thích màu hồng, mình không hài lòng với cái theme mặc định này lắm, nghĩ bụng, phải làm sao để cho nó đẹp hơn thôi, chứ cứ thế này không được.

Mình là người Việt Nam, mà Việt Nam nói là làm, không chần chừ lên ngày awesome-vuepress để kiếm theme cho em nó. Sau nhiều hồi lựa chọn giữa các em với nhau, mình đã chọn được 1 em khá vừa lòng là em này - Và chính nó cũng thành blog của mình luôn :heart_eyes::heart_eyes::heart_eyes:

Chọn được rồi thì cài đặt thôi nhể :) https://github.com/ttskch/vuepress-theme-blog-vuetify/

$ yarn add --dev vuepress-theme-blog-vuetify

# or
$ npm install -D vuepress-theme-blog-vuetify

Sử dụng

// .vuepress/config.js
module.exports = {
  theme: 'blog-vuetify',
  themeConfig: {
    // ...
  }
}

Đơn giản như đan rổ, làm ngay và luôn

Kiểm tra thành quả

Sau vài hồi config các thứ, run localhost:8080 và mình đã có được cái blog như hiện tại trên kia kìa :)

Deploy to Github Pages

Đến đây thì về cơ bản là đã xong rồi, làm thêm vài bước config nữa thôi

1. Tạo repo github, để public nhé(public mới vào việc với github pages được)
2. Push code lên thôi
3. Setting gh-pages

Setup Auto build

Đến đây thì lại nảy sinh một vấn đề là, ơ thế code mình như này, github pages chơi thế éo nào được, nào là md, nào là package.js :)

=> Chúng ta cần phải build nó trước khi push lên github thôi. Mà vốn bản tính lười, chẳng nhẽ lần nào viết xong bài mới là lại build à, chán. Nghĩ ngay đến github actions => một công nghệ mà mới đây(chẳng qua lâu rồi mà mình không hay dùng) mới tích hợp vào github. Nhanh tay search ngay làm sao tự động build vuepress cho github pages. Ui xời, quả là trời không phụ lòng người, ra ngay được https://github.com/marketplace/actions/vuepress-deploy. Thôi là lại một nốt nhạc nữa :))

Test ngay cho nóng

Ngon luôn, bật ngay github pages check thôi, và thành quả đơn giản là https://hoangpn.com/

Các vấn đề khác

Sơ sơ là thế, các bạn có thể nắm được và bắt tay xây dựng web được rồi. Tuy nhiên có 1 số lưu ý sau

Đối với việc setup token cho auto_deploy

name: Deploy to GH Pages
on: [push]
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout
      uses: actions/checkout@master

    - name: Build and Deploy
      uses: jenkey2011/vuepress-deploy@dev
      env:
        ACCESS_TOKEN: ${{ secrets.ACCESS_TOKEN }}
        TARGET_REPO: hoangpn256/hoangpn.github.io
        TARGET_BRANCH: gh_pages
        BUILD_SCRIPT: yarn && yarn build
        BUILD_DIR: src/.vuepress/dist/

Để ý rằng có biến secrets.ACCESS_TOKEN -> đây là access token của tài khoản github của bạn. Để lấy được nó hãy làm theo hướng dẫn sau đây

Đối với việc chia thư mục viết bài

Các bạn có thể tham khảo cấu trúc và config ở repo của mình.

Lưu ý các bài viết sắp xếp theo phần date

Đối với vấn đề setup domain cho github pages

Thêm file CNAME vào phần public trong source code

Thêm CNAME nếu bạn dùng sub-domain của mình cho github pages, hoặc A-record nếu bạn dùng chính domain của mình cho gh-pages

Có thể tham khảo thêm tại đây

Trên đây là cấu hình của mình

Kết

Okay, cơ bản thế là xong rồi đấy, chốt lại 1 số vấn đề như sau

1. Dùng vuepress để xây dựng blog
2. Dùng github pages để host đến chết :)
3. Dùng github actions để auto build
4. Một số cấu hình về github pages và config của dự án cần lưu ý(tham khảo repo của minh nhé - nhớ start nha :heart_eyes::heart_eyes: )

Nêu có bất kì thắc mắc gì cần giải đáp, hoặc góp ý cho mình, thì hãy comment ở dưới nhé. Cảm ơn các bạn đã đọc bài viết đến đây.

Ủng hộ mình với bài viết gốc tại đây

@hoangpn - Better every day!

Foreword

Đối với data khai báo là một function trả về object.

// Define a new component called button-counter
Vue.component('button-counter', {
  data: function () {
    return {
      count: 0
    }
  },
  template: '<button v-on:click="count++">You clicked me {{ count }} times.</button>'
})

<div id="components-demo">
  <button-counter></button-counter>
  <button-counter></button-counter>
  <button-counter></button-counter>
</div>

new Vue({ el: '#components-demo' })

Đối với data được khai báo là một object

data: {
  count: 0
}

Như chúng ta thấy thì sự khác nhau rõ ràng nhất là: Nếu khai báo data là object, thì data sẽ bị dùng chung bởi các instance của component đó. Đây là điều chúng ta trong phần lớn trường hợp là không hề mong muốn.

Core concepts

• Vue làm việc với component, và component trong Vue phần lớn là static.
• Một Vue component định nghĩa các methods, computed, ..., và nó được chia sẻ giữa tất cả các instance của component đó trong toàn bộ ứng dụng. Khi Vue cần sử dụng các methods đối với một instance cụ thể nào đó của component, nó sẽ apply()s chúng để lấy đối tượng thích hợp là this

Reason: Saving Memory

• Rất nhiều frameworks như angular 2, hoặc đôi khi là react sẽ tạo mỗi một instance của một component là một đối tượng riêng biệt.
• Angular 2 là trường hợp tệ nhất, trong đó mọi component là instance của một class, điều này nghĩa là mọi thứ mà component có bên trong sẽ được khởi tạo lại cho mọi component. Tuy nhiên, với mỗi instance của các component, chúng ta chỉ thực sự cần data là riêng biệt, còn các methods, định nghĩa về computed, watcher, .. vẫn như cũ.
• Vue làm được điều này bằng cách là khai báo data là một function trả về một object. Điều đó cho phép các component riêng biệt có các trạng thái riêng của nó (dữ liệu) mà không cần phải khởi tạo lại toàn bộ component. Các methods, định nghĩa về computed, ..., và các life cycle hook chỉ cần một lần tạo ra và lưu trữ, sau đó có thể sử dụng trên mọi instance của component đó.

Reason: Static Components

• Vue 2 hoàn toàn bao hàm các ý tưởng về static component nhanh, nhẹ. Chúng không có các trạng thái dữ liệu bên trong và thường được hiển thị một lần hoặc chỉ thay đổi trạng thái bên ngoài. Điều này cho phép các chức năng của component là cưc kỳ nhanh.
• Để tận dụng tính năng này bạn có thể sử dụng v-once để render thuộc tính một lần trong template, hoặc khai báo component hoạt động với functional: true trong định nghĩa của nó.

Potential Confusion

• Những người mới sử dụng Vue thường thấy rằng chúng ta khai báo dữ liệu trong data, methods trong methods, thuộc tính tính toán trong computed, ..., tất cả chúng đều được truy cập trên this.thing thay vì sử dụng this.type.thing (ví dụ this.myMethod() thay vì this.methods.myMethod() )
• Điều này, một lần nữa, là bởi vì các định nghĩa component chỉ đơn giản là định nghĩa mà thôi. Vue cần các định nghĩa về computed, methods, props, data, ... để có thể biết cách xây dựng component, nhưng để thuận tiện, nó ánh xạ chúng đên root của component thay vì các thuộc tính đó

Conclusion

• Vue sử dụng khai báo data bằng function trả về một object thay vì một object.
• Các methods, computed, watcher, props, life cycle hook chỉ một lần tạo ra và được lưu trữ lại để dùng chung cho mọi instance của computed.

Rất mong góp ý của các bạn để có thể cải thiện chất lượng bài viết.

Best regards,

Không quá dài dòng nữa, đấy là pair programing

Nội dung

Cùng theo tôi trả lời những câu hỏi sau, để bạn có thể hiểu được cái gì là pair programing nhé

1. Pair programing là gì?
2. Pair programing có thể làm được những gì?
3. Cách thực hiện của pair programing
4. Khi nào thì dùng, và một số điểm lưu ý
5. Kết luận, ý kiến của bản thân mình.

Pair programing là gì ?

Pair programing hay còn được gọi là pairing, programing in pair về cơ bản là một kỹ thuật phát triển phần mềm. Thường được thấy là việc 2 cá nhân cùng làm 1 task trên cùng một máy tính.

Cũng từ đó có 2 vai trò tương ứng là Driver và Navigator, Driver có trách nhiệm viết code, trong khi công việc của navigator là theo dõi driver, đưa ra lời khuyên và cố gắng hiểu và truyền đạt được bức tranh tổng thể của task đó cho driver. Hai vai trò này có thể được hoán đổi cho nhau trong khoảng thời gian thường xuyên.

Pair programing làm được gì? (ích lợi)

Theo cá nhân tôi, lợi ích được chia cho 2 đối tượng là Con người và Dự án

Con người

• Cải thiện vấn đề teamwork. Khi pair code, chúng ta nên, hay nói nặng nề hơn là cần trao đổi với nhau. Việc này thực sự giúp cho các member hiểu nhau hơn, từ đó vấn đề teamwork cũng được nâng cao.
• Trau dỗi kĩ năng của mỗi người tốt hơn. Khi pair code, chúng ta sẽ có được góc nhìn khác nhau từ 2 người, cũng như các kiến thức, kĩ thuật khác nhau để trao đổi. Đặc biết là nếu bạn được một người có trình độ cao hơn pair code cùng. => Kĩ năng của cả team cùng được phát triển lên.
• Độ tập trung, sự tự tin và độ hài lòng của các thành viên được cải thiện rất nhiều. Chúng ta có thể thấy rằng, nếu có người pair code cùng thì chúng ta sẽ ít xao nhãng hơn, ít check fb, instagram hơn , .. vì chúng ta không muốn làm người đồng hành của mình thất vọng do đó độ tập trung chắc chắn sẽ cải thiện rõ ràng. Và việc được code cùng với người khác như thế, có thể làm cho bạn thấy thú vị hơn, vui vẻ hơn => giúp cải thiện độ hài lòng của mình tốt hơn. Và bạn sẽ dần dần tự tin hơn vào bản thân cũng như kiến thức của mình có.
• Tăng cường khả năng giải quyết vấn đề. Bạn đã bao giờ nghe đến kĩ thuật Rubber Ducking - giải thích cho con vịt hiểu code của mình chưa. Khi pair code, chúng ta cần giải thích code của mình cho người đồng hành hiểu được. Việc này cũng mang lại kết quả tưởng tự như Rubber Ducking => giúp bạn hiểu rõ và có thể sẽ ra được cách giải quyết vấn đề mà chính bạn không ngờ tới đấy :)

Dự án

• Chất lượng code của dự án được nâng cao hơn( code ít bug hơn, unit test phủ kín hơn, code clean hơn). Vì sao lại thế? Đơn giản thôi, 2 cái đầu thì sẽ thường hơn 1 cái đầu. Khi pair code với nhau, chúng ta có thể dễ dàng phát hiện ra những sai sót của nhau, hay đưa ra cách giải quyết vấn đề tốt hơn, ...
• Thời gian giải quyết công việc tốt hơn. Hơi lạ nhỉ, thường thì mỗi người 1 việc sẽ nhanh hơn 2 người 1 việc chứ nhỉ. Nhưng trên thực tế cho thấy, đối với pair programing giúp giải quyết công việc nhanh hơn. Đối với một task khó, thì việc có 2 người cùng suy nghĩ sẽ nhanh hơn rất nhiều đối với một người.
• Khi pair code, chúng ta sẽ hiểu dự án kĩ càng hơn, việc này rất quan trọng, nó giúp cho dự án sẽ phát triển nhanh hơn đáng kể đấy.

=> Từ những điều trên, chúng ta có thể kết luận ở đây rằng, pair programing giúp cho dự án hoạt động tốt hơn, tiết kiệm thời gian, chi phí.

Cách thực hiện của pair programing?

Chúng ta có thể phân chia làm 2 loại là Trình độ và Kiểu

Trình độ

1. Người có kinh nghiệm cao hơn - người có kinh nghiệm ít hơn (có thể hiểu như là senior - junior, junior - fresher, ...). Đây dường như là sự kết hợp tuyệt với để tăng tốc độ học tập cho các bạn có level thấp hơn. Cũng là cách tốt để chia sẻ kinh nghiệm trong toàn team, nhưng hãy để ý đến sự cân bằng, Ví dụ pair giữa junior-senior, nếu không tốt thì junior chỉ là người xem cho đến hết task :) Chẳng tiếp thu được gì cả. Hay senior có thể cảm thấy khó chịu khi tốc độ của mình bị chậm đi khi cứ phải giải thích với junior chẳng hạn.

2. Người có trình độ level tương đương nhau (có thể hiểu là junior - junior, ...). Sự kết hơp này cũng cải thiện đáng kể năng suất và chất lương. Vì trình độ tương đương nhau, nhưng có cái người này biết, người kia không biết, ....

Kiểu

Driver-navigator là kiểu thường được thấy nhất, cả 2 đổi vai trò cho nhau => để output là một kết quả tốt nhất. Nhưng cũng gặp phải một số khó khăn như sau

• Driver tập trung code, và navigator không muốn làm phiền
• Hoặc khi driver bảo "đợi tí nhé" => Nagivator sẽ rảnh và khả năng cao là cũng bị xao nhãng bởi việc check fb, instagram, ....

Nói chung, để pair programing thành công được, thì mấu chốt là sự tôn trọng nhau, và giao tiếp của 2 người. Đáng tiếc là điều này thường khó thực hiện đối với các cặp mới.

Từ đó sinh ra một số kĩ thuật khác mà bản thân tôi cho rằng nên bắt đầu từ đó đối với các cặp mới như sau

Strong & Traditional Pairing Techniques

Kim chỉ nam của kỹ thuật này là "Driver sẽ không làm gì cho đến khi có sự hướng dẫn của navigator"

Bất cứ khi nào driver yêu cầu navigator giải thích về ý tưởng, thì navigator cần phải giải thích rõ ràng về việc đó, và sau đó thì đơn giản là quay về vị trí quan sát.

Ping-Pong Pairing

Kỹ thuật này thường được sử dụng khi xử lý unit test. Bắt đầu bằng việc người đầu tiên viết 1 test fail, và chuyển giao nó cho người thứ 2, người thứ 2 sẽ phải hoàn thành test fail đó, đồng thời viết thêm 1 test fail khác và chuyển giao lại cho nguời thứ 1. Cứ lặp lại cho đến khi coverage được phủ hết.

Khi nào thì dùng, và một số điểm lưu ý

Khi nào thì dùng?

Theo bản thân tôi thấy thì chúng ta sẽ dùng pair programing trong những trường hợp sau:

• Khi có 1 task phực tạp, hoặc một PR quá lớn.
• Khi coaching
• Khi fixing
• Hoặc đơn giản là muốn nâng cao trình độ các member trong team lên.

Túm đoạn này lại, hãy tìm thời điểm thích hợp để sử dụng, bắt đầu bằng thời điểm gợi ý như trên. Khi bạn đã có kinh nghiệm về vấn đề này rồi, thì đừng ngần ngại đề xuất sử dụng nó khi cần thiết nhé.

Những lưu ý?

• Công bằng, hãy nhớ vai trò của 2 người là như nhau.
• Hạ cái tôi xuống, tôn trọng nhau và tiếp thu ý kiến của đối phương.
• Hãy tin tưởng bạn đồng hành của mình.
• Đừng ép buộc
• Cho đối tác của bạn có cơ hội để "lái" vào đúng thời điểm
• Khuyến khích việc giao tiếp cởi mở.
• Đừng bỏ qua những khoảng nghỉ ngơi
• Xác định những sai lầm của bạn
• Nhận lỗi trước
• Bình tĩnh lại, đừng vội vàng

Trong khi paring, chúng ta có một số điểm sau cần chú ý

• Để tôi code cho
• Bạn có thể giúp tôi ?
• Cùng quẩy thôi
• Tôi định làm theo hướng như này, bạn nghĩ sao về nó ?
• Bạn có hướng giải quyết nào không ?
• Đoạn code này chạy thế nào đấy, viết unit test nhé.
• Tôi không hiểu ý bạn lắm, bạn có thể giải thích rõ hơn không ?
• Heeyyy, chúng ta có quên điều gì không nhỉ ?

Take a break

• Chúng ta nghỉ chút nhỉ
• Hey, tôi nghĩ nên đổi vai trò chút
• Yoo, ra làm cốc cafe đi.

Kết luận, ý kiến của bản thân mình.

Trên thực tế, pairing đã mang lại rất nhiều lợi ích. Vì thế lợi ích của paring là không thể phủ nhận được.

Nhưng, liệu rằng pair programing có phù hợp với tất cả mọi người không? Thực sự câu trả lời không đơn giản cho vấn đề này. Tất cả chúng ta khác nhau, vì vậy chắc chắn sẽ có những kết quả khác nhau., Pair programing rất hiệu quả với một số người, nhưng một số người thì không.

Hãy nhớ rằng, pair programing không phù hợp với mọi dự án

Theo quan điểm của tôi thì bản thân phương pháp nào cũng vậy, không có xấu tốt gì cả, chỉ đơn giản là nó có phù hợp trong thời điểm đó hay không thôi. Pair programing cũng vậy. Nhưng nên nhớ rằng, nếu không thử, thì sao biết được đúng không ?

Cuối cùng, cảm ơn bạn đã đọc đến cuối. Bất kỳ ý kiển gì hãy comment ở dưới nhé. :point_down::point_down::point_down:

Hãy ủng hộ mình bằng upvote. để mình có thể cải thiện và đưa ra những bài mới tốt hơn nhé.

@hoangpn - Better every day!