Home Blog Page 123

Phân biệt các thuật ngữ trong Distributed System (Tập 1)

System Design

Bài viết được sự cho phép của tác giả Edward Thiên Hoàng

Trong một hệ thống phân tán hiện đại ngày nay cùng với việc move lên Cloud thì có rất nhiều thuật ngữ, từ ngữ mô tả về hệ thống rất dễ gây nhầm lẫn như High Availability, Redundancy, Resiliency, Fault Tolerrance, Failover,… Hãy cùng phân tích và so sánh các thuật ngữ đó để có thể dùng chúng chính xác hơn trong từng ngữ cảnh.

  Bài toán đồng thuận trong Distributed Systems
  Distributed cache là gì? – điều gì khiến nó trở nên mạnh mẽ?

HIGH AVAILABILITY – TÍNH SẴN SÀNG CAO

High Availability (HA) hay còn gọi là Tính Khả Dụng/Sẵn Sàng Cao. Từ này gặp rất nhiều khi làm việc với các Cloud Service để đề cập đến việc 1 hệ thống hay service đó có tỷ lệ sống sót là bao nhiêu % trong 1 khoảng thời gian. Ví dụ nếu nói hệ thống có HA = 99% thì tức là sẽ có downtime (thời gian chết) là 3.65 ngày trong 1 năm, 7.31 giờ trong một tháng, 14.4 phút trong 1 ngày. Thời gian downtime có thể là do hệ thống cần được tắt để bảo trì nâng cấp hoặc bị cúp điện chẳng hạn. Vậy làm thế nào để có thể tăng tính HA cho hệ thống? Ví dụ có 1 số service sẽ có SLA (Service Level Agreement) hay Cam kết chất lượng dịch vụ cho HA lên đến 9 số 9 ( 99.9999999%) hoặc như DNS service sẽ có HA = 100%. Tất nhiên để HA càng cao thì chi phí càng đắt. Do đó, trong mỗi hệ thống cần suy nghĩ xem HA bao nhiêu là vừa đủ. Để làm được điều này thì chúng ta sẽ cần áp dụng một số kỹ thuật như redundancy, replication, zero-downtime deployment, fail-over,…

RELIABILITY – ĐỘ TIN CẬY

Một hệ thống có độ tin cậy cao thì HA sẽ cao, nhưng ngược lại không đúng. 1 hệ thống có khả năng sẵn sàng cao không có nghĩa là một hệ thống ưu việt. Ví dụ có con server đang sống và nhận, xử lý request đều đều, bỗng dưng không hiểu vì sao mà thời gian xử lý request mỗi lúc một lâu, có khi timeout luôn. Thì khi đó mặc dù ta nói HA vẫn cao nhưng độ tin cậy lại thấp.

Thật ra khi làm system design, mình chỉ hay chú ý đến High availability mà ít khi nghĩ đến tính Reliability. Phần này mình sẽ dựa theo Reliability pillar, một trong 5 pillars được định nghĩa trong AWS Well-Architected Framework.

Reliability is the ability of a system to recover from infrastructure or service disruptions, dynamically acquire computing resources to meet demand, and mitigate disruptions such as misconfigurations or transient network issues.

Độ tin cậy là khả năng hệ thống phục hồi từ sự gián đoạn cơ sở hạ tầng hoặc dịch vụ, tự động có được tài nguyên điện toán để đáp ứng nhu cầu và giảm thiểu sự gián đoạn như cấu hình sai hoặc các sự cố mạng tạm thời.

Nói ngắn gọn là để đạt được độ tin cậy cao thì cần phải áp dụng rất nhiều kỹ thuật, mà nổi bật nhất trong đó là High Availability. Ngoài ra còn có họ còn khuyến khích:

  • Triển khai tự động nhằm loại bỏ các yếu tố lỗi do con người.
  • Kiểm thử tính khả dụng, chịu tải, giả lập các tình huống gây lỗi tìm phương hướng khắc phục.
  • Cần giám sát hệ thống chặt chẽ và báo động, tìm giải pháp (tự động hoặc thủ công) nhằm khắc phục.
  • Thường xuyên kiểm tra (audit) để tìm ra các khuyết điểm của hệ thống.

REDUNDANCY VÀ REPLICATION – DỰ PHÒNG VÀ SAO CHÉP

Redundancy thường được thể hiện bằng cách có nhiều hơn 1 node/process trong 1 system để nhằm đảm bảo khi có sự cố xảy ra trên 1 node thì vẫn còn node khác có thể tiếp tục handle request, quá trình này gọi là fail-over. Có nhiều kiểu thiết lập redundancy như active-active hay active-passive bao gồm Cold-standby, Warm-standby hoặc Hot-standby. Các bạn có thể xem lại ở bài trước để hiểu rõ hơn ưu nhược của 2 hình thức này.

Replication thì tất nhiên là phải bao gồm việc đầu tiên là thiết lập redundancy kèm với việc sao chép data qua các redundant node luôn. Điển hình như việc sao chép dữ liệu giữa active DB node với các standby/passive node. Hoặc sao chép dữ liệu vào các backup node nhằm tránh tình trạng bị mất dữ liệu.

Hoặc có thể là có thêm máy phát điện dự phòng cho trường hợp cúp điện cũng là 1 ví dụ để tăng tính HA, nếu servers được host on-premises

Tuy nhiên, việc thiết lập 2 hoặc nhiều hơn các node có thực sự giúp cho HA cao hay không thì còn tùy vào cách setup. Ví dụ văn phòng bị chập mạch đường truyền internet vô data center bị đứt thì có bao nhiêu server trong đó đi chăng nữa cũng vô phương cứu chữa. Khi lên Cloud thì với lợi thế global infrastructure của mình, các nhà cung cấp hạ tầng, dịch vụ cloud cũng offer nhiều lựa chọn hơn cho khách hàng, ví dụ như thiết lập redundancy và replication ở nhiều khu vực vật lý khác nhau (multi AZ, multi Region, multi continent), và đương nhiên là giá cả sẽ khác nhau.

FAIL-OVER – CHUYỂN ĐỔI DỰ PHÒNG

Việc backup nhiều server dự phòng thôi là chưa đủ, ví dụ khi 1 server sập, làm thế nào để server khác có thể tiếp tục th

Trong một hệ thống phân tán hiện đại ngày nay cùng với việc move lên Cloud thì có rất nhiều thuật ngữ, từ ngữ mô tả về hệ thống rất dễ gây nhầm lẫn như High Availability, Redundancy, Resiliency, Fault Tolerrance, Failover,… Hãy cùng phân tích và so sánh các thuật ngữ đó để có thể dùng chúng chính xác hơn trong từng ngữ cảnh.

HIGH AVAILABILITY – TÍNH SẴN SÀNG CAO

High Availability (HA) hay còn gọi là Tính Khả Dụng/Sẵn Sàng Cao. Từ này gặp rất nhiều khi làm việc với các Cloud Service để đề cập đến việc 1 hệ thống hay service đó có tỷ lệ sống sót là bao nhiêu % trong 1 khoảng thời gian. Ví dụ nếu nói hệ thống có HA = 99% thì tức là sẽ có downtime (thời gian chết) là 3.65 ngày trong 1 năm, 7.31 giờ trong một tháng, 14.4 phút trong 1 ngày. Thời gian downtime có thể là do hệ thống cần được tắt để bảo trì nâng cấp hoặc bị cúp điện chẳng hạn. Vậy làm thế nào để có thể tăng tính HA cho hệ thống? Ví dụ có 1 số service sẽ có SLA (Service Level Agreement) hay Cam kết chất lượng dịch vụ cho HA lên đến 9 số 9 ( 99.9999999%) hoặc như DNS service sẽ có HA = 100%. Tất nhiên để HA càng cao thì chi phí càng đắt. Do đó, trong mỗi hệ thống cần suy nghĩ xem HA bao nhiêu là vừa đủ. Để làm được điều này thì chúng ta sẽ cần áp dụng một số kỹ thuật như redundancy, replication, zero-downtime deployment, fail-over,…

RELIABILITY – ĐỘ TIN CẬY

Một hệ thống có độ tin cậy cao thì HA sẽ cao, nhưng ngược lại không đúng. 1 hệ thống có khả năng sẵn sàng cao không có nghĩa là một hệ thống ưu việt. Ví dụ có con server đang sống và nhận, xử lý request đều đều, bỗng dưng không hiểu vì sao mà thời gian xử lý request mỗi lúc một lâu, có khi timeout luôn. Thì khi đó mặc dù ta nói HA vẫn cao nhưng độ tin cậy lại thấp.

Thật ra khi làm system design, mình chỉ hay chú ý đến High availability mà ít khi nghĩ đến tính Reliability. Phần này mình sẽ dựa theo Reliability pillar, một trong 5 pillars được định nghĩa trong AWS Well-Architected Framework.

Reliability is the ability of a system to recover from infrastructure or service disruptions, dynamically acquire computing resources to meet demand, and mitigate disruptions such as misconfigurations or transient network issues.

Độ tin cậy là khả năng hệ thống phục hồi từ sự gián đoạn cơ sở hạ tầng hoặc dịch vụ, tự động có được tài nguyên điện toán để đáp ứng nhu cầu và giảm thiểu sự gián đoạn như cấu hình sai hoặc các sự cố mạng tạm thời.

Nói ngắn gọn là để đạt được độ tin cậy cao thì cần phải áp dụng rất nhiều kỹ thuật, mà nổi bật nhất trong đó là High Availability. Ngoài ra còn có họ còn khuyến khích:

  • Triển khai tự động nhằm loại bỏ các yếu tố lỗi do con người.
  • Kiểm thử tính khả dụng, chịu tải, giả lập các tình huống gây lỗi tìm phương hướng khắc phục.
  • Cần giám sát hệ thống chặt chẽ và báo động, tìm giải pháp (tự động hoặc thủ công) nhằm khắc phục.
  • Thường xuyên kiểm tra (audit) để tìm ra các khuyết điểm của hệ thống.

REDUNDANCY VÀ REPLICATION – DỰ PHÒNG VÀ SAO CHÉP

Redundancy thường được thể hiện bằng cách có nhiều hơn 1 node/process trong 1 system để nhằm đảm bảo khi có sự cố xảy ra trên 1 node thì vẫn còn node khác có thể tiếp tục handle request, quá trình này gọi là fail-over. Có nhiều kiểu thiết lập redundancy như active-active hay active-passive bao gồm Cold-standby, Warm-standby hoặc Hot-standby. Các bạn có thể xem lại ở bài trước để hiểu rõ hơn ưu nhược của 2 hình thức này.

Replication thì tất nhiên là phải bao gồm việc đầu tiên là thiết lập redundancy kèm với việc sao chép data qua các redundant node luôn. Điển hình như việc sao chép dữ liệu giữa active DB node với các standby/passive node. Hoặc sao chép dữ liệu vào các backup node nhằm tránh tình trạng bị mất dữ liệu.

Hoặc có thể là có thêm máy phát điện dự phòng cho trường hợp cúp điện cũng là 1 ví dụ để tăng tính HA, nếu servers được host on-premises

Tuy nhiên, việc thiết lập 2 hoặc nhiều hơn các node có thực sự giúp cho HA cao hay không thì còn tùy vào cách setup. Ví dụ văn phòng bị chập mạch đường truyền internet vô data center bị đứt thì có bao nhiêu server trong đó đi chăng nữa cũng vô phương cứu chữa. Khi lên Cloud thì với lợi thế global infrastructure của mình, các nhà cung cấp hạ tầng, dịch vụ cloud cũng offer nhiều lựa chọn hơn cho khách hàng, ví dụ như thiết lập redundancy và replication ở nhiều khu vực vật lý khác nhau (multi AZ, multi Region, multi continent), và đương nhiên là giá cả sẽ khác nhau.

FAIL-OVER – CHUYỂN ĐỔI DỰ PHÒNG

Việc backup nhiều server dự phòng thôi là chưa đủ, ví dụ khi 1 server sập, làm thế nào để server khác có thể tiếp tục thực hiện các công việc hiện thời. Đó là nhờ các kỹ thuật về fail-over (chuyển đổi dự phòng). Các kỹ thuật fail-over thì cũng khá nhiều, tuy nhiên với việc lên Cloud hoặc sử dụng các container management and orchestration platform như Kubernetes thì việc cần làm là thiết lập cấu hình như DB fail-over hoặc container replica thì có thể ngồi rung đùi rồi.

ực hiện các công việc hiện thời. Đó là nhờ các kỹ thuật về fail-over (chuyển đổi dự phòng). Các kỹ thuật fail-over thì cũng khá nhiều, tuy nhiên với việc lên Cloud hoặc sử dụng các container management and orchestration platform như Kubernetes thì việc cần làm là thiết lập cấu hình như DB fail-over hoặc container replica thì có thể ngồi rung đùi rồi.

Bài viết gốc được đăng tải tại edwardthienhoang.wordpress.com

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev

Cách trở thành một MarTech Developer trong năm 2024

Cách trở thành một MarTech Developer trong 2021

Nói về MarTech chắc bạn đã nghe nói về các chức danh công việc khác nhau, như lập trình viên giao diện người dùng, lập trình viên phụ trợ, lập trình viên toàn bộ, v.v.

MarTech không phải là một thứ gì đó mới mẻ, nó đã xuất hiện khá lâu rồi, nhưng cách nó bùng nổ và phát triển trong vài năm qua là một hiện tượng.

Tôi chưa từng nghe về nó, cho đến khi làm việc trước đây trong một công ty tiếp thị tăng trưởng, nơi tôi học các khái niệm và nguyên tắc tiếp thị cũng như cách một lập trình viên có thể đóng một vai trò nào đó trong tiếp thị.

Vậy Martech là gì?

Bất kỳ công cụ hoặc phần mềm nào có thể giúp bạn tự động hóa, tối ưu hóa hoặc thậm chí cho phép bạn thực hiện các nỗ lực tiếp thị của mình là Martech hoặc Công nghệ tiếp thị.

Martech đi sau bất kỳ tiến bộ công nghệ nào, cho dù đó là trí tuệ nhân tạo hay blockchain, mọi công nghệ đều có tác dụng và mở ra những cánh cửa cơ hội mới trong martech.

Trước khi trở thành lập trình viên martech, bạn nên biết tại sao phải trở thành lập trình viên martech?

Tại sao chọn Martech?

Cách trở thành một MarTech Developer trong 2021
Bảng thống kê sự bùng nổ của marketing technology app trong một thập kỷ

Do sự bùng nổ của martech, các đại lý tiếp thị và quảng cáo trên khắp thế giới đang thuê các lập trình viên để tự động hóa các quy trình hiện có của họ và xây dựng các công cụ tự động hóa.

Không chỉ vậy, việc làm Martech được xếp hạng #3 trong báo cáo việc làm mới nổi năm 2020 của Linkedin. Điều này cho thấy rõ ràng cảnh quan công nghệ đang phát triển như thế nào và có nhu cầu rất lớn về các lập trình viên.

Bây giờ chúng ta hãy thảo luận về những gì bạn cần chính xác để trở thành một lập trình viên martech.

Một chút kiến thức Marketing

Hầu hết các lập trình viên nghĩ rằng martech chỉ dành cho các marketer, nhưng điều đó không đúng. Bạn không cần phải là một marketeer để trở thành một lập trình viên martech.

Kiến thức tiếp thị hoàn toàn phụ thuộc vào công việc bạn đang tìm kiếm. Ví dụ: nếu một công ty muốn tự động hóa việc báo cáo hoặc quảng cáo của Facebook hoặc Google Ads thì bạn cần phải học các API của Google Ads và Facebook Ads.

Tất cả là về mức độ quen thuộc của bạn với các công cụ tiếp thị và API của chúng.

Tuy nhiên, hầu hết các công ty đều đào tạo cho người mới bắt đầu nhưng bạn vẫn nên có kiến thức cơ bản tốt trước khi đi làm.

Tôi sẽ giải thích bên dưới những API và công cụ cơ bản nào bạn cần học để bắt đầu.

Vậy ngôn ngữ lập trình bạn nên học là gì?

Cách trở thành một MarTech Developer trong 2021

Không có ngôn ngữ lập trình hoàn hảo hoặc ưa thích nào mà bạn cần học để trở thành lập trình viên martech.

Một ngôn ngữ có thể được sử dụng cho bất cứ điều gì là những gì bạn cần.

Có một lệnh tốt của một ngôn ngữ mục đích chung như JavaScript, Python, PHP, v.v. là tất cả những gì bạn cần.

Tôi thích JavaScript hơn, bởi vì cho dù bạn muốn tạo ứng dụng web hay ứng dụng di động, hay thậm chí là ứng dụng máy tính để bàn, JS là tất cả những gì bạn cần biết.

Tất nhiên kỹ năng vững chắc về HTML, CSS cũng là bắt buộc nếu bạn đang muốn xây dựng các công cụ cho web.

Những tool bạn nên biết

Cảnh quan martech đang phát triển hơn bao giờ hết mỗi ngày các công cụ mới xuất hiện, nhưng đừng lo lắng bạn không cần phải học từng công cụ.

Làm quen với các công cụ phổ biến được các đại lý tiếp thị sử dụng hàng ngày. Kiến thức từ sơ cấp đến trung cấp là đủ để xây dựng các giải pháp trên các công cụ này.

Tôi liệt kê các danh mục công cụ với một số ví dụ, tất cả những gì bạn cần là tìm kiếm các công cụ hàng đầu trong các danh mục này để làm quen với chúng.

  • Ads Manager (Facebook Business Manager, Google Ads Manager)
  • Analytics (Google Analytics, Facebook Pixel)
  • Email Marketing tools (MailChimp, Aweber, HubSpot)
  • Integrations tools (Zapier)
  • CRM (Hubspot, Salesforce)

Hãy nhớ rằng những công cụ này được tạo ra cho các marketer, đó là lý do tại sao trọng tâm của bạn là hiểu biết kỹ thuật về công cụ và các API của nó. Là một lập trình viên martech, bạn sẽ tạo ra các giải pháp trên các công cụ này để giúp mọi thứ trở nên dễ dàng hơn cho các marketer.

Vậy bạn có thể học những kiến thức này từ đâu?

Đơn giản vậy thôi, Youtube!

Bất cứ khi nào tôi muốn tìm hiểu một cái gì đó mới, youtube là cách tốt nhất để có được một số kiến thức cơ bản để bắt đầu.

Nhưng điều đó không phải lúc nào cũng đủ để dành chút thời gian cho tài liệu chính thức hoặc hướng dẫn về các công cụ để hiểu sâu đầy đủ về các khái niệm.

Facebook và Google có các tài nguyên chính thức để bạn có thể bắt đầu.

Lời kết

Các agency marketing hiện nay cần những lập trình viên vừa sáng tạo và nhanh nhẹn để thấu hiểu dữ liệu và đưa ra kết quả cũng như báo cáo để hỗ trợ cho team marketing đưa ra các chiến lược hiệu quả.

Giờ đây, các marketer đang khám phá các công nghệ như Machine Learning, Blockchain, Virtual Reality, v.v. để đưa ra những ý tưởng đột phá cho khách hàng của họ và đó là lúc một lập trình viên martech sẽ giúp họ tìm ra công nghệ phù hợp.

Nếu bạn đang có ý định thay đổi sự nghiệp của mình vào năm 2023 thì martech là một lựa chọn đáng cân nhắc.

Có thể bạn quan tâm:

Xem thêm ITJobs for Developer hấp dẫn trên TopDev

10 trình quản lý file hàng đầu trong JavaScript

10 trình quản lý tệp Javascript hàng đầu

Quản lý file là một công cụ hữu ích trong bất kỳ ứng dụng kinh doanh nào. Dưới đây là tổng quan về các Trình quản lý file JavaScript chức năng, trang nhã và phổ biến nhất sẵn sàng được tích hợp vào giải pháp client-server.

Ngay cả khi bạn không có nhu cầu trực tiếp làm việc với file, bạn có thể mượn giao diện trình khám phá file cổ điển cho các tác vụ khác. Ví dụ, có một số trường hợp giao diện cổ điển trở thành cơ sở cho một ứng dụng web mới trong bài viết này.

Vì vậy, chúng ta hãy xem xét các trình quản lý file!

Tuyển Javascript lương cao up to 2000USD

1. Webix File Manager

10 trình quản lý tệp Javascript hàng đầu
Webix File Manager

Webix File Manager là một SPA làm sẵn. Giao diện của nó được thiết kế để tạo điều kiện thuận lợi cho quá trình tùy chỉnh và tích hợp vào các giải pháp của bên thứ ba. Phiên bản mới nhất chứa nhiều tính năng:

  1. dual panel mode
  2. preview panel
  3. thumbnail support for image files
  4. built-in media player
  5. text editor

Người dùng thể hiện nội dung của họ bằng tiện ích. Ví dụ: Emmanual Onah đã sử dụng nó trong một nền tảng quản lý dự án dành cho các dịch giả tự do. Bạn có thể tìm hiểu thêm về kinh nghiệm của anh ấy trong buổi giới thiệu.

Website: https://webix.com/filemanager/

Download link: https://webix.com/filemanager/download.html

2. Syncfusion File Explorer

10 trình quản lý tệp Javascript hàng đầu
Syncfusion File Explorer

Đây là một công cụ quản lý file trong JavaScript đơn giản rất giống với Windows File Explorer. Nó được cung cấp bởi sản phẩm Syncfusion phổ biến. Các nhà phát triển đã cung cấp một thiết kế giao diện đơn giản hóa, giả định rằng người dùng sẽ phát triển và tích hợp tầm nhìn của họ. Control thực hiện tất cả các hoạt động cơ bản của file như tải lên, tải xuống, xóa, tạo, sắp xếp, tìm kiếm và đổi tên cùng với tùy chọn bên ngoài để xem trước hình ảnh trong hệ thống file.

