Đây là cách Node.js được sử dụng

Node.js Foundation vừa công bố kết quả khảo sát trên toàn thế giới, tìm hiểu về mục đích sử dụng Node, nhằm xác định các thay đổi tiềm năng cho framework mã nguồn mở này.

Cuộc khảo sát được tiến hành trực tuyến từ ngày 30 tháng 11 đến ngày 16 tháng 1 năm 2017 với sự tham gia của 1.405 người. Các câu trả lời được phân tích bởi một hội đồng tư vấn nghiên cứu độc lập.

Hãy xem Node.js dùng để làm gì!

Trước hết, cuộc khảo sát kết luận rằng …

“Node.js đang nổi lên như là một framework phát triển dành cho việc chuyển đổi kỹ thuật số với nhiều ứng dụng đa dạng”

Các nhà phát triển chủ yếu sử dụng Node.js cho back-end, nhưng nó cũng được sử dụng như một giải pháp tốt cho cả Full-stack và Front-end.

Một trong những điểm mạnh của Nodejs là có thể sử dụng cùng 1 ngôn ngữ trong toàn bộ stack.

Bởi vì tất cả developer có thể dễ dàng hiểu điều gì đang xảy ra và những thay đổi nếu cần.

Foundatinon đã hỏi những người trả lời về những gì họ build với Node.js

Kết quả cho thấy Node.js được sử dụng chủ yếu để xây dựng các ứng dụng web, nhưng chúng tôi cũng nhận thấy rằng nó cũng là một sự lựa chọn rất phổ biến để xây dựng các ứng dụng doanh nghiệp.

‘“Sự phát triển của Node.js trong các công ty là một minh chứng cho sự linh hoạt của platform này. Nó không chỉ đơn giản là một nền tảng ứng dụng được sử dụng để thử nghiệm với dữ liệu và công ty, ứng dụng hiện đại hóa, và các giải pháp IoT. (Nguồn: Phân tích của Forrester)”

Cuộc khảo sát cho phép chúng ta tìm hiểu về những lựa chọn mà developer sử dụng Node để tạo ra. Kết quả cho thấy AWS là lựa chọn chính để chạy các ứng dụng Node.js trong sản xuất – nhưng có vẻ như các cơ sở hạ tầng tại chỗ (hoặc tự chủ) cũng rất phổ biến.

Dữ liệu này phù hơp với những dữ liệu chúng tôi thu được tại RisingStack đo cách đây một năm qua khảo sát Node.js. Sự khác biệt duy nhất đáng chú ý là cách đây một năm trước, Heroku và DigitalOcean là những đối thủ ngan cơ nhau trong cuộc chiến Node, giờ đây dường như Heroku đã có một chút lợi thế.

Ai sử dụng Node.js?

Vì Node.js có LTS (một kế hoạch hỗ trợ dài hạn tập trung vào bảo mật và ổn định) từ năm 2015, không có gì ngạc nhiên khi các tập đoàn lớn liên tục bổ sung nó vào các stack của họ.

Note không chỉ chinh phục các doanh nghiệp, mà còn trên phạm vi toàn cầu. Cộng đồng người dùng Node.js trải rộng trên 85 quốc gia và nói hơn 45 ngôn ngữ.

Theo cuộc khảo sát, phần lớn các nhà phát triển Node đang sống tại Châu Âu (41%), chứ không phải ở Bắc Mỹ.

Tại sao lập trình viên yêu thích Node.js?

Những người tham gia khảo sát cho rằng, Node.js cải thiện năng suất và hiệu suất ứng dụng một cách đáng kể.

Ngoài ra, thật tuyệt vời khi thấy rằng những lợi ích của việc sử dụng Node tăng tỷ lệ thuận với thời gian sử dụng

Các nhà phát triển và nhà quản lý sử dụng Node.js trong hơn hai năm đã khen ngợi các tác động tích cực này.

“Cuộc khảo sát cho thấy các nhà phát triển và chuyên gia phân tích dữ liệu / kinh doanh lớn nhận ra được những tác động tích cực lên kinh doanh sau khi Node.js tham gia vào cơ sở hạ tầng của họ với những lợi ích chính là năng suất, sự hài lòng, giảm chi phí và tăng hiệu suất ứng dụng.”

User “điển hình” của Node.js là cử nhân với 6-9 năm kinh nghiệm lập trình

Theo bảng điều tra đặc điểm nhân khẩu học người dùng của cuộc khảo sát, hầu hết các nhà phát triển sử dụng Node v6 (57%) và dành một nửa thời gian của họ bằng cách viết code trong Node.

Khảo sát cũng cho thấy rằng phần lớn các nhà phát triển nâng cao kiến thức của họ bằng việc tham gia các khóa học trực tuyến và các nguồn lực và thật tuyệt vời khi thấy NodeSchool cũng khá phổ biến.

Tương lai của Node.js

Theo báo cáo của TechCrunch vài tháng trước đây, Node.js đã trở thành một loại mã nguồn mở cấp doanh nghiệp.

Điều này có nghĩa rằng platform này là một trong những công nghệ mới nhất của doanh nghiệp hiện nay. Do đó, nhiều công ty lớn – từ những người khổng lồ về tài chính đến các nhà bán lẻ cho các công ty dịch vụ – đang xây dựng các doanh nghiệp của họ trên nền tảng Node.js thay vì các ngôn ngữ cũ như PHP hay Java.

Một điều chắc chắn là:

Với hơn 8 triệu lượt sử dụng Node.js trực tuyến, 3 trong số 4 người dùng cho biết sẽ tăng việc sử dụng của họ trong 12 tháng tới.

Học Node.js

Trong trường hợp bạn muốn nâng cao kiến thức về Node.js của mình, chúng tôi khuyên bạn nên kiểm tra hai khóa học trực tuyến miễn phí của chúng tôi và một số sách điện tử của chúng tôi:

Các bài hướng dẫn trực tuyến miễn phí:

Node Hero là một loạt hướng dẫn cho người mới bắt đầu tập trung vào các vấn đề cơ bản của Node. (Tổng cộng 13 chương)
Node.js at Scale là một tập hợp các bài viết tập trung vào nhu cầu của các công ty có cài đặt Node.js lớn hơn và các nhà phát triển đã học được những điều cơ bản về Node. (Tổng cộng 19 chương)

Sách điện tử miễn phí:

Node.js Monitoring, Alerting, Reliability: Hướng dẫn chi tiết để xây dựng và giám sát các ứng dụng Node đáng tin cậy.
Learning using npm: Học tập bằng cách sử dụng npm một cách tiên tiến.
Node.js Under the Hood: Nghiên cứu chi tiết về Node.js.
Building with Node.js: Mọi thứ bạn cần để xây dựng và scale up 1 ứng dụng Node đúng cách.
Node Hero ebook: Bắt đầu với Node.js và mang đến các sản phẩm phần mềm sử dụng Node
Node.Js is Enterprise Ready: Cách sử dụng Node.js để mang đến các sản phẩm doanh nghiệp tốt hơn, nhanh hơn.

Nguồn: blog.topdev.vn via hackernoon

Một số mẹo vặt dành cho Developer trên Chrome

1. Animation

Nếu như trang web của bạn có animation, bạn có thể giảm tốc độ hiển thị animation xuống còn 10% hay 25% để kiểm tra các bug lỗi dễ dàng hơn

2. Pretty screenshotting

Khi truy cập một trang web dưới chế độ mobile mode thì chrome hỗ trợ một tính năng chụp ảnh màn hình, đồng thời ảnh được chụp sẽ được tải ngay về máy tính. Trong phiên bản mới nhất của chrome, bạn còn có thể chụp full màn hình cho dù nội dung có dài đến đâu đi chăng nữa

Nếu bạn bật thêm chế độ show device frame thì hình ảnh tải về có cả hình điện thoại đi kèm như dưới đây

3. Chỉnh sửa text trực tiếp trên web

Giả sử trong quá trình phát triển bạn muốn thay đổi một vài đoạn text cho mục đích testing, có thể bạn sẽ nghĩ ngay tới Inspect HTML rồi sửa giá trị HTML là xong. Cách đấy cũng được, tuy nhiên còn một cách thú vị hơn nhiều đó là bạn chuyển trang web sang chế độ designMode bằng cách mở console gõ lệnh document.designMode=’on’ là xong

4. Chỉnh sửa với màu sắc

Trong chrome, mỗi khi chúng ta muốn thiết lập màu sắc cho background hay font chữ thì có thể chọn màu sắc thông qua popup đơn giản này. Hơn nữa chrome cũng hỗ trợ 2 mẫu mầu mắc đó là material design và các màu có sẵn trên trang web hiện tại

5. Kiểm tra font family

Đôi khi thật khó để biết được trang web đang sử dụng mẫu font nào. Chúng ta có một cách đơn giản hơn là vào tab computed, để ý vào phần filters (nhớ tích chọn show all)

Bây giờ kéo xuống dưới một chút, bạn có thể nhìn thấy mục font family có chứa những tên font mà đôi khi bạn không thể inspect nổi

6. Code snippet

Bạn có thể lưu lại các đoạn script hay dùng để test vào mục snippet của chrome

Tham khảo thêm các vị trí tuyển dụng ngành cntt hấp dẫn tại Topdev

Ứng dụng chrome mà mình sử dụng trong bài viết này là Chrome Canary – được khuyên dùng bởi google dành cho các lập trình viên. Mình có chọn lọc một số nội dung và lược dịch từ bài viết gốc tại đây

5 thói quen ngày thứ 2 giúp bạn xây dựng app tốt hơn

Khi build 1 sản phẩm kỹ thuật có rất nhiều điều cần lưu ý. Nếu bạn là 1 Product Manager hoặc bạn là trưởng nhóm phát triển sản phẩm, có lẽ một trong những vấn đề hàng đầu bạn có thể gặp phải là một loạt những vấn đề “khẩn cấp” đòi hỏi sự chú ý của bạn. Và sớm hay muộn, điều đó cũng dẫn tới hệ quả là những điều quan trọng sẽ không được quan tâm một cách thích đáng.

Tôi tin tưởng một cách mạnh mẽ vào sức mạnh của thói quen. Vì vậy, theo lời khuyên của Eisenhower, tôi lên thời gian biểu vào mỗi buổi sáng thứ hai, và đây là 5 điều tôi chắc chắn rằng mình sẽ làm.

1/ Phân tích thống kê và KPIs

Tôi có thể nói điều này có lẽ nên là một thói quen hàng ngày. Tôi đoán không cần phải nói thêm về tầm quan trọng của nó. Theo Drucker, nếu bạn không thể đo lường nó, bạn không thể quản lý nó.

Ngay cả khi bạn nhìn vào các KPI của bạn mỗi ngày, dành thêm thời gian vào thứ Hai phục vụ 2 mục đích:

Xác định thời gian cụ thể trong tuần để so sánh kết quả giữ các tuần .
Khám phá hành vi người dùng: có thể đây là một phần của đánh giá hàng ngày của bạn bao gồm các KPI chính cho các sản phẩm của bạn. Nhưng điều này sẽ không cung cấp cho bạn bất kỳ cái nhìn sâu sắc về hành vi người dùng … những gì đang chi phối KPIs? (nó thực sự sẽ hữu ích cho quyết định sản phẩm). Khám phá hành vi và nhận được những hiểu biết này là một cách tuyệt vời để bắt đầu một tuần mới với những việc cần thực hiện sau đó.

Ví dụ:

Trong khi làm việc về thương mại điện tử, tôi đã dành thêm thời gian vào buổi sáng thứ hai để khám phá hành vi “người mua” liên quan đến việc sử dụng bộ lọc. Mặc dù mức sử dụng bộ lọc thấp, nhưng những người sử dụng chúng có khả năng mua gấp đôi. Khám phá Insight khách hàng cung cấp cái nhìn sâu sắc rõ ràng hơn về khả năng chuyển đổi hành vi người mua.

2/ Kiểm duyệt sản phẩm

Điều này nghe có vẻ rõ ràng, nhưng điều làm tôi ngạc nhiên là rất nhiều người không làm điều này.

Trong trường hợp của tôi, tôi tiến hành kiểm duyệt sản phẩm một cách ngẫu nhiên, vào những thời điểm bất kì.

Khi tôi thiết lập nó như là một thói quen, tôi tạo ra danh sách các trường hợp lỗi thường gặp và cố gắng nhắc nhở mình thường xuyên.

Nhưng tôi nhận thấy rằng mình muốn đưa nhiệm vụ kiểm duyệt sản phẩm lần cuối vào list những công việc cần làm ngày thứ 2. Vì vậy, tôi đã tạo ra một “backlog” nhỏ để đánh giá lỗi thường xuyên, cố gắng dựa trên kinh nghiệm của người dùng đang sử dụng sản phẩm đó (tương tự như tôi sẽ yêu cầu người dùng làm thử nghiệm khả năng sử dụng)

Ví dụ:

Trước đây khi làm việc cho một công video game, tôi đã sử dụng sản phẩm (chơi trò chơi: D) trong 5-10 phút mỗi ngày.

Nhưng tôi nhanh chóng nhận thấy rằng tôi đã không trải qua những kinh nghiệm với tần suất đủ để hiểu về trải nghiệm người dùng. Tùy thuộc vào từng giai đoạn của vòng đời sản phẩm, mỗi tháng chúng tôi có từ 20% đến 80% số người dùng mới, do đó, tại bất kỳ thời điểm nào, nó là một con số lớn.

Đó là lý do tại sao tôi buộc bản thân phải trải nghiệm sản phẩm mỗi 2 tuần, nhờ thói quen này mà các tính năng mới sẽ luôn phù hợp với trải nghiệm người dùng mới.

3/ Kiểm tra đối thủ cạnh tranh và các sản phẩm liên quan

Tôi tin rằng bất cứ ai làm việc liên quan đến các sản phẩm kỹ thuật đều kiểm tra đối thủ cạnh tranh.

Tương tự như với sản phẩm của tôi, trước khi tôi xây dựng thói quen này tôi đã kiểm tra đối thủ cạnh tranh nhưng vào những theo một cách ngẫu nhiên và với mục đích ngẫu nhiên. Điều này, tất nhiên, đã khiến tôi bỏ qua rất nhiều cải tiến quan trọng, hoặc các tính năng mới không được kiểm soát.

Bây giờ tôi có một danh sách các đối thủ cạnh tranh tôi muốn đảm bảo kiểm tra thường xuyên các đối thủ của mình và cập nhật những thay đổi mỗi tuần.

Tôi cũng có một danh sách các công ty không phải là công ty đối thủ nhưng là nguồn cảm hứng cho sản phẩm của tôi. Ví dụ như Amazon, làm cách nào tôi có thể cải thiện thanh toán dựa trên kinh nghiệm tuyệt vời mà họ cung cấp?

Có một vài trường hợp tôi thường xử dụng, bao gồm cả các công việc ở thói quen #2 để đảm bảo rằng không có bất kì sự trùng lặp thông tin nào

Dựa vào ví dụ cuối ở duóiw, tôi bắt đầu kiểm tra sản phẩm của các đối thủ cạnh tranh trực tiếp, thường xuyên và các sản phẩm có liên quan phổ biến tại thời điểm đó.

4/ Tuần này bạn muốn trả lời câu hỏi gì?

Có thể bất cứ lúc nào, bạn cũng có thể đưa ra những giả thuyết và ý tưởng, và rất có thể có nhiều người sẽ đến mang theo những ý tưởng và giả thuyết khác và thuyết phục bạn thêm chúng vào danh sách của bạn.

Buổi sáng thứ hai là một thời điểm tuyệt vời để tổ chức lại chúng. Trong trường hợp của tôi, chỉ cần trải qua thói quen phân tích KPI, đánh giá sản phẩm và điểm chuẩn, cho tôi cái nhìn tổng thể vấn đề để quyết định ưu tiên trả lời những câu hỏi nào trước.

Cho dù bạn có một “backlog ý tưởng”, một sơ đồ cơ hội-giải pháp, hoặc một danh sách các việc đang làm, tôi vẫn khuyên bạn sử dụng buổi sáng thứ hai để tập trung và đưa ra một câu hỏi bạn muốn trả lời trong tuần đó.

Trở lại trải nghiệm của tôi trong trò chơi game, chúng tôi đã có phiên bản alpha cho một trò chơi mới, tỷ lệ người chơi cao hơn so với phiên đầu tiên. Theo thói quen # 1 chúng tôi đã xác định được một mô hình: chúng tôi thấy rằng khi người chơi đạt đến “Cấp 5”, sự gắn bó của họ tốt hơn nhiều. Vì vậy, cơ hội / giả thiết / câu hỏi mà tôi muốn trả lời trong tuần đó chỉ đơn giản là: điều gì sẽ làm cho nhiều người đạt đến cấp 5?

Tôi sẽ trở lại phân tích ví dụ này ở thói quen tiếp theo.

Hãy nhớ rằng câu hỏi để trả lời có thể liên quan đến nhiều khía cạnh của sản phẩm. Bạn có thể có các câu hỏi nghiên cứu theo định hướng (nghĩa là chúng ta đang giải quyết vấn đề gì?) Hoặc có nhiều đề xuất về giá trị liên quan (ví dụ: ai sẽ muốn tính năng này?). Có rất nhiều lựa chọn. Điều quan trọng là nắm bắt cái gì đó mà bạn muốn có thêm thông tin để đưa ra quyết định sản phẩm.

5/ Thúc đẩy trải nghiệm / tương tác khách hàng

Sau khi chọn một giả thuyết hoặc một câu hỏi mà bạn muốn giải quyết trong tuần này, bước tiếp theo là để suy nghĩ cách để trả lời.

Thông thường, điều này trở nên hoặc là:

Thử nghiệm: thiết lập 1 cửa giả hoặc trang đích để thử nghiệm đề xuất giá trị, giải pháp trợ giúp đặc biệt hoặc bất cứ điều gì bạn có thể chạy nhanh để tìm hiểu về những kết quả có thể xảy ra với những gì bạn dự định xây dựng.
( Hoặc là ) Một cuộc phỏng vấn / kiểm tra khả năng sử dụng: với mục tiêu cụ thể này, hãy đối mặt với khách hàng trong các cuộc đối thoại trực tiếp để tìm hiểu thêm về sản phẩm (trên sản phẩm hiện tại của bạn hoặc một nguyên mẫu cho những ý tưởng mới).

