CLI là cách người dùng và chương trình giao tiếp với nhau thông qua các dòng lệnh. CLI là viết tắt Command – line –interface, VD: nếu người dùng đồng ý thì gõ vào phím y rồi nhấn enter…
Interface là gì?
Interface là cách các đối tượng giao tiếp với nhau. Ở đây ta xét 1 đối tượng là người, 1 đối tượng là chương trình máy tính. Có 2 loại interface thường được nhắc đến là GUI và CLI (để ý chữ I ở cuối).
GUI = Graphical User Interface: Người dùng và chương trình giao tiếp với nhau thông qua các nút bấm, hình ảnh…Thao tác tiêu biểu cho GUI là: nếu người dùng đồng ý thì bấm vào nút OK, không thì bấm vào nút Cancel.
Bạn có thể thao tác công việc nhanh hơn hẳn so với dùng GUI. Với CLI, bạn chỉ cần gõ bàn phím, nên nếu đã gõ quen rồi, bạn có thể vừa nhắm mắt, vừa gõ code (yaoming) => Khi làm việc sẽ không còn bị mỏi mắt nữa=))
Một ví dụ khác: Mặc dù bạn không nhớ câu lệnh như thế nào, nhưng CLI có lưu lại các câu lệnh bạn đã gõ. Vì vậy bạn chỉ cần gõ câu lệnh man để gọi lại lịch sử command, bạn sẽ thấy công việc code hàng ngày của bạn có những thay đổi đáng kể.
Terminal là gì?
Là thiết bị cuối – thiết bị cuối cùng của đường dây. Thiết bị này được dùng vào thời mà những chiếc máy tính còn đắt đỏ. Một terminal chỉ có bàn phím (input) và màn hình (output). Cái mà ngày nay chúng ta hay gọi là terminal chạy trên máy tính thực chất là “virtual terminal” – terminal ảo.Các hệ điều hành nhân Linux đều trang bị sẵn các virtual terminal (từ giờ gọi là terminal cho ngắn).
Các terminal phổ biến như: GNOME Terminal, Konsole, rxvt, terminator…
Tự tạo một CLI để quản lý công việc
Câu chuyện có thay đổi một chút. Những điều tôi tổng hợp ra dưới đây không chỉ là những việc mà một kỹ sư phần mềm cần làm, mà nó còn áp dụng chung cho tất cả những ai đang làm việc, giúp công việc của bạn đạt được hiệu suất cao hơn.
• Quản lý Memo (viết note những việc cần làm)
• Quản lý Task
• Quản lý thời gian
Hiện tại, tôi đang áp dụng quản lý các việc trên bằng CLI nên cũng muốn giới thiệu, chia sẻ cho các bạn biết.
Quản lý Memo
Tôi đã viết bằng Markdown và đang quản lý File bằng Private Responsitory của Github. Tôi chia file code của từng ngày ra và lưu lại. Bằng cách gọi câu lệnh dưới đây, tôi có thể mở ra các phần memo của ngày hôm nay. Gõ câu lệnh này ra, đầu tiên màn hình sẽ chuyển trạng thái thành Get emacs /diary/ emacs ~/diary/emacs/diary/(date “+%Y/%m/%d.md”).
Cấu trúc Directory
Sau khi gõ câu lệnh trên, 1 file có Directory dạng là 年/月/日.md sẽ được tạo ra và có cấu trúc directory như dưới đây:
Tôi đang quản lý file, code của mình trên Responsity của GitHub. Với chức năng này, bạn có thể dễ dàng share thông tin giữa các thiết bị ở nhà và các thiết bị tại công ty. Vì thế, khi bạn muốn xem lại thông tin, code…v.v trên các thiết bị di động, bạn có thể xem dễ dàng lại vì các thông tin, code đó đã được đã được viết thêm Markdown, hiển thị sao cho dễ nhìn , kể cả khi bạn Access vào Github.
Search Memo
Tôi quản lý memo trên git, nên tôi có thể search lại các phần memo đó, chỉ với 1 cú pháp đơn giản là git grep . Qủa thực là rất tiện lợi các bạn ạ!
Quản lý Task
Tôi đang sử dụng Web app có tên là Todoist để quản lý các Task cá nhân.
App này rất tiện và dễ dùng nữa. Nhưng vì tôi muốn dùng CLI nên tôi đã tạo CLI client bằng Golang và đang dùng app tự mình viết.
Demo
Quản lý thời gian
Để đo thời gian làm các task hết bao lâu, tôi dùng 1 Web app là toggl
Khi thực hiện đo thời gian một cách chuẩn xác như vậy thì lần sau các bạn sẽ estimate thời gian làm task chính xác hơn. Thời gian làm task sẽ được tổng hợp thành các biểu đồ. Bạn sẽ dễ dàng nhìn ra được: Bạn đã dành bao nhiêu thời gian cho 1 task, thời gian vượt dự kiến là bao nhiêu…v.v
Có thể các bạn nghĩ tôi tự phụ, “tự hát, tự khen hay” nhưng vì thích dùng CLI nên tôi cũng viết client cho app này luôn=))
• sachaos/toggl: Toggl CLI Client
demo
Tổng kết
Trên đây tôi đã giới thiệu cho các bạn về các phương pháp, tool tôi đang sử dụng trong thực tế để quản lý Memo, task, thời gian bằng CLI. Bằng cách liên tục cải tiến các quy trình, bắt đầu từ những việc nhỏ như vậy, chúng ta sẽ tiết kiệm được thời gian, nâng cao năng suất, hiệu quả trong công việc.
Chúc các bạn làm việc vui vẻ, xong sớm, về sớm! (len)
Có bao giờ các bạn tự hỏi cách build chrome extension là gì? Có dễ không? Gần đây mình đã tự tạo một phiên bản chrome extension đầu tiên cho mình. Nó tên là Catify, và nó có thể thay mọi hình ảnh trên giao diện page của bạn tràn ngập hình mèo.
Đây cũng là lần đầu mình thử cách build chrome extension và nó rất thú vị. Bạn có muốn tự tạo cho mình một tiện ích trên Chrome giống vậy chứ? Mình sẽ hướng dẫn cho các bạn cách build chrome extension. Và đừng quá lo lắng, tổng thời gian chỉ mất khoảng 1 ngày thôi.
Hướng dẫn cách build chrome extension
Chrome extension (Tiện ích mở rộng trên Chrome) là gì? Mặc dù Chrome đã là một trình duyệt tuyệt vời rồi, nhưng bạn có thể làm nó tuyệt vời hơn thế nữa. Bằng cách thêm các tiện ích (extension) cho nó. Để kiểm tra tiện ích nào đã có sẵn, bạn có thể xem tại Chrome Web Store. Chỉ cần truy cập và kiểm tra tất cả những tiện ích thú vị đang có sẵn. Và giờ hãy tưởng tượng tiện ích của riêng bạn cũng đang nằm trên store đó thì sao nhỉ? Hãy cùng biến điều đó thành hiện thực nào.
Chúng ta sẽ làm gì?
Vì có lẽ bạn đã có khá nhiều ý tưởng tung tăng trong đầu để xây dựng tiện ích đầu tiên của mình, nên chúng ta cần xem qua một tí căn bản ở bước đầu nhé. Để làm tiện ích, chúng ta hãy xem một trong những ví dụ căn bản của Google là page redder, và cùng thêm chút gia vị vào đó nào. Chúng ta tạo một tiện ích có thể chuyển màu nền của trang sang một màu bất kỳ mỗi khi bạn bấm vào icon tiện ích đó.
Bước đầu tiên: Tạo tệp kê khai
Hãy chắc chắn là bạn đã thiết lập kiểm soát nguồn và để trình soạn thảo mình thích trỏ đến đúng vị trí. Chúng ta bằng đầu bằng việc tạo tệp kê khai, đây là file cho Chrome biết mọi thứ nó cần về tiện ích của bạn. Những thứ như tên, icon cũng cần được cho phép và xác nhận nơi nó được code. Hãy tạo 1 tệp tên manifest.jsonvà điền vào như thế này:
{
"name": "Make it rain(bow)",
"description": "Embrace the inner unicorn and reflect on the page background.",
"version": "0.0.1",
"manifest_version": 2
}
Vậy chúng ta thấy gì ở đây nào? Đầu tiên là name. Đây là cách mà tiện ích sẽ xuất hiện ở store, trong phần tổng quan tiện ích và trừ khi có quy định khác về những gì bạn thấy khi bạn di chuột vào icon trong trình duyệt. Sau đó có description, cái này chỉ là một cái title, một đoạn mô tả hiển thị trong store và phần tổng quan về tiện ích. Tiếp theo là version của tiện ích.
Bạn nên sử dụng phiên bản semantic cho tiện ích của bạn và gia tăng điều này mỗi khi bạn update tiện ích của mình. Cuối cùng hãy xem qua manifest_version, lệnh này sẽ cho Chrome biết file này được viết bởi tệp kê khai version 2. Có lẽ nếu bạn sẽ muốn hỗ trợ Chrome trước phiên bản 18, bạn nên sử dụng manifest bản 1, nhưng đừng để lỡ những phiên bản mới hơn. Bây giờ đã xong những cái cơ bản, chúng ta có thể từ từ thêm nhiều thứ nữa nhé.
Thay đổi title khi di chuột vào icon
Bằng cách mặc định hiện tên của tiện ích, nhưng cũng không hẳn là giống nhau. Hãy thay đổi nó nào! Thêm các câu lệnh dưới đây vào root của manifest.json như sau:
"browser_action": {
"default_title": "Unleash the unicorn dust!"
},
Bây giờ khi người dùng di chuột đến icon, nó sẽ hiển thị dòng chữ “Unleash the unicorn dust!”
Permissions và Script
Trước khi chúng ta có thể code thực cho tiện ích của mình, chúng nên thêm 2 thứ nữa vào manifest. Đầu tiên, chúng ta cần define các permission cần thiết. Trong trường hợp chúng ta không chỉ cần 1 permission, thì truy cập vào tab hiện hành. Hãy define cái này. Thêm những dòng lệnh như bên dưới vào root của manifest.json
"permissions": [
"activeTab"
],
Tiếp theo chúng ta cần một vài script để chạy. Chúng ta sẽ thực hiện việc này trong script background, cũng là việc mà chúng ta cần define trong manifest.json. Thêm vào root như sau:
Chúng ta sẽ define logic trong một file tên là background.js. Bên cạnh đó, nó sẽ không tồn tại lâu, bạn chỉ nên duy trì liên tục nếu tiện ích mở rộng dùng chrome.webRequest API để chặn hoặc sửa đổi yêu cầu mạng. Tới lúc xây dựng logic thực tế rồi!
Thay đổi màu background
Vì chúng ta đã báo cho Chrome biết rằng logic được đặt trong background.js, nên hãy dùng file này và build logic.
Hãy nhìn qua các dòng code. Dòng đầu tiên cho biết chúng ta đã thêm 1 Listener vào onClick của browserAction. Là sao?? BrowserAction là một cái nút bạn sẽ thấy ở Chrome khi thêm một tiện ích, onClick xảy ra khi bạn click vào cái nút đó và thêm 1 Listener, điều này nghĩa là nó chỉ kích hoạt khi bạn click vào. Vậy nên phương pháp này được thực hiện khi bạn nhấp vào nút bên trong Chrome.
Tự thân dòng code đã thoát ra. Chúng ta có một list màu, một phương pháp chọn màu ngẫu nhiên từ cái list đó và thực hiện script để đổi màu background. Chúng ta làm điều này bằng cách thực thi một đoạn javascript bên trong tab trình duyệt mà hiển thị trong trang thực tế.
Trước khi sử dụng thử tiện ích, chúng ta nên làm nó đẹp hơn một chút. Chúng ta sẽ define icon mà hiển thị trên đầu của trình duyệt cho tiện ích của mình. Bắt đầu bằng việc tạo một cái hình bất kỳ kích thước 128×128 mà bạn muốn. Giờ bạn sẽ lưu cái hình này dưới một số dạng sau:
128×128 để sử dụng trong store của Chrome
48×48 để sử dụng khi cài đặt
32×32 để hiện thị trên các cửa sổ
16×16 để sử dụng trong mỗi Chrome như icon hiển thị trên đầu màn hình của bạn
Để thêm những hình ảnh này, chúng ta hãy thay đổi một số cái trong manifest.json như bên dưới, thêm vào section browser_action:
"default_icon": "icon16.png"
Chúng ta chỉ cần ghi rõ hình 16×16 ở đây, vì icon đó luôn luôn để kích thước 16×16 trên mọi thiết bị. Và thêm phần này vào root:
Đây là những icon có thể dùng từ các ứng dụng của bạn và có sẵn các kích thước theo yêu cầu. Xem thêm: Cách tạo icon trên Android.
Hãy thử chạy nào!
Bạn có phấn khích không nào? Chắc chắn rồi, vì chúng ta sẽ chuẩn bị test thử tiện ích của mình trên trình duyệt. Bật trình duyệt lên và mở tiện ích của bạn bằng cách bấm vào nút menu và chọn More Tools -> Extensions. Việc đầu tiên bạn làm là enable Developer mode.
Giờ bạn sẽ thấy 3 cái nút xuất hiện đầu tiên bên trái trang. Cho phép bạn tải tiện ích đã giải nén, nén tiện ích hoặc bắt buộc update. Click vào nút đầu tiên để tải lên tiện ích đã giải nén.
Bây giờ hãy đến folder mà bạn đã tạo tiện ích và bấm Select folder. Tiện ích của bạn sẽ được cài đặt ngay, thật tuyệt vời! Sau khi cài đặt xong bạn sẽ thấy nó trên trang tiện ích của mình ở đầu trình duyệt.
Giờ hãy mở thử nó nào! Mở một tab mới, đến dev.to và nhấn vào icon cầu vồng. Rồi nhấn nó nhiều lần nữa để thấy cầu vồng xuất hiện nhé.
Hiệu nghiệm rồi!!
Publish tiện ích của bạn
Chỉ còn một chuyện nữa để làm, đó là publish tiện ích Make it rain(bow) tuyệt vời của bạn. Hãy làm theo các bước sau:
Tạo 1 file zip chưa mọi file bạn đã làm. manifest.json, background.js và mọi icon đều sẽ ở trong đó.
Sau khi bạn đồng ý các điều khoản, bạn có thể tiếp tục với tiện ích của mình.
Nhấn nút NEW ITEM ở trên cùng bên phải, sẽ hiện ra một cưa sổ, sau đó chọn file zip bạn đã tạo ở bước 1.
2. Sau khi upload, 1 cái form sẽ mở ra yêu cầu một vài chi tiết trước khi bạn có thể kích hoạt tiện ích của mình. Bạn sẽ phải điền:
Title
Tóm tắt
Mô tả chi tiết
Category
Ngôn ngữ
1 ảnh chụp màn hình. Hãy điền hết những cái này.
Bấm SAVE DRAFT và nếu mọi thứ đã được điền đúng, bạn sẽ có thể bấm “PUBLISH ITEM”. Click vào nó, và chỉ đợi một chút để được xác nhận. Bấm PUBLISH và hoàn tất nào. Vậy là bạn đã tự tạo được tiện ích đầu tiên của riêng mình rồi.
Kết
Cảm ơn bạn đã đọc bài viết ‘cách build chrome extension’, mình hy vọng bạn có thể được gì đó sau khi đọc xong. Như bạn thấy đó, cách build chrome extension không quá khó. Có ý tưởng cho một tiện ích chưa có, sẽ là một câu chuyện hoàn toàn khác. Chúc bạn may mắn và hy vọng sẽ thấy được các tiện ích của bạn sớm.
Làm thế nào mà việc giao tiếp giữa các microservice lại gây ảnh hưởng đến hiệu suất và khả năng mở rộng của ứng dụng. Giao tiếp giữa các dịch vụ có thể đồng bộ hoặc không. Đối với bài viết này, chúng tôi sẽ tập trung vào sự đồng bộ. Theo ý kiến cá nhân của chúng tôi thì có 2 giao thức phổ biến:
HTTP/1.1: giao thức http mặc định
gRPC:cuộc gọi thủ tục từ xa với hiệu suất cao (RPC framework). gRPC.io hoạt động dựa vào tài liệu toàn diện của mình.
Hãy thử xem một số code mẫu và chạy thử một số thử nghiệm hiệu suất để xem thử các lựa của chúng tôi
Với hai service đang chạy này chúng tôi có thể kích hoạt jMeter để thử nghiệm hiệu năng. Chúng tôi sẽ sử dụng 50 người dùng với 2000 yêu cầu mỗi người. Chúng ta có thể thấy trong ảnh chụp màn hình bên dưới trung bình của chúng là 37ms.
Kết quả hoạt động của HTTP / 1.1 ở chế độ Non-cluster
gRPC
gRPC sử dụng protocol buffers theo mặc định. Ngoài serviceA và serviceB, chúng tôi còn cần thêm một file proto sẽ xác định cuộc gọi từ xa của chúng tôi.
Như chúng ta có thể thấy từ dữ liệu này, gRPC nhanh hơn 27% so với yêu cầu HTTP / 1.1 thông thường.
Cấu Trúc Ứng Dụng Trong Chế Độ Cluster
Cấu trúc ứng dụng
Nếu bạn đang chạy bất cứ thứ gì trong quá trình sản xuất, rất có thể bạn đang chạy nhiều phiên bản của bất kỳ dịch vụ cụ thể nào. Trong trường hợp này, chúng ta đang thực hiện các thay đổi sau:
Chạy ba phiên bản dịch vụ của chúng tôi trên các cổng khác nhau
Chúng tôi đang sử dụng NGINX tạo sự cân bằng tải.
HTTP/1.1
Không có thay đổi được yêu cầu từ phía dịch vụ. Tất cả chúng ta cần làm đó là cấu hình nginx để cân bằng lưu lượng tải với serviceB. Chúng tôi có thể sửa đổi /etc/nginx/sites-available/default giống như bên dưới
upstream httpservers {
server ip_address:8001;
server ip_address:8002;
server ip_address:8003;
}
server {
listen 80;
location / {
proxy_pass http://httpservers;
}
}
nginx với HTTP/1.1
Bây giờ chúng ta có thể bắt đầu với 3 phiên bản dịch vụ của chúng tôi và chạy thử nghiệm hiệu suất của chúng.
Kết quả hoạt động của HTTP / 1.1 ở chế độ Cluster
gRPC
Hỗ trợ cho gRPC gần đây đã được thêm vào nginx phiên bản 1..13.10. Vì thế chúng ta cần sử dụng bản mới nhất vì sudo apt-get install nginx mặc định sẽ không thể hoạt động.
Tiếp theo, chúng ta cần thay đổi tệp /etc/nginx/sites-available/default để bắt đầu sử dụng gRPC.
upstream grpcnodes {
server ip_address:8001;
server ip_address:8002;
server ip_address:8003;
}
server {
listen 1443 http2;
ssl_certificate /home/ubuntu/interserviceCommunication/http2/certificates/localhost-certificate.pem;
ssl_certificate_key /home/ubuntu/interserviceCommunication/http2/certificates/localhost-privatekey.pem;
location / {
grpc_pass grpcnodes;
## try_files $uri $uri/ =404; // Don't forget to comment this else you will get 404 as a response
}
Chính là nó. Hãy chạy thử nghiệm hiệu suất một lần nữa
Kết quả hoạt động của gRPC ở chế độ non cluster
Như chúng ta có thể thấy gRPC nhanh hơn 31% so với HTTP / 1.1
Kết Luận
gRPC thì nhanh. Trong các bản thử nghiệm ở trên, chúng ta có thể thấy nó nhanh hơn 31% so với HTTP / 1.1 chỉ bằng cách thay đổi cách mà chúng tôi trao đổi.
Tuy nhiên, đối với những dự án cần một số yếu tố như tốc độ truyền thông cao và độ trễ thấp, truyền dữ liệu kiểm stream, các hãng công nghệ lớn thường có xu hướng chuyển đổi sang một framework RPC mới dựa trên protobufs và HTTP/2 của Google là gRPC API.
Tại buổi meetup ngày 14/01/2020 với chủ đề “Migrating APIs from REST to gRPC and LOOP Case study” do anh Việt Nguyễn – CTO | LOOP trình bày, hứa hẹn sẽ mang đến những giải pháp cho vấn đề giao tiếp giữa các services từ chính trường hợp của LOOP.
Tham gia ngay buổi meetup để trao đổi chi tiết hơn cùng cộng đồng IT và chuyên gia đến từ LOOP ngay nhé!
= = = **Nhập ngay code EARLYBIRD@1401 để giảm 100.000đ cho các vé đầu tiên ⏰ Thời gian: 18:30 – 21:00 ngày 14/01/2020 📌 Địa điểm: UP Bách Khoa Hà Nội, tầng 3 toà nhà A1-7, 17 Tạ Quang Bửu, HBT. 🎟 Đăng ký ngay tại:https://meetup.vn/e/F3S
===
LIÊN HỆ
Event team: event@applancer.net | 028 6681 3236 Ms. Thoa | thoa.nguyen@applancer.net | 038 5098 969 === Sự kiện thuộc chuỗi PRODUCT IN REAL LIFE hằng tuần được tổ chức bởi TopDev – Giải pháp tuyển dụng ngành IT ===
Hãy cùng Techtalk gặp gỡ và trò chuyện cùng những chuyên gia công nghệ tại Axon để hiểu thêm về định hướng, tầm nhìn và những chia sẻ sâu sắc của họ về thị trường công nghệ tại Việt Nam. Các lời khuyên của họ cũng sẽ là một hành trang vô cùng quý giá cho những lập trình viên sau này.
Có thể các bạn đã biết, Axon thành lập cách đây 25 năm, với sứ mệnh cốt lõi chính là: Bảo vệ tính mạng của tất cả mọi người – cả người dân và cảnh sát trong các tình huống nguy hiểm cũng như khi người dân và cảnh sát phải đụng độ trực tiếp.
Một trong những dịch vụ và phần mềm đám mây chứa thông tin theo dạng video (video information) lớn nhất thế giới để thay đổi cách thức thực thi công lý của các đơn vị chính quyền – cảnh sát mà không làm ảnh hưởng đến tính mạng con người.
2 năm trước, khách hàng của Axon cần một giải pháp công nghệ để xử lý và sắp xếp lại một số lượng lớn video bằng chứng để công bố thông tin rộng rãi đến công chúng cũng như báo chí. Và rồi, chúng tôi mua lại nhóm Computer Vision của Misfit, đây cũng là điểm khởi nguồn cho tất cả những thành phẩm tuyệt vời mà chúng tôi đang thực hiện hoá hiện nay trên quy mô toàn cầu.
Hiện nay, ngoài trụ sở Hoa Kỳ, nhánh Axon Việt Nam là trung tâm nghiên cứu và phát triển trọng điểm của tập đoàn Axon, với hơn 90 nhân viên & kỹ sư và ngày càng phát triển nhanh chóng.
Có 3 điều làm nên một Axon hoàn toàn khác biệt:
Thứ nhất, chúng tôi giải quyết các vấn đề gây trăn trở và khó khăn nhất của xã hội hiện đại, và công nghệ được phát triển ở đây có thể bảo vệ mạng sống bất cứ ai trên thế giới. Sẽ không có nhiều nơi trên thế giới mà bạn mang trong mình sứ mệnh “Loại bỏ đạn bạc – Bảo vệ con người” như thế.
Và cuối cùng, hãy thử tưởng tượng xem, cách đây 25 năm, nếu bạn nói với ai đó rằng một ngày bạn có thể ngăn chặn một tên tội phạm mà không gây nên bất kỳ thương tích nghiêm trọng nào, hoặc ngăn chặn nó từ chính thiết bị di động của bạn và gửi thông tin đó ngay cho cảnh sát địa phương để giải quyết, mọi người sẽ nghĩ bạn bị điên và thay vào đó sẽ báo bạn lên cho cảnh sát… Và giờ đây, bạn đã hoàn toàn có thể thực hiện nó chỉ trong cái chạm tay và có thể cứu lấy không ít người.
Có một điểm tôi rất muốn chia sẻ: Các kỹ sư và lập trình viên tại Việt Nam chưa bao giờ làm tôi hết bất ngờ. Từ thủ đô Hà Nội đến thành phố Hồ Chí Minh, tôi nhận thấy các bạn đều có nền tảng rất tốt về toán học và khoa học cơ bản, và điều đó là vô cùng quan trọng khi bạn bắt tay vào thiết kế các hệ thống AI và phần mềm phức tạp và độ chính xác cao.
Rất nhiều kỹ sư của chúng tôi ở đây có nền tảng mạnh về toán học và khoa học cơ bản, và điều đó là vô cùng quan trọng khi bạn bắt tay vào thiết kế các hệ thống AI và phần mềm phức tạp và độ chính xác cao. Có thể nói, các kỹ sư và lập trình viên Việt Nam thật sự rất đam mê và nghiêm túc với những gì họ đang làm để mang đến những sản phẩm và giải pháp tốt nhất.
Không ngừng xây dựng các mối quan hệ & kết nối mới – Gặp gỡ, chia sẻ thông tin và kiến thức là một trong những yếu tố quan trọng nhất để duy trì và củng cố sự phát triển bền vững của trong cộng đồng kỹ thuật Việt Nam hiện có.
Triết lý cá nhân của tôi đó là các kỹ sư khắp Việt Nam cần chia sẻ tài năng của họ trên quy mô toàn cầu. Tôi không nhìn nhận các công ty khác ở đây là đối thủ cạnh tranh, nhưng thấy đó là cơ hội để tất cả chúng ta trở nên mạnh mẽ & phát triển hơn.
Có một câu ngạn ngữ Anh nói rằng:
“A rising tide lifts all boats” (Sóng lên thì thuyền lên)
tức khi công nghệ ngày càng phát triển thì ai cũng sẽ được hưởng lợi từ nó.
Tại Axon, mọi người làm việc thoải mái và mang tính chủ động cao, để cô đọng hơn về môi trường làm việc ở đây, mình sẽ nói về 6 giá tr ị cốt lõi khi bạn làm việc tại Axon:
Outsource và Product có cách tư duy khác nhau. Dù sao đi nữa, thì để hiểu một công nghệ nào thì đối với Outsource hay Product tốn khá nhiều thời gian và tư duy. Theo mình thì những bạn theo làm Product sẽ có tư duy phản biện tốt hơn, và có thể trả lời được câu hỏi “Tại sao mình phải làm như vậy?”. Còn về outsource, các bạn có thể làm việc tốt hơn dù dưới áp lực về thời gian hay yêu cầu về sản phẩm.
Bên mình có một số sản phẩm dựa trên nền tảng AI. Ví dụ như tính năng tự động làm mờ những thông tin cá nhân trong các video chứng cứ khi camera quay và upload các chứng cứ lên trên mạng. Tính năng đó có tên là Redaction. Tất cả những thông tin cá nhân sẽ bị thay đổi trước khi chuyển sang cho giới truyền thông… Để xóa một video 10 phút cần một người làm việc trong 40 phút để chính sửa. Và bên mình đang nghiên cứu để sử dụng AI hỗ trợ rút ngắn thời gian đó xuống.
Về tiếng súng, Axon đang sử dụng các đặc điểm MFCC (Mel-scale Frequency Cepstral Coefficient), để chuyển các tín hiệu âm thanh thành dạng hình ảnh 2D, mà bọn mình có thể dùng khai thác tính toán. Đây cũng là kĩ thuật mà Google và Apple dùng đằng sau câu lệnh gọi điện thoại “Hey, Google” và “Hey Siri”. Chỉ khác là ở đây mình sẽ dùng tiếng súng.
Ở Axon, công ty quan trọng cách bạn suy nghĩ và tư duy giải quyết vấn đề hơn là bạn biết dùng công nghệ gì. Trong khi công nghệ bạn sử dụng có thể thay đổi được, cách suy nghĩ theo mình rất khó để đào tạo. Do đó khi phỏng vấn mình đặc biệt chú ý đến thái độ và cách bạn đó suy nghĩ, giải quyết vấn đề. Bên cạnh đó, mình cũng chú ý đến tính cách và khả năng hòa nhập với công ty, và các giá trị của công ty mà mình tìm nơi bạn đó.
Một lời khuyên cho các bạn ứng vên về sách đọc thuật toán nói riêng: cuốn Cracking the code interview. Ở trong cuốn này có nhiều mẹo nhỏ về những thuật toán nhỏ mình thường gặp. Nhưng mình muốn nói thêm rằng đây chỉ là cookbook để chuẩn bị cho phỏng vấn, và chắc chắn kiến thức thì không thể hình thành trong một ngày hai ngày, mà đó là cả một quá trình.
Công nghệ AI ở VN có khá nhiều hướng đi: một số công ty làm về Fintech, một số outsource làm về thị giác máy tính, và một số khác thiên về quảng cáo: xử lý ngôn ngữ tự nhiên, phân tích thái độ của bình luận. Một điều mình hay thấy ở nhiều start-up đó là vấn đề cây búa và cây đinh: đôi khi vấn đề mà họ đang gặp phải chưa cần đến những công cụ như machine learning, deep learning để giải quyết nhưng họ vẫn quyết tâm sử dụng. Tuy nhiên, cũng có rất nhiều công ty khác có nguồn dữ liệu dồi dào và nhiều người tham gia nghiên cứu đang tìm cách giải quyết những vấn đề rất thú vị, mà khi đó áp dụng những kĩ thuật mới như machine learning và deep learning sẽ mang lại ưu thế lớn hơn so với các phương pháp truyền thống cổ điển.
Cảm ơn phần chia sẻ rất hữu ích của hai anh về Axon cũng như những công nghệ mà công ty đang đem lại, hy vọng sẽ sớm được nhận nhiều chia sẻ hơn của hai anh trong thời gian tới.
Chào anh em. Hôm nay mình xin chia sẻ về một hiệu ứng rất thú vị. Đó là Flying flag effect: Làm hiệu ứng lá cờ bay trong gió bằng JavaScript, HTML và CSS.
– Đặt pass dễ nhớ nên bị brute force password
– Thông tin hosting cũng tương tự như trên
– Server OS bị bug và quá cũ dễ bị exploit
– Cài đặt plugin hoặc themes có bug + shell và lâu rồi ko được update để fix
– OS của bạn đang sử dụng bị virus và trực tiếp lây nhiễm vào OS và FTP Client.
Cách fix và restore site, làm tuần tự (nếu may mắn còn database + folder uploads):
– Đầu tiên export database ra để backup.
– Vào folder wp-content/plugins lưu lại danh sách các plugins hiện đang dùng.
– Đổi pass hosting (bao gồm ftp và cpanel quản lý nếu có), nếu dùng vps thì thường hay dùng account root thì đổi luôn password của root và tốt nhất là thêm việc đổi luôn port ssh của vps.
– Đổi pass mysql nếu hosting chứa nhiều database thì cũng đổi hết tất cả các database tương ứng (bước này áp dụng cả vps lẫn hosting).
– Xóa toàn bộ code hiện có chỉ chừa lại folder wp-content/uploads, folder này chứa các static files (chủ yếu là các file ảnh hoặc các file không phải là php) sau đó download folder này về và dùng các chương trình search với phần mở rộng là .php để xóa các file php thường là file shell được upload lên hoặc được giấu ở folder này.
– Install một bản wp fresh (download bộ cài từ wordpress.org) ở localhost và import file database đã backup ở bước đầu tiên vào, thay đổi các thiết lập trong wp_config.php để phù hợp với database đã import (thường thì chỉ là prefix thôi).
– Vào phpmyadmin kiểm tra bảng wp_users xem có account nào khả nghi và có quyền administrator thì một là xóa luôn nếu không biết acc của ai, 2 là nếu đã biết thì đổi luôn password (lưu ý là việc này cần xác nhận user đã biết là ai và user đó chắc chắn email không bị lộ pass và máy tính không nhiễm virus vì có quyền admin đương nhiên có thể request password qua mail và lại upload shell lên coi như công cốc)
– Copy hoặc move folder uploads đã backup ở trên vào wp-content/ (overwrite nếu cần).
– Xem lại list các plugins đã ghi lại ở bước trên và tiến hành download ở các nguồn tin tưởng (phiên bản càng mới càng tốt) và copy vào thư mục wp-content/plugins
– Đăng nhập vào wp-admin và check lại mọi thứ lần cuối sau đó backup lại và thử upload lên hosting để hoàn tất quá trình restore lại site.
Ngoài ra thì có thể cài thêm một số plugin hỗ trợ bảo mật như bên dưới để tăng cường:
iThemes Security: plugin này có chức năng firewall cơ bản là block các request dạng như bruteforce password, ẩn wp-admin link đăng nhập, disable việc thực thi php ở folder uploads (cái này chỉ hỗ trợ đối với server đang chạy là apache nhé), chế độ rảnh ngoài giờ của admin nghĩa là ko đăng nhập được trong khoảng thời gian nào đó cho dù đúng password, blacklist ip, scan files theo lịch và thông báo các thay đổi có liên quan đến database cũng như physical files, vân vân và mây mây rất nhiều…
Sucuri: chức năng report thay đổi database và file cũng gần như bên trên, firewall cơ bản. Bọn này nó có cái WAF bản trả phí thì có full bộ firewall về bruteforce lẫn ip blacklist, ngoài ra thêm kiểu chế độ quét định kỳ và fix lỗi site nếu bị hack luôn dạng dịch vụ.
Các plugin backup có thể sử dụng để backup site hoặc database:
BackupBuddy: hỗ trợ backup định kỳ cả file + database hỗ trợ dạng send email attachments hoặc lên Gdrive, Onedrive, Dropbox…
Updraft Plus như trên dùng 1 trong 2 =.=
Lưu ý là nếu plugin nguồn gốc rõ ràng mà đã chứa bug sẵn thì mọi cách làm bên trên đều bị vô nghĩa.
Pro MERN Stack – Lập Trình Ứng Dụng Web Full Stack với Mongo, Express, React, và Node”]
2. Các bạn sẽ học được những gì từ khóa học này.
Học là phải đi đôi với thực hành, nếu chỉ học basic cơ bản mà không có cơ hội áp dụng vào một ứng dụng lớn cụ thể thì sẽ rất khó cho các bạn mới. Nên mình đã soạn ra khóa học này.
Node.js & MongoDB:
Dĩ nhiên chắc chắn phải nói đến đầu tiên là Node.js và MongoDB trước rồi, một cách cụ thể hơn, các bạn sẽ nắm được rất nhiều kỹ thuật xử lý Javascript nâng cao trên platform Node.js và framework Express.js, cùng kết hợp tương tác với cơ sở dữ liệu MongoDB để lưu trữ dữ liệu.
Xử lý bất đồng bộ trong javascript:
Các kỹ thuật codingJavascript ES6, Promise+ Async – Await từ cơ bản đến nâng cao, áp dụng vào các trường hợp, các bài toán làm dự án cụ thể, từ đó các bạn sẽ có nhiều kinh nghiệm lập trình hơn là việc chỉ học và làm các ví dụ basic.
Phân tích thiết kế cơ sở dữ liệu:
Cách để lên ý tưởng, dựa vào ý tưởng rồi thiết kế cơ sở dữ liệu, áp dụng coding vớiMongoDBđể lưu trữ dữ liệu cho ứng dụng.
Xử lý Real-time:
Các kỹ thuật xử lý real-time thời gian thực sử dụng Web Socket & module Socket.IO
Streaming Video với công nghệ Web RTC:
Công nghệ Web RTC, Peer to Peer, Turn Server là gì và ứng dụng chúng vào việc streaming video trực tuyến giữa các người dùng với nhau, hay gọi đơn giản là chức năng call video trực tuyến real-time.
Các kiến thức xử lý giao diện – Front-end:
Các kiến thức nâng cao về HTML – HTML5, CSS – CSS3, xử lý DOM với Javascript & Jquery, Ajax request… và áp dụng vào từng bài toán xử lý hiển thị ứng dụng phía client.
Nâng cao về Design Pattern, tư duy logic code:
Tới một góc nhìn bao quát và nâng cao hơn là sau khóa học, các bạn có thể làm được và nắm vững được trong tay cách để tạo ra một Design Pattern tối ưu cho dự án.
Một luồng Request API hoạt động như thế nào, chạy từ đâu tới đâu, clients, routing, controller, services, model…vv…
Coding conventicons, clean code, sử dụng Git – GitHub:
Cho tới việc coding conventions, clean code, các kỹ thuật sử dụng Git – Github chuyên nghiệp trong quy trình làm việc nhóm – Teamwork thực tế mà ít nơi nào có thể dạy cho các bạn trước khi các bạn đi làm.
Chia sẻ Tip tricks, những kinh nghiệm xử lý logic code:
Và còn rất nhiều những tip tricks, những kinh nghiệm từ quá trình đi làm dự án thực tế của mình cũng áp dụng và truyền đạt lại cho các bạn trong khóa học này.
58 Video hướng dẫn rõ ràng chi tiết từ A-Z, từ những dòng code đầu tiên:
Còn về ứng dụng, chắc chắn mình sẽ hướng dẫn rõ ràng từ A-Z, từ dòng code số 0 trở đi cho các bạn để khi học hết khóa học, các bạn sẽ làm được một ứng dụng Mesenger hoàn chỉnh các chức năng như trong video mình demo ở trên.
3. Khóa học này phù hợp với những đối tượng như thế nào?
Quan trọng:
– Trước hết, có một điều mình cần làm rõ với các bạn luôn, đó là mình không đi theo lối dạy basic cơ bản như rất nhiều khóa học trên mạng hiện tại, mà mình dạy các bạn làm một dự án thực tế (như trong video mình đã giới thiệu).
– Chính vì vậy mà mỗi video mình làm ra trung bình sẽ dao động trong khoảng 30 phút đến 1 tiếng, có vài cái nhiều hơn một chút, vì khi làm dự án thực tế những tính năng có khi phải mất đến 1 hoặc 2 ngày mới xong, nên con số 30 phút hay 1 tiếng là không thể giảm hơn được nữa.
– Nên nếu đọc đến đây, bạn nào tự thấy không thể kiên nhẫn xem một cái video dài thì có thể dừng lại nhé.
Một điều quan trọng nữa mà mình muốn nhấn mạnh trong phần này đó là: “Không cần bạn phải có một bộ não xuất sắc, hay là IQ cao thì mới học được lập trình, mà điều thực sự quan trọng mình mong ở các bạn là phải rèn được đức tính kiên trì, sự chịu khó tìm tòi học hỏi, thì bạn đã dư khả năng để theo ngành lập trình này rồi.”
Trước khi đến với khóa học này, mình cần các bạn phải là người có kiến thức nền tảng cơ bản về lập trình, ngôn ngữ nào cũng được, ưu tiên nhất vẫn là Javascript.
Tại sao phải cần có nền tảng về lập trình? Vì khóa học của mình không dạy các bạn if – else hay for, while…. là gì, đó là những kiến thức rất căn bản, mà mình sẽ dạy các bạn sử dụng chúng cho mục đích hoàn thành công việc.
Node.js và MongoDB cơ bản, cái này nếu các bạn có thì càng tốt, còn nếu các bạn chưa có kiến thức này thì cũng không vấn đề gì, các bạn vẫn sẽ học được khóa học của mình.
Mình vẫn khuyến khích các bạn tham khảo qua trước 2 liên kết dưới đây thì sẽ dễ dàng hơn với các bạn trong quá trình học:
Node.js: https://www.w3schools.com/nodejs/
MongoDB: https://www.w3schools.com/nodejs/nodejs_mongodb.asp
Trong trường hợp bạn đã quên mất, Node.js đã hỗ trợ async/await kể từ phiên bản 7.6. Nếu bạn chưa thử qua, bài viết này sẽ liệt kê các lý do cùng ví dụ để giải thích tại sao bạn nên chọn nó.
Async/await 101
Với những ai chưa hề nghe qua về Async/await thì đây là những giới thiệu ngắn gọn:
Async/await là cách mới để viết code bất đồng bộ. Các phương pháp làm việc với code bất đồng bộ trước đây là sử dụng callback và promise.
Async/await là khái niệm được xây dựng ở tầng trên promise. Do đó nó không thể sử dụng với callback thuần.
Async/await cũng giống như promise, là non-blocking.
Async/await làm cho code bất đồng bộ nhìn và chạy gần giống như code đồng bộ.
Cú pháp
Giả sử một hàm getJSON trả về một promise, promise đó chứa 1 vài đối tượng JSON. Ta cần gọi hàm đó, log các đối tượng JSON ra, sau đó trả về "done".
Đoạn code sau miêu tả quá trình trên, sử dụng promise.
Hàm có thêm từ khóa asyncphía trước. Từ khóa awaitchỉ được sử dụng bên trong hàm được định nghĩa với async. Bất cứ hàm asyncnào cũng sẽ trả về 1 promise một cách không tường minh, và giá trị resolve của promise sẽ là bất cứ cái gì mà hàm return (trong trường hợp này là chuỗi "done").
Nhận xét trên cũng đồng nghĩa với việc ta không thể sử dụng await phía trước đoạn code chứa từ khóa async
// this will not work in top level
// await makeRequest()
// this will work
makeRequest().then((result) => {
// do something
})
await getJSON() có nghĩa là lời gọi console.logsẽ chờ đến khi promise getJSON()được xử lý và trả về giá trị.
Đơn giản nhất chính là số lượng code ta cần viết đã giảm đi đáng kể. Trong ví dụ trên, rõ ràng rằng ta đã tiết kiệm được rất nhiều dòng code. Ta không cần viết .then, tạo 1 hàm anonimous để xử lý response, hay là đặt tên data cho 1 biến ta không sử dụng. Ta tránh được các khối code lồng nhau. Những lợi ích nho nhỏ này sẽ tích tụ dần dần trong những đoạn code lớn, những project thật và sẽ trở nên rất đáng giá.
2. Error handling
Async/await giúp ta xử lý cả error đồng bộ lẫn error bất đồng bộ theo cùng 1 cấu trúc. Tạm biệt try/catch. Với đoạn code dưới dùng promise, try/catch sẽ không bắt được lỗi nếu JSON.parselỗi do nó xảy ra bên trong promise. Ta cần gọi .catch bên trong promise và lặp lại code xử lý error, điều mà chắc chắn sẽ trở nên rắc rối hơn cả console.logtrong đoạn code production.
const makeRequest = () => {
try {
getJSON()
.then(result => {
// this parse may fail
const data = JSON.parse(result)
console.log(data)
})
// uncomment this block to handle asynchronous errors
// .catch((err) => {
// console.log(err)
// })
} catch (err) {
console.log(err)
}
}
Bây giờ hãy nhìn vào đoạn code sử dụng async/await. Khối catchgiờ sẽ xử lý các lỗi parsing.
const makeRequest = async () => {
try {
// this parse may fail
const data = JSON.parse(await getJSON())
console.log(data)
} catch (err) {
console.log(err)
}
}
3. Câu lệnh điều kiện
Hãy xem thử 1 đoạn code như dưới đây. Đoạn code này sẽ fetch dữ liệu và quyết định trả về giá trị hay là lấy thêm dữ liệu.
Đoạn code đã dần dần giống với mô hình “xyz hell” mà ta thường thấy. Tổng cộng code có 6 level nested. Khi sử dụng async/await, ta sẽ có đoạn code mới dễ đọc hơn.
Hẳn bạn đã từng lâm vào tính huống sau: bạn cần gọi promise1, sau đó sử dụng giá trị nó trả về để gọi promise2 cuối cùng sử dụng kết quả trả về của cả 2 promise trên để gọi promise3. Code của bạn sẽ thành ra thế này.
Nếu promise3không yêu cầu tham số value1, promise sẽ bớt lớp nest đi 1 chút. Nếu bạn theo chủ nghĩa cầu toàn, bạn có thể giải quyết bằng cách wrap cả 2 giá trị value1 và value2 bằng Promise.all tránh được các lớp nest giống như đoạn code dưới.
Phương pháp này đã hi sinh tính ngữ nghĩa để đổi lấy tính dễ đọc của code. Đơn giản vì chả có lý do gì mà value1 & value2 được đặt chung vào 1 mảng, ngoại trừ việc làm như thế sẽ tránh được promise bị nest.
Tuy nhiên cái logic này trở nên cực kì ngớ ngẩn khi ta sử dụng async/await.
Khi bạn phát triển ứng dụng trên môi trường local, điều này thoạt nhìn không có quá nhiều tác dụng. Tuy nhiên với production server, nó lại rất hữu ích với Error Logs. Với những tình huống đó, biết được error xảy ra trong makeRequestsẽ tốt hơn rất nhiều khi được báo rằng error nằm trong thenphía sau then phía sau then….
6. Debug
Điều tuyệt vời cuối cùng khi bạn làm việc với async/await đó là việc debug trở nên rất đơn giản. Debug với Promise chưa bao giờ là công việc dễ chịu vì 2 lý do sau:
1/ Bạn không thể đặt breakpoint trong arrow function trả về expression.
2/ Nếu bạn đặt breakpoint bên trong khối .thenvà sử dụng short-cut debug như step-over, trình debug sẽ không chuyển đến khối .then kế tiếp bởi vì nó chỉ “step” ở các đoạn code đồng bộ. Với async/await, bạn không cần arrow function quá nhiều nữa, bạn hoàn toàn có thể step qua lời gọi await y như với code đồng bộ.
Kết luận
Async/await là 1 trong những tính năng mang tính cách mạng được thêm vào JavaScript trong vài năm gần đây. Nó giúp bạn nhận ra Promise còn thiếu sót như thế nào, cũng như cung cấp giải pháp thay thế.
Mobile Developer là những lập trình viên chuyên về công nghệ di động như phát triển ứng dụng trên các nền tảng Google Phone Android, Apple Apple iOS và Microsoft, Windows Phone. Nhiệm vụ chính của một Mobile Developer là phối hợp với các nhóm chức năng để xây dựng và phát triển các chức năng của ứng dụng di động, không ngừng cải thiện và tối ưu hóa ứng dụng di động để đáp ứng nhu cầu người dùng. Hy vọng, Mẫu bảng công việc lập trình Mobile này sẽ giúp các bộ phận nhân sự dễ dàng hơn cho việc tuyển dụng những vị trí này.
Về lập trình viên Mobile: Để thành một Mobile Developer giỏi, các lập trình viên cần nắm rõ cấu trúc dữ liệu và giải thuật, kỹ thuật lập trình hướng đối tượng cũng như có kiến thức hoặc kinh nghiệm về một trong các ngôn ngữ các ngôn ngữ Java (Android) hoặc Swift/Objective-C (iOS).… để cùng tham gia nghiên cứu, thiết kế, phát triển các ứng dụng phục vụ cho sản phẩm công ty/ khách hàng.
Mẫu bảng công việc lập trình Mobile
YÊU CẦU CÔNG VIỆC
Kinh nghiệm làm việc với lập trình Mobile trên nền tảng Android hoặc iOS
Thành thạo một trong các ngôn ngữ các ngôn ngữ Java (Android) hoặc Swift/Objective-C (iOS).
Trải nghiệm với các thư viện và API của bên thứ ba
Có kiến thức tốt về lập trình hướng đối tượng
Kỹ năng phân tích tuyệt vời và thái độ giải quyết vấn đề tốt
Khả năng thực hiện trong môi trường nhóm
Có sản phẩm được phát hành trên App store là lợi thế
MÔ TẢ CÔNG VIỆC
Xây dựng và phát triển các tính năng mới cho các ứng dụng iOS / Android
Phân tích, thiết kế và lập trình các ứng dụng theo định hướng của công ty
Hỗ trợ toàn bộ vòng đời ứng dụng (khái niệm, thiết kế, thử nghiệm, phát hành và hỗ trợ
Phát triển giao diện lập trình ứng dụng (API) để hỗ trợ chức năng di động
Khắc phục sự cố và gỡ lỗi để tối ưu hóa hiệu suất
Nghiên cứu và đề xuất các sản phẩm, ứng dụng và giao thức di động mới
Tham khảo thêm những công việc lập trình hot nhất thị trường tại đây
Như chúng ta đã biết, React là một thư viện JavaScript giúp thiết kế UI. Nhưng không phải ai cũng biết hết các công cụ mà mình giới thiệu hôm nay, sẽ giúp các bạn có những trải nghiệm với React thú vị hơn rất nhiều.
Dưới đây là 22 công cụ cho lập trình viên React 2021 bạn không thể bỏ qua. Cùng khám phá nhé!
Có bao giờ bạn tự hỏi liệu có package hay phần nào trong app của bạn đang chiếm hết dung lượng chưa? Nếu vậy thì webpack-bundle-analyzer sẽ giúp bạn trả lời câu hỏi này đấy. Công cụ này sẽ giúp bạn biết được những file đầu ra đang chiếm nhiều dung lượng trong app.
Nó sẽ tạo ra một máy chủ trực tiếp và hiển thị trực quan hoá treemap tương tác cho bạn. Với công cụ này, bạn có thể biết file đó nằm ở đâu, kích cỡ gzip của chúng, các tệp cha/con của chúng,…
Bạn có thể tối ưu app React của mình hơn rất nhiều với công cụ này. Mình đã screenshot lại cho các bạn thấy lúc nó hoạt động:
Dễ dàng thấy là các gói pdf chiếm hầu hết dung lượng của app. Bên cạnh đó chúng còn chiếm nhiều phần hiển thị trên màn hình, rất dễ thấy và phân tích.
Tuy nhiên, hình trên chỉ là phần cơ bản. Bạn có thể tuỳ chỉnh để thấy chi tiết hơn như generateStatsFile: true và có thể lưu file HTML tĩnh ở đâu đó bên ngoài để sử dụng cho lần sau.
react-proto
react-proto là một công cụ prototyping dành cho lập trình viên và designer. Đây là một phần mềm dành cho máy tính để bàn, nên bạn cần phải download và cài đặt nó trước khi sử dụng.
Khi sử dụng nó sẽ trông như thế này:
Ứng dụng này cho phép bạn khai báo props và các loại của chúng, xem component trong 1 cây, thêm hình nền, định nghĩa chúng là stateful hay stateless, component cha là gì, phóng to/thu nhỏ, xuất prototype vào một project mới hoặc project đã có sẵn…
Mặc dù ứng dụng này có vẻ dành cho người xài Mac, nhưng nó vẫn hoạt động rất tốt trên Window các bạn nhé.
Sau khi hoàn thành UI, bạn có thể chọn xuất sang một project đã có sẵn hoặc là một project mới vẫn được. Nếu bạn chọn xuất sang project có sẵn và chọn thư mục gốc, nó sẽ xuất chúng sang component ./src/ như thế này:
Và đây là một ví dụ của một trong các component mà chúng ta có:
react-proto hiện đã có hơn 2000 sao trên GitHub. Cá nhân mình thấy ứng dụng này cần update và làm việc với các phát hành react hook nhiều hơn.
Nó không phóng to được nếu bạn không có hình nền. Nói một cách khác, nếu bạn import hình nền, zoom out, sau đó xoá hình nền thì bạn sẽ không thể zoom trở lại vì các nút đã bị mờ đi. Cách duy nhất để zoom trở lại là thêm một cái hình nền lại, sau đó xoá nó trước khi bạn zoom.
Chính lỗ hổng này làm mình thay đổi quan điểm về ứng dụng này, nhưng mình vẫn quyết định đưa nó vào danh sách hôm nay vì chúng ta chưa thấy nó ở bấy kì đâu. Thêm nữa là ứng dụng này có khả năng tạo danh sách kho lưu trữ mở, một xu hướng của tương lai (tính năng của chúng rất quan trọng, nhưng có lẽ chúng vẫn còn chưa được tập trung phát triển).
why-did-you-update
Why-did-you-update là công cụ giúp monkey patch React để thông báo cho bạn các tái xuất có thể tránh được. Công cụ này không chỉ hỗ trợ bạn cải thiện performance cho dự án, mà nó còn giúp bạn hiểu được cách React hoạt động. Khi bạn đã hiểu hơn về cách hoạt động của React, bạn sẽ trở thành một lập trình viên React tốt hơn.
Bạn có thể đính kèm một listener cho một component bất kỳ bằng cách khai báo whyDidYouRender với giá trị true như sau:
Sau đó giao diện điều khiển của bạn sẽ có nhiều cảnh báo cực kỳ khó chịu:
Nhưng đừng hiểu sai nhé. Hãy tận dụng những thông báo khó chịu đó để khắc phục những rerender lãng phí, và bạn cũng sẽ được yên thân ngay thôi.
create-react-app
Mọi người chắc hẳn đã biết create-react-app là công cụ nhanh nhất để bắt đầu một dự án React (Tất nhiên là với những tính năng hiện đại nữa). Còn gì dễ hơn npx creat-react-app <name> nữa đúng không nào?
Hầu như mọi tutotials của mình đều là về xây dựng giao diện React với create-react-app, đơn giản là vì nó nhanh và dễ dàng.
Một vài thứ mà có thể bạn chưa biết là cách tạo một dự án typescript sử dụng CRA. Bạn chỉ cần thêm --typescript vào cuối như thế này:
npx create-react-app <name> --typescript
Và thế là bạn không còn gặp rắc rối khi thêm thủ công typescript vào CRA nữa rồi đó.
react-lifecycle-visualizer
react-lifecycle-visualizer là một npm hỗ trợ tìm và hiển thị các phương pháp vòng đời của React Component tuỳ ý.
Tuy nhiên, công cụ này có một nhược điểm là nó chỉ hoạt động với các class component, còn hook thì chưa được hỗ trợ.
Guppy
Guppylà một trình quản lý ứng dụng thân thiện, miễn phí cho React chạy trên máy tính để bạn. Công cụ này có vẻ dành cho những người mới làm quen với React. Tuy nhiên nó cũng rất hữu ích đối với các lập trình viên “lão làng” đấy.
Nó cũng cấp giao diện người dùng thân thiện cho nhiều loại tác vụ mà lập trình viên React thường gặp như khởi tạo dự án mới, thực hiện các tác vụ và quản lý các dependency.
Windows đã hỗ trợ công cụ này vào tháng 8 năm 2018, nên bạn có thể yên tâm là nó đa nền tảng.
react-testing-library
Mình rất thích react-testing-library nó luôn đem lại cảm giác làm test unit rất trơn tru. Thư viện này cung cấp các tiện ích test DOM, khuyến khích thực hành test rất tốt cho các bạn.
Giải pháp này hướng đến giải quyết vấn đề về test các chi tiết triển khai. Thay vào đó, nó sẽ test đầu vào/ra của các React Component như những gì mà người dùng thấy.
Kiểm tra chi tiết thực hiện không phải là cách hiệu quả để đảm bảo app của bạn hoạt động như mong đợi. Chắc chắn là bạn sẽ thấy tự tin hơn khi biết cách component nhận data cần thiết, hay phương pháp sắp xếp nào để sử dụng,… thế nhưng nếu bạn phải đổi cách thực hiện, trỏ đến một cơ sở dữ liệu khác và test unit của bạn sẽ thất bại vì chúng là những chi tiết triển khai được kết hợp logic.
Vấn đề này cũng được react-testing-library giải quyết, vì tất cả bạn cần cũng chỉ là giao diện người dùng của bạn hoạt động tốt và chính xác, cách đưa data vào component cũng không thật sự quan trọng miễn là output như mong đợi là được.
Đây là một ví dụ cách mà bạn có thể đặt test khi sử dụng thư viện này:
// Hoist helper functions (but not vars) to reuse between test cases
const renderComponent = ({ count }) =>
render(
<StateMock state={{ count }}>
<StatefulCounter />
</StateMock>,
)
it('renders initial count', async () => {
// Render new instance in every test to prevent leaking state
const { getByText } = renderComponent({ count: 5 })
await waitForElement(() => getByText(/clicked 5 times/i))
})
it('increments count', async () => {
// Render new instance in every test to prevent leaking state
const { getByText } = renderComponent({ count: 5 })
fireEvent.click(getByText('+1'))
await waitForElement(() => getByText(/clicked 6 times/i))
})
React Developers Tools
React developer tools là một tiện ích cho phép kiểm tra phân cấp React Component trong các công cụ dành cho nhà phát triển Chrome và Firefox.
Đây là công cụ phổ biến nhất trong danh sách này và là một trong những công cụ hỗ trợ các nhà phát triển rất nhiều để debug ứng dụng.
Bit
Một cách thay thế hay nhất cho việc dùng các thư viện component như material-ui hay semantic-ui-react chính là Bit. Công cụ này cho phép bạn khám phá hàng ngàn component mã nguồn mở và sử dụng chúng để xây dựng dự án.
Có rất nhiều React Component có sẵn khác nhau dành cho mọi người. Bao gồm tab, button, chart, table, điều hướng, dropdown, tải spinner, bộ chọn ngày, breadcrumb, icon, layout,… Chúng được tải lên bởi những React Developer khác như mình và bạn. Nhưng cũng có các tiện ích có sẵn như định dạng khoảng cách giữa các ngày,…
Storybook
Nếu bạn chưa biết về storybook, mình thật lòng khuyên bạn nên bắt đầu dúng nó ngay bây giờ nếu bạn muốn xây dựng UI component dễ dàng hơn. Công cụ này khởi động một máy chủ phát triển trực tiếp với tính năng hot reloading, giúp bạn phát triển react component theo thời gian thực.
Điều thú vị nữa ở công cụ này là bạn có thể sử dụng các addon mã nguồn mở hiện tại để đưa trải nghiệm phát triển của bạn lên tầm cao mới. Ví dụ, với storybook-readme, bạn có thể tạo một documentation readme trong khi phát triển react component để sử dụng sản production ngay trên cùng một trang.
React Sight
Có bao giờ bạn suy nghĩ rằng app của bạn sẽ như thế nào ở trong 1 flow chart? React sight sẽ cho bạn hình dung ra bằng cách hiển thị một cây hiearachy của toàn bộ app. Công cụ này cũng hỗ trợ react router, redux và react fiber nữa.
Với công cụ này, bạn chỉ cần di chuột qua các node là các liên kết đến các component liên quan trực tiếp đến chúng trong cây.
Nếu bạn gặp vấn đề trong việc coi kết quả, bạn có thể gõ chrome:extensions trên thanh địa chỉ của bạn, vào react-sight và kích hoạt Allow access to file URLs
react-cosmos
react-cosmos là một công cụ phát triển giúp tạo các react component tái sử dụng.
Nó scan project của bạn cho các component và cho phép bạn:
Render component dưới bất kỳ props, context và state nào.
Mock mọi dependency bên ngoài (như API response. localStorage,…)
Xem trạng thái ứng dụng phát triển trong thời gian thực khi tương tác với các phiên bản đang chạy.
Đây là một trong những công cụ tốt nhất hiện có giúp react nhanh hơn cả cái chớp mắt.
CodeSandbox là một trình chỉnh sửa online cho phép bạn tạo ứng dụng web từ prototype đến lúc triển khai, tất tần tật chỉ trên 1 website thôi.
Ban đầu CodeSanbox chỉ hỗ trợ React ở các giai đoạn trước. Thế nhưng giờ đây chúng đã mở rộng sang các mẫu khởi động bổ sung cho các thư viện như Vue và Angular. Nó cũng hỗ trợ khởi động project react web tiếp theo bằng cách tạo các project với các trình tạo trang tĩnh phổ biến như gatsby hay nextjs.
Có nhiều thứ để nói về CodeSandbox, như là tính active của nó.
Nếu bạn cần khám phá một vài project mà người ta đang xây dựng, bạn chỉ cần click explore và truy cập vào một đống ví dụ code giúp bạn hoàn thiện ở các project sau:
Công cụ này không khác gì một trình soạn thảo VSCode mạnh mẽ.
Bạn có thể tìm hiểu chi tiết hơn về CodeSandbox tại đây.
React Bits
React bits là một kho online bao gồm react pattern, kỹ thuật, tips và tricks… Giúp bạn tiếp cận nhanh chóng với các design pattern và kỹ thuật khác nhau, anti-pattern, styling, biến thể UX và các tài liệu react liên quan vô cùng hữu ích.
Nó có một vài ví dụ về concept như các prop proxying, composition xử lý các UX khác nhau trong các tình huống khác nhau, và thậm chí phơi bày một số vấn đề mà mọi nhà phát triển React cần biết.
Folderize
Folderize là một tiện ích của VSCode mới được ra mắt trong thời gian gần đây. Nó cho phép bạn chuyển 1 file component thành một cấu trúc folder component. React Component sẽ vẫn là component, chỉ là giờ nó được chuyển thành một danh mục.
Ví dụ: Nếu bạn đang tạo 1 react component cần một vài file như props để hiển thị thông tin hữu ích như meta data. Logic ở đây là meta data component tốn nhiều dòng nên bạn quyết định chia chúng thành 1 file riêng. Nhưng khi bạn làm vậy, bạn sẽ có 2 file có liên hệ với nhau. Nếu bạn có một danh mục thì nó sẽ như thế nào:
Bạn có thể lấy FileView.js và FileMetadata.js vào một danh mục như Apples.
Đặc biệt bạn có thể muốn add thêm component liên quan đến file như FileScanner.js.
Và đó là những gì folderize sẽ làm cho bạn để có một cấu trúc như thế này:
import React from 'react'
import FileView from './src/components/FileView'
const App = (props) => <FileView {...props} />
export default App
React Starter Projects
React Starter Projects cho bạn một danh sách các dự án khởi tạo React rất đỉnh. Nếu bạn là kiểu người muốn tìm hiểu nhanh và cần nhiều sự lựa chọn tốt, công cụ này chắc chắn dành cho bạn.
Khi tìm được project khởi tạo ưng ý, bạn có thể clone repository dễ dàng, sửa đổi cho phù hợp rồi có ngay một ứng dụng của riêng mình. Tuy nhiên không phải tất cả đều dành cho việc clone, vì một số thứ cần được cài đặt thay thế. Điều này sẽ gây khó khăn cho dự án của bạn. Tuy nhiên bạn có thể update thường xuyên và luôn giữ cho project của mình clean nhất.
Highlight Updates
Mình nghĩ đây là công cụ quan trọng nhất mà bất kì ai cũng nên có trong “đồ đồ nghề” của mình. Đây là một tính năng tiện ích mở rộng devtools, cho phép bạn xem component nào trên trang re-render không cần thiết:
Nó giúp bạn phát hiện các tắt nghẽn trong lúc lập trình và tô màu cam hoặc đỏ các lỗi để dễ nhìn thấy hơn.
Trừ khi bạn muốn tạo app không ai dùng, thì tạo sao không thử ngay công cụ này nào.
React Diff Viewer
react-diff-viewer là một trình xem văn bản đơn giản và đẹp đẽ dành cho Diff và React. Công cụ này hỗ trợ các tính năng như chế độ xem split, chế độ xem inline, word diff, line highlight,…
Công cụ này sẽ vô cùng hữu ích nếu bạn đang cố gắng nhúng tính năng này vào Ahem Boostnote và tuỳ chỉnh để nó phù hợp với app của bạn. (như màu của theme, kết hợp tài liệu với storybook,…)
js.coach
js.coach là trang mình dùng nhiều nhất để tìm tài liệu liên quan đến React. Mình không hiểu vì sao không có nhiều người nói về trang này, nhưng thật sự là mình tìm được mọi thứ mình cần trên đó. Nhanh chóng, dễ dàng, cập nhật liên tục và không bao giờ thiếu tài liệu cần thiết là tất cả mà bạn cần cho dự án của bạn.
Gần đây học còn thêm tab React VR vào nữa, rất tuyệt đúng không.
awesome-react
Kho lưu trữ mã nguồn mở awesome-react của GitHub là một kho đầy những thứ đỉnh cao về React dành cho bạn.
Mình có thể chẳng cần quan tâm đến những website khác và chỉ cần học về React trên đây thôi cũng đủ rồi. Bạn sẽ tìm được hàng loạt tài nguyên hữu ích giúp tạo nên những app React tuyệt vời.
proton-native
proton-native cho bạn một môi trường react để tạo các ứng dụng máy tính để bàn đa nền tảng.
Công cụ gần như thay thế cho Electron, có một số tính năng như:
Cùng syntax với React Native
Làm việc với các thư viện React hiện nay như Redux
Đa nền tảng
Native component, không còn Electron
Tương thích với mọi package Node.js thông thường
Nếu bạn cần có thể đọc chi tiết về công cụ này tạiđây.
Maven là công cụ quản lý và thiết lập tự động 1 dự án phần mềm. Chủ yếu dùng cho các lập trình viên java, nhưng nó cũng có thể được dùng để xây dựng và quản lý các dự án dùng C#, Ruby, Scala hay ngôn ngữ khác.
Maven phục vụ mục đích tương tự như Apache Ant, nhưng nó dựa trên khái niệm khác và cách hoạt động khác.
Maven hỗ trợ việc tự động hóa các quá trình tạo dự án ban đầu, thực hiện biên dịch, kiểm thử, đóng gói và triển khai sản phẩm.
Được phát triển bằng ngôn ngữ Java cho phép Maven chạy trên nhiều nền tảng khác nhau: Windows, Linux và Mac OS…
2. Maven hoạt động như nào?
Maven dùng khái niệm Project Object Model (POM) để mô tả việc build project, các thành phần phụ thuộc và các module. Nó định nghĩa trước các target cho việc khai báo task, trình biên dịch, đóng gói và thứ tự hoạt động để mọi việc diến ra tốt nhất.
Trong mỗi project Maven tạo ra một file .pom, trong file này định nghĩa ra những task như task khi chạy test, task khi build và khi chạy Maven sẽ dựa vào những định nghĩa này để thao tác với project.
Ví dụ file .pom
<!-- .pom -->
<project>
<!-- model version is always 4.0.0 for Maven 2.x POMs -->
<modelVersion>4.0.0</modelVersion>
<!-- project coordinates, i.e. a group of values which
uniquely identify this project -->
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<version>1.0</version>
<!-- library dependencies -->
<dependencies>
<dependency>
<!-- coordinates of the required library -->
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<!-- this dependency is only used for running and compiling tests -->
<scope>test</scope>
</dependency>
</dependencies>
</project>
3. Tại Sao cần Maven?
Khi một project do nhiều nhóm phát triển ví dụ có 2 team cùng tham gia dự án, 2 team đó ở 2 quốc gia khác nhau vì thế chúng ta luôn cần có một sự liên lạc để thông nhất trong việc lập trình vì thế phải có một cái chuẩn nào đó để tất cả mọi người cùng tuân theo, như trong việc sử dụng những thư viện nào, version của thư viện tất cả những thứ như vậy đều được Maven quản lý.
Đối với những hệ thống lớn, phức tạp sử dụng nhiều thư viện lại đòi hỏi phải release liên tục cho nên công việc đóng gói (build & deploy), quản lý, nâng cấp và bào trì chúng rất mất thời gian, và lúc đó ta có Maven.
Dependency chính là cách import thư viện vào project thông qua Maven
Cơ chế import thư viện thông qua maven.
Ví dụ để import thư viện redis, bình thường ta sẽ dowload file redis.jar về rồi buildpath trong eclipse, nhưng với thẻ dependency, Maven sẽ tự động dowload thư viện đó về thư mục ~/.m2 trên máy local và buildpath vào project.
Làm việc với ngày và giờ trong PHP không phải là nhiệm vụ dễ dàng gì. Chúng ta phải đối mặt với các vấn đề về thời gian, định dạng, nhiều tính toán, v.v.
Có một package khá tiện lợi có tên Carbon có thể giúp việc xử lý ngày / giờ trong PHP dễ dàng hơn và có nhiều ngữ nghĩa hơn để code của chúng tôi có thể trở nên dễ đọc và dễ bảo trì hơn.
Carbon là gì?
Carbon là một gói phần mềm được phát triển bởi Brian Nesbit mở rộng từ class DateTime của PHP. Từ phiên bản 5.3, Laravel đã tích hợp sẵn thư viện này vào Project. Việc sử dụng tốt thư viện này sẽ giúp bạn rất nhiều vấn đề về xử lý thời gian. Thư viện này giúp chúng ta rất nhiều trong việc xử lý datetime trong PHP. Điển hình như:
Xử lý timezone.
Lấy ngày tháng hiện tại dễ dàng.
Convert datetime sang định dạng khác để đọc
Dễ dàng thao tác với datetime.
Chuyển đổi cú pháp là cụm từ tiếng anh sang datetime.
Cách sử dụng Carbon trong Laravel
– Bạn cần import thư viện để sử dụng:
<?php
use Carbon\Carbon;
Lấy thời gian:
Carbon::now(); // thời gian hiện tại 2018-10-18 14:15:43
Carbon::yesterday(); //thời gian hôm qua 2018-10-17 00:00:00
Carbon::tomorrow(); // thời gian ngày mai 2018-10-19 00:00:00
$newYear = new Carbon('first day of January 2018'); // 2018-01-01 00:00:00
Để lấy tgian hiện tại tại Việt Nam ta sẽ thêm locale của Việt nam như sau:
Để biết thêm về các nước khác bạn có thể tại trang chủ của PHP: Timezone
Bạn cũng có thể chuyển đổi kiểu datetime khác:
$dt = Carbon::now('Asia/Ho_Chi_Minh');
echo $dt->toDayDateTimeString(); Thu, Oct 18, 2018 9:16 PM
echo $dt->toFormattedDateString(); // Oct 18, 2018
echo $dt->format('l jS \\of F Y h:i:s A'); // Thursday 18th of October 2018 09:18:57 PM
echo $dt->toDateString(); // 2018-10-18
echo $dt->toTimeString(); // 21:16:20
echo $dt->toDateTimeString(); // 2018-10-18 21:16:16
– Các bạn cũng có thể chỉ lấy ngày, tháng, năm, giờ, phút, giây, ngày của tuần, ngày của tháng, ngày của năm, tuần của tháng, tuần của năm, số ngày trong tháng. Thật dễ dàng :))
Carbon::now()->day; //ngày
Carbon::now()->month; //tháng
Carbon::now()->year; //năm
Carbon::now()->hour; //giờ
Carbon::now()->minute; //phút
Carbon::now()->second; //giây
Carbon::now()->dayOfWeek; //ngày của tuần
Carbon::now()->dayOfYear; //ngày của năm
Carbon::now()->weekOfMonth; //ngày của tháng
Carbon::now()->weekOfYear; //tuần của năm
Carbon::now()->daysInMonth; //số ngày trong tháng
– Có thể tăng giảm ngày, tháng, năm, giờ, phút, giây bằng hàm 2 hàm add() và sub()
– Ta cũng có thể so sánh với thời gian hiện tại một cách dễ dàng: Nó sẽ trả về là true hay false.
$now = Carbon::now();
$now->isWeekday();
$now->isWeekend();
$now->isYesterday();
$now->isToday();
$now->isTomorrow();
$now->isFuture()
$now->isPast();
$now->isBirthday(); // là ngày sinh nhật hay không
Cách đây 2 năm, tôi chỉ tập trung vào lập trình Android native. Nhưng đến năm ngoái, khi công ty yêu cầu tôi học lập trình iOS, tôi đã khá phấn khích lúc đầu, nhưng sự phấn kích đó nhanh chóng phai nhạt dần, năng suất làm việc của tôi cũng suy giảm đi. Tôi nhận ra, mình phải học lại từ đầu tất cả mọi thứ như framework, các công cụ, IDE…
Và vì tôi rất thích đến các buổi meetup nên tôi cũng bắt đầu tham dự các buổi meetups của cả Android và iOS. Tôi cần phải cập nhật với những tính năng mới nhất trên cả 2 platforms, nên rất tốn thời gian và khó chịu khi khả năng học của tôi không nhanh. Vì vậy, tôi đã rất hứng thú khi React Native dành cho iOS ra đời.
React Native là một giải pháp giải pháp tối ưu để phát triển ứng dụng trên cả hai nền tảng iOS và Android được nhiều người lựa chọn hiện nay. Vậy React Native là gì? Hãy cùng tìm hiểu trong bài viết này.
React Native là gì?
React Native là một framework phát triển ứng dụng di động đa nền tảng (cross-platform) được phát triển bởi Meta (tên trước kia là Facebook). React Native cho phép bạn xây dựng ứng dụng di động cho cả nền tảng iOS và Android bằng việc sử dụng JavaScript.
REACT NATIVE – Learn once, write anywhere. Chỉ cần viết một lần là có thể build ứng dụng cho cả iOS lẫn Android.
Việc này giúp chúng ta có thể tiết kiệm được thời gian, công sức, tiền bạc. Giúp tốc độ ra sản phẩm cũng như cập nhật ứng dụng nhanh chóng mặt.
Hybrid App là sự kết hợp giữa ứng dụng Web và ứng dụng mobile. Hybrid app được xây dựng dựa trên HTML + CSS + JS và được đóng gói load bên trong một ứng dụng mobile thông qua một native container gọi là Webview. Hybrid có thể truy cập vào hầu hết các chức năng thuộc phần cứng của điện thoại di động bao gồm máy ảnh, danh bạ, cảm biến gia tốc, âm thanh…
Nhược điểm của Hybrid App đó chính là vấn đề hiệu năng (tốc độ chậm, giao diện không thân thiện…) sẽ bị ảnh hưởng đáng kể cũng như không tương tác được hết những tài nguyên của điện thoại thông mình.
Trái ngược lại, React Native biên dịch mã JavaScript sang mã native (ngôn ngữ lập trình gốc) cho iOS và Android, cho phép ứng dụng có hiệu suất gần như ứng dụng native thực sự.
Những ưu điểm của React Native
React Native cùng với Flutter đang là xu hướng lập trình di động hiện nay bởi tính đa nền tảng cũng như tiết kiệm thời gian triển khai dự án. Sau đây là những lợi ích mà nó đem lại cho việc triển khai dự án và bạn có thể trả lời cho câu hỏi có nên dùng React Native không?
1. Thời gian học ngắn hơn
Một lý do lập trình mobile app rất khó và tốn thời gian là vì thực tế bạn cần tìm hiểu 2 hệ sinh thái hoàn toàn khác biệt. Nếu bạn muốn lập trình app iOS, bạn phải học Swift hoặc Objective-C và Cocoa Pods.
Nếu muốn lập trình app Android, bạn cần học Java hoặc Kotlin và Android SDK. Tôi từng viết code với 3 ngôn ngữ là Swift, Objective C, Java và không thực sự hứng thú với việc tranh luận ngôn ngữ nào tốt hơn.
Tuy nhiên, điều tôi có thể nói là chúng khác nhau và việc học từng ngôn ngữ đó sẽ tốn khá nhiều thời gian. Điều tương tự cũng xảy ra với các frameworks: Cocoa Touch và Android SDK.
Tất nhiên, mỗi frameworks luôn có 1 gói các công cụ như công cụ testing, các libs, packages… và việc các dev phải cập nhật các tính năng mới nhất của mỗi hệ sinh thái là điều không thể bàn cãi.
Mặc khác, nếu bạn chọn lập trình trên React Native, phần lớn thời gian bạn sẽ chỉ cần học 1 bộ công cụ. Có rất nhiều thứ để bạn làm quen như: JavaScript, Node, React Native… nhưng chỉ có 1 công cụ duy nhất để học.
2. Khả năng tái sử dụng code
Khả năng sử dụng lại code đóng vai trò quan trọng trong lập trình phần mềm, nên mỗi khi bạn có thể sử dụng lại code thì React Native là công cụ tốt.
React Native không phải chỉ viết 1 lần mà nó chạy ở mọi nơi. Bất cứ khi nào bạn lập trình 1 app, bạn cần phải xây dựng UI trông native và phù hợp với hệ điều hành bạn hướng tới. Vì lý do này, 1 số UI code cần được viết theo đúng các chỉ dẫn và chuẩn mực tốt nhất của platform đó.
Tuy nhiên, sẽ luôn có vài UI code thông dụng có thể được chia sẻ chung với nhau cùng tất cả logic. Tính năng “có thể chia sẻ code” có rất nhiều lợi điểm như: tận dụng nguồn nhân lực tốt hơn, duy trì ít code hơn, ít bugs hơn, các tính năng trong cả 2 platforms cũng tương tự nhau…
3. Học 1 lần, viết ở mọi nơi
Khi team của Facebook tạo React Native, mục tiêu của họ là giúp các dev học 1 lần nhưng sử dụng được mọi platform. Bởi vì tất cả code của Android và iOS sử dụng cùng bộ công cụ, nên ý tưởng có một team dev làm app cho cả hai platform là thực hiện được – một điều ít khi xảy ra khi có rất ít dev lập trình cả hai platform iOS và Android.
Thậm chí, tôi còn cho rằng team đang lập trình web app sử dụng React.js sẽ không phải cực khổ nữa khi học lập trình React Native và bắt đầu làm mobile app.
4. Cộng đồng lớn
React Native đang trở lên rất phổ biến, nhiều developer đang đóng góp để làm React Native tốt hơn. Đặc biệt là nó được tạo ra và hỗ trợ bởi tập đoàn Facebook.
React Native Github repro là một nguồn mở và có hàng nghìn cộng tác viên hoạt động rất năng nổ.
Cộng đồng rất lớn và đang phát triển mạnh mẽ. Nhiều vấn đề đã và đang được giải quyết và bạn sẽ không cần phải tốn thời gian để nghiên cứu lại trong suốt quá trình học và làm việc với React Native.
Thói quen thông thường của dev khi code là test các thay đổi mỗi lần code được viết. Để thực hiện được, app cần phải được đóng gói lại và cài đặt hoặc trong 1 simulator hoặc một thiết bị thật sự.
Với React Native, phần lớn thời gian, bạn không cần phải tổng hợp lại app mỗi lần có thay đổi. Bạn chỉ cần làm mới app trong simulator, emulator hoặc thiết bị. Thậm chí còn có một tính năng là Live Reload để tự động refresh app mỗi lần phát hiện 1 thay đổi trong code.
6. Nguồn mở
React Native vẫn còn là công nghệ đang được sử dụng nhiều. Tuy vẫn còn nhiều lỗi, nhưng nhìn chung, các lập trình viên vẫn có thể sử dụng React Native vào giai đoạn production ở hầu hết các mobile app.
Ngoài ra vẫn còn vài tính năng có sẵn trong các lập trình native, chưa sử dụng được với React Native nhưng đây không phải là vấn đề lớn. Từ kinh nghiệm của bản thân, đây chỉ là chuyện đơn giản khi bạn đã quen thuộc với lập trình native.
Thêm nữa, khi React Native đã là nguồn mở, với cộng đồng lớn các lập trình viên đã hỗ trợ thực hiện nhiều tính năng hơn, fix bugs… Phần lớn thời gian, nếu bạn đang cố gắng lập trình 1 thứ gì đó đã quen thuộc trong mobile apps thì nhiều khả năng là nó đã được lập trình rồi.
Như bạn thấy, tôi thực sự rất lạc quan về React Native. Tôi vẫn nhớ lập trình Android và iOS native nhưng đồng thời rất hứng thú khi sử dụng React Native thời gian qua. Tôi nghĩ React Native sẽ là game – changer – kẻ thay đổi cục chơi trong lập trình mobile và khó lòng đợi được cho đến lúc nó trở thành platform không thể bỏ qua để lập trình mobile!
React Native là một giải pháp tuyệt vời cho phát triển ứng dụng trên điện thoại di động, tuy nhiên đến thời điểm hiện tại, vẫn còn tồn tại một số khuyết điểm:
Vẫn còn thiếu các component quan trọng nhưng dần dần cũng đang có thêm nhiều cập nhật mới kể từ bài viết này mà tôi chưa được biết.
Không build được ứng dụng iOS trên Window và Linux: do yêu cầu từ Apple, mọi ứng dụng iOS cần được sử dụng nhiều native libs, cert…từ Xcode.
React Native không thể build được ứng dụng “quá phức tạp” nếu bạn không biết Swift/Objecive-C, Java – tính phức tạp ở đây là ứng dụng của bạn cần phải chỉnh sửa các component. Để viết được 1 ứng dụng native bằng javascript thì “luôn luôn” có sẵn các component đã được viết từ Swift/Objective-C (iOS) và Java (Android) để bạn sử dụng. Trường hợp bạn muốn chỉnh sửa 1 component nào đó: thay đổi thành phần hoặc thêm API thì bạn phải tự viết bằng chính ngôn ngữ tương ứng của iOS hoặc Android. Nhờ cộng đồng lớn nên cũng có nhiều lập trình viên khác đã viết nhiều component cần thiết cho hầu hết ứng dụng (đây cũng là lý do vì sao Facebook biến React Native thành mã nguồn mở).
Không dùng để viết game có tính đồ họa và cách chơi phức tạp.
Dùng ES2015/ES6 nên đây là cấu trúc mới cho Javascript từ 2015, vì khá là mới nên những cấu trúc của nó có thể bạn chưa quen, dẫn tới việc khó khăn trong việc tiếp cận.
Cơ hội việc làm của React Native Developer
React Native là một framework phát triển ứng dụng di động đa nền tảng được sử dụng bởi một số công ty và doanh nghiệp lớn nhất thế giới, bao gồm Facebook, Instagram, Airbnb và Uber. Điều này dẫn đến một nhu cầu lớn về các nhà phát triển React Native có tay nghề cao.
Theo báo cáo thị trường IT Việt Nam 2023 do TopDev phát hành, lập trình viên React Native 3 – 4 năm kinh nghiệm có mức lương lên đến $1.512. Mức lương này có thể cao hơn tùy thuộc vào trình độ kinh nghiệm và kỹ năng của nhà phát triển.
React Native cũng là một công nghệ có nhu cầu cao trên toàn thế giới. Theo một nghiên cứu gần đây của Stack Overflow, React Native là một trong những framework phát triển ứng dụng di động phổ biến nhất. Điều này có nghĩa là các React Native developer có nhiều cơ hội việc làm ở cả trong và ngoài nước.
Tóm lại React Native là một framework phát triển ứng dụng di động đa nền tảng hiệu quả và linh hoạt. Với những ưu điểm vượt trội, React Native đang trở thành một lựa chọn hàng đầu cho các nhà phát triển ứng dụng di động.
Trên đây là bài viết về React Native, hy vọng bài viết của TopDev đã cung cấp cho bạn những thông tin hữu ích. Nếu bạn quan tâm đến React Native, hãy bắt đầu học ngay hôm nay để nắm bắt cơ hội nghề nghiệp hấp dẫn trong lĩnh vực công nghệ thông tin.
nhưng nó đã không làm việc. Và errors thông báo nói về req.body không tồn tại. Tôi thực sự không hiểu lý do tại sao nó không hoạt động mặc dù tôi đã làm tất cả theo đúng trình tự.
Điều tiếp theo tôi đã làm là cố gắng kiểm tra req object. Tôi đã cố gắng để tìm thấy data trong req object. Nhưng req object quá lớn và khó hiểu và tôi không thể thực sự tìm thấy những data mà tôi đang tìm kiếm.
Cuối cùng, tôi đã tìm đến bodyParser(), và tôi đã được biết
Bạn cần phải sử dụng bodyParser() nếu bạn muốn data form có sẵn trong req.body
Nhưng tôi vẫn không thực sự hiểu tại nó hoạt động như thế nào.
app.use()
Trước tiên để sử dụng bodyParser() bạn cần sử dụng đoạn code như sau:
app.use(bodyParser.json());
Để hiểu cách thức hoạt động trên, bạn phải hiểu cách middleware hoạt động trong Express. Cụ thể, khi app.use() được sử dụng với đối số làm một function:
app.use(function(req, res) {
// make somethings
});
Function sẽ đựợc thực hiện với mọi request
Function này sẽ hoạt động như một middleware.
Đối lập với khi app.use() được gọi với đối số là một string
app.use(\'/test\', cb);
Nó sẽ chỉ match với request bắt đầu với /test
bodyParser.json() trả về một function và khi function đó được dùng làm đối số cho app.use, nó hoạt động giống như bất kỳ middleware khác.
var cb = bodyParser.json();
app.use(cb);
Data form trong req object
Thông tin được gửi qua internet qua các gói tin. Trong Nodejs, request object được đọc theo stream và response được ghi bởi stream.
req.on(\'data\', function(chunk) {
// here\'s the chunk
});
Mỗi lần một đoạn của dữ liệu đến, bạn có thể sử dụng nó. Ví dụ một chuỗi như sau
abcdefghijklmnopqrstuvwxyz
cũng có thể là 5 đoạn
abcde
fghij
klmno
pqrst
uvwxyz
và bạn có khả năng truy cập mỗi đoạn dữ liệu.
Như vậy dữ liệu POST sẽ không có sẵn trên đối tượng req. Nếu bạn muốn truy cập dữ liệu POST, bạn phải lấy nó từ stream
app.use(function( req, res, next ) {
var data = \'\';
req.on(\'data\', function( chunk ) {
data += chunk;
});
req.on(\'end\', function() {
req.rawBody = data;
console.log( \'on end: \', data )
if (data && data.indexOf(\'{\') > -1 ) {
req.body = JSON.parse(data);
}
next();
});
});
bodyParser
bodyParser trả về một function hoạt động như một middleware. Chức năng lắng nghe trên req.on (\'data\') và xây dựng req.body từ các đoạn dữ liệu mà nó nhận được.
Nhưng có một số lưu ý. Về cơ bản, có nhiều cách khác nhau để định dạng dữ liệu bạn POST đến server:
application/x-www-form-urlencoded
multipart/form-data
application/json
application/xml
maybe some others
Nói tóm lại, bodyParser phải phân tích dữ liệu một cách khác nhau tùy thuộc vào loại của nó. bodyParser hỗ trợ các function khác nhau để làm điều này.
// for parsing application/json
app.use(bodyParser.json());
// for parsing application/x-www-form-urlencoded
app.use(bodyParser.urlencoded({ extended: true }));
// for parsing multipart/form-data
app.use(multer());
Với việc sử dụng bodyParser bạn có thể lấy được data form từ req.body
Đối với lập trình viên, việc đọc code (readable code là gì) là việc cực kỳ quan trọng. Chúng ta thường có rất nhiều quy tắc cũng như các luật lệ bất thành văn cho việc sử dụng tên variable có nghĩa. Khi một function trở nên lớn hơn thì chia nó thành các function nhỏ hơn. Sử dụng các design pattern tiêu chuẩn. Nhưng dù cho tất cả mọi thứ có tuân thủ đúng theo những quy tắc trên thì chúng vẫn là một mớ hỗn độn.
Chúng ta có thể giải quyết vấn đề này bằng cách đặt thêm nhiều quy tắc hơn: Nếu tên variable quá dài thì hãy tái cấu trúc logic cơ bản lại. Khi một class tích lũy quá nhiều method hỗ trợ thì có lẽ nên cần hai class. Đừng sử dụng các design pattern trong những context không phù hợp.
Những hướng dẫn như vậy không có đúng hay sai và bạn phải tự đưa ra quyết định cái nào là tốt nhất, vì vậy chúng đòi hỏi các developer phải viết cách chọn lọc. Hay nói một cách khác, các developer phải biết viết code dễ đọc.
Đây là một bài toán khó. Và để giải quyết bài toán này chúng ta cần xây dựng một bức tranh rộng hơn về khả năng đọc.
Vậy “dễ đọc” để làm gì?
Trong thực tế, việc code có dễ đọc hay không thường tương tự như “Tôi thích đọc nó”. Đây không phải là một điều tự nhận ra được. Bên cạnh tính chủ quan thì tính dễ đọc còn bị ảnh hưởng bởi kinh nghiệm trước đây của chúng ta về việc đọc.
Code khó đọc giống như một cuốn tiểu thuyết khó hiểu vậy: Đầy những comment tường thuật dài; các file thì đầy chữ và phải đọc theo thứ tự tuần tự; thiếu sử dụng lại từ. Chúng ta cố gắng khiến code dễ đọc, nhưng thường nhắm sai độc giả mục tiêu.
Có một sự khác biệt giữa tính dễ đọc và code dễ đọc.
“Code tạo ra giao diện. Nhưng chính nó cũng là một giao diện.”
Có phải code đẹp thì dễ đọc hơn không? Đẹp là một phần phụ của việc dễ đọc, nhưng nó không khiến code dễ đọc. Bên cạnh đó, mỗi người đều có quan niệm riêng về “cái đẹp”. Thế nên sớm muộn gì định nghĩa của việc dễ đọc cũng sẽ tăng dần lên thành một đống tab, space, dấu ngoặc nhọn, camelCase và nhiều format khác.
Có phải code dễ đọc khi nó có ít bug hơn không? Có “ít bug hơn” đương nhiên tốt nhưng cơ cấu ở đây là gì? Cảm giác tuyệt vời mà ai đó có được khi họ nhìn thấy code dễ đọc? Đọc code không thể triệu tập bug bất kể học có đọc đi đọc lại bao nhiều lần đi chăng nữa.
Có phải code dễ đọc khi nó dễ chỉnh sửa hơn không? Đây có vẻ như là lý do tốt nhất trong tất cả những lý do trên. Khi các requirement thay đổi, các tính năng được thêm vào, bug xuất hiện thì cuối cùng cũng sẽ cần một người để sửa code đó. Để chỉnh sửa mà không gây ra sự cố gì, họ cần phải hiểu họ đang chỉnh cái gì và cách chỉnh sửa của họ sẽ thay đổi hành vi như thế nào. Điều này khiến chúng ta nhận ra một điều mới: Code dễ đọc nên được chỉnh sửa một cách dễ dàng và an toàn.
Điều gì làm cho code dễ sửa hơn?
Lúc này, chúng ta phải nhìn lại các quy tắc một lần nữa: “Code dễ chỉnh sửa hơn khi tên variable có ý nghĩa”. Nhưng chúng ta đã thay thế “dễ đọc” thành “dễ sửa”. Chúng ta đang tìm một insight mới chứ không phải một đống ghi nhớ theo quy tắc cũ.
Hãy bắt đầu bằng cách đặt thực tế là chúng ta đang nói về code sang một bên. Lập trình đã xuất hiện từ vài thập kỷ trước nhưng chỉ là dấu chấm nhỏ trong lịch sử loài người. Nếu chúng ta tự giới hạn bản thân trong dấu chấm đó, chúng ta sẽ giới hạn ý tưởng của mình.
Thay vào đó, hãy nhìn về khả năng dễ đọc thông qua lăng kính của thiết kế giao diện. Cuộc sống của chúng ta chứa đầy các giao diện, digital và nhiều thứ khác. Một món đồ chơi luôn có thêm tính năng cuộn lại hoặc kêu chút chít. Một cánh cửa luôn có giao diện để người dùng mở, đóng và khóa nó. Một cuốn sách sắp xếp dữ liệu theo các trang để dễ lật hơn thay vì cuộn lên xuống. Bạn có thể tìm hiểu thêm về những giao diện như vậy thông qua các khóa học design hoặc hỏi design team trong công ty. Chúng ta đều đang sử dụng những giao diện tốt ngay cả khi không biết điều gì làm cho chúng tốt như vậy.
Code tạo ra giao diện. Nhưng bản thân code, cùng với IDE của nó, cũng là một giao diện. Giao diện người dùng mà chúng ta đang tìm hiểu nhắm tới một nhóm đối tượng rất nhỏ: teammate của chúng ta. Từ phần này trở đi, chúng ta sẽ thay thế “teammate” thành “user” và đề cập tới UI design.
Với thay đổi này, hãy xem xét một số user flow mẫu như sau:
User muốn thêm một tính năng mới. Để làm được điều này, họ phải tìm đúng vị trí và thêm tính năng mà không tạo ra thêm bug.
User muốn fix bug. Họ cần tìm thấy nguồn bug và sửa bug để nó dừng hoạt động mà không tạo ra những bug khác.
User muốn xác định một trường hợp cụ thể diễn ra theo cách nào. Họ muốn tìm code đúng rồi từ đó dò theo tính logic để mô phỏng những gì sẽ xảy ra.
Và còn nhiều flow khác nữa. Đa số các flow đều theo một mô hình tương tự nhau. Chúng ta sẽ xem qua các ví dụ cụ thể, nhưng lưu ý rằng, hãy nhớ các quy tắc chung thay vì danh sách các quy tắc như cũ.
__________________________
Chúng ta có thể giả định rằng user của chúng ta không thể đi thẳng tới dòng code đúng. Điều này đúng cho cả những hobby project; chúng ta rất dễ quên vị trí của feature dù cho chính chúng ta là người viết nó. Vì vậy, code nên dễ tìm kiếm.
Nếu chúng ta muốn nâng cao khả năng tìm kiếm thì chúng ta sẽ cần công cụ SEO. Và tên variable có nghĩa có tác dụng rất lớn ở đây. Nếu user không thể tìm thấy feature bằng cách chuyển lên callstack từ một điểm đã biết, họ có thể bắt đầu gõ keyword vào khung tìm kiếm. Khi user của chúng ta tìm code, họ chỉ cần một điểm nhập duy nhất và làm việc từ đó. Chúng ta cần đáp ứng nhu cầu của user tốt nhất có thể. Nếu có quá nhiều keyword, họ sẽ cảm thấy không hài lòng.
“Nếu user thấy rằng “mức logic này chính xác” ngay lập tức thì họ có thể quên tất cả các lớp trừu tượng trước đó và cảm thấy thoải mái và sẵn sàng hơn để thực hiện các lớp tiếp theo.”
User cũng có thể tìm kiếm thông qua autocompletion. Họ biết họ cần call function nào hay muốn sử dụng enum case nào, vì vậy họ sẽ bắt đầu nhập và chọn autocomplete phù hợp. Nếu một function chỉ được sử dụng trong các trường hợp cụ thể hoặc xuất hiện cảnh báo yêu cầu đọc cẩn thận, chúng ta có thể cần một tên dài hơn. Khi user đọc danh sách autocomplete, họ có xu hướng tránh những tùy chọn trông có vẻ phức tạp trừ khi họ biết họ đang làm gì.
Tương tự, những tên ngắn và chung chung thường được xem là tùy chọn mặc định và phù hợp với user bình thường. Hãy chắc rằng họ không làm bất cứ điều gì kì lạ. Chúng ta không nên đặt các setter vào những getter-trông-đơn-giản, cũng giống như một UI cho khách hàng không nên hiển thị nút “View” mà làm thay đổi data của họ.
Và user muốn tìm thông tin một cách nhanh chóng. Trong hầu hết các trường hợp, compile tốn khá nhiều thời gian và run có thể yêu cầu visit rất nhiều các trường hợp khác nhau một cách thủ công. Nếu có thể, user sẽ thích đọc hành vi code hơn là ném vào các breakpoint và chạy code.
Để bỏ qua việc chạy code, họ cần thỏa mãn hai điều kiện sau:
Họ hiểu code đang làm gì.
Họ biết chắc code đang làm những gì được đưa ra.
Sự trừu tượng giúp thỏa mãn điều kiện đầu tiên. User nên lột lớp trừu tượng cho đến khi đạt được mức độ chi tiết mong muốn. Hãy suy nghĩ theo các dòng của UI phân cấp. Chúng ta cho phép người dùng thực hiện các điều hướng rộng trước, sau đó là điều hướng chính xác hơn khi họ muốn đọc logic chi tiết hơn.
Đọc một file hoặc method tuần tự mất linear time. Ngay khi user click lên xuống thông qua các callstack, họ sẽ chuyển sang thực hiện tree search. Đưa ra một hệ thống phân cấp cân bằng chỉ làm mất logarithmic time. Trong UI luôn có một danh sách nhưng hãy xem xét một cách cẩn thận liệu một context đơn có cần chứa nhiều hơn một vài method call không.
Đối với điều kiện thứ hai, user khác nhau sẽ có chiến lược khác nhau. Trong các tình huống rủi ro thấp, chúng ta có thể chỉ cần các comment hoặc tên method. Đối với các tình huống rủi ro và phức tạp hơn, hoặc khi user thấy khó chịu bởi các comment cũ, họ có thể bỏ qua chúng luôn. Đôi khi, ngay cả tên method và variable cũng tạo ra sự khó hiểu. Khi điều này xảy ra, user phải đọc code nhiều hơn và xây dựng một mô hình logic lớn hơn. Để giải quyết điều này thì ta cần những context nhỏ và dễ hiểu. Nếu user thấy rằng “mức logic này chính xác” ngay lập tức thì họ có thể quên tất cả các lớp trừu tượng trước đó và cảm thấy thoải mái và sẵn sàng hơn để thực hiện các lớp tiếp theo.
Khi user ở mode này, các token riêng lẻ bắt đầu trở nên quan trọng hơn. Một bool flag element.visible = true / false rất dễ phân tích trong sự cô lập, nhưng nó đòi hỏi phải kết hợp
hai token khác nhau. Nếu thay vào đó, flag là element.visibility = .visible / .hidden, các context liên quan đến flag có thể được lướt qua, mà không cần phải đọc tên của variable để tìm hiểu về khả năng hiển thị. Chúng ta có thể thấy những sự cải tiến về design trong customer-facing UIs. Trong vài thập kỷ qua, các nút xác nhận đã phát triển từ OK / Cancel sang các option cụ thể hơn như Save / Discard hoặc Save / Keep editing. User có thể tìm xem những gì đang diễn ra bằng cách nhìn vào các option thay vì phải đọc toàn bộ context.
Các unit test cũng có thể giúp chúng ta vượt qua tình trạng proof-of-behavior. Chúng hành động như những comment đáng tin cậy hơn vì chúng ít bị tổn thương. Điều này vẫn liên quan đến việc build. Tuy nhiên, bất kỳ team nào có pipeline CI tốt cũng đã run test, vì vậy user có thể bỏ qua bước này cho code hiện có.
Về lý thuyết, sự an toàn đến từ sự hiểu biết. Khi user của chúng ta hiểu hành vi hiện tại của code, họ sẽ có thể chỉnh sửa nó một cách an toàn. Trong thực tế, các kỹ sư cũng là con người thôi. Bộ não của chúng ta cũng giống như bất kỳ ai khác. Chúng ta hiểu càng ít thì các hành động mà chúng ta thực hiện càng an toàn hơn.
Code dễ đọc sẽ giảm tải phần lớn việc kiểm tra lỗi cho máy. Các debug assert là một cách để làm điều này, mặc dù chúng đòi hỏi building và running. Tệ hơn là chúng có thể không bắt các trường hợp như user quên path đó. Các unit test có thể thực hiện các trường hợp lãng quên như vậy tốt hơn, nhưng một khi user đã thực hiện các thay đổi, họ cần có thời gian để run.
“Tóm lại, code dễ đọc cũng phải dùng được. Và nếu được thì nó cũng nên đẹp đẹp chút”
Để có turnaround time nhanh nhất, chúng ta sử dụng các compiler error. Chúng hiếm khi yêu cầu full build và thậm chí có thể xuất hiện trong real time. Vậy chúng ta có thể tận dụng lợi thế của chúng như thế nào? Nhìn rộng ra là chúng ta muốn tìm kiếm các tình huống khi compiler trở nên nghiêm ngặt hơn. Ví dụ như đa số các compiler không quan tâm nếu câu lệnh “if” có đầy đủ không nhưng sẽ kiểm tra câu lệnh “switch” cho bất kỳ case thiếu sót nào một cách cẩn thận. Nếu user cố gắng thêm hoặc chỉnh sửa một case, thì tất cả các điều kiện trước đó nên là các exhaustive switch để an toàn hơn. Vào thời điểm họ thay đổi các case, compiler sẽ gắn cờ tất cả các điều kiện cần được kiểm tra lại.
Một vấn đề liên quan tới tính dễ đọc của code là dùng những hàm đơn giản trong các lệnh điều kiện. Đặc biệt là khi một ứng dụng được viết theo ngôn ngữ JSON, sẽ rất dễ mắc phải lỗi viết quá nhiều câu điều kiện if xung quanh với các tham chiếu là toán tử dạng chuỗi string hoặc dạng số nguyên. Điều này không chỉ làm cho việc gõ code dễ sai, mà còn làm cho user không biết được giá trị nào khả thi. Có một sự khác biệt rất lớn giữa việc phải kiểm tra tính khả thi của từng string với việc chỉ cần kiểm tra 2 phần 3 của chúng. Kể cả khi các hàm đơn giản được chuyển thành constant, user cũng là người sẽ tự gán các giá trị khác một cách tùy ý. Nếu chúng ta sử dụng custom objects hoặc enums, compiler sẽ chặn những giá trị không thỏa và đưa ra một danh sách những giá trị thỏa điều kiện khác.
Tương tự như vậy, chúng ta nên tập trung chỉ dùng một enum hơn là nhiều boolean flags nếu một vài kết hợp của flags không thỏa điều kiện. Ví dụ, tưởng tượng như một bài nhạc đang chờ tải về hoặc đang chơi. Nếu chúng ta đại diện 2 bool flags là (loaded, playing), compiler sẽ cho phép những giá trị không thỏa (loaded: false, playing: true). Tuy nhiên, nếu dùng enum, .buffering/.loaded/.playing, các trạng thái không thỏa sẽ không xảy ra. “Vô hiệu hóa các kết hợp không thỏa trong phần cài đặt” nên là một tính năng cơ bản trong việc thiết kế customer-facing UI. Nhưng khi chúng ta đã viết những dòng code bên trong một app, chúng ta thường quên mất đặt mình vào trường hợp này.
Sau khóa học về user flow này, chúng ta đã đạt được những nguyên tắc đã đề cập lúc ban đầu. Nhưng giờ thì ta sẽ có một quy trình cho việc tạo ra và tùy chỉnh chúng. Chúng ta cần tự hỏi rằng: • Những dòng code này có thể dễ cho user tìm thấy không? Liệu nó có thể làm lộn xộn và hiện ra những kết quả tìm kiếm không liên quan? • Một khi tìm thấy dòng code, user có thể xác định được behavior hiện tại của dòng code không? • Liệu user có thể dựa vào xác minh máy tính để chỉnh sửa và sử dụng lại code này một cách an toàn?
Tóm lại, code dễ đọc cũng phải dùng được. Và nếu được thì nó cũng nên đẹp đẹp chút.
Công nghệ sẽ phát huy một cách tốt nhất nếu bạn biết cách tận dụng nó, và điều này cũng tương tự với Docker.
Những trường hợp về các command cụ thể kèm theo lời giải thích và các bản demo sẽ có trong bài viết này. Hãy cùng mọi người trong team tham khảo khi áp dụng Docker trong thực tế nhé!
docker build
docker build --rm -t docker-examples:latest .
Trường hợp sử dụng: Bạn không có docker-compose file mà chỉ có dockerfile. Nếu bạn muốn chạy service của mình, tuy nhiên bạn phải build nó trước đã.
Chi tiết: Build một file ảnh từ một dockerfile.
--rm: được sử dụng để xóa một container trung gian sau khi đã build thành công. Sau khi build mà không có option đó trong danh sách container của bạn, cái này sẽ xuất hiện:
-t : gắn thẻ hình ảnh được build. Nếu không cái này, chúng ta sẽ rất khó biết có gì chứa trong đó nếu chỉ nhìn lướt qua
Trường hợp sử dụng: Bạn không chỉ rõ một gói phiên bản phụ thuộc và muốn cập nhật lên phiên bản mới nhất, nhưng bạn không thay đổi dockerfile và Docker liên tục sử dụng các layer được lưu trong bộ nhớ cache.
Trường hợp sử dụng: Bạn đã build hình ảnh Docker và muốn chạy nó. Ứng dụng bên trong container sử dụng 3000 port, nhưng bạn muốn sử dụng 4000 port trên máy cục bộ của mình.
Chi tiết:
-d : chạy container trong background và trong ID container.
-p : xuất cổng container tới cổng máy cục bộ
host_port: docker_port.
Phím tắt với VS Code
docker run docker-examples:latest
Trường hợp sử dụng: Dùng để chạy docker và kiểm soát launch process trong terminal của mình. Ấn Ctrl + C để thoát khỏi container
docker run -t -i docker-examples:latest node
Trường hợp sử dụng: Dùng để chạy một command, tool hay một instance mới của container ( Ví dụ như nếu bạn muốn truy cập vào bảng điều khiển node.js và thực thi một cái gì đó). Xem thêm các docker exec cho các container đã khởi chạy.
docker stop
docker stop container_name
Trường hợp sử dụng: Dùng để dừng một launched containery.
Chi tiết: Bạn có thể tìm thấy tên container bằng cách sử dụng command “docker ps -a”
Phím tắt với VS Code
docker stop $(docker ps -a -q)
Ví dụ: Dừng tất cả các container
docker ps
docker ps -a
Trường hợp sử dụng: Bạn muốn tìm tên của container cần được dừng. Bạn cũng có thể sử dụng cái này để xem trạng thái và các cổng tiếp xúc của container.
Phím tắt với VS Code
docker logs
docker logs -f container_name
Trường hợp sử dụng: docker logs sẽ cho bạn biết lý do tại sao service của bạn bị sập khi đang chạy. Hoặc khi bạn muốn xem các log cho một service trên cơ sở liên tục.
Chi tiết: Theo dõi các log của container cụ thể; cái này cũng được dùng để chạy và dừng container.
-f bật theo sau log output
Phím tắt với VS Code
docker kill
docker kill $(docker ps -q)
Trường hợp sử dụng: Bạn muốn xem mọi thứ về Docker khi có vấn đề xảy ra
Chi tiết: Xóa tất cả các container đang chạy.
docker rm
docker rm $(docker ps -a -q)
Trường hợp sử dụng: Bạn muốn dọn dẹp một danh sách container lộn xộn
Chi tiết: Xóa tất cả các container đã dừng
docker system
docker system prune
Trường hợp sử dụng: Bạn muốn loại bỏ những thứ không sử dụng nữa.
Chi tiết: Loại bỏ tất cả các container, netwwork, hình ảnh, tùy chọn và volume không còn sử dụng nữa
Phím tắt với VS Code
docker rmi
docker rmi $(docker images -q)
Trường hợp sử dụng: Bạn cần thêm dung lượng trên đĩa
Chi tiết: Xóa tất cả hình ảnh
docker exec
docker exec -it container_name /bin/sh
Trường hợp sử dụng: Khi container báo lỗi connection timeout của “get” request trong quá trình execution của example.com. Lúc đấy, bạn có thể kết nối với container và chạy curl / ping.
Chi tiết: Chạy một command / tool cụ thể bên trong container và tự cho phép bạn sử dụng nó bên trong container. Việc này rất hữu ích cho việc debug và để biết cái gì xảy ra trong Docker container
docker-compose up
docker-compose up
Trường hợp sử dụng: Bạn có một docker-compose file với một số service, bạn muốn build rồi chạy tất cả để xem output như thế nào.
docker-compose up -d
Trường hợp sử dụng: Bạn muốn build và chạy tất cả các service nền và sau đó xem trạng thái của chúng.
Phím tắt với VS Code
docker-compose up -d example-service-1
Trường hợp sử dụng: Bạn muốn chạy một service cụ thể (tên như trong docker-compose file) để tất cả các port và volume được sử dụng trong docker compose file trong service đó
docker-compose down
docker-compose down
Trường hợp sử dụng: Bạn cần dừng tất cả các service được khai báo trong docker-compose file. Lệnh này dừng các container và loại bỏ từng network, volume và hình ảnh của container được tạo bởi ip. Và nó cũng rất hữu ích khi bạn muốn bắt đầu từ một sheet clean.
docker-compose run
docker-compose run example_app rails db:migrate
Trường hợp sử dụng: Bạn cần chạy một task cụ thể (ví dụ như di chuyển, kiểm tra) mà service của bạn cung cấp. Bạn có thể thực hiện tương tự như chạy docker, nhưng cũng có thể theo tên service từ docker-compose run. Hãy nhớ rằng khi bạn sử dụng các cổng “run”, các khai báo trong docker-compose sẽ không được xuất ra nếu không sử dụng –service-port.
docker-compose exec
docker-compose exec example_app node
Trường hợp sử dụng: Lệnh này tương tự với docker exec khi bạn muốn truy cập vào bên trong container đã khởi chạy và thực thi một cái gì đó. Điểm khác biệt giữa hai cái là bạn có thể truy cập bằng tên service. Lệnh này rất hữu ích cho việc gỡ lỗi, kiểm tra mạng và kiểm tra xem tất cả dữ liệu có tồn tại bên trong bộ chứa Docker không.
docker-compose logs
docker-compose logs -f container_name
Trường hợp sử dụng: Service của bạn bị sập khi đang khởi chạy và bạn muốn biết lý do tại sao.
Chi tiết: Xem các log của container cụ thể, kể cả những cái đang chạy và bị dừng lại. Thay vì sử dụng lệnh docker logs thì hãy sử dụng tên service thay cho tên container.
-f bật theo sau log output.
docker-compose stop
docker-compose stop example_app
Trường hợp sử dụng: Bạn muốn dừng container theo tên service hoặc tên container.
docker-compose restart
docker-compose restart example_app
Trường hợp sử dụng: Bạn muốn khởi động lại một container với tên service hoặc tên container.
Lập trình Python chịu trách nhiệm viết logic ứng dụng web phía máy chủ, phát triển các thành phần back-end, kết nối ứng dụng với các dịch vụ web của bên thứ ba khác và hỗ trợ các nhà phát triển front-end bằng cách tích hợp công việc của họ với ứng dụng Python. Hy vọng, Mẫu bảng công việc lập trình Python này sẽ giúp các bộ phận nhân sự dễ dàng hơn cho việc tuyển dụng những vị trí này.
Về lập trình viên Python: Để thành một Python Developer giỏi, các lập trình viên cần nắm rõ cấu trúc dữ liệu và giải thuật, kỹ thuật lập trình hướng đối tượng cũng như có kiến thức hoặc kinh nghiệm về framework liên quan như Flask, Django cũng như Restful Framework của từng Framework trên… để cùng tham gia nghiên cứu, thiết kế, phát triển và tích hợp các các giải pháp và hệ thống ứng dụng phục vụ công việc quản trị, vận hành và điều hành cho sản phẩm công ty/ khách hàng.
Hiện tại, Laravel là PHP Framework được sử dụng phổ biến nhất trên thế giới vì những ưu điểm vượt trội tận dụng các kỹ thuật Design Pattern, các công nghệ mới nhất của PHP và rất dễ dàng tiếp cận và sử dụng nó.
Điểm yếu của Laravel là không hỗ trợ các phiên bản PHP cũ vì thế các website có nền tảng PHP version thấp hơn khá là khó khi có ý định chuyển sang Laravel và phải luôn cập nhật các thông tin mới nhất về PHP để áp dụng vào Laravel.
Dựa trên nền tảng Laravel PHP Framework có rất nhiều công ty, tổ chức đã tạo ra các CMS Open source để giúp developer hoặc người dùng dễ dàng thao tác và xây dựng ra một trang web nhanh hơn build từ chính core của framework.
Tính đến thời điểm hiện tại là một CMS dựa trên Laravel phổ biến nhất. Và nó xứng đáng với sự phổ biến vì là một trong những product hoàn chỉnh: tài liệu đầy đủ, dễ sử dụng, nhiều plugin, themes, và được chia sẻ bởi một cồng đồng rộng lớn bạn chỉ cần lấy về và sử dụng nó.
Với open source CMS khi bạn download toàn bộ source code về bạn chỉ cần cài đặt theo hướng dẫn là bạn đã có một trang web tương đối hoàn chỉnh.
Nhưng trong quá trình cài đặt thì luôn luôn có các options cho mình chọn: blank, theme hoặc ready-made
Tôi đã chọn một theme và nó là một trong những theme mặc định. Có rất nhiều theme cho mình lựa chọn.
Và sau đó cài đặt sẽ tiếp tục, download các files từ internet.
Dưới đây là kết quả của quá trình cài đặt, trang chủ sẽ như hình bên dưới:
Bây giờ, trang admin sẽ khá đẹp. Theme bao gồm tất cả các cấu trúc của các pages là gồm Twig templates, bạn có thể chỉnh sửa từ back-end.
Và tất nhiên, bạn có thể chỉnh sửa code từ back-end một cách trực quan tùy theo cách bạn bố trí layout… Nó là một CMS cho các developers.
Bạn có thể xem trước click button Preview và click vào Save bạn sẽ có một trang, một layout như ý bạn. Thật tuyệt vời phải không?
Ngoài ra, có một vài thiết lập hữu ích, đặc biệt như cấu hình nội dung mail – bạn không chỉ chọn trình điều khiển mail từ back-end (PHP Mail, Mailgun, Mandrill …) mà còn có các mẫu email đã được soạn sẵn để chỉnh sửa.
Vậy tôi có thể nói những cái hay về “marketing” trong cấu trúc nền tảng của October CMS, đó là điều quan trọng trong core của CMS.
Tài liệu của October CMS được viết rất tốt.
Chúng có sẵn hàng trăm plugins, bao gồm cả miễn phí và bản phải trả phí, deverlopers có thể kiếm tiền bằng cách viết các plugin or các themes.
Khoảng hơn 50 themes chia sẻ sẵn để ta dùng, điều này hoàn toàn phụ thuộc vào sự chia sẻ của các nhà phát triển.
Và một ấn tượng tốt đẹp khác về October CMS là bạn có thể nâng cấp bản hiện tại cho hệ thống đặc biệt nào đó khi mình cần.
Và cuối cùng, tên CMS này được đặt theo thời gian của dự án bắt bầu từ tháng Mười năm 2013. Bạn có thể xem những commit gần nhất trên Github của CMS này tại đây
Vậy nếu dự án bạn đơn thuần như kiểu cms thì bạn hãy chọn October CMS hoặc bạn có thể có vài lựa chọn khác nữa.
Là một dự án tương đối mới, bắt đầu vào năm 2015, nhưng nó thật sự mạnh. Nhưng CMS này nhắm đến các nhà phát triển nhiều hơn, nên khi cài đặt thì thực hiện bằng dòng lệnh.
Enter your database details in .env file on root folder.
Run php artisan migrate –seed to setup your database.
Và sau khi cài đặt xong tôi có thể nói Lavalite vừa đơn giản vừa dễ sử dụng. Trang Admin sẽ nhìn như sau:diện trang chủ rất đơn giản, nhưng bạn có thể tùy chỉnh nếu bạn muốn: bây giờ chúng ta chuyển sang những sản phẩm chưa thực sự hoàn chỉnh hoặc gặp khó khăn khi sử dụng, nhưng vẫn review chúng.
Kết luận
Có rất nhiều CMS dựa trên Laravel, nhưng October CMS mạnh hơn cả. Cá nhân tôi không phải là fan của giải pháp này (bạn phải maintain CMS và liên tục update framework và cms), nhưng nếu bạn cần loại kiến trúc này – chỉ cần chọn trong cms trên.
Lưu ý: Tôi cũng đã tìm thấy một số CMS khác hoặc chỉ mới bắt đầu mà tôi không đề cập ở đây.
Tham khảo tại Review: Top 5 Laravel-based CMSs
Xem thêm các vị trí tuyển dụng lập trình nhiều ngành nghề HOT tại Topdev
Unit Test là một loại kiểm thử phần mềm trong đó các đơn vị hay thành phần riêng lẻ của phần mềm được kiểm thử. Kiểm thử đơn vị được thực hiện trong quá trình phát triển ứng dụng. Mục tiêu của Kiểm thử đơn vị là cô lập một phần code và xác minh tính chính xác của đơn vị đó.
Unit là gì?
Một Unit là một thành phần PM nhỏ nhất mà ta có thể kiểm tra được như các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc các phương thức (Method).
Vì Unit được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt động đơn giản, chúng ta không khó khăn gì trong việc tổ chức, kiểm tra, ghi nhận và phân tích kết quả kiểm tra nên việc phát hiện lỗi sẽ dễ dàng xác định nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một Unit đang kiểm tra.
Mỗi UT sẽ gửi đi một thông điệp và kiểm tra câu trả lời nhận được đúng hay không, bao gồm:
Các kết quả trả về mong muốn
Các lỗi ngoại lệ mong muốn
Các đoạn mã UT hoạt động liên tục hoặc định kỳ để thăm dò và phát hiện các lỗi kỹ thuật trong suốt quá trình phát triển, do đó UT còn được gọi là kỹ thuật kiểm nghiệm tự động. UT có các đặc điểm sau:
Đóng vai trò như những người sử dụng đầu tiên của hệ thống.
Chỉ có giá trị khi chúng có thể phát hiện các vấn đề tiềm ẩn hoặc lỗi kỹ thuật.
Khi làm Unit test chúng ta thường thấy các khái niệm sau:
Assertion: Là một phát biểu mô tả các công việc kiểm tra cần tiến hành, thí dụ: AreEqual(), IsTrue(), IsNotNull()… Mỗi một UT gồm nhiều assertion kiểm tra dữ liệu đầu ra, tính chính xác của các lỗi ngoại lệ ra và các vấn đề phức tạp khác như: – Sự tồn tại của một đối tượng – Điều kiện biên: Các giá trị có vượt ra ngoài giới hạn hay không – Thứ tự thực hiện của các luồng dữ liệu …
Test Point: Là một đơn vị kiểm tra nhỏ nhất, chỉ chứa đơn giản một assertion nhằm khẳng định tính đúng đắn của một chi tiết mã nào đó. Mọi thành viên dự án đều có thể viết một test point. Test Case: Là một tập hợp các test point nhằm kiểm tra một đặc điểm chức năng cụ thể, thí dụ toàn bộ giai đoạn người dùng nhập dữ liệu cho đến khi thông tin được nhập vào cơ sở dữ liệu. Trong nhiều trường hợp kiểm tra đặc biệt và khẩn cấp có thể không cần đến test case.
Test Suite: Là một tập hợp các test case định nghĩa cho từng module hoặc hệ thống con.
Regression Testing (hoặc Automated Testing): Là phương pháp kiểm nghiệm tự động sử dụng một phần mềm đặc biệt. Cùng một loại dữ liệu kiểm tra giống nhau nhưng được tiến hành nhiều lần lặp lại tự động nhằm ngăn chặn các lỗi cũ phát sinh trở lại. Kết hợp Regression Testing với Unit Testing sẽ đảm bảo các đoạn mã mới vẫn đáp ứng yêu cầu thay đổi và các đoạn mã cũ sẽ không bị ảnh hưởng bởi các hoạt động bảo trì.
Production Code: Phần mã chính của ứng dụng được chuyển giao cho khách hàng.
Unit Testing Code: Phần mã phụ để kiểm tra mã ứng dụng chính, không được chuyển giao cho khách hàng.
2.Vòng đời Unit Test
UT có 3 trạng thái cơ bản:
Fail (trạng thái lỗi)
Ignore (tạm ngừng thực hiện)
Pass (trạng thái làm việc)
Toàn bộ UT được vận hành trong một hệ thống tách biệt. Có rất nhiều PM hỗ trợ thực thi UT với giao diện trực quan. Thông thường, trạng thái của UT được biểu hiện bằng các màu khác nhau: màu xanh (pass), màu vàng (ignore) và màu đỏ (fail)
UT chỉ thực sự đem lại hiệu quả khi:
Được vận hành lặp lại nhiều lần
Tự động hoàn toàn
Độc lập với các UT khác.
3. Thiết kế Unit test
Mỗi UT đều được tiết kế theo trình tự sau:
Thiết lập các điều kiện cần thiết: khởi tạo các đối tượng, xác định tài nguyên cần thiết, xây dựng các dữ liệu giả…
Triệu gọi các phương thức cần kiểm tra.
Kiểm tra sự hoạt động đúng đắn của các phương thức.
Dọn dẹp tài nguyên sau khi kết thúc kiểm tra.
4. Ứng dụng Unit test
Kiểm tra mọi đơn vị nhỏ nhất là các thuộc tính, sự kiện, thủ tục và hàm.
Kiểm tra các trạng thái và ràng buộc của đối tượng ở các mức sâu hơn mà thông thường chúng ta không thể truy cập được.
Kiểm tra các quy trình (process) và mở rộng hơn là các khung làm việc(workflow – tập hợp của nhiều quy trình)
5. Lợi ích của việc áp dụng Unit test
Thời gian đầu, người ta thường do dự khi phải viết UT thay vì tập trung vào code cho các chức năng nghiệp vụ. Công việc viết Unit Test có thể mất nhiều thời gian hơn code rất nhiều nhưng lại có lợi ích sau:
Tạo ra môi trường lý tưởng để kiểm tra bất kỳ đoạn code nào, có khả năng thăm dò và phát hiện lỗi chính xác, duy trì sự ổn định của toàn bộ PM và giúp tiết kiệm thời gian so với công việc gỡ rối truyền thống.
Phát hiện các thuật toán thực thi không hiệu quả, các thủ tục chạy vượt quá giới hạn thời gian.
Phát hiện các vấn đề về thiết kế, xử lý hệ thống, thậm chí các mô hình thiết kế.
Phát hiện các lỗi nghiêm trọng có thể xảy ra trong những tình huống rất hẹp.
Tạo hàng rào an toàn cho các khối mã: Bất kỳ sự thay đổi nào cũng có thể tác động đến hàng rào này và thông báo những nguy hiểm tiềm tàng.
Trong môi trường làm việc Unit Test còn có tác dụng rất lớn đến năng suất làm việc:
Giải phóng chuyên viên QA khỏi các công việc kiểm tra phức tạp.
Tăng sự tự tin khi hoàn thành một công việc. Chúng ta thường có cảm giác không chắc chắn về các đoạn mã của mình như liệu các lỗi có quay lại không, hoạt động của module hiện hành có bị tác động không, hoặc liệu công việc hiệu chỉnh mã có gây hư hỏng đâu đó…
Là công cụ đánh giá năng lực của bạn. Số lượng các tình huống kiểm tra (test case) chuyển trạng thái “pass” sẽ thể hiện tốc độ làm việc, năng suất của bạn.
6. Cách code hiệu quả với Unit Test
Phân tích các tình huống có thể xảy ra đối với mã. Đừng bỏ qua các tình huống tồi tệ nhất có thể xảy ra, thí dụ dữ liệu nhập làm một kết nối cơ sở dữ liệu thất bại, ứng dụng bị treo vì một phép toán chia cho không, các thủ tục đưa ra lỗi ngoại lệ sai có thể phá hỏng ứng dụng một cách bí ẩn…
Mọi UT phải bắt đầu với trạng thái “fail” và chuyển trạng thái “pass” sau một số thay đổi hợp lý đối với mã chính.
Mỗi khi viết một đoạn mã quan trọng, hãy viết các UT tương ứng cho đến khi bạn không thể nghĩ thêm tình huống nào nữa.
Nhập một số lượng đủ lớn các giá trị đầu vào để phát hiện điểm yếu của mã theo nguyên tắc:
Nếu nhập giá trị đầu vào hợp lệ thì kết quả trả về cũng phải hợp lệ
Nếu nhập giá trị đầu vào không hợp lệ thì kết quả trả về phải không hợp lệ
Sớm nhận biết các đoạn mã không ổn định và có nguy cơ gây lỗi cao, viết UT tương ứng để khống chế.
Ứng với mỗi đối tượng nghiệp vụ (business object) hoặc đối tượng truy cập dữ liệu (data access object), nên tạo ra một lớp kiểm tra riêng vì những lỗi nghiêm trọng có thể phát sinh từ các đối tượng này.
Để ngăn chặn các lỗi có thể phát sinh trở lại thực thi tự động tất cả UT mỗi khi có một sự thay đổi quan trọng, hãy làm công việc này mỗi ngày. Các UT lỗi cho chúng ta biết thay đổi nào là nguyên nhân gây lỗi.
Để tăng hiệu quả và giảm rủi ro khi viết các UT, cần sử dụng nhiều phương thức kiểm tra khác nhau. Hãy viết càng đơn giản càng tốt.
Cuối cùng, viết UT cũng đòi hỏi sự nỗ lực, kinh nghiệm và sự sáng tạo như viết PM.
Trước khi kết thúc phần này, tôi có một lời khuyên là viết UT cũng tương tự như viết mã một chương trình, điều bạn cần làm là không ngừng thực hành. Hãy nhớ UT chỉ thực sự mang lại lợi ích nếu chúng ta đặt vấn đề chất lượng phần mềm lên hàng đầu hơn là chỉ nhằm kết thúc công việc đúng thời hạn. Khi đã thành thạo với công việc viết UT, bạn có thể đọc thêm về các kỹ thuật xây dựng UT phức tạp hơn, trong số đó có mô hình đối tượng ảo sẽ được trình bày trong phần tiếp theo.
Trong mùa tuyển sinh năm 2019 có khá nhiều bất ngờ khi ngành công nghệ thông tin (CNTT) đã “soán ngôi” đầu khi vượt xa điểm chuẩn các ngành y, dược, mặc dù điểm chuẩn của các ngành đã tăng mạnh trong năm nay.
Điểm chuẩn cao nhất cả nước thuộc về ngành CNTT – Khoa học máy tính của ĐH Bách khoa Hà Nội với 27,42 điểm. Như vậy, điểm chuẩn ngành này vượt ngành Y đa khoa (điểm chuẩn là 26,75) của Đại học Y Hà Nội; ngành Y khoa của ĐH Y dược Thái Bình (24,60 điểm); ngành Y khoa của ĐH Y dược Hải Phòng (23,20 điểm). Riêng tại ĐH Quốc gia Hà Nội, nhóm ngành CNTT của ĐH Công nghệ lấy điểm cao nhất 25,85 điểm cho khối A00 và A01. Đây được coi là mức điểm cao nhất trong các khoa, trường thành viên của ĐH Quốc gia Hà Nội. Nhiều chuyên gia cho rằng, xu hướng số hóa doanh nghiệp “làm mưa làm gió” trong những năm qua, nên số thí sinh lựa chọn ngành CNTT nhiều kéo theo điểm chuẩn tăng cao là điều không nằm ngoài dự đoán. Không chỉ có các trường đại học, hiện nay chính phủ cũng có nhiều động thái đẩy mạnh hơn trong quá trình chuyển đổi số.
Điểm chuẩn trường Đại học Bách Khoa TP.HCM, đứng đầu là ngành Khoa học Máy tính với điểm chuẩn 25.75
Điểm chuẩn trường Đại học Tự nhiên TP.HCM, số điểm cao nhất thuộc về nhóm ngành Máy tính và Công nghệ Thông tin – 25.00
Trong một phát ngôn chính thức của mình, Bộ trưởng Bộ Thông tin và Truyền thông Nguyễn Mạnh Hùng cho biết Việt Nam cần phát triển thêm 50.000 doanh nghiệp công nghệ thông tin (ICT) để đẩy nhanh chuyển đối số Việt Nam. Việt Nam sẽ tuyên bố chiến lược về chuyển đổi số quốc gia, để tiến tới một nền kinh tế số, xã hội số. Các yếu tố nền tảng sẽ được nhấn mạnh, sẽ được đầu tư trước, sẽ đi trước, sẽ phải có thứ hạng cao trên thế giới, phải nằm trong top 50 vào năm 2025 và top 30 vào năm 2030.Cũng chính vì vậy, nhu cầu tăng cao, nguồn cung và đầu ra của đào chưa đủ nên ngành CNTT ngày càng khó khăn trong việc tìm kiếm nhân lực dù mức lương đã rất cao và cạnh tranh.
“Khát” nguồn nhân lực IT
Dù các trường có sức đào tạo mạnh, mức lương thị trường cạnh tranh, doanh nghiệp trải thảm đỏ nhưng việc tuyển dụng nhân sự CNTT vẫn còn gặp nhiều khó khăn. Cụ thể, 30,802,600 đồng/tháng là mức lương trung bình mà đa phần các nhà tuyển dụng sẵn sàng trả cho một lập trình viên có kinh nghiệm, và tỷ lệ tăng lương 6 tháng đầu năm 2019 đạt 15 -18%. Với mức lương trung bình là 27.610.500 đồng/tháng, C++ đang dẫn đầu trong top 5 ngôn ngữ được trả lương cao nhất, theo sau đó là Python và Java.
Mức lương trung bình theo ngôn ngữ lập trình và vị trí mà các lập trình viên nhận được
Trong đó, vì sự khan hiếm của thị trường nhân lực, các kỹ sư AI/ML hứa hẹn sẽ đạt mức lương khá cao, trung bình là 34.880.100 đồng/tháng. Trong khi đó, đối với các cấp quản lý, con số này không thấp hơn 35.000.000 đồng/tháng với kinh nghiệm trên 5 năm. Tuy nhiên, việc tuyển dụng những vị trí này gặp rất nhiều khó khăn do những đặc thù và yêu cầu gắt gao. Đây cũng là lý do khiến cho thị trường nhân lực IT càng hạn hẹp.
Dù lương và phúc lợi là chìa khoá quyết định giữ chân nhân tài, bức tranh IT toàn cảnh lộ rõ những khiếm khuyết về nhân lực, không chỉ riêng Việt Nam mà còn ở những khu vực lân cận. Đỉnh điểm là bài toán thiếu nhân lực ngành AI – Trí tuệ Nhân tạo tại các công ty Nhật lên đến hơn 100 triệu /tháng nhưng vẫn chưa chắc kiếm được người. Năm 2019 đánh dấu mức tăng kỷ lục trong nhu cầu tuyển dụng đến 56%. Ước tính đến năm 2021, riêng lao động trong ngành lập trình sẽ cần khoảng 400.000 nhân lực trong khi khả năng hiện tại chỉ có khoảng 200.000 lao động đáp ứng được nhu cầu công việc.
Nhu cầu tuyển dụng ngành IT năm 2019 tăng mạnh hơn bao giờ hết
Để lý giải cho việc này, Ông Nguyễn Hữu Bình, CEO TopDev cho biết “Giới công nghệ Việt Nam đang đứng trước hai làn sóng, làn sóng thứ nhất là làn sóng các quỹ đầu tư nước ngoài chú ý và tìm đến Việt Nam ngày càng nhiều hơn, sẽ có thêm nhiều startup mới ra đời để giải quyết rất nhiều vấn đề còn tồn đọng của xã hội bằng công nghệ, làn sóng thứ hai là xu hướng chuyển đổi số (digital transformation – DX) của các doanh nghiệp thuộc các ngành nghề truyền thống ứng dụng công nghệ để nâng cao cạnh tranh khiến cho ngày càng nhiều công ty có nhu cầu tuyển dụng nhân sự CNTT, vì vậy cũng dẫn đến việc gia tăng mạnh nhu cầu tuyển dụng lượng nhân sự này.”
Ông Nguyễn Hữu Bình còn cho biết thêm “Làn sóng khởi nghiệp công nghệ (tech startup), cũng như việc gia tăng thêm các dự án từ các tập đoàn lớn đã có mặt trên thị trường, cũng góp phần không nhỏ trong xu hướng gia tăng nhu cầu nhân sự CNTT như hiện nay, thị trường khan hiếm và bản thân các nhà lập trình viên đều hiểu rõ giá trị của họ nên giữ chân nhân sự thực sự làm đau đầu nhiều doanh nghiệp”.