Đây là danh sách các tính năng:

  1. customizable layout design
  2. file upload and download
  3. sorting
  4. searching
  5. drag-n-drop
  6. access control selection
  7. multiple file selection
  8. localization

JavaScript File Manager hỗ trợ một số chủ đề cài sẵn: Material, Bootstrap, Fabric (Office 365) và độ tương phản cao. Bất kỳ chủ đề tích hợp nào trong số này đều có thể được thiết lập hoặc có cơ hội cho người dùng tạo các chủ đề mới. Điều này có thể đạt được bằng cách ghi đè các biến SASS hoặc sử dụng ứng dụng Theme Studio.

Website: https://www.syncfusion.com/javascript-ui-controls/js-file-manager

Download: https://www.syncfusion.com/downloads/essential-js2

3. Bootstrap File Manager SDK

10 trình quản lý tệp Javascript hàng đầu
Bootstrap File Manager SDK

Đây là một epxlorer sáng giá và hùng mạnh khác, từng có tên gọi là AlphaManager. Nếu bạn định phát triển dự án của mình trên nền tảng Bootstrap, đây sẽ là lựa chọn phù hợp. Trình quản lý file DevExpress Bootstrap cung cấp giao diện người dùng trực quan được thiết kế để quản lý file và thư mục tương tự như Microsoft File Explorer.

Bao gồm các tính năng:

  1. Khả năng đổi tên, sao chép, di chuyển và xóa các thư mục và file;
  2. Hỗ trợ các nguồn dữ liệu hệ thống file khác nhau (vật lý, nguồn dữ liệu, lưu trữ đám mây);
  3. Khả năng tải xuống và tải lên file;
  4. Kiểm soát truy cập tích hợp với hỗ trợ cho các vai trò bảo mật.

Website: https://js.plus/products/file-manager

>>> Xem thêm: Javascript empty array – đừng gán [] thêm một lần nào nữa

4. DHTMLX File Manager

10 trình quản lý tệp Javascript hàng đầu
DHTMLX File Manager

DHTMLX cung cấp trình quản lý file trong JavaScript chất lượng cao. Nó là một công cụ thuận tiện để tạo các ứng dụng thân thiện với người dùng để quản lý hệ thống file. Nó giúp người dùng thực hiện các thao tác file phổ biến nhất, chẳng hạn như tải lên, chỉnh sửa và sắp xếp file trong thư mục. Trình thám hiểm hỗ trợ các file ở bất kỳ định dạng nào và cho phép theo dõi không gian còn lại.

Người dùng có thể tận hưởng các tính năng sau:

  1. Chế độ xem trước dạng grid hoặc list
  2. Sắp xếp theo thứ tự chữ cái tăng dần hoặc giảm dần
  3. Hỗ trợ context-menu
  4. Thông tin file

Bên cạnh đó, mẫu trình khám phá file DHX tuyên bố có khả năng điều hướng dễ dàng. Nó cho phép sắp xếp các thư mục theo cấu trúc cây và tìm kiếm các mục cần thiết bằng cách gõ tên vào ô tìm kiếm. Bản trình diễn quản lý file JavaScript này tuân theo nguyên tắc Material Design của Google.

Website: https://dhtmlx.com/docs/products/dhtmlxFileManager/

5. DevExtreme

10 trình quản lý tệp Javascript hàng đầu
DevExtreme

Thư viện này cung cấp một giải pháp đơn giản nhưng ngắn gọn để quản lý file. Tiện ích Trình quản lý file có thể hiển thị một tập hợp các mục phân cấp trình bày cấu trúc hệ thống file. Tiện ích cho phép người dùng cuối dễ dàng tải lên và chọn file cũng như thay đổi cấu trúc thư mục (đổi tên, di chuyển, sao chép và xóa file và thư mục). Khả năng quản lý file và thư mục hoàn toàn có thể tùy chỉnh và có thể tắt nếu cần.

Website: https://js.devexpress.com/Demos/WidgetsGallery/Demo/FileManager/Overview/jQuery/Light/

6. elFinder

10 trình quản lý tệp Javascript hàng đầu
elFinder

Một trình quản lý file trong JavaScript rất đơn giản nhưng đầy đủ chức năng được xây dựng bằng jQuery. Những nhược điểm của trình quản lý bao gồm không thể thay đổi chiều cao của cửa sổ chính, được cố định ở 400px. Công cụ này cho phép bạn xây dựng trong một trình chỉnh sửa trực quan. Nó có một tùy chọn để thêm hình ảnh vào văn bản.

Xem thêm các việc làm Citigo tuyển dụng

Nếu trình quản lý file được bật, bạn có thể tải xuống và nhận liên kết đến hình ảnh bằng hai lần nhấp. Ngoài việc tải hình ảnh lên trang web, bạn cũng có thể tải lên file, lưu trữ, tài liệu, v.v. Có thể chỉ định liên kết tải xuống trên trang đã tạo.

Các tính năng của ElFinder bao gồm:

  1. Tạo và xóa các thư mục và thư mục con
  2. Tải lên các file thuộc bất kỳ loại nào
  3. Tải xuống các file từ trang web
  4. Xem lướt qua
  5. Sao chép và di chuyển file
  6. Lưu trữ và giải nén nội dung
  7. Đổi tên file
  8. Chỉnh sửa hình ảnh (cắt, thay đổi kích thước, xoay)
  9. Tải file lên bộ nhớ đám mây

Website: https://github.com/Studio-42/elFinder

7. MooTools FileManager

10 trình quản lý tệp Javascript hàng đầu
MooTools FileManager

MooTools FileManager cho phép bạn xem, tải xuống và sửa đổi các file và thư mục bằng trình duyệt. Các tính năng của trình quản lý là:

  1. Xem các file và folder trên máy chủ
  2. Đổi tên, xóa, di chuyển (kéo thả), sao chép và tải file xuống
  3. Xem trước hình ảnh, file văn bản, file nén hoặc âm thanh
  4. Giao diện người dùng bắt mắt
  5. Tải file lên qua FancyUpload (tính năng tích hợp)
  6. Thay đổi kích thước của những ảnh có dung lượng lớn khi tải

Website: https://mootools.net/forge/p/mootools_filemanager

>>> Xem thêm: 9 lỗi JavaScript các lập trình viên hay gặp

8. AjaXplorer

10 trình quản lý tệp Javascript hàng đầu
AjaXplorer

AjaXplorer là trình quản lý file miễn phí không thể thiếu để quản lý file từ xa trên web server. Nó phù hợp cho nhiều mục đích khác nhau, chẳng hạn như quản lý file, thư viện ảnh, view code, vân vân. Yêu cầu PHP (4 hoặc 5) và không cần cơ sở dữ liệu.

Trình quản lý có nhiều tính năng:

  1. Đổi tên, sao chép, di chuyển, xóa, tải xuống file hoặc thư mục
  2. Tải lên nhiều file
  3. Theo dõi trạng thái trên thanh tiến trình (yêu cầu Flash)
  4. Tạo thư mục và file
  5. Chỉnh sửa file văn bản và tập lệnh (JS, PHP, HTML, Java, SQL, Perl)
  6. Xem ảnh và hình ảnh
  7. Nghe MP3 trực tuyến mà không cần tải xuống video watchFlash (FLV) ở chế độ toàn màn hình
  8. Xem và giải nén các file ZIP

Website: https://pydio.com/en/

Download: https://pydio.com/download/

9. CKFinder

10 trình quản lý tệp Javascript hàng đầu
CKFinder

CKFinder là một trình quản lý file mạnh mẽ nhưng dễ sử dụng cho các trình duyệt web. Giao diện trực quan và thân thiện với người dùng của nó cho phép bạn nhanh chóng học nó cho mọi đối tượng người dùng, từ chuyên gia đến người mới bắt đầu.

Các tính năng bao gồm:

  1. Up file an toàn
  2. Phản hồi nhanh
  3. Giao diện dễ dàng và thân thiện với người dùng
  4. Tạo, đổi tên và xóa các folder và file
  5. Hỗ trợ đa ngôn ngữ với tính năng phát hiện ngôn ngữ người dùng tự động
  6. Preview với hình ảnh chất lượng cao
  7. Folder tree

Website: https://ckeditor.com/ckfinder/

Download: https://ckeditor.com/ckfinder/download/

10. FileRun

10 trình quản lý tệp Javascript hàng đầu
FileRun

FileRun là một hệ thống quản lý file trong JavaScript (bằng PHP) cho phép bạn quản lý các file được lưu trữ trên máy chủ web của mình bằng giao diện thân thiện với người dùng (Ajax). FileRun được viết hoàn toàn bằng PHP và trình duyệt là thứ duy nhất mà người dùng cần để làm việc với các file. Bạn có thể dễ dàng truy cập tài liệu hoặc file của mình từ bất kỳ máy tính nào có kết nối Internet thông qua trình duyệt tiêu chuẩn.

Các tính năng là:

  1. Giao diện dựa trên Ajax
  2. Tải xuống và lưu trữ các folder
  3. Không giới hạn dung lượng để tải file xuống
  4. Dễ dàng quản lý các flie đã tồn tại trong hệ thống file

Website: https://www.filerun.com/

Download: https://filerun.com/download

Kết bài

Hy vọng qua bài viết này các lập trình viên có thể chọn được phần mềm quản lý file trong JavaScript hợp lý cho dự án của mình. Nếu bạn biết về phần mềm quản lý file hữu ích nào khác, có thể chia sẻ thêm tại comment để mình cải thiện danh sách trên. Xin cảm ơn

Có thể bạn quan tâm:

Xem thêm việc làm IT hấp dẫn trên TopDev

Công cụ performance test Jmeter

jmeter
Công cụ performance test Jmeter

Bài viết được sự cho phép của tác giả Lê Chí Dũng

I. Giới thiệu về Performance Test

1. Performance Test là gì?

  • Là một kiểu dùng để thực thi Non Functional test (kiểm thử phi chức năng)
  • Xác định khả năng hoạt động của hệ thống có phù hợp với yêu cầu hay không
  • Phục vụ nhiều mục đích khác nhau như chứng minh rằng hệ thống có thể đạt được các đáp ứng performance tối thiểu
  Hướng dẫn sử dụng JMeter test hiệu năng website - Phần 1
  Biện hộ: Vì sao các Developer không test phần mềm của họ?

2. Phân biệt test performance vs load vs stress

Refer: https://www.guru99.com/performance-vs-load-vs-stress-testing.html

Performance Testing (PT) Load Testing (LT) Stress testing (ST)
– Thực hiện để kiểm tra, xác định hệ thống thực hiện một khối lượng công việc cụ thể trong thời gian bao lâu.
– Xác định hiệu năng của hệ thống trong điều kiện thông thường
– Thực hiện với 1 hoặc nhiều user và một lượng dữ liệu lý tưởng.		 – Thực hiện để kiểm tra, xác định hoạt động của hệ thống trong điều kiện tải cao.
– Xác định hiệu năng của hệ thống trong điều kiện tải cao
– Thực hiện với một số lượng lớn user cùng truy cập.		 – Thực hiện để kiểm tra, xác định hoạt động của hệ thống khi điều kiện tải cao bất thường.
– Xác định tính tin cậy của hệ thống trong điều kiện khắc nghiệt nhất
– Thực hiện với một số lượng lớn dữ liệu và một số lượng lớn user cùng truy cập.

II. Tổng quan về Jmeter

1. Jmeter là gì?

  • Một mã nguồn mở được viết bằng java
  • Hỗ trợ GUI đơn giản, trực quan dễ sử dụng
  • Công cụ độc lập có thể chạy trên nhiều nền tảng hệ điều hành khác nhau, trên Linux chỉ cần chạy bằng một shell script, trên Windows thì chỉ cần chạy một file .bat
  • Đa luồng, giúp xử lý tạo nhiều request cùng một khoảng thời gian, xử lý các dữ liệu thu được một cách hiệu quả.
  • Đặc tính mở rộng, có rất nhiều plugin được chia trẻ rộng rãi và miễn phí
  • Một công cụ tự động để kiểm thử hiệu năng và tính năng của ứng dụng.
  • Công cụ để đo độ tải và performance của đối tượng, có thể sử dụng để test performance trên cả nguồn tĩnh và nguồn động, có thể kiểm tra độ tải và hiệu năng trên nhiều loại server khác nhau như:
    • Web – HTTP
    • HTTPS
    • SOAP
    • Database thông qua JDBC, LDAP, JMS
    • Mail – SMTP(S), POP3(S) and IMAP(S)
    • …

2. Jmeter hoạt động như thế nào?

Giả lập một nhóm người dùng gửi các yêu cầu tới một máy chủ, nhận và xử lý các response từ máy chủ và trình diễn các kết quả đó cho người dùng dưới dạng bảng biểu, đồ thị,cây… (Xem hình bên dưới)

Ưu điểm của Jmeter

  • Kiểm tra tải và kiểm tra hiệu năng theo nhiều kiểu khác nhau: Web – HTTP, HTTPS, SOAP, Database via JDBC, LDAP, JMS, Mail – POP3(S) and IMAP(S).
  • Rất nhẹ, không cần cài đặt, miễn phí.
  • Nền tảng xử lý đa luồng cho phép mô phỏng nhiều mẫu bởi nhiều thread của các chức năng khác nhau trên các thread group khác nhau
  • Dễ dàng thêm các plugin và tạo các báo cáo phù hợp yêu cầu.
  • Được hỗ trợ mạnh bởi cộng đồng open source

Nhược điểm của Jmeter

  • Sun’s JRE phải được cài đặt.
  • Chỉ sử dụng được với ứng dụng web.
  • Kết quả stress testing có thể khó xác định chính xác.
  • Khó khăn khi thực hiện các kịch bản kiểm thử phức tạp.
  • Khó thực hiện Recording

III. Hướng dẫn cài đặt và thông số của Jmeter

1. Cài đặt Jmeter

  • Download Jmeter http://jmeter.apache.org/download_jmeter.cgi
  • Sau khi download về giải nén và mở thư mục đó ra
    • Trên Windows chạy file : jmeter.bat
    • Trên Linux chạy file: jmeter.sh
      Chú ý: Cần chắc chắn rằng máy tính đã được cài đặt Java

2. Thông số của Jmeter

  • Test Plan: Bao gồm các bước sẽ được JMeter thực thi.
  • Thread Group: Đại diện cho người dùng ảo (virtual user), có thể gồm các thành phần sau:
  • Logic Controller: Cho phép điều chỉnh logic khi gửi các yêu cầu đến đối tượng cần kiểm tra.
  • Sampler: Cung cấp thông tin cho JMeter gửi các yêu cầu đến máy chủ cần kiểm tra. Tùy theo giao thức kiểm tra, JMeter hỗ trợ những loại sampler khác nhau.
  • Config Element: Sử dụng để thêm vào những thay đổi/ cấu hình cần thiết cho các sampler.
  • Timer: Điều chỉnh khoảng thời gian dừng giữa các lần gửi yêu cầu.
  • Listener: Cho phép thu thập thông tin kết quả. Có thể đưa ra các báo cáo kết quả kiểm tra dạng đồ thị, hoặc xuất ra tập tin.

Bài viết gốc được đăng tải tại lcdung.top

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev

Capacity Planning – Dự toán công suất cho ứng dụng (Tập 2)

Capacity Planning
Capacity Planning

Bài viết được sự cho phép của tác giả Edward Thiên Hoàng

Xem lại phần 1

4. THIẾT KẾ VÀ TỐI ƯU HÓA ỨNG DỤNG

Thiết kế của ứng dụng hoặc phần mềm đóng một vai trò lớn trong việc lập dự toán công suất. Nếu một session được tạo cho mỗi người dùng đồng thời, điều này có nghĩa là mức tiêu thụ bộ nhớ cho mỗi session. Đối với mỗi hoạt động, các yếu tố như kết nối cơ sở dữ liệu, số lượng object được lưu trữ trong bộ nhớ và lượng xử lý diễn ra sẽ xác định dung lượng bộ nhớ và dung lượng xử lý cần thiết. Các ứng dụng được thiết kế tốt sẽ cố gắng giữ cho những con số này ở mức thấp hoặc sẽ chia sẻ tài nguyên của hiệu quả. Số lượng tài nguyên được tạo ra cho một ứng dụng cũng đóng một vai trò. Ví dụ, đối với các hoạt động chuyên sâu của cơ sở dữ liệu, kích thước nhóm kết nối cơ sở dữ liệu sẽ là một yếu tố hạn chế. Tương tự, thread pool, thời gian thu gom rác, v.v. cũng xác định hiệu năng của hệ thống. Việc thử và thử nghiệm chịu tải ứng dụng bằng các công cụ (ví dụ: đối với các ứng dụng Java, JProiler, JConsole, JMeter, v.v.) sẽ giúp xác định các điểm tắc nghẽn trong ứng dụng.

  System Design Cơ Bản - Consistent Hashing
  System Design Cơ Bản - Định lý Cap / Cap Theorem

Các tham số tối ưu hóa cũng nên được tính đến như một phần của giải pháp. Các kỹ thuật như bộ nhớ đệm có thể giúp cải thiện hiệu suất và độ trễ – điều này cần được xem xét từ góc độ rộng hơn. Nếu các phản hồi của dịch vụ thay đổi thường xuyên, thì bộ nhớ đệm sẽ không tạo ra quá nhiều sự khác biệt. Bộ nhớ cache thời gian làm nóng cũng cần phải được tính đến.

Cũng khuyến khích để có một dung lượng buffer khi phân bổ các thông số máy chủ. Ví dụ, phân bổ thêm 20-30% thông số kỹ thuật của máy chủ cho các NFR cao điểm để đảm bảo hệ thống không hết dung lượng khi tải tối đa.

Cũng nên dùng các công cụ giám sát để tính toán công suất hệ thống. Thử nghiệm chịu tải, ứng dụng và máy chủ profiling thông qua các công cụ giám sát và profiling có thể giúp xác định công suất hiện tại khá chính xác và giúp xác định trước các điểm tắc nghẽn.

Loại phần cứng cũng là điểm khác biệt. Các máy vật lý truyền thống đang nhanh chóng được thay thế bởi VM và các Cloud. Cách lý tưởng để tính công suất là có điểm chuẩn trên các môi trường khác nhau này. Cấp phát bộ nhớ 4GB trên máy ảo có thể không giống với phân bổ bộ nhớ 4GB trên máy chủ vật lý hoặc phiên bản Amazon EC2. Cũng có những trường hợp hướng đến một số loại hoạt động nhất định. Ví dụ, EC2 có các trường hợp được tối ưu hóa bộ nhớ, tính toán tối ưu hóa hoặc tối ưu hóa I/O dựa trên loại hoạt động chính.

5. TÍNH SẴN SÀNG CAO VÀ KHẢ NĂNG MỞ RỘNG

5.1 KHẢ NĂNG MỞ RỘNG

Khả năng mở rộng là khả năng xử lý các yêu cầu tương ứng với tài nguyên phần cứng có sẵn; một hệ thống có thể mở rộng lý tưởng nên xử lý tăng / giảm yêu cầu mà không ảnh hưởng đến thông lượng chung.

Khả năng mở rộng có hai trường phái; mở rộng theo chiều dọc (vertical scaling) tăng hiệu suất của máy chủ bằng cách tăng bộ nhớ, sức mạnh xử lý, v.v. (ví dụ: chênh lệch hiệu suất giữa máy chủ RAM 4GB và máy chủ RAM 8GB) so với khả năng mở rộng theo chiều ngang (horizontal scaling) hoặc Mở rộng quy mô, nơi bạn triển khai thêm nhiều máy chủ cùng loại.

Dựa trên các yêu cầu về tính khả dụng đã thảo luận ở trên, chúng ta cần xác định mô hình sẵn sàng cao phù hợp. Tính sẵn sàng cao có thể được phân loại như sau:

5.2 TÍNH SẴN SÀNG CAO

Tính sẵn sàng cao có thể đạt được thông qua phương thức active-active, hoặc chuyển đổi dự phòng active-passive. Trong cách đầu tiên, tính khả dụng khá cao trong khi kịch bản thứ hai, chuyển đổi dự phòng sang node thụ động cần can thiệp thủ công hoặc tự động. Tùy thuộc vào điều này, sự sẵn có của sau này sẽ giảm.

Capacity Planning - Dự toán công suất cho ứng dụng (Tập 2)

Figure 7: High Availability Within a Data Center

Phân cụm (Clustering) là một kỹ thuật phổ biến để đạt được tính sẵn sàng cao bằng cách cung cấp dự phòng ở cấp độ phần mềm và phần cứng (Hình 7). Thông thường có 4 điều kiện khác nhau có thể được sử dụng ở đây:

  • Chế độ chờ lạnh (Cold-standby): Trong thiết lập này, node chính đang hoạt động và node phụ là node thụ động. Node phụ là bản sao lưu giống hệt của node chính, nhưng chỉ được cài đặt và khởi động (cả phần cứng và thành phần phần mềm của máy chủ) nếu node chính bị lỗi. Do đó, thời gian phục hồi để đưa node phụ trực tuyến và hoạt động sẽ là cần thời gian khá lâu.
  • Chế độ chờ ấm (Warm-standby): Trong thiết lập này cũng là node chính đang hoạt động và node phụ là node thụ động. node phụ là một bản sao lưu giống hệt của node chính và các thành phần phần mềm cần thiết được cài đặt, nhưng không chạy. Node máy chủ vật lý đang chạy mặc dù và trong trường hợp xảy ra lỗi node chính, các thành phần phần mềm trên node phụ được khởi động. Do đó, thời gian phục hồi để đưa node phụ trực tuyến và hoạt động sẽ là một vài phút.
  • Chế độ chờ nóng (Hot-standby): Trong thiết lập này một lần nữa, node chính được kích hoạt và node phụ là node thụ động. node phụ là một bản sao lưu giống hệt của node chính và các thành phần phần mềm cần thiết được cài đặt; và máy chủ vật lý và tất cả các thành phần phần mềm đang chạy. Tuy nhiên, node phụ không chấp nhận bất kỳ request nào và chỉ bắt đầu làm như vậy trong trường hợp lỗi node chính. Do đó, thời gian phục hồi để đưa node phụ trực tuyến và hoạt động sẽ là một vài giây.
  • Active-active: Cả hai node đang chạy và xử lý các yêu cầu song song. Ở đây, vì cả hai node chấp nhận yêu cầu, không có khái niệm thời gian phục hồi và cân bằng tải là tức thời.