Ví dụ:

Tiếp theo ví dụ “mức 5” của thói quen số 4, chúng tôi đã sử dụng UserTesting.com để thuê 5 người dùng, với 4 nhiệm vụ được dự định để họ chơi trò chơi thông qua các giai đoạn đầu.

2 ngày sau chúng tôi đã có 5 video video 1 giờ sử dụng trò chơi.

Chúng tôi tìm thấy 2 vấn đề:

Một vấn đề về khả năng sử dụng thông thường: khi mà hướng dẫn các bước không rõ ràng, vì vậy chúng tôi đã cố gắng thay hướng dẫn chơi rõ ràng hơn
Thứ hai đòi hỏi một số ngữ cảnh phù hợp: Trò chơi có một “cơ chế năng lượng” đặc biệt, đã cạn dần theo thời gian và người chơi phải đợi cho đến khi nó được sạc lại để tiếp tục chơi (hoặc trả tiền để có thêm năng lượng). Đây là một cơ chế rất phù hợp với các trò chơi online, khá giống với trò chơi Candy Crash là một ví dụ thiết thực nhất.

Chúng tôi phát hiện ra rằng năng lượng này đã cạn kiệt trước khi đạt đến cấp độ 5. Vì vậy, giả thuyết mới chúng tôi tạo ra là: “Nếu người chơi có thể tiếp tục trò chơi của mình mà không có những hạn chế về năng lượng đến cấp 5, nhiều người sẽ đạt được và cải thiện mức độ duy trì tổng thể”.

Vì vậy, quay trở lại mục tiêu ban đầu, chúng tôi đã có thêm thông tin về câu hỏi chúng tôi có trong tuần đó và nó cũng cung cấp một mục tiêu rõ ràng cho tuần sau mà chúng tôi có thể dễ dàng kiểm tra A / B.

Tại sao lại là thứ 2

Đối với tôi, bắt đầu tuần mới với những hoạt động quan trọng cảm giác như mọi thứ đều trở nên cấp bách, nếu không giải quyết sẽ giết chết những điều quan trọng. Và nó cũng cho bạn một cái nhìn về những gì cần tập trung và làm rõ các bước tiếp theo cần làm trong tuần: nếu bạn quản lý một cuộc thử nghiệm mỗi tuần, chắc chắn bạn sẽ làm tốt hơn hầu hết các công ty khác.

Thói quen hàng tuần của bạn là gì? Tôi nên thêm gì vào danh sách?

Tôi hy vọng điều này sẽ giúp người khác xây dựng sản phẩm tốt hơn

Nguồn: blog.topdev.vn via hackernoon

Bí kiếp học front-end của Grab – Phần 3

PHẦN 1 – PHẦN 2

Là phần cuối cùng trong series về bí kiếp học front end của Grab, chúng ta hãy cùng tìm hiểu thêm về những tools được dùng trong giai đoạn cuối của quá trình phát triển front-end cho một web app

Types — Flow

Static typing có rất nhiều lợi ích khi viết app. Nó giúp ta phát hiện ra những lỗi thường gặp từ rất sớm. Types cũng là một hình thức lưu trữ code và nó ảnh hưởng đến tính thẩm mỹ cũng như rất dễ đọc. Khi code base của bạn bắt đầu lớn dần, thì nhờ vào type mà việc sắp xếp lại cũng trở nên dễ thở hơn rất nhiều. Mặt khác, các thành viên mới cũng sẽ nhanh chóng làm quen và bắt kịp với tiến độ nhờ vào việc code được viết gọn gàn và dễ hiểu.

Gần đây, tôi phải sửa lại vài lỗi trong một code base mà cả tháng trời chưa đụng tới. Rất may là nhờ vào types mà tôi không mất quá nhiều thơi kiếm lỗi và sửa chúng.

Hiện nay có 2 ứng viên nổi bật nhất trong static types cho JavaScript là Flow (bởi Facebook) và TypeScript (của Microsoft). Tại Grab, chúng tôi chọn Flow vì nó dễ học hơn so với TypeScript cũng như ít đòi hỏi việc phải thay đổi trong code base. Mặt khác do là đứa con của Facebook, Flow có khả năng tương thích rất tốt với React ecosystem.

Tuy vậy, TypeScript cũng không hề thua kém và việc chuyển giao giữa chúng cũng không tốt mấy công sức do cú pháp cũng khá giống nhau nên việc thay đổi vẫn có thể xảy ra.

Thời gian ước tính: 1 ngày – Flow rất là đơn giản và có thể xem như là một phần mở rộng thêm của JavaScript. Hãy thử cho nó vào project của bạn và chứng kiến sức mạnh kì diệu của Flow.

Links Học

Lựa chọn thay thế

TypeScript

Xem ngay các tin đăng tuyển dụng Front-end lương cao trên TopDev

Build System — webpack

Phần này sẽ được giữ ngắn bởi quá trình setting up webpack đôi khi sẽ rất nhàm chán và dễ khiến developer bỏ cuộc bởi phải học quá nhiều thứ mới khi bước vào thế giới của front end developer. Nói ngắn gọn, webpack là một module bundler với khả năng compile một front end project và các dependencies của nó thành một bundle thống nhất để user sử dụng. Thường thì project đã có sẵn webpack configuration set up và developer cũng rất ít khi chỉnh sửa nó. Tuy vậy bạn vẫn sẽ cần phải có kiến thức về webpack.

Chúng tôi thấy webpack walkthrough của SurviveJS là một nguồn học cực kì tuyệt vời cho những bạn muốn biết về webpack.

Thời gian ước tính: 2 ngày (không bắt buộc)

Links tham khảo

webpack Homepage

SurviveJS — Webpack: From apprentice to master

Tham khảo khác

Rollup

Browserify

Package Management — Yarn

Nếu bạn thử vào xem node_modules directory, hẳn bạn sẽ nhận ra ngay nỗi kinh hoàng khi nhìn vào số lượng đồ số của các directories. Từng babel plugin, lodash function đều là một package riêng rẽ. Và khi bạn cùng lúc phải chạy nhiều project thì số lượng tăng một cách chóng mặt. Như vậy mỗi lần bạn chạy npm install trong một project mới, thì những packages này sẽ được download lặp đi lặp lại dù bạn đã có sẵn trong các project khác trong máy tính của mình.

Mặt khác khi sài npm install thì việc cài đặt rất dễ bị lỗi do các bản update thường chưa những thay đổi khiến cho việc không tương thích lẫn nhau xuất hiện hoặc đơn giản là bị trùng lập các file.

Yarn giúp giải quyết triệt để những vấn đề trên với yarn.lock file, giúp bảo đảm mỗi lần cái đặt đều có file structure giống nhau trong node_modules giữa các máy tính. Yarn cũng tối ưu hóa một global cache directory nhờ đó mà không cần phải download lại những packages bạn đã có. Hơn nữa, nó còn cho phép bạn cài đặt offline luôn.

Một số các Yarn commands nổi bật nhất bạn có thể vào xem tại đây. Thật sự thì chúng đều tựa như npm. Một trong những Yarn command mà chúng tôi thích nhất là yarn upgrade-interactive giúp cho việc dependencies sẽ tự động được update cho các JavaScript project.

Thời gian ước tính: 2 giờ

Links tham khảo

Yarn Homepage

Yarn: A new package manager for JavaScript

Continuous Integration

Tại Grab, chúng tôi dùng Travis CI cho continuous integration (CI) pipeline. Travis là một CI rất nổi tiếng trên Github cũng như build matrix của nó có khá nhiều tính năng vô cùng hữu ích khi bạn phải quản lí nhiều dự án khác nhau như Grab. Chúng tôi cài đặt để Travis thực hiện những nhiệm vụ sau:

Chạy lintingcho project.
Chạy unit tests cho project.
Nếu qua được bài tests:
Test coverage được tạo bởi Jest sẽ được uploaded lên Codecov.
Tạo một production bundle với webpack vào trong một build directory.
tar build directory với <hash>.tarvà upload nó lên một S3 bucket lưu trữ toàn bộ các build của chúng tôi.
Post một notification đến Slack để thông báo về kết quả của Trais build.

Links tham khảo

Tham khảo khác

Hosting — Amazon S3

Thông thường thì web sau khi nhận được request cho một webpage sẽ render nội dung trên server và return một HTML page với nội dung theo yêu cầu của user. Đây còn gọi là server-side rendering. Như đã nói ở phần Single-page Apps, web applications thời nay không đụng tới server-side rendering nữa mà giờ đây ta có thể dùng web server để cung cấp static asset files. Nginx và Apache là 2 lựa chọn khá tốt bởi nó không đòi ta phải bỏ công sức tìm hiểu cũng như setup quá nhiều. Tuy nhiên chúng ta cần phải biết là web server sẽ được điều chỉnh sao cho mọi request route sẽ được tập trung vào một điểm để client-side route có thể tiếp nhận. Dòng chảy cho front end routing sẽ như sau:

Web server nhận một HTTP request cho một route nào đó, như /users/john.
Khi đó server sẽ cung cấp index.html từ static assets directory.
index.html sẽ bao gồm scripts với khả năng load up một JavaScript framework/library với client-side routing.
The client-side routing library sẽ đọc route, và thông báo với MVC framework về nó.
MVC JavaScript framework renders ra view dựa theo thông tin của route đưa đến , thường là sau khi nó thu data từ một API.

Chúng tôi chọn Amazon Simple Storage Service (S3) là bởi vì nó có thể host cũng như hoạt động như một CDN cho nội dung của static website. Thật sự mà nói, S3 là một phương pháp vừa chắc ăn mà phù hợp với túi tiền của chúng tôi.

Một project mà chúng tôi có sử dụng S3 là Hub. Ngoài ra chúng tôi cũng dùng nó để tạo các .tar files từ các Travis build.

Links tham khảo

Lựa chọn thay thế

Google Cloud Platform
Now

Deployment

Bước cuối cùng chính là gửi sản phẩm của chúng ta đến tới user hay nói cách khác là deploy. Chúng tôi sử dụng Ansible Tower, một phần mềm tự động hóa cực kì mạnh mẽ giúp việc deploy build trở nên vô cùng dễ dàng.

Những đã nếu ra trong các phần trước, toàn bộ những build thành công đều được upload lên S3 bucket. Khi các bản update, patch được tung ra thì bản note lại những thay đổi cũng sẽ tự động được cập nhận và gửi tới cho user. Khi một thay đổi được đưa ra, Grab sẽ gửi command tag cho commit tới code hosting. Lúc đó Travis sẽ chạy các bước CI trên commit đó và upload một tar file (ví dụ như 1.0.1.tar) với phiên bản phù hợp với S3 bucket.

Trong Tower, chúng ta chỉ cần đơn giản là đưa ra tên của .tar mà ta muốn deploy nó tới hosting bucket và Tower sẽ làm hết những công đoạn sau:

Download .tar file đó từ S3 bucket

Trích xuất nội dung và điều chỉnh file tùy theo yêu cầu

upload nội dung tới hosting bucket

Gửi tin nhắn báo deploy thành công tới Slack

Tất cả quá trình trên đều diễn ra trong vòng 30 giây, có thể nói là tower đã giúp mọi thứ trở nên dễ thở hơn rất nhiều.

Links tham khảo

Ansible Tower Homepage

Mọi thứ chỉ mới bắt đầu thôi

Chúc mừng bạn đã theo dõi đến giờ này! Thật sự mà nói, phát triển Front end thời nay rất khó nhưng nó cũng trở nên thú vị hơn. Những gì mà chúng tôi vừa viết ra sẽ giúp các developer non trẻ nhanh chóng nắm bắt và theo kịp tiến độ công việc tại Grab. Vẫn còn rất nhiều thứ để học nhưng quan trọng nhất vẫn phải là việc bạn đã có một lượng kiến thức cơ bản vững chắc cái đã. Front end web developer roadmap sẽ giúp bạn hiểu rõ hơn cũng như có thêm nhiều lựa chọn thay thế trong việc chọn học các ngôn ngữ lập trình.

Chúng tôi hi vọng là sau 3 phần của bài viết này sẽ giúp các bạn hiểu rõ hơn về những công nghệ trong front end mà Grab đang sử dụng cũng như có được hướng đi riêng cho mình.

Nguồn: topdev.vn via Medium

Tìm việc IT lương cao, đãi ngộ tốt trên TopDev ngay!

“Luật 5 giây” giúp Steve Jobs thách thức mọi giới hạn sáng tạo

Bạn có biết Steve Jobs là một người cực kì khó tính và dữ tợn? Ông ấy chẳng quan tâm đến gì ngoài hiệu quả công việc. Và “luật 5 giây” khó nhằn của ông hóa ra lại là một bí quyết để giúp nhân viên của mình thách thức mọi giới hạn của sự sáng tạo.

Thomas Koulopoulos, tác giả bài viết này là một nhà báo, một tác giả nổi tiếng và là một nhà lãnh đạo, ông đã có dịp trò chuyện với Steve Wozniak, đồng sáng lập Apple, để hiểu “luật 5 giây” tài tình của Steve Jobs.

Tôi buộc phải thú nhận mình là một kẻ “máu lạnh” đối với đồng nghiệp của mình. Tôi sẵn sàng đối mặt với những thách thức dường như không thể bước qua và mong đợi những người cộng sự của mình sẽ làm điều tương tự. Lớn lên cùng những câu nói khắc cốt ghi tâm của cha tôi, “Lửa thử vàng, gian nan thử sức”. Vì lẽ đó, tôi chẳng mấy ngạc nhiên khi nhìn thấy những người lãnh đạo luôn cố gắng hết sức ở vai trò của mình.

Tôi thật sự rất may mắn vì đã nhiều lần được gặp những người như vậy, nhưng vẫn không sao có dịp gặp Steve Jobs. Dù vậy, tôi đã có lần trò chuyện cùng Steve Wozniak, đồng sáng lập của Apple.

Là một người sử dụng Apple từ những ngày đầu tiên của dòng máy tính Macintosh, tôi phải thừa nhận rằng được gặp Woz là cơ hội ngàn năm có một. Trong buổi họp đầu tiên, chúng tôi nói rất nhiều, từ thước lô-ga (bạn biết đấy, loại thước mà NASA sử dụng trong Apollo 13 để giải quyết những vấn đề toán học rắc rối khiến máy tính bị chậm!), đến chuyện chiếc máy tính đầu tiên của Texas Instruments và cả quan điểm của ông ấy về an ninh mạng.

Rồi chúng tôi cùng nhau lật lại từng trang lịch sử của máy tính, bàn về những năm tháng “chào đời” của Apple, sự phấn khích tột độ khi tạo nên những bước đột phá và lý do tại sao bo mạch được bố trí hợp lí lại được xem là một kiệt tác nghệ thuật.

Cuối cùng thì cuộc trò chuyện cũng ngã hướng về Steve Jobs. Vào thời điểm Jobs công khai rằng, mình cần phải giải quyết một số vấn đề về sức khoẻ, về căn bệnh cuối cùng đã tước đi mạng sống của ông.

Tôi không hiểu mấy về bệnh tình nghiêm trọng của Jobs, tuy vậy, tôi phải hết sức cẩn trọng với ba điều: Bối cảnh của cuộc trò chuyện, những lùm xùm xung quanh mối quan hệ giữa Jobs và Woz và cuối cùng là vai trò hiện tại của Woz. Vì thế, tôi chỉ vô tình đả động nhẹ đến những vấn đề này. Nhưng quả thật tôi rất tò mò về danh tiếng của Jobs, vì ông được xem như một kẻ máu lạnh chẳng quan tâm đến bất cứ điều gì ngoài hiệu suất công việc đạt chuẩn cao nhất. Tôi luôn tự hỏi làm sao Jobs có thể quản lí tốt những nhân viên của mình khi tính cách cá nhân của ông ấy dường như rất “máu lạnh” như thế.

“Ai cũng đều thích được khen ngợi, nhưng sự thách thức sẽ giúp ta cảm thấy hài lòng với những thành quả của mình”.

Đáng ngạc nhiên thay, Woz vô cùng thẳng thắn trước những câu hỏi của tôi. Vì vậy, tôi cũng khá thẳng thắn hỏi rằng, liệu Jobs có phải là một người rất khó để làm việc chung hay không. Câu trả lời tôi nhận được từ Woz khiến tôi nghĩ ngay đến cố vấn Peter Drucker của mình. Một lần tôi đã hỏi ông ấy một câu tương tự, và ông ấy xem rằng đó là câu hỏi hết sức nực cười. “Này, chẳng ai lại đi hỏi câu đó cả” là câu trả lời của ông ấy. Woz cũng đã trả lời tương tự, và sau đó chia sẻ câu chuyện về Steve Jobs trong những ngày đầu tại Apple.

Woz kể rằng, Steve Jobs hay có thói quen xông vào các cuộc họp. Ông ấy lướt một vòng quanh căn phòng, xem xét trực tiếp vấn đề đang được bàn bạc để tìm phương án giải quyết, và không cần đến năm giây để thông báo như sét đánh ngang tai: “Mọi người có thể làm tốt hơn nữa đấy.” Và ngay sau đó mất hút qua cánh cửa phòng. Giọng điệu của ông ta chẳng hề biểu lộ nét thất vọng hay kiêu ngạo gì cả, chỉ vỏn vẹn một câu nói, “Chưa ổn đâu!”

Mệt mỏi với ông già lắm chiêu này, nhỉ? Phản ứng đầu tiên của Woz khi nghe thấy những câu như thế là: “Ông biết cái quái gì mà nói ổn hay không chứ? Này nhé, chúng tôi đã ngồi vắt óc bàn bạc từ sáng đến giờ, đó là điều tốt nhất có thể rồi!”.

Đó quả là một điểm mấu chốt khi Jobs nói rằng, bạn có thể làm tốt hơn thế, và bạn sẽ muốn biết “tốt hơn” là như thế nào.

