5 nguồn học miễn phí giúp bạn “chinh phục” Vim

Điều kì bí luôn làm chúng ta tò mò và sợ hãi. Đó là bởi vì bộ não chúng ta phát ra tín hiệu rằng chúng nguy hiểm. Vim cũng không phải là ngoại lệ. Mặc dù đã có hàng triệu câu hỏi vì sao Vim lại khó đến vậy trên StackOverflow, nó vẫn là một trong những editors được dùng nhiều nhất bởi các developer.

Chẳng qua do có một bộ phận các developer vốn đã quen sử dụng các editor khác nên họ không muốn chuyển sang xài Vim. Họ muốn nằm trong vùng an toàn của mình và tin rằng Vim quá khó để học cũng như cũng chả có lợi ích gì mấy.

Khi bạn đọc bài viết này thì cũng có nghĩa là bạn cũng có chút tò mò về Vim. Trước khi nói về những nguồn học hay giúp bạn tiếp thu Vim dễ hơn, ta hãy nói về nguyên nhân vì sao Vim vẫn sống tốt và được nhiều người sử dụng đến vậy.

Vì sao bạn nên biết về Vim?

Bạn hẳn cũng muốn biết vì sao mình nên học về Vim bởi nó có thể ảnh hưởng rất lớn đến công việc của bạn. Và có thể sẽ rất bất công nếu bạn phải học thứ mà lại không có lợi ích gì cho mình.

Nó như là bạn đang chơi game vậy

Khi bạn bắt đầu chơi game, độ khó của nó không bao giờ là điều khiến bạn lo lắng. Ngược lại, nó còn là động lực để giúp bạn “phá đảo”. Vim cũng tương tự như vậy, khi bạn bắt đầu nhận ra nó khá nhanh và bắt mắt, thì bạn sẽ thấy hứng thú nhiều hơn. Và với sự xuất hiện của những command cao cấp thì rất có thể bạn đã bị Vim hút hồn rùi.

Không cần phải dùng tới chuột

Bạn có rất nhiều shortcut cho navigate bằng code và files, thế nên việc dùng chuột sẽ trở thành thừa thãi. Do đó, bạn có thể thoải mái gõ bàn phím toẹt ga mà không sợ hiệu năng bị giảm sút.

Command vô cùng mạnh mẽ

List các command mà bạn có thể dùng tới phải nói là cực kì dài. Tất nhiên, ta chỉ cần học một vài command cơ bản lúc mới vào và mở rộng ra khi vào sâu hơn. Nói cách khác, dù đã có vài năm kinh nghiệm với Vim nhưng bạn vẫn có thể học được thêm nhiều thứ mới mẻ từ nó.

Có khả năng tùy chỉnh rất cao

Có rất nhiều Configurations khác nhau để cho bạn tùy ý thay đổi và tinh chỉnh theo ý thích của mình. Ngoài ra, có hàng trăm colors schemes bạn có thể download về xài. Đó là chưa kể tới vô số plugins cho phép bạn biến Vim trở nên mạnh mẽ không kém gì các IDEs hiện đại.

Văn bản và chữ là trọng tâm

Thường thì các IDEs có rất nhiều tính năng được tích hợp vào. Kèm với một user interface đơn giản, chúng có rất nhiều nút bấm nhằm giúp giảm thiểu các bước sử dụng cho người dùng. Trái lại, Vim lại cực kì đơn giản và chuyên về text. Nhờ đó mà bạn có thể tập trung hoàn toàn vào code.

Nó thể hiện tinh thần của Linux

Phần lớn các servers đều dùng Linux làm hệ điều hành. Vì thế khi bạn đã quen thuộc với Vim thì bạn cũng thấy việc deploy cũng như bảo trì server trở nên dễ thở hơn.

Những lí do trên là những đặc điểm nổi bật nhất của Vim và là lợi ích dành cho người dùng.

5 free online resources dành cho các bạn

Sau đây là những khóa học online mà bạn nên dùng tới. Tuy vậy, đừng cố học Vim một cách gấp rút. Bởi có rất nhiều người đã dành tới gần 20 năm chỉ để tìm hiểu về Vim mà vẫn chưa hết những điều mới lạ về nó. Qua đó ta có thể được tiềm năng của Vim lớn đến chừng nào.

VimTutor

Nếu bạn đang xài Unix-based machine thì vimtutor chính là lựa chọn cho bạn. Với chỉ vài phút, bạn đã hiểu được những điều cơ bản về Vim với những bài hướng dẫn vô cùng tuyệt vời.

OpenVim

Với các bài giảng dạy đầy tính tương tác sẽ giúp bạn hiểu rõ hơn về bản chất của Vim.

Vim Adventures