Tính sẵn sàng cao cũng có thể đạt được thông qua các xem xét kiến ​​trúc bổ sung như:

  • Cân bằng tải và định tuyến – cân bằng các yêu cầu của khách hàng giữa các node; các kỹ thuật, chẳng hạn như session affinity, có thể được sử dụng để định tuyến các yêu cầu từ cùng một session đến cùng một node
  • Phân cụm – cho phép tất cả các thành phần trong cụm được xem như là một đơn vị chức năng duy nhất
  • Sao chép trạng thái – sao chép trạng thái của một máy chủ trong số các máy chủ khác có thể hoạt động trơn tru trong trường hợp chuyển đổi dự phòng
  • Hệ thống tự mở rộng – cho phép tự động mở rộng các server tùy thuộc vào yêu cầu
  • Hệ thống tự hồi phục – tự động khởi động lại hệ thống thông qua giám, v.v. cho phép các hệ thống không khả dụng tự phục hồi

5.3 PHỤC HỒI SAU THẢM HỌA (DISASTER RECOVERY)

Phục hồi thảm họa (DR) liên quan đến việc sao chép hệ thống chính lên một vùng riêng biệt về mặt địa lý để hệ thống có thể phục hồi khi hệ thống chính bị hỏng.

5.4 SAO LƯU VÀ PHỤC HỒI

Sao lưu và phục hồi liên quan đến việc sao chép ứng dụng, trạng thái hệ thống và ứng dụng và dữ liệu hệ thống lên phương tiện sao lưu. Điều này sau đó có thể được phục hồi do lỗi hệ thống chính hoặc do ứng dụng đạt đến trạng thái không nhất quán.

5.5 CLOUD

Đám mây cho phép các máy chủ được triển khai ở các vị trí địa lý khác nhau với các mạng tốc độ cao giữa các vị trí địa lý. Chẳng hạn, Amazon EC2 cho phép các máy chủ được triển khai trong một availability zone, cross zone hoặc thậm chí cross region, do đó cung cấp một cách thức rất dễ tiếp cận để đạt được tính sẵn sàng cao, toàn diện.

6. TÍNH TOÁN CÔNG SUẤT

Trên đây chỉ là một vài yếu tố có thể được sử dụng để lập dự toán công suất của một hệ thống và tầm quan trọng của các yếu tố này thay đổi dựa trên loại môi trường.

Các kiến ​​trúc sư khác nhau sử dụng các quy trình khác nhau để tính toán công suất. Một quy trình mẫu được minh họa trong Hình 6; bất kể quá trình nào, nó cần được kết hợp với quy trình kiến ​​trúc giải pháp hiện có của bạn.

Figure 8: Capacity Planning as Part of Deployment Architecture Process

Theo quy trình trong Hình 8, điều quan trọng là phải có một kiến trúc kinh doanh chính xác có thể được chuyển đổi thành kiến trúc giải pháp cấp cao. Dựa trên điều này, nhóm có thể bắt đầu thu thập dữ liệu dung lượng sẽ được sử dụng để tạo ra ma trận hoặc mô hình lập dự toán công suất.

Với các yếu tố này, chúng ta cũng cần một bộ số hiệu suất chuẩn để tính công suất máy chủ. Ví dụ, nếu chúng ta biết rằng một server trong các điều kiện môi trường nhất định với loại công suất nhất định hoạt động ở 3000 TPS, thì chúng ta có thể giả sử rằng một máy chủ có công suất và hoạt động tương tự sẽ cung cấp như nhau.

Tuy nhiên, điều quan trọng là phải hiểu rằng trong khi các điểm chuẩn có thể được sử dụng làm mô hình tham chiếu, thì khả năng áp dụng các số này cho vấn đề của bạn có thể khác nhau; do đó, ngoài khả năng dự báo, điều quan trọng là phải kiểm tra môi trường để xác định công suất cực đại của nó.

7. KẾT LUẬN

Không nghi ngờ gì nữa, lập dự toán công suất là một nghệ thuật cũng như khoa học và rõ ràng kinh nghiệm đóng vai trò quan trọng trong việc lập kế hoạch chính xác về năng lực. Trong bài này, chúng ta đã xem xét các khái niệm khác nhau về lập dự toán công suất và cách chúng ảnh hưởng đến năng lực giải pháp của hệ thống. Good luck!

8. THAM KHẢO

https://wso2.com/whitepapers/capacity-planning-for-application-design-part-1/

Article: ESB Performance Benchmark, Round 7.5
https://wso2.com/library/articles/2014/02/esb-performance-round-7.5/

Whitepaper: WSO2 Carbon Product Performance and Deployment Topology Sizing
https://wso2.com/whitepapers/wso2-carbon-product-performance-and-deploymenttopology-sizing/

Blog: How to measure the peformance of a server:
http://srinathsview.blogspot.com/2012/05/how-to-measure-performance-of-server.html

Bài viết gốc được đăng tải tại edwardthienhoang.wordpress.com

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev

7 lãng phí trong kiểm thử phần mềm

7 lãng phí trong kiểm thử phần mềm

Bài viết được sự cho phép của vntesters.com

Tựa đề “7 lãng phí trong kiểm thử phần mềm” nghe có vẻ quen quen? Vâng, 7 lãng phí nổi tiếng nhất là 7 lãng phí trong sản xuất tinh gọn (Lean manufacturing). Mình biết đến 7 lãng phí này cũng là sự tình cờ. Chuyện là công ty hiện mình đang làm việc là một công ty sản xuất. Mỗi ngày khi đi ăn trưa mình đều đi ngang qua xưởng sản xuất của công ty và có một tấm bảng được đặt dọc lối đi ngay cạnh xưởng sản xuất đã gây được sự chú ý của mình. Đó là tấm bảng nói về 7 lãng phí trong sản xuất tinh gọn. Đọc qua 7 nội dung thì mình thấy rõ ràng 7 lãng phí đó khá đơn giản, dễ hiểu và về cơ bản là đúng cho cả ngành kiểm thử phần mềm. Tìm hiểu kỹ hơn thì mình biết được rằng việc định ra và loại bỏ 7 lãng phí này đóng vai trò cực kỳ quan trọng trong sản xuất tinh gọn nhưng dường như ít ai quan tâm đến vấn đề này trong phát triển phần mềm cũng như trong kiểm thử. Điều đó đã thúc đẩy mình để thực hiện bài viết về 7 lãng phí trong kiểm thử phần mềm. Bài viết lần lượt đi qua 7 lãng phí trong sản xuất tinh gọn và được liên hệ với ngành kiểm thử phần mềm cùng với đó là những đề nghị giải pháp để loại bỏ hay giảm thiểu những lãng phí này.

  10 bước để bắt đầu áp dụng kiểm thử tự động vào dự án
  Các mức độ kiểm thử được sử dụng trong kiểm thử chức năng của một phần mềm

Lỗi (Defects)

Trong ngành sản xuất, lỗi được xem là lãng phí. Thực vậy, khi một lỗi xảy ra, chúng ta sẽ tốn nhiều thời gian của Dev để sửa lỗi, sau đó sẽ tốn thêm thời gian cho kỹ sư kiểm thử để kiểm thử lỗi một lần nữa. Tương tự, nếu một bản build bị hỏng (vì có quá nhiều lỗi nghiêm trọng), chúng ta đã lãng phí cả một quy trình, thời gian và công sức để làm lại từ đầu. Dĩ nhiên, lãng phí sẽ còn lớn hơn nếu sản phẩm bị lỗi sau khi đưa ra thị trường. Khi đó lãng phí không chỉ đơn thuần xảy ra ở bộ phận sản xuất mà còn kéo theo lãng phí cả những bộ phận khác trong công ty. Chắc các bạn cũng còn nhớ chuyện Toyota gần đây triệu hồi hàng chục nghìn xe tại Việt Nam và hàng triệu xe trên thế giới vì hàng loạt lỗi nghiêm trọng có thể ảnh hưởng đến sự an toàn của người sử dụng cho thấy mức độ nghiêm trọng của lỗi sau khi đưa ra thị trường. Rõ ràng không những tốn kém cho chi phí từ việc triệu hồi và sửa những lỗi đó mà còn ảnh hưởng không nhỏ đến hình ảnh của Toyota.

Để tránh lãng phí về lỗi, là kỹ sư kiểm thử, ngoài việc tìm lỗi chúng ta cũng nên chú trọng hơn vào vấn đề ngăn ngừa lỗi thay vì tìm lỗi. Việc chúng ta ngăn ngừa được một lỗi xảy ra có giá trị gấp nhiều lần một lỗi nghiêm trọng mà chúng ta tìm thấy vì khi chúng ta tìm thấy lỗi thì đã xuất hiện sự lãng phí. Để ngăn ngừa lỗi tốt hơn, kỹ sư kiểm thử nên được tham gia vào tất cả các khâu của dự án từ phân tích yêu câu, thiết kế đến viết code và càng sớm càng tốt.

Sản xuất thừa (Overproduction)

over_production

Trong kiểm thử phần mềm, việc chúng ta dành quá nhiều thời gian và công sức để tạo ra và cập nhật bản kế hoạch kiểm thử (test plan), chiến lược kiểm thử (test strategy), trường hợp kiểm thử (test case) mà thực tế thì nhiều khi chẳng ai hoặc ít ai đọc đến. Bi kịch là chúng ta biết điều đó nhưng vẫn phải làm vì nhiều lí do rất “thuyết phục” như “quy trình nó vậy”, “giờ không cần nhưng biết đâu khách hàng cần”, “như vậy mới pro” hay nhẹ nhàng hơn như “làm nhanh mà”. Các bạn đừng hiểu lầm là việc tạo ra các tài liệu kiểm thử là lãng phí, việc tạo ra tài liệu kiểm thử mà không có giá trị hoặc không cần thiết mới là lãng phí.

Trước khi bạn bắt đầu tạo một tài liệu kiểm thử hãy tự hỏi hay hỏi sếp mình những ai sẽ đọc nó và nó mang lại giá trị gì. Nếu không có câu trả lời hay câu trả lời là mơ hồ hay không rõ ràng thì tốt nhất chúng ta không nên tạo ra để tránh tình trạng sản xuất thừa.

Chờ đợi (Waiting)

work_in_progress

Ai đó từng nói “sống là không chờ đợi” ấy vậy mà trong ngành kiểm thử thì việc chờ đợi đã trở nên quen thuộc. Chúng ta đã bao nhiêu lần phải chờ đợi bản build từ đội Dev để kiểm thử, chờ môi trường kiểm thử sẵn sàng, chờ khách hàng kiểm duyệt cho các trường hợp kiểm thử đã tạo ra, chờ tài liệu yêu cầu từ khách hàng gửi sang, chờ khách hàng online để thảo luận, v.v. Lãng phí sẽ còn lớn hơn nếu trong khi chờ đợi và chúng ta không có gì khác để làm. “Tin tốt” là ngày nay sếp ít khi để cho nhân viên của mình nhàn rỗi trong khi chờ đợi và bạn luôn có việc khác để làm. Tin xấu là chúng ta đã tự đặt mình vào tình trạng bị động khi chờ đợi. Nhiều khi những thứ chúng ta chờ đợi lại đến không đúng thời điểm hay khi tất cả những thứ chúng ta đang chờ đợi cùng đến một lúc hay chẳng bao giờ đến. Đó là khi chúng ta chờ đợi 1 build từ đội Dev và gần cuối ngày chúng ta nhận được bản build với yêu cầu từ sếp là phải chạy xong bộ test case…trong ngày.

Hãy kiểm tra lại các khâu trong quy trình kiểm thử xem liệu có tình trạng “nút thắt cổ chai” đâu đó và đề ra giải pháp khắc phục tương ứng. Ứng dụng mô hình phát triển tích hợp liên tục (continuous integration) từ việc coding, triển khai, thực thi kiểm thử tự động, báo cáo kết quả không những tránh được lãng phí do chờ đợi mà còn tận dụng được nguồn lực máy móc một cách tối ưu. Hãy chuẩn bị sẵn cho mình kế hoạch B cũng như tìm ra những kênh liên lạc khác nhau để tránh tình trạng bị động khi phải chờ đợi.

Tồn kho (Inventory)

Việc sản xuất thừa cùng tình trạng chờ đợi ở trên dẫn đến một lãng phí khác là tồn kho. Trong ngành kiểm thử (và cả phát triển phần mềm) thì thuật ngữ “tồn kho” nghe có vẻ lạ lẫm nhưng thực tế thì có tồn tại việc tồn kho. Việc tạo ra quá nhiều tài liệu kiểm thử không cần thiết hoặc quá nhiều thứ đến cùng một lúc (do việc chờ đợi) hay quá nhiều thứ đang đợi để xử lý, dẫn đến tình trạng tồn kho (hay nói cách khác là “lưu trữ”). Ngày nay, với sự hỗ trợ của nhiều công cụ phần mềm cũng như dung lượng lưu trữ của máy tính lớn, chúng ta hầu như không thấy vấn đề về tồn kho trong dự án. Tuy nhiên, về lâu về dài việc tồn kho sẽ gây lãng phí về nguồn lực, thời gian trong quản lí và truy xuất. Ở đây, mình cũng thấy một vòng luẩn quẩn là từ việc chúng ta có hệ thống quản lí tồn kho tốt chúng ta lại vô tình khuyến khích tình trạng sản xuất thừa hay chờ đợi.

Thực tế thì việc tồn kho, quản lí tồn kho là không thể tránh khỏi và cũng không đáng kể trong kiểm thử phần mềm. Tuy nhiên, giải pháp tốt vẫn là tránh sản xuất thừa hay tình trạng chờ đợi ở trên để giảm thiểu việc tồn kho đến mức thấp nhất có thể. Hành động đơn giản mà chúng ta có thể làm ngay là hãy dũng cảm “delete” những tài liệu không cần thiết không những giúp cho kho hàng của bạn nhỏ gọn mà còn giúp bạn tìm kiếm dễ dàng hơn.

Vận chuyển (Transportation) và Hành động thừa (Motion)

Đây là 2 loại lãng phí chuyên biệt trong ngành sản xuất và thật khó để liên hệ với ngành phát triển phần mềm hay kiểm thử. Tuy nhiên, mình xin được phép liên hệ 2 loại lãng phí này với việc lãng phí trong việc phân bổ đội kiểm thử cũng như mô hình kiểm thử trong dự án. Cụ thể hơn, trong kiểm thử phần mềm, thì việc tổ chức sắp xếp các thành viên trong đội kiểm thử hay giữa đội kiểm thử với các đội khác trong dự án không hợp lí dẫn đến lãng phí. Sự không hợp lí này bao gồm cả về mặt địa lí cũng như cấu trúc. Việc đội kiểm thử và đội phát triển cách xa nhau về mặt địa lí (thường thấy trong môi trường outsource) sẽ gây nhiều khó khăn trong việc giao tiếp cũng như trao đổi tài liệu, kết quả kiểm thử. Một số dự án do cách xa nhau về địa lí cùng hệ thống network phức tạp, bảo mật nhiều tầng dẫn đến việc nhận build, cài đặt, kiểm thử, gửi kết quả kiểm thử, debug gặp rất nhiều thời gian và công sức. Việc đưa nhân viên onsite đào tạo hay thăm nom đội dự án giữa 2 bên cũng gây nhiều tốn kém. Ngoài vấn đề khó khăn về địa lí thì việc bố trí đội kiểm thử như là gatekeeper (“người canh cổng”) cho toàn bộ quy trình cũng gây lãng phí nguồn lực. Đội kiểm thử lúc này chỉ đóng vai trò như là người tìm lỗi và tham gia rất ít (hoặc không tham gia) vào quá trình ngăn lỗi. Ngoài những vấn đề nêu trên thì các mô hình quản lí kiểm thử rườm rà phức tạp như quá nhiều vòng kiểm và duyệt dư thừa cho các hoạt động kiểm thử cũng gây lãng phí nhiều thời gian.

Nếu có thể thì nên bố trí đội kiểm thử và đội phát triển “gần nhau” để dễ dàng cũng như giảm thiểu, chi phí trao đổi thông tin. Mô hình phát triển phần mềm linh hoạt (Agile) đã làm rất tốt về mặt này khi góp gần giảm bớt những hoạt động, quy trình không mang lại giá trị và tập trung vào những thứ mang lại giá trị thiết thực cho dự án.

Quy trình thừa (Over-processing)

over_process

Một số dự án nhỏ nhưng vì để “bằng chị bằng anh” đã áp dụng quy trình, mô hình quản lí như CMMI, ISO để quản lí dự án. Kết quả là thời gian mà đội kiểm thử dành để tạo, cập nhật tài liệu, báo cáo còn nhiều hơn thời gian thực tế dành cho công việc kiểm thử. Một ví dụ khác có thể nhìn thấy là vấn đề kiểm thử tự động. Nhiều người lầm tưởng là kiểm thử tự động là tiên tiến là hiện đại nên nhất quyết phải kiểm thử tự động cho bằng được mặc dù bản chất của sản phẩm không phù hợp với kiểm thử tự động hoặc chi phí bỏ ra để kiểm thử tự động lớn hơn giá trị thu về. Nguyên nhân dẫn đến tình trạng trên một phần xuất phát từ cái gọi là “quy trình chuẩn” hay “best practice” cùng góc nhìn chủ quan dựa trên những kinh nghiệm thành công trong quá khứ. Những quy trình chuẩn và những thành công mà chúng ta có được với dự án trước, công ty trước không đồng nghĩa là chúng ta sẽ lại áp dụng thành công ở dự án, công ty hiện tại. Vì bản chất dự án là khác nhau, con người khác nhau, thời điểm khác nhau, môi trường văn hóa công ty khác nhau.

Trước khi ứng dụng 1 quy trình, mô hình hay ứng dụng, chúng ta nên cân nhắc xem liệu “chiếc áo” ta sắp mặc vào có quá to so với mình hay không mặc dù nó rất vừa và đẹp với người khác. Tương tự, cũng nên cân nhắc xem liệu chúng ta có thật sự cần những công cụ quản lí kiểm thử như QC, JIRA, Bugzilla, Rally hay nhu cầu thực sự của chúng ta chỉ là 1 file Excel.

Lời kết

Bài viết nói về 7 lãng phí trong kiểm thử phần mềm dựa trên 7 lãng phí trong sản xuất tinh gọn nhưng điều này không có nghĩa là chúng ta chỉ có 7 lãng phí (tất nhiên rồi). Hãy nhìn vào dự án của mình, nhìn vào các hoạt động kiểm thử chúng ta làm mỗi ngày, các quy trình kiểm thử và xem xem liệu chúng ta có đang lãng phí điều gì không. Lãng phí không nhất thiết gây hại cho dự án nhưng việc định ra và loại bỏ những lãng phí là một trong hoạt động quan trọng trong cải tiến quy trình để hướng đến mục tiêu làm việc hiệu quả và tiết kiệm.

Bạn có quan điểm khác về lãng phí trong kiểm thử phần mềm? Rất vui nếu nhận được ý kiến đóng góp của các bạn.

Bài viết có tham khảo:

http://en.wikipedia.org/wiki/Muda_(Japanese_term)

http://en.wikipedia.org/wiki/Lean_manufacturing#Types_of_waste

http://www.proftest.nl/artikelen/LTM_TE_16_12_11.pdf

Bài viết gốc được đăng tải tại vntesters.com

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev

Cách xử lý dữ liệu trong quá trình làm việc với framework

framework
Cách xử lý dữ liệu trong quá trình làm việc với framework

Framework là một tập hợp chứa các thư viện phần mềm, các dữ liệu liên quan, các trình biên dịch, diễn dịch hoặc các API. Framework tạo ra một nền tảng, môi trường để công việc lập trình của các Data Scientist trở nên nhanh chóng và hiệu quả hơn.

  10 Java Web Framework tốt nhất
  Framework có đang giết chết sự sáng tạo trong thiết kế Web?

Về diễn giả

  • Anh Trương Bảo Duy hiện là Data Scientist Manager tại Công ty HEINEKEN Vietnam.
  • Anh đã từng làm việc với vai trò là một Academic Research, Data Scientist ở Tiki. Anh có bằng cử nhân về Công nghệ thông tin và thạc sĩ trong lĩnh vực kinh tế.

Framework dành cho ai và có thể làm được gì?

Những ai nên sử dụng framework?

Framework là sản phẩm chủ yếu dành cho những leader, manager và những bạn lần đầu tiên set-up data sciences, chưa có nhiều kinh nghiệm và không biết nên bắt đầu như thế nào cho hợp lí. Framework cũng hỗ trợ các team data sciences đã có finding và đang muốn apply nó vào sản phẩm.

Bên cạnh đó, framework cũng sẽ giúp cho những bạn làm Data Analyst, Data Scientist và những bạn lần đầu tham gia vào một start-up đang muốn tìm hiểu xem một Data Science Project nên vận hành như thế nào.

Framework có thể hỗ trợ những công việc nào?