Khi nghe Woz kể, tôi chợt nhớ đến những đứa con của mình lúc nhỏ, lúc đó tôi đang dạy chúng về cách giải quyết những vấn đề sáng tạo có tên là “Cực điểm Sáng tạo”. Đây là một chương trình “khó nuốt” đối với trẻ con nói chung, vì chúng sẽ phải tự giải quyết những vấn đề phức tạp mà không hề có sự hướng dẫn hay giúp đỡ từ bố mẹ.

Câu hỏi đặt ra ở đây là, cần gì phải có một người hướng dẫn nếu họ không thể giúp bạn tìm ra giải pháp? Đúng vậy, tôi thật sự rất ngạc nhiên khi vai trò chủ đạo của tôi chỉ là khuyến khích chúng tìm ra giải pháp tối ưu hơn thế. Bằng cách đó, chúng sẽ tìm ra cách để phá vỡ mọi giới hạn về sức sáng tạo. Kết quả thật đáng bất ngờ khi chúng hoàn toàn có đủ bản lĩnh để làm tốt hơn những gì chúng đang làm.

Giả sử như thế này, với tư cách là một người lớn đang huấn luyện những đứa trẻ, bạn sẽ có một lợi thế tiềm ẩn, vì chúng sẽ tin ngay khi bạn nói rằng, chúng có thể làm tốt hơn thế. Và đương nhiên, đó là vai trò thực sự của người lãnh đạo. Xét trên nhiều phương diện, có lẽ Jobs đã sai. Ông có những khí chất khiến những hành động và lời nói của mình có sức nặng hơn bao giờ hết. Với tư cách là những nhà lãnh đạo, chúng ta cần phải thiết lập một cơ chế hoạt động cho tổ chức, cho nhân viên, và cho cả chính ta.

Khen ngợi nhân viên cấp dưới khi họ làm tốt là một điều hiển nhiên, vì điều đó sẽ tiếp thêm động lực cho họ. Nhưng trước hết phải mang đến cho họ những thử thách. Ai cũng đều thích được khen ngợi, nhưng sự thách thức sẽ giúp ta cảm thấy hài lòng với những thành quả của mình.

Đừng trở thành kẻ ngủ quên trong chiến thắng. Drucker luôn luôn nhắc nhở tôi rằng vai trò mấu chốt của người lãnh đạo là thử thách mọi người. Ông ấy cảm thấy rằng, đức tính này là giá trị cốt lõi nhất của các nhà lãnh đạo và quản lí. Thông qua những thử thách ấy, chúng ta có thể chứng minh với những người tin tưởng sát cánh bên chúng ta rằng, khả năng của họ đủ để bứt phá mọi giới hạn.

Nhưng hãy nhớ, đừng bao giờ đặt ra những thử thách phi thực tế và không hợp lí. Bạn là một nhà lãnh đạo, không phải một kẻ sát nhân!

Không còn điều gì có thể ý nghĩa hơn khi bạn tạo cơ hội cho một người để họ cảm nhận được rằng, họ thật sự mạnh mẽ, thông minh và kiên cường hơn họ nghĩ. Một người trao cho bạn những trải nghiệm khó quên ấy sẽ là người bạn đi theo đến tận cùng trái đất, dù họ có “máu lạnh” đến mức nào!

Nguồn: brandsvietnam.com

Bí kíp học Front-end của Grab (Phần 2)

Nối tiếp PHẦN 1, chúng ta sẽ tiếp tục đi sâu hơn những tool chúng ta cần biết để làm được một React project một cách dễ dàng nhất.

Quản lí State — Flux/Redux

Khi app của bạn bắt đầu phát triển và bành trướng, bạn có thể sẽ thấy cấu trúc của app bắt đầu trở nên quá lộn xộn. Cho dù Components trong React vẫn hoạt động tốt nhưng cách làm lại khá “thô”. Bời dù sao đi nữa, React vẫn chỉ là view layer, nó không h liên quan hay ảnh hưởng lên cấu trúc của các layer khác trong app, như model và controller. Để giải quyết vấn đề trên, Facebook đã tạo ra Flux, một kiến trúc app bổ trợ cho React bằng cách dùng một dòng data không hướng (unidirectional). Nói tóm gọn thì Flux có những đặc điểm sau:

Dòng data không hướng (Unidirectional data flow) – Giúp cho theo dõi app hoạt động dễ dàng vì có thể check update tùy ý.
Hoạt động độc lập – Mỗi phần trông kết cấu của Flux đều có chức năng rõ ràng và hoạt động độc lập.
Phù hợp với lập trình declarative – updates được truyền thẳng tới view mà không cần phải chuyển đổi giữa các state.

Xem thêm các việc làm front end lương cao cho bạn

Vì Flux không phải là framework nên các developers đã thử nhiều cách thức khác nhau để lợi dụng những đặc điểm ở trên của Flux. Nhờ đó mà Redux ra đời. Redux kết hợp ý tưởng từ Flux, Command pattern và Elm architecture cùng với state management library mà các developer thường dùng cho React:

App state được miêu tả bởi một JavaScript object đơn (POJO).
Dispatch một action (cũng là POJO) để chỉnh sửa state.
Reducer là một pure function với khả năng nhận một state vào và tạo ra một state mới.

Nghe có vẻ đơn giản nhưng thật sự chúng rất mạnh mẽ bởi cho phép apps:

render state trên server và bootup trên client
Trace, log và backtrack những thay đổi trong app
Sử dụng undo/redo function dễ dàng

Cha đẻ của Redux, Dan Abramov, bỏ nhiều công sức để viết tài liệu hướng dẫn đầy chi tiết cho Redux, ngoài ra còn có cả video chỉ cách sử dụng nó với hai level khác nhau là cơ bản và nâng cao. Chúng đều là những nguồn học Redux vô cùng tuyệt vời mà bạn không nên bỏ qua.

Kết hợp view và state

Tuy Redux không bắt buộc phải dùng cùng với React, nhưng bạn nên làm như vậy bởi chúng giúp cải thiện cho nhau rất nhiều. Cả React và Redux đều có những điểm chung như:

Có những chức năng giống nhau – React tạo ra views (pure functions) trong khi Redux tạo ra pure reducers (cũng là pure functions)
Dễ đọc dễ hiểu – Bạn có khả năng kiểm soát và khi có vấn đề thì việc xác định chúng cũng dễ dàng. Với kinh nghiệm của chúng tôi, debug luôn khỏe hơn với React và Redux. Bởi dòng data không hướng (unidirectional data flow) nên việc trace hướng đi của data rất dễ cũng như xác định được nhanh chóng layer nào có lỗi.
Cấu trúc layer (tầng) – từng layer trong cấu trúc của app/ Flux đều được xem là pure function và có chức năng rõ ràng. Nhờ đó mà việc test các layer này cũng khá là nhẹ nhàng.
Trải nghiệm phát triển – Rất nhiều công sức bỏ ra để tạo ra những tools giúp debug cũng như kiểm tra và theo dõi app trong quá trình phát triển như Redux DevTools.

App của bạn sẽ phải đối mặt với những vấn đề từ async calls như API requests. redux-thunk và redux-saga được tạo ra để giải quyết những vấn đề này. Tuy vậy bạn sẽ cần bỏ nhiều thời gian để tìm hiểu về nó nên bạn chỉ nên đụng tới nó khi cần thiết thôi.

react-redux chính là kết hợp React giữa redux và rất dễ học.

Khoảng thời gian để hoàn thành: 4 ngày. Các khóa học sẽ khó xơi hơn nhưng nó hoàn toàn xứng đáng với những gì bạn bỏ ra. Sau khi đã hiểu về Redux thì bạn đã có thể áp dụng nó ngay vào một số React project. Liệu Redux có giải quyết được những vấn đề liên quan tới quản lí state mà bạn gặp phải trước đó.

Links học:

Lựa chọn thay thế

MobX

Coding với Style — CSS Modules

CSS (Cascading Style Sheets) là những tiêu chí mô tả cách hiển thị của HTML. Và viết CSS tốt luôn không phải là chuyện dễ dàng. Thường mất vài năm kinh nghiệm gian khổ mới có thể viết và quản lí CSS ở mức độ cao. CSS, với namespace toàn cầu, vốn được thiết kế cho web documents, chứ không dành cho web app với kiến trúc component. Do đó mà các front end developers lão làng đã tạo ra nhiều phương thức khác nhau để hướng dẫn người mới cách viết CSS dành cho những project khủng như SMACSS, BEM, SUIT CSS, etc.

Có lẽ bạn cũng đã nhận ra, front end ecosystem thật sự bão hòa với tools, và không có gì ngạc nhiên khi tools được tạo ra để giải quyết vấn đề của CSS khi dùng trong những project lớn. Nói cách khác là mỗi người có cách dùng CSS khác nhau và trong thời điểm hiện tại vẫn chưa có cách chính thức để viết CSS trong JS, hi vọng trong tương lai sẽ có cải thiện giống như sự ra đời của Redux. Còn hiện tại thì chúng ta vẫn phải dựa vào CSS Modules. CSS modules là phiên bản nâng cao của CSS nhằm khác phục vấn đề về namespace; nó cho phép bạn viết theo style của mình và encapsulated cho component. Đây là tính năng thông qua sử dụng tool CSS modules, giúp cho team phát triển có thể thoải mái làm modular và reuse CSS mà không phải lo bị xung đột hoặc override các phần khác của app. Tuy vậy, CSS modules vẫn sẽ được compiled thành globally-namespaced CSS để trình duyệt web có thể nhận diện được nên rất quan trọng việc hiểu rõ cách thức hoạt động của CSS.

Nếu bạn hoàn toàn là tay mơ với CSS thì khóa học online HTML & CSS course của Codecademy sẽ là điểm khỏi đầu lí tưởng. Tiếp theo bạn cần đọc Sass preprocessor, một bài viết nâng cao về ngôn ngữ CSS.

Khoảng thời gian để hoàn thành: 3 ngày. Hãy thử nghiệm nhiều style khác nhau như SMACSS/BEM hoặc CSS modules.

Links học

Lựa chọn thay thế

Bảo trì

Chúng ta dành nhiều thời gian để Code hơn là viết chúng. Điều đó càng đúng đối với Grab, khi mà qui mô team rất lớn lại có nhiều project khác nhau. Chúng tôi rất đề cao khả năng dễ đọc trong code, dễ bảo trì cũng như ổn định. Để đạt được những mục tiêu trên thì ta sẽ cần có vài cách sau: “Test mở rộng”, “style code nhất quán” và “type checking”

Testing — Jest + Enzyme

Jest là một testing library của Facebook với mục tiêu đơn giản hóa quá trình testing. Với các project của Facebook, Jest giúp trải nghiệm phát triển trở nên dễ thở hơn rất nhiều. Các bài test được chạy đồng loạt nhằm giúp rút ngắn thời gian. Trong watch mode, được đặt default, chỉ có tests cho những files bị thay đổi là được phép chạy. Một tính năng mà chúng tôi rất thích là “Snapshot Testing”. Jest có thể lưu trữ output của React component và Redux state dưới dạng files nên bạn không phải mất công lo những việc đó. Jest còn có tính năng như built-in mocking, assertion và test coverage. Có thể nói là một “soái ca” lo hết mọi việc.

React có tích hợp sẵn một số testing utilities, nhưng Enzyme bởi Airbnb giúp generate, assert, manipulate và traverse React components’ output dễ dàng hơn với API tương tự như trong jQuery. Vì thế mà chúng tôi khuyến khích bạn dùng Enzyme để test React components.

Jest và Enzyme giúp front end test trở nên nhẹ nhàng và “vui vẻ” hơn. Nó cũng giúp cho các developer bỏ công ra test kĩ lưỡng hơn. Mặt khác, React components và Redux actions/reducers cũng đã khá là dễ cho quá trình test bởi vai trò rõ ràng cũng như interface dễ nhìn. Với React components, chúng ta có thể test props, khi đó DOM sẽ được render, và callbacks sẽ cho phép hiển thị kết quả của user interaction. Với Redux reducers, chúng ta có thể test bằng state và action, với kết quả là một state mới được tạo ra.

Các tài liệu về Jest và Enzyme đều khá là chi tiết nên bạn cứ thoải mái tìm hiểu.

Khoảng thời gian để hoàn thành: 2-3 ngày. Hãy thử dùng Jest + Enzyme tests cho các React + Redux app của bạn!

Links học

Jest Homepage
Testing React Applications with Jest
Enzyme Homepage
Enzyme: JavaScript Testing utilities for React

Thay thế

AVA
Karma

Linting JavaScript — ESLint

Linter là một tool chuyên về phân tích code và xác định lỗi trong chúng cũng như bugs/runtime errors. Ngoài ra, Linter còn giúp coding style được nhất quán. Thời gian cũng được rút ngắn khi Pull request reviews với reviewer không phải mất công ghi comments trên coding style. ESLint là một tool để lint cho JavaScript code với khả năng mở rộng và tính tùy chỉnh. Các team đều có những luật về lint của riêng mình. Tại Grab, chúng tôi dùng Airbnb’s eslint-config-airbnb preset, đã được tinh chỉnh với style coding khá chất lượng trong Airbnb JavaScript style guide.

ESLint thật sự rất đơn giản, cứ như là chỉnh sửa một configuration file vậy. Bãn sẽ không phải học thêm gì nhiều ngoài mấy cái luật do mình đưa ra. Nhưng hãy lưu ý một số lỗi và google style nào tốt nhất.

Khoảng thời gian để hoàn thành: ½ ngày – Chả có gì nhiều phải học cứ cài ESLint vào project của bạn và quất thôi.

Links học

Lựa chọn thay thế

Nguồn: topdev.vn via Medium

Xem ngay những tin đăng tuyển dụng IT mới nhất trên TopDev

“Chuyện thường ở huyện” tại ZALORA

Bạn đã bao giờ thử trải nghiệm 1 ngày làm việc tại ZALORA – nơi được xem là môi trường làm việc lý tưởng của dân công nghệ? Có những điều tưởng chừng rất đặc biệt tại nơi khác nhưng với ZALORA thì đó lại là chuyện thường. Liệu có hấp dẫn thật vậy không? Phải khám phá mới biết!

Văn phòng mới đúng chuẩn kiểu “Silicon Valley”

ZALORA sở hữu văn phòng đặc biệt mô phỏng theo không gian mở của các công ty ở Silicon Valley, nơi trung tâm công nghệ của thế giới, nơi tồn tại những cái tên công nghệ lớn như Google, Facebook, Microsoft, Intel, Uber, Deloitte, PwC… và một loạt các công ty có tên tuổi lẫy lừng khác.

Dạng thiết kế văn phòng mở này chứa đựng nhiều ưu điểm lớn mà ngày nay không chỉ riêng ZALORA mà các công ty công nghệ khác cũng đang dần ưa chuộng theo xu hướng này. Điều ưu điểm đầu tiên có thể nói đến chính là việc cải thiện giao tiếp cho mọi người trong công ty bởi sự gắn kết và thống nhất cho một tổ chức. Theo trích dẫn lời ông Steven Jobs, nhà sáng lập Apple: “Ý tưởng không đến từ phòng họp mà chúng đến từ các cuộc gặp trên hành lang.” Đó là lý do tại sao không gian mở được xem là môi trường làm việc lý tưởng để sáng tạo.

Lợi thế nổi bật tiếp theo ở đây chính là sự đẩy mạnh hiệu quả trong công việc, chưa kể đến một phần còn tiết kiệm được chi phí mở văn phòng với các tiện ích đầy đủ được dùng chung. Không dừng lại ở việc nâng cao chất lượng hiệu quả, thiết kế này còn mang lại không khí tích cực cho môi trường làm việc, giúp cho các nhân viên tại ZALORA cảm thấy thoải mái, hạnh phúc hơn.

Trải nghiệm tool xịn và học hỏi toàn công nghệ mới

Các anh chàng Engineer nhà ZALORA phải nói lúc nào cũng thích thú và hăng say trong công việc. Lý do vì sao ư? Bởi vì mỗi ngày code là mỗi ngày nâng cao tay nghề. Tại ZALORA, các Engineer chẳng bao giờ sợ thiệt thòi vì họ được học hỏi rất nhiều thứ, từ Test Driven Development cho tới việc optimize những chi tiết nhỏ như HTTP Header, kế đó là giao thức HTTP/2. Thỉnh thoảng các anh làm front-end bỗng dưng “không hiểu vì sao chán” thì có thể đổi gió bay qua gõ code Golang cũng rất thú vị.

Làm việc tại ZALORA thì phải nhắc đến các tool xịn cực kì hữu ích để bổ trợ công việc. Có thể nói đến như Slack, AWS stack, còn Deploy code lên live chỉ cần gõ 1 dòng lệnh trên slack. Có phải là quá tuyệt vời không? Chưa nói đến việc hệ thống còn tự động integration test và soi code, quả nhiên là vi diệu. Ấy thế mà mới gia nhập còn được ZALORA cấp cho cả Macbook Pro cực xịn, bước ra đường là sang chảnh, vào công ty là thấy ai ai cũng mang phong thái chuyên nghiệp theo kiểu “tây tây”. Hỏi sao mà dev nào không mê cho được?

Làm việc hiệu quả… xả stress cũng hiệu quả

Mô hình văn phòng mới tại ZALORA còn được trang các thiết bị công nghệ tiên tiến nhất. Mọi người sau khi làm việc còn được giải trí với các tools xả stress vô cùng thú vị như Pingpong, PS4, Foosball, Billiards v.v… Đó cũng là lý do mà các anh chàng dev nhà ZA rất ít khi kêu ca, trái lại họ còn cảm thấy rất thích thú sau mỗi giờ làm việc khi được xả stress hết mình.

Nhưng nhiêu đó vẫn chưa sao kể hết được những đãi ngộ rất riêng mà ZALORA ưu ái dành cho các Engineer của họ. Gia nhập ZALORA là cả một quá trình cho bạn tiến lên và phấn đấu hoàn thiện tay nghề, chưa kể các kỹ năng khác của bạn từ đó cũng dần tiến bộ, điển hình như tiếng Anh, các Engineer sẽ được tham gia khóa học nâng cao và được ZALORA hỗ trợ đến…70% chi phí. Chỉ nhiêu đó thôi đã đủ thấy muốn vào ZALORA làm liền trong hôm nay.