Nếu bạn thích chơi game thì đây chính là lựa chọn tuyệt vời. Bạn sẽ phải dùng Vim commands cho việc navigation và tìm ra hướng thoát khỏi mê cung. Bạn có thể type ` :help bất cứ lúc nào để được trợ giúp.

The basics of Vim

Derek Wyatt đã chuẩn bị một album với 13 videos để chỉ bạn về Vim. Với lượt xem hàng vài ngàn lần, chúng chứa đựng resources rất quí giá giúp bạn học Vim một cách dễ dàng.

Vim Cheat Sheet

Print cái cheat sheet này ra và dán vào đầu bàn làm việc của bạn. Nó sẽ như là quyển kinh thánh cho các bạn mỗi khi học và sử dụng Vim. Đây cũng là một cách rất tốt để giúp bạn nhớ kĩ các command cần thiết và quan trọng.

Lời kết

Nếu bạn chưa biết gì về Vim, thì tốt nhất đừng nên bắt đầu nó ngay với project của mình bởi bạn sẽ cảm thấy rất là đau khổ đấy. Thay vào đó, hay làm với những mini project nhỏ, cực kì đơn giản và ngắn gọn để giúp bạn dễ thở hơn.

Nguồn: blog.topdev.vn via Medium

Code Review Done Right – Đừng để chỉ Chúa mới hiểu code của bạn!

Bạn đã từng nghe đến 1 câu nói vui trong cộng đồng lập trình: ”Khi tôi viết những dòng code này chỉ có tôi và Chúa hiểu, giờ đọc lại chỉ có Chúa mới biết”? Tình trạng lập trình viên code ẩu, tạo ra code “thối”, chỉ quan tâm “chạy được” mà không tối ưu, không comment để người sau kế thừa… trở thành vấn đề đáng báo động. Đặc biệt trong thời đại của AI, Machine Learning, Blockchain đi cùng độ phức tạp của thuật toán, những dòng code rõ ràng mạch lạc đã trở thành yếu tố sống còn.

Hơn nữa, việc xây dựng văn hóa đội Dev cũng là bài toán đau đầu đối với các bạn CTO, Tech Lead. Văn hóa tốt mới giúp các thành viên cẩn thận trong từng dòng code, sáng tạo giao lưu để tối ưu thuật toán và có chế độ kiểm soát chất lượng qua quy trình Code Review.

Những lợi ích rõ ràng nhất của Code Review chính là:

Phát hiện lỗi sớm, giảm thiểu số lượng lỗi phát sinh.
Các thành viên trong nhóm sẽ nắm bắt được tiến độ dự án, hiểu rõ công việc của nhau và có sự hỗ trợ khi cần thiết.
“Muốn code giỏi thì hãy đọc code của người khác”: các dev sẽ được học hỏi thêm nhiều kiến thức hữu ích, nhớ lâu hơn do việc học diễn ra đúng nơi (code của mình) và đúng thời điểm (đang viết code). Đặc biệt, học cách giảng giải và góp ý cho người khác cũng giúp kiểm nghiệm lại kiến thức, nâng cao kỹ năng 1 cách nhanh chóng.
Đảm bảo clean code – Khi cả team cùng review cho nhau sẽ phát hiện ra những chỗ có thể viết ngắn hơn mà hiệu năng cao hơn, áp dụng design pattern XYZ tốt hơn…
Tiết kiệm thời gian – Nghe thì có vẻ vô lý nhưng code sạch giúp làm việc hiệu quả hơn, tránh được nhiều bug hơn, từ đó giảm thiểu được thời gian test và sửa lỗi.

Bạn muốn hiểu rõ quy trình Code Preview? Bạn muốn xây dựng văn hóa đội dev hiệu quả? Tại sao phải code sạch?

Cùng gặp gỡ anh LÊ QUỐC VIỆT – SENIOR SOFTWARE ENGINEER đến từ Bloomberg London – tập đoàn công nghệ trong lĩnh vực thông tin tài chính với bề dày kinh nghiệm xây dựng các phầm mềm tài chính đột phá, thay đổi cục diện của hệ thống thông tin tài chính thế giới.

Đăng kí những slot ngồi giới hạn gặp gỡ chuyên gia đến từ tập đoàn hàng đầu thế giới – Bloomberg tại đây!

Điểm qua những cột mốc ấn tượng về vị diễn giả này trước khi đăng kí tham dự bạn nhé:

Anh Quốc Việt theo học ngành Computer Engineering tại NUS, Singapore
Năm 2010 – 2011 anh được mời làm Credit Suisse ở phòng Công nghệ Phục vụ Hoạt động Pháp chế (Legal and Compliance IT) và phòng Exchange Links. Tại đây, anh đã viết và xây dựng hệ thống giao dịch chứng khoán tốc độ cao (low-latency exchange links – 20μs-200μs). Các hãng đầu cơ (hedge funds, giao dịch thông minh tốc độ cao HFT) và ngân hàng luôn tìm kiếm chuyên gia trong lĩnh vực này.
Năm 2013, anh chuyển sang xây dựng phầm mềm cho lĩnh vực định giá sản phẩm phái sinh (FX & Commodity Derivatives Pricing) của Bloomberg London. Nếu tại Credit Suisse, công việc chuyên môn của anh Việt sử dụng hệ thống phân tán nhỏ tốc độ cao thì tại Bloomberg, anh lại sử dụng hệ thống phân tán lớn và sử dụng nhiều lớp Microservices. Khác với giao dịch chứng khoán chỉ làm trong giờ hành chính, Bloomberg luôn chạy 24/7, nên yêu cầu kiến trúc hệ thống và xây dựng phần mềm cũng khắt khe hơn.

Cũng tại Bloomberg, anh Quốc Việt chuyển sang phòng Trading Analytics với vai trò thu thập thông tin giao dịch từ thị trường chứng khoán và xử lý trong thời gian thực để cung cấp qua UI hoặc cho API.

Riêng về Bloomberg, Bloomberg dẫn đầu trong lĩnh vực thông tin tài chính nhờ chú trọng đầu tư vào công nghệ và kỹ sư công nghệ. Bloomberg đóng góp cho hệ sinh thái mã nguồn mở với những sản phẩm như BDE (thư viện C++ có tính ổn định cao hơn Boost và dùng cho nhiều hệ điều hành, nhiều trình biên dịch), Comdb2 (hệ thống CSDL phân tán), Bucklescript (transpiler OCaml thành JS và được cộng đồng Javascript đó nhận và Facebook sử dụng trong sản phẩm ReasonML)

Vì phục vụ các hãng tài chính hàng đầu, các trường đại học và cả các cơ quan chính phủ, Bloomberg đặt yêu cầu ổn định hệ thống lên hàng đầu nên việc thêm chức năng mới cũng phải dùng các phương pháp đảm bảo ổn định hệ thống. Testing mới chỉ là khía cạnh các công ty khác đều ý thức được, nhưng chưa đủ vì testing vẫn là kiểm nghiệm từ bên ngoài và chưa đủ sâu. Một trong những bí quyết đảm bảo hệ thống ổn định và dễ nâng cấp và mã nguồn dễ tái sử dụng là Code Review và các công cụ hỗ trợ Code Review và Static Analysis.

Như vậy, chuyên gia kinh nghiệm về Code Review đã chính thức xuất hiện với cộng đồng Dev tại TpHCM vào cuối tháng 8 này!

Nhanh tay đăng kí để dành những slot ngồi giới hạn TẠI ĐÂY!

Thời gian: 28/08/2017 tại Tp.HCM

Thông tin chi tiết:

Website: meetup.vn
Event page: https://www.facebook.com/events/721263891394410

Hotline/ Liên hệ hợp tác:

binh@applancer.net (A. Bình) | 0904 392 888
event@applancer.net (Event team) | 08 6273 3497

Sự kiện được tổ chức bởi TopDev – Giải pháp tuyển dụng ngành IT

Biết đồng nghiệp cùng cấp nhận lương cao hơn mình, thay vì bực tức hay chán nản, hãy bình tĩnh làm những việc sau

Tại hầu hết các công ty, vấn đề lương của nhân viên không được công khai và mỗi người chỉ biết mức lương của chính mình. Tuy nhiên trong trường hợp bạn biết được với cùng một vị trí, đồng nghiệp đang nhận lương cao hơn mình, bạn nên làm gì?

Giữ bình tĩnh

Thông thường khi biết mình đang nhận mức lương thấp hơn đồng nghiệp, đa số mọi người có cảm giác ngạc nhiên, chán nản, thậm chí bức xúc, tức giận. Một số người không điều tiết được cảm xúc, sẽ chạy ngay sang phòng sếp thắc mắc: “Tại sao tôi cũng làm tốt mà lương tôi lại thấp hơn anh A?”, hoặc nhận thấy rất khó để tiếp tục tập trung vào công việc hiện tại. Lúc này hành động cần thiết là chạy ra ngoài hít thở không khí, uống một tách cà phê và suy nghĩ nghiêm túc xem nên làm gì tiếp theo.

Tìm hiểu nguyên nhân vì sao đồng nghiệp hưởng lương cao hơn

Có nhiều yếu tổ ảnh hướng đến mức lương, không chỉ giới hạn ở vị trí và bản chất công việc. Ví dụ nếu đồng nghiệp có học vấn tốt hơn, kinh nghiệm nhiều hơn, kỹ năng giao tiếp tốt hơn… thì khả năng anh ấy nhận lương cao hơn là có thể xảy ra.

Bên cạnh đó, thời điểm cũng là một yếu tố cần cân nhắc. Những người được tuyển dụng trong thời điểm công ty đang rất cần nhân sự hoặc công ty đang trên đà tăng trưởng mạnh thường được đưa ra mức lương cao hơn các giai đoạn khác.

Một khả năng nữa là trong quá trình phỏng vấn, đồng nghiệp mạnh dạn thương lượng, đề nghị mức lương cao hơn của bạn, và được công ty chấp nhận. Nếu những yếu tố này tồn tại, bạn nên ngừng lăn tăn và quên vấn đề chênh lệch lương đi.

Trải nghiệm công cụ tính lương gross to net chuẩn tại TopDev

Tham khảo mức lương trên thị trường

Việc tham khảo thị trường giúp bạn có cái nhìn đúng đắn hơn về mức lương mình nhận về. Bên cạnh đó cũng giúp bạn nhìn rõ hơn bức tranh toàn cảnh về thang lương hiện tại trong ngành nghề bạn đang làm. Tuy nhiên có một điểm cần nhớ, những yếu tố ngoài lương (chi phí đóng bảo hiểm cao, thời gian nghĩ phép dài hơn, giờ giấc làm việc linh hoạt…) có thể làm mức lương của bạn thấp hơn một chút so với mức trung bình trên thị trường.

Trao đổi với bộ phận nhân sự

Nếu muốn tránh đụng độ với sếp, hãy gặp bộ phận nhân sự để tìm hiểu. Những người này có thể nắm rõ lý do vì sao đồng nghiệp A có mức lương cao hơn bạn, đồng thời đưa ra lộ trình tăng lương của công ty để khuyến khích bạn tiếp tục phấn đấu.

Nói chuyện với sếp

Nếu làm tất cả những bước trên mà vẫn không thấy thỏa đáng, hãy trao đổi trực tiếp với sếp. Tuy nhiên không nên đề cập đến tên tuổi đồng nghiệp mà chỉ nói chung chung như: “Tôi biết có những đồng nghiệp cùng cấp nhận nhiều lương hơn tôi, trên thị trường mức lương của tôi ở vị trí trung bình/thấp, vậy tôi có thể làm gì để cải thiện”. Đi cùng với thái độ tìm hiểu và hợp tác, câu hỏi của bạn có vai trò “đánh tiếng” để sếp biết bạn không hài lòng với mức lương hiện tại và mong muốn nhận được những gì xứng đáng hơn.

Tìm công việc mới

Sau một thời gian trao đổi, nếu sếp không có động thái gì trong khi với khả năng hiện tại, bạn hoàn toàn có thể tìm được công việc khác tốt hơn thì đừng ngại ngần chuyển việc. Nhưng trước khi tìm được việc mới, hãy tiếp tục làm tốt công việc cũ vì bạn vẫn cần chi phí trang trải cho các sinh hoạt hàng ngày.

Nguồn: Applancer Careers

Tôi biết lập trình nhưng không biết lập trình cái gì?

Sau thời gian 3 năm học lập trình thì mình nhận thấy đa số sinh viên/lập trình viên đều gặp phải vấn đề này. Tức là nếu đưa sẵn một yêu cầu, mô tả phần mềm rõ ràng thì có thể làm được, còn tự nghĩ ra rồi làm một phần mềm hoàn chỉnh thì thua. Đâu là nguyên nhân của việc này?

Bạn nào muốn theo hướng product, hay có ước mơ làm phần mềm cho hàng triệu người dùng thì cũng nên quan tâm. Để chi?

Lấy Mark Zuckerberg làm ví dụ, trước khi tạo Facebook, Mark đã làm ra những thứ sau:

ZuckNet: Cha của Mark làm bác sĩ nha khoa và có mở phòng khám ở nhà, Mark với chị gái ở tầng trên. Thấy việc đi lên đi xuống bất tiện, Mark làm app để cả nhà có thể chat với nhau ( Lúc này Mark 11 tuổi, instant message thời đó chưa phát triển ).
Synapse Media Player: app dùng machine learing dựa vào list nhạc của user để recommend bài hát. App này được Microsoft đề nghị mua lại nhưng Mark không bán.
CourseMatch: Lúc này Mark vô năm 2 tại Harvard, thấy việc đăng ký học phần nhàm chán quá nên làm CourseMatch – app xem môn học này có ai đăng ký rồi để học chung.
FaceMash: Hiện 2 bức ảnh sinh viên trong trường, user click để chọn ai hot hơn.

Ta có thể thấy sự ra đời của Facebook dựa trên nền tảng của ZuckNet, CourseMatch và FaceMash. Không ai tự nhiên đùng một cái xây dựng được phần mềm triệu người dùng được.

Vậy đâu là nguyên nhân biết lập trình nhưng không biết lập trình cái gì?

Cách học trên trường?

Như bạn biết, các môn trên trường sẽ có đồ án, mà đồ án thì thường thầy cô quy định một danh sách rồi sinh viên tự chọn. Học hết môn này đến môn khác đều có người chọn sẵn cho mình rồi nên thành ra cũng không cần nghĩ ngợi gì nữa. Mà đồ án thì làm mấy phần mềm khá ‘xa lạ’, như mình có bao giờ vào nhà hàng, khách sạn đâu mà làm quản lý nhà hàng, khách sạn.

Tâm lý sinh viên thì cứ làm theo ý thầy cô bảo đảm sẽ điểm cao nên cũng không quan tâm là làm cái gì. Nhiều bạn còn đem một đồ án nộp 3,4 môn luôn cũng chẳng sao.

Mà cách tốt nhất để giết đi sự sáng tạo là chấp nhận hoàn cảnh (accepting the status quo). Ai biểu gì làm đó hem cần quan tâm. Học lập trình di động mà thấy cả lớp làm Android nên cũng làm theo, dù mình có Macbook và thích IOS thì thua. Nếu có thể làm phần mềm mình thích mà lại phù hợp với môn học tại sao không nói với giáo viên để thương lượng. Sẵn quảng cáo luôn, trường mình rất thoáng trong khoảng này, đồ án thể hiện được khả năng của bạn là được , không có rập khuôn.

Chưa đủ trình

Nhiều bạn có những ý tưởng táo bạo hay lắm nhưng chưa bắt tay vào làm vì thấy bản thân còn ‘gà’ ( chưa đủ trình )

Đa số ứng dụng bây giờ theo hướng social, cần kết nối user với nhau nên nhiều bạn nghĩ là phải là full stack biết hết từ frontend backend thì mới có thể làm được phần mềm hoàn chỉnh.

Nhưng với công nghệ hiện nay thì khác rồi. Bạn không biết backend thì có thể xài BaaS (Backend as a Service) như Firebase, Graph.cool. Còn design xấu quá thì xài mấy open source library cho đẹp.

Tóm lại là quan trọng bạn có muốn làm không thôi. Chưa biết thì có thể học.

If you really want to do something, you’ll find a way. If you don’t, you’ll find an excuse

Không tìm hiểu kiến thức ngoài chuyên ngành

IT là ngành rất hay, nhưng nếu kết hợp với ngành khác thì xem như vô đối.

IT + hotel = AirBnB.

IT + transportation = Uber

IT + car = Tesla

IT + language = Rosetta Stone

Ngoài kiến thức chuyên môn ra, lập trình viên nên tìm hiểu thêm về Kinh tế, Tâm lý học nữa sẽ giúp ích rất nhiều.

Học kinh tế để biết product mình build có giá trị gì không. Học Tâm lý học để hiểu user hơn từ đó xây dựng những tính năng cần thiết. Không phải ngẫu nhiên mà những tính năng như Recommendation (gợi ý kết bạn, gợi ý video youtube, gợi ý mua hàng, có thể bạn sẽ thích), nút like, reaction, hashtag, mention people, notification, gợi ý tìm kiếm, vv lại có sức ảnh hưởng lớn như vậy.

Kết luận

Đừng cố gắng phải nghĩ ra ý tưởng tuyệt vời, hoàn hảo hay thay đổi thế giới gì cả. Viết phần mềm mà bạn muốn dùng hoặc ít nhất là bạn cảm thấy sẽ có người dùng.

Còn bạn, có bao giờ bạn trong hoàn cảnh “không biết lập trình cái gì?” chưa. Bạn giải quyết như thế nào? Bạn sẽ khuyên người khác như thế nào?

Nguồn: niviki.com

Native apps với Vue.js: Chọn Weex hay NativeScript?

Vue.js là một framework tuyệt vời! Nó rất dễ học và là tinh hoa của những gì tốt nhất từ React’s component và Angular’s templates. Tuy vậy, Vue.js vẫn có điểm yếu: khác với React Native, Vue.js không hề ổn định cũng như được dùng nhiều vào việc phát triển các app Native.

Tin vui là điều nay sắp được thay đổi với 2 framework mới đang được phát triển nhằm giúp cho Vue.js có thể dùng được trong lập trình ứng dụng Native. Chúng chính là Weex và NativeScript. Trong bài viết này, tôi sẽ so sánh chúng và cho bạn cái nhìn rõ hơn về cả hai framewoek đầy tiềm năng này.

Weex

Weex là một project của người khổng lồ đến từ Trung Quốc – Alibaba. Với slogan “Write once, run Everywhere”, có nghĩa là bạn có thể lập trình cho web (html5), Android và iOS chỉ với cùng một database. Hiện có một vài Weex projects đang được phát triển, với số lượng hàng triệu người dùng Trung Quốc. Weex có nhiều components, plugins để tương tác với native platform với một set tool riêng nhưng vẫn còn khá thô sơ.

Không may là Weex developers vẫn chưa nghĩ đến việc để nó thành open source là ưu tiên hàng đầu. Tuy bạn sẽ có khá nhiều tài liệu, github repos, etc., để học nhưng việc làm một project từ bàn tay trắng sẽ là bất khả thi nếu không dùng vài thủ pháp hack lên native code.

NativeScript

Trong tháng 4, Igor Randjelovic mở ra cơ hội sử dụng Vue với NativeScript. `nativescript-vue` là một NativeScript plugin giúp lấp đầy khoảng cách giữa Vue.js virtual DOM và NativeScript components, cho phép bạn lập trình cross-platform apps với Vue.js. Mặc dù project vẫn còn khá non trẻ và không phù hợp để thật sự áp dụng vào làm app. Nhưng điều không thể chối bỏ là ứng dụng có tiềm năng rất lớn bởi nó thúc đẩy NativeScript framework với những tools cùng kho đồ sộ các components và plugins. Với webpack, bạn thậm chí còn dùng được cả .vue single file components.

Cộng đồng của Native Script cũng khá xôm tụ và được quan tâm. Nếu bạn tham gia vào official slack thì sẽ thấy có rất nhiều thành viên khá thân thiện sẽ sẵn sàng giúp đỡ bạn, bao gồm NativeScript core team developers, cha đẻ của nativescript-vue, và các member khác.

Tóm tắt điểm mạnh và yếu

Weex :

Tốt – Đã trong giai đoạn sản xuất (Tuy chỉ là ở Trung quốc thôi);

Tốt – Dành cho Web, Android và iOS;

Dở – Cộng đồng quá tệ;

Dở – Tool còn quá hoang sơ;

Dở – Không biết bắt đầu từ đâu để làm một project

nativescript-vue:

Tốt – Cộng đồng quá tuyệt vời;

Tốt – Thúc đẩy tất cả NativeScript platforms;

Dở – Còn quá non trẻ;

Dở – Chỉ dành cho Android và iOS

Kết luận

Trong open source projects, cộng đồng tốt luôn là ưu tiên hàng đầu. Weex tuy được ra đời sớm hơn vài tháng và có một đế chế to lớn đứng đằng sau thế nhưng cộng đồng lại rất yếu ớt. Trái ngược lại, NativeScript + Vue có một cộng đồng rất mạnh mẽ và phát triển nhanh chóng. Mặc dù vẫn còn trẻ nhưng tiềm năng và tương lai lại đầy hứa hẹn. Chính vì thế mà tôi chọn NativeScript.

Bài học từ việc rút ngắn thời gian xây dựng ứng dụng xuống chỉ còn ¼

Trung bình, một ứng dụng ra mắt sẽ mất từ 6-8 tháng từ giai đoạn hình thành ý tưởng, build, testing đến hoàn thiện nhưng với những công nghệ mới ra đời, thời gian này cũng rút ngắn đáng kể. Cùng TopDev gặp gỡ anh Đặng Tiến Dũng – CEO & CTO đồng thời là Co-Founder của Futurify để lắng nghe những chia sẻ từ quá trình chuyển đổi build sản phẩm theo cách thức truyền thống sang mô hình công nghệ mới và kinh nghiệm làm việc với các đối tác nước ngoài.

1/ Trước tiên, anh có thể giới thiệu đôi chút về công ty Futurify?

Futurify là công ty Outsourcing với tôn chỉ xây dựng các ứng dụng sáng tạo, cung cấp các giải pháp tối ưu nhất cho khách hàng. Được thành lập từ năm 2012, sau 5 năm thành lập và phát triển, Futurify đã tích lũy được rất nhiều kinh nghiệm và xây dựng thành công quy trình phát triển sản phẩm chuẩn. Từ những khách hàng đầu tiên ở Canada cho đến nay, Futurify đã mở rộng đến với khách hàng trong và ngoài nước thuộc nhiều nhóm ngành, lĩnh vực khác nhau.

2/ Được biết Futurify đã triển khai rất nhiều dự án trong và ngoài nước. Vậy dự án nào khiến anh tâm đắc nhất cho tới thời điểm hiện tại?

Với một công ty startup được gầy dựng từ con số 0, nên đối với anh, mỗi dự án là một trải nghiệm mới mẻ và đều có những dấu ấn riêng. Nhưng để nói về dự án khiến anh tâm đắc nhất thì có lẽ đó là dự án M&E – là một dự án của tổ chức phi chính phủ ActionAid Vietnam – AAV (chi nhánh của ActionAid International) nhằm giúp cải thiện cuộc sống của người dân. Đây là một dự án lớn đánh dấu bước phát triển nhảy vọt của Futurify, vì ở dự án này team Futurify tham gia toàn bộ quy trình tạo ra sản phẩm: từ lấy ý kiến khách hàng, xây dựng sản phẩm, kiểm định, training cho khách hàng. Khó khăn rất nhiều vì tụi mình phải áp dụng công nghệ mới mà team chưa từng làm trước đó. Trước đây, bên anh dùng framework Orchard build trên nền .NET MVC nhưng dự án M&E lại yêu cầu không dùng framework, nên gần như mọi người trong team phải vừa làm vừa học mọi thứ. Cũng nhờ đó mà anh em đã học hỏi được rất nhiều kinh nghiệm: làm việc với khách hàng, hỗ trợ khách hàng, hiểu được quy trình, bản chất của sản phẩm… Những bài học có được trong dự án thực sự đã ảnh hưởng tới định hướng phát triển công ty sau này rất nhiều.

Rất may dự án M&E cũng đạt được những thành công nhất định, ứng dụng web mà Futurify tạo ra đã giúp AAV giải quyết được vấn đề mà họ gặp phải đó là theo dõi và đánh giá hệ thống trực tuyến, đưa ra các báo cáo nhằm giúp nâng cao hiệu quả hoạt động của M&E, hỗ trợ công việc của AAV tốt hơn. Futurify rất tự hào về những gì team đã làm được.

3/ Theo anh, làm dự án với đối tác nước ngoài thì có điểm gì khác so với đối tác Việt Nam?

Nhìn chung, dự án trong hay ngoài nước cũng không có nhiều khác biệt lắm, mỗi khách hàng đều có một ý tưởng, một vấn đề cần giải quyết. Tuy nhiên, thông thường, khách hàng nước ngoài sẽ biết chính xác điều họ muốn, chỉ cần cung cấp những gì họ cần, nhưng ngược lại chúng ta lại gặp khó khăn về giao tiếp. Còn đối với khách hàng Việt Nam, đôi khi họ không rõ ràng về mặt yêu cầu, nên giai đoạn hiểu nhau và đề ra giải pháp lâu hơn. Lúc đó, đòi hỏi phải có kinh nghiệm giải quyết vấn đề, giải pháp đưa ra cần rõ ràng, lộ trình cụ thể, tìm hiểu kĩ yêu cầu của khách hàng và giải pháp đề ra phải phù hợp.

4/ Điểm đặc biệt trong quy trình xây dựng sản phẩm của Futurify là gì?

Ứng dụng mới lần đầu làm mất 4 tháng, lần thứ 2 phát triển ứng dụng tương tự chỉ mất 2 tháng, còn bây giờ Futurify chỉ mất 1 tháng là làm được, rút ngắn thời gian chỉ còn ¼ so với ban đầu.

Thực ra không có bất kỳ phép màu hay công cụ nào đặc biệt đứng đằng sau giúp đẩy nhanh quá trình tạo ra sản phẩm. Tất cả nằm ở kiến trúc Microservices, mỗi dự án sẽ gồm nhiều services, bằng cách tận dụng hiệu quả các nền tảng đã có trong các dự án cũ, chúng ta có thể rút ngắn thời làm sản phẩm nhưng không làm giảm chất lượng sản phẩm tạo ra, thậm chí còn có thể làm tốt hơn sản phẩm trước đó.

Đồng thời giải pháp này cũng đáp ứng nhu cầu của nhiều khách hàng, đôi khi khách hàng chưa cần 1 sản phẩm đầy đủ các tính năng ngay từ đầu. Họ chỉ cần một vài tính năng cơ bản, thể hiện được ý tưởng của họ, một bản Demo sản phẩm là đủ cho khách hàng. Đối với các ứng dụng như vậy team làm theo từng MVP. Giảm thời gian đồng nghĩa với giảm chi phí rất nhiều.

5/ Lập trình viên khi làm việc với kiến trúc Microservices cần phải lưu ý những vấn đề gì?

Theo anh, khó khăn lớn nhất mà các lập trình viên cần quan tâm là thay đổi tư duy lập trình: làm thế nào để cùng làm ra các services khác nhau nhưng sản phẩm tạo ra cuối cùng đồng nhất với nhau. Nó đòi hỏi khả năng phối hợp tốt, cần có 1 kế hoạch cụ thể, phân công nhiệm vụ rõ ràng và cách thức liên kết với nhau ra sao. Thời gian đầu việc này tốn nhiều thời gian hơn so với cách thông thường, nhưng về lâu dài thì tối ưu hơn cách thông thường.

6/ Hiện nay, các dự án Cross-platform đang thu hút sự chú ý đặc biệt của cộng đồng lập trình, anh có đánh giá gì về tiềm năng của lập trình đa nền tảng trong thời gian sắp tới?

Cross-platform rất có tiềm năng trong tương lai gần. Bởi những ưu điểm viết code một lần nhưng build ra nhiều nền tảng, giảm thời gian, giảm thiểu chi phí, chỉ trong một tháng là có thể hoàn thành một ứng dụng. Đối với các lập trình viên vốn quen làm việc trong môi trường Native khi chuyển sang làm việc với cross-platform thì có rất nhiều lợi thế. Vì làm Native rất chuyên sâu về ứng dụng, hiểu rõ về ứng dụng và chỉ cần học thêm framework của cross-platform là có thể làm được. Còn những bạn từ Cross-platform sang làm Native thì khó khăn hơn.

7/ Với những bạn lập trình viên mong muốn được làm việc tại Futurify cần đáp ứng những yêu cầu gì?

Tất nhiên, bên cạnh những kỹ năng, kiến thức cần có để đáp ứng yêu cầu công việc, anh đánh giá cao những bạn ham học hỏi. Bởi kiến thức trong nhà trường chỉ là kiến thức nền tảng, nó chưa đủ để mình làm việc hiệu quả. Những bạn ham học hỏi sẽ tiến bộ nhanh hơn những bạn khác vì trong một môi trường bận rộn, không ai có đủ thời gian và kiên nhẫn để cầm tay chỉ việc từng bạn, các bạn cần chủ động tự học, tự tìm cách giải quyết vấn đề.
Văn hóa Futurify là: thân thiện, năng động, sáng tạo. Những bạn có cùng mindset đó sẽ rất dễ thích nghi với môi trường công ty. Sở dĩ anh đánh giá cao những bạn sáng tạo, vì những người như vậy luôn biết cách làm cho mọi việc trở nên dễ dàng hơn, nghĩ ra được phương pháp tối ưu hơn.

Và quan trọng là các bạn phải thực sự đam mê lập trình. Bản thân anh rất mê lập trình, đối với anh khi các bạn mê lập trình sẽ không phải làm việc một ngày nào, bạn coi đó là trải nghiệm, một phần cuộc sống của mình. Các bạn lập trình vì đó là niềm vui của các bạn chứ không phải là để phục vụ cho người khác. Đôi khi anh rất bận nhiều công việc giấy tờ, mệt mỏi và anh tìm đến lập trình để thư giãn đầu óc.

8/ Anh có thể chia sẻ về định hướng phát triển của Futurify trong thời gian tới?

Trước mắt, Futurify sẽ tập trung vào mảng Marketplace, xây dựng các ứng dụng cross-platform và mở rộng thị trường đến các khách hàng tiềm năng trên nhiều nước khác trên thế giới. Ngoài ra, Futurify cũng lên kế hoạch phát triển những engine có khả năng reuse (tái sử dụng), việc này giúp rút ngắn thời gian và chi phí phát triển phần mềm cho khách hàng. Futurify sẽ áp dụng phương pháp này đối với những phần mềm được xây dựng trên cùng một nền tảng, có những tính năng và business logic tương tự nhau. Lúc này, mình không phải tập trung quá nhiều vào kỹ thuật, mà tập trung vào ý tưởng, từ đó công việc sẽ trở nên thú vị hơn.

Cảm ơn anh Dũng đã dành thời gian chia sẻ với TopDev.

Cần làm gì để không bị thay thế bởi robot?

Ngày càng có nhiều mối quan ngại về tác động của automation – tự động hóa đến thị trường lao động. Các nhà khoa học, nhà báo, các chuyên gia công nghệ không đồng ý về sự chuyển đổi nhanh chóng và sâu sắc sẽ diễn ra.

Những người lạc quan nói rằng mặc dù thực tế là tự động hóa là không thể tránh khỏi trong thời gian tới nhưng chỉ có 5% việc làm ở Mỹ sẽ được tự động hoá thay thế hoàn toàn vào năm 2055. Những người khác bi quan hơn mô tả một kịch bản u ám 47% các công việc của Mỹ có nguy cơ tự động hóa trong tương lai 20 năm.

Bất kể tốc độ tự động hoá sẽ làm thay đổi thị trường lao động như thế nào, bạn nên sẵn sàng cho nền kinh tế AI, nơi các robot, phần mềm AI và các công cụ tự động thay thế con người trong các nhiệm vụ mà họ đã thực hiện trong nhiều thập kỷ.

Để cạnh tranh trong thời đại máy móc, đây là list các chiến lược để khai thác tiềm năng của Trí tuệ nhân tạo.

Hiểu cách giao tiếp với máy móc

Phần mềm tương tác với AI như chatbot, trợ lý ảo (ví dụ Siri của Apple, Alexa của Amazon) và các nền tảng phân tích (ví dụ: IBM Watson analytics) thay đổi cách thức người tiêu dùng và các công ty thu thập thông tin và đưa ra quyết định.

Đây là việc khai thác sức mạnh của các máy thông minh, mọi người nên làm chủ giao diện và chiến lược cho phép tương tác giữa người và máy. Cũng giống như việc các kỹ sư Google Search sẽ trao thưởng cho những người nhập truy vấn tìm kiếm, AI sẽ trở nên thân thiện với những người có khả năng giao tiếp tốt với nó.

Một nhân viên làm việc với các phân tích kinh doanh AI nên biết rõ những loại thông tin và dự đoán nào anh ta muốn lấy từ máy. Trong bối cảnh này, các kỹ năng quản lý AI là ưu tiên quan trong nhất.

Những Manage nên tận dụng tối đa sức mạnh của AI sẽ trở thành một tài sản quý giá cho công ty của họ trong kỷ nguyên máy móc.

Hiểu các khái niệm cấp cao

Hiểu biết về máy tính là một kỹ năng không thể thiếu trong kỷ nguyên máy tính. Ngày nay, khi chúng ta bước vào thời đại Trí tuệ nhân tạo,hiểu biết về AI thành một trong những tài sản quý giá để có thể cạnh tranh trên thị trường lao động.

Hiểu biết về AI bao gồm việc hiểu các khái niệm, công nghệ và giải pháp, cơ chế làm việc của AI. Cũng giống như việc hầu hết chúng ta đều biết rằng thông tin kỹ thuật số được lưu trữ theo byte, sẽ không cần phí thời gian để nghiên cứu các thuật toán ML (Machine Learning) làm việc như thế nào? sự khác nhau giữa giám sát và không được giám sát là gì? hay làm thế nào để cài đặt và Cấu hình một phần mềm AI.

Có nhiều khóa học trực tuyến và các hướng dẫn cung cấp cấp những kiến thức cơ bản về Trí tuệ nhân tạo (AI), mà ngay cả một người không có nền tảng kỹ thuật và toán học cũng có thể hiểu được. Điều đơn giản nhất bạn có thể làm bây giờ chỉ là để bắt đầu học cách sử dụng các phần mềm mã nguồn mở AI để trải nghiệm sức mạnh của công nghiệp này.

Cải thiện sự sáng tạo

Không phải là quá cường điệu khi nói rằng AI làm tốt hơn con người trong các công việc lặp đi lặp lại và các hoạt động đòi hỏi tính toán nặng nề. Nhờ những kỹ năng này, AI sớm hay muộn sẽ thay thế tài xế taxi và xe tải, chăm sóc khách hàng và thợ thủ công.

Tuy nhiên, những kỹ năng mà máy móc có được không phải là duy nhất. Sự sáng tạo vẫn là một phần độc nhất và quan trọng nhất của trí thông minh con người tạo ra những đổi mới như AI có thể. Khả năng sáng tạo của con người rất rộng và đa dạng. Nó bao gồm không chỉ khám phá khoa học, mà còn có rất nhiều vấn đề hóc búa trong cuộc sống, các giải pháp tối ưu hóa, và những hiểu biết sâu sắc mà mọi người đưa ra trong cuộc sống hàng ngày và công việc của họ.

Để có thể cạnh tranh với AI trong kỷ nguyên mới, mọi người nên phát triển những kỹ năng làm cho họ nổi bật so với đám đông. Điều này đòi hỏi phải thay đổi tư duy của dây chuyền lắp ráp Fordist – coi nhân viên là ‘robot’ thực hiện các hoạt động lặp đi lặp lại và không suy nghĩ.

Một khi robot thực sự bước vào thị trường lao động, nhiều người sẽ có cơ hội phát triển sự sáng tạo của họ.

Mở rộng chân trời trí tuệ

Một lý thuyết về sự đa dạng của trí tuệ giả định rằng trí thông minh con người không phải là một bộ quy tắc trừu tượng, mà là một hệ thống phức tạp liên quan đến các kỹ năng cảm xúc, xã hội, bằng lời nói, cơ thể, vận động và kỹ năng mềm

Điều này có nghĩa là vào kỷ nguyên AI con người sẽ tiếp tục đóng một vai trò quan trọng trong các lĩnh vực đề cao sự giao tiếp giữa con người với con người. Các lĩnh vực như: tư pháp, chăm sóc sức khoẻ, tâm lý trị liệu, điều dưỡng, nghệ thuật chỉ là một vài ví dụ về các hoạt động mà robot chỉ có thể đóng vai trò hỗ trợ.

Để cạnh tranh trong thời đại tự động hoá, mọi người nên tập trung vào các kỹ năng và khoa học làm cho chúng khác với máy móc. Cảm xúc, các quan hệ xã hội và các vấn đề liên quan xuất hiện. Phát triển sự đồng cảm, trở thành một cầu thủ, manager, leader sẽ là ưu tiên hàng đầu khi nhân viên tìm kiếm công việc trong nền kinh tế dựa vào AI.

Khi máy móc trở thành một phần không thể thiếu của nền kinh tế, năng lực kỹ thuật sẽ không đủ để cạnh tranh ngang bằng với chúng.

Máy móc có chức năng hỗ trợ và tăng cường

AI sẽ không thay thế hầu hết các công việc trong tương lai gần. Trong hầu hết các trường hợp, nó chỉ đơn giản là tăng thêm nhân viên, biến chúng thành những người điều hành và trợ lý. Trong bối cảnh đó, họ sẽ phải tìm hiểu làm thế nào để máy móc có thể hoạt động hiệu quả.

Ví dụ, các công ty Star-up sử dụng chatbot đang thuê các chuyên gia đào tạo AI đánh giá hiệu quả của phần mềm AI và bước xử lý nếu có sự cố. Nhiều công ty Star-up dùng chatbot sử dụng công nghệ AI để thực hiện một nhiệm vụ cụ thể, chẳng hạn như sắp xếp cuộc gọi hoặc cuộc họp với khách hàng và nhân viên.

Hình thức như vậy sẽ duy trì vai trò của nhân viên trong giao tiếp giữa AI và người tiêu dùng. Tương tự như vậy, một số nhân viên sẽ thực hiện ghi nhãn dữ liệu, dọn dẹp, chống trùng lắp dữ liệu để tạo ra các tập dữ liệu cần thiết để đào tạo các thuật toán ML.

Tất cả các hoạt động này sẽ tạo ra một nền kinh tế AI hỗn hợp, nơi nhân viên hợp tác với máy móc để cung cấp giá trị nhiều hơn cho các công ty của họ.

Điêu gì sẽ diễn ra tiếp theo?

Phủ định nguy cơ cách mạng AI đe dọa tới con người . Ở mỗi giai đoạn của lịch sử kinh tế của chúng ta, sự tiến bộ công nghệ đã dẫn tới sự thay đổi của thị trường lao động. Xưởng sản xuất, nhà máy công nghiệp, dây chuyền lắp ráp, máy tính chỉ là những giai đoạn tự động hóa lịch sử mang lại như một sự cải tiên về mức sống.

Điều này vẫn đúng với thời đại máy móc thông minh. Nó sẽ định dạng lại thị trường lao động một số công việc trở nên lỗi thời, nhưng hiệu quả cuối cùng của nó đối với xã hội sẽ phụ thuộc vào việc chúng ta sử dụng lợi thế cạnh tranh và sự sáng tạo vô hạn để khai thác sức mạnh của AI.

Nguồn: blog.topdev.vn via hackernoon

Từ lập trình viên đến nhà đầu tư thiên thần

Nguyễn Thành Nhân từng là kỹ sư ở Google, hiện làm việc tại Walmart (Mỹ) và đã đầu tư trên 10 startup tại Việt Nam và Mỹ.

Đến nay, hai phần ba dự án mà Nhân rót vốn đầu tư đã thất bại. Nhưng với anh, trở thành nhà đầu tư là việc phải tới, khi máu kinh doanh đã ngấm từ thuở bé.

Sinh trưởng trong gia đình có bố mẹ đều là giảng viên trường Đại học Kinh tế Quốc dân (Hà Nội), từ lớp 7 Nhân đã đọc sách kinh tế học. Một năm sau, được bố cho chơi điện tử trên máy tính của trường, nam sinh quyết định chuyển sang lớp chuyên Tin vì “chắc bên đó có nhiều trò chơi điện tử”. Từ đó, Nhân làm quen với máy tính, từng bước trở thành lập trình viên và tìm được chỗ đứng tại vùng đất công nghệ nổi tiếng thế giới: thung lũng Silicon.

Trong thời gian du học tại Đại học Simon Fraser (Canada), Nhân có cơ hội thực tập tại trụ sở chính của Google ở Mỹ. Dù được gã khổ lồ mời ở lại, anh vẫn chọn gia nhập startup Chai Labs và làm việc cho đến khi Facebook mua công ty này. Lý do bỏ việc cũng rất lạ. “Facebook tuyên bố họ nắm 10% thời gian người dùng, tôi nghĩ rằng họ đã lãng phí 10% thời gian của mọi người”. Thế là Nhân trở lại Google năm 2010, làm trong nhóm AdWords.

Trong thời gian xa xứ, Nhân vẫn giữ liên hệ với bạn bè ở Việt Nam, đặc biệt là cộng đồng startup. Mỗi dịp về thăm quê, anh đều dành thời gian trò chuyện cùng những người đam mê khởi nghiệp. Trong đó có Đỗ Tuấn Anh, nhà sáng lập và CEO Appota – cung cấp nền tảng cho di động.

“Khi nói chuyện với anh ấy, tôi thích quá nên muốn tham gia đầu tư. Trước kia tôi không quan tâm đến môn Sử nhưng anh Tuấn Anh nói phải biết phân tích sự kiện lịch sử và không để cảm xúc ảnh hưởng đến phân tích trong kinh doanh”, anh kể về cái duyên trở thành nhà đầu tư thiên thần 5 năm trước.

Đang có công việc tốt lương cao tại Google, lập trình viên quyết định mạo hiểm để đầu tư, cũng là thỏa mãn đam mê kinh doanh ngấm từ bé. Được một người bạn giới thiệu, Nhân “theo đuổi” CEO TechElite gần 3 tháng trời mới “có chân” trong nhóm đầu tư. “Tôi học được rất nhiều, từ việc chọn sản phẩm thế nào để xây dựng, có nên vào vườn ươm không hay gọi vốn từ nhà đầu tư mạo hiểm ra sao. Kinh nghiệm bán hàng, marketing hay PR cũng tích lũy được kha khá”, anh kể vể trải nghiệm lần đầu bỏ tiền vào một dự án.

Từ khởi đầu ấy, Nhân lần lượt đầu tư vào nhiều startup khác ở Việt Nam và Mỹ. Tiêu chí lựa chọn cũng rất lạ lùng, mục tiêu không phải là số tiền có được mà là “dự án phải giúp tôi học cái gì đó”. Định hướng từ đầu là vậy, nên anh không nản khi cho đến nay, đa phần số dự án đã rót vốn đã thất bại, con số thu về hoàn toàn bằng không.

Vừa mất tiền vừa mất thời gian, tại sao vẫn đi tiếp cuộc chơi mạo hiểm này? “Tôi đầu tư chủ yếu để học nên thất bại cũng dạy cho mình những bài học đắt tiền. Đầu tư mạo hiểm khác ở chỗ cần một công ty thực sự to để có lãi. Còn nếu sợ rủi ro, việc này không dành cho bạn”, anh nói.

tu-lap-trinh-vien-den-nha-dau-tu-thien-than

Lập trình viên kiêm nhà đầu tư Nguyễn Thành Nhân.

2/3 thất bại cũng có nghĩa 1/3 chưa chết. TechElite, dự án thử sức lập trình viên trong vai trò nhà đầu tư sau đó gọi được thêm nhiều nguồn vốn khác nên Nhân không bỏ thêm tiền vào nữa và nắm một số cổ phiếu. “Mối quan hệ giữa hai bên nhà đầu tư và dự án với tôi là lạt mềm buộc chặt. Chúng tôi chia sẻ lợi ích khi thành công bằng việc mua cổ phiếu. Nếu công ty thành công hay lên sàn, M&A thì tôi cũng được một phần nhỏ”, nhà đầu tư 5 năm chia sẻ.

Khi dự án thất bại, nhà sáng lập mở công ty khác, Nhân vẫn hỗ trợ và xem xét đầu tư. Bởi anh cũng hiểu rủi ro khi khởi nghiệp là gì. Theo anh, với startup thì dự án còn tồn tại là mừng và hết lỗ thì càng là cấp số nhân của niềm vui. Môi trường khởi nghiệp sẽ dạy cả người sáng lập và nhà đầu tư những bài học không tên từ nhỏ cho đến lớn. Khi cùng làm, cả hai bên sẽ hiểu nhau và biết có thể song hành trên con đường phía trước hay không.

Cũng chính trải nghiệm này từng thúc đẩy Nhân nghỉ Google và khởi nghiệp ở Mỹ năm 2016. Dự án Fintech của anh nhanh chóng tan vỡ vì chưa có kinh nghiệm về ngân hàng, rút ra một bài học sâu sắc về thời gian, công sức và tiền của. “Khi nói chuyện với nhiều người, tôi nhận thấy có vẻ họ không cần sản phẩm này. Đồng sáng lập chia tay để làm công việc khác. Chúng tôi quyết định dừng lại”, Nhân kể.

Tuy nhiên, đó không phải là dấu chấm hết cho hành trình đam mê của nhà lập trình từ thung lũng Silicon. Anh đã nhiều lần chia sẻ về dự định hồi hương trong tương lai gần. Ngày xưa, ước mong ấy từng rất kiêu. Đó là kiếm 10 triệu USD trước 35 tuổi và quay về Việt Nam mở trường tư mô hình Stanford, tính học phí cao và cho học bổng với học sinh giỏi.

Nhân hóm hỉnh nói giờ anh chưa có 10 triệu USD nhưng mới 34 tuổi. Anh đã đầu tư vào trường dạy thuật toán đầu tiên ở Việt Nam là BigOCoding với hy vọng có thể giúp sức đào tạo nhiều kỹ sư giỏi cho ngành công nghệ. Anh cũng bỏ tiền vào dự án dạy tiếng Anh phi lợi nhuận mang tên Elight, với hy vọng Việt Nam trở thành quốc gia nói tiếng Anh để đáp ứng điều kiện cần cho quốc gia khởi nghiệp.

Tư duy thuần khiết về định nghĩa của một lập trình viên không vướng áp lực tiền nong khiến Nhân đón nhận thất bại trong đầu tư rất nhẹ nhàng. “Khó khăn của một nhà đầu tư mới chính là chưa thất bại bao giờ. Thất bại chính là bài học cần thiết cho những nhà đầu tư mạo hiểm”, anh chia sẻ.

Năm năm không có một đồng lời thu về từ hoạt động này, cũng chưa dự án nào có dấu hiệu IPO hay M&A, Nhân vẫn ổn khi đang làm việc tại Walmart. Với anh, lập trình hay đầu tư đều là công việc của hai bên cánh tay. Nếu lập trình là tay phải, tay thuận, thì đầu tư là tay trái. Tay trái không sành bằng tay phải, nhưng vẫn là một cánh tay, thuộc về một phần con người anh.

Khi làm lập trình, Nhân chỉ ngồi một chỗ viết code hay đọc sách. Khi đầu tư, anh phải gặp gỡ nhiều nhà sáng lập và nhà đầu tư. “Khó cân bằng nhất là thời gian”, anh nói nhưng vẫn quyết đi tiếp. Hai công việc có vẻ tương phản lại thể hiện đúng nhất cá tính của chàng trai gốc Hà Nội này: đam mê học hỏi và không ngại mạo hiểm.

Nguồn: vnexpress.vn

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

Lập trình web – Bạn muốn học nhưng không biết từ đâu?

Vậy là bạn có hứng thú với học lập trình web và muốn trở thành một web developer? Trước tiên, xin chúc mừng vì bạn đã có một lựa chọn khá đúng đắn. Và khi bạn đọc bài viết này thì cũng có nghĩa bạn xài khá rành rọt Facebook, lên đọc Medium và các blog online. Tất cả những nơi đấy đều là nguồn tuyệt vời để học lập trình.

Một lần nữa, tôi xin chúc mừng bạn vì những hành động tuyệt vời trên. Tuy thuộc vào background của bạn mà bản thân sẽ tự hỏi rằng không biết nên bắt đầu từ đâu để học lập trình web. Nếu bạn thử Google thì có lẽ sẽ cảm thấy khá choáng bởi hằng sa các loại ngôn ngữ lập trình cần phải học cũng như các framework và nguồn để học.

Nhưng đừng lo lắng, bởi không chỉ có mình bạn gặp vấn đề này. Google có thể là người bạn tốt nhất những cũng có thể là kẻ thù nguy hiểm nhất. Nó hoàn toàn phụ thuộc vào cách bạn sử dụng.

Lập trình website là gì?

Lập trình web là quá trình tạo ra các trang web và ứng dụng web bằng cách sử dụng các ngôn ngữ lập trình và công cụ phát triển web.

Mục tiêu của lập trình web là xây dựng các trang web động, tương tác, và đáp ứng nhu cầu của người dùng, từ các trang web tĩnh cơ bản đến các ứng dụng web phức tạp, như hệ thống thương mại điện tử, mạng xã hội hoặc các nền tảng học trực tuyến.

Những lời khuyên về lập trình web

Tôi khuyên các bạn khi muốn làm về web thì hãy xác định mục đích rõ ràng cuối cùng của bạn là gì. Bạn muốn thay đổi sự nghiệp. Hoặc là bạn có một ý tưởng cực độc cho app. Hay chỉ đơn giản là bạn muốn học cho vui.

Dù là gì đi nữa, quan trọng nhất bạn phải biết vì sao mình lại làm vậy. Sự hiểu biết này sẽ giúp bạn làm việc hiệu quả hơn. Nó cũng sẽ là động lực cho bạn để tiếp tục mỗi khi muốn từ bỏ. Hãy luôn nhớ rằng goal của bạn dù có khó đến mức nào thì nó vẫn có thể đạt được bằng sự cần cù và quyết tâm.

Cứ cho là bạn hoàn toàn mới và không biết gì về lập trình web luôn. Thế thì bạn nên suy nghĩ và đưa ra lựa chọn giữa Back-end và Front-end. Tôi sẽ giải thích sơ lược sự khác biệt giữa chúng.

Frontend – đây là những gì mà user sẽ nhìn thấy và tương tác với khi vào website. Nó hoàn toàn là về design, hiệu ứng bóng bẩy, layout và hình ảnh nhằm tạo ra trải nghiệm sử dụng cho khách hàng.

Thông thường frontend developer rất giỏi về sáng tạo hình ảnh, kĩ năng design giỏi và có đam mê với việc tạo ra trải nghiệm cho người dùng tốt nhất. Các công nghệ thường được sử dụng bởi frontend developer bao gồm HTML, CSS, jQuery và JavaScript.

Tham khảo thêm các vị trí tuyển dụng Front end lương cao.

Backend – Đây là phần về xử lí, lưu trữ và sử dụng Data. Nó là cách mà web và app hoạt động. Backend developer là những người giỏi giải quyết vấn đề, suy nghĩ logic và có sở thích với các tính năng của web và app. Lập trình Backend thường dùng tới PHP, Python, Golang, Java, Javascript và Ruby.

25 thuật ngữ bạn nhất định phải biết khi lập trình web

Trong trường hợp của tôi, ngày từ đầu đã biết chắc rằng mình không phù hợp với visual design của bên frontend. Có lẽ là nhờ vào việc tôi từng học về kỹ thuật và xây dựng nên việc ra quyết định khá dễ và rõ ràng. Tôi thuộc vào nhóm giải quyết vấn đề và vận hành hơn là làm đẹp cho sản phẩm.

Dù thế nào đi nữa, bạn có chọn Frontend hay Backend thì việc đầu tiên luôn là học về HTML và CSS. Bởi ít nhất bạn phải có được khả năng làm ra một website cơ bản.

Sau đó bạn nên chọn cho mình 1 editor yêu thích để code trên như VS Code hay Sublime Text. Sau đó chọn ngôn ngữ lập trình nào dễ học dễ làm vd như tôi chọn Php để lao vào vọc ngay, tải các tài liệu học lập trình web liên quan đến php để nắm căn bản. Sau khi nắm căn bản rồi chọn một framework trong các framework php mà viết trang web đầu tiên của mình.

Sau khi đã hoàn thành những khóa trên thì xin chúc mừng bạn đã thực sự bước chân vào thế giới của lập trình web rồi đấy!

Giờ là lúc thực hành, có thể sẽ rất khó khi bạn mới thử. Chúng ta có quá nhiều thứ để lo như học, làm, gia đình, v.v… nên thời gian không hề dư dả gì.

Thế nên sự kiên trì, nhất quán chính là chìa khóa thành công. Bạn sẽ biết nhiều hơn với mỗi giờ học code mỗi ngày hơn là học 7 giờ trong một ngày.

Con người là sinh vật của thói quen. Vì thế hãy biến việc viết code thành thói quen hàng ngày.

Tham khảo thêm các vị trí tuyển dụng back end lương cao.

8 video game giúp bạn lập trình web tốt hơn

Hãy học code như bạn đang cố gắng trở thành người mạnh nhất thế giới.

Nếu bạn từng xem cuộc thi “Worlds Strongest Man”, thì việc học code cũng giống như kéo cái xe tải vậy. Nó cực kì khó khi mới bắt đầu, trông trả khác gì nhiệm vụ bất khả thi, và bạn thì chỉ có thể đi những bước nhỏ.

Nhưng khi chiếc xe bắt đầu lăn bánh thì nó cũng trở nên dễ hơn, và có khi bạn còn chạy như bay luôn.

Tại sao nên chọn Python để lập trình Web App?

Nếu bạn thích học bằng video thì YouTube chính là nguồn học chính cho bạn.

Những cộng đồng như freeCodeCamp cũng là nơi học cực kì tuyệt vời mà lại miễn phí. Và điều quan trọng nhất là nếu bạn biết cách thì việc trở thành một web developer giỏi mà không tốn một xu là điều có thể.

8 tools cần có để tăng workflow khi lập trình web

Bạn không cần phải giỏi HTML và CSS thì mới làm web được

Một điều mà tôi muốn nhấn mạnh rằng: bạn không phải giỏi về HTML và CSS mới làm được web hoặc học một ngôn ngữ khác.

Bạn không phải bỏ hàng tháng chỉ để học và học. Khi đã nắm được cơ bản rồi thì cứ “múc” và thực hành thôi.

Templates không phải là kẻ thù của bạn

Template thật sự khá hữu ích. Thật sự đấy. Mặc dù đúng là nó không giúp bạn tạo ra những trang web thật sự tuyệt vời nhưng ít ra nó cung cấp framework để bạn có thể làm ra những website đẹp và chuẩn. Tôi làm tại một công ty chuyên về product và templates luôn được sử dụng vào frontend của các sản phẩm. Điều đó có nghĩa là ta tiết kiếm được thời gian và tập trung vào tính năng của sản phẩm nhiều hơn.

Tuy vậy nếu bạn muốn trở thành một frontend developer đại tài thì sẽ phải cố gắng phát triển những kĩ năng tốt nhất,nhưng template thật sự khá hữu ích đấy.

Via Medium

Có thể bạn muốn xem thêm:

Xem thêm Top Việc làm lập trình viên trên TopDev

Triết lý Marketing 0 đồng – tất cả nằm ở chữ “Mượn”

Các bạn đã từng nghe qua thuật ngữ “Zero cost-Marketing” hay còn gọi là marketing 0 đồng?

Lạ thật đúng không! bởi Marketing là một trong những ngành đòi hỏi kinh phí đủ lớn để có thể chạy một campaign thành công. Và bạn không hề sai, Marketing vốn rất phức tạp và cực kì tốn kém. Nhưng đó là với khuôn mẫu truyễn thống như quảng cáo qua TV, báo đài. Còn Zero cost-marketing là loại hình sinh sau đẻ muộn hơn, nhưng lại có tiềm năng vượt trội hơn hẳn các phương pháp truyền thông truyền thống, mà theo anh Nguyễn Ngọc Long – sáng lập truyền thông Trăng Đen đã nhận xét: “Zero cost-Marketing sẽ định hình lại bộ mặt của marketing”.

Trong buổi event với chủ đề: Triết lý Zero cost Marketing cho Star-up được tổ chức bởi TopDev, với sự tham gia của hai diễn giả: Nguyễn Ngọc Long – sáng lập truyền thông Trăng Đen và Nguyễn Minh Thảo – CEO Umbala, là hai nhân vật khá nổi tiếng trong cộng đồng marketing. Người tham dự cũng là những leader và CEO đầy tâm huyết từ các startup nên có thể nói buổi event diễn ra rất sôi nổi với nhiều câu hỏi mang tính thiết thực. Tôi cũng là một người đến tham dự và may mắn được lắng nghe những bài học quí giá từ 2 đàn anh đi trước.

Triết lý Zero cost Marketing cho Start-up cùng anh Nguyễn Minh Thảo – CEO Umbala và anh Nguyễn Ngọc Long – sáng lập truyền thông Trăng Đen

Trong bài viết ngắn này, tôi xin phép chia sẻ những quan điểm của anh Long và anh Thảo về Zero cost-marketing cũng như cách mà bạn có thể áp dụng nó vào trong chiến lược quảng cáo sản phẩm của mình.

Theo anh Minh Thảo: ” làm zero cost marketing là một điều mà không ai muốn bởi nó thể hiện rằng bạn và team phải “thắt lưng buộc bụng” và tận dụng mọi thứ mình có. Nói cách khác, Marketing không đồng có thể hiểu là thay vì bỏ chi phí cho quảng cáo thì dùng nguồn tiền đó để đâu tư cho nhân sự của team” . Do vậy, thuật ngữ zero cost marketing ở đây là chưa chính xác và dễ gây hiểu nhầm bởi ta vẫn phải bỏ tiền ra, nhưng tận dụng những nguồn lực sẵn có để marketing ít tốn kém nhất mang lại hiệu quả cao nhất.

Zero cost marketing đóng vai trò cực kì quan trọng, có thể nói là quyết định sự sống còn của một startup, anh Thảo cho biết. Có 3 nguyên nhân chính dẫn đến việc một startup bị thất bại. Đầu tiên là sản phẩm, nếu sản phẩm dở thì dù marketing có mạnh đến đâu vẫn là công cốc. Thứ hai là nguồn vốn, dù marketing có thông minh tới đâu thì ta vẫn phải rót tiền vào. Và nếu tiền cạn thì cũng là hết máu, marketing chết khô và startup phá sản. Cuối cùng chính là con người. Để làm được zero cost marketing thì phải cần có những con người có sự điên rồ cũng như khả năng thay đổi theo kịp với thời đại. Bởi bạn sẽ phải luôn làm cái mà phù hợp với thị trường và đồng thời phải là kẻ giỏi nhất. Do đó nhân sự giỏi thì marketing sẽ bớt tốn kém và hiệu quả tăng lên rất nhiều lần.

Vậy cách thực hiện zero cost marketing là gì?

Anh Thảo, cũng chia sẻ thêm: “trước khi quan tâm về cách thức thì hãy hiểu về bản thân trước. Anh cho rằng câu hỏi quan trọng hơn mà chúng ta luôn phải tự hỏi mỗi khi làm zero cost marketing là: nó để làm gì? Bạn có hiểu về sản phẩm chưa? Bạn đã biết gì về khách hàng bạn muốn nhắm tới rồi?”

Marketing 0 đồng thành công thì trong đó hơn 7, 8 phần nằm ở khâu này. Không quan trọng bạn nói gì, họ nghe gì từ bạn mới là điều quyết định. Vì thế hãy luôn chắc chắn rằng thông điệp bạn truyền tải phù hợp với đối tượng mình nhắm tới. Một vài ví dụ cho dễ hiểu là nếu khách của bạn là người trẻ, họ sẽ thích xem hình vui, clip chế. Còn nếu khách của bạn là người cao tuổi thì họ sẽ thích xem những bài post mang đậm tính giáo dục.Thế nhưng để làm ra những content “chất” như vậy, theo anh Thảo là vô cùng khó, thế nên zero cost marketing lúc này bao gồm 2 vấn đề là viral và content marketing. Nếu như viral là cách khiến cho tăng lượng người xem và biết tới thương hiệu một cách nhanh chóng thì content marketing sẽ giúp họ trở thành những người khách hàng đầy tiềm năng. Trong bài viết ngắn này thì tôi sẽ đi chuyên sâu hơn về phần Viral và phân tích phần của anh Thảo. Còn phần content marketing sẽ được giới trong bài viết sau với anh Nguyễn Ngọc Long, có thể xem là một trong những người đi tiên phong trong lĩnh vực này.

Kế sách của người làm viral – content marketing: “Mượn”

Hẵn các bạn cũng nghe câu truyện cây cổ thụ và cơn bão. Vào thuở còn sơ khai, có một cây cổ thụ dài gần trăm mét, rễ bám sâu vào đất trong khi ngọn chạm đến trời. Nghe kể, cây vĩ đại tới mức nó nối được cả thiên giới với âm giới. Cây cổ thụ được người đời kính trọng nên khoái chí lắm. Mà thói đời hễ được xưng tụng thì lại bị xấu tính. Cổ thụ liền vênh váo, hách dịch. Đặc biệt là với mấy bụi tre ốm nhách kế bên mình. Lúc đó, trời đánh hơi được nên vô cùng nổi giận, liền cho bão nổi lên ầm ầm. Cổ thụ tuy rễ đụng tới tận nóc nhà của âm phủ cũng không thể chịu nổi mà phải chổng vó gẫy ngang cả người. Trong khi đó bụi tre người mèm dẻo ngả theo gió thì lại vẫn sống sót và được ông trời khen ngợi. Thế nên bạn cũng thấy được hễ làm gì, thì người Việt mình cũng dùng tới tre như làm lồng đèn, làm giáo, làm đũa… chứ tuyệt nhiên không xài tới cổ thụ. Làm zero cost marketing cũng phải như thế. Bạn phải như cây tre, đầy mềm dẻo và biết gió theo chiều nào thì mình theo chiều đó. Có trending nào thì mình phải mượn trending đó để làm marketing.

Anh Thảo cho rằng ta phải sống “kí sinh”, ăn theo và đứng trên vai người khổng lồ. Điều đó không có gì sai bởi làm start up thì làm gì có nhiều tiền. Mặt khác, để tạo ra một content chất thì nó mất rất nhiều tiền, thời gian và cả chất xám. Vì thế nó như một “con bài trùm”. Mà bài trùm thì có bao giờ đánh liền đâu, mà phải ém, để khúc quan trọng là tung ra để ăn cả giàn. Vậy trong thời gian chờ đợi đấy, hãy “mượn”. Mượn từ nội dụng, ý tưởng, mượn các trending đem về xào nấu lại theo phong cách của mình. Đó chính là tâm ý của viral marketing. Một ví dụ nho nhỏ là những hiện tượng như Sơn Tùng và các thể loại ăn theo như hình chế, clip chế, ….. với những ý tượng na ná nhau những vẫn là hit với trăm ngàn lượt hit và share.

Hi vọng qua bài viết này, các bạn đã có thêm cái nhìn rõ ràng hơn về marketing không đồng cũng như cách thức làm chúng. Lưu ý rằng đây chỉ như là bài hướng dẫn cho bạn hiểu cách một người làm marketing suy nghĩ. Sau đó việc thực hành là tùy vào mỗi người và khả năng tiếp thu của họ.

Techtalk

3 tools giúp bạn tăng hiệu năng của React App một cách bất ngờ

React rất đơn giản để học và làm, nhưng đôi khi vì quá dễ mà chúng ta hay mắc những lỗi nhỏ nhặt nhưng lại gây ảnh hưởng đến hiệu năng của chúng. Component mounts chậm, component trees quá rối rắm, cũng như những render cycle thừa thãi khiến cho user cảm thấy ứng dụng chạy chậm.

Thật may là có rất nhiều tool giúp phân tích và xách định vấn đề về hiệu năng trong React. Trong bài viết này tôi sẽ liệt kê ra những tool và mánh khóe để cải thiện tốc độ xử lí của các ứng dụng React.

Tool #1: Performance Timeline

React 15.4.0 vừa tích hợp vào tính năng mới là “performance timeline feature” cho phép bạn biết được chính xác khi nào components được mounted, updated, và unmounted. Nó còn có khả năng hiển thị component lifecycle cũng như mối quan hệ giữa chúng.

Note: Hiện tại tính năng này chỉ dành cho Chrome, Edge, và IE.

Cách nó hoạt động

Vào app và nối đoạn query param sau: react_perf. Như thế này: http://localhost:3000?react_perf
Mở Chrome DevTools Performance tab và chọn Record
Thực hiện hành động mà bạn muốn được phân tích
Dừng record
Kiểm tra kết quả từ User Timing

Hiểu rõ kết quả (output)

Từng cột màu cho ta thấy thời điểm mà từng component hoạt động. Bởi vì JavaScript là single-threaded nên khi một component đang mount hoặc render, nó sẽ được chạy trong thread chính và các code phải ngưng lại cho đến khi quá trình trên hoàn thành.

Phần thông tin trong mục [update] cho ta biết đang trong giai đoạn nào của component lifecycle. Cũng nhu thời gian cho từng bước để giúp bạn có thể so sánh giữa các phương pháp như [componentDidMount], [componentWillReceiveProps] [ctor] (constructor) và[render].

Các cột được xếp với nhau nhằm tượng trưng cho component trees. Mặc dù theo thông thường thì chúng ta sẽ có component tree khá lớn trong React, nếu bạn đang tinh chỉnh một component thương xuyên được mounted, nó sẽ giúp làm giảm số lượng của wrapper component và kết quả là cải thiện hiệu năng của app.

Điều cần lưu ý là thời gian xử lí trong quá trình phát triển app luôn sẽ chậm hơn so với thông số thật. Tuy là bạn không nên quá dựa vào những thông số trên nhưng sự khác biệt cũng không nhiều và nó cho ta cái nhìn rõ hơn về chất lượng và hiệu năng của sản phẩm đang ở đâu.

Demo #1

Để cho vui, tôi thử phá TodoMVC app để khiến nó có những vấn đề nghiêm trọng về hiệu năng. bạn cũng có thể thử chúng tại đây.

Để xem timeline, mở Chrome dev tools, vào “Performance” tab, chọn Record. Sau đó thêm TODOs vào trong app, dừng record, và xem timeline. Hãy thử xem bạn có thể biết được component chính là nguyên nhân khiến cho hiệu năng bị ảnh hưởng không.

Tool #2: why-did-you-update

Một trong những nguyên nhân chính khiến cho các ứng dụng trên React chạy chậm là bởi có quá nhiều render cycle không cần thiết. Khi để ở chế độ mặc định, React components sẽ re-render khi ba mẹ chúng (component chứa chúng) reder cho dù là không có thay đổi bất cứ thứ gì.

Một ví dụ đơn giản là với component sau:

class DumbComponent extends Component {
  render() {
    return <div> {this.props.value} </div>;
  }
}

Tham khảo việc làm lập trình React lương cao cho bạn

Với một component mẹ như thế này:

class Parent extends Component {
  render() {
    return <div>
      <DumbComponent value={3} />
    </div>;
  }
}

Mỗi khi component mẹ render thì DumbComponent re-render cho dù props của nó chả thay đổi gì.

Nói cách khác render chạy nhưng DOM ảo vẫn không thay đổi gì và một render cycle bị phí phạm. Với một app lớn thì việc xác định ra nguồn ngọn sẽ rất khó khăn, may thay chúng ta đã có một tool cho trường hợp này.

Sử dụng why-did-you-update

why-did-you-update là một library dành cho React với chức năng phát hiện ra những component render không cần thiết. Nó sẽ theo dõi và ngay lập tức phát hiện ra những component’s render mà prop lại không có thay đổi.

Setup

Cài đặt với npm: npm i --save-dev why-did-you-update
Thêm phần dưới đâu vào bất kì đâu của app của bạn:

import React from 'react'
if (process.env.NODE_ENV !== 'production') {
  const {whyDidYouUpdate} = require('why-did-you-update')
  whyDidYouUpdate(React)
}

Demo #2

Để cho bạn thấy khả năng why-did-you-update, tôi cài library đó vào TodoMVC app trên Code Sandbox, một online React playground. Mở trình duyệt console và thêm một số TODOs để xem kết quả.

Bạn có thể lấy bản Demo tại đây.

Bạn sẽ thấy một số component trong app render một cách không cần thiết. Hãy thử dùng kĩ thuật trên để khắc phục chúng.

Tool #3: React Developer Tools

React Developer Tools Chrome extension có một tính năng là hiển thị component updates. Nó cực kì tiện lỡi cho việc phát hiện ra những render cycles không cần thiết. Để sử dụng nó trước hết bạn cần phải cài extension đấy.

Sau đó mở extension bằng bấm vào “React” tab của Chrome DevTools và chọn phần “Highlight Updates”.

Giờ thì chỉ việc dùng app, tương tác với compopnent và chứng kiến DevTool thực hiện phép thuật của nó.

Hiểu rõ kết quả (output)

React Developer Tools sẽ highlights các components có redering. Nó còn cho màu sắc khác nhau như xanh, vàng, đỏ tùy thuộc vào việc component có render thường xuyên hay không.

Vàng và đỏ không có nghĩa là xấu bởi đôi khi ta update hoặc chạy nhiều tính năng nên khiến cho render diễn ra nhiều. Tuy nhiên nếu chỉ nhấn một nút đơn giản mà đã ra mà đỏ rồi thì khá là có vấn đề đấy. Mục đích của tool này là để chúng ta biết được update nào là không cần thiết. Và là một App developer, bạn sẽ biết khi nào thì enn6 update component.

Demo #3

Để bạn hiểu rõ hơn về tính năng component highlight, tôi đã sửa cho TodoMVC app update không cần thiết một số component.

Bạn có thể download bản Demo tại đây.

Vào đường link trên, mở React Developer Tools và chọn update highlighting. Khi bạn type trong text input, ta sẽ thấy toàn bộ TODOs highlight không cần thiết. Và khi bạn type nhanh hơn thì màu sắc cùa hightlight cũng sẽ biến đổi liên tục nhằm ám chỉ việc update thường xuyên.

Khắc phục renders thừa thãi

Sau khi bạn đã xác định được components nào re-rendering thừa thãi thì ta sẽ tìm cách khác phục chúng. Sau đây là một số phương pháp khá đơn giản.

Sử dụng PureComponent

Trong ví dụ trên, DumbComponent là một pure function cho props của nó. Nói cách khác, component chỉ re-render khi Prop thay đổi. Có thể nói tính năng `PureComponent` trong React chính là để dùng cho trường hợp đặc biệt này.

Bạn có thể dùng React.PureComponent như sau:

class DumbComponent extends PureComponent {
  render() {
    return <div> {this.props.value} </div>;
  }
}

Và thế là xong rồi đấy.

Tuy vậy, PureComponent chỉ quét sơ Props để phát hiện ra những thay đổi. Thế nên nếu trong trường hợp là một app phức tạp với nhiều Props khác nhau thì PureComponent đôi khi bỏ qua một số và sẽ không thay đổi.

Áp dụng shouldComponentUpdate

shouldComponentUpdate là một phương pháp của component khi ta call trước khi render nếuprops or state có thay đổi hay không. Nếu shouldComponentUpdate cho kết quả là true, thì render sẽ diễn ra còn nếu là false thì mọi thứ đều được giữ nguyên.

Với phương pháp trên, bạn có thể chỉ React cách tránh re-rendering thừa thãi với component mà props của nó không có thay đổi.

Chúng ta có thể áp dụng shouldComponentUpdate vào ví dụ trên như sau:

class DumbComponent extends Component {
  shouldComponentUpdate(nextProps) {
    if (this.props.value !== nextProps.value) {
      return true;
    } else {
      return false;
    }
  }
render() {
    return <div>foo</div>;
  }
}

Debugging vấn đề về hiệu năng

The React Developer Tools chỉ hoạt động với app của bạn trong máy của bạn. Thế nên nếu bạn muốn biết những vấn đề hiệu năng khi khách hàng sử dụng sản phẩm của mình thì hãy thử LogRocket.

LogRocket giống như DVR dành cho web apps, nó record lại tất cả mọi thứ xảy ra trên website của bạn. Nhờ đó thay vì phỏng đoán một cách mơ hồ thì giờ bạn đã có thể nhanh chóng replay lại và xác định được ngay vấn đề dẫn đến việc hiệu năng bị giảm sút.

LogRocket sẽ khiến App của bạn record thông tin về hiệu năng, Redux actions/state, logs, errors, network requests/responses với headers + bodies, và browser metadata. Không chỉ thế, nó còn record cả HTML và CSS trên trang, tạo lại videos chính xác tới từng pixel của các app một trang phức tạp nhất có thể.

Cảm ơn vì đã đọc bài viết này và hi vọng nó sẽ giúp ích cho các bạn trong project React tiếp theo.

Nguồn: topdev via Medium

Tham khảo thêm vị trí việc làm ngành IT tại đây

Database conventions

(1) Thiết kế database là công việc thường ngày của engineer, nhất là các bạn database engineer. Giống với coding cần clean, database cũng cần tính chất tương tự nhằm giúp việc vận hành, thay đổi, chuyển giao nó đỡ tốn nhiều công sức hơn, do đó chúng ta cũng cần có một số quy tắc nhất định trong việc thiết kế.

Thường thì mỗi nhóm hay công ty sẽ có bộ quy tắc riêng cho mình, cho dù có được viết thành document rõ ràng hoặc không. Cũng giống như coding có nhiều trường phái khác nhau, ví dụ python thì có hai đại diện tiêu biểu là PEP8 và Google Python Style Guide, Database conventions cũng không nhất thiết phải tuân theo một chuẩn duy nhất, miễn sao nó mang lại những giá trị mà theo tôi là quan trọng nhất: Sự thống nhất (Consistency) và Dễ hiểu (Simplicity, Self-explaining)

(2) Đã bao giờ bạn nhìn vào thiết kế DB của hệ thống cũ khi gia nhập vào một công ty mới hoặc khi bạn tham gia vào một team khác và tự hỏi những câu giống như dưới đây không?

“WTF is this field?” (ca này hay gặp nhất :D)
“Cái field status này có giá trị là 0-1 hay còn gì khác không?” (chẹp, SELECT DISTINCT để tìm chân lý vậy)
(đang code) “Table random này thì PK là id hay random_id nhỉ?” (mở DB ra coi lại)

Well, cá nhân tôi đã gặp khá nhiều và trở thành ám ảnh khi phải tiếp cận với một hệ thống lớn và phức tạp (ví dụ có 1000 table chẳng hạn) mà lại thiếu document. Đừng hiểu nhầm, tôi không kỳ vọng một bộ document cực kỳ lớn tới mức tôi phải lấy nhiều dũng cảm mới có thể đọc hết cho 1000 table kia, hoặc mỗi khi muốn biết 1 field là gì lại phải giở tài liệu ra tìm kiếm. Phần lớn các field đều có thể hiểu nhanh được nếu đặt tên tốt và có lúc cũng cần giải thích ngắn gọn đi kèm. Đây là 1 ví dụ:

(3) Vậy có cần DB document hay không? Tôi nghĩ là vẫn cần. Mỗi business/domain có các đặc thù riêng, dẫn tới các data field cũng khá đặc biệt nên nếu tôi không tìm hiểu kỹ thì sẽ chẳng hiểu nổi nó là gì, tương tác với dữ liệu đó sao cho đúng, như ví dụ dưới đây:

(4) Sẽ dễ dàng hơn nếu ngay từ khi thiết kế, chúng ta tuân theo một quy tắc là làm sao lần sau đụng tới thì tốn ít effort nhất có thể. Nhiều quy tắc được tổng hợp và thống nhất trong team thì trở thành bộ Database Conventions của team đó.

Trong bài này tôi sẽ đề cập tới một số conventions mà tôi và team của mình hay dùng.

Xem thêm: Việc làm Database lương cạnh tranh hấp dẫn

Nên	Ví dụ	Không nên	Giải thích
Tên là danh từ tiếng Anh
Chỉ dùng danh từ số ít	`inventory` `shelf` `octopus`	`inventories` `octopodes` `shelves` `octopuses` `octopi`	Đỡ mất thời gian nghĩ
Chỉ dùng `lower_case`	`customer`	`customer`
Chỉ dùng dấu gạch dưới `_` để nối các từ	`first_name`	`FirstName` `firstName` `"First Name"`	– Dễ đọc hơn – Đỡ thắc mắc khi nào thì có chữ hoa, khi nào thì có gạch dưới
Tên có tính tự giải thích. – Tránh dùng từ viết tắt – Tránh dùng kiểu dữ liệu thay cho tên	`middle_name` `blog`.`content` `amt`	`mid_nm` `blog` .`text` `amount`	Dễ hiểu
Tránh dùng từ khóa của SQL	`display_order` `updated_at user_name`	`order` `date` `name`	Có thể bị báo lỗi syntax nếu không enquote
Tên ngắn gọn, không nên dài quá 64 ký tự

Nên	Ví dụ	Không nên	Giải thích
Đặt prefix cho các table liên quan	`catalog_category` `catalog_product`		Tìm kiếm table dễ hơn
Thêm suffix `_tmp` cho các table dùng tạm trong tính toán nhưng không xóa	`catalog_product_price_tmp`
Thêm prefix `tmp_` cho các table dùng tạm, có thể xóa	`tmp_im_calculating`

Nên	Ví dụ	Không nên	Giải thích
Tránh thêm tiền tố không cần thiết	`product`.`name`	`product`.`product_name`	– Tên table đã nêu rõ context
Thêm prefix `is_` cho các field dạng YES/NO	`is_active` `is_deliveredis_free_shipping`	`active` `delivered` `free_shipping`	Nhìn field là biết chỉ có 2 giá trị
Nên lưu các thời điểm thay đổi dữ liệu với từng record	`created_at` `updated_at` `deleted_at`		Theo dõi tính toàn vẹn dữ liệu
Không đặt tên chứa kiểu dữ liệu	`return_code`	`int_return_code`	Kiểu dữ liệu có thể thay đổi: – date => timestamp – int => bigint

Nên	Ví dụ	Không nên	Giải thích
Chỉ nên dùng PK là `id`	`table` .`id`	`table` .`table_id`	– Dễ nhớ – Giảm effort khi đổi tên table sau này
Mỗi table nên có 1 PK, bên cạnh các UNIQUE KEY khác	PRIMARY KEY (id), UNIQUE KEY idx_unique (key1,key2)		Làm việc với các record nhanh hơn
PK mặc định nên dùng kiểu Interger, Auto-increment

Nên	Không nên	Giải thích
Tên FK được kết hợp từ tên field và tên table mà nó tham chiếu tới	`person_id` là FK của table và field `person.id`	Dễ hiểu
Tùy chọn Cascading Update có thể dùng, nhưng Cascading Delete thì nên tránh		Giảm rủi ro khi lỡ xóa record ở main table khiến cho toàn bộ dữ liệu liên quan biến mất

Nên	Ví dụ	Giải thích
Thêm prefix idx_ ở đầu	`idx_created_at`	Dễ nhớ, nhất là khi ALTER TABLE mà không dùng GUI Tool

Có nhiều quy tắc để nhớ, tuy nhiên có thể dựa trên nguyên tắc thiết kế ban đầu là:

Be Consistent and Simple, don’t waste your brain any single second for any unnecessary thing

Bạn có best-practice hoặc các quy tắc nào khác hữu ích hơn cho việc thiết kế Database không? Nếu có hãy chia sẻ cho mọi người tại đây nhé!

Nguồn: kipalog

Review: phỏng vấn vào vị trí SDE của Amazon

Mình vừa kết thúc job interview với Amazon vào tuần trước và đang chờ kết quả. Trong quá trình chờ đợi này, mình quyết định viết 1 cái note để kể về quá trình phỏng vấn, giúp cho anh chị em bạn bè nào muốn apply vào công ty này có thể mạnh dạn hơn. Mình không đợi có kết quả rồi mới viết vì sợ lúc đó chả có hứng nữa..

Vì mình ký vào bản cam kết NDA của Amazon, nên sẽ không tiết lộ bất cứ câu hỏi phỏng vấn hay tài liệu Amazon cung cấp nào trong bài viết này. Mình chỉ mô tả các bước tuyển dụng, độ khó dễ và feeling của cá nhân thôi. Ví trí mình phỏng vấn đợt này là SDE (Software Development Engineer), làm việc tại Vancouver, Canada. Có lẽ mình nên bắt đầu câu chuyện bằng lý do tại sao mình lại apply vào đây. Bên Amazon người ta đi khắp các nước để tổ chức Hiring Event, và Việt Nam là 1 trong số các điểm đến.

Hiring Event ở VN được ấn định vào 18-20/4/2017. Do vậy, trước đó 3, 4 tháng, các recruiters của Amazon lùng sục khắp cộng đồng LinkedIn ở VN để tìm ứng viên. Và may mắn thay, profile của mình lọt vào tầm ngắm của họ, và vào ngày 25/2 họ gửi mail mời mình join hiring process này, đúng 1 tháng sau khi mình nghỉ việc ở Zalo. Lúc đó mình đang cày IELTS điên cuồng và không định apply vì… sợ mất thời gian (trước đó có myth là phỏng vấn vào mấy công ty to như thế này rất khó và phải chuẩn bị cả năm trời mới okay). Sau cùng nhờ sự động viên của 1 vài người anh em, mình quyết định nộp CV cho người ta.

Vì người ta đã chọn mình trước nên đương nhiên vòng CV mình sẽ pass. Nhưng với nhiều bạn, vòng CV có thể là 1 vòng khó, nếu bạn không biết trau chuốt và nêu các thế mạnh của mình ra. Do vậy các bạn nên nghiên cứu kỹ, ví dụ link này Sau khi nhận được CV của mình, recruiter lập tức move forward sang bước thứ 2 là coding challenge. Mình được cho 1 cái link, mở ra là 1 IDE online, đi kèm với đề bài, kiểu như trang hackerrank vậy. Mình phải giải quyết 2 problems trong vòng 90 phút. Problems không quá khó, khá cơ bản, nếu bạn nào từng thi Google Code Jam thì còn thấy mấy bài này dễ hơn.

Chủ yếu mấy bài này test kiến thức Data Structure và Basic Algorithm thôi. Các bạn có thể dễ dàng search các đề bài kiểu này trên internet. Nếu các bạn thiếu tự tin thì có thể lên trang hackerrank để luyện tập. Mình thì hôm đó nhảy vào làm luôn vì lười luyện (lúc này vẫn đang tập trung cày IELTS. 1 tuần sau Coding Challenge, mình nhận được kết quả là đã pass và move forward tới vòng Phone Interview. Ở vòng này, người ta bảo rõ với mình là sẽ hỏi về DS (Array, List, Tree, Graph, HashTable…), Algorithm (BFS, DFS, Tree Traversal, Recursive function…) và quan trọng là hỏi về 1 vài example của mình trong công việc. Câu hỏi đó thường là “tell mReview: phỏng vấn vào vị trí SDE của Amazone about a situation in which you ….”.

Các câu hỏi kiểu này cũng dễ tìm thấy trên mạng nên mình ko nêu ra ở đây. Chỉ lưu ý các bạn là phải chuẩn bị trước kỹ càng cho các câu hỏi này, vì nó đóng vai trò rất quan trọng trong việc đánh giá của người ta. Phone Interview chỉ kéo dài 30 mins thôi nên đừng lo lắng quá. Cố gắng tập luyện để nói cho trôi chảy và hiểu được câu hỏi của recruiter cộng với review lại kiến thức để trả lời cho chắc chắn.

Hơn 1 tuần sau vòng Phone Interview, mình nhận được kết quả báo đã pass và được join hiring event. Hiring Event sẽ là face-to-face interview theo dạng loop. Có nghĩa là trong 1 buổi, kéo dài 4 tiếng, mình sẽ có 4 cuộc interview nhỏ với 4 nhóm Interviewers khác nhau. Hiring Event được tổ chức tại khách sạn Pullman, Ho Chi Minh City, và toàn bộ interviewers lẫn coordinators sẽ bay từ Canada sang Việt Nam để tổ chức. Từ lúc nhận tin đến lúc phỏng vấn thì mình chỉ có gần 20 ngày để chuẩn bị. Recruiters rất chu đáo khi gửi mình đầy đủ toàn bộ topic lẫn document cần phải nghiên cứu để chuẩn bị cho phỏng vấn.

Chỉ mỗi tội là khối lượng là khá nhiều nên khó để mà chuẩn bị được chu đáo trong 20 ngày. Nếu vượt qua được vòng này thì mình sẽ nhận được offer của Amazon, nên mình quyết tâm tạm dừng cày Ielts để dấn thân vào ôn luyện. 4 interviews sẽ có format tương tự nhau. Mỗi interview kéo dài 50 mins. 25-30 mins đầu dành cho việc hỏi các example (câu hỏi kiểu “tell me about a situation…” mà mình đề cập ở trên).

Người ta xoáy khá sâu vào các câu trả lời của mình, hỏi tường tận từng gốc rễ. Các example mà mình đưa ra vì vậy cần phải trung thực, bịa là biết liền. Quan trọng nhất là các example đó phải align với leadership principles của Amazon. Với phân nửa thời gian dùng để hỏi mấy cái này nên mình nhận thức được nó quan trọng như thế nào và cũng chuẩn bị khá kỹ, mặc dù vậy, có 1 vài câu hỏi vẫn không nghĩ ra được example ngay, phải xin họ 1 phút để ngồi ngẫm. Phần thời gian còn lại của interview là dành cho coding exercise (khoảng 20-25 mins).

Đề bài khá đa dạng, và toàn bộ code của mình phải viết trên bảng trắng (white board), chứ không phải bằng keyboard (cái này sinh viên BKHN chắc master luôn vì toàn phải thi lập trình trên giấy). Loop 1 mình được cho 1 đoạn code dài 1 trang A4 và yêu cầu viết lại cho dễ maintain và develop về sau. Key để solve được bài này là phải hiểu và vận dụng được cái Abstract Factory để thay cho 1 đoạn check if else quá dài. Do vậy, kinh nghiệm là phải nắm rõ được các Design Pattern cơ bản để giải. Loop 2 là 1 bài dạng Tree, áp dụng đệ quy linh hoạt chút là giải okay.

Loop 3 là 1 bài dạng graph, cũng không phức tạp lắm. Khó nhất là loop 4, là 1 bài Object Oriented System Design. Đề bài là 1 tình huống trong đời thực và mình phải vận dụng các kỹ năng thiết kế hướng đối tượng để mô hình hóa thành các class, viết các phương thức giao tiếp chính giữa các class. Mình vận dụng hết aggregation với inheritance, Queue, Timer, EventListener… để giải bài này.

Tuy không được hoàn chỉnh nhưng interviewer cũng accept cách làm của mình. Trong lúc giải các bài coding, mình contact liên tục với interviewers, hỏi họ bất cứ thứ gì mà mình thấy confuse, thỉnh thoảng họ cũng đưa ra gợi ý hoặc hỏi thêm mình 1 số câu hỏi. Điều đó giúp cho mình giải quyết các vấn đề nhanh hơn và tối ưu hơn. Mình coi các interviewers như những người đồng nghiệp đang trao đổi về bài toán với mình, chứ ko phải examiners trong 1 cuộc thi. Đây cũng là cách mình học hỏi qua cuốn Crack the Coding Interview. Các bạn quan tâm có thể đọc cuốn này, rất bổ ích. Cuối mỗi interview, các interviewers sẽ cho mình thời gian khoảng 5 phút để đặt câu hỏi cho họ.

Ban đầu mình chỉ chuẩn bị có 2,3 câu, hỏi 1 lần là hết, nên sau đó vào giờ nghỉ giải lao, phải vắt óc nghĩ xem nên hỏi người ta câu gì cho hay, cho ý nghĩa Nếu có lần sau chắc chuẩn bị hẳn chục câu từ ở nhà luôn. Mình vẫn đang đợi kết quả cuối cùng từ Amazon, nếu fail thì đây là bài viết duy nhất của mình nói về Hiring Process của Amazon.

Còn nếu pass thì mình sẽ có 1 số bài viết cụ thể hơn để nói về cách mình vượt qua từng vòng, từng vòng. Dù sao thì việc được tham gia phỏng vấn cũng là 1 trải nghiệm thú vị và đáng nhớ đối với mình Do vậy mình ko hề tiếc vì đã tiêu tốn thời gian cho sự kiện này. Cảm ơn các bạn đã bớt chút thời gian để đọc À một điều may mắn đối với mình là Amazon lại liên hệ đúng lúc mình đang nghỉ Zalo để học Ielts, nên trình nói tiếng Anh đang lên, và cũng có nhiều thời gian để chuẩn bị. Chứ nếu vừa đi làm vừa chuẩn bị thì chắc fail từ vòng gửi xe Update mới nhất 11h20pm ngày 26/04/2017: recruiter gọi điện cho mình báo pass interview. Chờ deal lương và làm thủ tục

Nguồn: Ken Nguyễn

Đâ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?

Vì sao bạn nên biết về Vim?

5 free online resources dành cho các bạn

VimTutor

Lời kết

Nhanh tay đăng kí để dành những slot ngồi giới hạn TẠI ĐÂY!

Giữ bình tĩnh

Tìm hiểu nguyên nhân vì sao đồng nghiệp hưởng lương cao hơn

Tham khảo mức lương trên thị trường

Trao đổi với bộ phận nhân sự

Nói chuyện với sếp

Tìm công việc mới

Tôi biết lập trình nhưng không biết lập trình cái gì?

Cách học trên trường?

Chưa đủ trình

Không tìm hiểu kiến thức ngoài chuyên ngành

Kết luận

Weex

NativeScript

Tóm tắt điểm mạnh và yếu

Weex :

nativescript-vue:

Kết luận

Links

Weex:

NativeScript + Vue.js:

1/ Trước tiên, anh có thể giới thiệu đôi chút về công ty Futurify?

2/ Được biết Futurify đã triển khai rất nhiều dự án trong và ngoài nước. Vậy dự án nào khiến anh tâm đắc nhất cho tới thời điểm hiện tại?

3/ Theo anh, làm dự án với đối tác nước ngoài thì có điểm gì khác so với đối tác Việt Nam?

4/ Điểm đặc biệt trong quy trình xây dựng sản phẩm của Futurify là gì?

5/ Lập trình viên khi làm việc với kiến trúc Microservices cần phải lưu ý những vấn đề gì?

6/ Hiện nay, các dự án Cross-platform đang thu hút sự chú ý đặc biệt của cộng đồng lập trình, anh có đánh giá gì về tiềm năng của lập trình đa nền tảng trong thời gian sắp tới?

7/ Với những bạn lập trình viên mong muốn được làm việc tại Futurify cần đáp ứng những yêu cầu gì?

8/ Anh có thể chia sẻ về định hướng phát triển của Futurify trong thời gian tới?

Hiểu cách giao tiếp với máy móc

Hiểu các khái niệm cấp cao

Cải thiện sự sáng tạo

Mở rộng chân trời trí tuệ

Máy móc có chức năng hỗ trợ và tăng cường

Điêu gì sẽ diễn ra tiếp theo?

Lập trình website là gì?

Những lời khuyên về lập trình web

Hãy học code như bạn đang cố gắng trở thành người mạnh nhất thế giới.

Bạn không cần phải giỏi HTML và CSS thì mới làm web được

Templates không phải là kẻ thù của bạn

Vậy cách thực hiện zero cost marketing là gì?

Kế sách của người làm viral – content marketing: “Mượn”

Tool #1: Performance Timeline

Cách nó hoạt động

Hiểu rõ kết quả (output)

Demo #1

Tool #2: why-did-you-update

Một ví dụ đơn giản là với component sau:

Với một component mẹ như thế này:

Sử dụng why-did-you-update

Setup

Demo #2

Tool #3: React Developer Tools

Hiểu rõ kết quả (output)

Demo #3

Khắc phục renders thừa thãi

Sử dụng PureComponent

Áp dụng shouldComponentUpdate

Debugging vấn đề về hiệu năng

1. Intro

2. DB Conventions

2.1. Một số quy tắc chung về đặt tên

2.2. Table

2.3. Column

2.3.1. Column

2.3.2. Primary Key

2.3.3. Foreign Keys

2.3.4. Indexes

3. Tổng kết

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

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

Ai sử dụng Node.js?

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

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

Tương lai của Node.js

Học Node.js