Bạn đã từng làm việc ở vị trí manager, leader, và có background về data engineer, data scientist nhưng khi tham gia vào một công ty mới, một môi trường hoàn toàn mới thì sẽ có rất nhiều vấn đề phát sinh mà bạn cần phải giải quyết, những vấn đề mà đôi khi những kiến thức trước đó không thể hỗ trợ được.

framework
Tận dụng kỹ năng của bản thân giúp quá trình làm việc tốt nhất

Đó có thể là data thuộc về nhiều product, nhiều platform khác nhau, thuộc về nhiều team khác nhau cũng như có data owner khác nhau. Hoặc cũng có thể nó liên quan đến chất lượng data. Ngoài ra, đối với các start-up, framework cũng hỗ trợ rất nhiều trong quá trình xây dựng Data Science Project. Với các FMCG nhưng các metrics, KPI vẫn chưa thật sự quá tốt hay những người làm việc ở đó chưa có nhiều trust trong data hoặc các team làm việc độc lập với nhau, họ không quen với teamwork, framework cũng có ảnh hưởng khá lớn.

Điều đương nhiên là framework không thể giải quyết tất cả các vấn đề này nhưng chắc chắn nó sẽ giúp cho hành trình apply data science trở nên dễ dàng hơn. Mỗi người có một background khác nhau và nếu đó là lần đầu tiên bạn setup data science thì mình nghĩ các bạn nên tập trung vào giải quyết các bài toán, các vấn đề là thế mạnh của mình. Đồng thời trong quá trình đó, bạn cũng nên apply một framework để giúp bạn build trust trong việc sử dụng data ở công ty của mình nhiều hơn.

Quá trình làm việc với framework diễn ra như thế nào?

1. Power Decisions

Nếu đã có kinh nghiệm làm việc ở vị trí Data Scientist, bạn sẽ biết được tầm quan trọng của việc xác định được câu hỏi chính xác cần giải quyết có ý nghĩa quan trọng như thế nào. Đây cũng là bước đầu tiên mà bạn cần giải quyết – Power decisions. Trong bước này bạn sẽ kết nối các business owner lại với nhau và cùng brainstorm để xác định đâu là những vấn đề mà công ty đang gặp phải, và câu hỏi nên được đặt ra để giải quyết ở đây là gì.

Chẳng hạn như ở Heineken, mỗi năm Heineken có rất nhiều chương trình cho khách hàng của mình. Các business owner là đối tác với Heineken, thường là Head of a Function hay team, câu hỏi chính của họ sẽ liên quan tới các projects do họ đang quản lý. Các business owner thường rất giỏi trong việc planning và execution nhưng việc optimization lại không phải là chuyên môn của họ nên team anh sẽ tham gia vào project để support họ. Các data analyst hoặc data scientist sẽ thông qua việc phân tích câu hỏi để có thể dùng data giải quyết vấn đề. Khi bạn có thể nắm được vấn đề và hiểu được mình nên giải quyết chuyện gì cho khách hàng thì đó đã là một phần thành công trong project này rồi.

framework
Xác định chính xác câu hỏi cần giải quyết sẽ định hướng hướng đi đúng đắn nhất cho dự án

2. Analytics và modelling

Đây là bước làm việc thứ 2, công việc ở quy trình này chủ yếu do data analyst hoặc data scientist chịu trách nhiệm. Mục tiêu chính của quá trình này là để xác định đâu là nguồn data chính cần phải sử dụng và đâu là các data owner cần liên hệ với business owner để xin data cũng như có thể điều chỉnh data lại theo đúng nhu cầu mình cần để phân tích. Kết quả cuối cùng của bước này là làm sao để translate những data, finding thành actionable insights hoặc productive models. Từ đó chúng ta có thể tiếp tục thực hiện bước thứ 3.

3. Test & Learn

Đây là một bước rất phổ biến ở các công ty công nghệ nhưng đối với các công ty như FMCG thì test & learn vẫn còn là vấn đề khá mới. Theo cá nhân mình quan sát thì khi họ phân tích data xong sẽ tìm kiếm cách scale up data lên toàn thị trường. Mình nghĩ đây là một bước có tính rủi ro khá cao vì 2 lí do.

Thứ nhất việc insights không chính xác. Trong quá trình phân tích để tìm ra insight, mọi người có thể gặp những vấn đề liên quan đến coding, hiểu sai về data, và rất nhiều vấn đề khác có thể xảy ra trong quá trình phân tích data dẫn đến insight này có thể không chính xác. Nên nếu ngay lập tức scale up data lên toàn bộ thị trường thì kết quả cuối cùng vẫn không đạt được đúng kỳ vọng và yêu cầu đề ra. Và việc đi sai hướng ngay từ đâu sẽ khiến thời gian và công sức đầu tư vào đó bị lãng phí.

Thứ hai là khi làm việc với các công ty traditional – những công ty không phải công ty công nghệ, testing cho phép team business learn chuẩn bị cho quá trình scale up. Vì thường bên anh sẽ đề xuất quy trình mới hoặc thay đổi quy trình/cách làm việc. Điều này có thể khiến cho quy trình cũ bị đổ vỡ và cần thay thế. Nếu không lường trước được những tác động của việc đổ vỡ này và tìm cách khắc phục, có thể sẽ làm business bị gián đoạn.

Xem thêm Học ngôn ngữ gì cho Data Science?

4. Scale up

Đây là bước cuối cùng và thật ra khá đơn giản. Bạn sẽ không cần nhiều sự tham gia của Data Analyst hoặc Data Scientist mà phụ thuộc phần nhiều vào Business owner. Business owner cần phải hiểu được vấn đề là sau bước test & learn thì đâu là thứ họ phải test để khi scale up họ có thể rút ra các kinh nghiệm làm việc sau này.

Đây là 4 bước cơ bản mà bạn sẽ trải qua khi làm việc với framework, tuy nhiên nó không chỉ dừng ở 4 bước này. Vì đây là 4 bước khá technical – kỹ thuật, nên để nó có thể gắn liền với business, trở thành sản phẩm không thể thiếu với business thì cách làm việc của con người đóng vai trò cực kỳ quan trọng.

Tổ chức công việc ra sao để framework vận hành trơn tru nhất?

Để làm việc hiệu quả, chúng ta cần có một Core Team gồm Data Scientist và Coordinator.

Data Scientist sẽ tập trung vào việc phân tích data, các vấn đề liên quan đến technical. Trong khi đó, Coordinator sẽ tập trung làm việc với các business. Nếu bạn làm việc ở một công ty startup hoặc công ty hoàn toàn mới chưa được setup thì Data Scientist phải làm cả công việc của Coordinator. Nhưng cá nhân mình nghĩ nên có 2 vị trí riêng biệt vì nó sẽ giúp các Data Scientist tập trung hơn vào công việc và thế mạnh của mình, nhất là khi data vẫn chưa ổn định, không thật sự clean. Data Scientist sẽ phải dành rất nhiều thời gian cho việc clean data, hiểu data, tìm kiếm insight và hiểu model với gì mình đang có.

Core team nên gặp Business Owner ít nhất một tuần hoặc 2 tuần một lần. Đây là một vấn đề cực kỳ quan trọng với hai lý do sau:

Thứ nhất, business owner là người hiểu rõ nhất về business của họ. Họ sẽ là người đưa ra đề bài nên đóng vai trò định hướng lại vấn đề trong trường hợp bạn đi chệch hướng. Ngoài ra, họ cũng sẽ đưa ra những thông tin phụ sau khi bạn bắt đầu quá trình phân tích dữ liệu.

Thứ hai, bạn cần họ tham gia vào Data Science Project vì sự thực là Data Science Project mang nặng tính kỹ thuật và đôi khi các business sẽ không hiểu được những khó khăn mà bên bạn đang gặp phải. Trong quá trình làm việc nếu họ nhận ra những khó khăn mình đang gặp hoặc có vấn đề gì với business thì họ sẽ can thiệp ngay. Đồng thời khi biết quy trình làm như thế nào thì họ có thể hiểu được và cảm nhận được tính quan trọng của công việc hơn.

framework
Core team đóng vai trò cốt lõi trong Data Science Project

Bước cuối cùng là meeting với những người mà mình tạm gọi là Framework Angels. Ở Heineken thì đây là những người thuộc về MT hoặc director. Vậy tại sao lại cần họ? Đối với những công ty nhỏ và mới thì điều này không quá quan trọng nhưng ở những công ty lâu năm, mọi thứ đã ổn định rồi thì họ sẽ giúp cho bạn nhiều thứ. Thứ nhất là họ giúp bạn làm việc với business owner tốt hơn vì đôi khi business owner họ sẽ không hiểu được tầm quan trọng của data scientist team thì các Framework Angels sẽ giúp bạn làm việc tốt hơn, họ giảm những căng thẳng giữa các team khi làm việc với nhau. Thứ hai là bạn cần những người này trong quá trình hoàn thiện và đưa sản phẩm ra thị trường, nó sẽ đảm bảo framework và project vận hành trơn tru.

Một số kinh nghiệm làm việc với framework

Trong quá trình apply framework cho công ty Heineken năm vừa rồi, team Data Scientist đã hoàn thành khoảng hơn 4 power decisions và hơn 3 triệu đô đã được actionable. Con số thực tế sẽ thấp hơn và thậm chí là thấp hơn khá nhiều ở thời điểm hiện tại vì công ty cần có thêm thời gian để build trust, bắt đầu quen dần với câu chuyện test & learn và scale up nó như thế nào nên con số mà team có thể optimize được là khoảng 10% của 3 triệu đô này.

Bài học và kinh nghiệm ở đây như mình đã chia sẻ thì bắt đầu với một câu hỏi đúng – right question thật sự rất quan trọng. Khi MT hiểu được vai trò, khả năng của team Data Science thì họ rất muốn có sự giúp đỡ của team Data Science và đôi khi những yêu cầu của họ không thật sự mang lại quá nhiều giá trị so với scale của công ty. Hoặc khả năng scalable của project khá lớn nhưng nó bắt đầu với một câu hỏi, tức là không tập trung vào một kpi nhất định, không thể giải quyết được các bài toán với những data mà công ty đang có thì việc thất bại là rất dễ xảy ra.

Xem thêm Chuyện nghề: Data Scientist là gì? Và hành trình để trở thành Data Scientist

Đôi khi business sẽ không thể hiểu được những vấn đề mà Data Scientists đang gặp phải nên khi làm việc, chúng ta nên cố gắng tìm ra vấn đề cần phải giải quyết ngay từ đầu. Vì đây thật sự là việc vô cùng quan trọng và cần thiết. Bên cạnh đó, việc chọn một business owner phù hợp cũng quan trọng không kém. Trong quá trình mình làm việc ở Heineken, đã có trường hợp business owner khiến mình nhận ra không ít vấn đề. Họ rất thông hiểu về business của họ và vấn đề mà mình đang cố gắng giải quyết.

Nhưng vấn đề ở đây là business owner không phải là người đưa ra quyết định cuối cùng, dẫn đến việc người phải đưa ra quyết định onboard quá trễ, họ không thể hiểu được toàn bộ dự án là như thế nào và không đồng ý đưa ra quyết định cuối cùng. Chính điều này khiến cho project này bị đình trệ hoàn toàn và không mang lại nhiều giá trị cho công ty nữa. Vậy nên để làm việc hiệu quả, bạn nên cố gắng tìm một business owner vừa hiểu về business vừa có khả năng make final decision. Hoặc nếu không có người như vậy trong tổ chức của bạn thì bạn nên cố gắng kết hợp 2 người như vậy với nhau để đảm bảo là đến cuối project nó sẽ được scale lên.

Thứ 3 là vấn đề testing, với Data Scientist thì đây là việc phải làm. Nó sẽ giúp bạn hạn chế rất nhiều rủi ro trong quá trình làm việc và scale up.

Thứ 4 là MT endorsement. Như mình đã chia sẻ trước đó là khi organization càng lớn và càng có nhiều phòng ban thì khi đó Data Science Project sẽ cần sự phối hợp của nhiều phòng ban lại với nhau. Nếu bạn không có support từ những high manager thì việc team work khi làm việc không hiệu quả. Sự tương tác giữa các MT với nhau giúp cho cỗ máy làm việc hoạt động hiệu quả nhất.

Bài viết được trích dẫn từ phần trình bày của anh Trương Bảo Duy tại sự kiện Vietnam Web Summit 2020 LIVE do TopDev tổ chức

Có thể bạn quan tâm:

Xem thêm các việc làm Developer hấp dẫn tại TopDev

Các câu lệnh kiểm tra repository trong Git

Các câu lệnh kiểm tra repository trong Git

Bài viết được sự cho phép của tác giả Kien Dang Chung

Trong quá trình làm việc với Git, chúng ta cần phải kiểm tra các trạng thái hiện tại hay các ghi log của kho lưu trữ, Git hỗ trợ các câu lệnh đủ mạnh để đáp ứng tất cả các yêu cầu này.

git status

Câu lệnh git status hiển thị trạng thái working directory và staging area, nó cho phép xem các thay đổi trong staging area, các file nào được track. Git status không hiển thị bất kỳ thông tin nào liên quan đến commit. Câu lệnh này cũng gợi ý các bước làm tiếp theo khi bạn thực hiện, ví dụ như với file untrack nó sẽ gợi ý bạn track bằng lệnh git add hoặc với file đã track có thể chuyển về untrack bằng git rm. Git status bỏ qua các thư mục, file được liệt kê trong .gitignore. Chúng ta cùng xem ví dụ về git status:

Các câu lệnh kiểm tra repository trong Git

Trong ví dụ trên, lần đầu sử dụng git status sẽ thấy thông báo file index.html đã được track và được thay đổi, nó cũng gợi ý có thể sử dụng git add để cập nhật vào staging area, hoặc git checkout — để bỏ qua các thay đổi trong working directory. Sau đó, git add sẽ ghi nhận lại các thay đổi vào staging area và chúng ta xem git status lần thứ hai thì thấy không còn gì cần làm.

git log

Các câu lệnh kiểm tra repository trong Git

Câu lệnh git log sẽ hiển thị các staging area snapshot đã được commit, nó cho bạn thấy danh sách các lịch sử thay đổi của dự án, cho phép lọc hoặc tìm kiếm các thay đổi. Git log và git status khác nhau ở chỗ, git status cho thấy trạng thái của working directory và staging area trong khi đó git log chỉ làm việc với các lần commit.

Các câu lệnh kiểm tra repository trong Git

Câu lệnh git log có rất nhiều các tùy chọn khác nhau:

  • git log -n : chỉ hiển thị log cho lần commit gần nhất.
  • git log –online: hiển thị mỗi log commit trên một dòng, sẽ không có thông tin như author và date được hiển thị.
  • git log –stat: hiển thị log commit chi tiết hơn với các file nào thay đổi và số lần git add, nếu danh sách quá dài, khi thoát cần nhấn tổ hợp Shift + ZZ.
  • git log -p: hiển thị log commit chi tiết –stat với các dòng thay đổi trong từng file được hiển thị, Shift + ZZ để thoát nếu danh sách quá dài.
  • git log –author=””: hiển thị các log commit của người thực hiện xác định.
  • git log –grep=””
  • git log ..: hiển thị các log commit trong khoảng từ đến , hai tham số này đều là các ID của mỗi lần commit.
  10 Vấn đề về Git thường gặp và Giải pháp
  12 điều cực "cool" mà bạn có thể làm với Github

Các tùy chọn có thể kết hợp với nhau tạo thành các truy vấn log commit phức tạp theo yêu cầu, ví dụ:

git log --author="kiendang@allaravel.com" -p index.html

Kết quả như sau:

Các câu lệnh kiểm tra repository trong Git

git show

git show <commit_id> dùng để xem chi tiết một commit. Câu lệnh git show có thể được sử dụng để xem rất nhiều các dạng đối tượng khác nhau, bạn xem chi tiết git show ở đây. Trong khuôn khổ bài viết chúng ta chỉ tìm hiểu git show ở góc độ xem chi tiết một commit. Trước hết để xem chi tiết, chúng ta cần lấy ID của commit bằng git log –oneline.

Các câu lệnh kiểm tra repository trong Git

git diff

Trong project cần rất nhiều lần thay đổi, làm chủ các thay đổi này giúp bạn quản lý dự án tốt hơn. Các câu lệnh git status, git log chỉ cho bạn thấy được một phần thông tin, với git diff bạn sẽ có được thông tin một cách tường tận nhất. git diff cho phép bạn so sánh các phiên bản khác nhau của một file.

  • git diff HEAD : So sánh file trong local repository với working directory.
  • git diff : So sánh file trong staging area với working directory.
  • git diff –cached : So sánh file trong staging area với local repository.
  • git diff <commit_id_1>..<commit_id_2>: So sánh file trong hai lần commit khác nhau.

Câu lệnh git diff được sử dụng rất nhiều trong quản lý phiên bản, có lẽ đây là một trong những câu lệnh được sử dụng nhiều nhất. Chúng ta cùng xem ví dụ được thực hiện git diff cùng các tùy chọn.

Các câu lệnh kiểm tra repository trong Git

Lời kết

Với các câu lệnh git status, git log, git show, git diff chúng ta đã kiểm soát được trạng thái và tìm ra sự khác biệt giữa các phiên bản khác nhau. Dựa vào các thông tin này chúng ta hoàn toàn quản lý được phiên bản một cách tốt nhất. Trong các bài viết tiếp theo chúng ta sẽ tìm hiểu về cách thức quay trở lại các phiên bản khác nhau cùng với các vấn đề khác khi làm việc trên Git.

Bài viết gốc được đăng tải tại allaravel.com

Có thể bạn quan tâm:

Xem thêm IT Jobs for Developer hấp dẫn trên TopDev

Thư mời phỏng vấn? Bật mí tips viết thư mời phỏng vấn hiệu quả 

thư mời phỏng vấn
thư mời phỏng vấn

Thư mời phỏng vấn là loại hồ sơ quan trọng được nhà tuyển dụng gửi đến các ứng viên sau quá trình dài chọn lọc CV. Sau khi cân nhắc và xét chọn dựa trên các tiêu chí đề ra, những thư mời phỏng vấn sẽ được thông báo cho các ứng viên tiềm năng nhất. Và không quá để nói rằng thư mời phỏng vấn là một trong những yếu tố đại diện bộ mặt của tổ chức/doanh nghiệp.

Nội dung của thư mời interview luôn là vấn đề được nhiều người quan tâm. Vậy hiểu thế nào là một thư mời phỏng vấn đúng chuẩn? Đâu là những điêm cần lưu ý khi viết thư mời phỏng vấn? Bí quyết nào giúp cho nhà tuyển dụng tạo ra các thư mời thật sự có hiệu quả. Cùng TopDev tìm hiểu thông qua bài viết sau.

Thư mời phỏng vấn là gì?

Thư mời phỏng vấn (hay còn gọi là Interview Invitation Email) là lá thư được gửi đến ứng viên sau vòng xét duyệt hồ sơ CV.

Mục đích chính là thông báo đến các ứng viên được chọn đi tiếp “thứ thách tuyển dụng” để trao đổi; khai thác thêm các vấn đề xoay quanh ứng viên.

Đây là loại thư mời quan trọng và được nhà tuyển dụng chú trọng. Thực tế cho thấy, có nhiều hình thức thông báo như gọi điện trực tiếp. Song, quá trình tuyển dụng cần tối ưu hóa và việc gửi thư mời qua email là cách thức hữu hiệu.

thư mời phỏng vấn
Thư mời phỏng vấn – Interview là gì?

Với loại thư này, ứng viên có thể chấp nhận hoặc không; hoặc có thể linh động chọn khác. Phía nhân sự tuyển dụng bên công ty nếu biết cách thiết lập một email chuyên nghiệp với đầy đủ thông tin; văn phong thu hút sẽ tạo ra ấn tượng mạnh với các ứng viên.

Đó cũng chính là cơ sở giúp các tổ chức/doanh ghi điểm trong việc tạo dấu ấn; khiến tỉ lệ ứng viên apply các vị trí lên một mức đáng kể.

Tại sao thư mời phỏng vấn lại trở nên quan trọng?

Đơn giản vì thư mời phỏng vấn là lá thư mời gọi. Nó có giá trị tạo điểm nhấn và liệu ứng viên có phản hồi hay không cũng phụ thuộc một phần vào thư mời này. Thư mời giúp kết nối ứng viên, thông báo sự tiếp diễn trong một quá trình. Từ đó, dẫn đến vòng phỏng vấn cuối cùng sẽ hiệu quả và thành công hơn.

Để giúp mẫu thư mời interview hiệu qủa, người soạn cần phải quan tâm đến nội dung; các mong muốn cần được truyền tải một cách khoa học nhưng vẫn dễ hiểu. Đặc biệt, mẫu thư mời không quá dài dòng. Nó cần thỏa mãn các tiêu chí về tính ngắn gọn, súc tích.

Bố cục nội dung của một thư mời phỏng vấn chuẩn

Thư mời cần rõ ràng về nội dụng. Trình tự logic rất quan trọng đối với mẫu thư mời phỏng vấn. Hãy đảm bảo rằng checklist dưới đây các bạn đã xem và áp dụng một cách phù hợp:

thư mời phỏng vấn
thư mời phỏng vấn

1. Tiêu đề email trong thư mời phỏng vấn

Đảm bảo tính chính xác, đặc biệt khi bạn sử dụng template email cho sẵn. Mẫu template cần ở định dạng chuẩn. Đừng gửi sai email hoặc gửi nhầm. Đó là sai lầm thể hiện sự thiếu chuyên nghiệp dẫn đến tổ chức sẽ bị mất điểm trong mắt các ứng viên.

Vd: THƯ MỜI PHỎNG VẤN

2. Chia sẻ lời cảm ơn ứng viên