Với các chàng dev mong muốn có thân hình 6 múi đúng chuẩn hay các cô nàng dev cá tính muốn sở hữu dáng bốc lửa thì hãy đến với gym. Thẻ gym tại đây luôn sẵn sàng cho bạn tập luyện, vừa có sức khỏe tốt, vừa là cách xả stress hữu hiệu nếu muốn quên đi các căng thẳng thường xuyên trong cuộc sống.

Đồng nghiệp thân thiện, sếp tâm lý

Tại ZALORA, bạn có thể cùng ngồi chung với team để hỗ trợ, học hỏi lẫn nhau vì mọi người nơi đây luôn thân thiện, nhiệt tình sẵn sàng giúp đỡ. Hoặc bạn cũng có thể ngồi riêng một góc miễn sao bạn cảm thấy phù hợp, nếu gặp khó khăn bạn có thể chủ động xin ý kiến của sếp. Có thể đôi lúc bạn sẽ gặp một vài vấn đề gì đó trong công việc hay kể cả cuộc sống, thay vì cứ giữ khư khư thì hãy tìm đến sếp chia sẻ thử. Biết đâu họ là người có thể cho bạn lời gợi ý và hướng giải quyết tốt nhất thì sao. Ở ZALORA, cứ mạnh dạn chia sẻ.

Để có được những trải nghiệm mua sắm online tốt nhất cho khách hàng thì sự phối hợp chặt chẽ, khéo léo giữa đội ngũ Engineer siêu giỏi và vị sếp lý tưởng chính là cái “keyword” phát triển tại ZALORA. Chưa kể sếp và nhân viên đều có thể vui chơi giải trí thoải mái với nhau sau giờ làm việc. Bạn đã từng thấy vị sếp nào mà thỉnh thoảng chiều chiều hay cùng chơi foosball với anh em hay chưa? Tại ZALORA thì có đó.

Qua những “chuyện thường” ở trên cũng có thể lý giải được phần nào tại sao ZALORA lại có sức hút đối với các Developer đến thế. Nếu bạn cũng đang mong muốn được trải nghiệm môi trường tuyệt vời như tại ZALORA thì đừng chần chờ gì mà không khám phá ngay cơ hội việc làm tại đây

Đếm 123, bạn đã sẵn sàng trở thành Software Engineer (PHP, Java, Python) tại ZALORA hay chưa?

Bí quyết chọn laptop để lập trình

Việc chọn một cái laptop phù hợp cho lập trình đôi khi là một việc rất khó khăn.

Bởi có quá nhiều lựa chọn khác nhau khiến bạn rối cả trí mỗi khi vào google search về chúng. Không những thế mỗi nhãn hiệu điều có những phiên bản khác nhau với điểm mạnh yếu tùy theo nhu cầu sử dụng của từng người.

Có một sự thật là bạn có thể code hầu như trên mọi loại máy laptop hiện nay. Tuy nhiên, năng suất của bạn sẽ tăng đáng kể nếu dùng laptop đúng theo nhu cầu của mình.

Có nhiều lĩnh vực phát triển, tools và ngôn ngữ khác nhau tùy theo ngành học của bạn. Thế nên không thể nào có một cái máy tính toàn năng, phù hợp với mọi yêu cầu mà giá thành lại rẻ được.

Tôi viết bài này là để dành cho các bạn web developer và chỉ có laptop để làm lập trình.

Sau đây là những lưu ý mà bạn cần phải nghĩ tới trước khi ra quyết định mua máy.

Tính di động

Laptop có đủ thể loại với kích cỡ hình dáng khác nhau. Bạn sẽ cần phải xác định rõ bạn muốn tính di động của laptop đến mức nào.

Nếu không phải mang laptop đi nhiều thì bạn nên chọn cỡ 15-inch. Những loại này thì thường được trang bị ngon lành hơn cũng như thực hiện được nhiều task khác nhau cùng một lúc.

Thế nhưng nếu bạn phải di chuyển rất nhiều thì hãy nên dừng ở mức 13~14 inch thôi. Chúng vừa nhẹ mà lại khá tiết kiệm pin.

Trừ khi bạn bắt buộc phải xài hoặc đó là hàng tặng thì đừng nên mua mấy cái laptop có touch-screen bởi nó chả cần thiết trong khi giá thì bị đội lên rất nhiều

Màn hình

Màn hình của laptop chính là thứ quan trọng nhất, đặc biệt là với programmer. Khi phải phát triển các ứng dụng đồng nghĩa với việc nhìn vào màn hình trong một thời gian dài bởi bạn phải tập trung vào rất nhiều chi tiết khác nhau.

Các Laptop giá rẻ thường có màn hình cỡ 1366 x 768, theo tôi thì chỉ thuộc dạng trung bình là cao nhất rùi. Chả đủ không gian để bạn làm nhiều việc cùng một lúc, đã thể chữ hiển thị cũng không đủ rõ để mắt bạn được dễ chịu mỗi khi đọc.

Còn màn hình 4K thì quá là lãng phí bởi bạn chả cần tới nó, chưa kể nó tốn tiền kinh khủng và ăn pin như hạm.

Nói chung, dù là gì đi nữa đừng bao giờ mua laptop mà có màn hình dưới Full HD 1920 x 1080 (1080p). Nếu có tiền thêm chút cho màn hình phân giải tốt hơn thì càng tốt.

Mà hãy chắc rằng bạn thấy thoải mái khi nhìn vào màn hình, không có gì tệ hơn khi nó phản chíu ánh sáng quá nhiều và trông chẳng khác gì một chiếc gương.

Processing Power (CPU)

CPU ảnh hưởng rất lớn đến hiệu năng của laptop thế nên bạn đừng nên ham rẻ xem nhẹ phần này. Có rất nhiều CPU khác nhau tùy vào nhu cầu của người mua. Một số thông số quan trọng bạn cần biết đến bao gồm cache, số core, frequency cũng như khả năng tỏa nhiệt của chúng.

Thường thì Intel core i5 hoặc i7 processor với frequency 3GHz hoặc hơn là lựa chọn tốt nhất cho bạn.

Memory (RAM)

Tôi không nghĩ bất cứ ai mà muốn theo nghiệp lập trình lại chọn mua laptop với ít hơn 4GB ram. Theo tôi, thấp nhất nên là 8 gb ram, với ngần đó cũng chỉ mới vừa đủ chạy một số ứng dụng khá tốn ram. Còn nếu dư dả thì bạn rất nên mua cái 16GB ram.

Ổ cứng – Dung lượng bộ nhớ

SSD (Solid State Drive) nên là một trong những ưu tiên bạn nên cân nhắc tới bởi sự cải thiện rõ rệt trong hiệu năng khi so sánh với các ổ cứng thông thường khác. Với SSD, tốc độ xử lí của OS, compile code. launch app hay load project đều được tăng rõ rệt.

256GB SSD là một khởi đầu tuyệt vời và nếu bạn điều kiện khá giả thì hãy mua 512GB hoặc 1TB SSD. Tất nhiên SSD không rẻ nên bạn chỉ nên để hệ điều hình và những software quan trọng vào SDD và những thứ khác như game, phim, nhạc, etc vào ổ cứng HDD.

Bàn phím

Bạn đừng xem nhẹ điều này bởi bàn phím là nơi mà bạn dùng để gõ code cả ngày đấy. Thường thì tôi sẽ ưu tiên những bàn phím rộng, thoải mái và có nút bấm nhạy.

Quan trọng nhất là bạn phải ngồi thử xài cái bàn phím trước khi ra quyết định có nên mua nó không. Lưu ý là nó phải khiến bạn cảm thấy thoái mái và không bị vướng víu khi gõ văn bản. Bàn phím có khả năng phát sáng trong đêm cũng khá là hay nếu bạn hay viết code vào đêm.

Thời lượng pin

Có thể không quan trọng mấy nếu laptop của bạn luôn được cắm sạc đầy đủ cũng như chả phải mang đi đâu xa. Dù vậy, tiêu chuẩn bạn nên nhắm tới cũng không ít hơn 6 tiếng.

Đừng nghe lời quảng cáo từ hãng mà hãy lên google tìm đọc những bài review của bên thứ 3 về chúng.

Hệ điều hành

Cái này thì không có gì phải nói, tùy vào nhu cầu của bạn mà nó sẽ khác nhau. Window thì bạn sẽ có khá nhiều lựa chọn nhưng nếu thích macOS thì bạn sẽ bị giới hạn với chỉ các dòng Macbook thôi.

Linux thì chạy tốt trên bất cứ máy nào nhưng bạn nên chọn những máy có hỗ trợ Linux chính thức. Thường thì Dell và System 76 về mặt này làm khá tốt.

Card đồ hoạ chuyên dụng hoặc tích hợp

Card rời không thật sự cần thiết cho việc coding thế nên bạn có thể tiết kiệm bằng cách chọn card on-board và lấy số tiền đó cho SDD hoặc CPU.

Và thế là bạn đã có thể tự tin trong việc kiếm cho mình một “chiến hữu” trong con đường trở thành lập trình viên rồi đấy!

Nguồn: blog.topdev.vn via Medium

Bí kíp học Front-end của Grab (Phần 1)

Bí kíp học Front-end của Grab (Phần 1)

Lập trình Front end chưa bao giờ phức tạp và đầy thú vị như thời điểm này. Các tools, libraries, frameworks, và plugins mới cứ thi nhau xuất hiện từng ngày. Có quá nhiều thứ để cho ta học.

Vì vậy mà nhóm lập trình web của Grab luôn cập nhật những công nghệ mới nhất cũng như tích hợp JavaScript ecosystem vào các ứng dụng của công ty.

Do đó mà các thành viên trong nhóm, dù mới hay cũ, cũng đều cảm thấy khá choáng ngợp với khối lượng kiến thức mới cần phải cập nhật. Thế nên chúng tôi đã lập ra một bản hướng dẫn nhằm giúp các bạn học nhanh hơn và theo đúng hướng để có thể navigate ecosystem một cách dễ dàng, cũng như việc shipping code cho user trở nên hiệu quả hơn.

Bài hướng dẫn này lấy cảm hứng từ “A Study Plan to Cure JavaScript Fatigue” cũng như kết hợp với những ý kiến riêng từ các thành viên trong nhóm với mục tiêu là chọn ra những libraries/frameworks phù hợp cho từng lĩnh vực của phát triển front-end cũng như đúng theo nhu cầu tại Grab.

Chúng tôi sẽ giải thích cặn kẽ vì sao những library đó được chọn và gợi ý những nguồn học để người xem có thể nâng cao kiến thức ngay luôn. Ngoài ra, những lựa chọn thay thế cũng sẽ được nêu ra nhằm giúp người đọc có thêm lựa chọn.

Nếu bạn đã rất quen thuộc với front end cũng như liên tục cập nhật công nghệ thì bài viết này có thể sẽ không giúp ích gì nhiều bởi nó dành cho người mới muốn học về front-end.

Và nếu công ty của bạn đang muốn tìm kiếm một JavaScript stack mới thì bài hướng dẫn này cũng sẽ rất hữu ích! Cứ thoải mái sửa đối tùy theo ý bạn. Bài viết sẽ được update thường xuyên nhằm giữ cho tính chính xác cũng như hữu ích cho người đọc.

Lối đi nào cho newbie IT - Front End, Back End hay Full Stack?

Điều kiện tiên quyết phải có trước khi bạn xem tiếp

Nắm vững về khái niệm lập trình
Thoái mái với basic command line actions cũng như quen thuộc với các source code version control systems như Git.
Có kinh nghiệm với lập trình web. Đã từng tạo ra các server-side rendered web apps với những frameworks như Ruby on Rails, Django, Express, etc.
Hiểu rõ cách thức hoạt động của web. Có kiến thức về web protocols như HTTP và RESTful APIs

Những topic chúng tôi sẽ nói đến trong bài viết

Single-page Apps (SPAs)
New-age JavaScript
User Interface
State Management
Coding với Style
Testing
Linting JavaScript
Linting CSS
Types
Build System
Package Management
Continuous Integration
Hosting
Deployment

Cứ thoải mái bỏ qua những topic nào bạn đã biết.

Xem ngay các tin đăng tuyển dụng Front-end lương cao trên TopDev

Single-page Apps (SPAs)

Web developer ngày nay thường ám chỉ sản phẩm của họ là web app chứ không gọi là website nữa. Tuy không có nhiều sự khác biệt nhưng web app có tính tương tác cao hơn cũng như tầm ảnh hưởng lớn hơn, cho phép user thực hiện một hành động và nhận lại kết quả được gửi từ web app.

Bình thường, các trình duyệt web sẽ nhận HTML từ server và render nó. Khi user chuyển hướng đến một URL khác thì full-page refresh sẽ diễn ra và trình duyệt gửi một HTML mới dành cho trang mới mà user muốn xem. Đây còn gọi là server-side rendering.

Thế nhưng trong SPAs đời mới, client-side rendering được sử dụng thay thế cho cách trên. Trình duyệt sẽ load page ban đầu từ server, kèm với scripts (frameworks, libraries, app code) cũng như stylesheets cần thiết cho cả app đó. Khi người dùng chuyển hướng URL, page refresh sẽ không bị kích hoạt. Thay vào đó, URL của page sẽ được update thông qua HTML5 History API. Các data cần thiết cho page mới mà user muốn vào xem, thường là thuộc định dạng JSON, sẽ được thu thập bới trình duyệt thông qua AJAX request tới server. SPA sau đó sẽ update page với data mới bằng JavaScript, vốn đã có sẵn sau khi được download ở initial page. Đây là cách thức hoạt động tương tự như của native mobile apps.

Lợi ích:

App trả lời nhanh hơn và user sẽ cảm thấy page load được nhanh hơn nhờ vào không phải dùng tới full-page refreshes.
Giảm thiểu HTTP requests tới serve cũng như không cần download nhiều data mỗi lần phải load page.
Phân chia rõ ràng giữa client và server; bạn sẽ dễ dàng tạo một client mới cho một platform khác mà không cần phải chỉnh sửa lại code của server. Ngoài ra, việc thay đổi technology stack của client và server đều có thể làm riêng rẽ miễn API contract vẫn được giữ nguyên.

Bất lợi:

Initial page load sẽ nặng hơn do phải download về framework, app code, cũng như các thành phần cần thiết cho nhiều page khác nhau.
Bạn sẽ phải điều chỉnh sao cho requests đều đi qua một điểm và cho phép client-side routing được quyền quản lí ở đầu bên kia.
SPAs dựa trên JavaScript để render nội dung, tuy vậy, không phải tất cả search engine đề chạy JavaScript trong quá trình tìm kiếm khiến cho nội dung thu được sẽ bị thiếu hụt. Kết quả gián tiếp lên việc SEO của app bạn bị giảm hiệu quả.

Mặc dù server-side rendered apps vẫn còn là một lựa chọn tốt, client-server redered apps vẫn thích hợp hơn khi nói đến sự phức tạp cũng như qui mô lớn, đòi hỏi việc client và server code được phát triển và chỉnh sửa độc lập. Điều này rất là chính xác với Grab bởi chúng tôi có tới hàng chục client apps nhưng có chung API server.

Như đã nói, web developers hiện nay tập trung vào việc phát triển các web app hơn là page, nhờ đó cộng đồng JavaScript ngày càng trở nên quan trọng hơn. Trong server-side rendered pages, ta thường dùng snippets của jQuery để thêm tính tương tác user cho từng page. Tuy vậy, với các app lớn thì chỉ có jQuery là không đủ, bởi nó chỉ là một library cho việc điều khiển DOM chứ không phải là framework. App của bạn sẽ không có được một cấu trúc rõ ràng nếu như chỉ dùng jQuery.

Do đó mà JavaScript frameworks được dùng để giải quyết vấn đề trên. Mặt khác việc sử dụng các frameworks quen thuộc cũng rất tiện lợi bởi giúp cho team dễ hiểu về code cũng như app hơn. May thay những framework nổi tiếng thì cũng có nguồn học rất phong phú và cực kì đa dạng.

Links tham khảo:

New-age JavaScript

Trước khi nhảy vào tìm hiểu về cách viết ra một JavaScript web app, bạn sẽ phải làm quen với ngôn ngữ lập trình web – JavaScript, hoặc ECMAScript. JavaScript là một ngôn ngữ cực kì linh hoạt bởi bạn có thể dùng làm web servers, native mobile apps và desktop apps.

Vào 2015, ECMAScript 5.1 chỉ mới được tung ra kể từ 2011. Thế nhưng trong những năm gần đây, JavaScript đã phát triển bùng nổ mạnh mẽ. Trong 2015, ECMAScript 2015 được tung ra với hàng chục tính năng để viết code dễ dàng hơn. Nếu bạn muốn biết rõ thêm thì có viết một bài khá hay là lịch sử và mẹo hay về JavaScript. Cho đến thời điểm hiện tại, vẫn chưa có trình duyệt nào thực sự có thể tận dụng hết tất cả tính năng và sức mạnh của ES2015. Các tool như Babel cho phép developers viết ES2015 trong các app của mình và Babel sẽ chuyển tiếp chúng xuống ES5 để giúp tương thích cho các trình duyệt web.

Biết cả ES5 và ES2015 là rất cần thiết. Bởi ES2015 vẫn còn khá nhiều open source code và Node.js apps vẫn được viết bằng ES2015. Nếu bạn debugging trong trình duyệt console thì có thể bạn sẽ không dùng được ES2015 syntax. Mặc khác, các tài liệu và libraries vẫn còn xài ES2015. Tại Grab, chúng tôi sử dụng babel-preset-env nhằm tăng hiệu năng nhờ vào sự cải thiện trong syntactic của JavaScript. babel-preset-env rất thông minh khi biết xác định các Babel plugins cần thiết (cũng như tính năng nào không thương tích và cần bị chuyển đi) bởi trình duyệt web đang tăng khả năng native support dành cho nhiều tính năng của ES hơn. Nếu bạn muốn dùng một số tính năng ngôn ngữ chạy ổn và bảo đảm, bạn có thể tìm thấy tại babel-preset-stage-3, một list các tính năng và thông số kĩ thuật sẽ được áp dụng trong trình duyệt web.

