Gitignore là gì? Đã là Dev thì chúng ta đều biết đến Git để quản lý source code. Và sẽ vài lần Khi làm việc trong 1 team, bạn có bao giờ gặp tình trạng pull request của các member cứ conflict lên xuống vì mấy file biên dịch hay log chưa… Và thế là Gitignore đã ra đời để giải quyết vấn đề đó.
Gitignore là file có tên là .gitignore do Git quy định. Nhiệm vụ của nó là liệt kê những file mà mình không mong muốn cho vào git hoặc hiểu nôm na là Git sẽ bỏ qua những file đó đi. Gitignore hiện nay rất quan trọng trong team work, các bạn nên áp dụng ngay vào quy trình làm việc của team.
Cách thức hoạt động của Gitignore là gì?
Có thể hiểu đơn giản là git sẽ bỏ qua file hoặc một tập các file trong project của chúng ta khi commit và push lên repository. Ví dụ:
Các file mà IDE tự sinh ra trong quá trình build project -> Tránh tốn kém tài nguyên server lưu trữ project.
Các file cấu hình đường dẫn của máy cá nhân -> Gây ra việc không build được project khi checkout về ở các máy thành viên khác.
Các file cần phải giữ kín nếu như repository của bạn đang để public.
…
Git quản lý các file mà chúng ta muốn “ignore” bằng file .gitignore được đặt ở trong thư mục root project.
Khi add 1 file mới vào git, git sẽ kiểm tra danh sách những file sẽ bỏ qua trong file .gitignore và không add chúng vào git. Đó mới chỉ là điều kiện cần, điều kiện đủ là files không có trong git cache nữa thì git nó mới bỏ qua, chứ files mà nằm trong git cache thì .gitignore sẽ vô tác dụng.
Các pattern format hay dùng
Sử dụng # để comment và có thể để cách dòng cho dễ đọc.
Đơn giản nhất là tên file cần ignore: example.exe
Hay cả thư mục: example_folder/
Khi ignore thư mục nên có dấu / ở sau tên thư mục để nhận biết đó là thư mục, nếu không nó có thể là coi là thư mục hoặc file hay symbolic link.
Dấu ! phía trước có ý nghĩa phủ định: !abc/example.exe
Sử dụng 1 * để tìm các file có cùng định dạng. Ví dụ như bạn muốn ignore tất cả các file .xml trong project: *.xml
Trường hợp khác của 1 * nếu bạn chỉ rõ đường dẫn ví dụ: config/*.xml thì nó chỉ có hiệu lực cho các file config/abc.xml mà không có hiệu lực cho các file config/sub/abc.xml.
Sử dụng ** để có hiệu lực cho các thư mục không cần định rõ tên. Ví dụ: **/foo nó sẽ có hiệu lực cho tất cả file hoặc thư mục có tên là foo ở mọi nơi trong project.
Hay sử dụng kiểu folder/** để có hiệu lực cho tất cả các file bên trong thư mục.
Hầu hết các IDE đều hỗ trợ, nếu chưa có bạn có thể cài đặt thêm plugin hay config ở đâu đó. Mình có thể chọn loại dự án mình đang làm và nó sẽ sinh tự động file .gitignore tương ứng.
Hoặc đơn giản bạn vào gitignore.io sau đó chọn loại project mình đang làm.
Sau đó nó sẽ tạo ra 1 file .gitignore ngon lành cho bạn. Ví dụ như 1 project Node.js nó sẽ kiểu như thế này:
### Node template
# Logs
logs
*.log
npm-debug.log*
# Runtime data
pids
*.pid
*.seed
# Directory for instrumented libs generated by jscoverage/JSCover
lib-cov
# Coverage directory used by tools like istanbul
coverage
# nyc test coverage
.nyc_output
# Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files)
.grunt
# node-waf configuration
.lock-wscript
# Compiled binary addons (http://nodejs.org/api/addons.html)
build/Release
# Dependency directories
node_modules
jspm_packages
# Optional npm cache directory
.npm
# Optional REPL history
.node_repl_history
Ví dụ về .gitignore
Phạm vi phủ sóng
File .gitignore sẽ ảnh hưởng đến các file và thư mục anh em với nó hoặc là con cháu, chắt của nó. Thường thì project chỉ cần 1 file .gitignore ở ngoài cùng là đủ nhưng nếu project quá lớn ta có thể tách file .gitignore vào từng folder nhỏ để dễ quản lý.
Khi nào lên dùng Gitignore?
Bất cứ project nào cũng nên dùng nó, bạn nên tạo ngay file .gitignore trong thư mục gốc ngay khi khởi tạo project của bạn và liệt kê luôn những file mà bạn muốn git bỏ qua. Tại sao phải liệt kê trước làm gì thế? Đọc phần dưới sẽ rõ ?
Chú ý – Git cache
Giả dụ thế này! Bạn vừa join vào project và thấy project liên tục bị conflict vì mấy file rác. Nhưng may quá bạn đọc được bài viết này và bạn rất thông minh nên đã tạo luôn file .gitignore cho project và thêm luôn file rác đó vào .gitignore rồi bạn xóa file rác đi và commit lên.
Rồi sao! 1 ông khác lại pull code mới về lại tạo ra file rác đó và nó vẫn dính vào git bình thường. Đờ heo? “Em cho nó vào .gitignore rồi cơ mà?.
Vì sao à? Vì file đó đã được thằng git cache thu nạp thành của nó rồi nên thằng git nó vẫn có quyền quản lý file đó. Vậy cách giải quyết đơn giản nó phải giải thoát file đó ra khỏi git cache là xong, bằng 1 dòng lệnh:
git rm -r --cached /path/to/file_or_folder
Từ bây giờ file đó không còn là của git cache nữa nên nó không thuộc quyền quản lý của git nữa và bây giờ .gitignore mới có tác dụng. Theo lý thuyết là vậy nhưng nếu bạn cần reset lại hết project để .gitignore hoạt động đúng thì mình thường xóa bỏ hết file của git cache luôn?
git rm -r --cached .
Sau đó mình sẽ add tất cả các file lại vào project như lúc mới tạo project.
git add
Và bây giờ bạn lại commit và push như bình thường.
SQL đã quá quen thuộc trong việc quản lý và thao tác cơ sở dữ liệu. Trong SQL, có nhiều công cụ mạnh mẽ để giúp quản lý dữ liệu hiệu quả, và một trong số đó là trigger. Trigger là một khái niệm quan trọng trong SQL, cho phép bạn tự động hóa các quy trình và kiểm soát chặt chẽ hơn các thay đổi xảy ra trong cơ sở dữ liệu của mình. Cùng làm rõ trigger SQL là gì và cú pháp sử dụng Trigger trong SQL.
Trigger trong SQL là gì?
Trigger là một đoạn mã SQL được thiết lập để tự động chạy khi một sự kiện cụ thể xảy ra trong một bảng hoặc view trong cơ sở dữ liệu. Sự kiện này có thể là một hành động như INSERT, UPDATE, hoặc DELETE. Khi hành động đó xảy ra, trigger sẽ tự động được kích hoạt để thực hiện một chuỗi các hành động đã được định sẵn.
Trigger là một loại stored procedure đặc biệt (không có tham số) được thực thi (execute) một cách tự động khi có một sự kiện thay đổi dữ liệu (data modification). Trigger được lưu trữ và quản lý trong Server DB, được dùng trong trường hợp ta muốn kiểm tra các ràng buộc toàn vẹn trong DB.
Trigger được sử dụng khi nào?
Trigger thường được sử dụng để kiểm tra ràng buộc (check constraints) trên nhiều quan hệ (nhiều bảng/table) hoặc trên nhiều dòng (nhiều record) của bảng.
Ngoài ra việc sử dụng Trigger để chương trình có những hàm chạy ngầm nhằm phục vụ nhưng trường hợp hữu hạn và thường không sử dụng cho mục đích kinh doanh hoặc giao dịch.
Ngăn chặn việc xóa những dữ liệu quan trọng. (có thể dùng back up các dữ liệu quan trọng sang table khác phòng khi …bị xóa ngoài ý muốn).
Mỗi table thường sẽ có 3 thao tác làm thay đổi dữ liệu đó là: UPDATE, INSERT, DELETE. Và đôi khi mỗi hành động như vậy ta sẽ có những ràng buộc trên bảng để giúp bảo toàn dữ liệu, lúc này sử dụng trigger là một giải pháp tốt.
Ví dụ bạn thiết kế cho bảng product và category, trong đó product sẽ có một column tên là total_product dùng để lưu trữ tổng số sản phẩm của category đó. Khi thêm một product thì ta phải tăng column đó lên một đơn vị. Khi update phải kiểm tra có thay đổi category không để tăng hoặc giảm cho hợp lý, khi delete thì bớt đi một. Việc này hoàn toàn có thể code bằng các ngôn ngữ đang sử dụng SQL Server, tuy nhiên bạn có thể sử dụng trigger để giúp hệ thống dữ liệu hoạt động tốt hơn.
Ưu và nhược điểm của Trigger
Ưu Điểm Của Trigger
Trigger tự động kích hoạt khi một sự kiện nhất định xảy ra (chẳng hạn như INSERT, UPDATE, DELETE), giúp tự động hóa các quy trình mà không cần can thiệp thủ công. Điều này giúp giảm thiểu lỗi do con người gây ra và đảm bảo tính nhất quán trong các thao tác.
Bảo Đảm Tính Toàn Vẹn Dữ Liệu: Trigger có thể được thiết lập để kiểm tra và đảm bảo rằng các ràng buộc và quy tắc kinh doanh được tuân thủ trước khi bất kỳ thay đổi nào được áp dụng vào cơ sở dữ liệu. Bên cạnh đó trigger cho phép hệ thống phản ứng ngay lập tức với các thay đổi trong dữ liệu, chẳng hạn như tự động cập nhật các bảng khác hoặc ghi lại nhật ký thay đổi.
Ghi Nhật Ký và Theo Dõi Thay Đổi: Trigger có thể được sử dụng để tự động ghi lại các thay đổi trong cơ sở dữ liệu vào một bảng nhật ký. Điều này rất hữu ích trong việc theo dõi các hoạt động, audit, và bảo mật.
Tính Linh Hoạt: Trigger có thể được sử dụng cho nhiều mục đích khác nhau, từ việc đảm bảo dữ liệu không bị lỗi, tự động cập nhật số liệu, đến việc quản lý các tác vụ phức tạp như đồng bộ dữ liệu giữa các bảng.
Nhược Điểm Của Trigger
Trigger được thực thi tự động và có thể bị kích hoạt bởi nhiều sự kiện khác nhau, do đó việc xác định nguyên nhân gốc rễ của lỗi trong cơ sở dữ liệu có thể trở nên phức tạp.
Sử dụng quá nhiều trigger hoặc các trigger phức tạp có thể khiến việc bảo trì cơ sở dữ liệu trở nên khó khăn, đặc biệt khi các trigger ảnh hưởng lẫn nhau.
Tăng Overhead Hệ Thống: Trigger được kích hoạt tự động bởi các sự kiện, và nếu trigger chứa các câu lệnh phức tạp hoặc xử lý nhiều dữ liệu, điều này có thể dẫn đến việc làm chậm hiệu suất của cơ sở dữ liệu.
Khả Năng Gây Deadlock: Nếu không được thiết kế cẩn thận, trigger có thể dẫn đến tình trạng deadlock (khi hai hoặc nhiều hành động đợi nhau để hoàn thành), gây tắc nghẽn và làm gián đoạn hoạt động của hệ thống.
Các trigger có thể xung đột với nhau hoặc với các ràng buộc khác trong cơ sở dữ liệu, dẫn đến những kết quả không mong muốn.
Cú pháp của Trigger SQL
Để tạo một Trigger, bạn sử dụng câu lệnh CREATE TRIGGER:
CREATE TRIGGER trigger_name trigger_time trigger_event
ON table_name
FOR EACH ROW
BEGIN
...
END;
Trong đó:
Một Trigger được khởi tạo sau câu lệnh CREATE TRIGGER. Quy tắc đặt tên nên tuân theo nguyên tắc: [trigger time]_[table name]_[trigger event], ví dụ before_employees_update.
Thời gian kích hoạt : BEFORE hoặc AFTER. Cần phải chỉ định thời gian kích hoạc khi bạn xác định được tiến trình kích hoạt của nó. Sử dụng từ khóa BEFORE nếu bạn muốn xử lý hành động trước khi thực hiện thay đổi trên bản và AFTER nếu bạn cần phải xử lý hành động sau khi thay đổi được thực hiện xong.
Sự kiện gây ra có thể là INSERT, UPDATE, DELETE.
Trình kích hoạt phải được liên kết với một bảng cụ thể, sử dụng từ khóa ON để xác định.
Câu lệnh SQL phải được đặt giữa từ khóa BEGIN và END.
Các Loại Trigger Trong SQL
Trigger có thể được phân loại dựa trên thời điểm và sự kiện kích hoạt:
BEFORE Trigger: Được thực thi trước khi hành động chính được thực hiện. Ví dụ, một trigger BEFORE INSERT sẽ chạy trước khi một dòng mới được chèn vào bảng.
AFTER Trigger: Được thực thi sau khi hành động chính đã hoàn tất. Ví dụ, một trigger AFTER DELETE sẽ chạy sau khi một dòng đã bị xóa khỏi bảng.
INSTEAD OF Trigger: Được sử dụng trong các view để thay thế hành động thực hiện trên view đó. Đây là loại trigger ít phổ biến hơn nhưng rất hữu ích trong các trường hợp cụ thể.
Ví dụ:
Cung cấp Cơ sở dữ liệu Báo cáo Học sinh, trong đó đánh giá điểm của học sinh được ghi lại. Trong lược đồ như vậy, hãy tạo một Trigger để tính tổng số và trung bình của các bảng đã chỉ định được tự động chèn bất cứ khi nào một bản ghi được chèn.
Ở đây, vì trigger sẽ gọi trước khi bản ghi được chèn, nên có thể sử dụng thẻ BEFORE.
createtrigger stud_marks
before INSERTon
Student
for each rowset Student.total = Student.subj1 + Student.subj2 + Student.subj3, Student.per = Student.total *60/100;
Câu lệnh SQL trên sẽ tạo một trigger trong cơ sở dữ liệu sinh viên, trong đó bất cứ khi nào điểm môn học được nhập, trước khi chèn dữ liệu này vào cơ sở dữ liệu, trigger sẽ tính toán hai giá trị đó và chèn các giá trị đã nhập.
select*from Student;+-----+-------+-------+-------+-------+-------+------+ | tid | name | subj1 | subj2 | subj3 | total | per |+-----+-------+-------+-------+-------+-------+------+ |100| ABCDE |20|20|20|60|36|+-----+-------+-------+-------+-------+-------+------+
Bằng cách này, trigger có thể được tạo và thực thi trong cơ sở dữ liệu.
Trigger trong SQL là một công cụ mạnh mẽ giúp bạn kiểm soát chặt chẽ hơn các hoạt động trong cơ sở dữ liệu, tự động hóa các tác vụ, và đảm bảo tính toàn vẹn của dữ liệu. Tuy nhiên, để sử dụng trigger hiệu quả, bạn cần hiểu rõ về cấu trúc và cách hoạt động của chúng, cũng như cân nhắc về ưu nhược điểm, hi vọng bài viết trên của TopDev đã giúp bạn hiểu rõ hơn về Trigger SQL.
Ngày nay, ReactJS đã trở nên rất phổ biến bởi những tính năng linh hoạt và đơn giản với hơn 1,300 developer và hơn 94,000 trang web đang sử dụng ReactJS. Nhiều người ám chỉ rằng ReactJS sẽ là tương lai của việc phát triển web.
ReactJS là một thư viện JavaScript mã nguồn mở được thiết kế bởi Facebook để tạo ra những ứng dụng web hấp dẫn, nhanh và hiệu quả với mã hóa tối thiểu. Mục đích cốt lõi của ReactJS không chỉ khiến cho trang web phải thật mượt mà còn phải nhanh, khả năng mở rộng cao và đơn giản.
Sức mạnh của nó xuất phát từ việc tập trung vào các thành phần riêng lẻ. Chính vì vậy, thay vì làm việc trên toàn bộ ứng dụng web, ReactJS cho phép một developer có thể phá vỡ giao diện người dùng phức tạp thành các thành phần đơn giản hơn.
TẠI SAO REACTJS LẠI LÀ LỰA CHỌN HÀNG ĐẦU CHO CÁC DOANH NGHIỆP
Trong lĩnh vực phát triển công nghệ, các chủ doanh nghiệp và developer luôn tìm kiếm những phương pháp tốt nhất để giúp doanh nghiệp của họ có những lợi thế cạnh tranh tốt hơn. Và một trong những công nghệ tốt nhất có thể giúp những doanh nghiệp vượt mặt đối thủ trong việc tạo ra những ứng dụng web chính là ReactJS.
Lập trình ReactJS cho phép các doanh nghiệp tạo ra những ứng dụng web với UI tốt hơn để nâng cao trải nghiệm người dùng. Đây cũng chính là công nghệ mà các doanh nghiệp cần để có được lượng tương tác của người dùng, tỉ lệ click cũng như chuyển đổi cao hơn. Hơn thế, các doanh nghiệp sử dụng ReactJS được đảm bảo có giao diện tốt hơn so với những doanh nghiệp sử dụng các framework khác bởi ReactJS giúp ngăn chặn việc cập nhật của DOM giúp ứng dụng nhanh hơn và truyền tải tốt hơn UX.
TƯƠNG LAI CỦA REACTJS
Facebook và toàn bộ đội phát triển ReactJS vẫn luôn cố gắng chứng tỏ trong việc cam kết nâng cao tính hiệu quả của ReactJS. Đây là vấn đề tiên quyết để vượt qua sự phát triển nhanh chóng của các framework khác như Vue.js. Một số cập nhật của React được mong đợi trong tương lai có thể kể đến như:
Sẽ có những loại render mới như việc add thêm những đoạn cú pháp độc đáo vào JSX mà không cần đến keys.
Cải thiện trong việc xử lý các lỗi phát sinh. Trước đây, các lỗi Javascript bên trong các Components sẽ làm hỏng state của component và cũng gây ra các lỗi trong quá trình render trong các component cha khác. Các lỗi này được thông báo rất khó hiểu gây ra khó khăn trong việc khắc phục. Một vấn đề khác là trong các phiên bản trước đây thì React không cung cấp cách thức để có thể bắt và xử lý lỗi và phục hồi khi xảy ra lỗi một cách rõ ràng trong Components.
Trên đây chính là những kiến thức cơ bản nhất về ReactJS, nếu như bạn đã có một base khá ổn về ReactJS, vậy bạn có bao giờ nghĩ rằng mình sẽ thay đổi và tối ưu tốc độ của nó cũng như lấn sân sang React Native để trở thành một React Developer???
Với Thách thức tuyển dụng Phần 1, TopDev đã đề cập về thương hiệu tuyển dụng cũng như vấn đề liên quan tới đặc điểm ứng viên. Tại Phần 2 này, TopDev sẽ giúp bạn có cái nhìn sâu hơn về những khó khăn liên quan đến chính bản thân nhà tuyển dụng và các yếu tố liên quan như công nghệ, hệ thống hỗ trợ…
Cũng như Phần 1, TopDev sẽ không dừng ở việc đưa ra vấn đề mà còn cung cấp cho bạn các giải pháp tối ưu nhất! Nào hãy cùng TopDev tìm hiểu nhé
Thách thức tuyển dụng IT 11: Xóa bỏ sự thiên vị
Thiên vị là điều khó tránh khỏi trong tuyển dụng. Dù bạn cho rằng mình công tâm nhất, vẫn có những thiên vị hiện diện vô thức ảnh hưởng xấu đến quá trình tuyển dụng đấy. Một số kiểu thiên vị thường gặp như: giới tính, quê quán, tôn giáo,…
Giải pháp
Cần làm gì?
Làm cách nào?
Triển khai các chiến lược đa dạng để loại bỏ thiên vị trong quá trình tuyển dụng.
=> Hướng dẫn nhà tuyển dụng cách tránh khỏi sự thiên vị trong từng bước của quá trình tuyển dụng.
-Tiêu chuẩn hóa quá trình tuyển dụng. Đảm bảo phỏng vấn các ứng viên với cùng loạt câu hỏi.
=>So sánh ứng viên dựa trên các tiêu chí định sẵn. TopDev tin rằng bạn sẽ chọn được ứng viên tốt nhất thay vì “thích” nhất.
-Cung cấp khóa đào tạo đa dạng giúp những người có liên quan học cách tránh thiên vị trong tuyển dụng.
-Thiết lập bảng phỏng vấn đa dạng.
=>Việc gồm nhiều người trong quá trình tuyển dụng giúp bạn nhận ra những thành kiến vô thức, cải thiện sự công bằng, bình đẳng.
Thách thức tuyển dụng IT 12: Chọn đúng ứng viên
Không ngạc nhiên khi có lượng lớn công ty cho rằng việc tuyển dụng của họ không hiệu quả. Theo một báo cáo của Micheals, chỉ có 19% công ty thu hút được ứng viên tài năng.
Trong 1 doanh nghiệp ít hơn 50 người, chi tiêu cho lao động cho 1 nhân viên trung bình là hơn 900 triệu đồng, theo Baron & Kreps. Một quyết định tuyển dụng sai lầm có thể khiến công ty tốn lên đến 150%-250% mức lương trung bình hằng năm của 1 nhân viên! Quả là một con số kinh khủng. Không chỉ thế mà doanh thu, năng suất, đạo đức nhân viên, quan hệ khách hàng cũng bị ảnh hưởng xấu.
Giải pháp
Cần làm gì?
Làm cách nào?
TopDev có thể giúp bạn thế nào?
Triển khai các phương pháp tuyển chọn ứng viên hiệu quả nhất.
=>Đảm bảo chọn đúng người cho đúng vị trí và phù hợp với văn hóa công ty.
-Triển khai các bài đánh giá kĩ năng, các buổi phỏng vấn và kế hoạch đánh giá đa dạng.
=>Đánh giá ứng viên hiệu quả hơn. Từ đó chọn được người phù hợp nhất với vị trí và văn hóa công ty.
Với Job Posting, TopDev cam kết tất cả CV đều được sàng lọc trước khi gửi nhà tuyển dụng. Giúp bạn đến gần hơn bao giờ hết việc chọn được nhân tài tương lai!
Thách thức tuyển dụng IT 13: Đảm bảo việc cộng tác dễ dàng
Gần đây, lĩnh vực thu hút nhân tài đã chuyển mình từ mô hình tuyển dụng truyền thống sang các phương pháp tuyển dụng mang tính cộng tác hơn. Quá trình tuyển dụng hiện đại dựa trên sự hợp tác hài hòa giữa ban quản trị, nhà tuyển dụng, chuyên gia IT,…
Tuy nhiên, ngày càng nhiều người làm việc ở các khu vực khác nhau, việc đảm bảo sự hợp tác trơn tru không hề dễ dàng!
Giải pháp
Cần làm gì?
Làm cách nào?
Triển khai mô hình tuyển dụng hợp tác hiệu quả.
Sau khi đã áp dụng thành công mô hình trên, TopDev có vài lời khuyên cho bạn như sau:
-Tập hợp các ban lại, thiết lập tiêu chí tuyển dụng rõ ràng, xác định must-haves và nice-to-haves.
-Khuyến khích mọi thành viên đưa ý kiến, nhận xét với từng ứng viên.
-Đảm bảo mọi người đều có công cụ cần thiết cho phép họ giao tiếp kịp thời và hiệu quả.
TopDev tin rằng khi 3 bước trên được thực hiện nghiêm túc, việc tuyển dụng của bạn sẽ khả quan hơn nhiều đấy !
Thách thức tuyển dụng IT 14: Giản lược quá trình tuyển chọn
Theo Báo cáo về thị trường IT Việt Nam 2022 của TopDev, có 18,6% ứng viên không thích quy trình tuyển dụng có quá nhiều vòng phỏng vấn. Do đó, việc sắp xếp, đơn giản hóa và tự động hóa quá trình tuyển dụng là điều cần thiết trong lúc này.
Giải pháp
Cần làm gì?
Làm cách nào?
Tinh giản quá trình chọn lọc và tuyển dụng để tiết kiệm thời gian và chi phí.
TopDev sẽ gợi ý cho bạn 3 bước cực kì hiệu quả để tinh gọn quá trình tuyển dụng:
B1: Xác định vấn đề còn tồn tại và cải thiện chúng.
B2: Cắt gọn quy trình tuyển dụng và đơn giản hóa hệ thống theo dõi ứng viên.
B3: Kết hợp việc tự động hóa càng nhiều càng tốt.
=> Một quá trình tuyển dụng nhất quán và tinh gọn sẽ không còn ngoài tầm với nữa!
Thách thức tuyển dụng IT 15: Đẩy nhanh quá trình tuyển dụng
Nếu bạn muốn giật lấy ứng viên top đầu, bạn cần phải tuyển dụng thật nhanh chóng. Thế thì nhanh đến mức nào? Theo ERE Medis’s Research, ứng viên hàng đầu chỉ có mặt trên thị trường việc làm trong 10 ngày mà thôi. Hơn nữa, 57% ứng viên sẽ mất hứng nếu quá trình tuyển dụng lôi thôi dài dòng.
Tuy nhiên đáng buồn là có 70% doanh nghiệp mất đến 1-4 tháng để tuyển thêm một người mới, theo LinkedIn.
Giải pháp
Cần làm gì?
Làm cách nào?
TopDev có thể giúp bạn thế nào?
Rút ngắn quá trình tuyển dụng. Nếu không, bạn phải chịu thêm chi phí vì một quá trình tuyển dụng trễ nải đấy.
Ngưng phí thời gian vào các thao tác hành chính thủ công không cần thiết và kém hiệu quả.
=> Các công việc như tìm nguồn ứng viên, xem xét và phân tích CV, lên lịch phỏng vấn,… cần tự động hóa.
Sở hữu hơn 300,000 dữ liệu IT và cộng đồng Developer lớn nhất Việt Nam, TopDev sẽ giúp bạn tiếp cận nhiều ứng viên hơn bao giờ hết, cũng như xem xét và lọc CV, việc bạn cần làm chỉ là lên lịch phỏng vấn mà thôi! Tìm hiểu thêm về tại đây!
Thách thức tuyển dụng IT 16: Tập trung vào dữ liệu
Số liệu tuyển dụng là nền tảng cũng như động lực thúc đẩy doanh nghiệp đạt được mục tiêu kết quả kinh doanh. Theo Global Human Capital Trends, 71% doanh nghiệp cho rằng phân tích dữ liệu là ưu tiên hàng đầu của họ. Ngược lại, các doanh nghiệp không xem trọng vấn đề này thường sẽ mất đi lợi thế cạnh tranh với đối thủ khác.
Giải pháp
Cần làm gì?
Làm cách nào?
Phát triển tư duy thống kê cho đội ngũ tuyển dụng của bạn.
Nếu bạn muốn có cái nhìn tổng thể về quá trình tuyển dụng, bạn cần theo dõi và đo lường các số liệu quan trọng. Điều này cũng được TopDev vận dụng và khá hiệu quả đấy.
=>Giúp bạn ra quyết định tốt hơn cũng như cải thiện năng suất làm việc.
-Xác định số liệu tuyển dụng mục tiêu và theo dõi chúng thường xuyên.
-Đo lường từng bước trong quá trình tuyển dụng
TopDev mong rằng sau khi thực hiện 2 phương án trên, bạn sẽ có cái nhìn sâu sắc và đưa ra quyết định mang tính chiến lược hơn.
=> Giúp bạn bớt lãng phí nguồn lực
Thách thức tuyển dụng IT 17: Xu hướng đầu tư tài chính cá nhân
Với sự bùng nổ của các lĩnh vực đầu tư cá nhân như tiền ảo, NFT và chứng khoán, một số cá nhân có hiểu biết và thích nghi nhanh với xu hướng đã nhanh chóng tạo lập được cơ sở tài chính cá nhân vững chắc. Viễn cảnh tốt đẹp được miêu tả như một cứu cánh khi thị trường lao động gặp nhiều khó khăn, khiến nhiều người ưa chuộng và bắt đầu theo đuổi.
Điều này trực tiếp gây ảnh hưởng đến thị trường lao động khi một thành phần lao động tách ra khỏi thị trường và theo đuổi những lĩnh vực này. Bên cạn đó, x hướng này còn khiến cho sự cạnh tranh giữa các doanh nghiệp để thu hút nhân tài ngành IT trở nên gay gắt hơn.
Giải pháp
Cần làm gì?
Làm cách nào?
Để thu hút nhân tài trở lại ngành IT, chủ doanh nghiệp cần tạo ra một môi trường làm việc thân thiện và có tính cạnh tranh cao.
Các chủ doanh nghiệp cần tạo ra các dự án thú vị và có tính cạnh tranh để thu hút nhân tài.
Một trong những cách thu hút nhân tài trở lại ngành IT là tăng cường quảng bá thương hiệu của doanh nghiệp.
Thu hút nhân tài có thể được thực hiện bằng cách cải thiện các chính sách về lương, phúc lợi, đào tạo và phát triển nghề nghiệp cho nhân viên.
Những dự án đó có thể là các sản phẩm công nghệ mới, các ứng dụng mới, các giải pháp mới cho các vấn đề trong ngành, và các dự án liên quan đến công nghệ mới như NFT, Blockchain,…
Các chủ doanh nghiệp có thể sử dụng các kênh truyền thông xã hội, trang web, hoặc các sự kiện liên quan đến công nghệ để giới thiệu về doanh nghiệp và thu hút sự chú ý của nhân tài.
Thách thức tuyển dụng IT 18: Công nghệ lỗi thời
Năm 2020, việc tuyển dụng bằng bảng tính Excel và email có vẻ không còn là sự lựa chọn phù hợp. Dù bạn có là một chuyên gia sử dụng các công nghệ chuyên môn như Applicant Tracking System (ATS), khả năng rất cao những phần mềm này trở nên lạc hậu. Các hệ thống theo dõi ứng viên thường quá tải khi đối mặt với nhu cầu ngày càng cao của quá trình tuyển dụng.
Giải pháp
Cần làm gì?
Làm cách nào?
Tận dụng tất cả tiện ích mà công nghệ cung cấp.
Đầu tư vào một phần mềm tuyển dụng hiện đại, đơn giản, thân thiện với người dùng.
Thách thức tuyển dụng IT 19: Vận dụng công nghệ mới
Nhà tuyển dụng của Base Enterprise cho biết năng suất của cô tăng ít nhất 200% so với công ty không có hệ thống hỗ trợ nào ngoài Excel cô làm trước đó. Nhờ vậy, cô không cần làm giấy tờ hành chính mà chỉ tập trung vào tương tác và nghĩ cách tối hưu hóa quá trình tuyển dụng của mình.
Công nghệ đang dần thay đổi thế giới, và thay đổi cả cách chúng ta tuyển dụng. Công nghệ tuyển dụng hiện đại hứa hẹn việc chiêu mộ nhân tài sẽ dễ dàng và hiệu quả hơn. Mặc dù nghe có vẻ thú vị, TopDev tin rằng việc áp dụng công nghệ mới có thể trở nên quá sức và đáng sợ!
Giải pháp
Cần làm gì?
Làm cách nào?
Nếu bạn muốn việc chiêu mộ nhân sự thành công trong năm 2024, bạn phải áp dụng giải pháp tuyển dụng mới nhất.
Đầu tư vào một phần mềm tuyển dụng hiện đại và thân thiện với người dùng.
Thách thức tuyển dụng IT 20: Kết hợp đa dạng các giải pháp tuyển dụng
Với sự phổ biến của hàng loạt giải pháp tuyển dụng thì việc kết hợp chúng vào một hệ thống chiêu mộ nhân tài là vô cùng cần thiết. Vậy thì làm sao để sự tích hợp này được trơn tru liền mạch?
Giải pháp
Cần làm gì?
Làm cách nào
TopDev có thể giúp bạn thế nào?
Tích hợp các giải pháp tuyển dụng vào 1 nền tảng duy nhất.
Đầu tư vào một phần mềm hiện đại, dễ sử dụng với các tính năng tiện ích.
TopDev tin rằng Job Posting sẽ giúp bạn giải quyết tối ưu những vấn đề tuyển dụng bạn đang gặp phải, bởi:
Đây là sự kết hợp của: tiếp cận ứng viên tiềm năng, đăng tin job, quảng bá job cũng như sàng lọc CV trước khi gửi nhà tuyển dụng!
=>Cực kì tiện lợi và tiết kiệm thời gian, chi phí.
KẾT LUẬN
Việc xây dựng quan hệ tích cực giữa nhà tuyển dụng và ứng viên đóng vai trò cực kì quan trọng quyết định sự hiệu quả của tiến trình chiêu mộ nhân tài. Để làm được điều đó thì việc nhà tuyển dụng kết hợp nhuần nhuyễn các công cụ khác nhau để thu hút, lôi kéo ứng viên ngày càng là một bài toán nan giải. Với kinh nghiệm và chuyên môn trong ngành, TopDev tự tin là giải pháp thiết thực nhất giúp khắc phục những khuyết điểm trong khâu chiêu mộ của bạn cũng như giúp bạn tối ưu hóa thời gian, chi phí để nhận được kết quả tốt nhất!
Nếu còn gì chưa rõ, ấn vào đây và đội ngũ TopDev sẽ giúp bạn giải đáp mọi thắc mắc !
Abstracts là nơi định nghĩa variables, functions, mixins.
Base bao gồm những tiêu chuẩn styles như resets, các rule và phần chung thường được sử dụng xuyên suốt project.
Components (or modules) định nghĩa các styles dành cho buttons, tabs, card, sliders và các thành phần tương tự. thông thường 1 project sẽ có nhiều components như vậy.
Layout chứa tất cả các styles liên quan đến layout trong project của bạn. Ví dụ như phần header, footer, navigation và grid system.
Pages những styles cho từng trang cụ thể. Ví dụ như có một trang không cùng styles với các trang khác và bạn không muốn để ở phần styles chung.
Vendors (có thể import từ node_modules) bao gồm tất cả những phần code mở rộng của bên thứ 3 của thư viện như, jQuery, Bootstrap…
main.scss dùng import các file khác để tạo ra file css chung cho cả website.
Thông thường, chúng ta viết các thuộc tính CSS một cách tự do, việc này cũng không có vấn đề gì. Tuy nhiên, để giúp code sạch đẹp, ngăn nắp hơn thì việc sắp xếp các thuộc tính theo 1 quy tắc nhất định sẽ giúp bản thân và người người khác maintain đỡ vất vả. Khi đó code của bạn cũng được đánh giá cao.
Có người sẽ sắp xếp theo thứ tự abc… theo mình cách dễ nhìn nhất là sắp xếp theo nhóm các thuộc tính liên quan.
Nên viết với định dạng .scss thay vì .sass. SCSS (Sassy CSS) là bản nâng cấp, thừa hưởng những gì tốt đẹp nhất từ người anh trai SASS. Tuy nhiên cũng có một vài ưu điểm điểm khiến mình lựa chọn.
Những thuộc tính như font-size, font-family, color, background nên dùng biến để thống nhất, không đặt trực tiếp.
Dừng lại ở 3 level
.section {
.list {
.items {
// STOP!
}
}
}
Selector chỉ nên viết tối đa 3 level, càng nhiều cấp sẽ làm performance bị hạn chế hiệu năng. Bạn cũng nên sử dụng BEM để hạn chế việc phải selector nhiều cấp.
Cách viết trên sẽ giúp chúng ta dễ phân biệt được các level của block, element, modifier và giúp ta tránh được việc selector nhiều cấp, giúp performance được tối ưu.
Viết gọn code để dễ đọc
// Good
@for $i from 1 through 3 {
.fading-item {
&:nth-child(#{$i}) {
transition-delay: 250ms * $i;
}
}
}
Trên đây là một vài chia sẻ của mình về kinh nghiệm xây dựng dự án với SASS. Hãy tạo cho mình một bộ source thật bài bản và những dòng code dễ maintain.
Chúc các bạn có một source code “sạch sẽ” và review những dòng code của người khác thật dễ nhìn.
Sau cả ngàn project thì chắc chắn anh em cũng muốn có một cái gì đó nhìn cho đẹp đẹp, cho mát mắt. Level sử dụng phức tạp đi kèm với load animation đẹp thì đỉnh không còn gì bằng! Giới thiệu cho anh em source 9 bộ CSS animation “sịn sò” để apply vào product của mình.
Một số animation bên dưới interactive được, chỉ cần rà chuột và click vào nhé.
1. Loading indicator “sịn” (chỉ trên CSS)
2. CSS animation ảo
3. “Mờ mờ nhân ảnh”…
4. Loading style Lửa trại
5. Style pastel dots
6. Lines cầu vồng
7. Style thôi miên
8. Animation Test
9. Style “Musical background” theo rà chuột
Hi vọng rằng tất cả các animation “độc” trên sẽ tiếp thêm động lực cho anh em là project. Sáng tạo là một phần rất quan trong trong công việc của chúng ta và nó cần một ít thời gian mỗi ngày để phát triển thêm nữa!💆
Tôi rất yêu lập trình. Tôi thích cảm giác tại nên cái gì đó từ số không, hay việc giải bài toán lập trình rồi thấy nó lớn lên thành cái gì đó có ích. Tôi đặc biệt yêu cảm giác học những thứ hoàn toàn mới chỉ trong vài tiếng, và trở nên giỏi hơn mà tôi không cần phải trả đồng nào hết.
Tôi được học một trong những trường đại học tốt nhất đất nước về ngành CNTT. Tôi có được job đầu tiên nhờ những nỗ lực sau kì thực tập mùa hè. Tôi rất yêu công việc của mình và tôi đã làm rất tốt phần của mình. Từ vị trí junior không lâu sau tôi đã lên senior rất nhanh và được công nhận nhờ những cố gắng của mình.
Nhưng cũng đến một thời điểm, nó không còn làm tôi hứng thú nhiều nữa. Bỗng dưng tôi ghét đi làm. Mỗi ngày là một cuộc chiến và tôi không muốn đối mặt với nó một tí nào nữa.
Chuyện gì đã xảy ra?
Tôi bắt đầu so sánh bản thân với người khác giỏi hơn.
Tôi bắt đầu sợ sai và sợ trở thành một “loser”.
Tôi bắt đầu sợ không đủ hiểu biết và bắt đầu không ngừng học tất cả mọi thứ.
Tôi bắt đầu cảm nhận được gánh nặng công việc, đồng nghiệp, con cái, nợ nần và hoá đơn.
Tôi còn có một nỗi sợ vô duyên khác: Sợ bị lộ là giả dối.
Tôi không nhận ra rằng mình đang mắc phải Hội chứng “Tâm lý kẻ mạo danh” (Impostor Syndrome)**.
**Impostor Syndrome: Đây là hội chứng tâm lý mà người mắc phải không nhận thức được giá trị bản thân và những thành công mà họ gặt hái được. Họ thường nghĩ những thứ mình đạt được là do may mắn chứ không phải vì có thực tài. Người mắc chứng tâm lý này thường rơi vào tự ti, cho mình kém cỏi, mất dần động lực phấn đấu, thu mình và không đạt được thành tựu nào trong cuộc sống.
Thay vì tận hưởng công việc thì tôi lại lo lắng thái quá về việc thiếu hiểu biết, rằng thôi chưa làm đủ. Rằng tôi không đem lại đủ giá trị cho công ty. Tôi quên đi những thành tựu mình đã làm được và chỉ tập trung vào lỗi lầm mà mình gây ra. Tôi không chỉ tập trung vào sự hoàn hảo ở chính mình mà còn đòi hỏi nó từ những người xung quanh nữa. Đây là một công thức hoàn hảo cho sự stress cao độ và mất đi hạnh phúc.
Tôi nhớ mọi bản demo mà tôi đã làm trong quá khứ. Tôi đã từng rất tự tin và hạnh phúc trước nhiều người. Bỗng một ngày nó biến mất. Thật sự lo lắng đến nỗi khi nói cũng lắp ba lắp bắp. Tôi sẽ suy nghĩ cực lung tung và sợ nói ra cái gì đó ngu xuẩn, và lo rằng người ta nghĩ gì về mình.
Những cơn giận dữ đột ngột cứ nhảy lên và cản trở tôi tập trung vào công việc. Và nó đã ảnh hưởng toàn diện lên sức khoẻ của tôi. Năng lượng luôn luôn dưới mức 0, và quan hệ của tôi với gia đình cũng như đồng nghiệp trở nên rất tệ, mất ngủ, mất sức, mất luôn người thân.
Thống kê cho thấy có đến 70% số người có tâm lý Kẻ mạo danh này. Vấn đề là bạn cảm thấy như bạn là người duy nhất chịu đựng nó. Nếu may mắn thì một trong những đồng nghiệp của bạn sẽ cũng mắc phải nó, nhưng đó rõ ràng không là cách giải quyết. Nó dấu mình rất tốt, và người mắc phải thì cũng rất giỏi dấu nó một cách rất chuyên nghiệp.
Một số cách giải quyết cho bạn nếu mắc phải nó
Nhìn nhận mình đang làm gì. Nó nhiều hơn bạn nghĩ
Nhìn nhận những gì bạn đã đạt được dù nhỏ hay to. Bạn xứng đáng như thế.
Nếu được khen, hãy nhận nó. Bạn xứng đáng mà.
So sánh bản thân với chính bản thân mình thôi. Hãy tốt hơn bản thân mình của ngày hôm qua. Đừng so sánh quá đà.
Hiểu một điều: Không ai thật sự hiểu mình đang làm gì cả. Ai cũng đang trong quá trình học cả.
Không biết mọi thứ cũng chả sao cả. Công nghệ phần mềm phát triển rất nhanh, quá nhanh là khác. Nên không việc gì phải vội.
Thường thì mức hiểu biết của bạn cũng như mọi người thôi, trong một số lĩnh vực khác nhau.
Giúp nhau học, để giúp bạn hiểu được mình đã học được đến đâu.
Thất bại là không sao cả. Nó là cái gì đó rất quan trọng và bắt buộc phải có trong cuộc sống. Và hãy cởi mở với tất cả các feedback của mọi người xung quanh. Nó sẽ giúp bạn lớn nhanh hơn.
Hiểu sai cũng chẳng sao đâu, cởi mở lên là ổn cả.
Theo thời gian bạn sẽ quen dần thôi, nếu đã lâu không dùng đến thì hãy xem lại sơ để nhớ lâu hơn.
Ở nơi công sở có rất nhiều thị phi, và nói xấu. Cứ lơ nó đi, nó chẳng hề hấn gì đến cuộc sống của bạn cả.
Không phải cái nào bạn làm ra cũng sẽ hoàn hảo. Phần mềm cũng như cuộc sống vậy, nó cần sự cải thiện lâu dài. Chữ bạn không phải chỉ là dòng code mà bạn viết ra trong vài tiếng rồi lại cần cải thiện ngay đâu.
Giả định là mọi người đều có tâm lý kẻ mạo danh này đi. Hãy động viên họ hằng ngày, nói rằng họ đang làm tốt, họ làm tốt cái gì. Một lời động viên nhỏ sẽ có hiệu ứng rất lâu dài. Nếu có 1 team làm được như vậy với mọi người sẽ tạo nên được một môi trường rất lành mạnh.
Chúng ta cũng chỉ là những con người nhỏ bé, sợ hãi có, nghi ngờ có. Ai cũng có những vấn đề và khó khăn riêng phải đối mặt ngoài áp lực công việc. Những ý tưởng này thường bị quên mất trong môi trường chuyên nghiệp, và chúng ta sẽ trở nên cách biệt nhanh chóng. Chỉ khi chúng ta nhận ra nó và mong muốn một môi trường làm việc theo hướng cá nhân hơn và gắn kết hơn.
Tôi không dám chắc rằng hội chứng này sẽ biến mất hoàn toàn. Nó có thể sẽ phai đi dần khi bạn nhận ra và hiểu được nó. Hãy nhớ rằng, có rất nhiều người mắc phải nó và điều đó là rất bình thường. Thật mừng khi tôi đang dần quay lại thời điểm mà tôi có hứng thú với lập trình.
Nó sẽ tấn công bạn bất cứ lúc nào. Có thể ngay từ lúc bạn mới học code, hoặc khi bạn đã già nghề được 10 năm. Có thể là khi bạn bắt đầu có đứa con đầu lòng, cũng có thể khi bạn phỏng vấn xin việc và không được ngay.
Cái quan trọng nhất vẫn là nhận biết nó. Hãy nghiêm túc xử lý nó. Một khi nó đã đến thì hãy đối diện xử lý nó, đừng ủ nó để nó lớn thêm nữa. Hãy nói chuyện với người khác và giúp họ nếu họ đang gặp phải vấn đề này. Có thể đây cũng là cách để bạn thoát khỏi nó. Hãy cùng nhau phấn đấu thêm nữa, để không còn cảm giác mặc cảm và giữ lửa đam mê lập trình.
Tôi nhận được thư từ của nhiều bạn hỏi về việc nên học gì và như thế nào để có thể tìm được việc làm và làm được việc trong ngành an toàn thông tin (information security). An toàn thông tin là một ngành rộng lớn với rất nhiều lĩnh vực. Những gì tôi biết và làm được chỉ gói gọn trong một hai lĩnh vực. Có rất nhiều mảng kiến thức cơ bản mà tôi không nắm vững và cũng có nhiều kỹ năng mà tôi không thạo. Hack tài khoản Yahoo! Mail là một trong số đó. Tôi cũng không biết cách tìm địa chỉ IP của bạn chat :-(.
Xét theo năm mức ngu dốt thì tôi nằm ở mức “1OI – thiếu kiến thức” ở hầu hết các lĩnh vực trong an toàn thông tin. Cũng có lĩnh vực tôi nằm ở mức “2OI – thiếu nhận thức”. Nhiều lần đọc sách vở hoặc nói chuyện với đồng nghiệp, tôi hay nhận ra rằng có nhiều thứ tôi không biết là tôi không biết. Theo ý của anh Ngô Quang Hưng thì đây là chuyện bình thường:
Dân máy tính thường phải đọc/học rất nhiều để theo kịp sự phát triển với tốc độ ánh sáng của ngành mình. Trong quá trình này, với mỗi vấn đề X của ngành, ta sẽ chuyển dần dần từ 3OI xuống 1OI. Sau đó, nếu X là cái mà ta thật sự thích hoặc cần cho công việc thì sẽ chuyển nó lên 0OI.
Rất nhiều sinh viên và nghiên cứu sinh KHMT ở mức 3OI khi mới bắt đầu đi học. Sau đó họ tìm hiểu về quá trình nghiên cứu, quá trình tìm các vấn đề và hướng nghiên cứu mới, quá trính cập nhật kiến thức về ngành của mình, và chuyển dần các thứ lên 2OI. Để có một quá trình hiệu quả từ 3OI lên 2OI không dễ chút nào. Ví dụ đơn giản: các journals, conference nào trong ngành mình là có giá trị, làm thế nào để tìm đọc các bài trong chúng, phương pháp lọc bài đọc thế nào, vân vân.
Tôi thấy anh Hưng nói có lý, nên mục tiêu chính của bài viết này là cung cấp một quá trình hiệu quả để bớt ngu về an toàn thông tin.
2. Làm an toàn thông tin là làm gì?
Tôi muốn viết phần này vì nhiều người tưởng tôi làm bảo vệ khi tôi nói tôi làm security. Ngoài ra có lẽ là do thị trường việc làm an toàn thông tin ở Việt Nam không phong phú nên hầu hết đều nghĩ rằng làm an toàn thông tin nghĩa là đảm bảo an toàn hệ thống mạng (network/system security), trong khi thực tế đây chỉ là một trong số rất nhiều công việc trong ngành.
Trong bốn phần nhỏ tiếp theo, tôi sẽ giới thiệu bốn nhóm công việc chính trong ngành. Đối với mỗi nhóm công việc, tôi sẽ bàn một chút về triển vọng nghề nghiệp ở Việt Nam và Mỹ, hai nơi mà tôi có dịp được quan sát. Nếu bạn không biết bạn thích làm gì thì cứ chọn một công việc rồi làm thử. Các công việc này đều có liên quan nhau, nên kiến thức mà bạn học được trong quá trình thử vẫn hữu ích cho những nghề khác.
2.1 An toàn sản phẩm (product security)
Công việc chính của nhóm này là làm việc với các đội phát triển sản phẩm để đảm bảo sản phẩm làm ra an toàn cho người dùng và an toàn cho hệ thống của công ty, cụ thể là:
Kiểm định mã nguồn và thiết kế của sản phẩm
Phát triển các giải pháp kỹ thuật và quy trình phát triển phần mềm an toàn để phát hiện và ngăn chặn những kỹ thuật tấn công đã biết
Đào tạo nhân lực để nâng cao nhận thức về an toàn thông tin cũng như kỹ năng viết mã an toàn
Nghiên cứu các hướng tấn công mới có thể ảnh hưởng hệ thống sản phẩm và dịch vụ của công ty
Tóm gọn lại thì nhóm này chuyên tìm lỗ hổng và kỹ thuật tấn công mới. Đây là công việc của tôi và tôi thấy đây là công việc thú vị nhất trong ngành :-).
Ở Mỹ thì thông thường thì chỉ có các hãng có phần mềm và dịch vụ lớn như Facebook, Google, Microsoft, Oracle, v.v. hay các tập đoàn tài chính ngân hàng lớn mới có đội ngũ tại chỗ để đảm nhiệm công việc này. Các công ty nhỏ thường chỉ thuê dịch vụ của các công ty tư vấn. IBM và Big Four đều có cung cấp dịch vụ tư vấn này. Dẫu vậy nếu được chọn lựa thì tôi sẽ chọn làm cho các công ty chuyên sâu như Matasano, iSec, Leviathan, Gotham, IOActive, Immunity, v.v.
Ở Việt Nam thì thị trường việc làm cho người làm an toàn sản phẩm có vẻ ảm đạm hơn. Cho đến nay tôi biết chỉ có một vài công ty ở Việt Nam là có nhân viên chuyên trách lĩnh vực này. Các công ty khác (nếu có quan tâm đến an toàn thông tin) thì hầu như chỉ tập trung vào an toàn vận hành. Các công ty tư vấn an toàn thông tin ở Việt Nam cũng không tư vấn an toàn sản phẩm, mà chỉ tập trung tư vấn chung chung về các quy trình và tiêu chuẩn an toàn thông tin.
2.2 An toàn vận hành (operations security)
Công việc chính của nhóm này là đảm bảo sự an toàn cho toàn bộ hệ thống thông tin của doanh nghiệp, với ba nhiệm vụ chính:
Ngăn chặn: đưa ra các chính sách, quy định, hướng dẫn về an toàn vận hành; kiện toàn toàn bộ hệ thống thông tin, từ các vành đai cho đến máy tính của người dùng cuối; cấp và thu hồi quyền truy cập hệ thống; quét tìm lỗ hổng trong hệ thống, theo dõi thông tin lỗ hổng mới và làm việc với các bên liên quan để vá lỗi, v.v.
Xử lý: phản hồi (incident response) và điều tra số (digital forensics) khi xảy ra sự cố an toàn thông tin, từ tài khoản của nhân viên bị đánh cắp, rò rỉ thông tin sản phẩm mới cho đến tấn công từ chối dịch vụ.
Đây là công việc khó nhất, nhưng lại ít phần thưởng nhất của ngành an toàn thông tin.
Tương tự như trên, chỉ có các hãng lớn của Mỹ mới có đội ngũ tại chỗ để phụ trách toàn bộ khối lượng công việc đồ sộ này, nhất là mảng xử lý và điều tra. Đa số các công ty chỉ tập trung vào ngăn chặn và sử dụng dịch vụ của bên thứ ba cho hai mảng còn lại. Các hãng như Mandiant, Netwitness hay HBGary cung cấp dịch vụ điều tra các vụ xâm nhập và có rất nhiều hãng khác cung cấp dịch vụ giám sát an ninh mạng.
Ở Việt Nam thì thị trường việc làm cho người làm an toàn vận hành tương đối phong phú hơn so với an toàn sản phẩm. Các công ty và tổ chức tài chính lớn đều có một vài vị trí chuyên trách về an toàn vận hành. Đa số người làm về an toàn thông tin ở Việt Nam mà tôi biết là làm trong lĩnh vực này. Dẫu vậy hầu như chưa có ai và công ty tư vấn nào làm về phản hồi và điều tra sự cố.
2.3 Phát triển công cụ (applied security)
Công việc chính của nhóm này là phát triển và cung cấp các công cụ, dịch vụ và thư viện phần mềm có liên quan đến an toàn thông tin cho các nhóm phát triển sản phẩm sử dụng lại.
Nhóm này bao gồm các kỹ sư nhiều năm kinh nghiệm và có kiến thức vững chắc về an toàn thông tin, viết mã an toàn và mật mã học. Họ phát triển các thư viện và dịch vụ dùng chung như phân tích mã tĩnh – phân tích mã động (static – dynamic code analysis), hộp cát (sandboxing), xác thực (authentication), kiểm soát truy cập (authorization), mã hóa (encryption) và quản lý khóa (key management), v.v.
Đây là dạng công việc dành cho những ai đang viết phần mềm chuyên nghiệp và muốn chuyển qua làm về an toàn thông tin. Đây cũng là công việc của những người thích làm an toàn sản phẩm nhưng muốn tập trung vào việc xây dựng sản phẩm hơn là tìm lỗ hổng.
Rõ ràng loại công việc này chỉ xuất hiện ở các công ty phần mềm lớn. Ở các công ty phần mềm nhỏ hơn thì các kỹ sư phần mềm thường phải tự cáng đáng công việc này mà ít có sự hỗ trợ từ nguồn nào khác. Ở Việt Nam thì tôi không biết có ai làm dạng công việc này không.
2.4 Tìm diệt mã độc và các nguy cơ khác (threat analysis)
Ngoài an toàn sản phẩm ra thì đây là một lĩnh vực mà tôi muốn làm. Công việc chính của nhóm này là phân tích, truy tìm nguồn gốc và tiêu diệt tận gốc mã độc và các tấn công có chủ đích (targeted attack). Mã độc ở đây có thể là virút, sâu máy tính, hay mã khai thác các lỗ hổng đã biết hoặc chưa được biết đến mà phần mềm diệt virút thông thường chưa phát hiện được. Các loại mã độc này thường được sử dụng trong các tấn công có chủ đích vào doanh nghiệp.
Tôi nghĩ rằng sau hàng loạt vụ tấn công vừa rồi thì chắc hẳn các công ty lớn với nhiều tài sản trí tuệ giá trị đều muốn có những chuyên gia trong lĩnh vực này trong đội ngũ của họ. Ngoài ra các công ty chuyên về điều tra và xử lý sự cố như Mandiant, HBGary hay Netwitness mà tôi đề cập ở trên đều đang ăn nên làm ra và lúc nào cũng cần người. Các công ty sản xuất phần mềm diệt virút dĩ nhiên cũng là một lựa chọn.
Ở Việt Nam thì tôi nghĩ hầu hết doanh nghiệp vẫn chưa thấy được nguy cơ đến từ các cuộc tấn công có chủ đích, thành ra họ sẽ không tuyển người chuyên trách vấn đề này. Tôi cũng không biết có công ty tư vấn nào ở Việt Nam chuyên về điều tra và xử lý sự cố hay không. Tôi nghĩ lựa chọn khả dĩ nhất cho những người thích mảng công việc này là các công ty phần mềm diệt virus.
Tuy nhiên cũng cần lưu ý rằng trong vài năm gần đây ở Việt Nam còn xuất hiện những loại mã độc nhắm vào đông đảo người dùng máy tính bình thường. Vấn nạn này có lẽ sẽ còn kéo dài trong nhiều năm tới và lẽ đương nhiên “phe ta” lúc nào cũng cần thêm những chiến sĩ lành nghề như anh TQN. Thành ra dẫu triển vọng nghề nghiệp không sáng sủa cho lắm, nhưng tôi rất hi vọng sẽ ngày càng nhiều người tham gia vào việc phân tích các mã độc nhắm vào người dùng máy tính ở Việt Nam. Đối với tôi họ là những người hùng thầm lặng, chiến đấu đêm ngày với các “thế lực thù địch” để bảo vệ tất cả chúng ta.
Đa số những bạn viết thư cho tôi đều đang học đại học ngành CNTT và tất cả đều than rằng chương trình học quá chán, không có những thứ mà các bạn muốn học. Tôi nghĩ đây là một ngộ nhận.
Hối tiếc lớn thứ nhì trong sự nghiệp học tập mấy chục năm của tôi là đã không học nghiêm túc khi còn là sinh viên (hối tiếc lớn nhất là tôi đã không nghỉ hẳn, nhưng đó là một câu chuyện dài khác). Tôi cũng đã nghĩ rằng chương trình học ở đại học là lạc hậu và không cần thiết. Bây giờ nhìn lại thì tôi thấy nội dung và cách dạy của từng môn học thì đúng là lạc hậu (chỉ có mấy môn triết học Mác-Lênin là bắt kịp ánh sáng thời đại), nhưng toàn bộ giáo trình đại học vẫn cung cấp được một cái sườn kiến thức rất cần thiết cho một kỹ sư an toàn thông tin.
Ở đại học người ta có cách tiếp cận top-down, nghĩa là dạy từ đầu đến cuối những kiến thức nằm trong chương trình. Điều này dễ dẫn đến tình trạng là người học phải học những kiến thức mà họ không thấy cần thiết. Nếu chương trình học cũ kỹ và không có nhiều thực hành, hoặc người dạy không chỉ ra được bức tranh toàn cảnh, vị trí hiện tại của người học và bước tiếp theo họ nên làm là gì thì người học sẽ dễ cảm thấy rằng họ đang phí thời gian học những kiến thức vô bổ.
Trong khi khi đi làm thì cách tiếp cận là bottom-up, nghĩa là lao vào làm, thấy thiếu kiến thức chỗ nào thì học để bù vào chỗ đó. Lúc này tôi hoàn toàn chủ động trong việc học và tôi cũng hiểu rõ tôi cần học cái gì và tại sao. Điều thú vị là mỗi khi truy ngược lại nguồn gốc của những kiến thức tôi cần phải có, tôi thường thấy chúng nằm trong chương trình đại học.
Ví dụ như tôi muốn luyện kỹ năng dịch ngược mã phần mềm (reverse code engineering – RCE) thì tôi thấy rằng tôi cần phải có kiến thức về tổ chức và cấu trúc máy tính. Hoặc nếu tôi muốn học về mật mã học thì tôi phải học lý thuyết tính toán, mà khởi nguồn là lý thuyết automata. Nhưng tại sao trước đó tôi cũng đi làm nhưng không thấy được những lỗ hổng kiến thức này? Tôi nghĩ là do tôi làm không đủ sâu. Ví dụ như nếu bạn suốt ngày chỉ lập trình PHP thì bạn sẽ không thể hiểu được tại sao phải nắm vững tổ chức và kiến trúc máy tính. Hoặc giả như công việc của bạn là sysadmin thì cũng sẽ rất khó để bạn thấy được tại sao cần phải học lý thuyết automata.
Những gì tôi nói lan man ở trên có thể tóm gọn lại thế này:
Học dựa theo chương trình đại học. Nếu bạn đang học đại học các ngành công nghệ thông tin, khoa học máy tính hay toán tin thì nên tập trung vào việc học các môn trong trường. Các học liệu trong phần 4 cũng được soạn theo các đại học lớn trên thế giới.
Học kiến thức căn bản thật vững (cái gì là căn bản thì xem phần 4), những món còn lại khi nào cần (căn cứ vào nhu cầu công việc) thì hẵng học.
Tìm dự án lề (side project) mà bạn thích để làm để có thể nhanh chóng nhận ra những mảng kiến thức còn thiếu.
Thời điểm tốt nhất để học một cái gì đó là khi bạn đang là sinh viên. Thời điểm tốt thứ hai là ngay bây giờ!
Các lớp mà tôi liệt kê trong phần 4 đa số là của đại học Stanford. Bạn không cần phải đến tận nơi, ngồi trong lớp mới có thể học được. Tôi thấy trong nhiều trường hợp thì bạn chỉ cần đọc lecture notes, sách giáo khoa mà lớp sử dụng rồi làm bài tập đầy đủ thì vẫn sẽ tiếp thu đủ kiến thức. Một số lớp mà tôi liệt kê dưới đây được dạy miễn phí rộng rãi trên Coursera.
Bạn có thể tham khảo chương trình SCPD nếu muốn học chung với các sinh viên Stanford khác. Đây là chương trình học từ xa thông qua video. Buổi sáng lớp diễn ra thì buổi chiều bạn đã có video để xem. Thi cử như các sinh viên chính quy khác và điểm phải trên B mới được học tiếp. Đây là chương trình mà tôi theo học. Điểm thú vị là mỗi học kỳ bạn chỉ cần lấy một lớp, nhưng Stanford vẫn sẽ cho bạn xem video của tất cả các lớp khác.
Ngoài Stanford và Coursera ra, bạn cũng có thể tham khảo các lớp trên Udacity, OCW và MITx. Khi tôi đang viết những dòng này thì MIT và Harvard công bố dự án edX. Chúng ta đang sống trong một thời đại cực kỳ thú vị! Bây giờ chỉ cần bạn chịu học thì muốn học cái gì cũng có lớp và học liệu miễn phí. Nhưng mà học cái gì bây giờ?
4. Học cái gì?
Có ba món quan trọng cần phải học: lập trình, lập trình và lập trình! Để làm việc được trong ngành này, bạn phải yêu thích lập trình. Không có cách nào khác. Thề luôn!
Tôi dành khá nhiều thời gian tìm hiểu giáo trình khoa học máy tính của các trường đại học lớn trên thế giới và tôi thấy tất cả các môn học đều có phần bài tập là lập trình. Học cái gì viết phần mềm cho cái đó. Học về hệ điều hành thì phần bài tập là viết một hệ điều hành. Học về mạng thì viết phần mềm giả lập router, switch hay firewall. Cá nhân tôi cũng thấy rằng lập trình là cách tốt nhất để tiếp thu kiến thức một môn học nào đó, biến nó thành của mình. Nói cách khác, lập trình là một cách mã hóa tri thức khá hiệu quả.
Ngoài ra nhìn vào mô tả công việc ở phần 2, bạn cũng có thể thấy kỹ năng lập trình quan trọng đến dường nào, bởi hầu hết các vấn đề và giải pháp của an toàn thông tin là đến từ phần mềm. Rõ ràng muốn tìm lỗi của phần mềm thì bạn phải hiểu được phần mềm thông qua mã nguồn trực tiếp hay trung gian của nó. Rất có thể bạn sẽ không phải lập trình hàng ngày, nhưng bạn phải viết được những công cụ nhỏ hay những thư viện hỗ trợ cho công việc và các lập trình viên khác.
Vậy làm thế nào để lập trình giỏi? Câu hỏi này làm tôi nhớ đến câu chuyện cười về ông lập trình viên không thể ra khỏi phòng tắm vì trên chai dầu gội có ghi hướng dẫn sử dụng là “cho vào tay, xoa lên đầu, xả nước và lập lại”. Từ khóa trong câu chuyện này là “lập lại”: muốn giỏi lập trình thì cách tốt nhất là lập trình nhiều vô!
Nhưng mà lập trình bằng ngôn ngữ gì bây giờ? Đây là câu hỏi dễ làm cho các lập trình viên oánh nhau nhất ;-). Cá nhân tôi thấy rằng người làm an toàn thông tin bây giờ cần phải thông thạo C, x86 Assembly, Python (hoặc Ruby) và JavaScript. Tôi có nói lý do tại sao trong phần giới thiệu sách tiếp theo.
Lập trình
Brian Kernighan, Dennis Ritchie, The C Programming Language (2nd Edition): kinh điển và phải-đọc cho tất cả những ai muốn học C! Linus Torvalds từng nói rằng “[…] all right-thinking people know that (a) K&R are _right_ and (b) K&R are right“. Tôi đã từng rất sợ C (vì nghĩ nó phức tạp), và cuốn này giúp tôi không còn sợ nữa.
Randal Bryant, David O’Hallaron, Computer Systems: A Programmer’s Perspective: cuốn này được dùng cho lớp CS107. Đọc cuốn này và làm bài tập của lớp CS107 sẽ rèn cho bạn kỹ năng lập trình C và x86 Assembly. Sau khi đọc cuốn này, bạn sẽ biết tại sao có lỗi tràn bộ đệm và cách khai thác chúng. Tôi rất thích các chương nói về x86 và sự liên kết giữa các công cụ như preprocessor, compiler và linker.
David Hanson, C Interfaces and Implementations: muốn mau “lên cơ” bida thì phải thường xuyên xem người khác chơi để mà học “đường” mới. Tương tự, muốn giỏi lập trình thì phải thường xuyên đọc mã của những cao thủ. David Hanson là một cao thủ C và cuốn sách này sẽ chỉ cho bạn nhiều “đường” mới trong việc sử dụng C. Tôi thích các bài tập của cuốn sách này. Tôi nghĩ chỉ cần luyện các bài này là đủ để trở thành một lập trình viên C hạng lông.
Justin Seitz, Gray Hat Python: Python Programming for Hackers and Reverse Engineers: cuốn này sẽ giúp bạn sử dụng Python để viết những công cụ nho nhỏ mà bất kỳ ai làm an toàn thông tin cũng sẽ phải viết một vài lần trong đời.
Douglas Crockford, JavaScript: The Good Parts: JavaScript là ngôn ngữ thống trị WWW. Nếu bạn muốn làm an toàn (ứng dụng và trình duyệt) web thì bắt buộc phải thành thạo ngôn ngữ. Cuốn sách rất mỏng này của tác giả JSON giới thiệu đầy đủ những vấn đề mà người làm an toàn ứng dụng cần phải biết về JavaScript. Cuốn này có thể dùng làm sách giáo khoa thay cho cuốn “Javascript: The Definitive Guide” trong lớp CS142 (xem bên dưới). Đọc cuốn này tôi mới hiểu closure là gì và bản chất prototypal của JavaScript.
Abraham Silberschatz, Peter Galvin, and Greg Gagne, Operating System Concepts, 8th Edition Update: cuốn này là giáo trình của lớp CS140. Tôi nghĩ không cần đọc cuốn này, chỉ cần đọc notes và làm bài tập (viết các phần khác nhau của một hệ điều hành!) là đủ. Đây là một lớp nặng. Tôi theo đuổi lớp CS140 này giữa chừng thì phải dừng lại do không có đủ thời gian.
Intel Software Developer Manuals: tôi thấy nên đọc tài liệu của 80386 trước, rồi sau đó hẵng đọc tài liệu của các CPU mới hơn.
Red Hat, Introduction to System Administration: tôi rất thích chương nói về “philosophy of sysadmin” của cuốn này và tôi nghĩ kỹ năng quản trị hệ thống là cực kỳ cần thiết khi muốn nghiên cứu các kỹ thuật tấn công/phòng thủ mới. Không thể làm an toàn vận hành nếu không có kỹ năng quản trị hệ thống.
Mạng máy tính
Richard Stevens, TCP/IP Illustrated Vol I: cuốn sách này quá nổi tiếng rồi nên tôi nghĩ không cần phải giới thiệu. Tôi chưa đọc Vol II, III nhưng nhất định sẽ tìm đọc trong thời gian tới. Lớp CS144 dùng một cuốn sách khác. Tôi chưa học lớp này, nhưng tôi thấy bài tập của họ khá thú vị.
Stephen Northcutt, Lenny Zeltser, Scott Winters, Karen Kent, Ronald W. Ritchey, Inside Network Perimeter Security, 2nd Edition: tôi thích cuốn này vì nó viết rất dễ hiểu về các vấn đề và công cụ thường gặp trong an toàn mạng.
Sẽ đọc: Fyodor, Nmap Network Scanning.
Sau khi đã có những kiến thức cơ bản ở trên, bạn có thể theo đuổi lớp CS155. Lớp này có trên Coursera với tên Computer Security. Song song với lớp CS155, bạn có thể tìm đọc các sách sau:
Tìm lỗi phầm mềm
Mark Dowd, John McDonald, Justin Schuh, The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities: Kinh điển và phải-đọc! Cuốn này là kinh thánh của lĩnh vực an ninh ứng dụng. Tôi thích nhất phần nói về tràn số nguyên và những vấn đề của ngôn ngữ C trong cuốn này.
Dafydd Stuttard, Marcus Pinto, The Web Application Hacker’s Handbook: Discovering and Exploiting Security Flaws: cuốn này tập trung vào ứng dụng web. Tôi không đọc cuốn này kỹ lắm, mà chỉ thường dùng nó để tham khảo. Dẫu vậy tôi nghĩ nó là một cuốn giới thiệu tốt cho những ai mới bắt đầu.
Michal Zalewski, The Tangled Web: cuốn này mới xuất bản gần đây nhưng đã ngay lập tức trở thành kinh điển! Cuốn này đúc kết quá trình nghiên cứu về an ninh web trong vài năm trời của một trong những hacker xuất sắc nhất thế giới. Tôi nghĩ chỉ cần đọc cuốn này là bạn đã có thể bắt đầu tìm lỗ kiếm tiền được rồi. Cuốn này và cuốn ở trên được dùng làm sách giáo khoa của lớp CS142.
Sẽ đọc: Tobias Klein, A Bug Hunter’s Diary: A Guided Tour Through the Wilds of Software Security
Dịch ngược mã phần mềm
Eldad Eilam, Reversing: Secrets of Reverse Engineering: mặc dù có rất nhiều người viết về RCE nhưng tôi thấy đây là cuốn duy nhất hệ thống hóa được các bước quan trọng cần phải làm khi cần dịch ngược mã của một tệp chương trình nào đó.
Chris Eagle, The IDA Pro Book: The Unofficial Guide to the World’s Most Popular Disassembler: IDA Pro là công cụ tốt nhất để làm RCE và đây là cuốn sách tốt nhất về IDA Pro. Nắm vững C và x86 Assembly thì chỉ cần đọc cuốn này là bạn có thể bắt đầu RCE các phần mềm phức tạp.
Tham khảo các tài liệu về dịch ngược mã phần mềm của lớp PenTest của đại học NYU.
Sẽ đọc: Michael Sikorski, Andrew Honig, Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software
Điều tra số (digital forensics)
Brian Carrier, File System Forensic Analysis: Brian Carrier là tác giả của bộ công cụ forensic nổi tiếng The Sleuth Kit. Cuốn này đã giúp tôi “khai quật” được một đoạn video bị xóa lưu trong một máy camera quay lén các máy ATM.
Sẽ đọc: Cory Altheide, Harlan Carvey, Digital Forensics with Open Source Tools
Mật mã hóa
Niels Ferguson, Bruce Schneier, Practical Cryptography: tôi có nhiều kỷ niệm đẹp với cuốn này ;-). Hầu hết các kết quả làm việc của tôi trong vài năm vừa rồi là nhờ vào việc đọc cuốn này. Tôi chép lại đây giới thiệu rất hay của một người bạn: “The best security books, you can read “inside out”, taking any recommendation on what to do and looking for people to do the opposite to find flaws. “Firewalls and Internet Security” was like that. So was “Practical Unix Security”, and so is TOASSA. This is that book for crypto. It’s also the one book on crypto you should allow yourself to read until you start actually finding crypto flaws.“
Jonathan Katz, Yehuda Lindell, Introduction to Modern Cryptography: Principles and Protocols: đây là sách giáo khoa của lớp CS255. Lớp này là lớp Cryptography trên Coursera.
Chú ý đây là những cuốn sách tập trung vào công việc hàng ngày và sở thích của tôi — nói cách khác, còn thiếu nhiều sách của các mảng công việc khác. Dẫu vậy tôi nghĩ những cuốn sách này sẽ giúp bạn có được một kiến thức nền tảng vững chắc để từ đó theo đuổi các nghề nghiệp khác nhau trong ngành an toàn thông tin. Trong thời gian tới tôi sẽ cập nhật thêm những cuốn sách mà tôi đang và sẽ đọc.
Nếu bạn biết sách nào hay thì hãy giới thiệu cho tôi.Ngoài ra trong các sách mà tôi vừa liệt kê không có cuốn sách toán (và lý thuyết khoa học máy tính) nào cả. Tôi nghĩ bạn sẽ tự có câu trả lời cho câu hỏi “Có nên học toán hay không?” khi bắt đầu học mật mã. Về hai mảng này thì tôi rất thích lớp “Great Ideas in Theoretical Computer Science” của Scott Aaronson và cuốn “A Computational Introduction to Number Theory and Algebra” của Victor Shoup. Thích đến nỗi tôi phải viết đoạn này chỉ để nhắc đến chúng ;-). Tôi cũng đã từng dành ra nhiều tháng để đánh vật với Introduction to the Theory of Computation của Michael Sipser. Nhưng thôi, tôi không muốn giới thiệu sách toán nữa vì tôi rất dốt món này!
5. Bắt đầu nói nhảm và hết
Phew! Không ngờ là tôi cũng viết được cho đến đây (hi vọng là bạn vẫn đang đọc!). Tôi định viết dông dài về thái độ học tập này nọ, nhưng thôi bài đã dài và nhiều thông tin rồi, nên tôi chỉ nói ngắn gọn thế này:
Cái mà tôi vừa “vẽ” ra là một con đường. Thú thật là tôi không biết đích đến của nó là gì — tôi chỉ biết rằng hành trình mà tôi đã đi qua (và hi vọng là những chặng đường sắp tới) đã mang đến cho tôi rất nhiều niềm vui — niềm vui của một con người đi khám phá thế giới, chinh phục những thử thách, để rồi chia sẻ những câu chuyện hay ho với tất cả mọi người.
Mỗi ngày tôi đều dành thời gian đọc sách, làm bài tập, viết mã hoặc chứng minh một cái gì đó. Không ai bắt tôi phải làm những chuyện đó. Có những thứ tôi học cũng không (hoặc chưa) có liên quan gì đến công việc. Tôi học chỉ vì tôi thích và tò mò. Tôi học vì tôi muốn hiểu thêm những thứ mà tôi cho là hay ho. Tôi học vì tôi muốn đi mãi, đi mãi, đi đến tận cùng những cái mà người ta viết trong sách, để xem ở đó có gì hay không.
Hôm rồi tôi đọc một mẩu chuyện về Richard Feynman, trong đó có đoạn kể về lúc Feynman bị bệnh gần đất xa trời, ông tâm sự rằng, “[I’m going to die but I’m not as sad as you think because] when you get as old as I am, you start to realize that you’ve told most of the good stuff you know to other people anyway”. Đương nhiên những gì tôi biết làm sao mà “good” bằng những gì Feynman biết, nhưng dẫu sao thì tôi cũng sẽ học theo Feynman: có biết chuyện gì hay ho thì kể cho nhiều người khác cùng biết. Bài này là một chuyện như thế.
React Native Developer sẽ xây dựng ứng dụng React Native App trên nền tảng Android và iOS bằng ngôn ngữ JavaScript. Công việc của React Native Dev thường tập trung phần Front-end của sản phẩm, nhưng họ cũng rất giỏi trong việc tìm hiểu các dịch vụ và cơ sở hạ tầng API mà ứng dụng cần tích hợp. Hy vọng, Mẫu bảng mô tả công việc lập trình React Native 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.
Mẫu bảng công việc lập trình React Native Developer
YÊU CẦU CÔNG VIỆC
Có kinh nghiệp lập trình Native App hoặc Hyprid App
Thành thạo React Native
Nắm vững các khái niệm lập trình OOP, mô hình MVC
Có kiến thức về Multithreading, Data structures, Algorithm và Design pattern
Hiểu biết về API REST
Có khả năng thiết kế và tối ưu cơ sở dữ liệu cho ứng dụng có lượng truy cập lớn
Có tinh thần học hỏi và nâng cao trình độ bản thân
Khả năng làm việc trong môi trường nhóm
Kỹ năng tư duy logic và thuật toán tốt, phân tích và giải quyết vấn đề
MÔ TẢ CÔNG VIỆC
Tham gia thiết kế, xây dựng và triển khai ứng dụng mobile với React Native
Xây dựng giao diện người dùng mượt mà, hoàn hảo về độ phân giải trên cả hai nền tảng di động
Tối ưu native APIs để tích hợp chắc chẽ với các nên tảng
Liên tục tối ưu và nâng cấp mã nguồn để đảm bảo hiệu quả, ổn định và an toàn
Chuyển các ứng dụng web React hiện có sang React Native
Hoàn thành các dự án đúng tiến độ, chủ động học hỏi, nghiên cứu, tìm kiếm các công nghệ mới
Hỗ trợ, phối hợp với các bộ phận khác.
Tham khảo thêm những công việc lập trình hot nhất thị trường tại đây
Mô hình O2O với lợi thế không phát sinh chi phí cho vận chuyển, kho bãi và không cạnh tranh trực tiếp với hệ thống bán hàng đã và đang là lựa chọn thành công của nhiều công ty, đơn cử đó là chuỗi Dienmayxanh.com của Thế giới di động.
Con số thống kê khổng lồ của Google Analytics DMX về Dienmayxanh.com cho thấy năm vừa qua doanh thu online tăng 120% so với năm 2017, trong đó phải kể đến một vài con số đáng chú ý như tăng 15% lượng traffic, 96% conversion rate, tăng 6% average order value cho nhóm sản phẩm giá trị điện tử, điện lạnh.
Bật mí những bí kíp hiệu quả về traffic Dienmayxanh.com trong năm 2018!
Landing page: ‣ Before cứ có chương trình mới là làm Landing page (LDP), một thời điểm trên site có thể có 8 – 10 LDP, mỗi LDP lại chỉ có vài sản phẩm. Việc này làm tốn vị trí banner truyền thông, resource thiết kế, code ‣ After: Hạn chế làm LDP. Tối ưu UX trang ngành hàng và ưu tiên đẩy campaign traffic về trang Ngành hàng vì đây là trang có Best UX cho việc tìm sp (với Filter, Sort by…)
Web Push: dùng chọn lọc, không lạm dụng gây spam. Conversion rate từ kênh Web push tốt gần bằng kênh Direct (là kênh có best CR)
Follow trend: khi thị trường “đỏ lửa” thì mình cũng nhào vô ‣ Before: “Ngày đó là ngày của web XYZ mà, họ quảng cáo mạnh, deal ngon thế thì làm gì đến lượt mình bán. Tránh voi chẳng xấu mặt nào” ‣ After: ngày đó cứ chuẩn bị “đủ súng ống đạn dược” (deal ngon), nước lên thuyền lên, họ tăng số thì mình cũng sẽ tăng số dù ko quảng cáo ầm ĩ.
“Khi thị trường hành động, thì bạn cũng nên hành động, đừng dừng lại!”
Nhân tố quan trọng nhất khiến CR (Conversion rate) tăng 96%: Tối ưu tỷ lệ chuyển đổi mua hàng!
Có 3 tỉ lệ chuyển đổi cần quan tâm và tối ưu
CR1: Tăng tỉ lệ đơn hàng đầu vào: Làm sao để khách vào web quyết định mua: KPI team Product.
CR2: Tăng tỉ lệ chốt đơn hàng thành công của Call center: Vì sao khách đặt rồi hủy: KPI team Call center, Nâng cao CLDV.
CR3: Tăng tỉ lệ xuất thành công: Khách đồng ý mua rồi mà sao chưa xuất: KPI team Logistics, Kiểm soát vận hành online.
Năm qua, Điện máy xanh đã đóng góp lớn nhất vào tổng doanh thu của Thế Giới Di Động với 4.167 tỷ đồng, chiếm tỷ trọng 53%, tăng trưởng 28%. Chọn lựa mô hình kinh doanh O2O đã mang lại giá trị sự tiện lợi cho khách hàng của dienmayxanh.com (về cả thời gian và địa điểm mua hàng), tăng cơ hội bán hàng và nhanh chóng tiêu thụ các mặt hàng upsell, crossell.
Tuy nhiên, tốc độ tăng traffic và tỷ lệ chuyển đổi của Dienmayxanh.com có phải là toàn bộ bí quyết khiến con số x2 doanh thu duy trì mỗi năm? Một quy trình chính thống được Dienmayxanh.com áp dụng rất thành công, bạn có tò mò đứng sau những lý thuyết mọi người có thể dễ dàng tìm đọc trên sách vở là những “công thức” gì không?
Product Manager của Thế Giới Di Động – anh Tùng Jacob sẽ bật mí những thắc mắc còn tồn đọng khi bạn muốn tìm hiểu sâu hơn về mô hình O2O bằng case study Dienmayxanh.com sắp diễn ra tại Hồ Chí Minh vào ngày 24/09/2019 sắp tới!
Nhập code TOPDEVBLOG@2409 ưu đãi 50.000đ dành riêng cho thành viên TopDev tại đây!
“Build only what you need to build, and do it fast”
Với sự phát triển không ngừng của công nghệ, đâu đâu người ta cũng nhắc tới Cách mạng công nghiệp 4.0. Trong bối cảnh đó, Học máy (Machine Learning) đã trở thành một cái tên không còn xa lạ trong giới công nghiệp. Cùng với nhu cầu ngày càng nhiều của xã hội, một ngành mới được ra đời, Kĩ sư Học máy (Machine Learning Engineers).
Kĩ sư Học máy là người có cả kĩ năng về Học máy và Kĩ thuật phần mềm (Software Engineering). Một Kĩ sư Học máy có thể sử dụng các kĩ năng của mình để tìm ra những mô hình học máy có hiệu suất cao đem vào ứng dụng và cũng là người xử lý các vấn đề từ cơ sở hạ tầng phục vụ huấn luyện cho đến tạo ra mô hình áp dụng thực tế. Có kha khá nguồn tài liệu trên mạng để một Kỹ sư phần mềm hay bất cứ ai học về Học máy. Tuy nhiên, trong thực tế, một đội ngũ làm Học máy sẽ phải đối mặt với vấn đề: Làm sao để có thể quản lý các tiến trình của dự án như các dự án phần mềm truyền thống ? Sau đây là bài viết trả lời cho câu hỏi đó.
The ML Engineering Loop
Trong bài viết này, chúng mình sẽ cùng tìm hiểu về khái niệm “OODA Loop” của Học máy: ML Engineering Loop, với khái niệm này một Kỹ sư sẽ tuần tự theo các bước
Phân tích (Analyze)
Chọn phương pháp (Select an approach)
Thực thi (Implement)
Đo đạc (Measure)
để có thể tìm ra được mô hình học máy hiệu quả một cách nhanh chóng. Đối với mỗi giai đoạn sẽ có những lời khuyên mà tác giả nghĩ có thể hữu ích trong việc tối ưu toàn bộ quá trình.
Một đội ngũ ML thành công khi triển khai được mô hình có hiệu suất cao với những rằng buộc đã cho (ví dụ: đạt độ chính xác cao nhưng vẫn phải đảm bảo về bộ nhớ, thời gian chạy, etc). Hiệu suất (performance) được định nghĩa là đơn vị đo liên quan nhất tới thành công của sản phẩm cuối. Hiệu suất sẽ được dịch sang ngôn ngữ tương ứng của Học máy để quy về các độ đo. Trong ví dụ dưới đây, tác giả sẽ chọn “error rate” là đơn vị đo hiệu suất.
Khi mới bắt đầu, bạn nên định nghĩa ra tiêu chí như nào thì gọi là thành công. Dưới góc nhìn về sản phẩm, theo bạn, hiệu suất như thế nào thì bắt đầu gọi là hữu dụng? Ví dụ như hệ thống của bạn gợi ý ra 5 bài báo liên quan, ít nhất bao nhiêu trong số đó cần phải thực sự liên quan, và thế nào là liên quan ?
ML Engineering Loop sẽ giúp bạn định hình được quá trình phát triển, đơn giản hóa quá trình quyết định để có thể tập trung hơn vào bước tiếp theo. Khi đã quen dần với vòng lặp này, bạn sẽ có thể nhanh chóng luân phiên giữa phân tích và thực thi. Vòng lặp này còn hữu ích kể cả khi bạn đã là chuyên gia, bạn sẽ không bị ngợp hay mông lung khi mô hình không đáp ứng yêu cầu hay đột nhiên mục tiêu của nhóm thay đổi.
Bắt đầu nào
Để có thế “kích” vòng lặp, hãy bắt đầu từ một phiên bản đơn giản. Mục đích của việc “kích” này là để có 1 con số cho chúng ta đánh giá, làm cơ sở cho việc đánh giá sau này. Nó sẽ bao gồm các việc sau:
Chuẩn bị dữ liệu training, development và testing.
Áp dụng một mô hình đơn giản chạy được.
Ví dụ, có thể sử dụng các dữ liệu tương tự có sẵn từ một cuộc thi trên Kaggle cho huấn luyện tập train, dữ liệu thu thập tay cho tập development và test. Về mô hình có thể chọn hồi quy tuyến tính (logistic regression) với dữ liệu các pixel gốc hay chạy một mô hình đã huấn luyện sẵn (pre-trained network). Nên nhớ rằng, mục đích là chỉ cần chạy được, để khởi động cho vòng lặp.
Lời khuyên
Về tập test:
Vì mục đích là làm tốt trên tập test, vậy nên tập test cần phản ánh chính xác mục đích sản phẩm hay thương mại của dự án. Ví dụ khi bạn đang xây dựng 1 ứng dụng chẩn đoán tình trạng của da người qua ảnh selfie, bạn có thể train trên bất cứ dữ liệu nào, nhưng hãy đảm bảo dữ liệu test sẽ chứa những ảnh ánh sánh yếu, chất lượng kém như ảnh selfie.
Thay đổi tập test sẽ là thay đổi mục tiêu của nhóm, vậy nên nếu có thay đổi thì nên thay đổi sớm, và chỉ nên thay đổi khi có thay đổi về dự án, sản phẩm hay mục tiêu thương mại.
Tập test và development cần phải đủ lớn để dữ liệu không bị nhiễu, đủ chính xác cho mục đích đánh giá, so sánh các mô hình.
Cẩn thận với nhãn của dữ liệu, vì mỗi điểm dữ liệu sai sẽ tương ứng với một lỗi trong yêu cầu của sản phẩm (Product requirement)
Nên biết hiệu suất của người hoặc các hệ thống đã có trên tập test. Đó sẽ là một giới hạn trên “error rate” giúp bạn xác định hiệu suất tốt nhất có thể đạt được.
Đạt tới hiệu suất tương tự con người thường là mục tiêu dài hạn. Bởi cho đến cuối cùng, mục tiêu là tối ưu hiệu suất đến gần với chính con người nhất có thể.
Về tập development và train:
Tập development đại diện cho tập test, được sử dụng để điều chỉnh các siêu tham số (hyper-parameters). Như vậy, tập này cần có phân phối dữ liệu gần với tập test, nhưng không được giống hệt, cùng một nhóm người dùng, đầu vào. Có một cách hay được sử dụng đó là xáo dữ liệu lên rồi chia ra tập development và test (sao cho phân phối hai tập tương đương).
Nếu bạn nghĩ rằng dữ liệu sản phẩm có thể bị nhiễu, hãy xử lý nó ở tập train bằng các phép gia tăng (augmentation) và giảm chất lượng (degradation) dữ liệu. Không thế kì vọng mô hình chỉ học ảnh sắc nét mà lại đoán tốt trên ảnh mờ được.
Một khi đã có bản prototype, bạn có thể kiểm tra hiệu suất trên các tập dữ liệu. Đây cũng là bước cuối của vòng lặp. Đo đạc các biến động của khoảng cách giữa hiệu suất test và hiệu suất mong muốn đáp ứng tiêu chí hữu dụng của sản phẩm. Giờ là lúc bắt đầu vào chu trình của chúng mình.
Phân tích (Analyze)
Xác định “nút thắt cổ chai” (bottleneck)
Giai đoạn Phân tích cũng khá giống trong y học: Bạn được trang bị một số phương pháp chẩn đoán và mục tiêu là kết luận được cái gì đã giới hạn hiệu suất của mô hình. Tìm ra những vấn đề dễ dàng thấy được trước, hiểu được tác nhân nào có tác động lớn nhất tới vấn đề đó, bạn không cần phải cố gắng hiểu cũng như giải quyết tất cả các vấn đề, bởi rất nhiều vấn đề nhỏ sẽ thay đổi và thậm chí là biến mất khi mô hình được cải thiện.
Dưới đây là danh sách một số phương pháp cũng với chẩn đoán. Việc chọn ra phương pháp nào cũng là một nghệ thuật, sau khi áp dụng nhuần nhuyễn ML Engineering Loop bạn sẽ có được “trực giác” để biết mình nên thử cái nào.
Điểm bắt đầu của chúng mình có lẽ là để ý tới hiệu suất training, development và testing. Ở mỗi một chu trình, bạn nên thống kê các con số ở bước cuối cùng một cách tự động. Thông thường, training error ⩽⩽ development set error ⩽⩽ test set error
Phương pháp và chẩn đoán
Nếu training set error là nhân tố gây hạn chế hiệu suất, có thể do những vấn đề sau:
Thuật toán tối ưu không được hiệu chỉnh đúng. Nhìn vào learning curve để xem hàm loss có giảm không. Liệu mô hình có thể overfit một lượng dữ liệu nhỏ hơn không. Bạn có thể vẽ ra histogram của các phản hồi từ neuron để kiểm tra tính bão hòa (saturating)
Tập train có thể chứa dữ liệu đánh sai nhãn hoặc lỗi. Dò xét kĩ tập train trước khi đem vào mô hình để học.
Mô hình có thể quá bé. Ví dụ khi bạn dùng mô hình hồi quy tuyến tính cho bài toán phi tuyến tính, mô hình sẽ không tài nào học được. Khi đó ta nói mô hình high biashay underfitting
Nếu development set error là nhân tố đó, các vấn dề khá tương tự:
Mô hình có thể quá lớn, quá phức tạp. Khi đó ta nói mô hình high variance hay overfitting
Dữ liệu chưa đủ để học hết các pattern
Phân phối của tập train không giống với tập development và test
Các siêu tham số chưa hiệu quả. Nếu bạn đang sử dụng một số phương pháp để tìm các siêu tham số này, nhiều khi chính phương pháp đó thật sự không hiệu quả.
Thành phần encode đầu vào cho mô hình thực sự không phù hợp với dữ liệu.
Và nếu test set error là nhân tố hạn chế, thì thường lý do là tập development quá nhỏ hay các bạn đã overfitting trên tập development qua nhiều thí nghiệm.
Với bất kỳ lý do nào kể trên, bạn đều có thể phân tích tập những mẫu dữ liệu mà mô hình đã học sai để hiểu bản chất vấn đề (Nhưng tuyệt đối không nên làm với tập test nhé để tránh “huấn luyện” trên những mẫu này).
Xác định các lỗi phổ biến bằng cách biểu diễn trực quan dữ liệu (visualizing the data). Nắm được tần suất của các loại lỗi trên dữ liệu. Trong bài toán phân loại (classification) confusion matrix sẽ giúp dễ dàng xác định được những class mà mô hình học tệ nhất. Sau đó bạn có thể tập trung vào giải quyết các loại lỗi đó.
Một số mẫu có thể bị đánh nhãn sai hoặc có nhiều hơn một nhãn.
Một vài mẫu có thể khó học hơn cái khác, hoặc bị thiếu thông thông tin. Hãy đánh mác lại cho các mẫu dữ liệu, có dữ liệu sẽ là “rất khó” và có dữ liệu lại “rất dễ”, kiểm soát được điều này sẽ giúp bạn tối ưu hơn trong việc giải quyết lỗi nào trước.
Một số chẩn đoán nêu trên sẽ có các khắc phục hiển nhiên, ví dụ như thiếu dữ liệu thì sẽ lấy thêm. Tuy nhiên, việc chia tách giai đoạn phân tích và chọn phương pháp sẽ giúp bạn hiểu rõ bản chất, phân tích các lỗi với một tâm thế thoải mái hơn.
Tìm cách đơn giản nhất để giải quyết “nút thắt cổ chai”
Sau bước phân tích ở trên thì bạn đã hình dung được mình đang phải đối phó với những loại lỗi nào và tác nhân gây ra chúng rồi. Với một chẩn đoán, có thể sẽ có nhiều giải pháp khác nhau, bước tiếp theo chính là liệt kê và đánh giá độ ưu tiên cho chúng.
Tác giả khuyên rằng các Kĩ sư Học máy nên liệt kê ra càng nhiều ý tưởng càng tốt rồi bám theo những giải pháp đơn giản và nhanh. Nếu đã có sẵn một giải pháp có vẻ ổn thì dùng nó luôn. Có thể các phương pháp tinh vi, phức tạp sẽ cho kết quả tốt hơn, tuy nhiên qua thực tế tác giả thấy rằng sự cải thiện qua nhiều chu trình sẽ cho ra kết quả không tồi, hơn là chỉ chăm chăm sử dụng một giải pháp state-of-the-art, tốn khá nhiều thời gian. Giữa việc dán nhãn 1000 dữ liệu với nghiên cứu một phương pháp học không giám sát (unsupervised learning), mình nghĩ bạn nên thu thập và dán nhãn dữ liệu. Nếu như có một số heuristic đơn giản, bạn cũng nên thử chúng trước.
Lời khuyên
Phụ thuộc và chẩn đoán ma sẽ có một số giải pháp phổ biến như sau
Nếu bạn muốn hiệu chỉnh thuật toán để phù hợp dữ liệu hơn:
Thử điều chỉnh learning rate hay momentum. Bắt đầu với momentum nhỏ thôi (0.5).
Thử các chiến thuật khởi tạo khác nhau, hay bắt đầu với một mô hình pre-trained
Sử dụng mô hình phức tạp hơn. Ví dụ khi dùng Cây quyết định (Decision tree), bạn có thể làm cho cây sâu hơn chẳng hạn.
Kiểm tra các mẫu trong tập train mà mô hình cho kết quả sai. Đầu tư thời gian vào làm sạch dữ liệu.
Nếu mô hình không khái quát được tập development:
Thêm dữ liệu train. Chú ý thêm dữ liệu mà giống với loại lỗi trên tập developemnt.
Tăng dữ liệu bằng cách sử dụng các kĩ thuật khác nhau, ví dụ như trong xử lý ảnh có thể dùng OpenCV để thêm hiệu ứng sương mù cho ảnh, làm ảnh mờ đi.
Thử các siêu tham số ở một khoảng rộng hơn để đảm bảo tìm được mô hình với hiệu suất tốt nhất.
Thử các biến thể khác của regularization (như weight decay, dropout, pruning)
Thử một loại mô hình khác. Trong Deep learning thì việc thử các mô hình rất thuận tiện vì các mạng neural thường được dựng thành các “building block” dễ dàng sử dụng. Nếu bạn sử dụng các mô hình truyền thống thì phần lớn công việc sẽ là tìm cách thay mô hình. Nhưng dù sao vẫn nên nhớ rằng, thử cái nào dễ trước nhé.
Thực thi (Implement)
Dựng cái gì bạn cần và làm nó thật nhanh
Vậy là bạn đã biết mình cần phải thử cái gì, bạn cũng đã làm cho nó đơn giản nhất có thể rồi. Giờ CHỈ cần bắt tay vào implement thôi. Mục tiêu của giai đoạn này là để nhanh chóng thử ý tưởng của bạn để có thể đo đạc, học từ đó và quay lại chu trình nhanh chóng. Do vậy, bạn chỉ nên làm những thử thực sự cần thiết. Tuy là nhanh nhưng bạn vẫn phải đảm bảo code của mình đúng nhé, hãy kiểm tra thường xuyên.
Lời khuyên
Khi thu thập và dán nhãn dữ liệu:
Thường xuyên kiểm tra dữ liệu. Kiểm tra dữ liệu thô, dữ liệu sau khi xử lý và nhãn. Bạn có thể sẽ tìm ra rất nhiều lỗi bằng việc kiểm tra thường xuyên dữ liệu của bạn đó.
Dán nhãn và làm sạch dữ liệu là điều hết sức bình thường. Nhiều người khá ngại việc thu thập và dán nhãn dữ liệu, đánh giá thấp bài toán với ít dữ liệu. Khi đã vào guồng thì bạn hoàn toàn có thể dán nhãn 20 cái ảnh trong một phút đấy. Bạn muốn dành một tiếng dán nhãn và một tiếng giải bài toàn phân loại với dữ liệu gồm 1200 ảnh hay là dành 3 tuần để có một mô hình học từ 5 mẫu ?
Khi bạn code một mô hình mới. Hãy bắt đầu từ những code tương tự. Có rất nhiều bài báo có mã nguồn mở trên mạng. Việc này sẽ giúp bạn tiết kiệm khối thời gian. Tác giả gợi ý các bước thực thi như sau:
Tìm một mã nguồn đã giải quyết vấn đề tương tự
Chạy lại mã nguồn với cùng tập dữ liệu và các siêu tham số.
Từ từ hiệu chỉnh mô hình và luồn dữ liệu sao cho phù hợp với những gì bạn cần.
Viết lại những phần cần thiết.
Viết đoạn mã kiểm thử gradients, các giá trị của tensor, dữ liệu đầu vào và nhãn xem đúng quy định chưa. Làm điều này ngay từ đầu sẽ giúp bạn kiểm tra lỗi bất cứ khi nào.
Đo đạc (Measure)
In ra các kết quả cũng như các số liệu để tiện theo dõi.
Nếu hiệu suất tăng, bạn đang đi đúng đường. Bạn có thể làm sạch các thành phần (component) mà bạn đang làm và đảm bảo rằng thí nghiệm có thể thực hiện lại được bởi cách thành viên khác trong đội.
Ngược lại, khi hiệu suất không tăng đáng kể thậm chí có thể tệ hơn, bạn phải quyết định nên tiếp tục hay bỏ ý tưởng hiện tại đi. Bỏ đi là khá dễ nếu như mỗi chu trình trong ML Loop có chi phí rẻ: bạn không tốn quá nhiều công để làm code “hoàn hảo”, và một lần thử nữa cũng không quá lâu.
Lời khuyên
Các số liệu đo hiệu suất bao gồm: độ chính xác, loss bên ML và những giá trị thương mại. Trong đó, những giá trị thương mại là thứ quan trọng nhất, bởi nó quyết định tính hữu dụng của thứ bạn đang làm. Nếu số liệu test (tối ưu bởi các thuật toán Học máy) của bạn không phù hợp với số liệu thương mại thì đây là lúc thích hợp để thay đổi các tiêu chí tối ưu hay tập test.
Đây cũng là lúc bản có thể tính toán các số liệu khác cần thiết dựa trên những số liệu đang có. Điều này sẽ giúp ích ở giai đoạn phân tích hoặc để quyết định xem có nên dừng ý tưởng hiện tại không.
Thêm một điều nhỏ nữa, bạn hãy tạo ra một cái Dashboard cho các số liệu để quan sát sau mỗi thí nghiệm. Cái này đặc biệt hữu ích trong làm việc nhóm nhé.
Tối ưu vòng lặp
ML Engieering Loop sẽ giúp bạn hình dung rõ về quá trình để có được một mô hình tốt hơn. Đây không phải là một hướng dẫn chi tiết, bạn sẽ phải phát triển khả năng của bản thân để có thể đưa ra sự lựa chọn hợp lý ở mỗi gia đoạn. Bạn cần phải làm quen nhanh chóng với các chu trình này, tìm cách cải tiến vòng lặp về cả chất lượng và tốc độ để có thể tối đa hóa các quá trình ở mỗi chu trình và nhiều chu trình trong thời gian ngắn.
Lời khuyên
Nếu giai đoan phân tích đang chậm, viết script để tóm tắt các kết quả, thu thập lỗi từ tập train, dev và biểu diễn một cách dễ nhìn. Cái “dashboard” này cực kỳ hữu ích cũng như tiết kiệm thời gian.
Nếu bạn vẫn đang mông lung không biết nêu thử cái gì, chỉ cần chọn đại một cái. Thử nhiều thứ một lúc sẽ khiến bạn chậm hơn. Bạn vẫn có thể thử một cái khác khi thí nghiệm đang chạy cơ mà.
Thu thập dữ liệu là một cách phổ biển để đạt được hiệu suất tốt hơn. Nếu việc lấy nhiều dữ liệu thật sự khó khăn, hãy tạo thêm công cụ để có thể thu thập, làm sạch và dán nhãn dữ liệu, bạn sẽ nó rất đáng để đầu tư đấy.
Hãy tham khảo ý kiến của các chuyên gia. Các chuyên gia trong lĩnh vực mà bạn đang tiếp cận thường có những cái nhìn cực kỳ hữu ích trong quá trình phân tích lỗi, trong khi đó các bài báo hay những người làm Học Máy kinh nghiệm sẽ cho bạn những hướng giải quyết khá sáng tạo, đáng để bạn thử đó.
Kĩ năng code là quan trọng, code đẹp có thể tránh được bugs. Tuy nhiên, trong quá trình thử bạn sẽ phải cắt xén code khá nhiều. Hãy thoải mãi với việc đó, bạn có thể “vệ sinh” code trước vòng lặp tiếp theo.
Nếu các thử nghiệm diễn ra quá lâu, bạn nên xem xét tối ưu code. Hãy nhờ đến sự giúp đỡ của một chuyên gia hệ thống để giúp bạn huấn luyện nhanh hơn. Nâng cấp GPU hay chạy nhiều thí nghiệm song song cũng là giải pháp thường thấy.
Kết luận
Như vậy, bài viết đã đưa ra một cách tiếp cận cho các dự án Học máy. Nếu như bạn cảm thấy mông lung và không biết bắt đầu từ đâu, hãy bắt đầu phân tích các lỗi, lên ý tưởng giải quyết, code chúng và xem nó hoạt động ra sao. Không ngừng tập trung vào chu trình trên một cách liên tục có thể đem đến những kết quả không ngờ trong cả nghiên cứu và ứng dụng đấy.
Với bài viết này, TopDev sẽ cập nhật cho bạn 20 thách thức tuyển dụng nhân sự IT lớn nhất trong năm 2024. Không chỉ thế mà còn cung cấp giải pháp thiết thực nhất giúp công ty bạn giải quyết bất kì khó khăn nào trong tuyển dụng. Nào cùng bắt đầu nhé !
Thách thức tuyển dụng nhân sự IT 1: Xây dựng thương hiệu vững mạnh
Theo LinkedIn, 75% người tìm việc cho rằng thương hiệu tuyển dụng rất quan trọng trong quyết định nộp CV của họ. Nếu họ không thích, họ sẽ không ứng tuyển hay chấp nhận lời mời làm việc. Nếu công ty có tiếng xấu, 75% ứng viên sẽ không làm kể cả khi họ đang thất nghiệp.
Employer branding
Giải pháp
Cần làm gì?
Làm cách nào?
TopDev có thể giúp bạn thế nào?
Một chiến lược đẩy mạnh thương hiệu tuyển dụng hiệu quả.
Theo nghiên cứu của TopDev, có đến 25% ứng viên hài lòng hơn nếu có văn hóa công ty phù hợp.
=> Kể về những câu chuyện, văn hóa công ty hấp dẫn để khiến ứng viên hào hứng tham gia hơn.
– Tạo trang web, blog nghề nghiệp thật thu hút, thể hiện thương hiệu tuyển dụng, cho thấy công ty bạn là nơi tuyệt vời để làm việc.
-Thêm hình ảnh nhân viên và văn phòng, chia sẻ về dự án hay ho hay công nghệ mới mà công ty đang thực hiện.
TopDev có thể giúp chiến lược tuyển dụng của bạn hiệu quả hơn với Employer Branding Digital.
Tại đây, TopDev sẽ đăng các bài viết xây dựng thương hiệu lên Techtalk.vn – chuyên trang tin tức và thông tin công nghệ hàng đầu tại Việt Nam, và Blog TopDev.vn.
Thách thức tuyển dụng nhân sự IT 2: Khó giữ chân nhân tài
Thiếu hụt nhân tài là thách nhức tuyển dụng nhức nhối nhất hiện nay. Cụ thể, có tới 67,5% Nhân sự/ Nhà tuyển dụng gặp khó khăn trong việc “Tìm kiếm ứng viên có năng lực” cho vị trí họ tìm.
Giải pháp
Cần làm gì?
Làm cách nào?
TopDev có thể giúp bạn thế nào?
Không còn gì ngoài việc phải “gia nhập” trận chiến tìm kiếm nhân tài, cạnh tranh các công ty khác để “giựt” lấy nhân tài.
Khi mọi đối thủ đều cho thấy họ là nơi đáng để làm nhất, làm sao để công ty bạn khác biệt?
Hãy nhờ nhân viên giới thiệu – vì ứng viên tin tưởng bạn của họ hơn là nhà tuyển dụng.
Nếu môi trường tìm kiếm nhân tài quá khốc liệt, bạn có thể sử dụng Job Posting của TopDev.
Vì tất cả CV đều sàng lọc trước khi gửi nhà tuyển dụng, giúp bạn vừa tiết kiệm thời gian vừa gia tăng xác suất tìm được nhân tài!
Thách thức tuyển dụng nhân sự IT 3: Mở rộng phạm vi ứng viên
Vì sự thiếu hụt các ứng viên chất lượng, nhà tuyển dụng muốn tìm nhân tài phải nhìn “xa hơn” cộng đồng địa phương và mạng xã hội của nhân viên họ. Bằng mọi giá bạn phải tìm cách mở rộng phạm vi ứng viên để tìm ra nhân tố tìm ẩn.
Giải pháp
Cần làm gì?
Làm cách nào?
TopDev có thể giúp bạn thế nào?
Mở rộng sự hiện diện với nhiều kênh và nơi chốn nhất có thể.
=>Xây dựng chiến lược tuyển dụng đa kênh.
Đảm bảo vị trí ứng tuyển được quảng bá rộng khắp các phương tiện và khu vực, gồm website việc làm địa phương và toàn cầu ̣(cả miễn phí và tính phí). Quảng bá trên mạng xã hội, sự kiện, diễn đàn,..
Vào cuối năm, TopDev có tổ chức Vietnam Web Summit sự kiện công nghệ có quy mô lớn nhất hiện nay. Quy tụ phần lớn người làm công nghệ, từ sinh viên đến chuyên gia, các cấp quản lý trong các công ty công nghệ.
Đây là dịp để bạn quảng bá công ty cũng như tìm kiếm kha khá ứng viên tài năng đấy! Xem thêm về sự kiện năm ngoái Vietnam Web Summit
Hình ảnh về sự kiện của TopDev
Thách thức tuyển dụng nhân sự IT 4: Xu hướng làm việc từ xa/tự do gia tăng
Do tác động của dịch Covid-19, số lượng ứng viên tìm kiếm đến những công việc freelancer ngày càng nhiều. Hơn nữa, nhu cầu tuyển dụng IT cũng tăng trưởng mạnh mẽ từ các quốc gia trên thế giới và xu hướng tuyển các lập trình viên ở nước ngoài trở nên phổ biến. Điều này dẫn đến việc các lập trình viên ở Việt Nam có nhiều cơ hội lựa chọn hơn và phần nào có mong muốn cao hơn về mức lương và phúc lợi của các công ty trong nước.
Theo bài cáo thị trường IT mới nhất của TopDev, gần 75% các lập trình viên đang làm công việc toàn thời gian, thấp hơn con số đó trước năm 2021. Lý do không phải do thất nghiệp, mà bởi xu hướng làm việc từ xa (remote)/ tự do (freelance) gia tăng với nhiều cơ hội hơn từ các nước phát triển.
Giải pháp
Cần làm gì?
Làm cách nào?
TopDev có thể giúp bạn thế nào?
Các ứng viên mong muốn sự cân bằng trong công việc và cuộc sống vậy nên hãy tạo sự linh hoạt trong công việc cho họ đồng thời tăng phúc lợi để thu hút ứng viên.
Ứng viên sẽ quan tâm đến việc phát triển bản thân nên hãy tạo điều kiện cho nhân viên phát triển hết mức đồng thời hãy tạo một trường làm việc tích cực.
Sử dụng công nghệ tiên tiến để tăng tính cạnh tranh và thu hút các ứng viên có kỹ năng chuyên môn cao.
Giúp nhân viên linh hoạt trong việc lựa chọn giờ làm việc hoặc nơi làm việc, kết hợp với phần mềm quản lý dự án để giúp nhân viên có thể hoàn thành công việc từ xa.
Cung cấp các khóa đào tạo, chương trình học tập để nâng cao kỹ năng của nhân viên. Cho phép nhân viên tham gia các dự án, hoạt động khác nhau để phát triển kỹ năng và năng lực.
Sử dụng các công nghệ mới nhất trong việc quản lý dự án, giao tiếp và hợp tác nhóm. Tạo ra một môi trường làm việc công nghệ cao, cho phép nhân viên truy cập vào các công nghệ tiên tiến để hoàn thành công việc từ xa.
TopDev với nguồn ứng viên khổng lồ luôn sẵn sàng đáp ứng nhu cầu nhân lực của doanh nghiệp. Cùng với đó, ứng dụng công nghệ giúp doanh nghiệp tiết kiệm thời gian và chi phí khi tìm kiếm ứng viên phù hợp.
Thách thức tuyển dụng nhân sự IT 5: Thu hút đúng ứng viên
Theo Grassdoor, 76% nhà tuyển dụng cho rằng việc thu hút đúng ứng viên là thách thức lớn nhất. Họ mất nhiều thời gian xem hàng ngàn CV mà không phù hợp với vị trí họ cần.
Giải pháp
Cần làm gì?
Làm cách nào?
TopDev có thể giúp bạn thế nào?
-Lọc lại quá trình tuyển dụng, đảm bảo thu hút đúng người ngay từ bước đầu.
=>Khiến ứng viên phù hợp ứng tuyển ngay và không khuyến khích các thành phần còn lại ứng tuyển.
-Đưa ra yêu cầu công việc chính xác và rõ ràng trong mô tả công việc.
-Dùng blog việc làm thể hiện văn hóa công ty cũng như mỗi ngày làm việc tại văn phòng. Những ứng viên tiềm năng có thể tự quyết định tiếp tục ứng tuyển hoặc rút nếu thấy không phù hợp.
-Thêm vài câu hỏi điều kiện trong đơn ứng tuyển. Đơn giản nhưng hiệu quả để lượt bỏ trước ứng viên không phù hợp !
Nếu đã thử các cách trên nhưng vẫn chưa tìm được đúng nhân tài thì TopDev có dịch vụ Email Marketing do khách hàng cung cấp và TopDev biên tập, được TopDev gửi đến 7.500 đối tượng phù hợp với đối tượng mục tiêu mà khách hàng mong muốn.
Bạn có thể tiết kiệm kha khá thời gian và chi phí đấy !
Thách thức tuyển dụng nhân sự IT 6: Xây dựng Talent pools
Talent pools là danh sách dữ liệu các ứng viên có hứng thú với công ty bạn. Bằng việc xây dựng Talent pools, bạn có thể lấp các vị trí trống với ít thời gian hơn bởi bạn đã có sẵn ứng viên để chọn. Vấn đề? Làm sao để xây dựng Talen pools chất lượng cao?
Giải pháp
Cần làm gì?
Làm cách nào?
TopDev có thể giúp bạn thế nào?
-Mời ứng viên tiềm năng tham gia vào “mạng lưới nhân tài” của bạn.
=>Họ vừa biết thêm về công ty vừa cập nhật vị trí ứng tuyển.
-Tạo mẫu đơn ngắn và đơn giản vào “mạng lưới nhân tài”. Bạn có thể thêm “Hãy gia nhập với chúng tôi” với nhiều vị trí khác nhau.
Ví dụ: cuối bài blog, đầu trang web việc làm, bài đăng Facebook, LinkedIn,..
Nhờ vậy, bạn có thể tiếp cận ứng viên tiềm năng và khuyến khích họ tham gia.
TopDev có thể giúp bạn quảng bá “mạng lưới nhân tài với dịch vụ hiển thị banner cho TechTalk.vn – hơn 1 triệu lượt truy cập/tháng và Blog TopDev.vn – hơn 300.000 lượt truy cập/tháng.
Ngoài ra, TopDev còn tư vấn thiết kế và chọn lọc nội dung hiển thị phù hợp với hàng trăm mẫu giao diện linh hoạt cho từng công ty.
Thách thức tuyển dụng nhân sự IT 7: Nguồn nhân lực không đủ
Ứng viên tài năng vẫn đang ngoài kia. Nếu không có chiến lược tìm nguồn nhân tài hiệu quả, nhà tuyển dụng chỉ phí thời gian và công sức mà không được kết quả gì. Việc tìm ứng viên chất lượng và có thông tin liên hệ của họ thật sự khó khăn!
Giải pháp
Cần làm gì?
Làm cách nào?
TopDev có thể giúp bạn thế nào?
Áp dụng chiến lược tìm kiếm tân tiến và chủ động hơn.
Ngừng phí thời gian vào nguồn cung ứng thủ công
=>Đầu tư vào những công nghệ cung ứng mạnh mẽ.
Với dịch vụ Job Posting, TopDev có thể giúp bạn tiết kiệm rất nhiều thời gian và chi phí bằng việc tiếp cận đúng đối tượng ứng viên và mọi CV đều được sàng lọc kĩ càng trước khi gửi nhà tuyển dụng.
Thách thức tuyển dụng nhân sự IT 8: Trải nghiêm đáng nhớ của ứng viên
Theo Experience Study, có 60% người tìm việc có trải nghiệm không tốt. Dẫn đến một vài kết quả sau:
-63% ứng viên từ chối lời mời công việc. (Nguồn: Software Advice)
-72% ứng viên nói cho người khác biết về trải nghiệm xấu (online và trực tiếp). (Nguồn: CareerArc)
-64% ứng viên ngưng mua sản phẩm/dịch vụ từ công ty đó. (Nguồn: CareerArc)
Tóm lại, nếu không cải thiện trải nghiệm ứng viên, bạn sẽ đánh mất ứng viên tài năng, danh tiếng, khách hàng công ty bạn.
Giải pháp
Cần làm gì?
Làm cách nào?
-Kiểm tra hiện trạng trải nghiệm của nhân viên.
-Thực hiện các bước cần thiết để cải thiện trải nghiệm ứng viên.
Liên tục cập nhật thông tin cho ứng viên trong từng giai đoạn của quá trình tuyển dụng.
=>Gia tăng thiện cảm và uy tín trong mắt ứng viên.
Thách thức tuyển dụng nhân sự IT 9: Tham gia với ứng viên chủ động và bị động
Tham gia với ứng viên liên tục là chìa khóa để tuyển dụng thành công trong 2024. Đây là quá trình giao tiếp liên tục với ứng viên của bạn. Mục tiêu là khiến họ hứng thú làm việc cho công ty và giữ chân họ tới khi có cơ hội làm việc xuất hiện.
Giải pháp
Cần làm gì?
Làm cách nào?
TopDev có thể giúp bạn thế nào?
-Tạo ra chiến lược dài hạn hiệu quả để thu hút ứng viên chủ động và bị động.
-Truyền tải đúng thông điệp cho đúng người vào đúng thời điểm.
-Tham gia với ứng viên chủ động và bị động thông qua tất cả các kênh.
-Trả lời bình luận và tin nhắn qua mạng xã hội, gửi email chiến dịch tuyển dụng và mời họ tham gia.
Với dịch vụ Đồng tô chức Tech Event, TopDev sẽ giúp bạn tạo môi trường tương tác giữa công ty và ứng viên tài năng ngay tại sự kiện.
Ngoài ra TopDev còn có truyền thông online trước sự kiện, kêu gọi nhiều ứng viên tham gia hơn.
Thách thức tuyển dụng nhân sự IT 10: Tuyển dụng cho sự đa dạng và hòa nhập
Đây là vấn đề ưu tiên hàng đầu trong năm 2024. Theo LinkedIn, 78% nhà tuyển dụng cho rằng đa dạng là xu hướng chính ảnh hưởng việc tuyển dụng của họ. 67% ứng viên cho rằng họ sẽ cân nhắc hơn nếu có một nguồn lực phong phú.
Giải pháp
Cần làm gì?
Làm cách nào?
TopDev có thể giúp bạn thế nào?
Triển khai chiến lược tuyển dụng tập trung vào tìm kiếm, thu hút và tuyển ứng viên đa dạng.
-Đăng tuyển công việc trên nhiều trang web việc làm đa dạng như Diversity Working. Cho thấy rõ công ty bạn đề cao sự đa dạng.
-Sử dụng trang web việc làm, mạng xã hội để đưa ra các trích dẫn, hình ảnh, video tự sự từ các nhân viên…
-Xây dựng mô hình phỏng vấn có cấu trúc để tuyển dụng công bằng, khách quan.
Với Employer Branding Digital, TopDev giúp bạn xây dựng thương hiệu qua bài viết trên Techtalk.vn và Blog TopDev.vn.
Quan trọng là tên thương hiệu được nhắc đến tự nhiên, khéo léo, không PR lộ liễu.
Còn tiếp….
Nếu còn gì chưa rõ, ấn vào đây và đội ngũ TopDev sẽ giúp bạn giải đáp mọi thắc mắc !
“Cung không đủ cầu” nhân lực do vốn đầu tư nước ngoài tăng mạnh, cạnh tranh ở những ngành Tài chính
“Năm ngoái, tỷ lệ nghỉ việc ở công ty chúng tôi khoảng 30%”, ông Nguyễn Công Ái – Phó tổng giám đốc KPMG Việt Nam kể lại. Những nhân tài rời đi, theo ông là được mời về các công ty gọi xe và thương mại điện tử, Fintech… vốn đang đầu tư vào Việt Nam.
Tất nhiên, ở vị thế trong nhóm Big4, công ty cũng thu hút ngược lại nhân tài từ nơi khác về. Nhưng tình hình cạnh tranh nhân sự trong giới công nghệ đang khá cao, dù KPMG vốn không phải công ty công nghệ mà chuyên về kiểm toán, tư vấn.
Do có nhiều khách hàng là công ty công nghệ nên đội ngũ của KPMG dễ dàng được nơi khác ‘mời mọc’. Với những người ở lại, công việc lúc nào cũng nhiều. “Chúng tôi chưa bao giờ bận rộn như năm nay. Nhân viên làm 12 giờ mỗi ngày vẫn không đủ để phục vụ cho khách hàng đến từ Hàn Quốc, Nhật Bản và trong nước”, ông Ái nói.
Ông Nguyễn Hữu Bình – CEO TopDev cho biết, làn sóng khởi nghiệp công nghệ cũng như việc gia tăng thêm các dự án R&D tại các tập đoàn lớn đang khiến cơn khát nhân sự IT lên cao, nhất là nhân sự chất lượng. Kể về lý do ra Quy Nhơn để xây một công viên đổi mới sáng tạo, ông Nguyễn Hữu Lệ – Chủ tịch TMA Solutions nói phải ‘can đảm’ về miền Trung để tìm thêm người.
Nhu cầu tuyển dụng ngành IT năm 2019 tăng mạnh hơn bao giờ hết
Đại diện KPMG nhận định, các tên tuổi điện tử nước ngoài lớn như Samsung, LG, Intel… đều mở rộng đầu tư vào Việt Nam những năm gần đây. Một số ‘đại gia’ khác cũng đang tìm hiểu đầu tư nhưng chưa thể tiết lộ. Ngày càng nhiều dự án đòi hỏi nguồn nhân sự IT chất lượng.
“Nissan đang có 2.000 kỹ sư làm việc tại Hà Nội, chịu trách nhiệm thiết kế phần lớn cho xe Nissan. Từ đây cũng thấy, cuộc cạnh tranh nhân lực là rất cao”, ông Ái nêu ví dụ.
Thu nhập cao không còn là yếu tố duy nhất “giữ chân” nhân tài
Theo báo cáo gần đây của TopDev, dù các trường đại học 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 đỏ, việc tuyển dụng nhân sự IT vẫn còn gặp nhiều khó khăn.
Mỗi tháng mức lương trung bình đa phần các nhà tuyển dụng sẵn sàng trả cho lập trình viên có kinh nghiệm khoảng hơn 30 triệu đồng, tỷ lệ tăng lương 6 tháng đầu năm 2019 đạt 15-18%. Với các cấp quản lý, con số này không thấp hơn 35 triệu đồng mỗi 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.
“Chúng ta có nhân tài nhưng đại học không đào tạo đủ chất lượng thì những người trung bình khó chuyển lên thành người giỏi. Chúng ta biết, nhân tài chỉ chiếm 1% và thậm chí thấp hơn”, ông Nguyễn Bá Quỳnh – Tổng giám đốc Global CyberSoft nhận xét.
Ông Bình xác nhận, do thiếu người nên các lập trình viên đều hiểu rõ giá trị bản thân. “Giữ chân nhân sự thực sự làm đau đầu nhiều doanh nghiệp”, ông nói.
Theo ông Ái, với những người giỏi, bổng lộc cao chưa chắc đủ giữ họ. “Họ đánh giá cao môi trường công việc và có nhiều dự án thú vị, chứ không phải lương. Do đó, cuộc cạnh tranh là nơi đâu có nhiều dự án hấp dẫn, nên đôi khi, đối thủ của chúng ta là các startup”, ông Ái bình luận.
Top các yếu tố khiến lập trình viên hài lòng với công việc
Trong mùa tuyển sinh năm 2019, ngành công nghệ thông tin “soán ngôi” đầu khi vượt qua điểm chuẩn các ngành y, dược. Điểm chuẩn cao nhất nước thuộc về ngành Công nghệ thông tin – Khoa học máy tính của Đại học Bách khoa Hà Nội với 27,42 điểm, vượt ngành Y đa khoa (26,75 điểm) của Đại học Y Hà Nội.
Nhiều chuyên gia cho rằng, với xu hướng số hóa doanh nghiệp trong những năm qua, số thí sinh lựa chọn ngành công nghệ thông tin nhiều, kéo theo điểm chuẩn tăng cao là điều không nằm ngoài dự đoán. Nhưng đó chỉ mới là bước đầu, giới công nghệ kỳ vọng, những học sinh giỏi này sẽ được đào tạo thành những chuyên gia giỏi, để sớm “giải khát” nhân tài cho ngành.
“Vai trò của đại học bây giờ cực kỳ quan trọng. Nhưng cuối cùng, người giỏi mình có vẫn không đủ”, ông Nguyễn Quốc Hùng là người đồng sáng lập công ty LogiGear, bình luận.
Hôm nay, chúng ta sẽ học TypeScript, một ngôn ngữ được biên dịch thành JavaScript, được thiết kế để xây dựng các ứng dụng lớn và phức tạp. Nó kế thừa nhiều khái niệm từ các ngôn ngữ như C# và Java, những ngôn ngữ nghiêm ngặt và có trật tự trái ngược với sự thoải mái và free-typed của JavaScriptt.Bài viết này, hướng đến những người đã khá thành thạo JavaScript nhưng vẫn còn là beginner khi đến với TypeScript. Chúng tôi sẽ đề cập hầu hết các tính năng chính và cơ bản bao gồm nhiều ví dụ với chú thích để giúp bạn thấy cách ngôn ngữ này hoạt động. Hãy bắt đầu học TypeScript cùng TopDev ngay!
Lợi thế của việc sử dụng TypeScript
JavaScript đã đủ tốt và bạn có thể tự hỏi: Liệu tôi có thực sự cần học TypeScript? Về mặt kỹ thuật, bạn không cần học TypeScript để trở thành một lập trình viên giỏi, hầu hết mọi người đều ổn mà không có nó. Tuy nhiên, làm việc với TypeScript có một số lợi thế sau:
Với static typing, code viết bằng TypeScript dễ dự đoán hơn, và dễ debug hơn.
Dễ dàng tổ chức code cho các ứng dụng cực lớn và phức tạp nhờ modules, namespaces và hỗ trợ OOP mạnh mẽ.
TypeScript có một bước biên dịch thành JavaScript, sẽ bắt tất cả các loại lỗi trước khi chúng chạy và làm hỏng một vài thứ.
Framework Angular 2 viết với TypeScript và nó cũng khuyến khích các lập trình viên sử dụng ngôn ngữ này trong các dự án của họ.
Lợi ích cuối cùng, thực sự là lý do quan trọng nhất với nhiều người để tìm hiểu TypeScript. Angular 2 là một trong những framework khá hot ngay lúc này và mặc dù các lập trình viên có thể sử dụng JavaScript, nhưng phần lớn các bài hướng dẫn và ví dụ được viết bằng TypeScript. Khi cộng đồng của Angular 2 được mở rộng, tự nhiên sẽ ngày càng có nhiều người sử dụng TypeScipt.
Mức độ phổ biến của TypeScript tăng lên trong thời gian gần đây, dữ liệu từ Google Trends
Dưới đây là các kiến thức TypeScript cơ bản mà các lập trình viên nên biết khi mới bắt đầu học lập trình TypeScript.
Các Text Editor hỗ trợ TypeScript
TypeScript là một dự án mã nguồn mở nhưng được phát triển và duy trì bởi Microsoft và vì vậy nó được hỗ trợ sẵn trong nền tảng Visual Studio của Microsoft.
Hiện nay, rất nhiều text editor và IDE hỗ trợ sẵn hoặc thông qua các plugin để hỗ trợ cú pháp của TypeScript, auto-complete suggestions, bắt lỗi và thậm chí tích hợp sẵn trình biên dịch.
Visual Studio Code – Một trình soạn thảo mã nguồn mở của Microsoft. Hỗ trợ sẵn TypeScipt.
Plugin cho Sublime Text
Phiên bản mới nhất của WebStorm cũng hỗ trợ TypeScipt
Và nhiều trình soạn thảo khác như Vim, Atom, Emacs …
Type (kiểu dữ liệu) trong TypeScript
Một tính năng rất đặc biệt của TypeScript là hỗ trợ static typing. Điều này có nghĩa là bạn có thể khai báo kiểu cho biến, và trình biên dịch sẽ đảm bảo rằng chúng không bị gán sai kiểu của các giá trị. Nếu khai báo kiểu bị bỏ qua, chúng sẽ được tự động phát hiện từ code của bạn.
Đây là một ví dụ. Mọi biến, tham số của hàm hoặc giá trị trả lại có thể có các kiểu được định nghĩa khi khởi tạo:
var burger: string = 'hamburger', // String
calories: number = 300, // Numeric
tasty: boolean = true; // Boolean
// Alternatively, you can omit the type declaration:
// var burger = 'hamburger';
// The function expects a string and an integer.
// It doesn't return anything so the type of the function itself is void.
function speak(food: string, energy: number): void {
console.log("Our " + food + " has " + energy + " calories.");
}
speak(burger, calories);
Khi TypeScript được biên dịch thành JavaScript, toàn bộ khai báo kiểu sẽ bị xóa:
// JavaScript code from the above TS example.
var burger = 'hamburger',
calories = 300,
tasty = true;
function speak(food, energy) {
console.log("Our " + food + " has " + energy + " calories.");
}
speak(burger, calories);
Nếu chúng ta thử làm một điều gì đó không hợp lệ, khi biên dịch tsc sẽ báo lỗi. Ví dụ:
// The given type is boolean, the provided value is a string.
var tasty: boolean = "I haven't tried it yet";
main.ts(1,5): error TS2322: Type 'string' is not assignable to type 'boolean'.
Nó cũng cảnh báo khi chúng ta truyền sai tham số tới một hàm:
function speak(food: string, energy: number): void{
console.log("Our " + food + " has " + energy + " calories.");
}
// Arguments don't match the function parameters.
speak("tripple cheesburger", "a ton of");
main.ts(5,30): error TS2345: Argument of type 'string' is not assignable to parameter of type 'number'.
Đây là một vài kiểu dữ liệu được sử dụng phổ biến nhất:
Number – Tất cả giá trị số được biểu diễn bởi kiểu number, không có định nghĩa riêng cho số nguyên (interger), số thực (float) hoặc các kiểu khác.
String – Giống như string của JavaScript có thể được bao quanh bởi ‘dấu nháy đơn’ hoặc “dấu nháy kép”.
Boolean – true hoặc false, sử dụng 0 và 1 sẽ gây ra lỗi biên dịch.
Any – Một biến với kiểu này có thể có giá trị là một string, number hoặc bất kỳ kiểu nào.
Arrays – Có 2 kiểu cú pháp: my_arr: number[]; hoặc my_arr: Array<number>.
Void – Được sử dụng khi hàm không trả lại bất kỳ giá trị nào.
Để xem danh sách tất cả các kiểu biến, đọc tài liệu hướng dẫn của TypeScript tại đây:
Interfaces được sử dụng để kiểm tra, xem một đối tượng có phù hợp với một cấu trúc nhất định hay không. Bằng cách định nghĩa một interface, chúng ta có thể đặt tên một sự kết hợp đặc biệt của các biến, đảm bảo rằng chúng luôn luôn đi cùng nhau.
Khi chuyển thành JavaScript, interface biến mất – mục đích duy nhất của chúng là trợ giúp trong giai đoạn giai đoạn phát triển.
Trong ví dụ dưới đây chúng ta định nghĩa một interface đơn giản để kiểm tra kiểu các tham số của một hàm:
// Here we define our Food interface, its properties, and their types.
interface Food {
name: string;
calories: number;
}
// We tell our function to expect an object that fulfills the Food interface.
// This way we know that the properties we need will always be available.
function speak(food: Food): void{
console.log("Our " + food.name + " has " + food.calories + " calories.");
}
// We define an object that has all of the properties the Food interface expects.
// Notice that types will be inferred automatically.
var ice_cream = {
name: "ice cream",
calories: 200
}
speak(ice_cream);
Thứ tự các thuộc tính không quan trọng. Chúng ta chỉ cần đủ số lượng các thuộc tính và đúng kiểu. Nếu một thuộc tính nào đó bị thiếu, hoặc sai kiểu, hoặc sai tên, trình biên dịch sẽ cảnh báo chúng ta.
interface Food {
name: string;
calories: number;
}
function speak(food: Food): void{
console.log("Our " + food.name + " has " + food.calories + " grams.");
}
// We've made a deliberate mistake and name is misspelled as nmae.
var ice_cream = {
nmae: "ice cream",
calories: 200
}
speak(ice_cream);
main.ts(16,7): error TS2345: Argument of type '{ nmae: string; calories: number; }
is not assignable to parameter of type 'Food'.
Property 'name' is missing in type '{ nmae: string; calories: number; }'.
Hướng dẫn này chỉ là bắt đầu, chúng ta sẽ không đi vào chi tiết. Tuy nhiên, còn nhiều thứ so với những gì mà chúng tôi đã đề cập, vì thế chúng tôi khuyến khích đọc thêm tài liệu của TypeScript ở đây.
Classes
Khi xây dựng các ứng dụng lớn, phong cách lập trình hướng đối tượng được ưa thích bởi rất nhiều lập trình viên, đặc biệt là trong các ngôn ngữ như Java hoặc C#.
TypeScript cung một hệ thống class rất giống các ngôn ngữ này, bao gồm kế thừa, abstract classes, interface implementations, setter/getters, …
Cũng phải đề cập là từ phiên bản ECMAScript 2015, classes là một tính năng có sẵn trong JS và có thể không cần sử dụng TypeScript. Hai phiên bản khá giống nhau, nhưng chúng vẫn có điểm khác biệt, đó là TypeScript nghiêm ngặt hơn.
Đây là một ví dụ đơn giản về TypeScript:
class Menu {
// Our properties:
// By default they are public, but can also be private or protected.
items: Array<string>; // The items in the menu, an array of strings.
pages: number; // How many pages will the menu be, a number.
// A straightforward constructor.
constructor(item_list: Array<string>, total_pages: number) {
// The this keyword is mandatory.
this.items = item_list;
this.pages = total_pages;
}
// Methods
list(): void {
console.log("Our menu for today:");
for(var i=0; i<this.items.length; i++) {
console.log(this.items[i]);
}
}
}
// Create a new instance of the Menu class.
var sundayMenu = new Menu(["pancakes","waffles","orange juice"], 1);
// Call the list method.
sundayMenu.list();
Bất kỳ ai đã biết một chút về Java hoặc C# sẽ thấy cú pháp này khá quen thuộc. Tương tự cho kế thừa:
class HappyMeal extends Menu {
// Properties are inherited
// A new constructor has to be defined.
constructor(item_list: Array<string>, total_pages: number) {
// In this case we want the exact same constructor as the parent class (Menu),
// To automatically copy it we can call super() - a reference to the parent's constructor.
super(item_list, total_pages);
}
// Just like the properties, methods are inherited from the parent.
// However, we want to override the list() function so we redefine it.
list(): void{
console.log("Our special menu for children:");
for(var i=0; i<this.items.length; i++) {
console.log(this.items[i]);
}
}
}
// Create a new instance of the HappyMeal class.
var menu_for_children = new HappyMeal(["candy","drink","toy"], 1);
// This time the log message will begin with the special introduction.
menu_for_children.list();
Để tìm hiểu sâu hơn về classes trong TS bạn có thể đọc ở đây.
Generics
Generics là các mẫu cho phép cùng một hàm có thể chấp nhận các tham số với nhiều kiểu khác nhau. Việc tạo ra các thành phần có thể tái sử dụng với generics tốt hơn sử dụng kiểu any, vì generics bảo tồn kiểu của các biến vào và ra của chúng.
Ví dụ dưới đây nhận một tham số và trả lại một mảng chứa cùng tham số
// The <T> after the function name symbolizes that it's a generic function.
// When we call the function, every instance of T will be replaced with the actual provided type.
// Receives one argument of type T,
// Returns an array of type T.
function genericFunc<T>(argument: T): T[] {
var arrayOfT: T[] = []; // Create empty array of type T.
arrayOfT.push(argument); // Push, now arrayOfT = [argument].
return arrayOfT;
}
var arrayFromString = genericFunc<string>("beep");
console.log(arrayFromString[0]); // "beep"
console.log(typeof arrayFromString[0]) // String
var arrayFromNumber = genericFunc(42);
console.log(arrayFromNumber[0]); // 42
console.log(typeof arrayFromNumber[0]) // number
Lần đầu tiên gọi hàm chúng ta thiết lập kiểu thành string. Điều này không bắt buộc vì trình biên dịch có thể xem tham số được truyền và tự động quyết định kiểu nào phù hợp nhất, giống như lần gọi hàm thứ 2.
Mặc dù không bắt buộc, luôn luôn cung cấp kiểu được coi là cần thiết vì trình biên dịch có thể đoán sai kiểu trong các kịch bản phức tạp.
Tài liệu hướng dẫn của TypeScript bao gồm một vài ví dụ cao cấp bao gồm generics classes, kết hợp chúng với interfaces, …Bạn có thể tìm thấy chúng ở đây.
Modules
Một khái niệm quan trọng, khi làm việc trên một ứng dụng lớn là tính module hóa. Chia code thành nhiều thành phần nhỏ có khả năng tái sử dụng giúp dự án của bạn dễ tổ chức và dễ hiểu, khi so sánh với một file duy nhất có 10000 dòng code.
TypeScript giới thiệu một cú pháp để exporting và importing các module, nhưng không thể xử lý thực sự việc liên kết giữa các file. Để cho phép modules TS dựa trên các thư viện của bên thứ ba: require.js cho các ứng dụng client và CommonJS cho Node.js. Hãy xem một ví dụ đơn giản với require.js:
Chúng ta có 2 file. Một file export một hàm, file còn lại import và gọi nó.
Bây giờ chúng ta cần download require.js và thêm nó trong một thẻ script – xem hướng dẫn ở đây. Bước cuối cùng là biên dịch 2 file .ts. Mộ tham số mở rộng cần được thêm vào để nói với TypeScript chúng ta đang xây dựng các module cho require.js (còn được gọi là AMD):
tsc --module amd *.ts
Modules khá phức tạp và nằm ngoài phạm vi của bài hướng dẫn này. Nếu bạn muốn đọc thêm về chúng, hãy xem trong tài liệu hướng dẫn của TS ở đây.
Function – Hàm
Trong Javascript, các function được xem như là Object, điều này có nghĩa là bạn có thể thao tác với chúng giống như khi làm việc với Object. Ví dụ, bạn có thể gán một function vào một biến, truyền function vào một function khác, hoặc một function có thể trả về một function khác.
TypeScript đã mô hình hóa tất cả những điều này bằng hệ thống kiểu mà tôi đã trình bày trong phần trước của bài viết.
Ví dụ về một function được định nghĩa trong TypeScript như sau:
functionadd(x: number, y: number): number {
return x + y;
}
letresult: number = add(5, 10); // result sẽ bằng 15
Cũng có thể khai báo hàm kiểu mũi tên (arrow function):
const multiply = (x: number, y: number): number => x * y;
Các file khai báo của bên thứ 3
Khi sử dụng một thư viện được thiết kế cho JavaScript, chúng ta cần áp dụng một file khai báo để làm cho thư viện đó tương thích với TypeScript. Một file khai báo có phần mở rộng là .d.ts và chứa nhiều thông tin về thư viện và API của nó.
Các file khai báo của TypeScript thường được viết bằng tay, nhưng nhiều khả năng thư viện bạn cần đã có sẵn một file .d.ts do một ai đó tạo ra. Definitely Typed là repo (kho) lớn nhất, chứa các file khai báo cho hàng nghìn thư viện. Cũng có một module Node.js được sử dụng phổ biến để quản lý các file khai báo TypeScript là Typings.
Nếu bạn vẫn cần phải tự viết một file khai báo, hướng dẫn này sẽ giúp bạn bắt đầu.
Hướng dẫn biên dịch sang từ TypeScript sang JavaScript
TypeScript được viết trong các file .ts (hoặc .tsx cho JSX), nó không thể sử dụng trực tiếp trong trình duyệt và cần biên dịch thành JavaScript. Điều này có thể thực hiện với một số cách:
Sử dụng các task runner như Gulp
Trực tiếp trong Visual Studio hoặc các IDE và trình soạn thảo khác
Trong terminal sử dụng lệnh tsc
Đối với Newbie chúng nên bắt đầu từ cách dễ nhất:
Câu lệnh sau sẽ nhận một file TypeScipt là main.ts và chuyển nó thành JavaScipt main.js. Nếu main.js đã tồn tại nó sẽ bị ghi đè:
tsc main.ts
Trong cùng 1 thời điểm, chúng ta có thể biên dịch nhiều file bằng cách liệt kê chúng hoặc áp dụng các wildcard:
# Will result in separate .js files: main.js worker.js.
tsc main.ts worker.ts
# Compiles all .ts files in the current folder. Does NOT work recursively.
tsc *.ts
Chúng ta cũng có thể sử dụng tùy chọn –watch để tự động biên dịch một file TypeScript khi có thay đổi:
# Initializes a watcher process that will keep main.js up to date.
tsc main.ts --watch
Một file tsconfig.json chứa nhiều thiết lập đôi khi cũng được viết bởi các TypeScript giàu kinh nghiệm. Các file như thế rất tiện lợi khi làm việc trên các dự án lớn có nhiều file .ts, nó hỗ trợ tự động hóa một phần tiến trình.
Tài liệu tham khảo:
Lượng thông tin trong tài liệu hướng dẫn của TypeScript có thể quá tải khi mới bắt đầu, nhưng lợi ích về lâu dài là rất lớn. Hướng dẫn của chúng tôi được sử dụng như phần giới thiệu, tiếp tục theo dõi TopDev để học thêm về TypeScript mỗi ngày bạn nhé!
UX thì vô cùng quan trọng trong việc lôi kéo khách hàng quay trở lại website, hẳn bạn sẽ không bao giờ quay trở lại 1 trang web mà chờ hết thanh xuân cũng không load ra cho bạn cái nội dung cần thiết. Đối với website hình ảnh là thứ vô cùng quan trọng. Nó có ở hầu hết mọi nơi từ Logo, Banner, Product Image…
Thật không vui khi mà ngày nay thì ảnh có dung lượng ngày 1 lớn hơn tỉ lệ thuận với chất lượng hình ảnh đi kèm. Theo như thống kê của HTTP Archive’s State of Images report. Page size trung bình thường là 1511KB trong đó Images chiếm lên đến 45% (650KB). Vì vậy số lượng ảnh đương nhiên có ảnh hưởng lớn đến việc load trang. Éo le thay chúng ta không thể vứt bớt ảnh đi được.Lúc này chúng ta sẽ nghĩ ngay đến kĩ thuật Lazy Loading Images.
1. Lazy Loading là gì?
Lazy Loading(Lười tải, Tải chậm) hiểu nôm na thì nó là việc load dữ liệu khi cần sử dụng đến chúng.Chẳng hạn nhiều người dùng khi vào 1 page còn chẳng kéo xuống hết đến cuối trang để xem toàn bộ nội dung thì ta cần gì load toàn bộ nội dung trước?Việc ta nên làm là người dùng scroll đến đâu ta sẽ load dữ liệu đến đấy.Lazy Loading có thể áp dụng cho bất cứ resource nào trên 1 page,thậm chí là file JavaScript . Giờ thì chúng ta tập trung vào việc Lazy Loanding Images(load images khi thật sự cần).
2. Tại sao nên áp dụng
Lazy loading giảm việc tải dữ liệu => Tốc độc load trang nhanh hơn và giảm chí phí (bằng cách giảm tổng số bytes transferred)
3. Lazy Loading Images
Có 2 cách phổ biến để load Image trên 1 page đó là sử dụng thẻ <img> , sử dụng thuộc tính background-image của CSS.
Lazy Loading Images qua thẻ Img
Thẻ <img/> với đinh dạng cơ bản:
<img src="/path/to/some/image.jpg" />
Như đã biết trình duyệt đọc src attribute để trigger đến việc tải ảnh. Nên chúng ta sẽ move link image qua 1 attribute khác để ngăn chặn việc tải ảnh này. Dưới đây là 1 VD sử dụng data-src attribute , bạn hoàn toàn có thể đặt bất cứ tên attr nào mà bạn muốn.
Sau khi ngăn chặn được việc load Images tức thời thì chúng ta cũng cần thông báo cho trình duyệt biết khi nào cần load Images lên. Lúc này ta sẽ sử dụng Javascript để bắt sự kiện của người dùng và add link từ data-src vào lại attr src.
Lazy Loading Images qua thuộc tính background-image
Với background-image , trình duyệt sẽ xây dựng cây DOM kèm theo CSSDOM và check xem kiểu CSS có áp dụng cho nút DOM hiện tại không. Nếu DOM hiện tại có background-image thì trình duyệt sẽ load Image. Tương tự như src attr , trước tiên ta sẽ set cho DOM có giá trị background-image: none sau đó sẽ change giá trị khi cần thiết.
Đương nhiên ta không thể thiếu class để trigger đến đối tượng thông qua JavaScript cho cả 2 trường hợp trên.
3. Ứng dụng
Sau khi hiểu bản chất của Lazy Loading Images và cơ chế hoạt động của nó, giờ việc của chúng ta là tìm 1 vài thư viện có sẵn và tích hợp vào project( vì không nên chế tạo lại chiếc bánh xe ) ) Dưới đây là 1 vài thư viện phổ biến
JQuery-Lazy : Thư viện hỗ trợ lazy load phổ biến được viết bằng JQuery.
Lazysizes : Đây là một thư viện rất phổ biến với chức năng mở rộng. Nó bao gồm hỗ trợ cho các attr srcset và size cho việc responsive kèm theo.
Các bạn có thể click vào mấy link trên và đọc hướng dẫn sử dụng để áp dụng ) .Rất dễ để dùng )
4. Testing Lazy Load
Khi đã tích hợp Lazy Loading Images thì chúng ta sẽ cùng check xem Images có được tải chậm thật không nhé. Mở chrome dev tool bằng cách nhấn F12 or click chuột phải chọn Inspect elements(Kiểm tra) sau đó chọn tab Network->Img. Ở lần refresh page đầu tiên bạn sẽ chỉ nhìn thấy 1 số image phía trên được load
Sau đó khi bạn scroll xuống dưới thì sẽ để í thấy những Images khác ngay lập tức được load theo
5 Kết luận
Cảm ơn các bạn đã đón đọc, mọi góp í xin để lại cmt bên dưới >< .
Ruby on Rails Developer là người đảm nhiệm việc phát triển các server-side logic web ứng dụng bằng ngôn ngữ Ruby và framework Rails. Người lập trình Ruby on Rails thường phát triển các thành phần của Back-End, liên kết app với các web services khác (thường là third-party web) và hỗ trợ tương thích với Front-End của ứng dụng. Hy vọng, Mẫu bảng mô tả công việc lập trình Ruby on Rails 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 Ruby on Rails : Để thành một Ruby on Rails Developer giỏi, á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ó kinh nghiệm về ngôn ngữ Ruby và framework Rails để 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.
Bài viết được sự cho phép của tác giả Chu Xuan Thang
Mở đầu
Ok, trước khi bắt đầu, bạn cần có một chút kiến thức về SEO để hiểu những thứ bên dưới. Trước hết, có nhiều cách để cho Google và các search engines khác biết thông tin về trang web của bạn. Theo định kì các search engines sẽ ghé thăm trang web của bạn, nó sẽ chạy từ page này qua page khác để đọc dữ liệu, tìm hiểu xem trang web của bạn là gì, có những content gì, tiêu đề của content, nội dung của content, nếu là trang web bán hàng, nó sẽ xem sản phẩm tên gì, thuộc loại sản phẩm nào, giá bao nhiêu, sản xuất ở đâu,…v.v. Việc này có thể gây mất nhiều thời gian và có thể search engines đọc sai/không đủ thông tin về trang web của bạn, khiến search engines đánh độ ưu tiên trang web của bạn sai.
Vậy thì thay vì phải mất thời gian đọc qua lần lượt từ đầu như thế, tại sao chúng ta không cung cấp cho search engines luôn dữ liệu về trang web của chúng ta khi search engines ghé thăm, như thế sẽ tiết kiệm thời gian cũng như cung cấp được thông tin chính xác nhất cho search engines.
JSON-LD là một cách (tương đối) mới để thể hiện dữ liệu về nội dung của bạn với search engines. Nó đi kèm với một vài lợi ích chính, ok cùng bắt đầu nào.
JSON-LD là gì ?
JSON-LD là viết tắt của JavaScript Object Notation for Linked Data, là một phương thức mã hóa dữ liệu liên kết sử dụng JSON
JSON là một định dạng trao đổi dữ liệu nhẹ, dễ đọc và viết đối với con người và dễ phân tích và khởi tạo đối với máy tính. Xem thêm JSON là gì
Linked Data là cách sử dụng internet để kết nối các dữ liệu có liên quan
JSON-LD là kết hợp của cả hai thứ trên. Nó sẽ là một đoạn code cho bạn biết sản phẩm nào có giá thế nào, hoặc zip code này thuộc về công ty nào… Về cơ bản, bạn sẽ cung cấp một đoạn mã Javascript nhỏ có tất cả thông tin trên.
Nó là một cách định dạng cho dữ liệu tương tự có cấu trúc với Microdata and RDFa. Về cơ bản, theo điều khoản của SEO, JSON-LD là thể hiện bộ từ vựng của Schema.org, với sự đồng hợp tác của Google, Bing, Yahoo và Yandex từ năm 2011 để tạo ra một bộ từ điển đồng nhất dữ liệu cấu trúc cho các trang web. (Tuy nhiên, Bing và các search engines khác không chính thức công bố sự hỗ trợ đối với JSON-LD).
Schema.org là gì?
Ok chúng ta đã nói về Schema.org, vậy nó là cái gì? Thứ chúng ta đang nói tới ở đây là dữ liệu có cấu trúc cho trang web của bạn. Schema.org cung cấp những cách thể hiện thông tin của bạn với Google theo một cách mà máy tính có thể đọc được. Với dữ liệu có cấu trúc, bạn tạo ra các lựa chọn cho Google để thể hiện content của bạn theo ba loại Google Search:
Rick results: Các nội dung được thêm vào của bạn, như giá của sản phẩm, xếp hạng và sự khả dụng của sản phẩm đó, được hiển thị chính xác trong kết quả tìm kiếm dưới dạng thông tin bổ sung trong snippet của bạn.
Site links search boxes: Nếu trang web của bạn đủ điều kiện, bạn có thể tiến hành search content của trang web của bạn từ chính trang tìm kiếm.
Knowledge Graph cards: Cái này khó hơn một chút, vì bạn sẽ phải chứng minh trước tiên rằng bạn là người có thẩm quyền đối với một số nội dung nhất định. Sau khi bạn đã làm như vậy, Google có thể đưa dữ liệu của bạn vào Knowledge Graph cards.
Tại sao phải sử dụng JSON-LD?
Các phương thức từng được sử dụng để triển khai schema.org trước khi JSON-LD xuất hiện thì rất cồng kềnh. Bạn phải thêm các thuộc tính schema.org vào các đoạn mã trong markup của bạn. Markup có thể phải thay đổi từ trang này sang trang khác, mặc dù bạn đã gắn cùng một header ở mọi nơi. Điều này làm cho schema.org tốn rất nhiều công sức để thực hiện.
JSON-LD cho phép bạn thu thập tất cả dữ liệu về sản phẩm của bạn và hiển thị chúng trong một đoạn mã JavaScript nhỏ, có thể được đẩy vào trang ở bất kì chỗ nào. Điều này cho phép bạn làm việc trên schema.org sử dụng JSON-LD độc lập với sự phát triển trang web của bạn.
Trên thực tế, trong document của mình, Google thường tuyên bố JSON-LD là cách dễ nhất để thêm siêu dữ liệu vào các trang web. Nó là lựa chọn mà ít có khả năng bị “hỏng” nhất khi bạn thực hiện các thay đổi với trang web của mình.
JSON-LD có tác dụng gì?
JSON-LD chú thích các phần tử trên một trang, cấu trúc các dữ liệu, những thứ mà các công cụ tìm kiếm có thể sử dụng để định hướng các phần tử và thiết lập các thông tin xung quanh các thực thể, điều này liên quan đến việc tạo ra tổng thể một website tốt hơn, có tổ chức hơn.
Dữ liệu rất lộn xộn và không liên kết. JSON-LD tổ chức và kết nối chúng, tạo ra một Web tốt hơn.
JSON-LD nằm ở đâu trong trang HTML?
Google đề xuất bạn nên thêm JSON-LD vào phần <head> của HTML. Tuy nhiên, vẫn ổn nếu JSON-LD nằm trong phần <body>. Google cũng có thể nắm bắt các thẻ được tạo trong DOM. Tóm lại là nó nằm ở đâu Google cũng có thể nhận được =))
Khi bạn thấy JSON-LD, thứ đầu tiên bạn sẽ luôn thấy là thẻ <script>. Thẻ <script> có thuộc tính type cho biết: “Hey trình duyệt, tôi đang gọi JavaScript có chứa JSON-LD.”
Lưu ý: JSON-LD của bạn phải được đặt trong dấu ngoặc nhọn.
"@context": "http://schema.org/",
Phần tử thứ hai giữ vị trí cố định trong markup JSON-LD là @context với giá trị là http://schema.org. @Context nói: “Hey trình duyệt, đây là từ vựng tôi tham khảo. Bạn có thể tìm thấy nó tại http://schema.org”. Lợi ích cho SEO là chúng ta có thể sử dụng bất kỳ loại và thuộc tính nào mà Schema.org định nghĩa.
"@Type": "…",
Phần tử cuối cùng trong nhóm sao copy/paste JSON-LD Schema là đặc tả @type ( sau dấu hai chấm sẽ là chú thích dữ liệu). @type chỉ định loại danh mục được đánh dấu. Bạn có thể tìm thấy một danh sách tất cả các loại danh mục tại: https://schema.org/docs/full.html.
Ví dụ: "@type": "Person",
@type nói rằng: “Hey, tôi đang sử dụng loại danh mục Person (Bạn có thể tìm thấy tại http://schema.org/Person)”. Thật vậy, nếu bạn nhập URL vào trình duyệt, document của loại danh mục và thông số kỹ thuật sẽ xuất hiện, bao gồm mọi thuộc tính danh mục (và thường là một số trường hợp sử dụng ví dụ).
Các cặp Attribute-value
Bước tiếp theo là chú thích thông tin về loại danh mục. Bạn có thể tìm thấy các thuộc tính trong trang Schema.org.
Attribute: Các thuộc tính xuất phát từ bộ từ vựng của Schema.org và phải được đặt trong cặp nháy kép, và phải thuộc về thuộc tính được cho phép trong loại danh mục đó.
Value: Giá trị tương ứng với thuộc tính. String (kí tự) và URL cần đặt trong cặp ngoặc kép. Số (int, float hoặc double) thì bản thân nó không cần ngoặc kép, tuy nhiên đặt chúng vào cặp ngoặc kép vẫn ok (điều này có nghĩa là chúng sẽ được coi như dạng dữ liệu string)
Ngoặc vuông
Dấu ngoặc vuông tồn tại cho các tình huống có nhiều giá trị cho thuộc tính. Một cách sử dụng phổ biến là tận dụng thuộc tính sameAs như sử dụng [dấu ngoặc vuông] để liệt kê nhiều nền tảng truyền thông.
Lưu ý: Không có dấu phẩy sau phần tử cuối cùng trong ngoặc vuông. Điều này chỉ ra rằng không có thêm thông tin trong dấu ngoặc vuông.
Thêm JSON-LD vào website
Bạn có thể sử dụng bất kỳ thuộc tính schema.org nào vào trong JSON-LD. Bạn có thể tìm thấy một danh sách tất cả các loại danh mục và thuộc tính liên quan tại: https://schema.org/docs/full.html. Sau khi thêm script JSON-LD mới vào trang web của bạn, hãy đảm bảo xác thực code của bạn bằng công cụ kiểm tra dữ liệu có cấu trúc của Google. Ở đây bạn có thể kiểm tra xem đoạn code của bạn đã chính xác cấu trúc hay chưa.
Ngoài ra còn có một cách đơn giản hơn là sử dụng các template có sẵn (ví dụ như cái này) để tạo đoạn script nhanh hơn với các danh mục được liệt kê sẵn. Nếu bạn đang sử dụng WordPress, có rất nhiều plugin có thể giúp các bạn thêm đoạn JSON-LD trong 1 nốt nhạc.
Tổng kết
Trên đây là những kinh nghiệm của mình khi sử dụng JSON-LD, trong khuôn khổ bài viết chỉ mang tính giới thiệu và phân tích về JSON-LD.
Về cách sử dụng các bạn có thể thực hành bằng cách sử dụng thử các danh mục thuộc tính tại https://schema.org/docs/full.html và test lại với công cụ kiểm tra dữ liệu có cấu trúc của Google.
Hầu hết các lập trình viên đều cho rằng việc optimize hiệu suất là một vấn đề phức tạp đòi hỏi nhiều kinh nghiệm và kiến thức. Tất nhiên, điều đó không phải sai, bởi optimize một ứng dụng để đạt được hiệu suất tốt nhất không phải là một nhiệm vụ dễ dàng. Nhưng điều đó không có nghĩa là bạn không thể làm bất cứ điều gì nếu bạn không có những kiến thức đó. Dưới đây là một số gợi ý và bài tập tốt nhất giúp bạn tạo ra một ứng dụng hiệu quả.
Hầu hết các mẹo này đều dành cho Java. Nhưng cũng có một số language-independent (ngôn ngữ độc lập), mà bạn có thể áp dụng cho tất cả các ứng dụng và ngôn ngữ lập trình. Chúng ta hãy nói về một số mẹo dành chung trước khi chúng ta đến các mẹo điều chỉnh hiệu suất của riêng trong khi lập trình Java.
Đó là một trong những mẹo điều chỉnh hiệu suất quan trọng nhất. Bạn nên làm theo các bước bình thường một cách tốt nhất và thử test các trường hợp sử dụng. Nhưng điều đó không có nghĩa là bạn cần thay thế bất kỳ thư viện chuẩn nào hoặc xây dựng các bước optimize (tối ưu hoá) phức tạp trước khi bạn xác định được đó là điều cần thiết.
Trong hầu hết các trường hợp, optimize sớm khiến tốn rất nhiều thời gian và làm cho code khó đọc và khó giữ nguyên. Và tệ hơn nữa, những hành động optimize này thường không mang lại bất kỳ lợi ích nào vì bạn đang dành rất nhiều thời gian để optimize các phần không quan trọng của ứng dụng của bạn.
Vậy làm thế nào để xác định được bạn cần optimize cái gì?
Trước tiên, bạn cần phải xác định ứng dụng của mình chạy nhanh như thế nào, ví dụ bằng cách xác định thời gian phản hồi tối đa cho tất cả các lệnh call API hoặc số lượng bản record bạn muốn nhập trong một khung thời gian nhất định. Sau khi bạn đã bước đó, bạn có thể tính toán được những phần nào trong ứng dụng của bạn quá chậm và cần phải được cải thiện. Và khi bạn đã xác định được, bạn nên xem tiếp mẹo thứ 2.
2. Sử dụng Profiler để tìm điểm kém hiệu quả thật sự
Sau khi bạn làm theo mẹo đầu tiên và xác định được các phần của ứng dụng cần cải tiến, hãy tự đặt câu hỏi phải bắt đầu từ đâu?
Bạn có thể tự giải quyết câu hỏi này theo hai cách:
Xem code của bạn và bắt đầu với những phần có vẻ đáng ngờ nhất hoặc điểm mà bạn cảm thấy nó có thể gây ra vấn đề.
Hoặc bạn sử dụng profiler và để nhận được thông tin chi tiết về trạng thái và hiệu suất của từng phần trong code.
Tôi nghĩ có lẽ không cần phải giải thích tại sao bạn nên chọn cách thứ hai.
Rõ ràng là phương pháp dựa vào profiler sẽ giúp bạn hiểu rõ hơn về hiệu suất của code và cho phép bạn tập trung vào những phần quan trọng nhất. Và nếu bạn từng sử dụng một profiler, bạn sẽ nhớ một vài tình huống khiến bạn ngạc nhiên bởi những phần code đã tạo ra các vấn đề về hiệu suất.
3. Tạo một bộ test hiệu suất cho toàn bộ ứng dụng
Đây là một mẹo chung giúp bạn tránh được rất nhiều sự cố không mong muốn, thường xảy ra sau khi bạn đã triển khai bước cải tiến hiệu suất trong sản xuất. Bạn cần có một bộ test hiệu suất để kiểm tra toàn bộ ứng dụng, chạy nó trước và sau khi bạn cải tiến hiệu suất để so sánh.
Những lần test bổ sung này sẽ giúp bạn xác định các chức năng và hiệu suất đã thay đổi thế nào và đảm bảo rằng bạn không tung ra bản cập nhật làm hại đến ứng dụng. Điều này đặc biệt quan trọng nếu bạn làm việc trên các component được sử dụng bởi một số phần khác nhau của ứng dụng, như cơ sở dữ liệu hoặc caches.
4. Xử lý những nút thắt lớn nhất đầu tiên
Và sau khi bạn đã tạo bộ test và phân tích ứng dụng của bạn với một profiler, bạn sẽ có một danh sách các vấn đề bạn muốn giải quyết để cải thiện hiệu suất. Điều đó tốt, nhưng nó vẫn không giúp trả lời được câu hỏi rằng nên bắt đầu từ đâu. Bạn có thể tập trung vào quick win (những điểm cần xử lý nhanh chóng) hoặc bắt đầu với một vấn đề quan trọng nhất.
Có thể bắt đầu với quick win bởi vì bạn sẽ sớm có thể nhận được những kết quả đầu tiên. Đôi khi, điều này có thể cần thiết để thuyết phục các thành viên khác trong nhóm hoặc quản lý của bạn rằng việc phân tích hiệu suất là quan trọng.
Nhưng xét chung, tôi khuyên bạn nên bắt đầu từ đầu và đánh vào những vấn đề ảnh hưởng đến hiệu suất đáng kể nhất trước tiên. Điều đó sẽ giúp bạn cải tiến hiệu suất tốt nhất và bạn có thể không cần phải sửa nhiều mà chỉ cần sửa những vấn đề này để đạt được hiệu suất mong muốn.
4 mẹo vừa rồi là dành cho những vấn đề chung về hiệu suất. Chúng ta hãy cùng xem xét một số mẹo dành riêng cho Java nhé.
5. Sử dụng StringBuilder để nối các String
Có rất nhiều phương thức để kết nối strings trong Java. Bạn có thể dùng những cách đơn giản như `+` hoặc `+=`, StringBuffer hoặc StringBuilder.
Vậy bạn thích cách tiếp cận nào nhất?
Câu trả lời tùy thuộc vào code bạn kết nối String. Nếu là thêm nội dung với for-loop thì bạn nên dùng StringBuilder bởi nó dễ dùng và cho hiệu năng tốt hơn StringBuffer. (Lưu ý rằng StringBuffer thì an toàn và phù hợp cho nhiều tình huống).
Bạn chỉ cần instantiate một StringBuilder và call append method để add phần mới vào String. Sau khi đã add mọi thứ thì bạn có thể call toString() method để lấy lại các String được kết nối. Code snippet sau đây cho ta thấy trong mỗi lần iteration, loop convert i thành một String và add chúng với một khoảng trống vào StringBuilder sb. Do đó, Code viết vào log file như sau: “This is a test0 1 2 3 4 5 6 7 8 9”:
StringBuilder sb = new StringBuilder(“This is a test”);
for (int i=0; i<10; i++) {
sb.append(i);
sb.append(” “);
}
log.info(sb.toString());
Bạn có thể thấy trong code snippet, ta cung cấp yếu tố đầu tiên của String tới constructor method. Nó sẽ tạo ra StringBuilder mới chứa String được cung cấp kèm theo khoảng trống có thể thêm 16 kí tự nữa. Khi bạn add thêm kí tự vào StringBuilder, JVM sẽ ngay lập tức tăng size của StringBuilder lên rất nhiều.
Còn nếu bạn đã biết có bao nhiêu kí tự trong String, bạn có thể giới hạn số lượng khoảng trống và nhờ đó tăng hiệu năng bởi nó không cần phải tự tăng sức chứa.
Khi bạn triển khai ứng dụng đầu tiên trong Java, hẳn sẽ có ai đó nói với bạn rằng bạn không nên nối String bằng ‘+’. Và điều đó đúng nếu bạn đang nối String với application logic (các logic riêng cho một application cụ thể). Các String là không thay đổi và kết quả của mỗi String concatenation được lưu trong một String object mới. Điều đó đòi hỏi thêm memory và sẽ làm chậm ứng dụng của bạn, đặc biệt nếu bạn đang nối nhiều String trong một loop (vòng lặp).
Trong những trường hợp này, bạn nên làm theo mẹo số 5 và sử dụng một StringBuilder.
Nhưng đó không phải là lựa chọn nếu bạn đang muốn phá vỡ một String thành nhiều dòng để cải thiện tính dễ đọc của code.
Trong những trường hợp này, bạn nên nối String của mình với một ‘+’ đơn giản. Trình biên dịch Java của bạn sẽ optimize điều này và thực hiện các concatenation tại thời gian compile. Vì vậy, trong runtime, code của bạn sẽ chỉ sử dụng 1 String.
7. Sử dụng Primitives ở điểm có thể
Một cách nhanh chóng và dễ dàng để tránh chi phí phát sinh và cải thiện hiệu suất của ứng dụng là sử dụng các kiểu primitive thay vì các class wrapper của chúng. Vì vậy, tốt hơn hết là sử dụng một int thay vì một Integer, hoặc một double thay vì một Double. Điều đó cho phép JVM của bạn lưu trữ value trong stack thay vì trong heap để giảm mức độ tiêu thụ memory và xử lý tổng thể hiệu quả hơn.
8. Cố gắng tránh BigInteger và BigDecimal
Như chúng ta đã nói về các loại dữ liệu, chúng ta cũng nên xem nhanhBigInteger vàBigDecimal. Đặc biệt là vì tính chính xác của nó. Nhưng cái gì cũng có giá của nó.
BigInteger và BigDecimal yêu cầu memory nhiều hơn một long hoặc double đơn giản và làm chậm tất cả các phép tính một cách đáng kể. Vì vậy, tốt hơn hãy suy nghĩ thật kỹ, nếu bạn cần tăng độ chính xác hoặc nếu number của bạn vượt quá phạm vi của một long. Đây có thể là điều duy nhất bạn cần phải thay đổi để khắc phục các vấn đề về hiệu suất, đặc biệt là nếu bạn đang thực hiện một mathematical algorithm (thuật toán về toán học).
9. Kiểm tra ở Current Log đầu tiên
Điều này là hiển nhiên, nhưng thật không may, bạn có thể thấy hiện nay có rất nhiều đoạn code bỏ qua nó. Trước khi tạo một thông báo debug, bạn nên luôn luôn kiểm tra current log trước tiên. Nếu không, bạn có thể tạo một String mà log message sẽ bị bỏ qua.
Dưới đây là hai ví dụ về cách mà bạn KHÔNG nên làm.
// don’t do this
log.debug(“User [” + userName + “] called method X with [” + i + “]”);
// or this
log.debug(String.format(“User [%s] called method X with [%d]”, userName, i));
Trong cả hai trường hợp này, bạn sẽ thực hiện tất cả các bước cần thiết để tạo ra log message mà không cần biết liệu logging framework của bạn có sử dụng log message hay không. Tốt hơn hết là kiểm tra mức độ current log đầu tiên, trước khi bạn tạo ra các tin nhắn debug.
// do this
if (log.isDebugEnabled()) {
log.debug(“User [” + userName + “] called method X with [” + i + “]”);
}
10. Sử dụng Apache thông thường StringUtils.Replace thay vì String.replace
Nói chung, method String.replace hoạt động tốt và hiệu quả khá cao, đặc biệt nếu bạn đang sử dụng Java 9. Nhưng nếu ứng dụng của bạn đòi hỏi nhiều hoạt động replace và bạn chưa cập nhật phiên bản Java mới nhất, thì vẫn có các lựa chọn thay thế nhanh hơn và hiệu quả hơn.
Một ứng cử viên sáng giá là method StringUtils.replace của Apache Commons Lang. Như Lukas Eder mô tả trong một trong các bài blog gần đây của họ, nó vượt trội hơn method String.replace của Java 8.
Và nó chỉ đòi hỏi ít sự thay đổi. Bạn cần phải thêm một Maven dependency vào project Commons Lang của Apache vào application pom.xml của bạn và thay thế tất cả các lệnh call của method String.replace bằng method StringUtils.replace.
// replace this
test.replace(“test”, “simple test”);
// with this
StringUtils.replace(test, “test”, “simple test”);
11. Lưu trữ resource lớn, như kết nối Database
Caching (bộ nhớ đệm) là một giải pháp phổ biến để tránh việc lặp lại các đoạn code “nặng” hoặc thường xuyên được sử dụng. Ý tưởng chung đơn giản là: Tái sử dụng các resources như vậy sẽ đỡ tốn kém hơn so với việc tạo ra một cái mới hơn.
Một ví dụ điển hình là lưu trữ các kết nối cơ sở dữ liệu trong một pool. Việc tạo ra một kết nối mới đòi hỏi nhiều thời gian, bạn có thể tránh được điều đó nếu bạn sử dụng lại một kết nối hiện có.
Bạn cũng có thể tìm các ví dụ khác bằng chính ngôn ngữ Java. Method valueOf của class Integer, ví dụ, lưu các value giữa -128 và 127. Bạn có thể cho rằng việc tạo ra một Integer mới không phải là quá tốn kém, nhưng nó thường sử dụng cách lưu trữ các giá trị được sử dụng nhiều nhất để đạt hiệu suất tối đa.
Nhưng khi bạn nghĩ về cache, hãy nhớ rằng việc thực hiện cache cũng tiêu tốn resource. Bạn cần phải dành thêm memory để lưu trữ các resource tái sử dụng và bạn có thể cần phải quản lý bộ nhớ cache của mình để giúp cho các resource có thể truy cập được hoặc để xóa các resource lỗi thời.
Vì vậy, trước khi bạn bắt đầu bộ nhớ cache bất kỳ resource nào, hãy đảm bảo rằng bạn sử dụng chúng thường đủ để vượt quá chi phí của việc triển khai bộ nhớ cache của bạn.
Tổng kết
Như bạn đã thấy, đôi khi không cần quá nhiều công sức để cải thiện hiệu suất ứng dụng của bạn. Hầu hết các đề xuất trong bài này chỉ cần thêm một sự cố gắng nhỏ là có thể áp dụng chúng vào code của bạn.
Nhưng như thông thường, những khuyến nghị quan trọng nhất vẫn là:
Thế giới đang nằm trong “tâm bão” AI – Trí tuệ nhân tạo: Các chuyên gia về Machine Learning thì “hét” mức lương “trên trời”, còn nhà đầu tư cũng “giang rộng vòng tay” đổ không ít vốn vào các startup AI. Vì thế mới nói: đây là một trong những công nghệ gây chuyển biến mạnh mẽ nhất những thập kỉ vừa qua. Nó đã đến, ở lại và sẽ thay đổi cục diện cuộc sống của chúng ta.
Tuy nhiên, nó không đồng nghĩa với việc làm startup AI dễ ăn – dễ sống. Có một số “bẫy ngầm” mà bất cứ ai gia nhập vào ngành này chắc chắn sẽ dẫm phải. Bạn có vượt qua nó không mới quyết định được thành bại của startup mình.
“Tôi và con trai” – bức tranh được vẽ hoàn toàn bằng Artistic Style Transfer – 1 dạng kỹ thuật Deep Learning gây không ít tranh cãi
Các kỹ năng về AI đang bị “hạ giá”
Vào năm 2015 khi tôi vẫn còn ở Google và còn chơi DistBelief (đã được đổi tên lại là TensorFlow). Nói thật là: nó chán vê-lờ… Viết cũng thấy ngượng ngượng, phần abstraction chính cũng chẳng được như bạn kỳ vọng. Giấc mơ build nó ngoài hệ thống build của Google thật sự đúng như tên gọi: một GIẤC MƠ.
Đến cuối năm 2016 thì tôi đang làm cho 1 project detect được bệnh ung thư dựa trên các ảnh mô bệnh (histopathological images). Lúc đó tôi muốn dùng transfer learning: bằng cách dùng Inception – công nghệ phân loại ảnh tốt nhất bấy giờ của Google, và “dạy” nó lại theo dữ liệu về bệnh ung thư tôi có. Tôi còn dùng những công nghệ của bản Inception trước-khi-train do Google cung cấp, chỉ thay đổi 1 chút ở phần layer trên cùng theo hướng tôi đang làm. Sau thời gian lăn lộn với TensorFlow, tôi cũng tìm ra được cách xử lý các layer khác nhau, và hầu hết đều hiệu quả. Nó đòi hỏi không ít kiên nhẫn và thời gian đọc lại source của TensorFlow. Ít ra tôi cũng không phải lo quá nhiều về các dependencies, vì những người làm TensorFlow đã (tốt bụng) chuẩn bị sẵn file docker.
Đầu 2018 thì task trên không còn phù hợp với intern như tôi nữa. Cũng may nhờ có Keras (một framework nền của TensorFlow) chỉ cần vài dòng code Python là bạn đã có thể hoàn thành công việc, và cũng không đòi hỏi bạn phải am hiểu chuyên sâu về nó nữa. Cái “đau đầu” duy nhất còn lại đó là phần Hyper Parameter tuning. Nếu bạn dùng Deep Learning model, bạn có thể tận dụng các knob, số lượng và size của layer,… Việc tối ưu configuration thật ra cũng không quan trọng lắm, và một số thuật toán như grid search cũng không thật sự hiệu quả. Bạn có thể tiến hành nhiều thử nghiệm, bạn sẽ thấy trải nghiệm của vụ này giống như 1 công trình nghệ thuật hơn là một nghiên cứu khoa học.
Giờ đây, khi đang ngồi mổ cò những dòng này (năm 2019), thì Google và Amazon đã offer các dịch vụ automatic model tuning (Cloud AutoML, SageMaker), phía Microsoft cũng đang lên lộ trình ra mắt các dịch vụ tương tự.
Đến đây chắc bạn đã hiểu cái tôi đang muốn nói đến rồi. Những bài toán hóc búa trong quá khứ, giờ đã trở nên dễ dàng hơn. Giờ bạn có thể làm được những thứ khó nhằn, mà không cần tốn công sức quá nhiều. Những công trình kỹ thuật vĩ đại ngày xưa giờ đây đã bị gán mác “lỗi thời”, và bạn cũng chẳng cần kỳ vọng những cái ta đang làm hiện tại sẽ khủng hơn trong tương lai. Đây chẳng qua là dấu hiệu của sự tiến bộ. Chúng ta nợ một lời cảm ơn đến các công ty như Google đã tiêu tốn không ít nghiên cứu & phát triển nên tool để hỗ trợ chúng ta và publish nó free. Lí do họ làm nên những việc này cũng có 2 mặt của nó.
Văn phòng của bạn sau khi được “tái cơ cấu”.
Đầu tiên, đây là dạng Commoditize the complement (hàng hóa bổ sung) cho các sản phẩm hiện tại của họ, gọi là cloud infrastructure. Trong nền kinh tế, 2 món hàng mà bạn thường có xu hướng mua chung với nhau thì gọi là hàng hoá bổ sung, ví dụ: xe hơi mua chung xăng, sữa mua chung ngũ cốc, trứng thì mua chung với thịt. Nếu giá của 1 trong 2 giảm, thì cầu của nó tăng dẫn đến cầu của cái còn lại sẽ tăng. Phần “hàng hóa bổ sung” của cloud chính là phần mềm chạy trên đó, và nhờ đó, những thứ công nghệ liên quan đến AI cũng có một nguồn tài nguyên dồi dào để có thể triển khai một cách dễ dàng. Vì thế, Google cũng giải quyết được vấn đề chi phí -> về lâu về dài, việc phát triển công nghệ này sẽ trở nên tiết kiệm hơn.
Lí do thứ 2 mà Google lại rất hứng thú với AI là vì họ sẽ dành được lợi thế tương đương so với các đối thủ trên thị trường như Amazon và Microsoft. Họ làm nó trước, và chính họ là người mang concept Deep Learning ra thế giới, vì thế mà họ có rất nhiều nhân tài trong đội ngũ. Họ có nhiều kinh nghiệm về phát triển sản phẩm AI, từ đó tạo được nhiều ưu thế khi phát triển tool và dịch vụ ra ngoài thị trường.
Nghe có vẻ hay, nhưng đây là tin buồn cho cả công ty và các cá nhân đang nghiên cứ các kĩ năng AI. Ngày nay, họ sẽ cho bạn nhiều lợi thế cạnh tranh, vì một kĩ sư Machine Learning đủ chuẩn cần rất nhiều thời gian để đọc tài liệu, và phát triển background về toán thật vững để bắt tay vào việc. Tuy nhiên, vì tool có sẵn càng ngày càng tốt và hữu ích, lúc này skill của bạn lại bắt đầu “bớt hiệu lực”. Luật chơi bây giờ sẽ là “đọc hướng dẫn sử dụng” hơn là “đọc nghiên cứ tài liệu”. Nếu bạn không sớm nhận ra ưu thế của mình, đến intern cũng có thể ăn mất phần của bạn. Đặc biệt, nếu intern có data tốt hơn, và câu chuyện chưa dừng lại ở đó…
Data mới là thứ quan trọng hơn so với đống AI Architecture hào nhoáng!
Hãy cùng bàn về case của 2 startup founder, Alice và Bob. Côn ty của họ kêu gọi được cùng lượng tiền, và cạnh tranh khốc liệt trên cũng 1 thị trường. Alice đầu tư vào những kĩ sư giỏi nhất, từ PhD đến Doctor công nghệ siêu sao. Bob thì chỉ thuê các kĩ sư tầm trung, và đầu tư phần lơn vào bảo toàn data hiện có. Vậy công ty nào là lựa chọn của bạn?
Tôi sẽ nằm kèo anh Bob trong lần này. Tại sao? Machine learning hoạt động dựa trên một dataset và chuyển hoá nó vào các model weight. Một model tốt hơn sẽ hiệu quả hơn trong process này (về thời gian và năng suất chung), nhưng theo một số chuẩn thông thường, data tốt hơn sẽ mang đến architecture tốt hơn.
Để chứng minh luận điểm này, hãy thực hiện test sau. Tôi sẽ làm tạo các convolutional network đơn giản, một cái “ngon” và một cái “không ngon bằng”. Layer cuối cùng của bản “ngon” có 128 neuron, còn cái còn lại chỉ có khoảng 64 cái. Tôi đã “dạy” nó về subsets của MNIST dataset của size, và cho sẵn độ chính xác của model trên test set so với số sample mà chúng được học.
Màu xanh dương là model “ngon” hơn, màu xanh lá là model “xấu” hơn
Hiệu ứng tích cực của việc set dataset size rất rõ ràng (ít nhất cũng đến khi model bắt đầu fit và ổn định). Model “ngon” hơn – line màu xanh dương, rõ ràng sẽ làm tốt hơn so với cái kia – line xanh lá. Tuy nhiên, cái tôi muốn nhấn mạnh là độ chính xác của line xanh lá sau khi được học trên 40k mẫu lại tốt hơn hẳn so với line xanh dương chỉ được luyện trên 30k mẫu.
Điểm mấu chốt ở đây là, kĩ sư của Alice không chỉ đang cạnh tranh với kĩ sư của Bob. Nhờ có văn hoá mở của cộng đồng AI và tầm quan trọng của việc chia sẻ kiến thức, họ cũng đang chạy đua với cả các researcher tại Google, Facebook, Microsoft, và cả ngàn trường đại học trên thế giới. Sử dụng architecture phù hợp nhất cho data của bạn là một cuộc chiến thử nghiệm về chiến lược nếu như mục tiêu của bạn là giải quyết vấn đề (ngược lại với việc cống hiến bản gốc cho khoa học). Nếu không có sẵn những cái hiệu quả, việc đợi người mang giải pháp đến chỉ là vấn đề về thời gian. Bạn thậm chí có thể tổ chức một cuộc thi Kaggle để khuyến khích các researcher nghiên cứu phân tích vấn đề cho bạn.
Kĩ sư tốt là quan trọng, nhưng nếu bạn đang làm về AI, thì data mới là ưu thế cạnh tranh. Câu hỏi “Ai là triệu phú” ở đây đó là: Liệu bạn có khả năng tin tưởng vào data và giữ vững được lợi thế của mình không.
Giữ vững lợi thế cạnh tranh trong ngành AI là cực khó!
Với đống dữ liệu dataset khủng, Bob đã dành ưu thế hoàn toàn so với Alice. Bob launch được sản phẩm và dần dành lấy được nhiều thị phần. Chưa kể Bob đã bắt đầu thuê các kĩ sư cao cấp hơn, vì công ty của Bob đã ở một tầm cao mới.
Rồi một ngày Chuck xuất hiện, Chuck rất giàu, có nhiều tiền, nhưng Chuck sẽ phải làm rất nhiều thứ để bắt nhịp được cuộc chơi. Ném một đống tiền vào không đảm bảo việc một project có chạy nhanh hay không. Chưa kể, việc cố gắng gượng ép đưa càng nhiều kỹ sư vào lại còn gây hại hơn, dễ gây rối loạn tình hình. Tuy nhiên, việc tạo ra dataset thì lại khác. Thường thì nó cần rất nhiều nhận lực tay chân, thì bạn sẽ phải chi tiền để thuê thêm người. Hoặc có khi chỉ cần 1 người có thật nhiều data – khi đó tất cả những gì bạn phải làm đó là chi tiền cho license đó. Lúc này thì tiền mới thật sự có tác dụng.
Tại sap Chuck lại có thể kêu gọi được nhiều tiền đầu tư hơn Bob?
Khi một founder kêu gọi vốn được 1 vòng, họ thường sẽ cố gắng đi hai hàng, một là thêm thật nhiều tiền vào, tuy nhiên không được quá nhiều vì cổ phần sẽ bị pha loãng (dilute), Thêm một nhà đầu tư đồng nghĩa với việc bán đi một phần của công ty. Team lãnh đạo phải phải kiểm soát đủ cổ phần trong startup, để không mất động lực và tiền (làm startup khổ lắm quý vị, thật!…)
Mặc khác, nhà đầu tư lại muốn bơm tiền vào những ý tưởng tiềm năng, nhưng cũng phải kiểm soát rủi ro. Nếu rủi ro dự kiến tăng cao, thì họ sẽ kỳ vọng nhiều hơn trên mỗi đồng họ đã đầu tư.
Khi Bob kêu gọi vốn, việc AI sẽ giúp cho sản phẩm vượt trội hơn là điều không tưởng. Dù Bob và team xuất chúng đến đâu thì chuyện bị lên án chỉ trích là không thể tránh khỏi. Trường hợp của Chuck lại khác. Anh ấy hiểu rõ vấn đề, mọi thứ đều nằm trong tầm tay: Sản phẩm của Bob đã là bằng chứng “sống” rõ ràng nhất.
Bob đã đáp trả lại thử thách này bằng cách tiếp tục kêu gọi vòng khác. Bob vẫn đang dẫn đầu cuộc đua. Tuy nhiên tình hình lại phức tạp hơn, nếu như Chuck có thể bảo toàn được quyền access data bằng quan hệ hợp tác thì sao? Thử nghĩ về một startup chẩn đoán bệnh ung thư đi. Chuck hoàn toàn có thể dùng vị trí ngầm nào đó trong một viện y tế để bảo toàn deal với viện đó. Và Bob sẽ không bao giờ có đủ tài chính để làm chuyện đó.
Vậy nên, làm sao để giữ được ưu thế cạnh tranh của sản phẩm AI? Không lâu trước tôi đã vinh hạnh được nói chuyện với Antonio Criminisi của Microsoft Research. Bí mật nằm ở chỗ, chìa khóa của sản phầm không nên chỉ nằm ở AI (AI only), tức là không nên bỏ trứng vào cùng 1 rổ. Ví dụ, InnerEye project của anh ấy sử dụng AI và công nghệ computer vision truyền thống (không dựa trên ML) để phân tích các ảnh chụp x-quang. Khả năng đưa data vào một model và xem nó hoạt động thế nào khá là hay. Tuy nhiên, với một yếu tố kết hợp dùng AI với phần mềm truyển thống, sản phẩm của bạn sẽ khó đoán hơn, vì loại yêu cầu các lập trình viên phải suy nghĩ về các thuật toán và sử dụng một số kiến thức khó để có được kiến thức về miền, nói chung là rất khó để đối thủ có thể nắm bắt được.
AI chỉ nên được dùng như một “đòn bẩy”.
Một trong những cách để phân loại một doanh nghiệp chính là xem xét xem mô hình kinh doanh ấy đang thêm thắt giá trị gì cho những đối tác xung quanh. Hãy xem công ty e-commerce sau làm ví dụ. Nếu bạn tạo ra 1 dòng sản phẩm mới tức là bạn đang thêm giá trị trực tiếp. Trước đó chẳng có gì, giờ đây đã có widget và khách hàng sẽ chi tiền để mua nó. Còn cho ra một kênh phân phối mới, cái đó gọi là đòn bẩy. Bằng cách bán widget mới của bạn trên Amazon, tức là bạn đang nhân đôi lượng bán ra. Cắt giảm chi phí cũng được gọi là đòn bẩy. Nếu bạn thương lượng được một deal ngon với một nhà cung cấp từ Trung Quốc, bạn cũng đang nhân đôi lợi nhuận gộp (gross margin) của mình nữa.
Hãy tư duy theo kiểu thế này, chiếc đòn bẫy chỉ đóng vai trò như một lực đẩy nhẹ giúp bạn đi xa hơn, không nên gượng ép ứng dụng nó vào sản phẩm. Luôn nhớ rằng, đòn bẫy chỉ thật sự hữu ích khi nó được kết nối với một nguồn data giá trị, cũng giống như việc nếu bạn không có đủ loại hàng để bán, thì việc đẩy thêm kênh phân phối dường như không mang lại nhiều giá trị.
Vậy thì nhân tố AI ở đâu để chúng ta hiểu? Có rất nhiều công ty đang cố đưa AI trực tiếp vào sản phẩm của mình (vd: các API nhận diện hình ảnh và những cái tương tự). Đối với các chuyên gia AI thì còn gì hấp dẫn hơn được nữa. Tuy nhiên, đây là một ý tưởng khá fail.
Một là, bạn đang cạnh tranh với Google và Amazon. Thiệt luôn…
Hai là, việc tạo ra sản phẩm AI thuần một cách tỉ mỉ là việc khó không tưởng. VD: Tôi muốn dùng Vision API của Google. Đáng tiếc là, chúng tôi chưa reach đến được nhóm đối tượng có nhu cầu phù hợp. Nó hoặc hơi quá mức, hoặc chưa đủ đô, có khi lại cả hai…
Một lựa chọn hay hơn đó là đúng AI như một “đòn bẩy”. Bạn có thể dùng model hiện tại sẵn có và tăng tốc nó bằng AI. VD, nếu bạn đang có 1 quy trình tốn nhiều nhân lực người làm, việc tự động hoá đó sẽ mang đến điều kì diệu. Một số ví dụ điển hình sẽ là ECG analysis, industrial inspection, satellite image analysis. Chính bởi vị AI nằm ở phía backend, bạn sẽ có nhiều option AI hơn để build và giữ được ưu thế cạnh tranh.
Kết luận
AI là một công nghệ thực sự xoay chuyển cuộc chơi. Thế nhưng xây dựng công ty của bạn phụ thuộc vào nó lại là một câu chuyện khác. Bạn không nên quá phụ thuộc vào các kĩ năng về AI, vì chúng đang dần bị “hạ giá” trên xu hướng thị trường nói chung. Việc xây dựng các AI model có vẻ thú vị thật, nhưng cái quan trọng là phải có nguồn data tốt hơn. Giữ lợi thế cạnh tranh đã khó, đặc biệt là khi gặp thằng đối thủ siêu giàu nữa thì nguy cơ cao đó là AI của bạn sẽ bị “nuốt chửng”. Bạn nên hướng về một process data scalable nào mà khó có thể bị bắt chước bởi đối thủ. AI sẽ là cách tiếp cận tốt nhất cho những công việc không cần quá nhiều nhận thức và đầu óc con người, vì sức mạnh lớn nhất của nó là tự động hoá.
Thay vì tận hưởng công việc thì tôi lại lo lắng thái quá về việc thiếu hiểu biết, rằng thôi chưa làm đủ. Rằng tôi không đem lại đủ giá trị cho công ty. Tôi quên đi những thành tựu mình đã làm được và chỉ tập trung vào lỗi lầm mà mình gây ra. Tôi không chỉ tập trung vào sự hoàn hảo ở chính mình mà còn đòi hỏi nó từ những người xung quanh nữa. Đây là một công thức hoàn hảo cho sự stress cao độ và mất đi hạnh phúc.