Dù đây được xem là yếu tố formal nhưng nó cần phải có. Và bắt buộc phải có trong mỗi mẫu thư mời interview. Đặc biệt, nó lại là nội dung quan trọng trước khi dẫn đến các nội dung trọng tâm khác.

Hãy dành vài dóng đầu tiên để dành lời cảm ơn đối với ứng viên. Cảm ơn vì họ đã quan tâm đến công ty và dành sự đầu tư tâm sức cho vị trí ứng tuyển trong thời gian dài vừa qua.

Lời chia sẻ có thể kèm thông tin của người tới nhận phỏng vấn bao gồm: họ và tên, địa chỉ email, số điện thoại xác nhận…

3. Thông tin về cách thức phỏng vấn

Nếu phỏng vấn qua điện thoại hoặc Skype, bạn sẽ phải cung cấp trước cho ứng viên số điện thoại hoặc tài khoản Skype cho họ; hoặc phỏng vấn qua Google thì cần có mã,…

4. Thông tin về những người liên hệ và các lưu ý kèm xác nhận của công ty/doanh nghiệp

Đây là những phần nhỏ nhưng sẽ cho thấy sự kỹ lưỡng, tính chuyên nghiệp trong khâu tổ chức, quản lý và kiểm soát quá trình tuyển dụng dành cho ứng viên.

Ứng viên có thể bị lạc đường hoặc nhớ nhầm thời gian, bạn phải có những giải pháp back-up trước cho ứng viên. 

5. Thông tin chính thức về công ty

Website, fanpage,… Đây được xem là các kênh giúp tăng mức độ nhận diện. Đồng thời, thông qua nguồn thông tin được chia sẻ, ứng viên có thể tìm hiểu cơ bản về các giá trị mà công ty đang định hướng. Đây cũng là một nước đi tốt giúp ứng viên tự tin hơn trong buổi phỏng vấn sắp tới.

  Cách viết thư trả lời kết quả phỏng vấn siêu chuẩn

Những lưu ý khi gửi mẫu thư mời phỏng vấn cho ứng viên

Để tạo ra những thuận lợi cho quá trình phỏng vấn, TopDev gửi đên bạn đọc những tips sau đây. Cần thật sự lưu tâm vì đây đều là những lưu ý quan trọng.

– Thời gian cần đảm bảo tính khả thi: Thời gian hiệu quả nhất được tính từ lúc gửi thư mới đến thời điểm diễn ra phỏng vấn là khoảng 5 – 7 ngày. Điều này đảm bảo giải quyết các rủi ro có thể xảy ra. Ví dụ như nhiều ứng viên nhảy việc, họ cần một khoảng thời gian để sắp xếp xin nghỉ và tham gia phỏng vấn.

– Phần trọng tâm nội dung ban đầu cần phải nhắc đến ứng viên. Không đi quá xa vào các khía cạnh khai thác thông tin khác.

– Nên nhắc lại vị trí ứng tuyển. Điều này giúp tạo lại ấn tượng về vị trí ứng tuyển của ứng viên. Vì thực tế, ứng viên có thể đã gửi đơn apply rất nhiều nơi tuyển dụng khác nhau.

– Các thông tin về thời gian, địa điểm, cách thức phỏng vấn đều phải rõ ràng, cụ thể tránh mơ hồ khiến ứng viên thiếu hụt thông tin và dẫn đến hoang mang..

– Kiểm tra lỗi chính tả, văn phong trong email trước khi gửi mẫu thư mời cho ứng viên trước khi gửi.

– Phía tuyển dụng của tổ chức/doanh nghiệp cần gọi điện thoại để thông báo cho ứng viên sau khi gửi thư mời tham dự phỏng vấn. 2-6 giờ sau khi gửi email thông báo, bạn có thể gọi để nhắc các ứng viên lần 1.

  Hướng Dẫn Trả Lời Thư Mời Phỏng Vấn Với Nhà Tuyển Dụng

Mẫu thư mời phỏng vấn đẹp nhất

Mỗi mẫu thư mời đều phải được xây dựng trên một trình tự nội dung chuẩn. Ngoài ra, hình thức của mỗi thư mời cũng đặc biệt quan trọng. Tương tự như bất kỳ loại văn bản nào: sơ yếu lý lịch cho IT, đơn xin nghỉ việc,… thư mời phỏng vấn cũng được xem xét là loại thư mời cần thiết cho quy trình tuyển dụng.

Nó không đơn thuần là một bản thông báo có hiệu lực ngắn hạn được đính kèm trong email. Nó có ý nghĩa quan trọng đối với quy trình tuyển dụng. Nhờ có thư mời phỏng vấn, ứng viên có thể đánh giá sơ bộ tổ chức/doanh nghiệp của mình như thế nào. 

Cùng TopDev điểm qua một số mẫu thư mời chuẩn nhất sau đây:

thư mời phỏng vấn
M1 – thư mời
thư mời phỏng vấn
M2 – thư mời
thư mời phỏng vấn
M3 – thư mời

Lời kết

Thư mời phỏng vấn là một trong những loại văn bản quan trọng. Ít người chú trọng đến nó những khi phân tích kỹ, thư mời interview có lại yếu tố chi phối đến mức độ ứng viên đồng ý tham gia buổi phỏng vấn cuối cùng. TopDev hi vọng với những chia sẻ, mọi người sẽ hiểu được tầm quan trọng của thư mời interview. Đồng thời, biết cách viết thư mời sao cho hiệu quả, hấp dẫn ứng viên; tạo ra sự kết nối tốt nhất đến với những ứng viên tiềm năng nhất.

Tuyển Dụng Nhân Tài IT Cùng TopDev
Đăng ký nhận ưu đãi & tư vấn về các giải pháp Tuyển dụng IT & Xây dựng Thương hiệu tuyển dụng ngay!
Hotline: 028.6273.3496 – Email: contact@topdev.vn
Dịch vụ: https://topdev.vn/page/products

Có thể bạn quan tâm:

Xem thêm việc làm it lương cao hàng đầu tại TopDev

Lập trình viên tài năng nhất chỉ cách bạn bảy bước chân

Lập trình viên tài năng nhất chỉ cách bạn bảy bước chân

Bài viết được sự cho phép của tác giả Trần Thị Thu Hà

Sau vài ba năm chinh chiến trong nghề lập trình, chợt nhìn lại thấy đám bạn học cùng đại học giờ đã lên level Tech Lead rồi Manager, mình thì vẫn đi code dạo kiếm tiền. Cùng một xuất phát điểm, nhưng họ thành công hơn bạn. Thực tế, bạn chỉ đứng cách họ 7 bước chân thôi!

“Làm cách nào để thành công với nghề lập trình?” Một chút hài hước, dường như trong chính câu hỏi của các bạn, đã có câu trả lời. Sẽ chẳng có cách nào dễ dàng có thể biến bạn từ một người không biết gì về code trở thành một lập trình viên tài ba cả. Nếu có, thì chắc nó cũng nằm đâu đó trong “7 bước chân” topITworks sắp chia sẻ dưới đây. Quan trọng là bạn có sẵn sàng bước hay không?

  10 câu nói cực hay về lập trình
  10 lý do cho thấy tại sao bạn nên theo học ngôn ngữ lập trình Java

1. Học ở trường Đại học, không phải là tất cả.

Các bạn phải thừa nhận một điều rằng, trường học chỉ cung cấp các kiến thức cơ bản, họ đào tạo lý thuyết chứ không phải chuyên môn có thể giúp bạn trở thành một lập trình viên giỏi. Và đó là lý do hầu hết các lập trình viên giỏi khi còn trẻ không đốt thời gian bằng cách ngồi trên ghế nhà trường trong thời gian còn đi học. Hãy bước ra ngoài và tham gia một vài dự án product nhỏ để lấy kinh nghiệm thực tế. Sẽ có rất nhiều điều bạn cần phải học đấy.

Thực tế, đa phần các chương trình ở trường đại học đều gặp khó khăn trong việc theo kịp sự thay đổi của công nghệ. Trong 1 đến 3 năm đầu, một tấm bằng mà bạn mua được bằng tiền và thời gian có thể giúp bạn kiếm được một công việc giúp bạn đủ sống nhưng từ sau đó, bằng cấp sẽ chẳng tạo ra sự khác biệt nào cả. Các công ty không phải lúc nào cũng căn cứ vào tấm bằng, nhất là đối với những người đã ra trường được một thời gian.

Thế nên, nếu bạn muốn vứt tiền và thời gian vào những bằng cấp này thì tôi khuyên bạn đừng suy nghĩ nhiều về việc trở thành một coder giỏi!

2. Bắt đầu lại với những ngôn ngữ cơ bản nhất.

Nếu bạn muốn nâng cao khả năng code, hãy bắt đầu với những ngôn ngữ lập trình đơn giản nhất. JavaScript là lựa chọn tuyệt nhất cho những ai muốn hiểu sâu hơn về ngôn ngữ lập trình. Đây gần như là ngôn ngữ tiêu chuẩn của nền tảng web và cũng được sử dụng để viết các ứng dụng di động. Bạn thậm chí còn có thể sử dụng JavaScript để viết các ứng dụng cho robot, máy bay không người lái và trò chơi. Khi bạn đã thành thạo những ngôn ngữ cơ bản, việc nâng cao khả năng với các ngôn ngữ khó hơn chỉ còn là vấn đề thời gian.

3. Cách tốt nhất để học code là hãy code đi!

Ở những ngành khác, người ta chọn đọc nhiều sách để nâng cao trình độ chuyên môn. Điều đó đúng, nhưng không phải ở ngành công nghệ thông tin. Cho dù bạn có đọc 100 cuốn sách về lập trình và các ngôn ngữ đi chăng nữa, mà chẳng đụng tay đến máy tính coding lấy một dòng, thì tôi tin chắc rằng bạn sẽ chẳng bao giờ khá lên.

Điều tôi có thể khuyên bạn là : hãy đọc ít thôi và dành thời gian cho các bài luyện tập thực sự, từ đơn giản đến phức tạp. Thay vì đọc những câu chuyện từ sách vở, viết code sẽ giúp bạn nhớ lâu hơn và ở những lỗi sai, bạn mới thực sự hiểu bạn đang cần học thêm gì để giúp việc coding của mình khá hơn.

4. Học từ những người bạn.

Một trong những cách tuyệt vời  nhất để học lập trình là xem cách người khác code và quan sát cách họ tư duy cũng như giải quyết vấn đề.

Tốt nhất là hãy tìm một người giỏi hơn bạn hoặc một người có cùng đam mê như bạn và thử lập trình cặp (pair-programming – hai lập trình viên cùng làm việc chỉ trên một máy tính). Tin tôi đi, một vấn đề dưới góc nhìn của mỗi người sẽ có cách giải quyết khác nhau, code cũng vậy. Bạn sẽ học được khá nhiều điều thú vị từ những người ấy. Chỉ cần một thời gian áp dụng, khả năng code của bạn sẽ tốt lên một cách bất ngờ. Đây cũng là cách mà hầu hết những lập trình viên trẻ trên thế giới áp dụng để nâng cao khả năng của mình trong một khoản thời gian ngắn.

5. Đọc và viết blog công nghệ.

Khi bắt đầu viết blog, tôi chắc chắn rằng, mình không là chuyên gia hàng đầu trong lĩnh vực mà tôi chia sẻ đến bạn đọc. Tôi thậm chí còn không thể chắc chắn rằng mọi thứ tôi viết đều đúng. Tôi mắc phải lỗi và nhận được phản hồi từ những người đọc. Nhưng cũng từ những phản hồi này tôi có thể nâng cao kiến thức và kỹ năng của mình. Chính việc chia sẻ những hiểu biết của mình cho cộng đồng tôi mới nhận ra rằng có những việc, nếu không bao giờ chia sẻ với mọi người, bạn sẽ chẳng biết được mình đã sai ở đâu mà cần thay đổi cả.

Mỗi tuần topITworks Blog của tôi có khoảng 3-5 bài viết mới, mỗi bài viết có trung bình khoảng gần 4,000 lượt quan tâm. Bạn có theo dõi hàng tuần không? Vài thứ hay ho bạn không muốn bỏ lỡ đâu: www.topITworks.com/blogs

Lập trình viên tài năng nhất chỉ cách bạn bảy bước chân

6. Học bằng cách dạy người khác.

Nếu bạn  đã là một lập trình viên thì tôi dám chắc chắn bạn cũng đã biết điều này: công nghệ thay đổi và những điều bạn biết ngày hôm nay có thể sẽ biến mất sau một tháng. Vì vậy việc cập nhật xu hướng công nghệ mới là điều hết sức cần thiết cho các lập trình viên. Và nếu bạn không phải là một người có trí nhớ siêu phàm thì khả năng bạn quên những thứ mới học được sau 1 vài tháng là điều khó tránh khỏi.

Thay vào đó, cố gắng truyền đạt cho ai đó những gì bạn biết là một cách tuyệt vời giúp bạn nhớ tốt hơn. Khi nói về những hiểu biết của mình bạn cũng sẽ tự mình đặt ra nhiều câu hỏi hơn cho bản thân. Và trong nhiều trường hợp bạn nhận ra được nhiều kiến thức “có vẻ” như bạn đã hoàn toàn hiểu trước đó lại là những thứ bạn cần phải đào sâu hơn.

7. Học nhiều hơn một ngôn ngữ lập trình.

Tôi đề xuất bạn đọc cuốn “Seven Languages in SevenWeeks” (tạm dịch: 7 ngôn ngữ trong 7 tuần). Học các ngôn ngữ với các triết lý khác nhau sẽ giúp bạn biết thêm nhiều hướng khi nghĩ về một vấn đề. Cởi mở tâm trí và mở rộng khả năng sáng tạo.

Tuy nhiên, hãy lên kế hoạch để tập trung vào JavaScript trước khi học thêm các ngôn ngữ khác nhé. Muốn giỏi một cái gì đó, hãy chắc rằng bạn đã hiểu rõ bản chất của nó.

Bài viết gốc được đăng tải tại smartjob.vn

Có thể bạn quan tâm:

Truy cập ngay việc làm IT đãi ngộ tốt trên TopDev

Capacity Planning – Dự toán công suất cho ứng dụng (Tập 1 )

Bài viết được sự cho phép của tác giả Edward Thiên Hoàng

Một trong những công việc cuối cùng trong khâu thiết kế hệ thống sau khi đã hoàn thành khâu logical design là dự toán công suất vật lý của hệ thống để xem cần bao nhiêu máy chủ, (v)CPU, RAM, Disk, network bandwidth là bao nhiêu để hệ thống có thể hoạt động đủ mượt nhưng không quá nhàn rỗi dẫn đến lãng phí tài nguyên. Hiện nay với xu hướng người người, nhà nhà đi lên Cloud để tận dụng khả năng elastic, auto-scaling thì có vẻ là công việc này sẽ nhẹ nhàng hơn, nhưng lại có những challenge khác liên quan đến việc thiết kế ứng dụng để làm sao scale được. Trong phạm vi bài viết này, hãy cùng xem xét về góc cạnh dự toán công suất cho ứng dụng.

  Giải mã bí ẩn "system load" trên Linux
  System Design Cơ Bản - Consistent Hashing

1. GIỚI THIỆU

Khả năng xác định hoặc dự báo khả năng của một hệ thống hoặc tập hợp các thành phần, thường được gọi là ‘sizing’ của một hệ thống, là một hoạt động quan trọng trong thiết kế hệ thống. Một hệ thống với công suất quá khổ sẽ dẫn đến chi phí vượt trội về tài nguyên phần cứng, trong khi công suất quá thấp có thể dẫn đến giảm hiệu suất và không có khả năng để phục vụ mục đích của nó. Hãy tưởng tượng một nhà cung cấp thương mại điện tử sẽ hết bộ nhớ vào Black Friday hoặc một nhà cung cấp công cụ tìm kiếm phải trả gấp 20 lần chi phí cho công suất tối ưu của họ – cả hai kịch bản rõ ràng những nhà dự toán, kiến trúc sư phải xem xét kỹ hơn.

Lập kế hoạch công suất trong thiết kế hệ thống là nghệ thuật cũng như khoa học. Cùng với các tham số nhất định, nó cũng cần đến kinh nghiệm, kiến ​​thức về lĩnh vực kinh doanh và kiến ​​thức bên trong hệ thống. Trong một số trường hợp, chúng ta còn phải phân tích tâm lý của người của hệ thống, mô hình sử dụng của họ, v.v.

2. CÁC CHỈ SỐ HOẠCH ĐỊNH CÔNG SUẤT

Có nhiều phương pháp để thực hiện dự toán công suất. Bài viết này đề cập đến một số chỉ số tập trung vào cách các yếu tố như tính đồng thời, giao dịch mỗi giây (TPS), công việc được thực hiện trên mỗi giao dịch, v.v. Tất nhiên, nhiều yếu tố khác có thể xác định khả năng của một hệ thống, bao gồm sự phức tạp của các giao dịch, độ trễ và các cuộc gọi service bên ngoài, phân bổ và sử dụng bộ nhớ, v.v.

Cách tốt nhất là kiểm tra hiệu năng của hệ thống của bạn để xem liệu nó có hoạt động với công suất dự kiến hay không khi bạn đã thiết lập hệ thống theo phán đoán kế hoạch công suất, sau đó sẽ có những điều chỉnh kịp thời, lấy đó làm kinh nghiệm cho những lần lập kế hoạch tiếp theo.

Chúng ta hãy xem xét chi tiết một số các chỉ số này dưới đây.

2.1 THÔNG LƯỢNG (THROUGHPUT) VÀ TPS

Thông thường thông lượng được xác định là số lượng transaction được xử lý trong một khoảng thời gian nhất định. Thông lượng là thước đo số lượng hành động trên một đơn vị thời gian, trong đó thời gian có thể tính bằng giây, phút, giờ, v.v. TPS (Transaction Per Second) là số lượng giao dịch trên mỗi giây. Đối với một máy chủ stateless, đây sẽ là đặc điểm chính ảnh hưởng đến dung lượng máy chủ.

Về mặt lý thuyết, nếu người dùng thực hiện 60 giao dịch trong một phút, thì TPS sẽ là 60/60 TPS = 1 TPS. Tất nhiên, vì tất cả người dùng đồng thời đăng nhập vào hệ thống có thể không nhất thiết phải sử dụng hệ thống đó tại thời điểm nhất định, điều này có thể không chính xác. Ngoài ra, thời gian suy nghĩ, trì hoãn (think time) cũng nên được xem xét. Nhưng loại bỏ những điều trên, đây có thể được coi là trung bình 1 TPS khi người dùng truy cập thống nhất hệ thống trong hơn 60 giây.

2.2 CÔNG VIỆC ĐƯỢC THỰC HIỆN TRÊN MỖI GIAO DỊCH

Mỗi ‘giao dịch’ đến máy chủ sẽ có một số mức độ hoạt động để hoàn thành giao dịch đó. Điều này có nghĩa là CPU sẽ được kích hoạt để xử lý transaction bao gồm xử lý ứng dụng cũng như các hoạt động hệ thống như truy cập cơ sở dữ liệu, truy cập hệ thống bên ngoài, v.v. Nếu giao dịch đơn giản, điều đó có nghĩa là yêu cầu xử lý tương đối ít hơn so với giao dịch kích hoạt một tập hợp các hoạt động tiếp theo. Một sơ đồ trình tự của giao dịch sẽ giúp xác định các hoạt động thực tế có liên quan đến giao dịch.

2.3 THỜI GIAN SUY NGHĨ (THINK TIME)

Từ góc độ ứng dụng web, người dùng gửi yêu cầu, sau đó được xử lý ở phía máy chủ trước khi trả lại cho người dùng. Sau đó, người dùng thường chờ phản hồi và ‘xử lý, suy nghĩ’ trước khi gửi yêu cầu tiếp theo. Sự chậm trễ này là thời gian suy nghĩ của người dùng, rơi vào giữa các yêu cầu và có thể được tính đến khi tính toán tải hệ thống tối ưu. Đối với giao tiếp giữa máy với máy, thông số thời gian nghĩ này sẽ tương đối thấp hơn. Đối với lập dự toán công suất, thời gian suy nghĩ trung bình là hữu ích trong việc tính toán thông lượng chính xác.

2.4 NGƯỜI DÙNG TÍCH CỰC (ACTIVE USERS) VÀ ĐỒNG THỜI (CONCURRENT USERS HAY CCU)

Một hệ thống sẽ có tổng số người dùng – điều này có thể không ảnh hưởng trực tiếp đến công suất máy chủ, nhưng là một số liệu quan trọng trong việc định kích thước cho cơ sở dữ liệu. Trong tổng số nhóm người dùng này, một tập hợp con trong số họ sẽ là người dùng hoạt động – người dùng sử dụng hệ thống tại một thời điểm nhất định. Thông thường người dùng hoạt động đăng nhập vào một hệ thống, thực hiện một số thao tác và đăng xuất; hoặc họ chỉ để hệ thống hoạt động, đến lượt nó sẽ logout người dùng ra sau khi phiên hết hạn (thường trong 30 phút hoặc lâu hơn).

Capacity Planning - Dự toán công suất cho ứng dụng (Tập 1 )

Hình 1: Users in Capacity Planning

Người dùng hoạt động đồng thời là số lượng người dùng riêng biệt truy cập đồng thời vào hệ thống tại bất kỳ thời điểm nào. Như trong ví dụ trong hình ở trên, người dùng đồng thời là một tập hợp con của những người dùng đang hoạt động đang sử dụng hệ thống tại một thời điểm nhất định. Nếu 200 người dùng hoạt động được đăng nhập vào hệ thống và có thời gian suy nghĩ 10 giây, thì đó sẽ là khoảng 20 người dùng đồng thời thực sự tấn công hệ thống. Trong dự toán công suất, điều này có một số ý nghĩa. Trong một máy chủ ứng dụng stateful với các session tương ứng cho từng user, số lượng người dùng đồng thời sẽ đóng vai trò lớn hơn việc xử lý stateless. Đối với các hệ thống được thiết kế theo cách như vậy, mỗi người dùng đồng thời tiêu thụ một số mức bộ nhớ cần phải được tính đến.