Hãy dành 1 đến 2 ngày để khám phá và tìm hiểu ES5 cũng như ES2015. Những tính năng nổi bật trong ES2015 bao gồm “Arrows and Lexical This”, “Classes”, “Template Strings”, “Destructuring”, “Default/Rest/Spread operators”, and “Importing and Exporting modules”.

Khoảng thời gian để hoàn thành: 3–4 ngày. bạn có thể học/tìm hiểu về syntax khi học về các libraries cũng như trong quá trình viết ra một app cho mình.

Links tham khảo:

Learn ES5 on Codecademy
Learn ES2015 on Babel
ES6 Katas
Free Code Camp
You Don’t Know JS (Advanced content, optional for beginners)

User Interface — React

Khi nói đến các JavaScript projects hấp thụ hệ thống front end ecosystem nhiều nhất thì React sẽ phải đứng đầu. React là một library với open-sourced được tạo ra bởi Facebook. Trong React, developer viết các components cho web interface và kết hợp chúng lại với nhau.

React khuyến khích các developer luôn tìm tòi, suy nghĩ cách thức sử dụng tốt nhất. Các web developer luôn được dạy rằng nên viết HTML, JavaScript và CSS riêng rẽ. React thì hoàn toàn ngược lại, nó khuyến khích ta viết HTML và CSS trong Javascript của mình. Nghe có vẻ thật điên cuồng nhưng sau khi bạn thử thì nó sẽ trở nên có lí hơn. Đó là nguyên nhân việc có sự thay đổi trong việc phát triển front-end với mô hình component làm chủ đạo. Các tính năng của React:

Declarative (tuyên bố): bạn mô tả điều mà bạn muốn thấy chứ không phải cách để có được nó. Vào thời của jQuery, developers phải nghĩ ra rất nhiều bước để điều khiển DOM nhằm từ app state này sang cái khác. Trong React, bạn chỉ cần thay đổi state trong component luôn và mọi thứ sẽ tự động update theo state. Ngoài ra cũng rất dễ để xác định cách component sẽ như thế nào nhờ vào render() method
Functional: View thật sự chỉ là function của props và state. Trong phần lớn các trường hợp, một React component sẽ được define bằng props (external parameters) và state (internal data). Với props và stateđó thì view sẽ được tạo ra. Pure functions rất dễ để test và điều đó cũng đúng với functional components. Nguyên nhân cho việc test trong React rất dễ dàng là bởi vì component’s interfaces đã được define rất kĩ và bạn chỉ cần thay đổi props và state để so sánh kết quả output thu được của render.
Maintainable (Bảo trì): Khi viết view theo component-based fashion cũng sẽ giúp tăng khả năng tái sử dụng. Chugn tôi nhận ra rằng khi define một component của propTypes khiến cho người đọc React code hiểu rõ hơn về những thứ cần có cho component đó. Mặt khác, view và logic của bạn sẽ tự động chứa trong component, và nó sẽ không bi ảnh hưởng hay tác động đến các component khác. Nhờ đó mà việc thay đổi các component dễ dàng hơn, miễn là props vẫn được giữ nguyên.
Hiệu năng cao – Bạn hẳn cũng từng nghe qua rằng React sử dụng một DOM ảo (khác với shadow DOM) và nó re-renders lại mọi thứ khi state có thai đổi. Vì sao lại cần một DOM ảo? Đó là vì dù JavaScript engine khá nhanh, việc viết và đọc từ DOM vẫn còn chậm. Do vậy, React sẽ có sẵn một phiên bản ảo của DOM trong bộ nhớ. “Re-rendering mọi thứ” là một cụm từ bị dùng sai. Trong React thì re-rendering lại thực chất chỉ diễn ra trong phiên bản ảo của DOM. Như vậy khi có bất kì thay đổi trong data của component, một hiện thị (ảo) được tạo ra và so sánh với phiên bản cũ. Những khác biệt (nằm trong phạm vi cho phép) sau đó sẽ được patch nhờ vào DOM (thật) của trình duyệt.
Dễ học – Học React rất dễ. React API trông rất là nhỏ gọn khi bạn thử so sánh với một library khác. Bạn chỉ cần học một vài API và chúng có rất ít thay đổi. Hơn nữa, cộng đồng React rất lớn, có hẳn một ecosystem riêng cho tool, open-sourced UI components, và vô số nguồn học online vô cùng hữu ích cho bạn.
Kinh nghiệm của Developer – Có rất nhiều tools giúp cho developer lên trình rất nhanh với React. React Developer Tools là một browser extensioncho phép bạn xem và kiểm tra component, view cũng như tinh chỉnh props và state của chúng. Hot reloading với webpack cho phép bạn theo dõi các thay đổi của code trong trình duyệt của mình mà không cần phải refresh nó. Lập trình Front end đòi hỏi việc phải tinh chỉnh code rất nhiều, save rồi refesh trình duyệt. Hot reloading giúp bạn bỏ qua bước cuối cùng. Mỗi khi library được update, Facebook sẽ cung cấp một codemod scripts để giúp bạn chuyển code của mình lên APIs mới. Điều này khiến cho quá trình update trở nên thật nhẹ nhàng.

Qua nhiều năm, các view libraries với hiệu năng cao hơn cả React đã bắt đầu xuất hiện. React có thể không còn nhanh nhất nữa nhưng nếu xét về hệ ecosystem, trải nghiệm người dùng cũng như lợi ích thì nó vẫn là một trong những top libraries. Ngoài ra, Facebook cũng đang tập trung để phát triển React khi hãng bỏ công ra viết lại các thuật toán gốc cho nó. React giúp chúng ta viết code một cách gọn gàn hơn, tốt hơn cũng như để việc bảo trì và phát triển web app dễ dàng hơn.

Chúng tôi khuyến khích bạn nên thử qua lập trình một game Tic Tac Toe trẹn React homepage để hiểu rõ hơn về nó. Để hiểu sâu hơn về React, bạn có thể vào học khóa React Fundamentals cực kì hữu ích của tác giả của React Router, một chuyên gia trong cộng đồng React. Create React App là một tool khác giúp giản đơn các tính năng của React nên rất phù hợp cho người mới học React.

Khoảng thời gian để hoàn thành: 3–4 ngày. Hãy thử làm những project đơn giản như to-do list, Hacker News clone với React. Bạn sẽ tăng level rất nhanh và có thể gặp phải một số vấn đề mà React cũng không giải quyết được, và như vậy chúng ta sẽ đến topic tiếp theo trong phần 2…..

Links học

Một số lựa chọn khác

Đừng bỏ lỡ những bài viết hay về Front-end:

TopDev via Medium

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

Một số lời khuyên nhanh để tiếp cận Trí tuệ nhân tạo

Để tiếp cận được trí tuệ nhân tạo nên bắt đầu như thế nào?

Đầu tiên cần hiểu cách máy tính nhìn nhận thế giới, bằng cách xây dựng được model, chuẩn hóa dữ liệu, ví dụ cần xử lý ảnh, video, âm thanh, xử lý chuỗi rồi cho ra input đầu vào….

Sau đó cần làm quen với các thuật toán tiếp cận gần đúng và tổng quát, là đặc trưng kiểu trí tuệ nhân tạo, kể cả đơn giản như dùng giải thuật di truyền, sinh ngẫu nhiên tập kết quả và chọn ra kết quả tốt nhất dựa trên sai số với hàm lượng giá là thấp nhất, học không giám sát chỉ là phân cụm dữ liêu, về cơ bản các mạng nơ ron cũng là lặp lại sao cho sai số là thấp nhất.

Cuối cùng là áp dụng thử vào các bài toán thực tế, như phân loại dữ liệu, nhận dạng số, khuôn mặt..v.v

Deep learning về cơ bản không phải là thuật toán gì cao siêu, bản chất của trí tuệ nhân tạo không nằm ở thuật toán cao siêu mang tính tuyệt đối, mà nó nằm ở khả năng có thể học cực tốt, không giới hạn, học sâu thể hiện qua mạng nơ ron rất nhiều lớp, học thêm, học tất tần tật, và chắc là không giống như dùng nhiều trick để xử lý dữ liệu đầu vào siêu chuẩn và nhận dạng bằng máy tính thường, học sâu học bất kỳ, như captcha là học cả ảnh nhiễu chứ ko cần bóc tách.

Về tương lai trí tuệ nhân tạo có thể phát triển mạnh dạng các service và chúng ta build model, sau đó tái sử dụng kết quả training. Bởi vì sau khi train xong, chúng ta có mạng nơ ron được hiệu chỉnh trọng số, dùng để thực hiện nhiệm vụ cơ bản nhất là reduce đầu vào thành tập nhỏ kết quả đầu ra để quyết định, và tương lai gần thì robot cũng không lắp kịp một CPU đủ khả năng tính toán siêu khủng để thông minh như con người, nên chắc sẽ cập nhật kết quả học từ server, mà nghe nói chỉ để đánh cờ thắng con người cũng đã cần server khủng rồi, nên thực tế nhất nên sử dụng nó vào data mining ví dụ như recommendation system.

Nguồn: Thanhtu Pham

8 câu hỏi phỏng vấn dành cho các lập trình viên Mobile app

Cơ hội việc làm dành cho các mobile dev đang ngày càng mở rộng với số lượng tăng cao các doanh nghiệp ứng dụng công nghệ mobile vào công việc kinh doanh của mình.

Vì vai trò này rất quan trọng đối với các startups tương lai, việc tuyển chọn các ứng viên managers phù hợp đòi hỏi tính chọn lọc cao và rất khắt khe.

Nếu bạn là 1 dev mobile app tài năng và đã từng ứng tuyển vào các công việc ở mảng này, bạn có thể đọc tiếp. Chúng tôi liệt kê danh sách 8 câu hỏi mà bạn có thể nhận được khi đi phỏng vấn cho vị trí Mobile Apps Developer

1. Loại smartphones mà bạn sử dụng là gì?

Đúng là câu hỏi vô nghĩa nhỉ! Bạn đang lập trình ứng dụng cho di động, tất nhiên smartphone của bạn phải là 1 trong các công cụ chính. Tôi đoán là bạn sẽ chẳng có vấn đề gì khi trả lời câu hỏi này nhưng nếu bạn thể hiện sự quen thuộc và kiến thức sử dụng nhiều hơn 1 hệ điều hành/ thương hiệu thì sẽ tốt hơn nhiều.

2. Kể tên 3 mobile apps mà bạn thích

Nếu bạn chọn lập trình app là nghề nghiệp mà bản thân theo đuổi, bạn phải cập nhật kiến thức về những apps mới nhất. Người quản lý mảng tuyển dụng sẽ muốn bạn luôn thử nghiệm và kiểm tra nhiều app khác nhau, từ đó đưa ra những tiêu chuẩn chắc chắn về những điểm được xây dựng tốt và những điểm cần cải thiện trong app. Đảm bảo chắc chắn là bạn sở hữu vài app yêu thích trong smartphone của mình và sẵn sàng thảo luận về chúng từ chức năng đến các điều kiện lập trình.

3. Bạn đã từng tham gia quy trình làm app được đưa lên iTunes hay Android stores?

Đây là lúc để bạn phô diễn về công việc và kinh nghiệm của bản thân. Hãy chỉ ra vai trò của bạn trong giai đoạn lập trình của mỗi dự án và những khó khăn bạn gặp phải khi tạo app. Nếu bạn chưa từng làm app chuyên nghiệp, bạn có thể khoe khoang những app mà bạn tự lập trình hoặc trong các bài tập thực hành tại trường. Tạo 1 nguồn app mở trước khi nộp đơn xin việc là 1 ý tưởng tốt.

4. Hãy nói cho chúng tôi vài điểm bất lợi của cả Android và iOS

Nếu bạn đang lập trình 1 app cho 1 platform chuyên biệt, bạn nên biết những điểm bất lợi của nền tảng đó. Đây là lúc bạn có thể đề cập đến các vấn đề kỹ thuật mà bạn gặp phải khi phát triển cho mỗi platform, cũng như những giải pháp cho các vấn đề đó. Chú ý là các ví dụ mà bạn cung cấp phải cụ thể.

5. Điểm khác biệt giữa lập trình ứng dụng desktop/ web so với lập trình ứng dụng di động?

Các màn hình và kích thước khác nhau, tốc độ kết nối đa dạng, khả năng tiêu thụ pin, giới hạn dung lượng bộ nhớ… là những vấn đề ở các thiết bị mobile và hãy cho nhà tuyển dụng thấy bạn thực sự biết cách quản lý, kiểm soát chúng.

6. Làm thế nào để giải quyết các vấn đề bảo mật?

Bảo mật luôn là vấn đề nhạy cảm, đặc biệt là khi đề cập đến các thiết bị di động. Thể hiện kiến thức của bạn về bảo mật và các ý tưởng để giảm thiểu các vấn đề bảo mật trong app. Theo tin mới nhất, chẳng phải có 1 cuộc tấn công vào phần mềm gần đây sao? Hãy đề cập đến nó và chuẩn bị các giải pháp cho vấn đề này.

7. Vai trò quan trọng của giao diện người dùng/ trải nghiệm người dùng (UI/UX) trong lập trình ứng dụng di động?

Giao diện người dùng và trải nghiệm người dùng trở thành chìa khóa thành công của các ứng dụng mobile, vì vậy chắc chắn các nhà tuyển dụng sẽ đặt ra cho bạn rất nhiều câu hỏi liên quan đến UI/UX. Nêu rõ ý kiến và các mẹo của bạn để tận dụng tốt nhất giao diện mobile. Bạn có thể chỉ ra app nào mà bạn nghĩ có UI tốt và những app UI không tốt. Ngoài ra, 1 số doanh nghiệp có thể yêu cầu bạn vẽ nhanh 1 giao diện.

8. Bạn đã từng tích hợp app từ 1 platform sang 1 platform khác chưa?

Hầu hết các apps đều sử dụng được nhiều hơn 1 hệ điều hành, vì thế việc học cách cấu hình lại hoặc chuyển app từ 1 platform sang platform khác là 1 phương án tốt. Hãy kể về kinh nghiệm trong lĩnh vực này và nêu chi tiết về những app mà bạn đã từng cấu hình lại cũng như các giải pháp mà bạn đã thực hiện. Nếu bạn không có bất kì kinh nghiệm nào, hãy trình bày lý do bạn nghĩ bản thân đã chuẩn bị kỹ thuật cho nó.

Giải pháp của JobFluent

Rèn luyện sự tự tin, đảm bảo an toàn khi phỏng vấn bằng cách tự đặt câu hỏi cho bản thân. Đây là vài ví dụ dành cho bạn:

Bạn đã từng sở hữu dự án lập trình nào chưa?

Thể hiện sự hứng thú với những gì bạn đang làm, phân tích chi tiết và đưa ra vài gợi ý liên quan đến dự án.

Bạn có viết code review không?

Một trong những cách nhanh nhất để phát triển thành 1 developer là để người khác đọc và trả lời trên code của bạn. Những review code thường xuyên đồng nghĩa là team của bạn đang tốt dần lên.

Ok, bây giờ thì bạn đã sẵn sàng rồi! Hãy tìm hiểu về công ty mà bạn đã ứng tuyển và thể hiện thái độ tốt và sự tự tin nào. Chúc may mắn!

Nguồn: Jobfluent

Xem ngay những tin đăng tuyển dụng IT mới nhất trên TopDev

Chiếc nón học tập – Ai cũng nên biết!

Tiến trình Đọc – Học – Vọc hay Biết – Hiểu – Hành nói ra thì dễ nhưng cứ phải tới khi đụng và ngã ngửa rồi mới hiểu ra và khi có được động lực kèm môi trường thì chịu học.

Bạn sửa bài cho, rồi đọc lại tôi mới thấy những cái bị sửa đơn giản vô cùng và toàn là những cái tôi đã biết và hiểu nhưng tôi chẳng nhớ, chẳng dùng. Bạn bảo bởi “passive learning”, tức học thụ động, được hiểu rằng chỉ có nạp và xử lý rồi để đấy mà không hành. Với ngôn ngữ, nó là chuyện đọc nhiều, nghe nhiều, biết phát triển ý, biết đặt câu hỏi nhưng không chủ động nói, không viết thường xuyên và sử dụng những gì đã học vào quá trình này, vậy nên biết nhưng không làm được.

Cái hình dưới của nhà giáo người Mỹ Edgar Dale ra đời cách đây cũng tầm 70 năm nhưng vẫn còn xài được. Nó cụ thể hóa cái quá trình trên bằng mấy con số và mấy cách thức mà Dale đã khảo sát và nghiên cứu. Tháp đồ đơn giản này có ý nghĩa quan trọng trong định hình phương pháp giảng dạy chủ động, kết hợp các hình thức khác nhau để kích thích mọi giác quan của người học. Với người học, họ cũng có thể tham khảo để biết cách học chủ động sao cho tiếp thu hiệu quả và thực hành được chính xác những gì đã học.

Cách đây mấy hôm tại Sài Gòn, vị tỉ phú người Mỹ, Jeff Hoffman, người là đồng sáng lập và giám đốc của mấy công ty du lịch siêu bự, dạng trùm thế giới cũng nói về chuyện học chủ động kết hợp với các phương tiện kỹ thuật số để phục vụ cho đổi mới sáng tạo. Ngoài việc chia sẻ các công nghệ mới đang định hình lại cách ta học tập, làm việc, và tầm quan trọng của khai thác các công nghệ này như (thực tế ảo, hologram, gương thông minh, …), ông cũng chỉ một cách nữa nằm ở trên đỉnh của tháp đồ Dale, là đọc. Hãy đọc thật nhiều và đọc mỗi ngày. Đọc sách là chuyện hiển nhiên rồi, nhưng hãy đọc thêm những tài liệu khác. Đọc mọi chủ đề chứ không chỉ 1 chủ đề. Vì bài nói của ông đề cập đến đổi mới sáng tạo, ông cho hay chính nhờ mỗi ngày dành ra 10 phút đọc những cái mới hay những chủ đề khác lạ so với chuyên ngành của mình trong suốt 30-40 năm nay mà ông, một kỹ sư, mới mang đến những thành công từ việc biết áp dụng những kiến thức từ ngành khác vào đổi mới lĩnh vực du lịch. Ông học chủ động bằng cách áp dụng nó ngay vào công việc của mình.