Thông thường, thông lượng của hệ thống tăng theo số lượng người dùng đồng thời cho đến khi đạt được công suất tối đa như trong Hình 2; từ đó trở đi hệ thống sẽ bị suy giảm hiệu năng. Do đó, điều quan trọng là phải tính toán số lượng user đồng thời tối đa mà một hệ thống có thể xử lý.

Capacity Planning - Dự toán công suất cho ứng dụng (Tập 1 )

Hình 2: Server Performance – Throughput

2.5 KÍCH THƯỚC MESSAGE

Kích thước của message của các request cũng là một yếu tố quan trọng trong việc xác định dung lượng cần thiết của một hệ thống. Mesage với kích thước lớn hơn có nghĩa là yêu cầu năng lượng xử lý nhiều hơn, yêu cầu bộ nhớ nhiều hơn. Là một cơ sở để lập dự toán công suất, các kích thước message như bảng dưới đây nên được xem xét.

Message size range Message size category
Less than 50 KB Small
Between 50 KB and 1 MB Moderate
Between 1 MB and 5 MB Large
Larger than 5 MB Extra Large

Hình 3: Message Sizes

2.6 ĐỘ TRỄ (LATENCY)

Độ trễ là thời gian bổ sung của hệ thống để thực hiện các thao tác. Các yêu cầu phi chức năng (Non-functional requirements – NFRs) của một hệ thống thường sẽ chỉ ra thời gian đáp ứng mong muốn của một giao dịch mà sau đó một hệ thống phải cố gắng đáp ứng. Xem xét ví dụ trong Hình 4, nếu một transaction đơn lẻ thực hiện một số lệnh gọi xuống cơ sở dữ liệu hoặc một tập hợp các lệnh gọi web service đồng bộ, transaction phải ‘chờ’ để nhận phản hồi. Điều này sau đó sẽ thêm vào thời gian phản hồi tổng thể của transaction.

Capacity Planning - Dự toán công suất cho ứng dụng (Tập 1 )

Hình 4: Server Performance – Latency

Các kỹ thuật như bộ nhớ đệm có thể được sử dụng để cải thiện thời gian trễ.

Độ trễ thường là từ máy khách và cũng cần tính đến chi phí mạng / băng thông.

2.7 CÁC YÊU CẦU PHI CHỨC NĂNG KHÁC

Các yêu cầu về chất lượng dịch vụ (Quality of service – QoS), cùng với các yêu cầu phi chức năng khác, sẽ có ảnh hưởng đến cách bạn lập dự toán công suất. Ví dụ, nếu việc gửi message được đảm bảo (guaranteed delivery) hoặc việc truyền message an toàn (secure) là một yêu cầu bắt buộc, điều này sẽ ảnh hưởng đến hiệu suất chung của hệ thống và cũng cần phải được tính đến. Tương tự, nếu giải pháp với nhiều hệ thống với nhiều công suất khác nhau, thì cũng cần thực hiện một số điều chỉnh (throttling) giữa các hệ thống đó để tránh tình trạng thắt cổ chai (bottleneck).

Một khía cạnh khác cần được xem xét là tính sẵn sàng hoặc thời gian hoạt động của hệ thống. Về lý thuyết, tính khả dụng được xác định là tỷ lệ phần trăm khả dụng của hệ thống trong một năm. Lưu ý mặc dù tính khả dụng và thời gian hoạt động không đồng nghĩa – hệ thống có thể hoạt động, nhưng có thể không sẵn sàng để chấp nhận các yêu cầu, trong trường hợp đó hệ thống không khả dụng.

Thời gian chết (downtime) hệ thống được chấp nhận là một yêu cầu thực tế, thường được tìm thấy như một phần của các yêu cầu không chức năng. Điều này trực tiếp xác định làm thế nào một hệ thống có tính sẵn sàng cao cần thiết kế. Khi tính toán dung lượng, điều quan trọng là phải tính đến thời gian ngừng hoạt động theo kế hoạch, chẳng hạn như nâng cấp hệ thống và triển khai ứng dụng và thời gian ngừng hoạt động ngoài dự kiến, chẳng hạn như sự cố máy chủ.

Tính khả dụng của một hệ thống được xác định theo phương trình sau, mang lại kết quả tỷ lệ %.

x = (n – y) * 100 / n

trong đó ‘n’ là tổng số phút trong một tháng theo lịch nhất định và ‘y’ là tổng số phút dịch vụ không khả dụng trong một tháng theo lịch nhất định.

Availability(%) Downtime per year Downtime per month Downtime per week
90% (“one nine”) 36.5 days 72 hours 16.8 hours
95% 18.25 days 36 hours 8.4 hours
97% 10.96 days 21.6 hours 5.04 hours
98% 7.30 days 14.4 hours 3.36 hours
99% (“two nines”) 3.65 days 7.20 hours 1.68 hours
99.5% 1.83 days 3.60 hours 50.4 minutes
99.8% 17.52 hours 86.23 minutes 20.16 minutes
99.9% 8.76 hours 43.8 minutes 10.1 minutes
99.95% 4.38 hours 21.56 minutes 5.04 minutes
99.99% (“four nines”) 52.56 minutes 4.32 minutes 1.01 minutes

Hình 5: Availability Numbers

Source: Wikipedia – http://en.wikipedia.org/wiki/High_availability

3. DỰ BÁO YÊU CẦU NĂNG LỰC

Với các khái niệm trên (Hình 5), doanh nghiệp cần quyết định thời gian dự báo là gì. Bạn chỉ tập trung vào năm thứ nhất? Liệu các yêu cầu về năng lực sẽ tăng gấp đôi trong năm thứ hai, và nếu vậy sẽ có một thời gian chết đáng kể vào cuối năm thứ nhất để đáp ứng điều này? Một bảng, chẳng hạn như bảng được đưa ra trong Hình 6, sẽ hữu ích cho việc dự báo và có thể dựa trên các xu hướng trong quá khứ và dự báo kinh doanh trong tương lai.

Parameter Year 1 Year 2 Year 3 Year 4
TPS 50 500 1000 2500
Concurrent Users 20 100 500 1000

Figure 6: Capacity Forecasting for 4 Years

Bài viết tham khảo từ: https://wso2.com/whitepapers/capacity-planning-for-application-design-part-1/

Bài viết gốc được đăng tải tại edwardthienhoang.wordpress.com

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev

Tại sao mình lại chuyển từ WordPress sang Ghost?

Tại sao mình lại chuyển từ Wordpress sang Ghost

Bài viết được sự cho phép của tác giả Trần Khôi Nguyên Hoàng

WordPress là một CMS cực kỳ lớn và nổi tiếng. Đã số các blog đều sử dụng WordPress để cho tiện trong việc config và hosting. Bản thân cái blog của mình cũng sử dụng WordPress. Nhưng hôm nay thì mình đã chuyển toàn bộ nền tảng blog qua một CMS khác là Ghost. Và mình vừa chuyển qua nên mình làm cái review cho vui nhé.‌‌

  10 trang web hàng đầu để tìm hiểu WordPress
  Cấu hình Redis Caching để tăng tốc site WordPress của bạn

Ghost là gì?

Tại sao mình lại chuyển từ WordPress sang Ghost?

Ghost là một Blog Platform mã nguồn mở sử dụng NodeJS.

Nói một cách ngắn gọn thì Ghost nó tương tự như WordPress vậy. Nhưng mà nó không có nhiều tính năng mặc định như của WordPress.

Trang chủ của Ghost: https://ghost.org/

Link Demo: https://demo.ghost.io/

‌‌Ủa? Nếu mà ít tinh năng hơn thì sao không xài WordPress đi, còn bày đặt chuyên platform làm chi vậy?

Tại mình thích

Thích là lý do chính mình chọn Ghost. Khi mỗi lần có ai đó muốn làm một blog cá nhân thì đa số mọi người đều gợi ý nên làm WordPress đi. Mình thì mình thích cái gì đó lạ lạ hơn, cái gì mà ít người làm thì mình làm. Và khi biết là có Platform này thì đã thử chuyển sang đây. Và để mình review một chút về Platform này nhé.

Điểm mạnh

Cài đặt đơn giản.

Nếu như với WordPress thì bạn cần một LAMP stack và source code WordPress thì với Ghost chỉ cần NodeJS là đủ. Ngay cả khi là nếu muốn deploy lên server thì nó vẫn đơn giản hơn WordPress.

Mình thì mình sử dụng 1 Click App của Digital Ocean nên cái nào với mình cũng như nhau. Có SSL các thứ luôn. Xịn xò con bò.

Không cần cài plugin

WordPress đã từng là một Blog Platform. Nhưng hiện tại thì không phải nữa mà nó có thể làm nhiều hơn là Blog. Chính vì vậy mình phải setup một số thứ để viết Blog. Ví dụ như cài Anti Spam, Yoast SEO, hay W3 Total Cache. Với Ghost thì không cần. Nó đã tự làm hết mọi thứ cho việc viết rồi. Mình lười trong chuyện tìm hiểu xem nên cài Plugin nào rồi Config ra làm sao lắm. Tốn thời gian mà không có lợi gì nhiều.

Phù hợp với IT blog

Ghost có một cái editor rất mạnh, gần giống như của Medium vậy. Nó cực kỳ phù hợp cho những bạn viết Blog nói chung và cực kỳ phù hợp cho các bạn viết Blog IT nói riêng. Lý do chính là các IT blogger có thể chèn code vào blog một cách đơn giản và đẹp. Điều mà bên WordPress không có hoặc phải cài thêm Plugin vào để có Syntax Highlighter. Nhưng dù có thì vẫn không thể ngon được bằng thằng Ghost. Bên cạnh đó tình năng chèn ảnh, chèn YouTube video, chèn codepen cũng ngon hơn WordPress rất nhiều.

Nhanh, rất nhanh

NodeJS và PHP so sánh về tốc độ thì khỏi phải bàn nhỉ. Blog mình hồi còn dùng WordPress thì chậm không tả được. Điểm số của Google PageSpeed Insights thì đâu đó được 9 hay 10/100 gì đó. Chả hiểu sao. Sau khi cài thêm mấy cái Plugin để Cache thì lên được 50 – 60/100. Còn với Ghost thì toàn 90 95/100 không à.

Tại sao mình lại chuyển từ WordPress sang Ghost?
Tại sao mình lại chuyển từ WordPress sang Ghost?

Toàn 99 100 thôi

Điểm yếu

Gõ tiếng việt rất sida

Ghost có một bộ editor ngon nhưng việc gõ tiếng việt rất là sida. Mình chưa thử trên Window thì như nào nhưng ở Ubuntu, Ibus Teni và Firefox thì không gõ được. Còn với Chrome thì gõ được nhưng vẫn sida lắm. Phải setup thêm Google Font thì mới tạm tạm gõ được một chút.

Không có Dashboard, Category cũng như khung comment mặc định

Ghost không hề có trang Dashboard dùng để thông kê lượt truy cập hay gì cả. Mình có thể sử dụng Google Analytic để xem nhưng cũng lằng nhằn lắm.

Một điều nữa là nó không có khung comment mặc định. Mình phải tự code thêm tính năng này hoặc dùng của bên thứ ba. Mà mình thì lười lắm. Cơ bản là cũng không có ai vào đọc mà comment ấy chứ :))

Một cái sida nữa là nó không có Category, mà nó quản lý chuyên mục bằng các thẻ  Tag. Vì thế nên không có Menu đa cấp mặc đinh. Cũng phải tự code thêm.

Theme ít và rất đắt

Thằng này Theme rất ít, hơn nữa còn lại đắt dã man. Toàn mấy chục đô Trump thôi. Nên mình xài theme mặc định luôn. Thế là OK rồi.

Tại sao mình lại chuyển từ WordPress sang Ghost?
Nhìn kho theme mà chán

‌‌Kết luận

Sau một vào giờ setup thằng này thì mình khá là hài lòng. Các bạn nào chưa viết blog thì bật máy và làm một cái blog đi thôi nào.

Bài viết gốc được đăng tải tại htknguyen.com

Có thể bạn quan tâm:

Xem thêm Tìm việc làm WordPress hấp dẫn trên TopDev

Lập trình viên biết test có giá như thế nào?

Lập trình viên biết test có giá như thế nào?

Bài viết được sự cho phép của tác giả Kiên Nguyễn

Chà, căng nhỉ lập trình viên biết test. Đã dev rồi còn test nữa thì nghe khá là căng. Hiển nhiên là mấy bạn mới ra trường hoặc có 1,2 năm kinh nghiệm chắc chắn sẽ từ chối hiểu. LOL

mà phân trần thì cũng có lý chứ không phải là không có lý.

  • Tester tuyển dụng yêu cầu gì?
  • Công ty tuyển tester vào làm gì mà đội dev phải test.
  • Nhiệm vụ là dev thì cứ dev thôi, test làm gì?

Hiểu, chắc chắn là hiểu cái lý do trình bày này. Nhưng thử phân tích thêm 2,3 cái lý do dưới đây. Nếu nghe xuôi tai thì test cũng còn chưa muộn.

1. Test không hẳn là một công việc nhàm chán

Thực sự thì test là tìm ra lỗi trong sản phẩm. Tiến hành khắc phục, hoặc bịt bug :). Nghĩ thoáng ra một tí thì test làm cho sản phẩm tốt hơn, hoàn hảo hơi.

Bản thân mình tìm thấy bug là một điều may mắn, khách hàng sẽ không bị crash, không gặp bug mà phải cau có mặt mày.

Đôi khi bản thân được gọi là “Software Engineer” – “Kỹ sư phần mềm”. Từ kỹ sư ở đây không khác gì kỹ sư xây dựng, kỹ sư cầu đường. Xây nhà lại để sập, xây cầu để cầu gãy?. Làm gì có chuyện đó đúng không?.

Để cầu không gãy, nhà không sâp thì ta cần ông giám sát công trình. Bên Software thì ta có chị QC, anh QA. Nhưng không cần chị QC, anh QA, bản thân SE cũng có thể test được. Vì vậy phải xác định trước, test là việc nên làm để đảm bảo chất lượng. BUG là niềm vui. Má, nghe nổi da gà.

Đùa chứ mấy anh lập trình viên biết test lại được đánh giá cao. Được tin tưởng giao task khó và bớt thời gian test do trong lúc dev đã test rồi

2. Test giúp nâng skill lập trình

Nhiều ông cứ bảo tôi điêu. Nhưng thử ra ngoài hỏi xem, có ông nào trình cao mà chưa đi fix bug khó không. Fix bug thực sự hữu ích, nâng skill rất nhanh. Nhanh bởi vì sao:

  • Fix bug đôi khi không phải chỉ hiểu một đoạn code, hiểu cả hệ thống.
  • Fix bug đôi khi liên quan tới cả business
  • Fix bug đòi hỏi phải hiểu rõ chức năng hiện tại, vấn đề tương lai

Đấy, fix bug nâng tầm, mà bug thì không phải từ test mà ra sao?. Các ông tìm được bug khi test -> nhớ -> lần sau sẽ chú ý dev kĩ hơn.

  04 Điều Cần Chú Ý Cho Người Mới Làm Automation Test
  Cách Engineer Nhật Bản thực hiện test như thế nào

3. Không thể cover hết testcase

Một số trường hợp phát sinh bug. Bản thân Software Engineer có thể biết điều đó, nhưng tester thì không. Theo pattern đôi khi không thể cover hết tất cả các key.

Tôi còn gặp mấy ông code xong thách tester tìm bug, vì bản thân mấy ông đó biết là testcase không thể chạm tới bug đó.

Chính vì vậy, ngay lúc này bản thân Dev cần bắt tay vào test, hoặc ít nhất là nói với tester về khả năng có thể xảy ra case đó trong thực tế. Biết hoặc viết ra sẽ dễ hơn dể tìm và diệt bug.

Nếu cũng nghĩ về chất lượng sản phẩm thì sẽ gạt bỏ được bất đồng (đôi khi thôi)

Đấy, lập trình viên biết test hoặc có kinh nghiệm test cũng được được đánh giá cao hơn trong mắt nhà tuyển dụng.

4. Lập trình viên biết test được đánh giá cao

Trên đây là một số lý do tại sao lập trình viên lại nên test thử cho biết. Rõ ràng mà nói, test hay không test thì bug vẫn là thứ ảnh hưởng tới sản phẩm. Một số bug cơ bản tuy không chết ai. Nhưng nếu viết firmware cho thiết bị y tế có thể đi cả mạng người.

Rèn luyện kỹ năng test giúp Software Engineer có thể thực thụ trở thành một người Senior. Hiểu biết sâu sắc về nghề, tường tận quy trình phát triển phầm mềm. Nên anh em cố mà test nha!

5. Tham khảo

Còn có một trường phái viết test trường khi dev để đảm bảo cover hết case nữa cơ

Thank for your attention – Good day to test – Happy coding!

Bài viết gốc được đăng tải tại kieblog.vn

Có thể bạn quan tâm:

Truy cập ngay việc làm IT đãi ngộ tốt trên TopDev

Quá trình bước chân vào con đường freelancer – P1 (Khởi đầu)

Quá trình bước chân vào con đường freelancer

Bài viết được sự cho phép của tác giả Tin Tran

Năm 2020 vừa qua là một năm thực sự khó khăn với nhiều quốc gia trên thế giới, do ảnh hưởng của dịch covid gây ra, ngành công nghệ thông tin cũng chịu ảnh hưởng không nhỏ, các công ty outsource cho Châu Âu, Nhật Bản đang ít các dự án dần vì dịch, một số công ty đã giảm lương và sa thải nhân viên, nên một số bạn lập trình viên cũng đang gặp khó khăn, tuy nhiên chúng ta đã bước sang năm 2021, thông tin về vắc xin cũng đang được thử nghiệm, chúc các đọc giả năm 2021 này sẽ gặp được nhiều thành công trong công việc cũng như trong cuộc sống.
Trở lại với loạt bài viết chia sẻ về quá trình bước chân vào con đường làm freelancer này, tôi sẽ chia sẻ về quá trình làm freelancer, nhận dự án, báo giá, các kiểu khách hàng gặp phải. Với bài khởi đầu này tôi sẽ nói tổng quan về vì sao tôi chọn làm freelancer, những lợi ích khi làm freelancer và khó khăn gặp phải.

  Freelancer IT là gì? Những điều thú vị về Freelancer lập trình
  Những kỹ năng cần thiết cho freelancer

Nếu mọi người đã đọc bài viết về tâm sự lập trình của tôi thì cũng biết ngoài công việc trên công ty thì tôi cũng làm freelancer vào buổi tối và cuối tuần. Lý do tôi chọn freelancer là vì ngoài kiếm tiền ra thì tôi cũng học hỏi được rất nhiều điều thú vị về các dự án, có thể ở công ty bạn chỉ làm những dự án theo kiểu rập khuôn và không đa dạng về nghiệp vụ. Nhưng với freelancer thì bạn sẽ nhận được nhiều yêu cầu mà có thể bạn chưa từng nghe bao giờ.

1. Freelancer là gì?

Nãy giờ nói lan man về freelancer, nhưng có thể có một số bạn chưa hiểu về khái niệm này, freelancer là một người làm công việc tự do, không gò bó bởi công ty, hoàn toàn kiểm soát thời gian làm việc của mình, hoàn toàn có thể chọn nơi làm việc mà mình thích. Freelancer có hai loại. Thứ nhất là làm freelancer toàn thời gian, loại này sẽ không làm ở bất cứ một công ty nào cả, chỉ nhận dự án và làm tự do. Loại thứ hai là làm ở một công ty nào đó, buổi tối và cuối tuần thì sẽ làm freelancer, tôi là loại thứ hai.

2. Lợi ích của làm freelancer là gì?

– Kiếm được tiền : Tiền thì chắc ai cũng cần để trang trải cuộc sống, đối với những người đã có vợ con thì lúc nào cũng sẽ cảm thấy thiếu tiền hoặc đối với những người chưa có nhà cửa ở các thành phố lớn thì cũng cần phải cày cuốc để kiếm tiền mua nhà, mua xe…
– Giúp nâng cao skill bản thân : Từ một thằng có skill kém nhưng từ khi làm freelancer thì đã tăng được nhiều kỹ năng về giải quyết vấn đề, kỹ năng search, kỹ năng phân tích và còn nhiều skill khác nữa. Công việc freelancer là làm việc độc lập, nên việc tự tìm hiểu nhiều thứ là điều tất nhiên, khi bạn tìm hiểu một vấn đề nào đó thì nó sẽ tích lũy dần theo năm tháng.

– Tăng tính tự giác : Việc tự học một ngôn ngữ, kỹ thuật nào đó thì sẽ rất lười biếng tuy nhiên khi đã làm dự án với khách hàng thật, lấy tiền thật thì việc tự giác tìm hiểu, học ngôn ngữ mới hay học thêm nhiều cái khác để đáp ứng nhu cầu công việc thì rất tự giác.
– Quản lý được thời gian công việc : Khi bạn làm freelancer bạn phải tự cân đo đong đếm thời gian làm để hoàn thành dự án và giao hàng. Việc này rất quan trọng vì vừa phải cân bằng được thời gian làm ở công ty vừa cân bằng được thời gian làm freelancer mà không làm hại sức khỏe là một bài toán khó.

3. Nhược điểm của freelancer

Ngoài những lợi ích đem lại thì khi bạn là một freelancer thì sẽ có những nhược điểm không mong muốn.
– Không được đi đâu chơi : Nếu làm freelancer có dự án liên tục thì việc đi chơi với người yêu, đi nhậu nhẹt với bạn bè là điều không thể, vì phần lớn thời gian bạn sẽ chạy dự án, khi đã ngồi vào bàn làm việc rồi thì việc ra ngoài là điều rất khó đối với các bạn lập trình viên.

– Mất ngủ, mệt mỏi, căng thẳng : Việc không quản lý được thời gian làm việc sẽ dẫn đến bạn phải thức đêm thức hôm để làm việc, dẫn đến mệt mỏi căng thẳng, stress, cáu gắt. Sức khỏe lúc này suy giảm.
– Những dự án thúi quắc : Đôi khi nhận dự án, báo giá xong tới khi làm thì mới phát sinh ra nhiều vấn đề, lúc này không thể báo giá lại được nữa và chấp nhận làm chịu lỗ.
– Bị xù tiền, chậm thanh toán : Vì một số lý do nào đó mà khách hàng không thanh toán phần còn lại của dự án hoặc châm thanh toán, có những dự án 5-6 tháng mới thanh toán xong.

Những lợi ích và nhược điểm khi dấn thân vào con đường freelancer ở trên mà tôi đã đúc kết được từ quá trình của mình, các bạn đã sẵn sàng đi vào con đường này hay chưa, bài viết tiếp theo tôi sẽ chia sẻ về dự án freelancer đầu tiên của mình, hãy đón đọc nhé.

Bài viết gốc được đăng tải tại chickencodes.com

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev

Message queue là gì?

message queue là gì
Message queue là gì?

Bài viết được sự cho phép của tác giả Lê Chí Dũng

Message Queue là một thành phần quan trọng thường sử dụng trong các hệ thống lớn (Ví dụ Yahoo, Tiki) hoặc phần mềm theo kiến trúc microservice.

Tuy vậy, nếu không gặp các dự án có hệ thống lớn thì sẽ không biết rõ Message Queue là gì, được sử dụng với mục đích gì!

  Messaging App sẽ định hình lại E-commerce
  Xây dựng ứng dụng realtime messaging bằng Firebase như TikTok, Bigo...

Messege Queue là gì?

Message Queue nôm na là Queue (hàng đợi), chứa Message (Tin nhắn) như hộp thư 😀 Và nó cho phép các thành phần/service trong một hệ thống (hoặc nhiều hệ thống), trao đổi thông tin cho nhau.

Ý nghĩa của queue (hàng đợi) là nó thực hiện việc lấy message theo cơ chế vào trước thì ra trước ( First In First Out ).

Một hệ thống Message Queue thường có những thành phần sau:

  • Message: Thông tin được gửi (có thể là text, binary hoặc JSON)
  • Message Queue: Nơi chứa những message này, cho phép producer và consumer có thể trao đổi với nhau
  • Producer: Service tạo ra thông tin, đưa thông tin vào message queue
  • Consumer: Service nhận message từ message queue và xử lý
  • Một service có thể vừa làm producer, vừa làm consumer 

Một số Message queue được dùng hiện nay:

  • Kafka
  • Pulsar
  • RabitMQ
  • ActiveMQ
  • SQS
  • ZeroMQ
  • MSMQ
  • IronMQ
  • Kinesis
  • RocketMQ

Thực tế Message Queue được sử dụng thế nào?

Trong các hệ thống dùng kiến trúc microservice, ta sử dụng message queue để giúp các service liên hệ với nhau một cách bất đồng bộ. Service X làm xong việc có thể gửi message queue để service Y kích hoạt xử lý.

Ví dụ: có một trang web cho phép người dùng tải video từ hệ thống thì nó sẽ có các thành phần sau:

  • API service: Là 1 producer. Nhận thông tin (URL Video) từ phía người dùng và đưa thông tin này vào message queue
  • Processing Service: Vừa là consumer vừa là producer. Service này đọc URL Video từ message queue, bắt đầu tải file Video về và encode lại, lưu vào server. Sau khi encode xong, nó đưa URL của file đã encode vào message queue
  • Uploading Service:  Khi nhận được message từ processing server, nó sẽ upload video đó lên Amazon S3

Tại sao lại sử dụng Message Queue?

Ưu điểm về Message Queue

  • Dễ scaling hệ thống: Vào giờ cao điểm, nhiều truy vấn, ta có thể tăng số lượng consumer lên để xử lý được nhiều messege hơn. Khi không cần ta có thể giảm lại.
  • Phân tán hệ thống: Giúp phân tách hệ thống thành nhiều service nhỏ hơn, mỗi service chỉ xử lý 1 chức năng nhất định theo cấu trúc microservice.
  • Đảm bảo duration/recovery: Do message đã được lưu trong queue, khi 1 service đang xử lý nhưng bị crash, ta không lo bị mất data vì có thể lấy message từ trong queue ra và retry. Trong 1 hệ thống có nhiều consumer, nếu vài consume crash cũng không làm crash cả hệ thống
  • Hỗ trợ rate limit, batch process: Trong trường hợp khả năng xử lý của hệ thống có hạn (chỉ có thể xử lý 100 lượt release/s) mà phải xử lý 10000 lượt release. Với message queue, ta có thể lấy từng lượt release chưa xử lý trong queue ra xử lý từ từ, không sợ bị mất.

Điểm cần lưu ý về Message Queue

  • Làm hệ thống phức tạp hơn: Thêm message queue sẽ tăng tính phức tạp của hệ thống.  Ta cần phải biết rõ message nào gửi vào queue nào, ai gửi ai nhận. Lúc debug ở local sẽ khó khăn hơn
  • Phải có Monitor Queue: Phải có các biện phát theo dõi (monitor), để đảm bảo lượng message queue không quá nhiều, làm đầy queue. Queue tốt nhất là queue luôn rỗng, hoặc số lượng message trong queue không tăng lên nhiều (message gửi vào queue đều bị consume hết trong thời gian ngắn nhất)
  • Phải có message format: Để gửi/nhận từ 2 phía producer và consumer thống nhất format với nhau. Nếu 1 bên thay đổi sẽ làm bên kia không đọc được dữ liệu.
  • Khó xử lý đồng bộ: Không phải hệ thống nào cũng cần tới message queue. Nếu như service A gọi service B, theo cơ chế đồng bộ, cần kết quả xử lý ngay, ta nên dùng Rest hoặc gRPC sẽ tốt hơn.

Bài viết gốc được đăng tải tại lcdung.top

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev

Cách viết một bug report tốt

Bài viết được sự cho phép của vntesters.com

Report bug là công việc thường xuyên và liên tục của một người làm test. Nhưng đã bao giờ bạn nghĩ mình có thể làm gì để một bug report trở nên hoàn chỉnh, ngắn gọn cũng như thể hiện sự chuyên nghiệp và rõ ràng trong từng report được gởi ra cho Dev? Hay nói một cách khác bạn đã bao giờ nghĩ làm sao để viết một bug report tốt.

  Bài học cho các Developer sau lỗi bug video từ Facebook
  Debug là gì?

Bài này mình chia sẻ những kinh nghiệm của bản thân trong việc làm sao để viết một bug report tốt. Hy vọng sẽ giúp ích cho các bạn.

Một mẫu report bug tham khảo

Bug ID: ————-
Date: —————
Assigned to:———
Status: ————-

Title: ————————————–
Summary/Description: ————————
Environments (OS/Browser): ——————
Step to reproduce:
1.
2.
3.

Actual results: —————————–
Expected results: —————————
Severity: ———————————–
Priority Level: —————————–

Tiêu đề (Bug Title)

  • Miên tả ngắn gọn, thể hiện được lỗi. Tiêu đề tốt còn có thể giúp Dev biết được lỗi mà không cần xem các bước bên trong
  • Có thể sử dụng cấu trúc dạng: What…When/Where…. Thể hiễn lỗi trước sau đó đến vị trí của lỗi
  • Không nói chung chung

Ví dụ:

  • Good Title: Missing the username & password label at Login form
  • Good Title: [Authentication] The logout button does not clickable at Homepage
  • Bad Title: The logout button does not work
  • Bad Title: Something wrong with the register function

Mô tả lỗi (Summary)

Đây là nơi bạn có thể diễn tả rõ hơn về lỗi, không giống như tiêu đề bị gò bó bởi chiều dài, tại summary bạn có thể diễn tả dài hơn.

Tuy nhiên nếu lỗi đơn giản bạn có thể không cần ghì hoặc sao chép lại tiêu đề. Không nhất thiết phải cố gắng diễn tả dài dòng khi lỗi nó chỉ cần chừng đó thông tin là đủ.

Các bước tái tạo (Reproduce / Steps)

  • Các bước nên đánh thứ tự 1-2-3
  • Ngắn gọn, diễn tả một hành động, không nên ghi dài
  • Đảm bảo các bước đúng thứ tự và có thể tái tạo được

Ví dụ:

  1. Enter admin email
  2. Enter admin password
  3. Click on change profile
  4. Upload the photo with GIF format
  5. Check the uploaded photo

Một số trường (field) thường gặp

Actual / Expected (Kết quả thật tế / Kết quả mong muốn)

  • Ngắn gọn
  • Thể hiện chính xác mong muốn trong phần expected.

Bad Expected: Change the text color