Tài liệu về đọc, học chủ động trên mạng cũng nhiều, chịu khó tìm kiếm thì có cả đống để đọc đó nghen.

Nguồn: Gương Nga

Developer Việt còn thiếu gì để thành công?

Sở hữu trên 100 giải thưởng lớn nhỏ về công nghệ thông tin trong và ngoài nước, là tác giả của ứng dụng BusMap với hơn 300 000 lượt tải; là người trẻ nhất trong số 10 gương mặt được trao giải “Quả cầu vàng”-giải thưởng do T.Ư Đoàn TNCS và Bộ Khoa học – Công nghệ tổ chức, sinh viên duy nhất trong danh sách 6 Công dân trẻ tiêu biểu 2014, một trong 7 sinh viên Việt Nam thực tập tại Google, và còn vô số những thành tích mà chàng trai 23 tuổi- Lê Yên Thanh đã đạt được những thành công khiến người khác phải khâm phục.

Tuy nhiên, hôm nay tôi gặp Yên Thanh không phải tư cách là gương mặt trẻ tiêu biểu, hay chàng trai vàng của công nghệ Việt Nam, càng không phải người từ chối Google để về Việt Nam làm Start-up. Tôi gặp Yên Thanh với tư cách là một Backend Developer của Umbala-đấu trường ngôi sao. Chúng tôi nói về những câu chuyện về nghề lập trình, kinh nghiệm xây dựng sản phẩm, những tiềm năng và cơ hội cho developer Việt.

Yên Thanh có thể chia sẻ về công việc hiện tại của bạn

Mình đang làm Back-end tại Umbala. Hiện tại Umbala đang thực hiện một dự án hợp tác với Viettel triển khai các gói giá trị gia tăng, khi người dùng đăng kí 1 gói 4G của Viettel có thể sử dụng ứng dụng Umbala miễn phí, ngoài ra còn có những dịch vụ nạp tiền vào ứng dụng, sau này sẽ có nhiều tiện ích được tích hợp trong ứng dụng Umbala. Chính vì vậy, bên cạnh làm back-end mình còn phụ trách cả phần thuê máy chủ, bảo mật vào nội dung bên trong của ứng dụng.

Bạn có thể nói rõ hơn về ứng dụng Umbala

Umbala là một sản phẩm tạo video clip với nhiều hiệu ứng vui nhộn, độc đáo, thú vị. Tính năng đặc biệt nhất giúp Umbala khác biệt so với các ứng dụng video hiện tại có trên thị trường là các hiệu ứng hình ảnh có thể tự điều chỉnh theo tiết tấu nhạc. Hiện nay chưa có nhiều ứng dụng làm được điều đó. Chất lượng video tốt, thỏa mãn thị giác người dùng, cũng chính là 1 điểm killer features của ứng dựng Umbala.

Hiện tại Umbala đang phát triển theo hướng tương tác real time. Tương tác Real time giải quyết được các nhu cầu thực tế từ các nhà quảng cáo. Không giống như các sản phẩm quảng cáo banner hay hiển thị không thể đo lường được hiệu quả quảng cáo. Với tương tác thời gian thực- Real time tất cả mọi thứ đều diễn ra cùng 1 lúc nên có thể đo lường chính xác hiệu quả quảng cáo trong thời gian thực. Chính vì vậy việc nhận diện thương hiệu cũng trở nên hiệu quả hơn. Hơn thế nữa, vì sử dụng video nên có thể dễ dàng thêm bất kì nội dung gì theo yêu cầu từ nhà quảng cáo.

Trong quá trình triển khai dự án Yên Thanh có gặp khó khăn gì không?

Với dự án phối hợp với Viettel, do hiện tại Viettel đang sử dụng hệ thống viết bằng swap còn hệ thống của Umbala viết API bằng resfull, vì vậy gần như phải xây dựng hệ thống lại từ đầu. Với hệ thống SMS truyền thống chỉ chủ yếu là nhắn tin cú pháp nhưng trong dự án này yêu cầu nhiều hơn thế, chính vì vậy, cần phải làm cho nó tương thích với ứng dụng của mình cũng là một bài toán cần phải giải quyết.

Với đặc thù User ở Viêt Nam chỉ tập trung vào một số khung giờ nhất định nên phải thiết kế hệ thống có khả năng tự Scale để tối ưu hóa chi phí nhất có thể. Bên cạnh đó Umbala cũng đang nỗ lực để cải thiện tốc độ tải cũng như chất lượng Video để giúp người dùng có được trải nghiệm tốt nhất.

Đã từng có cơ hội được làm việc ở nước ngoài tại sao Thanh lại trở về Việt Nam?

Tuy làm việc nước ngoài cuộc sống tốt hơn, còn ở Việt Nam có nhiều thứ rất khác, đặc biệt khi làm việc ở 1 StartUp thì càng có nhiều vấn đề, và gần như mình phải tự thân vận động toàn bộ, không ai hỗ trợ mình.

Nhưng mình cảm thấy ở Việt Nam còn rất nhiều cơ hội, nếu bây giờ không nắm bắt sẽ bị những người giỏi khác cướp mất.

Làm việc ở công ty lớn khác gì với làm cho Start-Up

Ở công ty lớn sẽ ít việc hơn vì công việc được chuyên môn hóa cao, hệ thống tốt hơn, có thể yêu cầu máy chủ, mua framework đều rất đơn giản. Làm ở công ty lớn không cần phải tốn thời gian để xây dựng hệ thống cấu trúc máy chủ. Còn ở công ty Start-Up luôn phải đối mặt với áp lực deadline, khối lượng công việc nhiều vì vậy OT là chuyện rất bình thường, và luôn phải giải quyết vấn đề tối ưu hệ thống tiết kiệm nhất nhưng mang lại hiệu quả cao nhất.

Nhưng làm việc ở công ty Start-Up mình được tự quyết định cái mình muốn, không phụ thuộc vào người khác.

Theo Yên Thanh lập trình viên Việt Nam mình còn yếu và thiếu ở điểm nào?

Mình thấy ở Việt Nam xét mặt bằng chung lập trình viên còn thiếu về kinh nghiệm, ở giai đoạn này mình không phải thiếu kiến thức nền nữa, cái quan trọng là phải có kinh nghiệm. Không chỉ là kinh nghiệm làm việc mà còn phải có kinh nghiệm về quản lý nữa: kinh nghiệm phỏng vấn lập trình viên, phân công công việc như thế nào cho phù hợp. Những điều đó chỉ có thể có được qua tích lũy qua những trải nghiệm của bản thân, không có sách vở nào dạy những điều đó. Phải vừa có kiến thức nền vừa có kinh nghiệm làm việc thì mới hoàn hảo được. Dù có kiến thức tốt nhưng không có kinh nghiệm thì chỉ có thể làm công ăn lương sẽ luôn bị người có kinh nghiệm chỉ đạo. Còn nếu có kinh nghiệm mình sẽ tự đi được.

Một điểm nữa là lập trình viện Việt Nam mình còn hơi yếu về tư duy, chủ yếu về tư duy theo kiểu software engineer, chỉ biết làm theo yêu cầu. Tức là chỉ biết Input và Output rõ ràng, không có tư duy sản phẩm. Điều mình hướng tới không phải là Software Engineer mà là Product Engineer, phải tư duy về mặc sản phẩm. Mình Không chỉ nghỉ mình làm tính năng gì, bấm cái nút đó ra làm sao, mà mình phải nghĩ là người dùng sẽ được cái gì, tức là khi làm tính năng đó thì người dùng sẽ tương tác ra sao, cảm nhận của người dùng như thế nào.

Vậy làm thế nào để khắc phục được những yếu điểm đó?

Muốn có tư duy tốt phải chủ động sáng tao, phải đọc sách nhiều, phải học người khác cách họ tư duy như thế nào, học cách tư duy trong mọi vấn đề của cuộc sống. Đặc biệt với những bạn làm Outsourcing đừng để bị chi phối bởi lối tư duy Software Engineer, vì làm như vậy một thời gian sẽ bị vùi đầu vào việc Input – Output sẽ không còn khả năng tư duy sáng tạo như vậy rất nguy hiểm.

Yên Thanh có dự định gì cho riêng mình không?

Hiện tại mình đang cố gắng để trở thành Full Stack có thể build một hệ thống hoàn thiện. Làm quản lý không nhất thiết phải làm hết mọi thứ nhưng mình cần biết bên dưới làm những gì, phân công nhiệm vụ cho từng người phù hợp để không chỉ phát huy được năng lực của nhân viên mà còn phát triển được doanh nghiệp của mình. Hiện tại mình cũng đang ấp ủ một dự định nhưng chưa có thời gian thực hiện, phát triển ứng dụng Umbala là ưu tiên hàng đầu của mình lúc này.

Cảm ơn Yên Thanh vì những chia sẻ thú vị, chúc cho những kế hoạch, dự định của bạn sớm được thực hiện.

Cùng khám phá sức mạnh của ES6 Generators

Generators có thể xem như là cách áp dụng của iterables

Điều khiến generators trở nên đặc biệt bởi vì chúng là những functions có khả năng hoãn lại quá trình execution mà vẫn giữ nguyên được context.

Đây là một tính năng rất quan trọng khi ta phải dùng tới những executions đòi hỏi phải có quãng pause nhưng context phải được để nguyên nhằm để recover lại trong tương lai khi cần đến.

Bạn có từng nghe qua quá trình phát triển async chưa?

Syntax – Cú pháp

Syntax (Cú pháp) cho generators bắt đầu với function* declaration của chính nó (nhớ lưu ý cái asterisk) và yield dành cho khi generator muốn dừng (pause) execution.

function* generator() {
    // A
    yield 'foo'
    // B
}

Với next function, chúng ta có thể kiểm soát được quá trình tạo ra một generator từ generator sẵn có.

Khi chạy next function, thì code của generator sẽ được thực hiện (execute) và cho đến khi gặp yield thì sẽ ngừng lại.

Lúc đó, yield sẽ xen vào và khiến cho generator execution bị đình chỉ (pause).

const g = generator()

g.next() // { value: 'foo', done: false }
// Our generator's code A gets executed
// and our value 'foo' gets emitted through yield.
// After this, our generator's execution gets suspended.

g.next() // { value: undefined, done: true }
// At this stage the remaining code (i.e. B) gets executed.
// Because no value is emitted we get 'undefined' as the value,
// and the iterator returns 'true' for iteration done.

yield được sinh ra cùng lúc với generator và cho phép chúng ta đưa ra các giá trị mà mình muốn. Tuy nhiên, nó chỉ thực hiện được khi ở trong phạm vi của generator.

Nếu thử dùng yield với một giá trị trong callback thì cho dù đã declared trong generator thì nó vẫn sẽ bị lỗi.

function* generator() {
    ['foo','bar'].forEach(e => yield e) // SyntaxError
    // We can't use 'yield' inside a non-generator function.
}

yield*

yield* được tạo ra nhằm có khả năng gọi một generator nằm trong một generator khác.

function* foo() {
    yield 'foo'
}

// How would we call 'foo' generator inside the 'bar' generator?
function* bar() {
    yield 'bar'
    foo()
    yield 'bar again'
}

const b = bar();

b.next() // { value: 'bar', done: false }
b.next() // { value: 'bar again', done: false }
b.next() // { value: undefined, done: true }

Bạn có thể thấy b iterator, thuộc bar generator, không hề chạy như đúng ý ta khi call foo.

Đó là mặc dù foo execution cho ra một iterator, nhưng ta sẽ không có lặp lại (iterate) nó được.

Vì thế mà ES6 cần có operator yield*

function* bar() {
    yield 'bar'
    yield* foo()
    yield 'bar again'
}

const b = bar();

b.next() // { value: 'bar', done: false }
b.next() // { value: 'foo', done: false }
b.next() // { value: 'bar again', done: false }
b.next() // { value: undefined, done: true }

Đồng thời nó cũng hoàn toàn có thể áp dụng với data consumers

for (let e of bar()) {
    console.log(e)
    // bar
    // foo
    // bar again
}

console.log([...bar()]) // [ 'bar', 'foo', 'bar again' ]

yield* có khả năng kiểm tra và chạy qua hết tất cả ngõ ngách trong generator để yield ra phần nó cần.

function* bar() {
    yield 'bar'
    for (let e of foo()) {
        yield e
    }
    yield 'bar again'
}

Generators cũng chính là Iterators

Generators thực chất là những iterables đơn giản. Nói cách khác chúng cũng sẽ theo luật của iterable và iterator .

Luật của iterable cho ta biết một object sẽ nên return một function itera với key là Symbol.iterator.

const g = generator()

typeof g[Symbol.iterator] // function

Còn luật của iterator cho ta biết iterator nên là một object chỉ tới yếu tố tiếp theo của iteration. Object này phải chứa một function gọi là next

const iterator = g[Symbol.iterator]()

typeof iterator.next // function

Bởi vì generators là iterables nên chúng ta có thể dùng data consumer for-of, để iterate (lặp lại) giá trị của generators (values).

for (let e of iterator) {
    console.log(e)
    // 'foo'
}

Return

Chúng ta còn có thể add vào return cho generator, thế nhưng return sẽ hoạt động hơi khác đi tùy thuộc vào cách generators’ data được iterated.

function* generatorWithReturn() {
    yield 'foo'
    yield 'bar'
    return 'done'
}

var g = generatorWithReturn()

g.next() // { value: 'foo', done: false }
g.next() // { value: 'bar', done: false }
g.next() // { value: 'done', done: true }
g.next() // { value: undefined, done: true }

Khi ta thực hiện iteration bằng tay, sử dụng next, sẽ nhận được returned value (i.e. done ) cũng chính là value cuối của iterator object và khi done đưa ra kết quả true.

Mặt khác, khi sử dụng defined data consume như for-of hoặc destructuring thì returned value sẽ bị bỏ qua.

for (let e of g) {
    console.log(e)
    // 'foo'
    // 'bar'
}

console.log([...g]) // [ 'foo', 'bar' ]

yield*

Như bạn đã biết yield* được tạo ra nhằm có khả năng gọi một generator nằm trong một generator khác.

Ngoài ra, nó còn cho phép chúng ta lưu trữ value returned bằng executed generator.

function* foo() {
    yield 'foo'
    return 'foo done'
}

function* bar() {
    yield 'bar'
    const result = yield* foo()
    yield result
}

for (let e of bar()) {
    console.log(e)
    // bar
    // foo
    // foo done
}

Throw

Chúng ta có thể dùng throw trong một generator và next sẽ truyền exception ra.

Và khi một exception bị đẩy ra, iterator (lặp) sẽ bị phá và state của nó sẽ được set thành done: true

function* generatorWithThrow() {
    yield 'foo'
    throw new Error('Ups!')
    yield 'bar'
}

var g = generatorWithReturn()

g.next() // { value: 'foo', done: false }
g.next() // Error: Ups!
g.next() // { value: undefined, done: true }

Generators cũng chính là Data Consumers

Generators ngoài khả năng như một data producers, với yield, nó cũng có thể consume data khi dùng next.

function* generatorDataConsumer() {
    // A
    console.log('Ready to consume!')
    while (true) {
        const input = yield; // B
        console.log(`Got: ${input}`)
    }
}

Có một vài điểm khá thú vị sau đây

// (1)
var g = generatorDataConsumer()

// (2)
g.next() // { value: undefined, done: false }
// Ready to consume!

// (3)
g.next('foo') // { value: undefined, done: false }
// Got: foo

Generator Creation (1)

Ở stage này, chúng ta đang tạo ra generator g.

Và execution sẽ dừng lại tại điểm A.

Next đầu tiên (2)

Execution đầu tiên của next giúp cho generator được executed cho tới khi gặp phải yield.

Tất cả các giá trị (value) trong stage này khi đi qua next sẽ bị lơ đi. Nguyên nhân là vì vẫn chưa có gặp một yield nào cả.

Và execution của chúng ta chỉ dừng lại tại điểm B khi một value nào đó được đưa ra bởi yield.

Next tiếp theo (3)

Lúc này thì value đã đi qua yieldvà như vậy execution sẽ bị ngừng lại.

Hãy dùng Cases

Implement Iterables

Bởi generators là một iterable implementation, khi chúng được tạo ra thì chúng ta cũng sẽ có một iterable object với từng yield đại diện cho một giá trị sẽ được đưa ra trên từng iteration. Nói cách khác chúng ta có thể dùng generators để tạo ra iterables.

Ví dụ sau đây sẽ thể hiện generator như là iterable với khả năng lập một dãi các số nguyên cho tới khi nó đạt max. Và ta cũng dùng for-of để lập những giá trị trên.

Các bạn cũng cần lưu ý rằng yield sẽ khiến các execution bị dừng lại tại một điểm và các iteration sẽ khiến cho execution chạy tiếp tại các điểm đó.

function* evenNumbersUntil(max) {
    for (let value = 0; value <= max; value += 2) {
        // When 'value' is even we want to 'yield' it
        // as our next value in the iteration.
        if (value % 2 === 0) yield value;
    }
}

// We can now user 'for-of' to iterate over the values.
for (let e of evenNumbersUntil(10)) {
    console.log(e)
    // 0
    // 2
    // 4
    // 6
    // 8
    // 10
}

Asynchronous Code

Ta còn có thể dùng generators với những async code như promises.

Tiện thể thì cũng coi như là để giới thiệu về async/await trên ES8.