Good Expected: Change the text color to red (#E52121)

Bad Expected: Add the label to username

Good Expected: Add the label “Username” to the username field.

Một chú ý nhỏ nữa nhưng cũng góp phần quan trọng trong việc tạo cảm giác tốt cho dev là tránh ghi trực tiếp và đề cập đến con người trong đó.

Không nên: You need to fix the bug

Nên: The bug should be fixed

Không nên: Can you change the header text to bold?

Nên: The header text color should be in bold.

Các viết thứ hai sẽ không đề cập đến con người (You need, you must…) mà chỉ tập trung vào vấn đề.

Gợi ý:

  • Nên đính kèm ảnh, hình ảnh sẽ giúp Dev hiểu rõ vấn đề hơn, đôi khi không cần đọc các bước.
  • Hạn chế video: khá nặng và tốn nhiều thời gian để xem, chỉ dùng trong các lỗi phức tạp.
  • Phân biệt và dùng đúng mức độ priority và severity.
  • Không phải các bug đều được report bằng chữ, bạn có thể report và làm việc trực tiếp với Dev. Có nhiều lỗi bạn cần và cũng nên chia sẻ thông qua giao tiếp & làm việc nhóm.
  • Kiểm tra kĩ trước khi report, tránh report trùng hoặc không phải là lỗi.
  • Không nên gộp nhiều lỗi vào 1 report, mỗi report chỉ nên xử lý một vấn đề.
  • Ghi rõ môi trường + phiên bản đang test.

Vậy tổng kết, thế nào là một bug report hiệu quả?

  1. Có thể tái tạo lại được bởi developer
  2. Ngắn ngọn, tiết kiệm thời gian
  3. Đầy đủ thông tin, hình ảnh
  4. Độc lập, có thể theo dõi được từng lỗi

Mình rất muốn nghe chia sẻ thêm từ những kinh nghiệm của các bạn trong việc viết một bug report tốt và hiệu quả, nếu có gì muốn chia sẻ hay bổ sung các bạn để lại comment nhé!

Bài viết gốc được đăng tải tại vntesters.com

Có thể bạn quan tâm:

Những kỹ năng cần có của 1 BrSE

Những kỹ năng cần có của 1 BrSE

Bài viết được sự cho phép của tác giả Nguyễn Văn Trọng

Nếu bạn đang đọc bài viết này thì chứng tỏ bạn rất quan tâm đến nghề và nghiêm túc trong con đường phát triển bản thân.

OK vậy tốt rồi ! tiếp theo đây mình xin chia sẻ 1 vài kỹ năng cần thiết mà 1 BrSE cần có, nếu bạn đang có thì hãy cố gắng trau dồi, còn nếu chưa … cũng đừng lo, cứ học từ từ sẽ được. Cách đây 5 năm mình cũng ngáo ngơ lắm cứ nhắm mắt làm chứ chả có định hướng gì, h đỡ hơn tí .. hihi. Vậy nên muốn viết ra cụ thể để các bạn xác định trước, sẽ đi đến đích nhanh hơn.

Có 3 kỹ năng chính cần thiết : cứng, mềm và ngoại ngữ.

Tham khảo các vị trí tuyển dụng Brse lương cao hấp dẫn nhất

Kỹ Năng Cứng – Hard Skill

Khi làm việc với khách hàng, tùy dự án sẽ cần có những nền tảng kỹ thuật khác nhau. Với nghề này các bạn đôi khi không được quyền lựa chọn.

Khách hàng chọn bạn chứ không phải bạn chọn khách hàng

Vậy nên hãy đầu tư cho mình kiến thức rộng về kỹ thuật (ngôn ngữ, framework …), kỹ năng design (basic design, detail design) và khả năng tự học. Vì sao cần có khả năng tự học ? đơn giản thôi, bạn phải nắm bắt thật nhanh hệ thống làm về ngôn ngữ gì, framework gì để lập ra các đối sách cũng như làm việc được ngay, không ai chờ đợi 1 vài tháng để mình học xong mới áp dụng.

1.Kỹ năng design – basic design và detail design

DesignFlowDesign Process

Đối với khách hàng Nhật, tài liệu là thứ quan trọng nhất trong dự án. Nếu các bạn đã từng làm dự án với các bác Nhật thì cũng từng trải qua việc nhai tài liệu hàng chục đến hàng sheet excel như nhai cơm trắng trước khi code. Vậy nên trong quá trình này hãy để ý đến cách làm tài liệu, rút ra những ưu nhược điểm đúc kết thành kinh nghiệm để sau này viết ra cái đống ấy.

BASIC DESIGN (hoặc system design)

Hầu hết các dự án đều phải có basic design viết ra với đầu vào tài liệu đặc tả nghiệp vụ, basic design sẽ là tiền đề để tạo Detail Design sau này.

Với những dự án winform hay web ngoài mô tả chức năng xử lý thì cần phải có Prototype. Với những dự án không phải web thì prototype được tạo bằng excel (thông thường) hoặc 1 số tool chuyên dụng – đôi khi code luôn app mô tả thao tác (hardcode), còn dự án web thì ngoài exel để mô tả flow xử lý còn cần có html prototype. Vậy nên các bạn cần chuẩn bị những thứ sau :

  • Kỹ năng vẽ sơ đồ xử lý hay tạo form bằng excel
  • Html và css để create html prototype
  • Kỹ năng giải thích process bằng câu chữ (cái này hơi khó nên cần trau dồi qua kinh nghiệm dự án – đọc design)
Basic design tốt là mô tả đầy đủ - dễ hiểu các chức năng của hệ thống

DETAIL DESIGN

Với đầu vào là basic design, detail design được tạo ra sao cho – Nhìn vào là code được. Vậy nên cần phải trang bị cho mình những kiến thức về design pattern, ngôn ngữ – framework, cấu trúc dữ liệu. Về design pattern, nếu có thời gian tìm hiểu thì quá tốt còn nếu không thì sao ? hãy nắm vững nguyên lý SOLID để cho thiết kế hoàn hảo kẻo mấy anh em cu đơ chửi cho nát mặt “thằng nào design ngu vcd !!!”.

Ngoài ra, vì trong quá trình làm sẽ xảy ra việc làm nhiều cái tương tự nhau, ví dụ như mô tả Item screen – mapping item database. Vậy nên để tăng năng suất thì hãy tự tạo các tool gen tài liệu, mình thấy dùng macro excel là dễ và nhanh nhất – quan trọng là hiệu quả chứ không cần cầu kỳ đâu. Khách hàng sẽ nhìn bạn với con mắt “thán phục” nếu như bạn có 1 vài cái tool apply cho dự án 🙂

Tóm cái váy lại những gì cần :

  • Design pattern hoặc nguyên lý SOLID
  • Ngôn ngữ, Framework : để chọn cách làm tối ưu
  • Cơ sở dữ liệu : để biết cách tương tác dữ liệu sao cho hợp lý nhất
  • Tạo tool nâng cao năng suất – vd : excel macro
Detail design tốt là mô tả đầy đủ - tối ưu - dễ hiểu, nhìn vào code được ngay

2.Kỹ thuật – công nghệ

Tùy dự án sẽ áp dụng ngôn ngữ – framework khác nhau. Vậy nên hãy nắm THẬT CHẮC 1 ngôn ngữ và 1 framework, và nắm TỔNG QUAN 1 vài ngôn ngữ – framework phổ biến, để khi cần có thể rút ngắn thời gian đào sâu nghiên cứu.

Những ngôn ngữ – framework phổ biến (khách hàng Nhật)

  • Java – Spring, Struts, Hibernate. bonus : Seasar, Jersey.
  • C# – .Net FW, MVC 3, MVC 4 …
  • Javascript – Jquery, Knockout, AngularJS, NoteJS
  • VB6, VB.Net
  • Bonus : C++ nếu các bạn thích embedded (nhu cầu C++ để làm lập trình nhúng ở nhật cực kỳ cao), COBOL (ngôn ngữ củ chuối từ xa lắc lơ mà các bác JAV vẫn dùng ầm ầm)

Vì hiện tại có rất nhiều page khác viết về mảng công nghệ kỹ rồi nên mình không nói thêm ở đây nữa.

Kỹ năng mềm

kynangmem75% thành công được quyết định bởi kỹ năng mềm

Vì sao cần ? thực ra dù làm vị trí nào thì kỹ năng mềm đều cần thiết cả, nhưng với nghề này thì cực kỳ quan trọng vì các bạn phải thường xuyên tiếp khách (tiếp xúc khách hàng – chứ ko phải bán thân :D) cũng như liên lạc thường xuyên với manager để báo cáo, PM để trao đổi tình hình dự án, Dev – giải thích nghiệp vụ, Tester – để bênh dev … giỡn chứ để đàm đạo lúc nghiệm thu sản phẩm. Đôi khi còn nhâm nhi vs cả QA hay BA nữa, nói chung là “quan hệ rộng” (rộng chứ không phải bừa bãi đâu nhé).

Hãy hòa nhã mới mọi người, cương nhu phối hợp nhịp nhàng

Cụ thể là gì ? Có hàng tá kỹ năng mềm các bạn có thể tìm thấy trong sách hay trên internet, ở đây mình chỉ liệt kê những cái thiết thực nhất đúc kết qua kinh nghiệm.

  • Biết lắng nghe

Nghe khách hàng, nghe phía nhà mình, là việc hằng ngày gặp phải. Nhưng nếu không LẮNG thì không NGHE được 1 cách đầy đủ và thấu hiểu. Nhớ nhé : lắng rồi mới nghe. Người Nhật đa số rất ghét kiểu đang nói mà bị chen ngang, hoặc là nói mà bị lơ.

  • Thuyết trình

Nói đúng hơn là cách trình bày vấn đề, nếu tiếng nhật không đủ lưu loát thì hãy viết ra những gì muốn nói theo trình tự. Có thể chọn 1 trong 2 cách trình bày :

cách 1 : Nêu bối cảnh hay tiền đề rồi sau đó đến điều cần nói.

cách 2 : Nói cái cần nói trước rồi sau đó là phần giải thích thêm.

Cách nào cũng được chỉ cần mạch lạc.

  • Làm việc độc lập

Chủ động, chủ động và chủ động. Tự lên kế hoạch công việc, báo cáo 2 bên định kỳ tình hình cho dù không được yêu cầu. Ngoài ra hãy ghi To-do list vào mỗi buổi sáng, và check lại vào cuối ngày xem đã hoàn thành đến đâu.

  • Giải quyết vấn đề

Mọi việc không phải khi nào cũng suôn sẻ, việc trễ deadline hay gặp khách hàng thay đổi requirement xoành xoạch cũng không hiếm. Vậy nên trong những trường hợp này nếu không có cách nào tốt thì hãy chọn cách đỡ xấu nhất. Năm ngoái mình đã gặp trường hợp dự án trễ liên tục vì design quá tệ hại, cũng may khách hàng hiểu vấn đề từ đầu (design họ làm mà) nên mình báo cáo hằng ngày cho họ biết chi tiết từng module bị trễ và số thời gian để hoàn thành, ban đầu  thì khá căng thẳng nhưng cuối cùng cũng xong xuôi – phù phù. Viết đến đây thấy áy náy, nước mắt rưng rưng chảy dài trên gương mặt đập chai … nhớ lại hồi đấy để keep deadline mà bắt anh em trong team OT vs ON thấy bà nội luôn … tội lỗi ! tội lỗi.

  10 Kỹ năng quan trọng cần có của Front-end để tìm công việc dễ dàng hơn
  13 mẹo có thể giúp bạn rút ngắn thời gian phát triển kỹ năng lập trình

NGOẠI NGỮ

ngoainguNgoại ngữ là quan trọng nhất với BrSE

Thực ra ngoại ngữ thuộc kỹ năng cứng nhưng mình tách ra thế này để nhằm mục đích nhấn mạnh. Dù bạn ở đâu, đang làm gì, bao nhiêu tuổi … không quan trọng bằng việc bạn có thực sự quyết tâm để hiểu được mấy em gái nhật nói gì, nhầm ! mấy bác khách hàng Nhật nói gì.

9 tháng từ Zero lên N2 ? tại sao lại không ? đã rất nhiều người làm được, nếu bạn không tin thì có thể hỏi bất kỳ 1 nhân viên công ty Fsoft là sẽ biết thực hư. trong 9 tháng này mọi người được học mỗi ngày 10 tiếng, vậy nên nếu học 1 ngày 3- 4 tiếng thì khoảng 2 năm là lên được N2 rồi.

5 phút dành cho quảng cáo :

Hiện tại công ty cũ Fsoft của mình có tuyển sinh kỹ sư cầu nối với chương trình 10K BrSE. Nếu các bạn quan tâm thì có thể đi theo hướng này cũng tốt. Chi phí hơi tốn kém chút nhưng đổi lại tiếng Nhật sẽ lên rất nhanh do được đào tạo bài bản ngay tại Nhật. Nếu muốn sau khi học xong làm được BrSE ngay thì các bạn hãy trau dồi kỹ năng cứng và mềm trước (mình viết ở trên) rồi học tiếng nhật sau thì sẽ có nhiều lựa chọn hơn.

Cảm ơn bạn đã đọc đến đây, bài dài quá trời đất. Nếu có gì sai sót hay cần bổ sung thì hãy comment ở bên dưới nhé.

Bài viết gốc được đăng tải tại kysubrse.com

Có thể bạn quan tâm:

Xem thêm Việc làm it cho Developer hấp dẫn trên TopDev

Giới thiệu chung về Postman

postman
Giới thiệu chung về Postman

Bài viết được sự cho phép của vntesters.com

Sau bao nhiêu bài chém gió linh tinh, bài giới thiệu chung về Postman này mới bắt đầu vào công cụ Postman. Nguyên nhân chính của việc ít bài là do mình bận và mình lười.

  10 kênh Youtube học lập trình không thể bỏ qua dành cho Junior Web Developer / Designer
  20 trường hợp sử dụng lệnh Docker cho developer

Bài này gồm có 3 mục chính:

  1. Ưu, nhược điểm của Postman
  2. Cài đặt Postman
  3. Các thành phần chính của Postman

1. Ưu, nhược điểm của Postman

Postman là 1 công cụ để test API của cty Postdot Technologies được bắt đầu phát triển từ năm 2012. Hiện tại Postman có 3 phiên bản: Postman, Postman Pro (2016) và Postman Enterprise (2017). Mình mới sử dụng Postman phiên bản free nên mình chỉ giới thiệu phần này.

Ưu điểm:
– Dễ sử dụng, hỗ trợ cả chạy bằng UI và non-UI.
– Hỗ trợ viết code cho assert tự động bằng Javascript.
– Hỗ trợ cả RESTful services và SOAP services.
– Có chức năng tạo API document.

Nhược điểm:
– Những bản tính phí mới hỗ trợ những tính năng advance: Làm việc theo team, support trực tiếp…

2. Cài đặt Postman

Postman cho phép người dùng cài đặt dưới 2 hình thức: tool cài vào máy và Chrome Apps.

Cài Postman vào máy:

Download tại địa chỉ https://www.getpostman.com/

Postman

Cài đặt Postman như một Chrome app (UPDATE 30/10/2017): Hiện nay Chrome không còn hỗ trợ app nữa nên phần này không còn sử dụng được

Vào link https://chrome.google.com/webstore/search/postman?hl=en-US. Sau khi cài xong Postman sẽ xuất hiện ở đây

Postman Chrome

3. Các thành phần chính của Postman

Giao diện của Postman

Postman UI

Settings: chứa các thông tin về cài đặt chung.

  • Thông tin Account: dùng để Login, logout và sync data.
  • Settings tùy chỉnh: themes, shortcut, format…
  • Import data từ ngoài vào

Postman Settings

Collections: lưu trữ thông tin của các API theo folder hoặc theo thời gian.

Postman Collections

API content: hiển thị nội dung chi tiết API và các phần hỗ trợ giúp thực hiện test API. Đây là phần mà tester phải làm việc nhiều nhất.

Postman Content

Trong phần này gồm có 3 thành phần chính:

  • Environments: Chứa các thông tin môi trường. Ví dụ: mình làm 1 dự án nhưng có 3 môi trường khác nhau: dev, staging và product. Có phần này, mình có thể nhanh chóng đổi sang môi trường cần test mà không phải mất công đổi URL của từng request. (Cái này sẽ được nói rõ hơn ở những bài sau)
  • Request: Phần chứa các thông tin chính của API. Có thể đọc lại bài API Testing – Protocol là gì
  • Response: Chứa các thông tin trả về sau khi Send Request.

Phần giới thiệu chung đến đây là kết thúc, bài sau mình sẽ bắt đầu thử với những API đầu tiên.

Bài viết giới thiệu chung về Postman này được đăng lần đâu tiên tại http://giangtester.com/. Bạn có thể download ebook API Testing với Postman của mình ở đường link này.

Bài viết gốc được đăng tải tại vntesters.com

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev

Sức mạnh của thái độ và thói quen – mindset

Sức mạnh của thái độ và thói quen
Bài viết được sự cho phép của BBT Tạp chí lập trình
“Niềm tin sẽ làm nên suy nghĩ của bạn, Suy nghĩ đó sẽ làm nên lời nói của bạn, Lời nói đó sẽ làm nên hành động của bạn, Hành động đó sẽ làm nên thói quen của bạn, Thói quen đó sẽ làm nên giá trị của bạn, Giá trị đó sẽ làm nên số phận của bạn.”

          — MAHATMA GANDHI —

Hãy bắt đầu từ thái độ

Chúng ta có thể gặp những người ngoài 60 tuổi vẫn rất chịu khó học hỏi, những cụ 70 vẫn lọ mọ học máy tính để chat với con cháu ở xa. Họ là ví dụ của những người có mô thức phát triển (growth mindset, chữ của nhà tâm lí học Carol Dweck ở đại học Stanford). Những người này không để tuổi tác đè nặng, họ học hỏi không ngừng, thích chinh phục những thử thách, thấy khó tìm cách vượt qua, mỗi cơ hội làm việc được tận dụng để hoàn thiện chính mình, luôn coi các chỉ trích hướng vào mình như là cơ hội học tập, và vui mừng khi thấy sự thành công ở người khác. Đây là mẫu tư duy thường gặp ở những người thành công trong các lĩnh vực học thuật, kinh doanh, hay nghệ thuật.

  5 biểu hiện của nhân viên cần cân nhắc sa thải
  5 thói quen xấu khiến developer bị sa thải

Ngược lại, lại có những người không thích các thử thách, thấy khó khăn là chùn bước, thấy phê phán là phản ứng tức thì, thấy việc làm là ngại, thấy người khác thành công thì ghen tị. Họ được xếp vào những người có mô thức đông cứng (fixed mindset). Sự khác biệt giữa hai mô thức nằm ở thái độ đối với các mục tiêu trong cuộc sống, trong cách thức phản hồi với thử thách và thất bại, niềm tin về nỗ lực và chiến lược, cũng như thái độ với sự thành công của người khác.

Các nghiên cứu về não bộ gần đây cho thấy tính “mềm dẻo” của não người là rất lớn, và nó có thể thay đổi từ tấm bé cho tới lúc già. Số lượng tế bào thần kinh có thể không tăng, nhưng cơ cấu tổ chức não bộ với những kết nối phức tạp giữa các tế bào đó thì thay đổi luôn luôn. Ngay cả những công nghệ như Internet, Facebook, Google cũng khiến cho hoạt động của não bộ thay đổi đến ngạc nhiên; điều này được Nicolas Carr bàn kĩ trong cuốn “Trí tuệ giả tạo” bán chạy. Từ nghiên cứu về mô thức (Mindset) của Carol Dweck,chúng ta có thể rút ra được kết luận hết sức quan trọng là con người hoàn toàn có thể phát triển trong suốt cuộc đời. Cách phân biệt mô thức đông cứng và mô thức phát triển đặt nền móng khoa học vững chắc cho niềm tin về việc học tập suốt đời và sự làm chủ cuộc đời cho những người làm giáo dục-đào tạo trên toàn thế giới. Nó cũng giúp ta chọn lựa một thái độ tích cực và chủ động đối với các nỗ lực vươn tới thành công và hạnh phúc.

mindset

Thói quen hoạt động như thế nào

Có thái độ thôi chưa đủ, chúng ta phải hành động, và còn phải tạo lập các thói quen tốt. Một nghiên cứu ở Đại học Duke cho thấy 40% hoạt động của chúng ta hằng ngày thuần túy là do thói quen chứ không phải do suy nghĩ thấu đáo. Con số đó cho thấy tầm ảnh hưởng rất lớn của những việc lặp đi lặp lại theo kiểu “phản xạ có điều kiện” này.

Khi đã có thói quen, chúng ta lặp lại các phản xạ trước các tính huống của cuộc sống mà không phải suy nghĩ nhiều. Điều đó có nghĩa là nếu thói quen tốt và được rèn luyện tốt, thì trong phần lớn các tình huống lặp đi lặp lại ấy, chúng ta đang sử dụng cách làm tốt, mang lại kết quả tốt, mà không phí sức. Ngược lại, nếu thói quen xấu, nó sẽ vô tình chung ảnh hưởng tới kết quả mà chúng ta cũng không để ý, cho tới khi sự việc đã muộn rồi.

Tác giả Charles Duhlgg của cuốn sách bán chạy “Sức mạnh của thói quen” dẫn các nghiên cứu khoa học cho biết, sở dĩ chúng ta hình thành các thói quen vì não chúng ta muốn được giảm tải. Ví dụ như khi chúng ta mới học lái xe, đầu óc sẽ suy tính rất mệt mỏi, đạp ga thế nào, phanh thế nào, tay giữ vô lăng chặt như thế có được không, v.v. Nhưng qua thời gian luyện tập, chúng ta hầu như không còn phải nghĩ nhiều về những việc này nữa, chúng
ta hoạt động theo thói quen, và não thì rảnh để quan sát đường, và suy nghĩ về những việc khác khi lái xe.

Thói quen được hình thành theo một chu trình ba bước: Bước Kích hoạt có tác dụng khởi động não bộ vào trạng thái tự động và lựa chọn thói quen để sử dụng; bước Hoạt động (có thể là hoạt động thể chất, tinh thần, cảm xúc); và cuối cùng là Phần thưởng cho những hành động vừa trải qua (phần thưởng này có thể là sự khoan khoái, hoặc được ngợi khen, hoặc bằng những vật có giá trị). Não bộ sẽ đánh giá phần thưởng để xem xét khả năng lưu giữ lại hoạt động đó để lặp lại khi có kích hoạt tương tự. Sự liên hệ Kích hoạt với Phần thưởng sẽ giúp não bộ phát triển cảm giác kì vọng, từ đó dẫn đến hình thành thói quen. Khi được lặp đi lặp lại, chu trình “Kích hoạt, Hoạt động, Phần thưởng” sẽ được tự động hóa, và chúng ta có thói quen.

Bạn không thể bỏ thói quen xấu, nhưng có thể tạo thói quen mới. Nguyên tắc vàng để thay đổi thói quen là giữ nguyên phần Kích hoạt và Phần thưởng, chỉ thay đổi phần Hành động. Lặp đi lặp lại, ta sẽ có thói quen mới. Đây là cách thay đổi thói quen phổ biến và rất hữu hiệu.

Cần 66 ngày để có một thói quen mới

Một nghiên cứu gần đây đăng trên Tạp chí Tâm lí học xã hội Châu Âu cho thấy, trung bình bạn cần 66 ngày để hình thành một thói quen. Trong 66 ngày đó bạn sẽ phải làm đi làm lại điều bạn muốn nó trở thành cơ hữu với con người bạn, sẽ thành “phản xạ” ngay cả khi bạn không còn nghĩ gì về nó nữa. Dĩ nhiên 66 là con số trung bình, con số cụ thể sẽ phụ thuộc vào nhiều yếu tố khác như tính chất của thói quen bạn định hình thành, cá tính của bạn, và cả điều kiện mà bạn đang có. Nhưng con số này cho thấy, để tạo lập thói quen, bạn cần một sự kiên trì đáng kể. Đó là lí do vì sao các chuyên gia về thói quen khuyên chúng ta cần tạo lập sự liên kết chặt chẽ giữa phần Kích hoạt với Phần thưởng để liên tục duy trì động lực khi thực hành thay đổi thói quen.

Hình thành thói quen làm việc hiệu quả dựa trên Scrum

Một trong điểm mạnh cơ bản nhất của Scrum, một phương pháp Agile phổ biến nhất, chính là giúp bạn có một thói quen làm việc tốt: tính toán kĩ khi bắt đầu công việc, lập kế hoạch khả thi và linh hoạt, kiểm soát công việc liên tục, đánh giá cẩn thận kết quả đạt được và cải tiến liên tục. Các bước đó được sắp đặt và kết hợp logic với nhau, lặp đi lặp lại để sớm hình thành nếp nghĩ, nếp làm việc một cách khoa học và hiệu quả. Scrum không chỉ giúp bạn sớm nhìn ra hiệu quả công việc, vui sướng ngay trong khi làm việc, mà còn duy trì một thói quen tốt.

Tác giả của Scrum, tiến sĩ Jeff Sutherland đã từng viết trên blog cá nhân và trong cuốn sách “Scrum: Nghệ thuật làm được gấp đôi chỉ trong một nửa thời gian” về những câu chuyện thành công trong sử dụng tư duy Scrum vào mọi mặt của đời sống, từ việc dạy học ở trường phổ thông, đến việc marketing, hay tổ chức công việc hằng ngày ở nhà thờ. Chúng ta gọi thói quen này là Scrumlife, để chỉ việc áp dụng tư duy Scrum vào hình thành thói quen
làm việc hằng ngày cho thật tốt.

Hãy bắt đầu Scrumlife đơn giản như thế này:

Chúng ta sẽ khởi đầu tuần làm việc bằng việc lập kế hoạch, gồm 2 bước: xác định việc cần làm, và cách để hiện thực hóa việc cần làm.
Xong rồi ta cập nhật các công việc đó lên Bảng công việc (kanban board), bắt đầu làm những việc có độưu tiên cao hơn, dần dần cho tới hết. Mỗi ngày ta thực hiện 15 phút DailyScrum để tự theo dõi tiến độvà thích ứng với các tình huống thay đổi.
Cuối tuần ta rà soát lại xem đã làm việc gì, so với dự kiến trong kế hoạch đầu tuần thì hoàn thành được bao nhiêu phần trăm, so với tuần trước thì thế nào?
Cuối cùng, ta suy nghĩ về cách làm việc , có ổn không, cần cải tiến gì không. Hãy cố gắng rút ra ít nhất một điều cải tiến, để tuần sau làm tốt hơn. Lưu ý đây là cải tiến cách làm; ví dụ, nếu tuần rồi ta viết thư điện tử cho sếp mà quên không đính kèm file, dẫn đến sếp bực mình, và đây là lỗi lặp lại lần thứ 3 rồi, thì ta có thể kĩ đến cách thức viết thư mới (ví dụ: đảo ngược quy trình viết thư: Đính kèm đầu tiên, rồi mới viết tiêu đề, rồi viết nội dung, cuối cùng là đọc lại và thêm phần To và gửi cho sếp).
Cách làm này áp dụng cho 1 tuần làm việc hăng say và duy trì sự hiệu quả liên tục. Nhưng bạn cũng có thể áp dụng tư duy ấy cho mỗi ngày làm việc với cấu trúc tương tự.

Trước khi bắt đầu thực hiện thói quen này, hãy nghĩ về mối liên hệ Kích hoạt – Phần thưởng. Phần thưởng cho việc hình thành thói quen này là gì? Bạn hãy nghĩ về những mối bận tâm thường trực khi làm việc: Bạn bắt đầu và kết thúc công việc trong tuần thế nào? Năng suất ra sao? Có hiệu quả không? Có thành tựu không? Có thấy vui sướng khi làm việc không? Và lưu ý, hãy tự thưởng cho mình, hoặc tìm kiếm các phần thưởng từ bên ngoài (từ Sếp, từ gia đình, bạn bè …) khi bạn hoàn thành tốt công việc. Nó không chỉ là cơ chế duy trì động lực tạo thói quen, mà còn là sự tận hưởng cuộc sống.

Nếu bạn thực hành Scrum được 2 ngày và thấy hơi gò bó, thì xin chúc mừng bạn, bạn đang trong quá trình hình thành một thói quen mới. Nhưng hãy nhớ, bạn còn khoảng 64 ngày nữa. Cứ lặp đi lặp lại sẽ hình thành một nhịp làm việc và sinh hoạt đều đặn, dần trở nên tự nhiên và phát huy tác dụng. Hãy thử vài tuần đi, bạn sẽ thấy rất nhiều điều bất ngờ đấy.

scrum-life

Bạn có biết: Scrum từng được đề nghị trao giải Nobel về quản trị?

Đó chính là giải (không có thật) được trao bởi một cây viết quen thuộc trên tạp chí nổi tiếng Forbes, Steve Denning, cho hai ông Ken Schwaber và Jeff Sutherland vì đã có công phát minh ra phương pháp tổ chức công việc nổi tiếng Scrum làm thay đổi thế giới phần mềm trong hơn một thập kỉ qua.

Chuyện giải Nobel là do ông Denning “bịa” cho vui, nhưng để nhấn mạnh sự hiệu quả nổi bật mà Scrum có thể mang lại cho các nhóm làm việc trên khắp thế giới.

Trong một bài viết năm 2011, Denning tóm tắt 10 đặc điểm của Scrum (có thể không giống cách nói của chính các tác giả của Scrum):

  1. Tổ chức công việc theo các chu trình ngắn (gọi là phân đoạn)
  2. Khi nhóm làm việc của họ trong các chu trình ngắn này, cấp quản lí không can thiệp (tức nhóm được trao quyền tối đa)
  3. Nhóm báo cáo trực tiếp cho khách hàng, không phải cho nhà quản lí 4. Nhóm ước tính thời gian để hoàn thành công việc.
  4. Nhóm quyết định khối lượng công việc để làm trong phân đoạn 6. Nhóm quyết định cách hoàn thành công việc trong phân đoạn.

Bài viết gốc được đăng tải tại tapchilaptrinh.vn

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev

Message Queue VS Message Bus

Message Queue VS Message Bus

Bài viết được sự cho phép của tác giả Lê Chí Dũng

MESSAGE QUEUE

Message Queue work flow

Message Queue nôm na là Queue (hàng đợi), chứa Message (Tin nhắn) như hộp thư.  Và nó cho phép các thành phần/service trong một hệ thống (hoặc nhiều hệ thống), trao đổi thông tin cho nhau.

  Discord đã lưu trữ hàng tỉ messages mỗi ngày như thế nào
  Kafka là gì? Ứng dụng Kafka cơ bản cho hệ thống message

Message queue nhận message từ một application và cung cấp chúng cho một hoặc nhiều application khác theo cơ chế vào trước thì ra trước ( First In First Out ).

Một số Message queue được dùng hiện nay:

  • Kafka
  • Pulsar
  • RabitMQ
  • ActiveMQ
  • SQS
  • ZeroMQ
  • MSMQ
  • IronMQ
  • Kinesis
  • RocketMQ

Architectural scenarios

Nếu API A cần gửi thông tin cập nhật trạng thái tới các API B và C, thì message queue được thiết lập riêng cho B và C.

A sẽ gửi các message riêng biệt cho mỗi queue và mỗi API nhận sẽ đợi và nhận messgae từ queue được thiết lập riêng, sau khi gửi message thành công thì message sẽ bị khử khỏi queue.

Lúc A gửi message thì cả B và C đều không cần có sẵn để nhận message. Message queue luôn hoạt động, vì vậy nếu một API nhận bị khởi động lại, thì nó sẽ bắt đầu kéo message từ queue riêng của nó khi nó trở lại trực tuyến.

Điều này giúp phá vỡ sự phụ thuộc giữa các hệ thống và cung cấp khả năng mở rộng và khả năng chịu lỗi lớn hơn cho các API.

MESSAGE BUS

Message Bus work flow

Message bus còn được gọi Service Bus.

Message Bus cung cấp phương thức để một hoặc nhiều application giao tiếp message đến một hoặc nhiều application khác.

Message Bus không đảm bảo cho việc vào trước xuất trước. Người nhận (Subscribers) đã đăng ký Message Bus có thể nhận message được publish mà không biết về người gửi (Publisher or Sender).

Một số Message Bus được dùng hiện nay:

  • Commercial
    • IBM Integration Bus
    • IBM WebSphere ESB
    • InterSystems Ensemble
    • Information_Builders iWay Service Manager
    • Microsoft Azure Service Bus
    • Microsoft BizTalk Server
    • Mule ESB
    • Oracle Enterprise Service Bus
    • Progress Software Sonic ESB (acquired by Trilogy)
    • SAP Process Integration
    • TIBCO Software ActiveMatrix BusinessWorks
    • webMethods enterprise service bus (acquired by Software AG)
    • Sonic ESB from Aurea
  • Open source
    • Apache Camel
    • Apache ServiceMix
    • Apache Synapse
    • Fuse ESB from Red Hat
    • JBoss ESB
    • NetKernel
    • Open ESB
    • Petals ESB
    • Spring Integration
    • UltraESB
    • WSO2 ESB

Architectural scenarios

Nếu API A truyền thông tin cập nhật trạng thái cho API B thông qua một Bus.

Sau đó, API C cũng có thể hưởng lợi từ những cập nhật này. Ứng dụng C có thể được cấu hình để listen Bus và thực hiện hành động dựa trên các cập nhật này mà không cần bất kỳ yêu cầu cập nhật nào từ API A.

Không giống như Message queue, API gửi message vào queue cho tất cả các API nhận, Message bus sử dụng mô hình Publisher / Subscribers.

Message được API gửi publish lên Bus thì bất kỳ API nhận nào đã subscribe loại tin nhắn nào thì sẽ nhận được message tương ứng.

Cách tiếp cận này cho phép các API tuân theo nguyên tắc Open/Closed, vì chúng trở nên mở đối với các thay đổi trong tương lai trong khi vẫn đóng để sửa đổi bổ sung.

Bài viết gốc được đăng tải tại lcdung.top

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev

1...122123124...230Page 123 of 230