Ví dụ dưới đây cũng sẽ cho ta thấy cách tìm kiếm một JSON file nhờ vào promises. Đây là ví dụ của Jake Archibald thuộc developers.google.com.

function fetchStory() {
    get('story.json')
    .then(function (response) {
        return JSON.parse(response)
    })
    .then(function (response) {
        console.log('Yey JSON!', response)
    })
}

Nhờ vào co library và một generator, code của chúng ta sẽ nhìn giống như synchronous code.

const fetchStory = co.wrap(function* () {
    try {
        const response = yield get('story.json')
        const text = yield JSON.parse(response)
        console.log('Yey JSON!', response)
    }
})

Với async/await thì nó vẫn sẽ khá giống so với phiên bản trên

async function fetchStory() {
    try {
        const response = await get('story.json')
        const text = await JSON.parse(response)
        console.log('Yey JSON!', response)
    }
}

Lời Kết

Dưới đây là một map thể hiện mối quan hệ giữa generators và iterators, bởi Axel Rauschmayer trên Exploring ES6.

Generators chính là một cách thực hiện của iterable và nó dựa theo luật của iterable của iterator . Vì thế mà chúng có thể dùng để tạo ra iterables.

Tính năng tuyệt vời nhất của Generator là khiến execution bị hoãn lại. Với yield nếu xài ES6.

Không những thế với yield*, ta còn có thể gọi một generator nằm trong một generator khác.

Generators chính là cách thức để giúp việc phát triễn không đồng bộ trở thành đồng bộ.

Nguồn: Topdev via Medium

Java đang ngăn cản sự phát triển của Android và Kotlin không phải là cách giải quyết

Dưới đây là một số chia sẽ của Topdev tổng hợp được cho bạn về Android và Kotlin.Quá trình phát triển của Android từ 5 năm về trước như thế nào? Java đang ngăn cản sự phát triển của Android và Kotlin không phải là cách giải quyết.

Hãy cùng tìm hiểu thêm từ bài viết dưới đây:

Java quá là rườm rà

Bnh thường thì bạn có thể dùng 2 phương pháp calls để làm nó nhưng với Java thì lại phải OOP rất nhiều cho cái solution rồi chạy code generation bởi với Google thì đó là cách duy nhất cho in-app purchase API. Như vậy, với một ngôn ngữ mà bạn không thể nào dùng callback khi thiếu class và platform (phụ thuộc rất nhiều vào hành vi không đồng bộ) thì kết quả là một đống code hỗn tạp lộn xộn.

Mặc dù Kotlin có giúp cho mọi chuyện bớt phức tạp hơn khi sử dụng cấu trúc nhôn ngữ hiện đại hơn. Tuy vậy, Android APIs vẫn được thiết kế để sử dụng với Java. Để cho công bằng thì Google thật sự đã cố gắng để đưa ra nhiều cải thiện với Java 8 support cho Android Studio 3.0 tuy nhiên nó sẽ cần mất nhiều năm nữa chúng ta mới thấy được thành quả của chúng.

Bản chất chậm chạp của Java khiến cho việc phải bỏ nhiều công sức hơn vào quá trình phát triển của một app

vòng đời hoạt động/dịch vụ/phát triển của các Android events quá phức tạp. Rất nhiều developer không hiểu rõ về nó cũng như bạn sẽ chẳng thể yêu cầu ai cũng bỏ quá nhiều thời gian chỉ để sử dụng chúng một cách rành rọt. Trong thời đại mà các ngôn ngữ đề cố gắng đơn giản hóa mọi thứ như iOS hoặc Windows Phone thì Java lại khiến mọi thứ phức tạp hơn.

Kotlin thì thêm overhead vào runtime, thế nhưng nó lại khiến cho ta phải bỏ ra thêm nhiều công sức hơn. Hị vọng rằng với Android reactive libraries mới cùng tính năng automated app lifecycle sẽ giúp khác phục vấn đề trên.

Ứng dụng nặng với quá trình xử lí phức tạp khiến cho việc thực hiện các iteration nhanh trở nên bất khả thi và làm cho Andiord không thân thiện với người dùng

Nếu bạn muốn ứng dụng của mình sử dụng được Google APIs, Firebase hay một libraries của nhóm thứ 3 mà vẫn giữ được tốt độ lặp nhanh (iteration) thì phải có một workstation với CPU và SSD cực khủng. Google hiện vẫn đang tập trung đầu tư phát triển Java nhưng nó vẫn chưa thật sự thích hợp cho máy tính phổ thông chạy tốt ở thời điểm hiện tại. Như vậy các developer sẽ phải chi tiền ra để nâng cấp máy tính của mình và như vậy phần lớn bộ phận người dùng sẽ bị cho ra rìa. Theo tôi, các ngôn ngữ lập trình phải thật đơn giản và tiện lợi cho người dùng để họ có thể tạo sản phẩm phù hợp với mình chứ không thể đi theo hướng ngược lại khi mà bắt họ phải tự bơi hoặc là chết chìm được.

Kotlin cũng hỗ trợ các libraries cũng đòi hỏi việc ta tốn nhiều chi phí nếu bạn thật sự muốn nó đoàng hoàng. Ít ra thì Google cũng đang cố gắng giải quyết vấn đề trên bằng cách cải thiện quá trình tối ưu hóa của nó.

Web Apps

Rất vui khi Google I/O tung bố Android web app integrations. Google có lẽ đã hiểu rằng để Android có thể phát triển thì phải tập trung vào mảng web apps cho nó.

Trong tương lai không xa thì sẽ không ai dùng Java hay Kotlin để làm app cả. Google đang rất nổ lực để cải thiện tình hình trên khi hãng liên tục hỗ trợ cộng đồng lập trình viên của Java. Và Topdev hi vọng web app sẽ trở lại một cách huy hàng trên ngôn ngữ lập trình Java và Kotlin.

Nguồn: Topdev via Hackernoon

Tham khảo thêm các vị trí tuyển dụng lập trình android tại đây

Tình hình AI tại thị trường Việt Nam – Đầy khó khăn và thách thức

Cứ thử nhắc tới “artificial intelligence”, “machine learning”, hay “neural nets” cho bất kì nhóm software engineers nào mà bạn gặp, tôi bảo đảm bạn sẽ nghe một đống chuyện từ họ. Trong thời đại này, tất cả các ông lớn về công đều sẵn sàng chi mạnh tay để có thể tối ưu hóa những công nghệ đấy vào sản phẩm của họ. Kể cả những cá nhân software engineer trẻ cũng cố gắng tham gia vào mỏ vàng trên.

Artificial intelligence thực chất chính là cách ta tái tạo và mô phỏng theo trí não của con người. Mục tiêu là để cho ra đời những bộ máy có khả năng nhận ra những chi tiết mà chỉ có con người mới hiểu được như cảm xúc. Và đó không phải là một điều dễ dàng. Chính vì thế mà hôm nay, Vietcetera phỏng vấn anh Herve Vu Roussel, Head of Data Engineering tại AI firm Sentifi, để chia sẻ về những suy nghĩ của anh về AI tại Việt Nam. Chúng ta sẽ hiểu thêm về một trong những người đi đầu về Vietnam’s AI cũng như cộng đồng và khả năng phát triển cho AI tại thị trường Việt Nam.

Tình hình phát triển AI của Việt Nam như thế nào?

Đây là một câu hỏi khó. Bởi không như San Francisco hay Montreal, Vietnam’s AI vẫn chưa thật sự được phát triển hết tiềm năng của nó. Chúng ta vẫn còn đang đi lên. Nói đến một số cá nhân/ tổ chức nổi bật thì tôi nghĩ tới Tinypulse và Trusting Social. Với khảo sát, phân tích cảm xúc, natural language processing, Tinypulse nhắm tới cải thiện tinh thần cho nhân viên và khiến họ gắn bó với công ty. Trusting Social, theo tôi, là một ngôi sao đang lên. Là đối tác với Viettel, công ty vừa kêu gọi vốn thành công lên đến vài triệu đô. ý tưởng đằng sau Trusting Social là liên quan đến việc tính toán và phỏng đoán các con số. Khá là thú vị bởi khả năng ứng dụng cho nhiều lĩnh vực khác nhau của nó.

Tôi nghĩ thì hiện tại Sentifi vẫn đang đứng đầu những công ty mạnh về AI tại Việt Nam. Chúng tôi là công ty đi tiên phong về sử dụng mảng trí tuệ nhân tạo trong non-trivial applications. Nhóm data engineering của chúng tôi sử dụng machine learning, deep learning, và AI để phân tích hơn một tỉ tweets mỗi tháng để thu được insight từ đám đông. Sau đó dựa vào những data đó chung tôi liên hệ với những phân tích từ thị trường tài chính. Đó là cách giải thích đơn giản nhất mà tôi có thể đưa ra. Điều làm khác biệt Sentifi với các đối thủ khác nằm ở việc các sản phẩm của hãng đều tích hợp những công nghệ đi đầu thị trường Việt Nam

Tôi tin rằng trong tương lai không xa, AI sẽ giúp cải thiện chất lượng dịch vụ tại Việt Nam. Ví dụ như giờ bạn đã có thể khám online, có một AI chuyên theo dõi sức khỏe và chăm sóc nhắc nhở bạn hay việc gửi hình X-quang để cho nó phỏng đoán bệnh tình mà không hề thua kém một bác sĩ thực thụ.

Có cộng đồng AI nào lớn tại Việt Nam không?

Thật không may là hiện tại vẫn chưa có. Chỉ vài nhóm nhỏ lẻ trên Facebook với tính tương tác thấp. À mà tháng 3 vừa rùi, IBM AI XPRIZE có tổ chức sự kiện AI đầu tiên tại Việt Nam. Với hơn trăm người tham dự. Bạn có thể nói mọi người đều rất tò mò và muốn tìm hiểu về AI nhưng phần lớn đều chưa có kinh nghiệm hay đủ trình độ để hiểu sâu về nó. Vì vậy mà chúng tôi cũng đang cố gắng thúc đẩy AI tại Việt Nam nhưng nó sẽ mất thêm một khoảng thời gian nữa lận.

Từng làm việc vài lần với AI XPRIZE cũng như hướng dẫn nhiều teams tại Việt Nam, XPRIZE là một tổ chức phi lợi nhuận chuyên khuyến khích tranh tài nhằm cải thiện kiến thức chung của thế giới. Tổ chức này cũng lên một kế hoạch phát triển AI trong vòng 4 năm nhằm giải quyết các vấn đề nan giải của nhân loại. Phần thưởng cho team thắng cuộc là 5 triệu đô và cơ hội được diễn thuyết tại TED 2020. Ngoài ra nhiều công ty và nguồn lực sẽ hộ trợ cho các nhóm tham gia XPRIZE. Tôi muốn gửi thông điệp rằng Việt Nam có tiềm năng rất lớn trong AI.

Nói về công việc của tôi với XPRIZE, tôi chủ yếu nắm vai trò hướng dẫn và giúp các team Việt Nam. Hiện các nhóm đều có cho mình những project khá thú vị. Như Altoera với ý tưởng kết hợp computer vision, hardware, và software nhằm tạo ra tính năng image recognition để phát hiện sâu bệnh của cây trồng. Hiện mọi thứ chỉ ở software nhưng trong tương lai thì chúng tôi sẽ phát triển cả robot để chúng theo dõi và diệt trừ sâu bệnh luôn. Một project khác cũng rất có triển vọng là Dropdeck, với ý tưởng kết nối các nhà đầu tư với startup entrepreneurs và giúp bảo đảm các startup có thể tìm kiếm nguồn vốn đầu tư dễ dàng hơn.

Tham khảo các vị trí tuyển dụng AI lương cao tại đây:

03 AI Engineer 1*** USD – VNIB Vietnam tuyển dụng
AI Engineer 2*** USD – Asilla tuyển dụng
AI Engineer 2******* – 3******* VND – 24H Media tuyển dụng

Lời khuyên của anh đối với những bạn muốn đột phát vào ngành này?

Hãy tìm kiếm thông tin tuyển dụng của các công ty AI và vào làm cho họ. Ngoài ra hãy có những project của riêng mình cũng như tham gia một số cuộc thi trên Kaggle. Ngoài ra còn rất nhiều nguồn online với hình thức tượng tự như Coursera, gồm các khóa học từ các đại học danh tiếng trên thế giới. Không có lí gì mà bạn không thể tự học trong hời đại internet này.

Điều gì đang cản trở sự phát triển của AI tại Việt Nam?

Một trong những vấn đề lớn nhất là đầu vào quá khó. Mất 1 đến 2 năm chỉ để nghiên cứu tìm hiểu là chuyện thường ở huyện, rồi việc thiếu hụt về sức người – không có đủ người giỏi hiểu biết về machine learning cũng như data scientists. Hơn nữa, AI còn khá mới lạ, ngay cả trên thế giới thì số lượng công ty chuyên về trí thông minh nhân tạo cũng còn khá ít, như vậy sẽ khiến chi phí cho phát triển tăng rất nhiều.

Một vấn đề nan giải khác tại Việt Nam là việc có quá ít dữ liệu và thông tin. Mà khi nói về AI thì data luôn đứng top quan trọng hàng đầu. Việt Nam rất nghèo về khoảng này. Nói chi đâu xa, khi bạn xài Google Maps, thỉnh thoảng sẽ có những đường không hề có trên map. AI thực chất chính là việc chúng ta thu thập và sử dụng data để tạo ra nó. Như vậy nếu không có dữ liệu thì AI coi như chết.

Cái nữa là việc phát triển AI vẫn chưa được ủng hộ và khuyến khích tại Việt Nam. Bởi vì do giá lao động còn thấp nên việc áp dụng AI thật sự không hiệu quả. Đơn cử như việc dùng robot bảo vệ. Nội tiền phát triển và bảo trì nó thôi đã mắc gấp mấy chục lần việc thuê bảo vệ. Vậy AI chỉ thực sự có đất dụng võ khi người Việt mình được cải thiện về đời sống về có mức lương cao.

Tuy vậy, giờ chúng ta đã bắt đầu nghiêm túc hơn về vấn đề trí thông minh nhân tạo. Bạn có thể thấy Google đang dần trở thành một công ty về AI. Điều Việt Nam có thể làm là đẩy mạnh nhiều chương trình cho data engineering, data mining, và databases. Nhưng quan trọng nhất là tạo ra một cộng đồng và nuôi dưỡng nó. Thật may là công nghệ phát triển rất nhanh. Hồi 10 năm trước, để kiếm được việc liên quan tới AI có thể gọi là không thể bởi nó như chỉ dành cho phim ảnh viễn tưởng thôi. Nhưng giờ thì các start-up AI bắt đầu xuất hiện trên toàn thế giới.

Anh có muốn gửi lời chia sẻ gì đến các bạn đọc không?

Bởi việc AI trở nên khá hot nên nhiều startup cứ áp dụng nó tùm lum vào mọi thứ họ có thể. Tôi mong các bạn start-up nên nhớ quan trọng nhất vẫn là sản phẩm của mình có khả năng giải quyết vấn đề thật cho khách hàng thật vẫn là điều quan trọng nhất, AI chỉ là một phương tiện giúp ta đạt được điều đó.

Nguồn: Vietcetera

3 phút làm quen với Vue.js

Vue.js là một thư viện Javascript để xây dựng giao diện người dùng. Năm ngoái nó bắt đầu trở nên khá phổ biến đối với các nhà phát triển web. Nhẹ, tương đối dễ học và mạnh mẽ là ưu điểm của nó.

Bài viết này, trang bị cho một số kiến thức để bắt đầu xây dựng các ứng dụng Vue.js cơ bản. Nào cùng tìm hiểu thôi!

Mẫu cú pháp và dữ liệu

Cốt lõi của Vue.js là một cú pháp mẫu đơn giản như sau:

<div id="myApp">
    {{ message }}
</div>

Ghép chúng với đoạn code JavaScript sau:

var myApp = new Vue({
   el: '#myApp',
   data: {
       message: 'Hello world!'
   }
})

Và nó sẽ cho ra kết quả Hello world! Đang được hiển thị trên trang web.

Phần el: #myApp yêu cầu Vue hiển thị ứng dụng bên trong phần tử DOM bằng id của myApp. Đối tượng data là nơi đặt dữ liệu bạn muốn sử dụng trong ứng dụng của mình. Chúng tôi đã thêm một khoá vào đây, message, và tham chiếu trong HTML của chúng tôi như sau: {{ message }}.

Vue quan tâm liên kết đối tượng data đến DOM, vì vậy nếu dữ liệu thay đổi, trang cũng sẽ được cập nhật.

Đây được gọi là declarative rendering. Bạn chỉ cần chỉ định những gì bạn muốn cập nhật và Vue sẽ biết thực hiện điều đó.

Bạn có thể thay đổi dữ liệu bằng cách này:

myApp.message = 'Some new value';

Directives

Khái niệm tiếp theo bạn sẽ cần phải học là directives. Directives là các thuộc tính HTML có tiền tố v-, thể hiện cách chúng phản ứng với DOM được hiển thị.

Giả sử chúng ta chỉ muốn render một cái gì đó nếu điều kiện là đúng và ẩn nó đi nếu điều kiện đó là sai. Thì chúng ta sẽ sử dụng v-if.

Trong HTML, nó trông như thế này.

<div id="app">
    <p v-if="seen">Now you see me</p>
</div>

Trong JavaScript:

var app = new Vue({
    el: '#app',
    data: {
        seen: true
    }
})

Điều này sẽ dẫn đến việc hiển thị đoạn “Now you see me” nếu thấy trong dữ liệu là đúng. Để ẩn đoạn văn, bạn có thể đặt thành false, như sau:

app.seen = false;

Ngoài ra có rất nhiều directives khác, như v-for, v-on, v-bind và v-model.

Xử lý Input của người dùng

Một directive quan trọng bạn cần phải học là v-on. Nó sẽ nối một event listener vào phần tử DOM, để bạn có thể xử lý Input của người dùng. Bạn chỉ định loại event sau dấu hai chấm. Vì vậy, v-on:click sẽ “lắng nghe” các cú nhấp chuột.

<div id="app">
    <button v-on:click="myClickHandler">Click me!</button>
</div>

myClickHandler đề cập đến khóa có cùng tên trong các đối tượng methods . Không cần phải nói, đó là đối tượng mà bạn đặt các method của ứng dụng. Bạn có thể bao nhiêu method mà bạn muốn.

var app = new Vue({
    el: '#app',
    methods: {
        myClickHandler: function () {
            console.log('button clicked!');
        }
    }
})

Điều này sẽ giúp nút đăng nhập chuyển người dùng đến giao diện điều khiển khi nhấp vào nút.

Kết hợp tất cả lại với nhau

Bây giờ chúng ta hãy tạo ra một ví dụ mà chúng ta sử dụng cả dữ liệu và method, kết hợp những gì chúng ta đã học được cho đến bây giờ.

<div id="app">
    <p>{{ message }}</p>
    <button v-on:click="changeMessage">Click me!</button>
</div>

Cùng với JavaScript:

var app = new Vue({
    el: '#app',
    data: {
        message: 'Start message'
    },
    methods: {
        changeMessage: function () {
            this.message = 'The message has changed!'
        }
    }
})

Ban đầu, nó sẽ hiển thị thông báo “Start” trên trang, tuy nhiên sau khi nhấp chuột nó sẽ hiển thị thông báo này đã thay đổi để thay thế.

Từ khóa this đề cập đến trong ví dụ của Vue này chúng tôi gọi là app. Trong trường hợp này, dữ liệu của chúng ta đã tồn tại, vì vậy chúng ta có thể tham khảo dữ liệu message thông qua this.message.

Hy vọng với những kiến thức cơ bản về Vue.js được cung cấp trong bài viết đã đủ để giúp bạn hiểu về Vue.js và có thể bắt đầu tạo các ứng dụng đơn giản với Vue.js.

Tham khảo thêm các việc làm VueJS lương cao tại Topdev.

Nguồn: freeCodeCamp

[Tài liệu] Ebook Kotlin for Android Developers

Dành cho những nhà phát triển muốn tự học trong thời gian ngắn. Nó sẽ chỉ cho bạn các bước để tạo một Ứng dụng Android sử dụng Kotlin làm ngôn ngữ chính. Bạn sẽ học theo tốc độ của riêng mình mà không mất thời gian làm các bài kiểm tra thử và sai.

Với Kotlin dành cho Nhà phát triển Android, bạn sẽ học được:

Cách tạo ứng dụng Android từ đầu bằng Kotlin. Tất cả những điều cơ bản bạn cần để tạo một ứng dụng.
Cách áp dụng ngôn ngữ cho Android. Các tính năng độc quyền cho Android và tương tác với khuôn khổ.
Cách sử dụng các công cụ phát triển, tích hợp Kotlin vào Android Studio và sử dụng nó trong các dự án của bạn.
Thông qua các ví dụ và cách viết mã, mọi thứ đều thực tế 100%

Donwload tại đây

Tuyển dụng lập trình android hấp dẫn tại Topdev

UX Tips – Web tốt phải load nhanh dưới 2 giây!

Như thế nào là 1 trang web có UX tốt? Muốn trở thành UX Design thì các bạn lập trình viên cần lưu ý điều gì? Tất cả đã được giải đáp tại buổi phỏng vấn của TopDev với anh Trần Trọng Thanh – người đồng sáng lập của Nâu Studio xoay quanh những kinh nghiệm quý giá liên quan đến UX/UI.

Xem thêm: Việc làm ux designer lương cao

1/ Được biết Nâu Studio hoạt động thiên về Thiết kế, nên ắt hẳn công ty mình sẽ mạnh về UX/ UI Design – lĩnh vực còn chưa phát triển nhiều tại thị trường Việt Nam?

Vì được vấn đề đó nên mục tiêu và định hướng ban đầu khi thành lập công ty là muốn đào sâu về Front End và UX/UI. Tụi anh làm ra những sản phẩm cho khách hàng & mang tính duy nhất, không dùng đến template, bootstrap hay những CSS frameworks. Nâu Studio hầu hết đều code lại từ đầu, làm sao để giao diện, theme của mình hoàn toàn khác biệt. Tất nhiên bên mình cũng sử dụng những nguyên tắc, chuẩn mực UX cơ bản nhất để build như các best practices về vị trí đặt button, menu, kích thước font…

2/ Vậy 1 bạn lập trình Web muốn tìm hiểu về UX thì các bạn cần phải tập trung vào những điểm nào?

Thực ra đối với các lập trình viên, đầu tiên các bạn khoan quan tâm đến UX mà hãy rèn luyện kĩ năng lập trình của mình trước. Khi đã thuần thục rồi, thì lúc đó mới bắt đầu thoát ra hơn, suy nghĩ thêm những thứ liên quan đến trải nghiệm người dùng, những thứ không nằm trong bài vở mà thuộc về kinh nghiệm. Khi nói về UX, đòi hỏi các bạn phải làm nhiều, đồng thời phải có những tích lũy về kiến thức như đọc những bài viết, sách UX liên quan

Thực sự là ở Việt Nam mình cũng chưa có những trường lớp nào chuyên dạy UX 1 cách bài bản. Nếu có thì hầu hết vẫn dừng ở mức sử dụng công cụ, còn để thực sự hiểu UX thì mình cần có nền tảng liên quan đến principles. Trong đó anh thấy 1 cuốn sách rất hay mà các bạn nên đọc là Don’t Make Me Think, phù hợp với cả những bạn chưa biết gì về UX Design. Quyển này đặt ra những vấn đề tuy rất hiển nhiên nhưng chúng ta hầu như không để ý, hệ thống hóa lại các vấn đề đó thành những principles. Từ những kiến thức nền tảng đó, các bạn mới đọc đến những cuốn sách đi sâu vào thực tế.

Ngoài ra khi bắt tay vào làm giao diện thiết kế, việc bắt chước điều hoàn toàn bình thường. Hãy nghiên cứu những trang web được giải thưởng vì đây là những showcase rất hay để học hỏi.

3/ Khi tuyển dụng các bạn lập trình viên cho Nâu Studio, không biết anh có yêu cầu skill nào đặc biệt không?

Anh cũng thay đổi tiêu chuẩn tuyển dụng của mình 1,2 lần để đạt được mục đích tuyên dụng nhưng định hướng trước đây và hiện tại vẫn luôn nhấn mạnh vào thái độ của các bạn với công việc thông qua những trao đổi trực tiếp hay khi mình đưa ra những tình huống để các bạn xử lý. Từ đấy mình sẽ đánh giá được các bạn có thích công việc hay không, có nghiêm túc, có chuyên nghiệp hay không.

Anh lúc nào cũng muốn tìm 1 nhân sự, 1 người đi lâu dài với công ty nên tụi anh rất chú trọng đến định hướng về sự nghiệp của các bạn. Các bạn lập trình viên vào Nâu Studio phải xác định rõ ràng là các bạn ấy có thực sự thích Front End hay không, có thật sự thích những công việc mà anh sẽ giao cho các bạn làm hay chỉ vào làm cho đúng giờ, đúng ngày.

Điểm khác nữa là khả năng tư duy. Đây là điểm mà các bạn lập trình viên rất cần có để tiến xa hơn trong công việc. Đối với các bạn fresh, Nâu Studio có đưa ra 1 bài test về IQ trên platform online. Sẽ có điểm ngưỡng để anh đánh giá mức độ phù hợp với công việc vì tư duy logic là điều không thể thiếu ở các bạn lập trình viên. Khả năng giao tiếp, soft skills thì mình có thể định hướng và hướng dẫn sau.

4/ Nói về thái độ làm việc của lập trình viên, thì anh có thể chia sẻ thêm về văn hóa của Nâu Studio?

Như đã đề cập trên website, Nâu Studio tập trung vào trải nghiệm của người dùng và trải nghiệm của lập trình viên. Trải nghiệm của người dùng tức là những sản phẩm, những thành quả của Nâu Studio đưa ra đều rất chú ý đến UX và UI. Về phía các bạn lập trình viên thì anh thường nhắc nhở các bạn chú ý đến những chi tiết giúp tăng UX cho người dùng, chẳng hạn như button phải có hiệu ứng chạm để người dùng biết là họ đã chạm đúng. Hoặc như 1 link theo chuẩn Mobile-first thì phải có kích thước tối thiểu là 40 pixel vì nếu các bạn làm quá nhỏ, thì tay rất khó đụng tới được vùng chạm. Ngoài ra còn có những chi tiết về màu sắc, font chữ… phù hợp với thiết bị di động hay desktop. Đây là những bước đầu tiên mà các bạn cần chú ý, để sau này khi các bạn lên vị trí Senior, có thể truyền lại cho các bạn mới.

Ngoài ra, văn hóa của Nâu Studio là chia sẻ những gì mà các bạn tìm hiểu được thông qua kênh chat chung. Tụi anh cũng có riêng 1 ngày là Friday Sharing để 1 bạn đại diện đứng lên thuyết trình về chủ đề tự do, không nhất thiết đến kĩ thuật vì buổi thuyết trình có sự tham gia của cả Designer, HR, Admin, Manager, Dev…

Điểm nữa mà Nâu Studio cũng rất tự hào đó là khâu đào tạo mảng đào tạo nhân sự. Tụi anh xác định ngay từ đầu các bạn lập trình viên là những người sẽ đi lâu dài cùng mình, là những người làm những dự án lớn và phức tạp hơn mà tụi anh sẽ giao nên tụi anh đào tạo các bạn rất kĩ. Như hiện tại Nâu Studio tập trung vào Front End và Javascript nên các bạn sẽ được nắm vững các kiến thức nền, sau đó mới học tiếp những nội dung khác như ReactJS, NodeJS…

Nguyên tắc làm việc của Nâu Studio là rất chú trọng quy ước khi lập trình – đây cũng là trải nghiệm cho lập trình viên mà anh muốn nói đến. Nâu Studio có 1 bộ quy chuẩn cho việc viết code, cùng những công cụ để kiểm tra các bạn đã viết đúng hay chưa, từ đó mới có thể gò các bạn vào 1 nếp để viết cùng 1 style với nhau, cùng best practice với nhau. Điều này đặc biệt có lợi trong trường hợp phải thay người mới thì họ sẽ bắt đầu rất nhanh, hạn chế những khó khăn khi đọc code do thay đổi văn phong, quy ước.

5/ Quy trình này là của riêng Nâu Studio hay có thể áp dụng được ở những nơi khác?

Team nào cũng có thể áp dụng được nếu họ thấy phù hợp.. Anh đang tổng hợp lại các tài liệu và open source tại http://code.naustud.io/ và sẽ chia sẻ bộ quy ước này rộng rãi đến cộng đồng trong thời gian tới . Bộ quy ước này cũng dựa trên những quy ước đến từ các công ty lớn như Javascript thì dựa trên quy ước của Airbnb, Google cũng như những công ty lớn khác…

6/ Thiết kế UX cho 1 website nước ngoài sẽ có những khác biệt gì so với thiết kế UX của 1 website cho người Việt Nam, chẳng hạn cho những user là người lớn tuổi?

Nói ví dụ về icon thì bọn anh đều có text đi kèm, dùng dạng label nhiều hơn. Còn về cách sắp đặt vị trí thì bên anh vẫn chưa thấy có gì quá khác biệt. Có thể là vì các sản phẩm của Nâu đa phần vẫn tập trung vào đối tượng người trẻ, biết về kĩ thuật nên mình cùng chỉ dựa trên những practices chung. Trong trường hợp có yêu cầu với các đối tượng đặc biệt thì bên anh sẽ tổ chức những buổi usability testing với những đối tượng người dùng thật để đánh giá phản ứng của họ với giao diện thử nghiệm . Dựa trên đó mình sẽ lưu ý lại và đưa ra những điều chỉnh phù hợp.

7/ Theo anh những điểm nào để đánh giá thành công về mặt UX của 1 website?

Theo tiêu chuẩn của Nâu Studio, website phải load nhanh dưới 2s. Tụi anh làm được điều này vì những công nghệ của NodeJS cũng đã tối ưu và rất nhanh. Ngoài ra, tụi anh cũng áp dụng các công cụ tự động hóa để tối ưu Front End từ lúc code cho đến lúc deploy.

Thứ 2 là website đó phải mobile-friendly như font chữ phải vừa mắt, kích cỡ nút và link phải phù hợp, giao diện tùy ứng (responsive UI) phải cung cấp được thông tin phù hợp nhất cho các user sử dụng di động. Các thống kê của 2017 xác nhận là người dùng đã vào web bằng thiết bị di động với màn hình chạm nhiều hơn trên máy tính (laptop, desktop), nên Mobile-first là điều bắt buộc. Tất cả các website mà Nâu Studio làm đều xuất phát từ Mobile, sau đó mới mở ra layout cho desktop. Cách tiếp cận code cũng như vậy như Code CSS cho Mobile trước tiên, sau đó mới điều chỉnh cho những giao diện lớn hơn.

Đa phần thì các framework, template của WordPress chẳng hạn thì vẫn theo Desktop trước. Với cách làm này, thì CSS ban đầu mình viết ra sẽ chỉ chạy được trên Desktop, lúc này nếu mở bằng điện thoại thì cả trang web sẽ bị scale xuống, chữ rất nhỏ. Ngược lại, CSS đầu tiên viết ra sẽ dành cho Mobile thì mọi thứ sẽ dễ điều chỉnh hơn về sau.

Cách làm này đối với thế giới thì không mới nhưng ở Việt Nam thì còn khá mới.

8/ Định hướng sắp tới của Nâu Studio?

Trước đây Nâu tập trung vào outsource, làm services cho khách hàng. Nhưng sắp tới công ty đang tập trung vào sản phẩm phần mềm về quản lý nhân sự, được build theo hướng Software as a Service và sẽ được ra mắt vào cuối tháng 7. Unique Selling Point trong phần mềm này là phương pháp quản lý KPI mới: Objective – Key Results chia công việc thành những objectives và update tiến trình để đi từ 0 đến 100%. Mỗi mục tiêu sẽ được chia nhỏ theo từng cấp bậc: người quản lý, trưởng phòng ban, các thành viên…. Từ đó mình sẽ có được những cảnh báo và điều chỉnh kịp thời, tương tự như những gì Google đang làm để đưa 1 bộ máy lớn đi lên.

Nguồn: TopDev via Techtalk

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

Facebook rất thích push content, đặc biệt là việc sử dụng video để quảng cáo. Và các bạn biết đấy, bản chất của video là những bức ảnh chuyển động. Người xưa có câu trăm nghe không bằng một thấy, giá trị của những video là rất lớn khi nói đến hiệu ứng quảng cáo.

Đó cũng là một trong những tham vọng của ông lớn Facebook với tính năng chèn video vào khung cover của các page trên Facebook.

Vốn là một admin của trang công động trên facebook với vài ngàn like, tôi khá tò mò về tính năng mới này.

Quá trình cài đặt khá dễ dàng và nhanh chóng. Bạn chỉ cần vào mục cover, chọn clip và chỉnh vị trí cũng như thêm cái thumbnail. Thế là bạn đã hoàn thành hết rồi đấy… Tuy nhiên thực tại lại hoàn toàn ngược lại.

Cái gì thế này? Đã sai ở chỗ nào nhỉ? Mặc dù bạn đã theo đúng hết theo chỉ dẫn, mọi thứ đều ổn và không hề có bất kì sai sót nào trừ việc nó hoàn toàn không thể làm được. Kết quả lúc nào cũng chỉ là bản báo lỗi hết sức ngắn gọn như gáo nước lạnh tạt thẳng vào mặt.

Và như mọi người dùng khác, bạn sẽ thử làm lại từ đầu với hi vọng biết đâu kết quả sẽ khác đi. Tuy nhiên lúc này một lỗi khác lại xuất hiện, video của bạn đã biến mất khỏi trang một cách ảo diệu.

Ngạc nhiên chưa! Content của bạn ra đi vĩnh viễn!

Thế là video mà bạn được mấy trăm like, comment đã biến mất hoàn toàn.

Nói cách khác nó bị xóa bởi một bug bí ẩn và coi như mất trắng tất cả công sức bạn bỏ ra để seed và chạy ads cho video đó.

Vậy giờ thì phải làm sao?

Gọi Facebook?

Tin buồn là cho dù bạn có gọi đi nữa thì cũng chả được ích lợi gì bởi họ sẽ cho rằng đó là lỗi của users, của chính bạn??

Nguyên văn chính xác là:

“Facebook đã phân tích vấn đề và xác định rằng video/post đó bị xóa bởi user. Đây là điều rất đáng tiếc bởi khi nó bị xóa bởi user thì sẽ không thể phục hồi được nữa”

Publish video lại?

Nhưng như vậy cũng có nghĩa là bạn đã chấp nhận mất đi tất cả lượng like, comment, share khổ cực kiếm được.

Bài học được rút ra là gì dành cho các software developer

Hãy biết chân trọng giá trị content của user. Vì thế hãy luôn cho thêm option hỏi họ có chắc không khi muốn xóa một nội dung nào đó.

Đây là bài học mà hẳn các mobile developer đều đã thuộc lòng. Cho người dùng tính năng access mạnh mẽ nhưng đồng thời cho phép họ revert lại những hành động trên.

Tôi hi vọng các developer tại Facebook cũng như các hãng công nghệ khác học được bài học qua vấn đề trên:

Đừng để có bất cứ lỗi nào có khả năng xóa content của người dùng
Cho dù user có muốn xóa content thì vẫn có tính năng phục hồi cho họ
Hãy mạnh dạng chấp nhận lỗi của mình thay vì cứ đổ lên người dùng

Với tư cách là một người dùng, tôi thấy bài học cuối cùng là quan trọng nhất. Mặc dù tôi đã tìm mọi cách chứng minh như dùng account khác nhau và quay clip lại nhưng bên Facebook vẫn tỏ ra thờ ơ và mặc định đó không phải lỗi của họ. Họ chỉ xin lỗi vì sự phiền toái do nó gây ra nhưng như vậy thì có giải quyết được gì đâu…

Nguồn: blog.topdev.vn via hackernoon