Home Blog Page 225

Giải đáp UX: User Empathy Mapping là gì? User Story được form như thế nào?

Le Quang Phowr

AMA (Ask Me Everything) là sự kiện Hỏi – đáp diễn ra thường kì trên fanpage Topdev nhằm tạo cơ hội để các bạn lập trình viên tiếp cận được những kiến thức, kinh nghiệm thực tế từ các chuyên gia trong ngành thông qua những màn hỏi đáp trực tuyến nóng hổi. Bắt đầu từ đầu năm 2017, sự kiện AMA sẽ kéo dài nguyên tuần từ 8h sáng thứ 3 đến 24h thứ 6 hằng tuần để cộng đồng dev có nhiều thời gian trao đổi với các chuyên gia hơn.

Khách mời sẽ xông đất năm mới cho sẽ là anh Quang Phowr – một Product Manager kỳ cựu đang làm việc tại Websosanh.

Trước tiên chúng ta hãy cùng tìm hiểu đôi nét về khách mời nhé:

  • Anh đã từng kinh qua các vị trí như Product Designer và PM tại VNP
  • Năm 2014 làm PM và Mobile Development Manager tại VNP Group
  • Tháng 7/2014 anh đảm nhiệm vị trí VP Business Development tại CubicWater
  • Tháng 9/2014 đến tháng 5/2015 anh làm Product Specialist tại VinEcom thuộc VinGroup
  • Anh đã có 1 năm nắm giữ vai trò Head of Product ở Haravan và hiện tại anh đang là Head of Product tại Websosanh.vn

Lĩnh vực chuyên môn mà anh trao đổi kì này vẫn là UX trong lĩnh vực thương mại điện tử.

Dưới đây là những thắc mắc đã được anh Quang Phowr giải đáp tuần rồi. Cùng xem qua để rút tỉa kinh nghiệm cho bản thân nha các dev!

Q: Chào anh Quang ạ, anh có thể chia sẻ cấu trúc và cách xây dựng User Empathy Maping, từ đó làm thế nào liệt kê đc triệt để các User Story ạ? Hiện tại team em đang có kế hoạch improve website của mình https://www.tripi.vn/ . Anh có thể cho bọn em 1 vài góp ý, trước hết là ở trang chủ đc ko ạ? Em cảm ơn anh ạ

A: User Empathy Mapping có 2 phần quan trọng nhất là Pain và Gain. Pain là những thứ người dùng đang gặp khó khăn, khó chịu. Gain là những thứ người dùng muốn đạt được.

User story được form dưới dạng cấu trúc, As a [user segment], I want to [do something] so that I can [achieve something]

Có 2 chú ý:
1, Làm user empathy map với từng user segment (nếu có nhiều hơn 1 user segment)
2, Achieve something trong user story có thể đến từ phần GAIN hoặc đã giải quyết được phần PAIN

Ví dụ: Là một người hay bay thường xuyên, tôi muốn tripi có chức năng săn vé tự động, để tôi bay được nhiều chuyến hơn (gain). Là một người bận bịu, tôi muốn tripi có chức năng săn vé tự động, để tôi không mất thời gian đi săn vé (pain)

User segmentation do cách team thống nhất với nhau để dễ phục vụ khách hàng hơn chứ ko có quy chuẩn chung

Q: Hello anh em học chuyên ngành thương mại điện tử về tech e cũng biết 1 ít và về kinh tế cũng biết 1 ít, em rất thích làm 1 product manager như a, a có thể chia sẻ 1 số bước cơ bản để trở thành 1 PM không ạ. E cũng tò mò là hồi đó anh Quang học chuyên ngành gì ạ hehe.

A: Chào Nam, sry em vì comment bị trôi nên giờ anh mới trả lời.

Trước anh học CNTT ở Bách khoa Hà Nội. Anh cũng background là dev 1 thời gian. Nói chung, product manager phải biết khá nhiều thứ. Tùy vào tổ chức công ty mà vai trò lớn hay nhỏ.

Với PM trong mảng phát triển sản phẩm (product development manager) thì việc chính là đưa ra các giải pháp để phát triển sản phẩm. Lúc này là sự giao thoa giữa business, tech và user experience. Em cần có background của 3 cái này thì giải pháp đưa ra mới hiệu quả (bám sát business, khả thi với tech và ux tốt)

Với PM trong mảng quản lý sản phẩm nói chung (có một số nơi gọi là product owner hoặc product director) thì PM ngoài việc quản lý development còn có thêm 2 phần nữa là product strategy và product operation. Lúc này cần hiểu biết rất sâu về đối thủ, chiến lược thị trường, marketing, sale, vận hành doanh nghiệp để đưa ra các quyết định sản phẩm hợp lý. Thường PM dạng này là CEO công ty hoặc hoạt động như CEO của sản phẩm. Startup thì CEO kiêm PM luôn, vừa định hướng, vừa phát triển, vừa vận hành. Hoặc là các dự án độc lập trong 1 công ty to cũng tương tự như vậy.

Các bước cơ bản thì em nên tích lũy kinh nghiệm công việc, trải nghiệm sống, tự tạo mục tiêu cho bản thân trong việc học (học gì thì anh nói ở phía trên rồi). Tìm các môi trường thực hành và kiểm nghiệm kiến thức của mình như các công ty sản phẩm sẽ hiệu quả. Chúc em thành công

Q: Chào anh, em hiện cũng đang thích theo đuổi UX Designer. Tuy nhiên, em vẫn còn chút chưa rõ về công việc. Vậy anh có thể mô tả công việc cụ thể của chức danh UX Designer tại Websosanh được không ạ?

A: Chào Dương. Anh sẽ trả lời em ở phạm vi rộng hơn là chức danh UX Designer ở các công ty Việt Nam.

Hiện nay có nhiều công ty đặc biệt là các công ty lớn như VNG, Tiki, Viettel, Lazada… có nhu cầu về vị trí này nhưng rất khó tuyển người và đãi ngộ các vị trí này tương đối cao so với mặt bằng thu nhập nói chung.

Hiện tại có 2 vị trí phổ biển em sẽ thấy thông qua các mẫu tuyển dụng:
– UX/UI Designer
– UX Designer hoặc các vị trí có công việc tương tự như product executive, product manager

Với UX/UI Designer (tuyển dụng nhiều) thì em sẽ phải lo cả về mặt đồ họa và giao diện khi thiết kế một ứng dụng di động hoặc một website
Với UX Designer (ở các công ty lớn) thì sẽ có những bạn lo phần đồ họa và giao diện nên em sẽ san sẻ được phần nào công việc.

Công việc chính của UX Designer nói chúng là tìm hiểu vấn đề của phía người dùng thông qua nhiều phương pháp khác nhau như hỏi người dùng, tự cảm thông người dùng, … Từ đó đưa ra các giải pháp cải thiện và theo dõi hiệu quả của việc cải thiện

Q: Hiện nay, các công ty lớn đang dần chú trọng vào phát triển đội ngũ UX designer vì họ nhận ra UX là yếu tố cơ bản tạo nên sự thành công trong hoạt động kinh doanh thương mại điện tử. Anh có thể chia sẽ chi tiết hơn là vì sao UX lại là yếu tố cơ bản trong thành công của thương mại điện tử không ạ?

A: Chào Phong, anh nói rộng hơn TMDT mà ngành công nghệ nói chung

Khái niệm user phổ biến trong lĩnh vực phần mềm. Ngoài đời sống thì được gọi với cái tên customer. Trải nghiệm người dùng UX hay rộng hơn là trải nghiệm khách hàng CX (chú ý hai khái niệm này không phải lúc nào cũng tương đương, phụ thuộc vào góc nhìn). Khách hàng quan trọng với doanh nghiệp thế nào thì User quan trọng với phần mềm như vậy. Bên kinh doanh có câu “Khách hàng là thượng đế” chắc em còn nhớ.

Trước đây phần mềm được xây dựng để sử dụng trong doanh nghiệp, và để sử dụng được thì phải thông qua đào tạo sử dụng. Tuy nhiên xu hướng internet nên các phần mềm lên mây nhiều hơn. Vì lên mây nhiều nên có nhiều sự so sánh cạnh tranh cái này tiện hơn, cái kia tốt hơn v.v. Từ đó UX là một trong các yếu tố giúp phần mềm bán được (phần mềm ở đây em hiểu theo nghĩa rộng là 1 chương trình máy tính cho người sử dụng, tùy cách bán là thu tiền như các dịch vụ SaaS hay miễn phí rồi bán sản phẩm cho đối tượng khác như Facebook bán quảng cáo)

Sales/Marketing có vai trò thu hút khách hàng về, khách hàng kí hợp đồng. Tuy nhiên để giữ được khách hay không thì lại góp công lớn nhờ chất lượng của phần mềm. Phần mềm mà khó sử dụng, không đáp ứng được nhu cầu, nhàm chán thì việc bán lại lần thứ hai rất khó (vì hiện tại có nhiều lựa chọn rồi). UX có vai trò trong việc giữ khách hàng.

Ngoài ra UX cũng giúp khách hàng chi trả nhiều tiền hơn, có nhiều thiện cảm hơn đối với phần mềm, từ đó giúp doanh nghiệp tăng trưởng bền vững hơn (nhiều lợi nhuận tốt vì NPS tăng lên)

Q: Anh có thể chia sẻ một vài thủ thuật nhỏ nhằm giúp website trông thân thiện với người dùng hơn được không ạ?

A: Trước tiên bạn cần xác định nhóm người dùng của website mình là ai?

Bước 2, bạn giả định mình là họ và trả lời một số câu hỏi:
1, Website của mình đã đáp ứng được nhu cầu sử dụng của họ hay chưa?
2, Website của mình có quá khó hiểu với họ không?
3, Website của mình có bị lỗi ở đâu không?
4, Website của mình có hấp dẫn với họ (về nội dung lẫn giao diện)
5, Website của họ có mang lại nhiều giá trị cho họ hơn các website đối thủ không?

Từ những câu hỏi này bạn sẽ cải thiện. Khi ấy website của bạn sẽ ngày càng thân thiện với người sử dụng hơn

Q: Chào @Le Quang!

Theo giới thiệu, bạn hiện đang làm tại công ty so sánh giá lớn nhất hiên nay là http://websosanh.vn

Bạn có thể chia sẻ một số kinh nghiệm khi làm ở đó được không?
– Việc thiết kế ui/ux của họ có thực sự hướng đến ngừoi dùng không?
– Họ không bán hàng, thì trải nghiệm người dùng trên websosanh.vn dc họ đánh giá thế nào?

Cảm ơn bạn rất nhiều!

A: Chào anh Tú.

Hiện tại websosanh đang dễ dùng hơn trước. Thay đổi cần có thời gian nhưng đang đi đúng lộ trình.

Websosanh.vn không bán hàng nhưng mang lại giá trị là cung cấp nhiều lựa chọn hơn cho người dùng để linh hoạt lựa chọn mua sắm cho phù hợp.

Mình lấy ví dụ anh cần mua Iphone 7 anh phải vào nhiều nơi để khảo giá thì thay vào đó chỉ cần vào websosanh là đủ. Giả sử anh chỉ vào lazada để xem thôi thì anh bị phụ thuộc vào chính sách vận chuyển của lazada, có thể vài ngày anh mới nhận được hàng. Tuy nhiên với websosanh thì anh biết được địa điểm nào gần mình đang bán (có thể giá cao hơn 1 chút) nhưng lại đáp ứng được nhu cầu sử dụng gấp của anh. Đó là giá trị websosanh muốn đem lại.

Cách đánh giá trải nghiệm websosanh thì dựa trên các chỉ số định lượng về việc khách hàng có đáp ứng được nhu cầu mua sắm của mình (như ví dụ nói trên) hay không)

Q: Chào anh trước Tết em có tham gia sự kiện Demo Day của các bạn về việc reDesign UX của web 123phim.vn không biết thì hiện tại anh còn hỗ trợ các đội nhóm đó không anh nhỉ và anh có dự tính muốn mở rộng những mô hình như kiểu khóa huấn luyện UX Design vừa rồi không ạ.

A: Hiện tại mình vẫn đang dạy các khóa ngắn ngày. Bạn follow UX Design 101 để nắm các thông tin. Cảm ơn bạn

Q: Em chào anh Quang ạ. Đối với UX design nói chung và trong thương mại điện tử nói riêng, thì coder sẽ chịu trách nhiệm phát triển UX, cùng với sự hỗ trợ của, marketing, product và sale team. Thì anh có thể chia sẻ chi tiết hơn về những sự hỗ trợ của các team ấy sẽ diễn ra như thế nào vậy anh?

A: Chào Yukay,

Chúng ta sẽ đứng trên góc độ người sử dụng để trả lời câu hỏi này. Anh lấy ví dụ chúng ta vào Amazon.
1, Nếu em vào Amazon mà website không truy cập được thì em sẽ thấy thế nào? Có hài lòng hay không? Lỗi này là lỗi của ai?
2, Nếu em ấn vào nút “add to cart” mà giá trong cart lại khác với giá hiển thị thì em có hài lòng không? Có thấy amazon mập mờ không? Lần sau còn tin tưởng mua hàng tại amazon không?
3, Nếu em tìm sản phẩm em định mua là “iphone 7” nhưng toàn ra các kết quả “ốp lưng cho iphone 7” thì em có thấy bực mình không? Có tin tưởng vào chức năng search của Amazon không?
4, Nếu em vào Amazon mà amazon biết ngay thị hiếu mua sắm của em ra sao. Em tìm chung chung từ khóa “điện thoại” nhưng Amazon lại đưa ra các kết quả hoàn toàn trùng khớp với thị hiếu của em là điện thoại cho nữ, selfie lung linh (anh ví dụ vậy) thì em có dễ dàng lựa chọn hơn không?

4 ví dụ trên để em thấy vai trò của coder đối với UX, không chỉ xoay quanh việc đáp ứng chức năng hoạt động đúng mà còn giúp gia tăng hiệu quả bán hàng. UX là khái niệm trải rộng, mỗi người đều có thể tham gia nhằm phục vụ khách hàng tốt hơn

Một lần, Topdev rất cảm ơn anh Le Quang Phowr với lần xuất hiện thứ 2 trên AMA. Những chia sẻ nhiệt tình, thực tế của anh chắc chắn đã giải tỏa được rất nhiều khúc mắc về UX của các bạn. 

Xem thêm: Các công việc ux và việc làm it hấp dẫn tại Topdev.vn

Bức tranh toàn cảnh về thị trường lập trình Việt Nam 2016

Năm 2016 đang dần trôi qua và đây là thời khắc để cũng nhìn lại bức tranh toàn cảnh về ngành lập trình Việt Nam nói chung và nhân sự ngành nói riêng bắt nguồn từ sự thay đổi về công nghệ và những xu hướng mới trong hoạt động của doanh nghiệp.

Bạn có thể tải miễn phí ngay bản báo cáo tại đây

Về công nghệ, bên cạnh sự tăng trưởng bền vững trong số lượng các lập trình viên web, các ứng viên có kiến thức, kỹ năng liên quan đến lập trình mobile đang dần được ưa chuộng nhiều hơn. Ngay cả Big Data cũng sẽ chuyển qua các “sân khấu nhỏ” hơn để hỗ trợ cho làn sóng mới này. Bên cạnh đó, những kỹ năng về UX/UI, phân tích dữ liệu, công nghệ về AI (trí thông minh nhân tạo) đang có bước đà trong năm 2016, cũng được dự báo sẽ bùng nổ mạnh mẽ hơn trong thời gian tới. 

vietnam-developer-report-2016-05vietnam-developer-report-2016-07

Về mô hình doanh nghiệp, các công ty startup tiếp tục nở rộ về số lượng khiến nhu cầu tuyển dụng lập trình viên gia tăng. Một trong những đề tài được nhắc đến nhiều nhất là thiếu hụt nhân sự có tay nghề cao. Nhân sự cấp cao khan hiếm khiến nhiều doanh nghiệp có nhiều hoạt động tuyển dụng đa dang để thu hút nhân tài và đưa ra các chế độ lương thưởng phù hợp nhằm giữ chân nhân viên, đáp ứng các hướng đi dài của công ty. Nhìn chung, lập trình viên giờ không chỉ là những người “thợ” thuần gia công ứng dụng, mà họ còn phải được trang bị kiến thức cũng như những kỹ năng tổ chức quản lý đội ngũ. Theo các thống kê của Topdev, nhu cầu tuyển dụng các senior dev có kinh nghiệm làm việc trong startup đang tăng mạnh trong năm 2016.

vietnam-developer-report-2016-08vietnam-developer-report-2016-13

Cụ thể, các nhà tuyển dụng IT đã có hướng đi và góc nhìn mới cho công tác tuyển dụng như thiên về khuynh hướng Marketing và Branding hơn là các phương pháp truyền thống. Số liệu cho thấy hơn 55% các nhà tuyển dụng hàng đầu Việt Nam đều tin rằng các công ty cần chú trọng đến đánh bóng tên tuổi mình trước những ứng viên hơn. Cũng chính việc tạo thương hiệu tốt, các công ty sẽ có nhiều cơ hội thu thập nhiều hồ sơ và dữ liệu thuận tiện phát triển các dự án về sau, cũng như tạo được lợi thế cạnh tranh trong việc thu hút nhiều ứng viên tốt hơn trong giai đoạn cạnh tranh khốc liệt giữa các công ty công nghệ. Trung bình, các nhà tuyển dụng thường tốn khoảng 1 tháng để kiếm được 1 ứng viên thật sự tốt và phù hợp cho đội ngũ của mình. Theo đó, các nhà tuyển dụng sẽ kết hợp nhiều công cụ mạng xã hội, tận dụng mạng lưới quan hệ hơn là chỉ đơn thuần phụ thuộc vào trang tuyển dụng, để nguồn tuyển cũng phong phú hơn và không còn phụ thuộc vào các trang job listing thông thường nữa.

vietnam-developer-report-2016-12

TẢI ĐẦY ĐỦ REPORT THỊ TRƯỜNG LẬP TRÌNH VIÊNbutton_ta%cc%a3i-da%cc%82y

 

[Infographic] Lương của nhân sự ngành CNTT dao động từ 8 – 120 triệu đồng

Lương của nhân sự ngành CNTT dao động từ 8 – 120 triệu đồng, trong đó vị trí công việc có lương cao nhất là Giám đốc CNTT (CIO) – theo tài liệu tham khảo lương 2016 của Adecco Việt Nam.

KIỂM TRA MỨC LƯƠNG CỦA BẠN NGAY

0578b93ed07b04359790d04cc3b46933

Tài liệu tham khảo về mức lương năm 2016 đã được Adecco Việt Nam thực hiện và công bố hồi quý I trong năm. Cũng theo thông tin từ Adecco Việt Nam, tài liệu này được tổng hợp dựa trên các vị trí công việc toàn thời gian cố định được khách hàng yêu cầu Adecco Việt Nam tuyển dụng trong năm vừa qua cũng như từ chính các ứng viên đã làm việc với Adecco. Thông tin gồm mô tả công việc, mức lương cũng như số năm kinh nghiệm làm việc. Các tư vấn viên của Adecco cũng đã thực hiện phỏng vấn các ứng viên được lựa chọn cho từng vị trí để xác minh mức lương đối với yêu cầu công việc.

Screen Shot 2016-08-24 at 4.19.30 PM

Tính lương chuẩn với công cụ tính lương gross – net tại TopDev

Đại diện Adecco khu vực Thái Lan và Việt Nam đã nhận định: “Thiếu hụt nhân sự có tay nghề cao đã trở thành một trong những đề tài được nhắc đến nhiều nhất trong năm 2015. Nhân sự cấp cao khan hiếm khiến nhiều doanh nghiệp cố gắng thu hút và giữ chân nhân viên tài năng hiện tại. Chế độ lương thưởng đóng một vai trò quan trọng trong việc giữ chân nhân sự, đặc biệt với sự hình thành của Cộng đồng Kinh tế ASEAN – nơi sự chuyển dịch nhân sự trong khu vực vừa là cơ hội vừa là thách thức cho các doanh nghiệp. Làm thế nào để công ty có thể tìm thấy tài năng thật sự và giữ họ ở lại mà không bị cuốn vào vòng xoáy lương – lạm phát là vấn đề cấp bách nhà lãnh đạo cần phải xem xét trong năm nay”.

Theo thông tin của nhiều đại lý cung cấp các gói bảo hiểm nhân thọ của nước ngoài như AIA, Acelife, Liberty … năm 2016 các doanh nghiệp đã đẩy mạnh việc sử dụng các gói bảo hiểm cao cấp của họ cho việc “giữ chân nhân tài”.

Xem việc làm IT tại TopDev

Nguồn: Techtalk via Funix 

Làm thế nào để IT và HR hiểu nhau hơn?

Sự chuyển đổi công nghệ số đã loại bỏ được rất nhiều công việc khó khăn hằng ngày liên quan đến nhân sự. Perry Oostdam, đồng sáng lập và CEO của Recruitee chia sẻ rằng nhân sự (HR) đã từng là bộ phận thụ động bởi những thủ tục giấy tờ, nhưng công nghệ tự động hoá các hoạt động về biên chế, lương bổng và quyền lợi của nhân viên đã giảm bớt những công việc nhàm chán, giải phóng các chuyên gia HR, giúp họ tập trung nhiều hơn vào chiến lược sáng tạo và kỹ năng phân tích.

“Công nghệ giúp tăng năng suất, nâng cao hiệu quả là một điều không thể phủ nhận”. Điều quan trọng hơn nữa là công nghệ đã giúp HR thêm động lực để đổi mới. Thay vì dùng cả ngày chỉ để duy trì bits and mảng số liệu trên giấy tờ, bây giờ HR có thể có thời gian và công cụ để tối ưu hoá và tái tạo lại quá trình này,”- ông ấy nói.

Tuy nhiên, khi công nghệ được áp dụng ngày càng rộng rãi, các chuyên gia HR sẽ cần đánh giá mối quan hệ của họ với bộ phận IT. Oostdam chia sẻ rằng đối với mỗi công ty, có một sự đối đầu cơ bản truyền thống giữa hai bộ phận này, nhưng mà điều quan trọng là công nghệ chuyển đổi ngày càng nhanh chóng sẽ làm thay đổi thái độ lạc hậu này.

CẦN SỰ HỢP TÁC ĐỂ TÌM RA ĐƯỢC PHẦM MỀM HỖ TRỢ CHO HR TỐT NHẤT

Có rất nhiều platforms HR áp đảo trên thị trường để hỗ trợ HR, tuy nhiên phòng IT có thể giúp phòng HR bằng cách sắp xếp và xác định rõ những công cụ có sẵn nào là hiệu quả nhất. Họ sẽ đảm bảo phần mềm triển khai suôn sẻ, tổ chức đào tạo tất cả nhân viên làm sao tận dụng tốt nhất các phần mềm nhân sự mới nhất.

“Hơn thế nữa, chúng ta có thể thấy rằng HR đóng vai trò lớn trong việc tổ chức hiệu quả các hoạt động, vì vậy họ cần có công nghệ phù hợp để thực hiện điều đó,”  Kris Duggan, Giám đốc điều hành của BetterWorks chia sẻ.

Để bắt kịp sự phát triển không ngừng của công nghệ, IT phải thay đổi bản thân theo xu hướng. Duggan cho rằng nhân sự và IT cũng giống như việc tập trung vào “Xu hướng nào đang xảy ra giữa người và công nghệ.” Và vì con người đang dần tiếp thu nhiều hơn trong thời đại công nghệ không ngừng thay đổi, họ cũng ngày càng mong đợi nhiều hơn sự tiện dụng mà công nghệ sẽ hỗ trợ họ trong công việc.

Cách phối hợp này đã bắt đầu từ những ngày đầu. Nếu các CIO và giám đốc nhân sự (CHRO) ây dựngmối quan hệ liên kết lẫn nhau bền chặt, luôn giao tiếp cởi mở, hiện tượng giao tiếp này sẽ xảy ra tương tự khắp các bộ phận khác – theo Gordon Laverock, Hoa Kỳ đối tác quản lý về Presence of IT – một công ty tư vấn toàn cầu thuộc ngành nhân sự.

Mối quan hệ bền chặt giữa CIO và CHRO không chỉ khuyến khích nhân viên phòng ban IT và HR cộng tác với nhau, mà còn giúp phát triển các phương pháp hay công nghệ cho toàn bộ tổ chức. Mỗi bộ phận, từ Marketing đến Tài Chính, đều dựa vào các phần mềm hay phần cứng mới và cải tiến – nhưng không phải bộ phận nào cũng hiểu được ý nghĩa của việc áp dụng công nghệ mới. Bởi vì IT và HR là hai bộ phận phải làm việc với nhiều dữ liệu nhạy cảm, các giám đốc nên hướng dẫn, đưa ra đường lối chỉ đạo để giúp họ thực hiện công việc một cách tốt nhất thông qua khả năng nhận sự thay đổi của chiến lược kỹ thuật số mới.

“Hình thành một cơ cấu quản trị không chỉ dựa vào sự đánh giá của công nghệ và quá trình thực hiện mà còn thiết lập quy trình quản trị liên tục trên mọi phòng ban của tổ chức – điều này sẽ tạo ra cơ hội mạnh mẽ để tiến tới thành công” – Laverock nói.

HR CẦN BIẾT CÁCH HOẠT ĐỘNG CỦA BẢO MẬT IT

Có rất nhiều công cụ giúp các chuyên gia HR trong quá trình làm việc, và chẳng có gì sai khi áp dụng các công cụ đó vào nơi làm việc, tuy nhiên nhân sự cũng giải quyết số lượng lớn dữ liệu một cách rất bí mật. Điều cuối cùng mà tổ chức mong muốn làm là thông tin về sức khoẻ , tiền lương hoặc những dữ liệu cá nhân khác của nhân viên không rơi vào tay người xấu khi được đưa lên các đám mây trực tuyến hoặc một máy chủ nào đó. Ngược lại, hệ quả sẽ gây ra rắc rối pháp lý nếu dữ liệu nhân sự bị khai thác hoặc bị mất – và đó là một trong những vấn đề lớn nhất mà IT có thể giúp đỡ – Oostdam chia sẻ.

Nếu bộ phận IT và nhân sự chỉ hợp tác trên một khía cạnh nào đó, việc hợp tác này nên được bảo mật. Làm việc chặt chẽ với IT là cách duy nhất để có thể đảm bảo mọi người đều được bảo vệ; đặc biệt kể từ khi HR đồng ý giao dịch các thông tin nhạy cảm hơn so với IT, biến yêu cầu bảo mật trở thành ưu tiên số 1.

TRẢI NGHIỆM BUY-IN VÀ NGƯỜI DÙNG

Nhân viên mong đợi khả năng sử dụng với các ứng dụng của doanh nghiệp, và phần mềm hỗ trợ cho HR cũng không ngoại lệ. Theo Duggan, IT không lạ lẫm gì khi lựa chọn phần mềm hay phần cứng sao cho phù hợp với trải nghiệm người dùng, bởi vì họ có nhiều kinh nghiệm có thể  hướng dẫn HR đâu là hướng đi đúng, từ đó đưa ra được lựa chọn thân thiện nhất với người dùng. Lựa chọn phần mền HR đúng đắn sẽ cải thiện độ hài lòng của nhân viên, đối tác, năng suất và hiệu quả công việc, kết quả sẽ ảnh hưởng đến doanh thu, hạn chế lãng phí thời gian và sự thất vọng của khách hàng.

Căn chỉnh hệ thống IT và HR để gặt hái doanh thu

IT và HR đều là hai bộ phận cơ bản trong mỗi doanh nghiệp và có rất nhiều công việc của họ ảnh hưởng trực tiếp đến nền tảng hoạt động của công ty. Nếu HR có thể đánh giá mức độ engage và hạnh phúc của nhân viên, họ sẽ đảm bảo lực lượng lao động luôn giữ vững động lực và giúp mang doanh thu trở lại. Đối với IT, nếu họ lựa chọn đúng công cụ thích hợp với nhân viên, công việc sẽ đạt hiệu suất cao hơn và hiệu quả tốt hơn.

“Các mối quan hệ hiện đại giữa HR và IT nên tập trung vào trải nghiệm của nhân viên mà cả 2 bộ phận muốn cung cấp. Thay vì triển khai 1 chương trình nhân sự cứng nhắc, hãy biến chương trình ấy trở nên thật “hào nhoáng”. Đội ngũ nhân viên đang tương tác với rất nhiều công cụ và công nghệ trong cuộc sống hằng ngày, do vậy HR và IT phải tích hợp được 1 chương trình nhân sự HR vào công nghệ stack hiện tại của tổ chức” – Duggan đề cập.

Một nhân viên vui vẻ và năng suất sẽ mang đến lợi nhuận tốt hơn và tính thống nhất cho toàn bộ tổ chức hơn.  Theo Laverock: “Bằng cách kết hợp 50.000 cách nhìn nhận về thiết kế, triển khai và duy trì một giải pháp tầm cỡ doanh nghiệp cộng với sự hiểu biết nhân lực của đội ngũ HR, HR & IT có thể khai thác sự hợp tác hiệu quả hơn và đem lại nhiều giá trị hơn cho doanh nghiệp.” – 

Nguồn: Techtalk via cio.com

 

Tại sao 1 người sếp tốt thường là 1 người bạn tệ?

Tôi lên vị trí quản lý lần đầu khi còn rất trẻ. Từ sale trở thành leader của 1 nhóm sale, trong đó rất nhiều người gấp đôi tuổi tôi. Bây giờ nhìn lại, thực sự thì tôi cũng không giỏi đến mức như vậy.

Tuy nhiên, trải nghiệm đó đã dạy tôi rất nhiều bài học quý giá – 1 trong số đó chính là rất khó để cân bằng giữa những mối quan hệ cá nhân và mối quan hệ công việc với những người bạn lead. Đây không chỉ là vấn đề mà các nhà quản lý mới làm lần đầu gặp phải, mà còn là câu chuyện ngay rất nhiều nhà quản lý kinh nghiệm cũng đang đặt nghi vấn và rất nhiều người thậm chí còn không cho đó là vấn đề.

Thân thiện với những người trong team của bạn đóng vai trò thực sự rất quan trọng. Trên thực tế, khi thuê nhân viên mới, 1 trong điểm ưu tiên hàng đầu của tôi là liệu tôi có muốn đi uống 1 cố bia với người đó và tìm hiểu họ nhiều hơn không? Tôi sử dụng cách suy nghĩ này như 1 linh cảm để đánh giá sự phù hợp của 1 ai đó với văn hóa của công ty.

Như đã nói, tuy việc tạo khoảng cách giữa người chủ và bạn bè có thể khá khó khăn nhưng điều đó là cần thiết. Đối xử với nhân viên như bạn thân thỉnh thoảng lại có ảnh hưởng tiêu cực đến 1 số đặc tính trong leadership, bất kể bạn là manager mới hay bạn đã quen với công việc này. Dưới đây là 1 số ví dụ về những chức năng đó, cách áp dụng chúng và 1 số lời khuyên để điều chỉnh chúng và đảm bảo sự “mạnh khỏe” của doanh nghiệp lẫn sự hài lòng của nhân viên.

1. Duy trì tính khách quan và nhất quán

Trở thành 1 leader tốt nhất định phải khách quan. Các hoạt động đánh giá chất lượng, phân tích tài năng, đánh giá điểm mạnh và điểm yếu là những nghĩa vụ đặc biệt quan trọng của 1 leader. Những nghĩa vụ này cũng đòi hỏi tinh thần khách quan gần như cao tuyệt đối. Mặc khác, tình bạn lại không mang đến điều đó.

Thật không may là các nhà quản lý thường đưa ra quyết định dựa trên mức độ họ quen thân với 1 nhân viên nào đó dù chính bản thân họ cũng không nhận ra. Sau tất cả, đây cũng là cách kết nối dễ nhất với những người mà bạn thích nhất. Nên nhớ, dù tính cách và quan điểm của nhân viên đó có tương thích với bạn hay không, thì họ thường chứng tỏ được giá trị với tổ chức 1 cách chính xác nhất dựa trên những điểm khác biệt. Một nhân viên không giống bạn sẽ mang đến những quan điểm và kĩ năng đặc biệt đến độ mà team của bạn không thể thiếu. Việc hướng về những nhân viện mà chúng ta quen thuộc nhiều nhất có thể khiến chúng ta không thấy rõ những đóng góp của các cá nhân khác.

Tuy không muốn thừa nhận nhưng những mối quan hệ thân thiết với nhân viên sẽ tạo nên sự thiên vị khó mà thay đổi được. Ví dụ rõ ràng nhất là khi bạn phải đưa ra quyết định mang tính quản trị như tăng lương, sa thải hoặc thăng chức. Tuy rất khó khăn khi phải để bất kì nhân viên nào ra đi thì bạn sẽ cảm thấy khó khăn gấp bội sau khi đã xây dựng 1 mối quan hệ cá nhân thân thiết. Dù chỉ là ngẫu nhiên thì bạn cũng dễ tha thứ cho những lỗi lầm của họ hơn so với nhân viên khác. Hãy cảnh giác, xem thử mối quan hệ giữa sếp – nhân viên đang ở vị trí nào trước khi đưa ra bất kì quyết định cuối cùng nào.

Nói cách khác, sự khích lệ tích cực và hỗ trợ thân thiện là những nghĩa vụ cần thiết.

Cũng giống như bất kì sản phẩm nào khác, content sáng tạo, chất lượng cần phải được truyền tải kịp thời và trong kinh phí cho phép. Nhưng để sản xuất được content chất lượng, sáng tạo đòi hỏi sự liều lĩnh, dám mạo hiểm, sự trải nghiệm và khám phá – những concepts rõ ràng, không thể thay đổi. Ưu tiên của tôi là luôn truyền đạt tinh thần hứng khởi đến các khách hàng của mình và thỉnh thoảng, điều đó đồng nghĩa với việc đang động viên nhân viên của mình làm việc chăm chỉ hơn hoặc nhanh hơn so với khi họ tự thúc đẩy bản thân.

Là 1 leader, trách nhiệm của tôi là tạo nên 1 môi trường làm việc nuôi dưỡng tinh thần sáng tạo và quyền tự do sáng tạo. Khi đi dạo quanh văn phòng, tôi cố gắng dành thời gian trao đổi nhanh với những người mình khi đi trên đường. Thỉnh thoảng, tôi trao đổi về công việc nhưng đa số là không.

Có thể nói, nếu việc hình thành khoảng cách quan trọng thì việc thân thiện, cơi mở, tạo sự kết nối với nhân viên cũng quan trọng không kém.

2. Những mong đợi bị xóa nhòa

“Chúng ta sẽ trở thành những gì mà chúng ta mong muốn trở thành, vì vậy hãy cẩn thận với những gì mà chúng ta mong muốn” – Kurt Vonnegut

Tôi không nghĩ Vonnegut đang ám chỉ đến việc quản lý nhân viên, nhưng nhìn chung vẫn có 1 mức độ tương thích nhất định. Tất cả chúng ta đều mong đợi điều gì đó ở bạn bè của mình cũng tương tự như cách chúng ta mong đợi ở những người sếp của mình.

Tuy nhiên, tôi có thể cá rằng không có nhiều điểm tương đồng như bạn nghĩ vậy đâu.

Điểm khác biệt chính là: Không giống như 1 người bạn, 1 người sếp là người dẫn dắt những nhân viên bằng cách cung cấp chỉ dẫn và góp ý thích hợp để giúp nhân viên phát triển. Sếp sẽ giúp bạn tối thiểu rủi ro và mang đến kết quả nào đó. Một người bạn có khuynh hướng tỏ ra thương xót khi điều gì đó xảy ra sai, thì 1 người sếp sẽ nhận diện lỗi lầm đó và thẳng thắn phân tích làm sao để chuyện đó không xảy ra lần nữa. Đây chính là 1 trong những điều quan trọng nhất mà tôi làm (dù nhân viên có nhận ra hay không)

Khi bạn mong đợi sự ưu tú, xuất sắc, tinh thần trách nhiệm từ tất cả các nhân viên, bạn sẽ công bằng và trung thực hơn, bạn cũng sẽ duy trì được tiêu chuẩn cao và theo đuổi được những mục tiêu giá trị. Khi các nhân viên biết rằng họ là thành phần quan trọng đối với team & team sẽ thất bại nếu họ không cam kết hết mình, sự gắn kết và chất lượng công việc sẽ tăng lên; họ có thể chắc chắn rằng các đồng nghiệp cũng đang ở tiêu chuẩn tương tự mà không hề có ngoại lệ nào.

Một lần nữa, điều này không đồng nghĩa là bạn phải tách biệt bản thân với tinh thần đồng đội của team. Chẳng có gì sai khi lâu lâu dành 1-2 giờ trao đổi với thoải mái với team. Nhưng nếu bạn mỗi tối thứ 3 hằng tuần để chơi game với họ, khoảng cách giữa sếp và nhân viên sẽ mờ dần đi và bạn đang lấy mất của nhân viên mình 1 trong những đặc tính giá trị nhất mà 1 người sếp có thể mang lại – khả năng giúp nhân viên phát triển bằng những góp ý khách quan.

3. Khu vực thư giãn

Cho dù bạn là 1 người lý tưởng như thế nào thì cũng không thể làm việc tốt 100% thời gian. Chúng ta đều cần 1 “lối thoát” để xử lý những căng thẳng trong công việc thường ngày khi rời khỏi văn phòng. Dù rủi ro nhưng chúng ta thường sẽ trút nỗi buồn và căng thẳng lên mạng xã hội – đây là không gian riêng tư và quyền lợi cần phải tôn trọng. 

Đó là lý do tôi khuyên bạn không nên kết bạn và theo dõi nhân viên trên mạng xã hội. Ban đầu có thể chẳng có gì, nhưng về sau sẽ xảy ra 1 trong 2 hướng: hoặc là họ sẽ kiềm chế chia sẻ quan điểm thực sự vì cảm thấy bạn đang theo dõi từng động thái của họ, hoặc quên luôn việc bạn đang theo dõi họ. Hướng thứ 2 sẽ dẫn đến những tình huống khó xử khi bạn nhìn thấy 1 bài viết trung thực về công ty, về khối lượng công việc và thỉnh thoảng về chính bạn. Trong cả hai trường hợp, bạn đã tạo ra 1 lực cản không thoải mái.

Vì lợi ích của bản thân và của team, hãy xem xét các hoạt động mạng xã hội cá nhân như một phần liên quan đến tài sản cá nhân; nó không liên quan đến bạn và không để lại lợi ích gì cho bạn khi áp đặt bản thân vào cuộc sống của nhân viên sau giờ làm việc. Nếu có một vấn đề gì về nhân viên thực sự cần phải quan tâm, họ sẽ tìm kiếm lời khuyên bằng cách thảo luận trực tiếp nghiêm túc với gia đình và bạn bè trước khi cố gắng giải quyết nó tại nơi làm việc.

Khi đặt mình vào vị trí của họ, bạn sẽ hiểu được lý do tại sao phải duy trì tính riêng tư này. Nếu tôi chấp nhận lời mời kết bạn của 1 nhân viên nào đó, họ sẽ có khả năng nhìn thấy tất cả suy nghĩ và ý kiến của tôi cho dù họ có liên quan trực tiếp đến công việc đó hay không. Cá nhân tôi không muốn nhân viên tạo ra các giả định về mình hay đem tôi ra như một tối tượng để bàn tán trong công việc, măc dù tôi không cố ý định tạo ra điều ấy và họ cũng không có ý định làm vậy. Bạn có thể hỏi thăm nhân viên làm gì vào ngày cuối tuần hay họ nghĩ gì về trận đấu bóng đá hôm qua, nhưng mạng xã hội không cho phép bạn kiểm soát những gì riêng tư của người khác. Duy trì được như vậy là chìa khoá để duy trì mối quan hệ tốt đẹp trong công việc.

Nguồn: topdev via wheniwork

50 Web & Mobile UI Kits miễn phí hot nhất đầu năm 2024 (phần 1)

Graphic là yếu tố đầu tiên nhất mà users nhìn thấy trên 1 trang web. Một giao diện người dùng tốt, chất lượng sẽ giúp users tương tác với website của bạn liên tục, liền mạch. Bên cạnh đó, giữa 2 websites hoặc ứng dụng, users sẽ chọn website hoặc ứng dụng nào có vẻ hấp dẫn về mặt thẩm mỹ và thân thiện với người dùng hơn. 

Dưới đây là tổng hợp 1 số các web và mobile UI kits hot nhất, mới nhất và hoàn toàn miễn phí đầu năm 2024. Những UI kits này hỗ trợ làm thủ công các thiết kế websites & app sáng tạo, đẹp và hữu ích. Bạn có thể điều chỉnh các thiết kế này để đáp ứng theo nhu cầu riêng, chỉnh sửa các element như button, login form, các icons của social media…

Tìm việc làm web và việc làm mobile

1. Chat

Format: Sketch, PSD [Download]

chat

2. Blog UI Kit

Format: Sketch [Download]

3. Prometheus

Format: PSD [Download]

Prometheus

4. 11thagency

Format: PSD [Download]

5. Creastore UI kit

Format: Sketch [Download]

Creastore UI kit

6. Inspirational UI Elements

Format: PSD [Download]

7. Take UI Kit

Format: PSD [Download]

Take UI Kit

8. Surfing Theme

Format: PSD [Download]

9. Kauf UI Web Kit

Format: PSD [Download]

Kauf UI Web Kit

10. Monet

Format: PSD [Download]

11. Move

Format: Sketch [Download]

12. V Avenue

Format: PSD, Sketch [Download]

13. Relate UI Kit

Format: Sketch, PSD [Download]

14. Smart Home UI Kit

Format: Sketch [Download]

15. Taxi App UI

Format: Sketch [Download]

16. Avital Mobile UI Kit

Format: PSD, Sketch [Download]

17. Beautiful Free Kit iOS

Format: PSD, Sketch [Download]

18. Material Fitness Dashboard UI

Format: Sketch [Download]

19. Trend

Format: PSD [Download]

20. Free PSD

Format: PSD [Download]

21. UI Kit

Format: PSD [Download]

22. Inspirational UI Elements

Format: PSD [Download]

23. Social Leads

Format: Sketch [Download]

24. Hooked

Format: Adobe XD [Download]

Nguồn: Topdev via Hongkiat

Nữ sinh đội tuyển Word đi theo CNTT chia sẻ bí kíp phát triển sự nghiệp

Confession là một hình thức fanpage không mới, nhưng với sự xuất hiện đầu tiên trong giới lập trình, page Lập Trình Viên Confessions mỗi tuần đều tạo cơ hội cho các bạn coder thể hiện sự “bẩn bựa” của mình, đem đến cho cộng đồng không ít lần phải “té ghế”.

Hẳn là đội tuyển Word

“Em là nữ ạ.Em sinh năm 99.Khối B là khối mạnh của em,bố mẹ định hướng cho em thi Y Đa Khoa.Nhưng thấy mấy anh chị học y bảo cực khổ vô cùng,ko nên thi vô đó.Em cũng không thích y cho lắm!Em search g.g tìm hiểu đôi chút về công nghệ thông tin,mà em thấy công nghệ thông tin khá dễ.Em cũng đã từng học về Word năm lớp 9,đội tuyển.Các anh chị bảo em rằng,con gái nên học công nghệ thông tin vì nó khá là nhàn.Em thì ko học Kinh Tế được và Ngoại Ngữ chắc không thi nổi.Anh chị em khuyên nên học ngành này,em cũng chưa quyết định.Vì em thấy anh họ em bảo em học được y đa khoa thì cái gì cũng học tốt”
Trích lời của cô em hàng xóm hỏi tôi.Ae cho tôi lời khuyên cho cô bé này.

Những chia sẻ về kinh nghiệm gầy dựng sự nghiệp

Chia sẽ kinh nghiệm cho các bạn đi theo nghề code dạo mới ra trường. Người chia sẻ không tài giỏi gì chỉ xoay sở được mức lương 2000$ trong 6 năm làm việc. Ai giỏi quá không cần phải chê đâu, tui tự biết.

Năm đầu :

+ Trường hợp thứ nhất : bạn không phải thiên tài bạn không có gia sản to đùng của ai đó để lại, không ai rủ bạn startup, bạn có tài năng bình thường như tôi . Hãy kiếm công ty nào cần người bất gấp bất kể chế độ lương bổng. Nổi tiếng bóc lột cũng không sao. Hãy lăn lê bò lết làm mọi thứ học mọi thứ. Tiền chỉ để ăn và học thêm ngoại ngữ. Hãy cố gắng code chạy được đừng nhọc nhằn lo vở sạch chữ đẹp, bạn có khả năng bị đuổi rất cao nếu không kịp deadline vì mải mê code đẹp.

+ Trường hợp thứ hai : bạn rất tự tin về tài năng của mình, bạn có vốn hay đủ uy tín để huy động vốn. Hãy làm startup đừng sợ thất bại. Hãy làm từ ý tưởng nhỏ trước. Startup nên với hai hoặc ba người là tối đa. Team rất dễ tan vỡ nếu nhiều hơn ba người. Lịch sử đã chứng minh chuyện đó rất nhiều rồi không cần phải đi theo vết xe đổ.

Năm hai: Từ năm này trở đi tôi chỉ nói về trường hợp một

+ Bạn đã có một số vốn kiến thức, bạn đủ tự tin có thể làm được sản phẩm kịp deadline. Okay giờ là vấn đề lương bổng. Lương bạn sao khi tang dưới 8 chai bạn nhảy. Lương bạn hơn 8 chai nhưng so với năm trước dưới 15% bạn nhảy. Bạn hỏi tại sao? Bởi vì đơn giản là bạn đang bị phạt chứ không phải thưởng. Công ty đang cố gang bóc lột bạn hơn thôi. Tiền lương của bạn không theo kịp tỉ lệ trượt giá. Trung Bình mỗi năm tiền ăn và tiền nhà của bạn trung bình tang 20% nếu lương bạn thấp hơn thì bạn hiểu rồi đó. Bạn càng ngày càng nghèo.
+ Bạn quyết định nhảy hay lựa chọn những công ty trả bạn cao hơn 30% so với múc lương hiện tại của bạn.

+ Từ đây bạn hay chú tâm vào luyện skill optimize.

Năm ba :

Nay bạn đã có thể code rất nhanh và dự án chạy với performance cực tốt. Lại nói về chuyện lương bổng. Cũng như năm trước nếu lương tăng dưới 20% bạn nhảy. Lương bé hơn 10 chai bạn nhảy luôn.

+ Từ năm này hay luyện kiến trúc code. Giờ bạn phải hiểu rang bạn sắp lên sub-leader hoặc leader hoặc chí ít bạn cũng phải quản lý chỉ dẫn cho những người mới vào. Thì một dự án không những cần nhanh performance tốt mà còn cần làm sao để cả team hoạt động hiệu quả. Kể cả giao cho team bạn người code chuối nhất nếu theo kiến trúc của bạn đặt ra thì dự án cũng thành công đó là mục tiêu.
Năm tư :
Nay bạn đã phải là một senior hoặc leader không phải thì hãy tự nhìn lại bản thân. Nếu theo đường quản lý thì hãy học thêm những khóa ngắn hạn về kỹ năng giao tiếp, lập kế hoạch. Nếu theo đường nghiên cứu thì hãy học thêm một lĩnh vực khác có liên quan. Chẳng hạn front-end thì học thêm back-end. Đừng quên ngoại ngữ.
Lại nói về lương nếu năm nay lương bạn dưới 16 triệu bạn nhảy.
Năm thứ năm trở đi bạn hãy làm việc ổn định đừng bay nhảy nữa. Lúc này trở đi bạn kiếm thêm tiền bằng các dự án ngoài, như hùn vốn mở tiệm…
Hãy học thêm thứ gì đó như kinh tế chẳng hạn.

Tham gia chia sẻ ngay tại Lập Trình Viên Confession

Để làm lập trình viên sau 1 năm, nên học gì?

Thực sự thì mình chỉ mới đi làm được gần 1 năm, skill cũng chưa có nhiều nên cũng không thể chém gió sâu vào kỹ thuật được. Lúc trước mình theo mảng front-end nhưng ngày càng nhận ra không có hứng thú nên dần dà chuyển sang back-end từ lúc nào không hay, và mình chỉ có một số lời khuyên dành cho lập trình website chứ bên ứng dụng thì mình không biết.

Kỹ năng cần học thì quá nhiều, mỗi công ty có mỗi yêu cầu và thay đổi theo thời gian. Kỹ thuật phát triển không ngừng nên một khi đã theo ngành này thì xác định là phải học cả đời.

Tới đây nhiều người sẽ có thể chém em rằng ôi chú em mới đi làm được một năm thì biết gì về kỹ thuật mà nói! Ahihi, cười trừ. Thực ra thì trình độ không chỉ cân đo đong đếm bằng số năm kinh nghiệm, chủ yếu là số vấn đề mình đã gặp qua và cách giải quyết nó, số dự án đã hoàn thành, bác tự học bao nhiêu giờ một ngày, từ đó rút ra kỹ năng của bác có cứng không. Chứ còn nói “Tôi có 5-6 năm experience nhưng trong 5-6 năm đó toàn làm xoàng xoàng, dự án thì xong nhưng kiểu đúng deadline không hơn không kém, và chiều chiều canh hết giờ làm rồi về”…. chấm hết, không thể đánh giá chính xác với trường hợp như vậy.

Thôi vô vấn đề chính, vậy để làm lập trình thì cần những gì, lộ trình thế nào….. Cái đó phụ thuộc vào hướng bạn đi.

screen-shot-2016-11-03-at-8-59-18-am

Hướng front-end developer

Hướng này có rất nhiều kỹ thuật, nhưng mình nghĩ các bạn nên học những kỹ thuật chắc chắn cần trước. Còn lại phụ thuộc vào công ty các bạn làm có yêu cầu học thêm không. Danh sách thì dài đằng đẳng như thế này đây: https://github.com/dypsilon/frontend-dev-bookmarks

Nhưng các skill sau đây nhất định phải có khi đi làm, ít nhất là để làm được việc:

  • HTML (HTML5 càng tốt)
  • CSS (CSS3 càng tốt)
  • Javascript cơ bản (jQuery). Nói trước là Javascript chuyên sâu rất hay và rất khó gặm.
  • Photoshop cơ bản
  • Illustrator cơ bản
  • Một số front-end framework như Twitter Bootstrap, AngularJS mới nổi….

Tham khảo các vị trí tuyển dụng front end lương cao tại Topdev

Hướng back-end developer

Hướng này thì kinh tởm hơn, theo mình nếu đã chọn con đường chông gai này thì chỉ nên chọn 1-2 ngôn ngữ lập trình mà theo (học sâu). Mình thà làm vua một nước chứ nước nào cũng thích thì dễ tẩu hỏa khi luyện công lắm. Các kỹ năng cần chủ yếu là nền tảng và phụ thuộc vào tư duy logic của bạn:

  • Các nền tảng cơ bản về ngôn ngữ bạn định làm, mấy kiến thức đơn giản này phải khắc cốt ghi tâm chứ đôi khi cũng có người quên và phải đọc lại từ Google. Vòng lặp, cách khai báo biến, hàm, hướng đối tượng….. Đặc biệt phỏng vấn bao giờ cũng có hướng đối tượng.
  • Kiến thức về database MySQL, Microsoft SQL.
  • Rộng hơn là Design Pattern (Singleton, Factory, Strategy, MVC, HMVC….).
  • Các framework hot tính tại thời điểm viết bài này, đơn giản nhất và dễ nhất là CodeIgniter.

Bạn nên học một framework sau đó đi làm và học tiếp theo để dễ thấm và có cơ hội làm nhiều hơn. Theo lời khuyên của mấy đàn anh đi trước thì 1 developer cần biết 2 framework và 1 CMS nếu muốn đi đánh dự án với các công ty outsource.

Tham khảo các vị trí tuyển dụng backend lương cao tại Topdev

Hướng full stack

Là full-stack developer có nghĩa là bạn phải cởi mở đối với các công nghệ mới, có hiểu biết sâu về một vài công nghệ và phải có sự hiểu biết về cách một ứng dụng web được thực hiện từ một khái niệm thiết kế cho đến khi các sản phẩm đã hoàn thành.

screen-shot-2016-11-03-at-9-00-03-am

Full-stack developer không có nghĩa là phải thông thạo mọi công nghệ mà chỉ cần có hiểu biết về các ngôn ngữ đang có, có thể giao tiếp một cách thông minh giữa các thành viên trong nhóm và là một nguồn lực tốt, sẵn sàng nếu dự án cần đến bạn.

Full-stack trên thế giới hiện nay có thể cần những kỹ năng sau (tham khảo):

  • Không giới hạn mình ở bất kỳ 1 language hay 1 framework hay 1 chuyên môn cụ thể nào.
  • Có kiến thức IT tổng quát và khả năng tìm hiểu sâu khi cần thiết bất kỳ vấn đề gì thuộc: (1) Server – Network (2) Database (3) Web frameworks (4) Mobile frameworks
  • Hiểu và ứng dụng được UI/UX vào trong projects
  • Nắm bắt nhanh Business Logics và chuyển được thành Technical Logics
  • Biết được khi nào cần hiểu rộng, khi nào cần hiểu sâu một vấn đề
  • Có thể lập trình được ít nhất 1 ngôn ngữ lập trình web và 1 ngôn ngữ lập trình mobile (iOS/Android)

Tham khảo các vị trí tuyển dụng full stack lương cao tại Topdev

Hiện nay khá nhiều người theo hướng này, một phần do cái danh full-stack khá là hay ho (cảm giác như super hero), một phần là hiện nay các nhà tuyển dụng cũng yêu cầu khá cao về skills của developer. Các công nghệ chết tiệt trong thế giới lập trình lỗi thời đủ nhanh để cuốn trôi bất kỳ 1 “nền tảng” vững chãi nào. Do đó nếu bạn chỉ biết 1 ngôn ngữ, biết 1 nền tảng nào đó, hiện tại bạn vẫn có thể kiềm tiền ngon ăn với nó, nhưng liệu 2 – 4 năm nữa thì không chắc chắn.

Do đó bạn có thể là 1 “super-code dạo” hiện tại, nhưng chưa chắc điều đó sẽ đảm bảo cho bạn một tương lai chắc chắn cho những năm tới đâu.

Đối với ai đi theo hướng này, nếu được nên học front-end trước rồi từ từ mò qua back-end bởi vì trong 1 năm bạn không thể nào trở thành full-stack đâu – cũng có nhiều người tự phong, ahihi. Và tất nhiên mình cũng khuyến khích (nếu được) các bạn nên đi theo hướng này (về lâu về dài) để đáp ứng nhu cầu công việc trong tương lai.

Tất cả những gì cần thiết mình đã nêu ở trên, nếu các bạn biết về chúng thì có thể đi code dạo và kiếm cơm được rồi. Sau này đi làm cố gắng trau dồi nhiều thật nhiều kỹ năng để tăng giá trị bản thân lên (tăng lương).

Techtalk via justfunny

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

Giải đáp những thắc mắc kĩ thuật quan trọng về Microservices

AMA (Ask Me Anything) là 1 sự kiện Q&A (Hỏi đáp trực tiếp) diễn ra đều đặn trên fanpage của TopDev vào thứ 6 hằng tuần. AMA đón nhận sự xuất hiện của anh Nguyễn Minh Khôi CTO – DKT Technology giúp các bạn trẻ đam mê IT giải đáp những thắc mắc liên quan đến Microservices & xây dựng kiến thức hệ thống.

Trước tiên, chúng ta hãy tìm hiểu 1 chút về quá trình công tác của anh Khôi nhé!

  • 8/2007 – 9/2009: anh là developer của FPT
  • 5/2009 đến nay: anh đồng hành cùng DTK trong vai trò CTO
  • Anh đã từng góp mặt tại các sự kiện công nghệ hàng đầu tại Việt Nam với vai trò Speaker, điển hình như sự kiện Vietnam Web Summit vừa qua.

Q: Chào anh, Anh có thể chia sẻ về việc sử dụng esb trong esb và các cách liên lạc giữa các service cũng như API Gateway được không a.

A: ESB là khái niệm trong SOA, microservice không dùng cái đó. Bản thân các service khi gọi nhau phải hiểu được giao thức & format dữ liệu của nhau. Đơn giản nhất là các microservice gọi nhau qua Rest API sử dụng Json.

Còn API Gateway đóng vai trò như 1 cửa ngõ chung để các ứng dụng bên ngoài gọi vào các microservice bên trong. Các microservice gọi trực tiếp nhau không thông qua API Gateway. Vấn đề là làm thế nào để các microservice (và cả API Gateway) biết được thông tin của microservice khác để gọi. Khi đó trong hệ thống cần có 1 thành phần gọi là Service Discovery.

Q: Câu hỏi của mình đây (và có thể là câu hỏi mong muốn của nhiều bạn): áp dụng microserver có điểm gì dở nhất cho việc phát triển một hệ thống phần mềm, và ngoài kiểu Rest call giữa các microservice, thì còn kiểu nào nữa? Mỗi kiểu áp dụng cho trường hợp nào?

A: Mình xin trả lời nhé:

Về điểm dở của Microservices đó là việc phát triển ứng dụng khó hơn, vận hành & xử lý lỗi cũng khó hơn nhiều. Stack công nghệ cũng thay đổi rất nhiều so với làm ứng dụng Monolithic.

Bạn cần xác định trước 1 số yếu tố khi triển khai microservice:
1. Đây có phải là sản phẩm phát triển lâu dài hay không?
2. Mức độ scale của hệ thống có lớn không (scale về lượng người dùng hoặc về dữ liệu)?
3. Team có sẵn sàng đối đầu với những khó khăn khi chuyển sang mô hình này không?

Khi bọn mình bắt đầu làm cho sản phẩm Bizweb thì 2 câu hỏi đầu đã xác định được luôn rồi. Câu số 3 thì cũng ko gặp vấn đề gì vì cả team đều rất máu chiến, mặc dù lúc đó chưa biết gì.

Microservice có một số mô hình phát triển:
1 là dùng Restful thuần túy, sử dụng format JSON (hoặc Protobuf, Avro…). Các service gọi service khác đồng bộ hoặc bất đồng bộ.
2 là theo mô hình message queue, sử dụng các hệ thống message như RabbitMQ, Kafka… để tương tác giữa các microservice. Cách này là bất đồng bộ hoàn toàn.
3 là dùng Event Sourcing Pattern, phân tách phần đọc & ghi. Mô hình này thì bên mình chưa triển khai.

Độ khó thì tăng dần từ mô hình 1 -> 3

Theo mình cái dở (ý không phải cái khó) có nghĩa khác. Cái dở – cũng là cái hay của microservice chính là vì nó tách rời dữ liệu và logic các module của hệ thống, lỏng lẻo hơn, chỉ liên quan đến nhau bởi các API được define để giao tiếp nhau theo quy tắc định trước, nó không đề cao tính integrity về dữ liệu lẫn đồng nhất chức năng của cả hệ thống, để có được tính uyển chuyển độc lập cao hơn giữa các module, ví dụ trong quản lý khách hàng và hợp đồng dịch vụ kiểu monolithic, thì thường cùng 1 DB, các entitty hay các bảng thường có ràng buộc bởi khoá ngoài với nhau để đảm bảo đồng nhất dữ liệu, và cũng gắn với nhau về quy trình, ví dụ không bao giờ có chuyện tạo ra hợp đồng dịch vụ web rồi mới tạo ra bản ghi khách hàng của hợp đồng đó, phải đúng thứ tự bởi mỗi bước sẽ bị kiểm tra tính chất này.

Với microservice thì có thể nếu module quản lý hợp đồng và module quản lý khách hàng là 2 service độc lập, hợp đồng có thể tạo trước, và gắn mã khách hàng sau đó 1 quy trình độc lập khác, chả có gì ngăn cản lập trình viên không làm điều đó cả, và người thiết kế phần mềm phải tính toán các trường hợp ngoại lệ như thế như là 1 đặc tính phải có.
Đây chính là đặc điểm khiến cho microservice không phù hợp để áp dụng cho một số bài toán cần sự đồng nhất cao của dữ liệu và cần chặt chẽ của logic, nếu nó quá phức tạp, như bài toán cần tính chất transaction chắc chắn như banking, hoặc hệ thống thanh toán điện tử.

Ý kiến vậy thôi.

Sorry mình giờ mới trao đổi tiếp. Đúng như bạn nói, bản thân kiến trúc microservices là tách thành các module nhỏ. Và theo nguyên lý CAP (Consistency, Availability, Partition tolerance) thì chỉ 2 trong 3 yếu tố trên là đc đảm bảo trong 1 ứng dụng. Microservices thường đáp ứng 2 yếu tố A & P, còn yếu tố C về tính nhất quán thì ko đảm bảo dc. Nhưng nếu yêu cầu nghiệp vụ hệ thống chấp nhận Eventual Consistency – tức là cho phép độ trễ trong việc đồng bộ dữ liệu thì microservices vẫn đáp ứng đc. Với cách giải quyết phù hợp thì mình nghĩ microservices vẫn có thể áp dụng được vào các bài toán banking hoặc thanh toán điện tử. Ngoài ra một số hệ thống banking mình biết còn áp dụng mô hình CQRS – tách biệt phần ghi & phần đọc dữ liệu, cho phép có độ trễ nhỏ khi hiển thị thông tin thanh toán cho ng dùng.

Q:  Em chào anh Khôi ạ, hiện tại em có một dự án về bán hoa online tuy nhiên bên client yêu cầu kích thước của ứng dụng siêu nhỏ, vậy làm sao để dữ liệu không bị phân tán quá mức cần thiết ạ.

A: Anh chưa rõ câu hỏi của em lắm. Ứng dụng của e là ứng dụng web hay mobile, dữ liệu hiện tại phân tán như thế nào (lưu cả ở client lẫn server)? Em bổ sung thêm a sẽ tư vấn đc

Q: Anh có thể chia sẻ về những kinh nghiệm gặp khó khăn cũng như những giải pháp mà anh đã từng trải trong suốt quá trình sử dụng microservice. Có bài học nào a nhớ nhất k?

A: Khó khăn thì có nhiều đó em, a chia sẻ lại mấy cái gặp phải khi phát triển Bizweb:
– Thay đổi tư duy từ close source sang open source: trước đó team chỉ làm ASP.NET + SQL Server + Windows Server, còn lại gần như không áp dụng công nghệ gì khác. Sau đó thay đổi 180 độ sang các giải pháp open source: Java Spring, Netflix OSS, MongoDB, Nginx, Linux, Kafka, Docker…Mà trước đó gần như cả team chưa biết gì, tự học từ đầu hết. Sau 6 tháng ra được bản demo sản phẩm, 8 tháng ra mắt phiên bản chính thức.

– Việc vận hành, phát hiện & xử lý lỗi khó hơn nhiều: trước kia mô hình đơn giản, vận hành rất dễ, chỉ cần monitor mỗi con máy chủ web + máy chủ db là xong. Nhưng khi chuyển sang microservices thì nó là 1 hệ thống phân tán, phải xử lý mấy chục service, chạy trên nhiều máy chủ (vật lý & ảo hóa) khác nhau. Nói thật là nhiều khi gặp lỗi mất nguyên 1 ngày mới tìm ra được nguyên nhân 😀 Việc xây dựng hệ thống monitor dịch vụ là cần thiết và nên được đầu tư sớm.

– Phải luôn luôn học hỏi, nâng cao kỹ năng của dev & test: món này ko dành cho bạn nào lười học hỏi, các bạn sẽ nản ngay vì nó khá phức tạp. Anh nhận thấy sau 2 năm các bạn trong team kỹ năng phát triển rất nhanh & giỏi.

Q: Chào anh, anh chia sẻ giúp e những tài liệu hay về Microservices vs anh. Thank anh nhiều

A: Có 1 số nguồn e có thể tham khảo nhé:
http://microservices.io/
https://martinfowler.com/articles/microservices.html
http://www.slideshare.net/juminchoi/bizweb-microservices-architecture
https://www.nginx.com/blog/introduction-to-microservices/

Kinh nghiệm của a khi triển khai là cứ làm mô hình ban đầu đơn giản rồi upgrade nó dần dần.

Q: Anh Khôi cho em hỏi, làm thế nào để quản lý việc cập nhật dữ liệu một cách đồng bộ với nhiều bảng trong cơ sở dữ liệu trung tâm ạ ?

A: Ý em muốn nói đến là thực hiện distributed transaction trong microservices hả? Bên anh hiện tại đang tránh việc đó, nói chung đó là 1 cái khó. Anh Nghĩa bên Tiki có 1 buổi chia sẻ về distributed transaction thứ 7 vừa rồi, slide đây em: http://www.slideshare.net/NghiaLeMinh1/distributed-transaction-lastest-version

Q: Anh ơi, muốn test 1 service nhỏ trong khối microservice thì đôi khi phải yêu cầu chạy các services khác vì các services phụ thuộc dây chuyền với nhau. Vậy nên việc test sẽ trở nên rất khó khăn và anh có thể chia sẻ 1 vài hướng giải quyết được không ạ? Và nếu 1 mắt xích trong khối microservice thay đổi thì các mắt xích khác có thay đổi theo không? Và đến đây việc testing có còn khả thi?

A: Đúng là việc test trong hệ thống microservices là khá khó khăn. Về vấn đề môi trường thì cần phải có đủ các service chạy mới test được nên để test trên máy của dev là khá phức tạp. Bọn anh có 1 máy chủ dev ở công ty, trên đó chạy đủ các service (service discovery, api gateway, redis, kafka…). Các bạn có thể cấu hình project trên máy của dev sử dụng lại các tài nguyên đó, hoặc nếu máy bạn nào cấu hình tốt thì chạy full service.

Khi 1 service thay đổi thì các service liên quan cũng cần update theo, nó không khác gì việc phát triển ứng dụng thông thường. Tuy nhiên trong thiết kế thì bên anh tránh tối đa việc gọi chéo giữa các microservices. Để làm được thế thì việc phân tách Bounded Context cần đảm bảo.

Bên a cũng đang áp dụng automation test để test API. Test từng API 1 thì dễ, nhưng để test theo quy trình (gọi service A, lấy kết quả làm tham số đầu vào gọi sang service B, C) thì chưa tìm ra được công cụ nào làm việc đó. Thế nên chỉ còn 1 cách là sử dụng Selenium Webdriver để lập trình automation test thôi.

Q: anh cho e hỏi là từ dev lên CTO, mình cần “update” bản thân những mảng nào hay kĩ năng nào đặc biệt quan trọng k anh?

A: Căn bản 1 công ty cũng chỉ có 1 ông gọi là CTO nên câu hỏi này khó trả lời quá😀. Từ ngày DKT mới thành lập thì a đã là CTO rồi.
Nhưng nếu nói về hướng phát triển của 1 dev thì có thể đi theo 2 hướng:
– Trở thành chuyên gia: ít nhất là của 1 lĩnh vực nào đó, ví dụ DB Expert (MySql, SQL Server, Oracle), Software Architect, Enterprise Architect, Cloud Solution Architect. Cái này a nghĩ cần cày cuốc nhiều & cũng cần có tố chất chút.
– Trở thành quản lý: trưởng nhóm, trưởng phòng. Cần có các kỹ năng mềm về quản lý & giám sát công việc, xây dựng team.

CTO ở VN có lẽ là tổng hòa của cả 2 cái trên (R&D, định hướng công nghệ, hỗ trợ các đội giải quyết các vấn đề khó cả nhân sự lẫn kỹ thuật, xây dựng quy trình, giải đáp thắc mắc tâm sinh lý)

Q: Anh có thể giải thích nếu các dịch vụ nhỏ thiết kế phục thuộc vào nhau theo chuỗi. A gọi B, B gọi C, C gọi D. Nếu một mắt xích có giao tiếp API thay đổi, liệu các mắt xích khác có phải thay đổi theo không vậy anh ?

A: Về thiết kế microservices thì đây là 1 việc nên tránh:
Thứ 1 là nó tăng sự phức tạp của hệ thống lên nhiều (khó phát triển, khó debug), tăng sự phụ thuộc giữa các microservices. Để tránh việc đó thì cần phân tích bài toán nghiệp vụ thật kỹ để chia hệ thống ra các domain khác nhau, gọi là Bounded Context. Mỗi 1 microservices là 1 Bounded Context, và hầu hết mọi thao tác xử lý sẽ nằm trong microservices đó, ko phải gọi qua thằng khác.
Thứ 2 là ảnh hưởng performance do gọi chéo nhiều quá (tăng network latency)
Thứ 3 là khi thay đổi 1 microservices e sẽ phải sửa những microservices có gọi đến nó. Như vậy là mất đi khá nhiều ý nghĩa của việc triển khai microservices (loose coupling)

Q: Anh ơi, liệu Microservices có đúng trong đa số trường hợp bài toán? Có ngoại lệ nào hay không?

A: Ko có cái gì gọi là “one size fits all” cả em. Thế nên microservices cũng chỉ phù hợp với 1 số bài toán & cần đội ngũ phát triển có kỹ năng tương đối.
Áp dụng microservices sẽ giúp ích nhiều khi cần quan tâm 1 số vấn đề như:
1. Sản phẩm phát triển lâu dài
2. Xử lý lượng người dùng hoặc dữ liệu lớn
3. Scale team phát triển
4. Bảo mật mã nguồn
5. Đảm bảo phát triển liên tục (CI/CD), update tính năng này ko làm downtime tính năng kia

Ngoài ra thì đội ngũ phát triển cũng cần có kỹ năng khá & ham học hỏi.

Q: Chào anh, hiện tại thì làm thế nào để kiểm soát danh tính người dùng trong Microservice một cách đơn giản mà không bị phân tán dữ liệu ?

A:  Dữ liệu danh tính người dùng thì chỉ lưu ở 1 nơi thôi em, khi nào cần xác thực thì truy vấn vào đó.

Có 2 cách xử lý authentication & authorization trong microservices.
1 là xử lý tập trung: có thể để ở API Gateway hoặc có 1 microservices thực hiện việc authentication/authorization, các service khác sẽ gọi đến service đó để kiểm tra quyền.
2 là authentication/authorization trên mỗi microservices. Khi đó sẽ viết nó thành 1 thư viện dùng chung giữa các microservices. Việc update thư viện này cũng ko thường xuyên nên không gặp phải vấn đề.

Và bên anh đang áp dụng cách thứ 2, nó tránh việc phải gọi đến service xác thực quá nhiều. Em có thể tìm hiểu chi tiết hơn về giải pháp trong slide anh có share ở mấy comment khác đó

Cảm ơn anh Minh Khôi đã rất nhiệt tình giải đáp cho các các bạn fan của Topdev những thắc mắc liên quan đến Microservices.

Chúc các bạn dev nhiều thuận lợi trong công việc và cuộc sống.

Bill Gates: 3 kỹ năng đảm bảo giúp bạn kiếm được việc!

Bill Gates, như chúng ta đều biết, là người đàn ông giàu có nhất thế giới! Bill Gates, tên thật là William Henry Bill Gates, 1 ông trùm kinh doanh, 1 doanh nhân, 1 nhà từ thiện, 1 nhà đầu tư và cũng là 1 lập trình viên.

Vì vậy, nếu bạn đang bâng khuâng lựa chọn ngành nghề, vì nhất định không thể bỏ qua lời khuyên của Bill Gates.

Theo Bill Gates, các công việc trong tương lai sẽ thuộc về những người giỏi trong các lĩnh vực như Khoa học, Engineering và Toán học. Dựa trên dữ liệu thu thập mà Bill Gates thu thập được thì background liên quan đến 3 ngành này sẽ được săn đón nhiều nhất.

“Bạn không chỉ biết viết code, mà còn phải hiểu các engineers có thể làm gì và không thể làm gì”

 

Doanh nhân tỷ phú cũng bổ sung thêm các nhân viên thành thạo Khoa học, Engineering và Toán học chính là “tác nhân thay đổi các tổ chức. Điều này bắt nguồn từ thực tế là Trí thông minh nhân tạo, IoT và Machine Learning sẽ có những bước tiến mạnh mẽ hơn trong những năm tới.

Nguồn: blog.topdev.vn via Techviral

7 cách giúp nhân viên làm việc năng suất trong mùa lễ

Mùa lễ Tết đang đến gần.

Đối với các nhân viên bán lẻ của Mỹ, Halloween kết thúc đánh dấu 1 cột mốc đáng sợ hơn: lễ Tết. Các hoạt động kinh doanh bùng nổ, nhân viên kiệt sức, áp lực và không có thời gian dành cho gia đình vì phải làm việc tăng ca. Là chủ 1 doanh nghiệp nhỏ, bạn sẽ nhanh chóng nhận ra đây chưa hẳn là thời điểm tuyệt vời nhất trong năm.

Giữ cho nhân viên của bạn có động lực và làm việc hiệu quả trong kỳ nghỉ lễ là điều khó khăn. Họ đang trải qua những nhu cầu liên quan đến kỳ nghỉ trong cuộc sống cá nhân của họ. Họ có những kỳ vọng về kỳ nghỉ của riêng họ, và đối với hầu hết họ, có lẽ là tận hưởng kỳ nghỉ chứ không phải làm việc 24/7.

Dưới đây là một số điều cần ghi nhớ trong kỳ nghỉ lễ nếu bạn muốn duy trì động lực cho cả nhóm của mình

Xem thêm Tại sao phải giữ chân nhân viên?

Hãy cho họ thời gian nghỉ

Với 1 tổ chức nhỏ, chỉ cần 2 nhân viên nghỉ thôi doanh nghiệp sẽ gặp khó khăn ngay. Bạn có thể đóng cửa vào ngày Giáng sinh nhưng không thể đóng cửa liên tiếp 4 ngày. Vậy làm cách nào để kiểm soát tình trạng PTO (Personal Time Off – Thời gian nghỉ cá nhân) vào ngày lễ  1 cách tốt nhất?

Đừng bủn xỉn quá.

Nếu muốn team của mình hoạt động với 100% công suất dù phải bỏ lỡ thời gian quý giá bên gia đình, bạn cần phải thể hiện rõ bạn trân trọng công việc của họ bằng các giá trị tương đương. Từ chối thời gian nghỉ của nhân viên trong thời gian lễ sẽ dẫn đến cảm giác giận dữ, mích lòng, đi kèm với việc nhân viên không còn động lực làm việc nữa.

Nên nhớ, làm việc hơn 40 giờ 1 tuần sẽ giảm hiệu suất công việc và mức 60 giờ/ tuần cũng sẽ ảnh hưởng đến doanh nghiệp về lâu dài. Tình trạng kiệt sức sau thời gian lễ là có thực và sau lễ Tạ ơn, nhân viên sẽ có nguyên 1 tháng để ra đi.

Thay vào đó, hãy cho nhân viên thời gian nghỉ. Bạn có thể bàn bạc với team về số lượng ngày nghỉ, và thiết lập 1 sơ đồ ngày nghỉ để họ chọn – theo mức độ thâm niên, xố số may mắn hoặc ai đặt lịch trước thì nghỉ trước. Càng làm thao tác này sớm, bạn càng quản lý được khoảng thời gian nào có nhiều yêu cầu xin, nên ưu tiên yêu cầu của ai trước và giải quyết các ngày nhiều người nghỉ ra sao. Nếu bạn bắt 1 vài nhân viên làm việc 1 tuần nghỉ lễ, hãy cân nhắc cho họ quyền ưu tiên được nghỉ vào đợt kế tiếp.

Tặng quà cho nhân viên của bạn

Tại sao không tặng nhân viên của bạn những món quà vật chất thực tế?

  • Cốc du lịch tùy chỉnh.
  • Áo phông hoặc áo khoác.
  • Bộ theo dõi bước.
  • Sách về lãnh đạo hoặc các chủ đề thú vị khác.
  • Các tạp chí có thương hiệu.
  • Một cái gì đó hoàn toàn không thực tế nhưng hoàn toàn vui vẻ.

Đặt mục tiêu cuối năm cho team (hoặc không)

Hãy quên đi những quyết tâm của Năm mới và thực hiện những mục tiêu vào cuối năm. Vào ngày 31/12, bạn muốn đạt được thành tựu gì cho doanh nghiệp của mình? Làm thế nào để bạn và nhân viên phối hợp cùng nhau để đạt được mục tiêu đó?

Dù mục tiêu là gì, cũng phải đảm bảo mọi thành viên đều có thể đóng góp vào đó. Mục tiêu có thể là đạt hạn ngạch cuối năm, số lượng đơn đặt hàng nhân đôi hoặc đạt thêm số X khách hàng mới. Bạn cũng có thể kéo giãn mục tiêu – 1 con số yêu cầu team nỗ lực hơn mới đạt được, nhưng không quá bất khả thi. Luôn tưởng thưởng xứng đáng với ai làm thêm việc. Đề xuất thêm ngày nghỉ, tiền thưởng để họ mua quà cho người thân hoặc trao cơ hội được nghỉ lễ cho lần tới.

Bằng email cập nhật hằng ngày hoặc cột mốc thời gian gắn ở nơi dễ thấy, bạn sẽ theo dõi mức độ tiến bộ dựa theo mục tiêu đã kéo giãn của bạn. Cổ vũ tinh thần của team khi gần đạt mục tiêu, tăng thêm động lực bằng 1 buổi coffee hoặc bữa trưa miễn phí.

Tuy nhiên, nếu các nhân viên của bạn đang “lầy lụa”, thì đây có thể không phải là ý tưởng tốt nhất vì sẽ tạo ra nhiều áp lực. Ngược lại, nếu nhân viên đang sục sôi tinh thần cạnh tranh mà không lo bị kiệt sức thì cứ thế mà tiến.

Có tổ chức

Rất khó để theo dõi tất cả mọi thứ. Thường thì giữa việc cân bằng công việc, cuộc sống và ngủ, những người chủ của các doanh nghiệp nhỏ chỉ chọn 2 mà thôi. Bí quyết để giữ được sự tỉnh táo của chính bạn và của team chính là: tính tổ chức.

Luôn đi trước deadlines. Biết rõ những gì cần hoàn thành và thời điểm nào cần hoàn thành. Bắt đầu vạch rõ ngày cuối cùng có sẵn các đơn đặt hàng từ khách hàng hoặc thời điểm cuối cùng để gửi hàng. Đảm bảo mọi người biết rõ về lịch nghỉ hoặc ai sẽ nghỉ thời gian nào hoặc ai sẽ làm thay phần việc của ai. Cập nhật danh sách về người chịu trách nhiệm thông báo khi thời tiết bất thường hoặc các tình huống trì hoãn chuyến bay…

Nếu đến cuối cùng, nhân viên lại muốn làm việc tại nhà, hãy đảm bảo hệ thống lưu trữ đám mây hoặc các files online và các hệ thống quản lý dự án luôn cập nhật. Giả như vào 10h tối đêm trước Christmas có 1 khách hàng gọi đến hỏi hàng hóa của họ ở đâu hoặc tại sao hàng vẫn chưa chuyển đi, bạn vẫn có thể biết chính xác điều gì đang xảy ra.

Nắm bắt tinh thần lễ hội

Mang tinh thần vui vẻ vào công việc với 1 vài cuộc thi hoặc trò chơi trao đổi quà. Cho phép nhân viên đội mũ hoặc mang lễ phục khi đi làm. Chụp các bức ảnh nhóm và ghép với nhau thành 1 tấm thiệp lễ hội để gửi đến khách hàng và nhân viên.

Dù không trực tiếp mang tinh thần lễ hội vào công việc đi nữa thì thái độ của bạn vẫn sẽ lay động nhuệ khí của nhân viên. Hãy nói cho họ biết bạn trân trọng họ ra sao. Nếu nhân viên của bạn (hoặc bạn) cần 1 không gian an toàn hoặc 1 cái gì đó để trì hoãn áp lực từ những người mua hàng, hãy sắp xếp 1 phòng riêng để giải tỏa căng thẳng. Đó có thể là 1 khu vực ít được sử dụng, kèm túi ngủ lớn, vài bánh snack hoặc bất cứ thứ gì nâng cao tinh thần của nhân viên.

Bạn cũng có thể yêu cầu team tải 1 ứng dụng luyện thiền như Headspace và dành ra vài phút đầu ngày để tập hợp các nhân viên lại thành 1 nhóm. Nghiên cứu đã cho thấy chỉ cần thiền trong vài phút là đủ để giảm mức độ stress. Ngoài ra bạn có thể thực hiện vài hoạt động team building như yêu cầu mỗi người trong team đi vòng quanh và nêu 1 thứ khiến họ yêu quý nhất ở các thành viên trong team. Hoạt động này sẽ kích thích tinh thần trò chuyện mở và tăng nhuệ khí của nhân viên, cùng tập trung vào hoàn thành công việc.

Đăng kí tham dự 1 sự kiện tình nguyên cho cả team

Điều gì sẽ xảy ra nếu bạn có thể nâng cao cảm giác hạnh phúc trong nhân viên, giảm nguy cơ trầm cảm và gia tăng vòng đời sống của họ? Đúng vậy, bạn không thể làm tất cả điều đó trong 1 ngày nhưng có 1 thứ mà bạn có thể bắt đầu: làm tình nguyện. Tham gia hoạt động tình nguyện trong cộng đồng sẽ tăng khả năng vận động, các kết nối xã hội và hạnh phúc cá nhân – 1 công thức hoàn hảo dành cho các nhân viên năng suất và có tinh thần cao. Thêm nữa, hầu như 75% nhân viên muốn công ty của họ hỗ trợ vấn đề xã hội nhiều hơn.

Các hoạt động mà team có thể tham gia như: phát đồ ăn từ thiện, hỗ trợ những gia đình gặp khó khăn hoặc thăm quan 1 trại thú nuôi. Đây là cơ hội để nhân viên dành thời gian bên nhau ngoài công sở.

Khuyến khích nhân viên vận động

Tập thể dục tại nơi làm việc là 1 phương pháp quan trọng giúp cho nhân viên hạnh phúc và năng suất hơn. Các bài tập thường xuyên sẽ mang đến nhiều năng lượng hơn xuyên suốt cả ngày và thậm chí là nhiều tế bào não hơn, so với những đồng nghiệp không tập thể dục, thể thao. Những người có nhiều khả năng luyện tập, đặc biệt ở cường độ cao hơn là khi họ luyện tập theo nhóm.

Nếu trong team của bạn đã có nhiềuthành viên thường xuyên luyện tập thì bạn có thể kêu gọi họ cùng nhau tham gia các cuộc thi thể thao mùa lễ hội. Hoặc thách thức các nhân viên đo lường mức độ tiến bộ của nhau trong 1 ứng dụng chung như dành khoảng 15 phút để tập yoga trong giờ làm việc… từ đó tạo động lực vận động cho nhân viên xuyên suốt những tháng mùa đông. Thêm nữa, hãy tưởng tưởng 1 phần quà lớn để kích thích nhân viên nỗ lực hơn vào năm tới.

Cuối cùng thì… hãy quẩy lên!

Dù cho bạn có đạt mục tiêu cuối năm hay chưa, dù có đạt doanh số trong ngày Black Friday hay không, cũng đừng quên dành thời gian để ăn mừng. Nhân viên thích các buổi tiệc lễ hội hơn cả việc kì nghỉ Giáng sinh bị hủy bỏ. 9 trên 10 người được phỏng vấn cho biết họ cảm thấy thất vọng nếu buổi tiệc lễ tại công ty bị hủy bỏ, và 9 trên 10 người cũng nói rằng các buổi tiệc này đóng vai trò quan trọng với tinh thần năng động của team.

Bạn có thể chỉ mời nhân viên hoặc mời cả gia đình đến để tham gia chơi trao đổi quà tặng. Nếu team của bạn hoàn thành các mục tiêu, bạn có thể mang đến vài bất ngờ như 1 địa điểm không ai nghĩ tới hoặc vài món quà thú vị.

Mùa lễ hội đã và đang bắt đầu. Hãy giúp nhân viên luôn làm việc tốt bằng cách trao cho họ khoảng thời gian nghỉ họ cần và xây dựng 1 lịch làm việc rõ ràng. Tìm mọi cách để giảm stress bằng các ứng dụng miễn phí, các hoạt động teambuilding, tập thể thao theo nhóm hoặc các sự kiện tình nguyện cộng đồng. Đừng quên tập trung vào những thành tựu đã đạt được và dành thời gian để cổ vũ kết quả công việc của nhân viên.

Nguồn wheniwork

Các công việc của tương lai & 2 kỹ năng bạn cần chuẩn bị

Bức tranh tương lai của việc làm là chủ đề nóng tại World Economic Forum Annual Meeting – Hội nghị thường niên của Diễn đàn Kinh tế thế giới.

Liệu robot có làm hết phần việc của bạn? Hàng triệu người từng không công nhận phong trào tự động hóa sẽ nhanh chóng phải chấp nhận câu trả lời “yes”.

Nghiên cứu Future of Jobs của Diễn đàn Kinh tế thế giới dự đoán sẽ có 5 triệu việc làm bị mất trước năm 2020 vì trí thông minh nhân tạo, robotics, công nghệ nano và các yếu tố kinh tế-xã hội sẽ thay thế nhu cầu tuyển dụng lao động là con người.

Tin tốt là cùng lúc đó, những tiến bộ công nghệ cũng tạo thêm 2,1 triệu việc làm mới. Người lao động chân tay và liên quan đến giấy tờ có thể không sở hữu kĩ năng cần thiết để cạnh tranh cho vị trí mới. Hầu hết những công việc mới sẽ rơi vào các lĩnh vực chuyên môn hơn như điện toán, toán học, kiến trúc và kĩ sư.

Các nhà quản lý và người lao động trong mỗi lĩnh vực đều đang được kêu gọi phải kiềm chế và rèn luyện lại kĩ năng cho nhân viên của mình để tránh 1 cuộc khủng hoảng.

“Nếu không có hành động nhanh chóng và chính xác ngay bây giờ, các nhà quản lý phải giải quyết với tình trạng thất nghiệp và bất bình đẳng tăng cao và các doanh nghiệp đang có nguồn khách hàng thu hẹp để quản lý giai đoạn chuyển giao ngắn hạn và xây dựng 1 lực lượng lao động với các kĩ năng bảo chứng cho tương lai (future-proof)” – Klaus Schwab, Nhà sáng lập kiêm Giám đốc điều hành của Diễn đàn Kinh tế thế giới cho biết.

Các kĩ năng mới cho những nền kinh tế mới

Vậy người lao động cần phải có những kĩ năng gì để chắc chắn rằng họ mang đến đủ giá trị cho doanh nghiệp khi 4.0 đang đến gần? Một số người ắt hẳn sẽ ngạc nhiên khi nhận ra các kĩ năng thu thập được ở thời mầm non được đánh giá rất cao.

David Deming, Phó Giáo sư Kinh tế và Giáo dục tại ĐH Harvard cho rằng các kĩ năng mềm như chia sẻ và thương thuyết đóng vai trò cực quan trọng. Theo đó, địa điểm làm việc hiện đại, nơi mọi người di chuyển giữa nhiều vai trò và dự án khác nhau sẽ tương tự như các lớp học mầm non – nơi chúng ta học các kĩ năng xã hội như đồng cảm và cộng tác.

Trong mô hình bên dưới, Deming đã phác thảo những nhu cầu đang thay đổi của nhân viên và các kĩ năng quan trọng để vươn lên được trên thị trường việc làm trong tương lai gần. Cùng với các kĩ năng mềm đó, kiến thức toán học cũng có ý nghĩa rất lớn.

Các công việc cần bộ kĩ năng đơn sẽ ít dần

Deming cho rằng trong những năm gần đây, rất nhiều công việc chỉ đòi hỏi các kĩ năng toán học đã được tự động hóa như giao dịch viên ngân hàng và nhân viên thống kê… Những vi trí đa phần đòi hỏi các kĩ năng xã hội (ví dụ: nhân viên chăm sóc trẻ) có khuynh hướng nhận lương thấp vì nguồn cung cấp nhân lực tiềm năng là rất lớn.

Nghiên cứu chỉ ra: các nhân viên – những người kết hợp thành công các kĩ năng toán học, giao tiếp, tạo lập mối quan hệ trong các nền kinh tế tri thức tương lai sẽ tìm kiếm được những cơ hội hữu ích, sinh lợi.

Tái tập trung vào giáo dục các kĩ năng

Theo Deming, thách thức đang đặt ra cho các nhà giáo dục để thực thi quy trình giảng dạy các kĩ năng kĩ thuật như toán học và khoa học máy tính, đảm bảo nhân sự tương lai có được các kĩ năng mềm để cạnh tranh trên thị trường việc làm mới.

Nguồn weforum 

Trưởng bộ phận tuyển dụng của Linkedin làm gì đầu tiên với ứng viên khi phỏng vấn?

Bài viết lý giải nguyên nhân tại sao mỗi khi phỏng vấn ứng viên, Trưởng bộ phận tuyển dụng của Linkedin – Brendan Browne – lại đưa cho họ 1 cây bút đánh dấu xóa được, yêu cầu họ đến thẳng chiếc bảng trắng treo trên tường.

Browne đã cầm lái đội ngũ tuyển dụng của kênh mạng xã hội nổi tiếng Linkedin từ năm 2010, và trong quá trình xây dựng đội ngũ của mình, anh đã tìm ra được 1 bài tập mới lạ, nhờ đó Browne biết được có nên tuyển ứng viên đó hay không.

Brendan Browne linkedin

Bất kể đang tuyển vị trí gì, Browne cũng sẽ hỏi ứng viên: “Điều bạn tâm huyết nhất trong cuộc sống là gì? Hãy sử dụng bảng trắng kia, giải thích cho tôi quy trình hoạt động của nó” 

“Vì đây là 1 tình huống khá mơ hồ nên các ứng viên có khuynh hướng trả lời 1 cách rất tự nhiên”

Ví dụ, nếu 1 ứng viên thích uống bia tự pha khi có thời gian rảnh, anh ta sẽ vẽ ra 1 quy trình pha bia và giải thích quy trình đó. Tương tự với 1 ứng viên có đam mê theo vai trò cụ thể (role-specific) như product management.

4 điều mà Browne học được từ bài tập này:

  1. Điều gì khiến các ứng viên quan tâm sâu sắc nhất?

2. Họ có thể giải thích về bản thân ở mức độ nào? 

3. Cách suy nghĩ về quy trình?

4. Cách giải quyết câu hỏi/ tình huống… mơ hồ? 

Tạo CV Online mới nhất tại đây

Nhờ có bài tậ trên, Browne đã thể hiện rõ quan điểm của CEO của LinkedIn CEO, Jeff Weiner về 1 nhân viên lý tưởng sẽ phù hợp với 3 mảng sau: mơ những điều lớn lao, biết cách có được niềm vui và hoàn thành công việc.

“Rất khó để đánh giá 1 buổi phỏng vấn vì tính thiếu sót sẽ rất cao, nhưng điều mà tôi thực sự muốn biết chính là bạn là ai, và mọi thứ sẽ như thế nào nếu bạn và tôi cùng nhau giải quyết 1 vấn đề khó nhằn và chúng ta phải làm việc tới mức… sút chỉ tụt quần?” – Browne chia sẻ.

Browne cũng cho biết các ứng viên thường bất ngờ bởi câu hỏi trên vì họ đang mong đợi 1 cái gì đó truyền thống hơn hoặc liên quan đến công việc họ đang làm hơn, nhưng cách họ phản hồi với cảm giác khó chịu sẽ xác định được liệu ứng viên có thể giải quyết những gì mà Browne mong đợi ở họ tại công sở hay không.

“Có thể chúng tôi sẽ quyết định loại bỏ 1 dự án mà chúng tôi đang làm hoặc thay đổi thứ gì đó – những chuyện thường xảy ra trong kinh doanh, nhất là tại Thung lũng Silicon – thì tôi muốn xem cách bạn giải quyết nó”. Đó là lý do tại sao anh nghĩ câu trả lời cho câu hỏi phỏng vấn yêu thích của anh ở trên sẽ là “dấu hiệu hàng đầu” cho thấy mức độ thành công trong các tình huống đã nêu.

Bạn cũng có thể xem thêm bài test trắc nghiệm tính cách cho các Dever tại đây nhé!

Nguồn: Business Insider

“MMRPG vẫn thống trị thị trường Mobile Game và Shooting và game cho nữ giới sẽ bùng nổ”

AMA (Ask Me Anything) là 1 sự kiện Q&A (Hỏi đáp trực tiếp) diễn ra đều đặn trên fanpage của TopDev vào thứ 6 hằng tuần.

Tuần này, AMA quay trở lại với các bạn đam mê IT với sự xuất hiện của khách mời Lê Giang Anh – CEO của JOY Enertaiment. 7 năm kinh nghiệm làm việc trong lĩnh vực video game, đặc biệt ở những mảng lập trình, thiết kế, quản lý chất lượng và sản xuất game giúp anh Giang Anh trở thành 1 nhân vật đình đám trong làng game Việt với kiến thức rộng rãi về mobile game, mobile app marketing.

Cùng AMA xem qua màn trò chuyện của anh vào ngày 13/1 nhé!

Tham khảo tuyển dụng lập trình Game hấp dẫn lương cao

Q: Chào anh Giang Anh, em có một thắc mắc nhỏ là không biết hiện nay thiết kế mobile app đang chuộng xu hướng nào ạ. Em cảm ơn anh

A: Hi bạn. Ý bạn là xu hướng về kỹ thuật hay xu hướng về kinh doanh? Nếu về kỹ thuật thì việc sử dụng các framework cross-platform mới như React Native đang lên ngôi.
Còn về kinh doanh thì ở nước ngoài đang rộ lên về Bot/AI. Tuy nhiên mình nghĩ việc áp dụng được vào team của chúng ta được hay không còn tùy thuộc nhiều yếu tố khác, ví dụ như thị trường, mục đích sản phẩm

Q: Anh đánh giá như thế nào về tốc độ phát triển của mobile marketing hiện nay và trong tương lai?

A:  Mình giả định bạn đang nói thị trường Việt Nam. Ở Việt Nam hiện nay chưa định hình chuẩn về mobile marketing. Chủ yếu vẫn chỉ dùng lại ở: Mobile Ads và SMS/Mobile Social Network. Còn các mảng khác như Mobile App Marketing (ASO, Re-marketing, branding, etc) thì gần như bỏ ngõ.

Q: Em chào anh Giang ạ. Anh ơi hiện tại em đang học về lập trình Java tuy nhiên em cũng có vài ý tưởng làm app trên mobile và em muốn ứng dụng Machine Learning vào ý tưởng của mình thì em nên tham khảo tài liệu gì vậy anh?

A: Hi bạn. Mình không chuyên sâu về tech như vậy nên không thể hỗ trợ bạn được. Tuy nhiên mình thấy ML và AI đang hot nên việc tìm kiếm tài liệu chắc không phải khó khăn. Tốt nhất bạn nên tìm hiểu các tài liệu mới bằng tiếng Anh

Q: Em chào anh Giang ạ, em hiện đang khá mê viết game nên em có đi tìm hiểu vòng vòng trên bác Google, thì thấy có mấy bác khuyên nên thử Python nếu như mới tập code game. Theo anh như vậy có hợp lý không anh?

A: Mình không rõ lý do các bạn khác khuyên xài Python là gì. Tuy nhiên hiện nay hầu hết các dev xài các game engine để có thể phát triển cross platform được dễ dàng. Ví dụ: Cocos2D-x, Unreal xài C++ và Unity3D xài C#

Q: A có thể hướng dẫn e về những phong cách trong lập trình game mobile ko a ?

A: Câu hỏi hơi rộng. Mình hiểu ý bạn là các các kiểu/style/quy mô của phát triển game. Như vậy thì có:

  • One man army: 1 mình cân tất
  • Tiny indie: Team từ 2-3 bạn làm game
  • Studio: team từ khoảng 5 bạn trở lên

Còn về thể loại thì nhiều: Tập trung vào casual games, tập trung vào online game, casino game, etc.

Q: Anh có lời khuyên nào dành cho những startup về mobile game không ạ? Cụ thể là về game dạng casino….

A: Đừng làm ở Việt Nam nhé bạn.

Q: theo anh nhận định thì thể loại mobile game nào sẽ phát triển mạnh mẽ nhất tại thị trường Việt Nam trong năm nay?

A: Mình nghĩ MMRPG vẫn thống trị. Tuy nhiên Shooting và game cho nữ giới sẽ bùng nổ

Q: Nếu là Startup nhỏ và không đủ kinh phí để phát triển mobile game trên cùng lúc cả 2 iOS và Android, thì mình lựa chọn 1 trong 2 dựa trên những yếu tố nào ạ?

A: Bạn có thể chọn các engine hỗ trợ multi-platform như Unity3D và Cocos2D-X nhé.

Q: Khi lập trình mobile game thì bước nào là quan trọng nhất ạ?

A: Tất cả đều quan trọng. Tuy nhiên hiện tại hầu hết các team đều yếu ở khâu game design

Q: Với tập khách hàng là nam giới tuổi từ 30-45 thì có nên dùng mobile ad thông qua mobile game để tiếp cận họ không anh? Em đang phân vân không biết nên tiếp cận tập khách hàng này bằng phương tiện nào vì budget cho quảng cáo của em cũng không quá lớn nên bị hạn chế về lựa chọn

A: Tập đó là trả tiền nhiều nhất đó bạn. Đặc biệt là các game chiến thuật

Q: Yếu tố nào là quan trọng nhất để một dự án mobile game thành công ạ?

A: Theo cá nhân mình nghĩ thì khoảng 40% là chất lượng sản phẩm, 60% là kinh doanh, marketing. Còn đi sâu hơn nữa thì chắc còn dài. Bạn có thể trao đổi trực tiếp với mình nhé

Q: Anh ơi không biết mình có thể Re-Marketing bằng Mobile app không ạ? Em đã tìm hiểu trên google nhưng không có tài liệu nào rõ ràng về việc này cả. Nếu được mong anh có thể cho em một vài gợi ý về những dự án Re-marketing bằng Mobile app mà anh cho là hay nhất được không ạ? Em cảm ơn anh nhiều.

A: Re-marketing là một khâu trong mkt. Nếu làm với app thì em có thể search chính những tài liệu của Google Play và sử dựng các tool của Google như adsense, Analytics

Q: theo em nghiên cứu thì ngành mobile game là một ngành cạnh tranh rất khốc liệt và ít doanh nghiệp nào có thể trụ lâu được. Vậy không biết anh có thể chia sẻ kinh nghiệm trong việc duy trì sự ổn định của dự án mobile game được không ạ?

A: Kinh nghiệm xương máu của mình là start nhỏ và chắc. Phải kiếm được những người cùng đam mê và có sự kiên trì. Một điều nữa là phải có chất lượng tốt dù làm game nhỏ.
Nên đi học các anh đi trước

AMA cảm ơn anh Giang Anh đã dành thời gian bận rộn cuối năm để tham gia chương trình. Đặc biệt, AMA và Topdev cũng cảm ơn các bạn đã luôn quan tâm và ủng hộ Topdev trong thời gian qua. Một năm Đinh Dậu với nhiều hứa hẹn, nhiều hy vọng đang đến gần, chúc các bạn dev sẽ gặt hái được nhiều thành công, có thật nhiều niềm vui trong cuộc sống!

Hướng đi đúng để apps kiếm tiền hiệu quả nhất

Hiện nay, ngành quảng cáo đang chứng kiến sự vươn lên mạnh mẽ của quảng cáo di động với dự báo Mobile Ads sẽ san bằng khoảng cách về doanh thu với quảng cáo trên Desktop trong vài năm tới. Xu hướng này cũng mở ra cơ hội kiếm tiền từ quảng cáo hết sức tiềm năng cho các nhà phát triển ứng dụng di động.
  • Vậy đâu là hướng đi đúng để apps của bạn kiếm tiền hiệu quả nhất?
  • Những chính sách gì có thể ảnh hưởng tới doanh thu, thậm chí có thể khiến apps của bạn bị “ban” trên Google Play?
  • Có những thủ thuật, giải pháp nào giúp tối ưu doanh thu quảng cáo di động hiệu quả?
Tất cả những câu hỏi trên sẽ được trả lời tại Workshop “BÍ QUYẾT ĐẺ TRỨNG VÀNG CHO ỨNG DỤNG TRONG NĂM ĐINH DẬU” do ADSOTA – Đối tác chiến lược của Google tại Việt Nam về mảng quảng cáo di động, phối hợp cùng đại diện Google tổ chức vào ngày 19.1.2017.
Nội dung trong chương trình do chính đại diện của Google và Adsota chia sẻ gồm:
  • Tổng kết ngành quảng cáo di động 2016
  • Dự đoán xu hướng nội dung, quảng cáo di động chủ đạo năm 2017
  • Các bí quyết nâng cao doanh thu quảng cáo từ ứng dụng di động của bạn
  • Giải đáp các thắc mắc của các Publishers về chính sách của Google nói chung và Google Play nói riêng.
Ngoài ra, các khách mời tham dự chương trình còn có cơ hội nhận được những phần quà đặc biệt hấp dẫn từ Adsota và Google.
Thông tin chi tiết về sự kiện:
  • Thời gian: 14:30 – 16:45 19/1/2017
  • Địa điểm: Tầng 10 tòa nhà LE Building, ngõ 71, Láng Hạ, quận Ba Đình, Hà Nội
Diễn giả trong chương trình:
  • Ms. Gaby Hien – Business Development Manager (OPG SEA, GOOGLE)
  • Ms. Pear Vijitra Natephisarnwanish : Google Strategist, Trust and Safety
  • Ms. Loan Nguyen: Project Manager Appota Ad Exchange
Cách thức đăng ký: Link đăng ký tham dự https://www.facebook.com/events/1839080686375859/
  • Bạn vui lòng đăng ký sớm trước ngày 17/1/2017. Ban tổ chức sẽ liên hệ với các bạn được lựa chọn trở thành khách mời trong chương trình
  • Mọi thông tin chi tiết vui lòng liên hệ hotline: 0947436045/ 0943190535 (Mr. Duy)

Đầu năm đàm đạo chuyện PHP & PHP7

Những ngày đầu năm 2017, ắt hẳn nhà nhà người người đều tất bật chuẩn bị cho những kế hoạch của năm mới và cả những dự định cho mùa Tết Đinh Dậu đang cận kề. Tuy bận rộn là thế nhưng hơn 100 dev vẫn không quên tề tựu tại sự kiện PHP & PHP7: Secrets Behind Optimization vào 12/01 vừa qua để đàm đạo, chia sẻ những giải pháp để tối ưu 1 trong những ngôn ngữ lập trình phổ biến nhất hiện nay.

Chủ đề đầu tiên bàn thảo chính là PHP Story, tổng hợp kinh nghiệm chinh chiến PHP hơn 6 năm của diễn giả Thảo Lê – Engineering Manager đến từ Harvey Nash. Ba câu hỏi được anh Thảo Lê tập trung giải quyết chính là:

  • What kind of language is it?
  • How do we implement PHP?
  • How do we control quality in PHP?

Trong đó, để kiểm tra chất lượng PHP, anh đã đề cập đến các cách thức như Automated Testing (Unit Tests, Test-Driven Development, Behavior-Driven Development; Automated Deployment (Shell scripts, Phing, Capistrano) cùng 1 số điểm tương quan giữa PHP & Node.js.

Xem ngay tin tuyển dụng PHP lương cao trên TopDev

Tiếp mạch chương trình, diễn giả Khánh Trần – Technology Evangelist của GEEK Up mang đến 1 chủ đề nhận được rất nhiều sự quan tâm của cộng đông dev thời gian qua là: Docker-Composer.

Đặc biệt, 2 mục mà BTC, khán giả và cả anh Khánh Trần tâm đắc nhất chính là: How to set-up a Phalcon PHP Project with Docker-Composer và 10 “mẹo” PHP cực hay không thể bỏ qua!

  • How to use volumes to store container’s data
  • Simplify application’s configuration by using links
  • Running development tasks with use on-off containers
  • Simplify docker-compose commands by using makelife
  • Mitigate remembering to many ports by using typicode/hotel
  • Experimental web scaling in development env.
  • Mount your docker.sock
  • How to config different environment
  • Avoid breaking change by using tagging image
  • Improve devops skill by learning from master

Phần Panel Discussion như càng tiếp thêm lửa cho sự kiện với sự xuất hiện của anh Lê Đức Huy trong vai trò moderator. Nguyên là trưởng phỏng sách điện tử tại tiki.vn với 6 năm kinh nghiệm phát triển sản phẩm hướng di động, gần đây nhất là sáng lập và xây dựng dự án Miki Ebook phát triển lên đến 500.000 thành viên đọc sách ebook, anh Huy đã góp phần “đẩy đưa” những câu hỏi về PHP & PHP7 của người tham gia đến 2 diễn giả 1 cách rất tài tình và cực kì hiệu quả.

Một lần nữa, Topdev Techtalk rất cảm ơn các bạn lập trình viên đã dành chút thời gian bận rộn đầu năm để đến tham dự và cùng nhau chia sẻ những kiến thức xoay quanh chủ đề của sự kiện. Hẹn gặp lại các bạn tại các sự kiện Topdev Techtalk tiếp theo ngay sau Tết Đinh Dậu, nhé!

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

11 cách tăng tốc nhanh cho WordPress bằng file wp-conig.php

Wordpress - Cách tối ưu web lên 99 điểm trên di động PageSpeed Insights

Việc tối ưu lại cơ sở dữ liệu luôn là một trong các việc quan trọng nhất cần phải làm khi một website đã có quá nhiều dữ liệu và có quá nhiều lượt truy cập. Bởi vì bạn biết rằng website càng có nhiều lượt truy cập thì website sẽ càng gửi nhiều truy vấn (query) về database để lấy dữ liệu ra (đa phần là truy vấn SELECT). Mà đã nhiều truy vấn rồi mà dữ liệu lại lớn, chưa được sắp xếp gọn gàng thì nó lại càng mất thêm thời gian để xử lý các truy vấn đó.

Ngoài việc dọn dẹp database, chúng ta còn một cách khác nhưng cũng rất quan trọng đó là tối ưu lại bảng wp_options của database. Bảng này sẽ chứa toàn bộ các thiết lập bên trong website, bao gồm các thiết lập theme và plugin. Điều đó có nghĩa là bạn đã từng cài nhiều plugin và theme vào website thì bảng này sẽ rất nặng mặc dù bạn đã tắt các plugin hoặc theme đó đi vì đa phần các plugin không hỗ trợ “làm sạch” chiến trường khi ta tắt đi để có thể sử dụng lại sau này.

Xem ngay tin tuyển dụng PHP lương cao trên TopDev

wp-config.php là một tập tin PHP nằm trong thư mục chứa website WordPress của bạn, bạn có thể tìm thấy file wp-config.php theo như danh sách như hình 1 bên dưới đây :

TopDev Techtalk #54: PHP & PHP7 – Secrets behind Optimization

*Hồ Chí Minh: 18h00 – 21h00 thứ 5, ngày 12/01/2017

9

Đây là tập tin chứa các thông tin cấu hình cần thiết để WordPress hoạt động bao gồm các thông tin như : thông tin đăng nhập MySQL, Authentication Keys,…

Các bạn cần lưu ý là các đoạn mã thiết lập bên dưới cần phải thêm vào phía trước dòng “require_once(ABSPATH . ‘wp-settings.php’);” trong file wp-config.php , nếu bạn thêm sau dòng này có thể gây ra lỗi website.

Debug truy vấn

Trước tiên, chúng ta cần nên xem trực tiếp các query có trên website và thời gian thực thi của nó để coi có query của plugin nào chiếm nhiều thời gian không. Có một cách làm việc này đó là sử dụng plugin Query Monitor.

Nhưng trước khi cài đặt nó, bạn bật debug trong wp-config.php lên.

1
define(‘WP_DEBUG’, true);

Sau đó ở mỗi trang, bạn sẽ xem được query của nó bằng cách ấn vào nút xem debug ở Admin Bar.

query-monitor-adminbarBạn ấn vào và chọn Queries để xem các truy vấn nhé. Bây giờ bạn có thể biết trên trang đó có bao nhiêu truy vấn, mỗi truy vấn tốn bao nhiêu thời gian.

query-monitor-querytime

Nếu bạn thấy mình có quá nhiều truy vấn gửi vào table wp_posts thì hãy:

  • Hạn chế sử dụng truy vấn để lấy bài viết ra, bao gồm các widget. Các theme tin tức thường có rất nhiều query kiểu thế này.
  • Hạn chế số lượng bài viết hiển thị trên mỗi trang.
  • Ngoài ra bạn cũng có thể sẽ thấy truy vấn ở một vài plugin. Nếu bạn thấy plugin đó không cần thiết thì tắt đi.

Kế tiếp là bạn ấn vào menu Debug, chọn Hooks và bạn sẽ thấy có bao nhiêu thành phần được load ra như có bao nhiêu theme được kích hoạt, bao nhiêu hook ở widget, theme sử dụng hook nào để thực thi,…và nếu hạn chế được càng nhiều thì càng tốt.

query-monitor-hooks

Ngoài ra bạn có thể xem thêm phần PHP Errors để xem có lỗi nào trong PHP không, nó sẽ cho bạn biết lỗi đó là gì, nằm ở file nào đoạn số bao nhiêu trong code để bạn biết mà sửa.

Tối ưu bảng wp_options

Cột autoload trong bảng wp_options nghĩa là để nó xác định xem tuỳ chọn đó có được tải mặc định tự động ra bên ngoài hay không. Điều đó có nghĩa là mặc dù các plugin của bạn không dùng nữa nhưng các thiết lập trong database vẫn còn thì nó vẫn là autoload, đây là lý do sốt một khiến tốc độ truy cập website bị chậm đi.

Trong bài này có sử dụng truy vấn SQL. Để chạy truy vấn SQL, bạn vào phpMyAdmin -> chọn database cần làm việc và chọn tab SQL. Hoặc nếu bạn không có phpMyAdmin thì đăng nhập vào MySQL Server rồi gõ USE tên_database để chọn database.

Trước hết, chúng ta kiểm tra xem bảng wp_options có bao nhiêu hàng.

1
explain SELECT option_name, option_value FROM wp_options WHERE autoload = ‘yes’
1
2
3
4
5
+———+——————–+———————–+———+———————–+———+————–+———+———+——————–+
| id   | select_type | table         | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+———+——————–+———————–+———+———————–+———+————–+———+———+——————–+
|    1 | SIMPLE      | wp_options | ALL  | NULL          | NULL | NULL    | NULL |  808 | Using where |
+———+——————–+———————–+———+———————–+———+————–+———+———+——————–+

Như các bạn thấy là chúng ta có thể thấy được mình đang có 808 hàng trong bảng wp_options.

Bây giờ hãy thử thêm INDEX cho cột autoload để xem sự khác biệt.

1
ALTER TABLE `wp_options` ADD INDEX (`autoload`);

Bây giờ bạn chạy lại truy vấn ở trên xem nó đã có giảm số hàng xuống chưa, đồng thời cột Extra của mình nó sẽ để là Using index condition.

1
2
3
4
5
+———+——————–+———————–+———+———————–+—————+————–+———–+———+———————————–+
| id   | select_type | table         | type | possible_keys | key      | key_len | ref   | rows | Extra                 |
+———+——————–+———————–+———+———————–+—————+————–+———–+———+———————————–+
|    1 | SIMPLE      | wp_options | ref  | autoload      | autoload | 82      | const |  762 | Using index condition |
+———+——————–+———————–+———+———————–+—————+————–+———–+———+———————————–+

Ngoài ra thì tốc độ truy vấn của mình cũng giảm đáng kể.

Trước đó:

query-monitor-adminbar

Sau khi thêm INDEX

query-monitor-after-index

Thế thì tại sao sử dụng INDEX trong MySQL lại giúp bạn giảm thời gian gửi truy vấn?

Bạn hãy tưởng tượng rằng, INDEX giống như bạn đánh số cho từng trang sách vậy. Khi bạn cần tìm một cái gì đó thì bạn chỉ cần giở ra đúng số trang mà bạn cần tìm thay vì ngồi mò từng trang, phải không? INDEX trong MySQL cũng thế, nó sẽ giúp cho các truy vấn WHERE tìm kiếm dữ liệu nhanh hơn để lấy ra bên ngoài.

Nếu bạn muốn thì bạn có thể thêm INDEX cho cột post_id và meta_key trong bảng wp_postmeta.

1
2
ALTER TABLE `wp_postmeta` ADD INDEX (`meta_key`);
ALTER TABLE `wp_postmeta` ADD INDEX (`meta_key`);

Xoá bớt các options không sử dụng

Như mình nói ở trên, mặc định table có cột autoload mà nếu hàng nào có giá trị là yes thì nó sẽ mặc định được gửi ra toàn bộ trong khi WordPress tải website của bạn. Nếu bạn dùng website đã lâu, đã từng sử dụng qua nhiều plugin nay không dùng nữa thì nên xoá đi các tuỳ chọn của nó trong bảng wp_options. Bạn có thể browse bảng này và xoá đi các tuỳ chọn giống như mình làm ở dưới, cẩn thận với các tuỳ chọn mặc định của WordPress (ở các trang đầu tiên).

Xoá các options không sử dụng nữa.

Cấu hình Post Revisions, Auto Save

Post Revisions cũng là bài viết được lưu trong bảng “wp_posts” của database, tuy nhiên nó chỉ thể hiện trong trang quản lý bài viết của /wp-admin/ mà không hiển thị ra trang ngoài.

Mỗi khi bạn soạn thảo bài viết trên WordPress thì WordPress sẽ tự động lưu lại các phiên bản của bài viết đó để bạn so sánh các thay đổi nội dung so với trước kia.

Điều này có thể cần thiết đối với nhu cầu của 1 số người, tuy nhiên nếu bạn không cấu hình Post Revisions cho WordPress thì sẽ có vô số bản nháp không cần thiết khi số lượng bài viết của bạn ngày càng nhiều, điều này sẽ có thể làm chậm website của bạn do việc xử lý database ngày càng nhiều.

Để khắc phục điều này, bạn có thể thêm các dòng sau

1
define (‘WP_POST_REVISIONS’, 6); /* Giới hạn mỗi bài viết chỉ có tối đa 6 Post Revisions */
1
define (‘WP_POST_REVISIONS’, false); /* Vô hiệu Post Revisions */

Theo mặc định thì khoảng 60 giây thì WordPress sẽ tự động tạo một phiên bản Post Revisions khi bạn đang soạn thảo bài viết, nếu bạn muốn tăng khoảng thời gian này lên thì có thể thêm vào dòng sau :

1
define (‘AUTOSAVE_INTERVAL’, 300); /* Cứ mỗi 300 giây thì tạo Post Revisions, mặc định của WordPress là 60 giây */

Cấu hình dọn dẹp Trash (thùng rác)

Khi bạn xoá post, page,… thì WordPress sẽ không xoá ngay mà tạm thời di chuyển chúng vào Trash để bạn có thể khôi phục lại nếu muốn. Theo mặc định thì WordPress sẽ xoá tất cả các đối tượng nằm trong Trash nếu sau 30 ngày bạn không khôi phục nó (tính từ lúc di chuyển đối tượng vào Trash). Nếu bạn muốn thay đổi thời gian mặc định này, bạn có thể thêm dòng sau

1
define (‘EMPTY_TRASH_DAYS’, 7); /* Xoá tất cả các đối tượng trong Trash có thời gian lớn hơn 7 ngày */
1
define (‘EMPTY_TRASH_DAYS’, 0); /* Vô hiệu Trash.Có nghĩa là khi bạn xoá đối tượng thì WordPress sẽ không lưu trữ trong Trash nữa mà xoá luôn, và bạn không thể khôi phục lại dữ liệu được nữa. */

Tăng giới hạn bộ nhớ PHP cho WordPress

Theo mặc định thì WordPress sẽ thiết lập giới hạn bộ nhớ (RAM Memory) là 32 MB (Megabytes). Nếu nhà cung cấp Host bạn đang sử dụng cho phép bạn sử dụng nhiều hơn 32 MB RAM thì hãy thêm dòng sau

1
define (‘WP_MEMORY_LIMIT’, ‘128M’); /* Tăng giới hạn bộ nhớ cho WordPress lên 128 Megabytes */

Lưu ý nếu bạn thiết lập thông số này cao hơn giới hạn cho phép của Host hoặc VPS thì sẽ không có tác dụng.

Thiết lập này sẽ rất hữu ích khi website của bạn phải xử lý nhiều dữ liệu như database lớn, sử dụng nhiều plugins,…

Automatic Database Optimizing

Từ phiên bản 2.9 trở đi thì WordPress cung cấp tính năng tối ưu và sửa chữa database (Optimizing & Repair Database). Đây là tính năng đặc biệt hữu ích khi WordPress không thể truy vấn table nào đó trong database do table đó bị crash. Để kích hoạt tính năng này, bạn thêm dòng sau

1
define (‘WP_ALLOW_REPAIR’, true); /* Kích hoạt Optimizing & Repair Database */

Sau khi kích hoạt tính năng, bạn truy cập vào url {$your_site}/wp-admin/maint/repair.php để thực hiện

Lưu ý : Bất kỳ ai cũng có thể sử dụng tính năng trên bằng cách truy cập vào url mà không cần phải đăng nhập, do đó sau khi đã fix database xong bạn nên vô hiệu tính năng này bằng cách sửa lại là define( ‘WP_ALLOW_REPAIR’, false );

Plugin & Theme Editor

Theo mặc định thì WordPress cho phép bạn chỉnh sửa các file *.php, *.js,… của Theme hoặc Plugin ngay trong trang quản trị của WordPress. Điều này là không cần thiết và không nên sử dụng, nếu bạn cần chỉnh sửa các file .php hoặc bất kỳ file này trong mã nguồn website thì chỉ nên dùng các chương trình IDE như PhpStorm, NetBeans, Notepad++, Sublime Text,… rồi upload lên host bằng các chương trình FTP clients như FileZilla, WinSCP,…

Để vô hiệu tính năng Plugin & Theme Editor của WordPress, bạn thêm dòng sau vào file wp-config.php

1
define( ‘DISALLOW_FILE_EDIT’, true ); /* Vô hiệu tính năng chỉnh sửa file của Plugin & Theme tại trang quản trị của WordPress */

Sử dụng SSL (https) khi đăng nhập

Nếu bạn muốn Username & Password của người dùng an toàn hơn thì có thể cấu hình WordPress bắt buộc sử dụng SSL khi đăng nhập

1
define( ‘FORCE_SSL_LOGIN’, true ); /* Kích hoạt tính năng bắt buộc sử dụng SSL khi người dùng đăng nhập tài khoản WordPress */

Ngoài ra bạn cũng có thể cấu hình cho WordPress bắt buộc sử dụng SSL khi truy cập vào trang quản trị (/wp-admin/*)

1
define( ‘FORCE_SSL_ADMIN’, true ); /* Kích hoạt tính năng bắt buộc sử dụng SSL khi truy cập vào các trang quản trị của WordPress /wp-admin/ */

Auto Update Core WordPress

Nếu bạn muốn Core WordPress (mã nguồn chính của WordPress, không phải Theme hay Plugin) luôn tự động cập nhật những phiên bản mới nhất của WordPress (từ trang https://wordpress.org/ ) thì thêm dòng sau :

Debug WordPress – Tìm lỗi website WordPress

Nếu bạn là Developer thì việc tìm các lỗi có trong website WordPress là việc nên làm để cải thiện hiệu năng và các lỗi của website.

Tuy nhiên việc hiển thị các lỗi của website không nên thực hiện trên website chính, bạn chỉ nên kích hoạt tính năng hiển thị lỗi của Web trên local hoặc phiên bản test.

Để kích hoạt trạng thái debug của WordPress trên phiên bản test, bạn sử dụng :

1
2
3
4
5
@ini_set( ‘log_errors’, ‘Off’ );
@ini_set( ‘display_errors’, ‘On’ );
define( ‘WP_DEBUG’, true ); /* Kích hoạt trạng thái Debug WordPress */
define( ‘WP_DEBUG_LOG’, false );
define( ‘WP_DEBUG_DISPLAY’, true );

Còn trên phiên bản public của website bạn nên sử dụng :

1
2
3
4
5
@ini_set( ‘log_errors’, ‘On’ );
@ini_set( ‘display_errors’, ‘Off’ );
define( ‘WP_DEBUG’, false ); /* Kích hoạt trạng thái Debug WordPress */
define( ‘WP_DEBUG_LOG’, true );
define( ‘WP_DEBUG_DISPLAY’, false );

Nếu bạn muốn chỉnh sửa các file JavaScript (*.js) hoặc Cascading Style Sheets (*.css) nằm trong các thư mục wp-includes/js, wp-includes/css, wp-admin/js, và wp-admin/css thì có thể sử dụng :

1
define( ‘SCRIPT_DEBUG’, true ); /* Kích hoạt trạng thái Debug .js & .css WordPress */

define( ‘SCRIPT_DEBUG’, true ); sẽ nạp các file chưa nén (uncompressed) thay vì các file đã làm nhỏ gọn (minify) như *.min.css và *.min.js chứa trong các thư mục trên.

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

10 tuyệt kĩ từ trang web nhanh nhất thế giới (phần 2)

#6 Inline

Mỗi lần ngồi suy nghĩ liệu inline CSS có đáng hay không thì tôi lại đi đến kết luận rằng.. tùy tình hình.

Nếu bạn là trang facebook.com và 99,9% lượt page views là return visitors, thì hãy có 1 file CSS riêng và lưu trữ nó. Nếu nhưng trang của bạn không cần nhiều lượt repeat visit thì bạn có thể muốn inline CSS và lưu 1 network request.

Nếu bạn muốn “tự tạo đau khổ” cho mình thì có thể thử để inline ở vào nửa trên của giao diện và phần còn lại sẽ tải trong 1 file CSS riêng.

Quy tắc riêng của tôi là: nếu bạn có thể tích hợp CSS vào HTML và dung lượng ở mức 14KB thì hãy làm đi (Và tại sao lại là con số 14 thì Tìm hiểu tại đây)

CSS + HTML (đã tinh giảm) của tôi là 3.5 KB –  nhờ vậy mọi thứ đều trở nhanh nhẹ hơn

#7 Preload, sau đó là load

Chúng tôi nghĩ <scripts>  nên ở phần cuối của <body>. Khi tôi nhận ra mọi người nói <scripts>  là footer, header và body. Thì tôi đã được khai sáng.

[5 phút sau…]

Thỉnh thoảng, tôi nghĩ mình là người dễ bị xao nhãng.

Tôi đang làm gì ở đây?

Ah đúng rồi, 1 bài blog về tốc độ website.

Một mô hình thường thấy trong React với SSR (Server Side Rendering) là:

  1. Trong server, generate HTML bằng cách gửi vài dữ liệu vào component để render
  2. Write dữ liệu đó vào HTML với lệnh như window.APP_DATA = data;
  3. Gửi cả DOM (dựa trên dữ liệu đó) đã được render và dữ liệu trở lại payload của HTML
  4. Trong browser, chạy lệnh window.APP_DATA và kết hợp ứng dụng với nó

Cách thức này có chút lãng phí nhưng thực sự không ảnh hưởng nhiều vì HTML sẽ được render trong cùng 1 thời gian, chỉ có JavaScript bị delay 1 chút. Nếu trang web của bạn chạy mượt trước khi Javascript tải thì chả ảnh hưởng gì.

Dưới đây là những gì tôi muốn nó diễn ra:

  • Bắt đầu tải dữ liệu ngay khi có thể (mà không chặn HTML)
  • Bắt đầu tải JavaScript của ứng dụng ngay khi có thể (mà không chặn HTML)
  • Khi cả script và dữ liệu đã được tải, và HTML đã được parse, script sẽ giúp page sống động hơn.

Tôi có thể thực hiện tất cả các thao tác trong JavaScript để quy trình này chạy tốt nhưng tôi có 1 giải pháp tốt hơn. Đúng là nó hiệu quả đấy nhưng tôi lại có cảm giác khó chịu là mình đang làm cái gì đó khá ngu ngốc.

  • Trong <head> tôi có 1 <link rel="preload" … > dành cho cả JSON và JS (tôi cũng có prefetch dành cho các browsers chưa hỗ trợ preload)
  • Ở phần cuối body, tôi tải ứng dụng JS trong tag <script>
  • Khi JS chạy, fetch() sẽ đẩy file JSON ra và .then() sẽ khởi động render cho ứng dụng React

Kết quả tương tự như sau:

Khi asset bất kì gặp vấn đề, các calls tải asset khác sẽ không mất khỏi network. Các network calls sẽ trông như thế này:

Vì vậy, nếu tôi không lầm, tôi không thấy có lý do mà mình không preload mọi thứ ở đầu trang.

Câu chuyện bên lề: tôi đã muốn mã hóa tên file JSON để có thể lưu trong cache mãi mãi. Tôi đã tự phá luật và tiến tới npm luôn. Tôi loay hoay 1 hồi trước khi nhận ra thư viện crypto được build ngay vào Node có thể qua mặt được mà không cần tốn quá nhiều sức.

1
const fileHash = crypto.createHash(‘md5’).update(fileContents).digest(‘hex’);

#8 Tưởng thưởng hành vi tốt

Những users đang xài Chrome, Edge và Firefox là những người tốt bụng. Tôi đã từng có các production sites gửi đi những polyfills 30KB hàng triệu lần đến các users này và khiến tôi cảm thấy “lầy lụa” không chịu được.

Với dự án này, tôi chỉ tạo 1 file polyfill riêng và tải nó nếu cần. Trong HTML của tôi, tôi có 1 thứ như thế này:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
var scripts = [‘app.a700a9a3e91a84de5dc0.js’]; // script for all users
var newBrowser = (
  ‘fetch’ in window &&
  ‘Promise’ in window &&
  ‘assign’ in Object &&
  ‘keys’ in Object
);
if (!newBrowser) {
  scripts.unshift(‘polyfills.a700a9a3e91a84de5dc0.js’); // script for the less fortunate
}
scripts.forEach(function(src) {
  var scriptEl = document.createElement(‘script’);
  scriptEl.src = src;
  scriptEl.async = false;
  document.head.appendChild(scriptEl);
});

Để generate 2 gói này với webpack rất đơn giản.

1
2
3
4
5
6
7
8
9
config.entry = {
  app: [
    path.resolve(__dirname, `../app/client/client.jsx`),
  ],
  polyfills: [
    `babel–polyfill`,
    `whatwg–fetch`,
  ],
};

Nhờ đó, kích cỡ build của tôi giảm từ 90KB xuống 60KB.

Bạn có nhận ra mãi cho đến bây giờ tôi vẫn chưa đề cập đến kích cỡ tải? Là vì kích thước file không có liên quan.

Nếu bạn đang tính toán “thời gian tương tác” của trang web thì bạn đã tính đến kích cỡ file; cả thời gian tải và thời gian parse. Nếu bạn nghe ai đó nói là họ đã giảm file CSS đi 5KB thì hãy hỏi con số đó theo milliseconds.

Dưới đây là biểu đồ về kích thước file của ứng dụng mà tôi đã lập trình và React với tất cả các polyfills trước và sau khi có Preact.

Nếu bạn muốn làm rõ và điều chỉnh các polyfills cho mỗi hệ điều hành, polyfill.io đã làm điều đó. Dưới đây là 1 số lý do sẽ khiến bạn “mê mệt” polyfill:

  • Ở bất kì điểm nào, nếu ai đó làm gì đó sai, toàn bộ site có thể bị gãy. Và nó có thể gãy trong 1 hệ điều hành mà bạn không dùng nó nhiều. Có thể trang của bạn hiện đã hỏng tại 1 vài hệ điều hành. Làm thế nào bạn biết được?
  • Polyfill cực nhanh, nhưng đó là 1 blocking script ở phần đầu của trang web

Vì thế tôi chỉ đơn giản phục vụ cái package nhỏ nhất cho những ai đang sử dụng các hệ điều hành tốt và tất cả những người khác có thể đạt được mức 30KB.

(Tôi nhận ra mình khá xấu xa khi loại Safari ra – Safari 10 có hỗ trợ JavaScript – nhưng không có fetch tôi sợ chúng sẽ không tạo danh sách các browsers hiện đại được)

#9 Các service workers

Tôi đã trì hoãn nghiên cứu các service workers trong 1 thời gian dài. Khi tôi quyết định tạo trang web nhanh nhất hành tinh này, tôi nghĩ lý do đến từ thời gian.

5 tiếng sau, tôi hoàn thành. Và 4 giờ, 35 phút là để phạm lỗi lầm.

Dưới đây là cách thức vận hành:

  • Kết quả của build script mà tôi làm là 1 chùm các files trong danh mục tên là public (gồm index.html của tôi)
  • Sau đó tôi gọi thư viện sw-precache của Google để tạo file service worker sẽ cache mỗi file trong danh mục đó và cho phép trang của tôi làm việc offline được
  • Code clien-side đăng kí service worker mà sw-precacheđã tạo

Có 16 dòng code bắt buộc phải có.

13 dòng trong build script (tất cả các code của tôi nằm trong /public)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
swPrecache.write(path.resolve(__dirname, `../public/service–worker.js`), {
  cacheId: `know–it–all`,
  filename: `service–worker.js`,
  stripPrefix: `public/`,
  staticFileGlobs: [
    `public/app.*.js`, // don’t include the polyfills version
    `public/*.{html,ico,json,png}`,
  ],
  dontCacheBustUrlsMatching: [
    /\.(js|json)$/, // I’m cache busting js and json files myself
  ],
  skipWaiting: true,
}, (err) => {
  if (err) {
    reject(err);
  } else {
    resolve();
  }
});

(Tôi không tải polyfill lên cache vì các browsers cần polyfills không có service workers)

Sau đó trong 3 dòng của client – nơi tôi cần tải service worker:

1
2
3
if (`serviceWorker` in navigator) {
  navigator.serviceWorker.register(`service–worker.js`);
}

Một khi bạn đã tải trang 1 lần, nó sẽ vận hành mà không cần network. Nếu có sẵn phiên bản mới, nó sẽ cài đặt trong background nếu bạn đang online và khi refresh bạn sẽ có phiên bản mới.

Tương lai nằm ở đây. Hãy sử dụng service workers.  HÃY DÙNG NÓ.

Không may là 50% số người đọc được điều này trên Safari/iOS vào thời điểm này lại không có service workers. Apple chắc chắn đang nghiên cứu nhưng trái lại, nếu bạn muốn sở hữu Internet nhanh thì hãy mua 1 chiếc Android.

#10 Computers có những fonts đẹp

Web fonts là “nỗi đau”, là những thứ tốn thời gian. Nhưng nếu có được web fonts đẹp thì cũng tốt.

Tôi nhận ra 4 phần sau đây:

  • macOS có các font đẹp
  • Android có các font đẹp
  • Windows có các font đẹp
  • iOS có các font đẹp

Vậy tại sao lại không dùng chúng? Tôi đã chọn Calibri Light, Roboto và Helvetica Neue. Nếu bạn cần 1 font giống nhau, tùy chỉnh trên tất cả các thiết bị thì mọi thứ đã đi quá xa rồi và bạn không còn hy vọng nào đâu.

Vì vậy, đây là lý do tôi nghĩ mỗi website đơn nên có nền tảng typography.

Text đẹp, không request network.

1
2
3
4
5
6
7
body {
    color: #212121;
    font–family: “Helvetica Neue”, “Calibri Light”, Roboto, sans–serif;
    –webkit–font–smoothing: antialiased;
    –moz–osx–font–smoothing: grayscale;
    letter–spacing: 0.02em;
}

Chính sửa: Ban đầu tôi có text-rendering: optimizeLegibility. Một ai đó đã nói trong comment rằng đây là 1 vấn đề liên quan đến hiệu suất.

Sau đó, tuy có chút ngần ngại nhưng tôi đã chạy vài trials và xem thử có khác biệt nào không.

Cảm ơn, Jacob Groß!

#11 Không bao giờ từ bỏ

app.js của tôi vào khoảng 28KB và tôi đã tự hỏi nó được tạo ra như thế nào. Sau khi fiddle, tôi nhận ra ImmutableJS chiếm 19KB. Một thư viện nhỏ mà đã chiếm hơn 2/3 toàn bộ kích cỡ app!

Tôi chỉ sử dụng 1 tập hợp rất nhỏ các tính năng của ImmutableJS và nhận ra tôi  có thể tự mình sao chép lại. Sau đó vài giờ, website có thể hoạt động mà không cần ImmutableJS và độ tăng trưởng về hiệu suất tốt hơn bất cứ thay đổi nào mà tôi từng thực hiện: giảm 60% thời gian tải.

Lý do không phải vì ImmutableJS “chậm”. Nó có thể chiếm 19KB của Javascript bất kì. Vấn đề đến từ thời gian để parse.

Tôi đã xử lý thành công 14% thời gian “first view” (và dưới 400 đối với “repeat view”) bằng cách loại immutable và không chuyển đổi file big data client-side đó.

Xây dựng 1 trang web nhanh cũng như nuôi thú cưng, đòi hỏi sự kiên nhẫn và nhất quán (cả về thời gian và từ những người liên quan). Bạn có thể giữ mọi thứ rất sạch sẽ, gọn gàng nhưng nếu bạn cẩu thả, sử dụng 1 thư viện 11KB để format date và để đống phân thú cưng đó trên giường, bạn sẽ gặp nhiều khó khăn để dọn dẹp sạch sẽ.

Nguồn: Techtalk via Hackernoon

10 tuyệt kĩ từ trang web nhanh nhất thế giới (phần 1)

Bài viết này phân tích về những kĩ thuật tăng hiệu suất của 1 trang web, vì thế hy vọng bạn sẽ không phiền nếu trang web được nói đến vẫn chưa hoàn thiện lắm.

Nhưng bạn cần có 1 cái gì đó để click vào và đánh giá xem ý kiến của tôi có giá trị hay không. Bạn có thể tham khảo tại đây: https://knowitall-9a92e.firebaseapp.com/

Hy vọng trang web sẽ mở nhanh để tôi có được chút danh tiếng ban đầu.

Nếu bạn đang tự hỏi tại sao tôi lại đang viết về trang web này khi nó vẫn chưa hoàn thiện.. là vì những góp ý. Hiệu suất là tập hợp chuỗi mẹo và các cách suy nghĩ về mọi việc. Vì vậy tôi sẽ rất vui nếu bạn có thứ gì đó hay ho để góp ý cho website bằng cách truy cập source tại đây.

Khi chế độ Strict Mode được bật, nếu tham số truyền vào là string, trong khi chúng

Hãy nói về tốc độ

Bạn có thể tham khảo biểu đồ sau.

Liệu bạn có muốn website được cách điệu 1 cách không cần thiết?

Đây có phải là cuộc chiến công bằng?

Không. Những trang web trên có chức năng hoàn toàn khác biệt, nên sẽ rất vô lý nếu chúng tải cùng 1 thời gian. Nhưng những trang web trên đã rất nỗ lực để cải thiện hiệu suất và đạt mục tiêu tạo được 1 trang web tải nhanh hơn trang homepage của Google.

Tại sao trông chúng lại không ấn tượng

Nếu bạn vô tình cảm thấy ấn tượng, tôi khuyên bạn nên bình tĩnh 1 chút. Tôi không phải read từ 1 database để sản xuất content hay bắt bạn đăng nhập hay tải 7 loại ads từ bên thứ 3 – mỗi cái thực hiện 40 redirects trước khi chúng tải được 1 file flash. Tôi thậm chí còn không dùng đến bất kì hình ảnh nào nữa cơ. Và page count = 1.

Tại sao chúng lại gây ấn tượng

Trước khi trang web được tải và sẵn sàng chạy, tôi đang tải về và parse 1 file JSON 75.000 line. Nếu được expanded, sẽ cho ra kết quả là 9.986 hàng.

Và tôi đang xài 1 thư viện. Các thư viện đều chậm (bất kể tốc độ nhanh chóng mà chúng đang có).

Dưới đây là 10 bài học mà tôi có được trong suốt hành trình đã qua. 7 trong số chúng khá hữu hiệu ở thời điểm cách đây 2 tháng, 3 cái còn lại thì khá… rác rưởi.

Tất nhiên, tôi sẽ không nói bạn đâu là 3 cái đó.

#1 Đừng cố gắng tạo 1 trang web chậm

Tôi nghe được điều này từ 1 người không phải là lập trình viên web. “Tôi đang lướt trang mercedes.com và nó quá chậm, làm thế nào mà họ có thể tạo được 1 trang chậm như thế”

Tôi cho rằng việc tạo nên 1 trang web chậm thì chẳng khó khăn gì, tất cả những gì bạn phải làm là cố gắng không phải tạo 1 trang web nhanh.

Đây là tin tức tốt, vì nếu tất cả những gì bạn làm là cố gắng tạo trang web nhanh, bạn sẽ tự động có được 1 trang web nhanh hơn.

Đối với trang web này, trong mỗi bước, tôi lại dành ra vài thời điểm để nghĩ về mức độ ảnh hướng đến hiệu suất trong những gì mình đang làm. Với mỗi thư viện mà tôi đã sử dụng trong ứng dụng này, tôi đo đạc lại 3 chỉ số này, trước và sau:

  • first meaningful paint
  • thời gian interactive
  • expanding 1 DOM node

Nếu 1 thư viện có ảnh hưởng tiêu cực, hãy bỏ nó ra. Ví dụ, tôi đã từng dùng lodash deepClone trong đối tượng JS có 75.000 prop. Sau khi chuyển sang Immutable.js thì mọi chuyện đã hoàn toàn khác.

Tôi đang sử dụng React, và thỉnh thoảng dùng đến thư viện classnames. Sau đó tôi ước lượng lại bằng số liệu lần nữa và… không có gì khác biệt.

Mỗi lần bạn nhập 1 thư viện mới hoặc tạo nên 1 sự thay đổi lớn để nâng cao hiệu suất, bạn chỉ tốn có 5 phút mà thôi..

#2 Do mobile first

Có 2 chiến lược “mobile first” ở đây.

Chiến lược đầu tiên (tôi vẫn làm mãi cho đến dự án này), tôi đã ngồi tại monitor 27″ với 1 style website imax trước mặt, 1 fan-cooled CPU “quái vật” và hàng tá RAM thực hiện mọi mệnh lệnh mà tôi đặt ra.

Sau đó, tôi viết CSS media queries với min-width và nói với bạn bè của mình rằng, tôi đang thực hiện chiến lược “mobile first”

Đối với dự án này, tôi thực sự đã làm mobile first. Đó là, phát triển trang web chạy trên thiết bị di động. Tôi làm điều này trước, và khi đã hài lòng về UI và hiệu suất, tôi tiến hành nó trên máy tính lớn.

Bạn sẽ bất ngờ khi nhận ra không hề khó để có 1 trang web nhanh chạy trên 1 machine nhanh!

(Câu chuyện không đơn giản như thế, tôi đã bắt đầu dự án với những thói quen cũ không tốt, sau đó nửa đường thì dần trưởng thành, học hỏi được nhiều hơn và đã mặc định là bắt đầu lập trình trên mobile)

Bây giờ, việc trang web chỉ chạy trên 1 chiếc điện thoại là 1 giấc mơ, nhưng khi so sánh các chỉ số về hiệu suất sau nhiều ngày và nhiều tuần, bạn muốn 1 benchmark nhất quán. Nếu bạn xem video này, bạn sẽ biết rằng testing trên 1 thiết bị mobile thực tế không hề chuẩn mực chút nào. Bạn cũng sẽ biết tại sao tôi lại nói 1 cái CPU – được – quạt – mát sẽ đóng vai trò rất quan trọng.

Khi bạn thực hiện benchmarking, bạn nên sử dụng Chrome DevTools and throttle CPU và network của bạn. Tôi sử dụng CPU giảm tốc 10x lần và để network ở chế độ “Good 3G”. Tôi biết nó có thể không chậm bằng chiếc điện thoại trung bình nhưng tôi không muốn bị làm phiền với các vấn đề về tốc độ.

Bởi vì không dừng lại ở 1 cái gật đầu và lời đồng tình rằng đây là ý tưởng tốt mà nó còn phải là 1 ý tưởng thực sự có giá trị.

 

Đây là 1 thứ khiến tôi khá ngạc nhiên: chúng thực sự rất ồn.

Đây là thứ khác khiến tôi ngạc nhiên: tôi có 1 CPU i7 lớn mà tôi sử dụng để làm hầu hết mọi việc và 1 Pixel XL hoàn toàn mới: chiếc điện thoại nhanh nhất trên thế giới. Theo bạn thì hiệu suất điện thoại của tôi sẽ ra sao? 80% desktop? 60%? Hay có ai đoán là trên 10% không?

Sai rồi! Chỉ có 10% mà thôi. Nếu tôi làm chậm i7 lại khoảng 10 lần, nó cũng bằng tốc độ với chiếc điện thoại 1400USD trước mặt tôi.

Đó là sự khác biệt giữa cái click 20ms và click 200ms. Hoặc 1 khung hình tốn 16ms để render với 160ms.

#3 Trở thành 1 kẻ rành về benchmark

Một khi đã nhận được nhận xét tốt trên 1 trang benchmarking, tôi lại càng muốn tiến hành với tất cả các trang benchmarking để được nghe lời khen nhiều hơn.

Khi tôi chạy lighthouse trên trang web, tôi chỉ nhận được 97 điểm. 3 điểm còn lại của tôi đã mất đi đâu rồi!!!

Như tôi đã thấy, tôi được nhận xét là tôi có 1 input latency 285ms. Nếu nó thực sự đúng, thì sẽ là chuyện khá kinh hãi. Nhưng tôi biết nó chỉ 20ms thôi.

Vậy thì nhân viên của lighthouse chẳng qua là những kẻ ngu ngốc.

Vì vậy, tôi ngập ngừng thừa nhận với bản thân rằng có lẽ tôi nên nghiên cứu điều này, dù thực tế cho thấy tôi đã hoàn toàn đúng và 1 thuật toán được viết bởi Google đã sai rõ ràng.

Nó nhắc tôi phải bắt đầu lại toàn bộ quá trình giảm tốc CPU, và chắc chắn, thời gian phản hồi mà tôi nghĩ là nhất thời đã chậm đến 200+ ms.

Vì vậy tôi đã làm vài profiling và hầu hết thời gian là dành cho React. Tôi đã thực hiện hầu hết các practices tốt nhất liên quan đến hiệu suất React, và không có “updates nào bị lãng phí”.

Tôi thậm chí còn memoize (memoization là một kỹ thuật tối ưu, nhằm tăng tốc chương trình bằng cách lưu trữ kết quả của các câu gọi function và trả về các kết quả này khi function được gọi với cùng input đã gọi) các components có số lượng phần tử thấp (low-cardinality)

Bạn cũng nên biết tôi là 1 fan bự của React. Nhưng hiệu suất đã đánh bật lòng trung thành đó.

Đầu tiên, tôi đã thử preact-compat. Nó tốn mất 15 phút để convert codebase cả tôi. Một sự tiến bộ vượt bậc.

Tôi kể chuyện này với 1 người bạn từng viết Preact và anh ấy nói tôi nên thử đầy đủ Preact và wowsers vì nó thậm chí còn nhanh hơn.

Dưới đây là biểu đồ tôi có được.

Có người còn bảo tôi hãy thử Inferno nên tôi đã chuyển ứng dụng của mình sang inferno để siết chặt thêm về hiệu suất.

Đây chính là kết quả thu được.

Đúng vậy tôi đã thử, Inferno nhanh nhưng không nhanh bằng Preact nên tôi rút lại thay đổi đó.

Tôi đã học được bài học ở đây rằng đừng ngần ngại gạch bỏ công việc. Nhưng bạn cũng nên rụt rè 1 chút. Không ai lại thích 1 kẻ hướng ngoại nói “nhiều” đâu.

Và đây…

Tiếp theo, tôi test trên yslow. Tôi gần như đã đạt được những điểm số cao nhất, ngoại trừ 1 con D (!) vì có quá nhiều DOM nodes. Điều buồn cười là vì tôi biết số lượng DOM nodes mà tôi cần và không ai khác có thể nói tôi nên làm cái gì vì tôi chính là người quản lý của chính tôi.

Có vẻ như những nhân viên của yslow đã sai.

Vì vậy tôi đã khá ngần ngại khi nghĩ đến việc tôi có thể giảm số lượng DOM nodes mà mình đã render. Vì thế, tôi đã thay đổi các nhánh trong tree của mình đã được expand mặc định.

Đây là biểu đồ dành cho bạn!

Cảm ơn các nhân viên của yslow, có vẻ như gợi ý ở trên khá tốt đấy.

#4 Render Client Side rất tốn kém

Client Side Rendering (CSR) cũng có những lợi điểm nhưng đối với trang web này thì lại vô dụng.

Tôi không có bất cứ phần nào dành riêng cho người dùng trên trang của mình nên tôi gửi cùng 1 HTML đến tất cả mọi người. Và tôi cũng có 1 nhiệm vụ processing khá năng thực hiện về phần client, khiến CSR ngày càng tệ hơn. CSR không phải là cách nhanh nhất để các pixels của tôi tiếp cận được ánh nhìn của bạn.

Đây là lời khuyên của tôi nếu bạn đang xây dựng 1 trang web cho 1 công ty có – và mong muốn duy trì dòng doanh thu:

  • Hãy xem bảng phân tích của bạn và xem thử phần trăm traffic đến từ Bing là bao nhiêu (đối với tổ chức của tôi là 1,6%)
  • Đúng vậy là Bing vì chúng không xài JS khi index và vì vậy không index 1 trang web CSR nào
  • Giúp thu nhập hằng năm của nhân viên bạn tăng 1,6%
  • Hãy hỏi công ty nếu họ hạnh phúc với số tiền được đưa vào cuộc cạnh tranh bởi vì bạn sẽ không thu được các kết quả tìm kiếm Bing nữa đâu

Có lẽ bạn đã hiểu. Tôi đã đi lạc đề.

Chỉ cần gửi HTML đã render từ server của bạn.

#5 Đừng server-render HTML

Đúng là nghe có vẻ nghịch lý. Làm thế nào bạn serve HTML mà không server-render HTML? Bạn làm đúng những gì mà mọi người có thể đã làm vào những năm 90…

React (và họ hàng nhanh hơn của nó) cần có vài tá milliseconds để render 1 trang HTML khiêm tốn. (Ai đó có số liệu về thời gian PHP hoặc JSP không? Tôi rất muốn so sánh). Điều đó đồng nghĩa là 1 single core chỉ phục vụ được khoảng 50 người trên mỗi giây, các requests thêm sẽ phải xếp hàng chờ đợi ngay ngắn và điều này không tốt chút nào.

Đối với trang web nhỏ của mình, tôi đang gửi cùng HTML vào mỗi response. Nếu trang của bạn tương tự thì bạn không cần 1 web server để render HTML và gửi đi các files CSSs và JS theo yêu cầu. Bạn có thể xuất HTML của mình vào thời điểm build time và ra mắt toàn bộ từ static hosting (hoặc cache it trên 1 CDN tốt). Github và Firebase và khả năng là những người khác sẽ cho bạn static hosting vì chúng rất thân thiện.

Ý tưởng này không áp dụng được nhiều nên bạn có thể bỏ qua phần này. Nhưng nếu bạn có bất kì trang nào có thể được render vào build time (như trang chủ của Linkedin, Paypal, Github) và tận dụng nó.

Tôi nghĩ ra ý tưởng này khi đang xem vài blog, nhận ra tôi chỉ tốn mất 96 milliseconds để nhấn vào link dẫn đến blog đã nói (nhưng nhìn chung tôi vẫn cho rằng trang của tôi là trang nhanh nhất trên thế giới – và thực tế đôi khi lại không công nhận điều đó)

Tôi đã phát hiện blog được hosted như 1 static site với Firebase. Nhưng điều đó đồng nghĩa là tôi phải generate HTML vào build time. .

Giá như React có thể output DOM đã generated như 1 string. Như thế tôi có thể chỉ cần lưu string đó vào 1 file HTML như 1 phần của build script.

Vốn dĩ React đã có 1 method có tên là renderToString (mặc dù bạn nên sử dụng renderToStaticMarkup).

(Đây là cơ hội tốt để chạy HTML qua 1 minifier trước khi lưu vào đĩa).

Mời bạn đọc tiếp phần 2

 Nguồn: Techtalk via Hackernoon (còn tiếp)

“Những sản phẩm bạn làm được ra mới là thước đo chính xác cho năng lực của bạn”

AMA (Ask Me Anything) là 1 sự kiện Q&A – Question & Answer (Hỏi đáp trực tiếp) với các chuyên gia hàng đầu trong ngành Tech diễn ra vào mỗi chiều thứ 6 hằng tuần trên fanpage của TopDev.

Những ngày cuối năm tuy bận rộn là thế những các diễn giả vẫn rất nhiệt tình nhận lời tham gia chương trình. Và 1 trong những gương mặt tiêu biểu chính là anh Vũ Tuấn Phong – Lead Full-stack Developer, Bravebits.

Trước khi dừng chân tại ngôi nhà Bravebits anh đã từng làm Architect tại Kume Design Asia. Tháng 10/2011 anh thành lập Jam.vn, một trang web chuyên về âm nhạc lần đầu tiên tại Việt Nam sử dụng công nghệ web 2.0. Đến năm 2013 anh đảm nhiệm chức vụ Design Consultant tại Not A Basement Studio.

Lĩnh vực chuyên môn mà anh Phong sẽ trao đổi tại AMA là: FullStack Web app Development, NodeJS, ReactJS, BackboneJS, UI & UX Design, Server Infrastructure.

Q: Anh Phong ơi Anh cho em hỏi là cần phải học bao lâu để trở thành UI/UX Desginer chuyên nghiệp. Em cảm ơn anh nhiều ạ

A: Để trả lời cho câu hỏi của bạn thì nó sẽ là 1 con đường rất dài và bạn sẽ phải đồng hành với nó. Học là thứ mà bạn phải làm hằng ngày, bạn cố gắng nắm bắt đc nhiều kiến thức mới mỗi ngày. Nhưng cái chính là bạn phải dùng những kiến thức bạn học được để làm ra được những sản phẩm thực tế hữu ích. Những sản phẩm bạn làm đc ra mới là thước đo chính xác cho năng lực của bạn. Còn đâu kiến thức dù nhiều đến đâu cung ko có tí giá trị nào.

Q: Anh ơi em muốn hỏi là những tố chất quan trọng nào để một Developer có thể đảm nhận một vị trí Full Stack Web app ạ em cảm ơn Anh ạ

A: Khi bạn tự tin nói “OK” với bất cứ công việc nào được giao, kể cả những việc bạn chưa làm bao giờ. Chắc chỉ thế là đủ!

Q: Anh ơi anh có thể chia sẻ về các resource hữu ích cho các bạn Developer muốn trở thành Full Stack Developer. Em cảm ơn anh nhiều ạ.

A: Resource quan trọng nhất là kinh nghiệm và chỉ có đc khi mình làm. Vậy mình khuyên là nên làm nhiều vào, nếu có thời gian. Tự đưa ra những project nhỏ và tự tìm cách giải quyết. Trong lúc làm bạn sẽ biết mình cần học j. Nếu bí thì có thể giúp bạn bè, người quen vào công việc thực tế. .. thực hành lý thuyết phải đi song song.

Q: Anh Phong ơi, tầm quan trọng của UI/UX trong việc lập trình hiện nay là thế nào ạ? Do em cũng muốn học về UX nhưng không biết có cần thiết lắm không.

A: Comment ở dưới sẽ trả lời câu hỏi của bạn. Bổ sung thêm về UX, theo mình thì UX cực kỳ quan trọng tới thành công của 1 sản phản, và ai trong team cũng dev hay design đi nữa, cũng phải có kiến thức căn bản về UX. Nó UX ko nhưng giúp cho trải nghiệm người dung tốt hơn mà còn chính trải nghiệm của bạn để cho flow dev thông minh hơn, đơn giản hơn và sáng tạo hơn.

Q: Em chào anh Phong. Theo em được biết anh là 1 bậc thầy về React ở BB, vậy hi vọng anh có thể tiết lộ cho em biết các dự án nào anh đã sử dụng react, và anh đánh giá kết quả của những dự án đó như thế nào? Em xin cảm ơn anh.

A: Chào bạn. Thực tế mình cùng mới bắt đầu với ReactJS khoảng hơn nửa năm trc. Và cũng là project đầu tiên mình build bằng ReactJS. Nói chung để hiểu và dùng đc React không mất khá nhiều thời gian, nhưng để master đc React là một quảng đường rất dài và gian nan. Tuy nhiên kết quả cho ra hơn cả mình mong đợi.

Q: vậy theo anh thấy ReactJs sẽ hiệu quả nhất trong những dự án nào và không nên dùng trong những dự án nào?

A: ReactJS phù hợp cho projects lớn và quy mô 1 chút với team nhiều người, và hiển thị nhiều dâta. ReactJS rất dễ đc chia nhỏ và khá chặt chẽ. Tuy nhiên tránh dùng ReactJS vào projects nặng animation + looping vì React rất dễ bị mất kiểm soát ở khâu update trong render chain và khó debug ở đoạn này. Mình đã thử dùng react làm app điều khiển máy bay và ko tốt chút nào.

Q: Chào anh Phong, anh cho em hỏi lập trình viên thuần code có cần quan tâm đến UI/UX hay không vậy anh ?

A: Mình nghĩ 1 lâp trình viên nên có kiến thức về design. Nếu hiểu sâu được càng tốt bởi vì nó không chỉ giúp bạn làm nhanh hơn đẹp hơn. Hiểu biết về design còn là chìa khoá mở ra những giải pháp tối ưu hơn cho 1 vấn đề của code. Ví dụ thực tế luôn. Bạn vào trang (http://www.woorockets.com/) và đầu bài là tên lửa phun khói làm sao phải thật như trong after effect, nhưng lại phải viết bằng javascript. Khi nhận đc đề bài này thì lúc đầu cũng hơi lo vì làm trong 2 ngày. Nhưng nhớ lại là hồi xua mình có làm rất nhiều 3D modeling & rendering vì mình từ desgin lên mà. Thì ngay lập tức những kiến thức về particles system, và physics lập tức trở về đúng là giải pháp tốt luôn và resolve issue trong 2 ngày.

Q: Chào anh Phong, em thấy anh biết khá nhiều framework vậy thì đâu là framework mà anh thường sử dụng và thấy nhiều ưu điểm nhất ạ. em cảm ơn anh nhé

A: Mỗi framework nó được làm ra để giải quyết những vấn đề của riêng nó. Cá nhân mình đã đùng thử 1 vài framework, thì mình thấy cái nào cũng có ưu điêm hết, nhưng để thực sự giải quyết đầu bài của bạn 1 cách triệt để, thì vẫn phải là bạn người dev. Trước mình thích Backbone.JS, vì đơn giản là nó nhẹ và có khá đầy đủ những thứ mình cần cho webapp độc lập. Nhưng khi làm app cho Joomla thì mình mới thấy nó không đáp ứng đươc. Ngay cả React bh cũng vậy.

Để thực sự làm chủ đc nó bạn vẫn cần phải viết khá nhiều plugins, đôi hi phải hack trực tiếp vào framework mình đang dùng để đạt được cái mình muốn.

Đây cũng là 1 điểm yếu của React bởi vì mình không thể can thiệp nhiều vào quá trình render and update view của nó. Cũng dễ hiểu thôi bởi vì React khá chặt chẽ và bắt dev phải tuân thủ theo đúng quy trình của React nếu muốn chọc vào bạn phải hiểu rất sâu về nó.

Q: thật sự em đang rất thích React, tuy nhiên những tài liệu hiện tại em đã đọc không thực sự thiết thực vậy anh có thể giới thiệu em một tài liệu mà anh thấy hay nhất được không anh. Nha anh

A: chỉ 2 nơi mà mình thường xuyên đọc là source code và developer docs.

Q: Em chào anh, em tò mò không biết môi trường làm việc ở BB như thế nào ạ, và anh có dự định gắn bó lâu dài ở đó không anh?

A: Mình đang lead 1 project chủ chốt ở BB và đang trong kế hoạch cho những projects tương lai. Thế nên chắc là sẽ còn gắn bó lâu lâu. Môi trường làm việc ở đây như gia đình vậy, không phân biệt sếp hay nhân viên, mọi ý kiến đều đc lắng nghe, mọi ý tưởng đều được tôn trọng …. Hiện tại team cũng đang chiêu mộ anh em đam mê mảng này để có thể mở rộng hơn cho ra nhiều những ý tưởng hay hơn nữa.

Q: Vậy tại sao anh quyết định trở thành fullstack webapp developer mà không phải chuyên sâu về một mảng nào đó ạ?

A: Mình muốn tạo ra được nhiều sản phẩm hay, và cũng nung nấu nhiều ý tưởng muốn được thực hiện. Kiến thức của mình bây giờ hoàn toàn không do mình dự đoán trước , mình chưa bao giờ nghĩ đến việc trở thanh 1 full stack developer, tuy nhiên làm công việc mình dam mệ và đi đung con đường mình hướng tới mang tới cho mình tất cả kiến thức và kỹ năng mình có đc hom nay.

Q: Anh Phong ơi ngoài thời gian làm việc tại BB anh có nhận thêm project ở ngoài không anh vì em thấy anh làm fullstack ạ

A: Mình hiện tại đang full-time tại BB và dành hầu hết thời gian vào các dự án của BB. Tuy nhiên trước kia mình cũng đã từng thực hành tại nhiều mảng khác nhau như iOS Apps, System Admin và Design. Tuy nhiên ngoài công việc căng thẳng ở cty, thì mình có 1 thú vui đo là chơi Drone. 1 Năm vừa rùi nghiên cứu và nghịch ngơm, thì cũng rút ra đc rất nhiều kiên thức cũng như thực hành thực tế, mà chính xác là làm mạch, nạp code cho MicroChips, C++, MobileApp để điều khiển, Unit testing và vo số skill khác nữa.

Q: Vậy em bên lập trình java nhưng em thích cả việc tổ chức sự kiện thì anh nghĩ em nên đi tìm hiểu về tổ chức sự kiện để sau này có thể tạo event cho anh em lập trình giao lưu với nhau hay là cứ chuyên tâm học code trước ạ

A: Hoặc em có thể tổ chức events j đó cho anh em có thể được ngồi code cùng nhau. Có phải e vừa học code vừa tổ chức events

Q: Anh ơi Anh cho em hỏi là sự khác biệt giữa React và các framework Js khác như Angular, Ember, Backbone là gì? Em cảm ơn anh ạ.

A: Mình ko có câu trả lời cho câu hỏi này. Mình nghĩ là người làm nên những thư viện này, mục đích của hộ không phải để mọi người đem ra so sánh!! mỗi thư viện đc làm ra để giải quyết 1 vấn đề cụ thể nào đó theo cách nghĩ của người làm. Thế neen mình hay có 1 thói quen là tự đưa ra 1 đầu bài của mình rùi dùng các thử viện khác nhau để đưa ra kết qua giống nhau. Làm như vậy bạn sẽ hiểu rõ hơn cái nào phù hợp với công việc của bạn. Nếu như kết quả như nhau, thì bạn học được thêm nhiều cách tư duy để giải quyết 1 vấn đề.

Một lần nữa, AMA rất cảm ơn anh Phong đã trả lời nhiệt tình rất nhiều câu hỏi của các bạn trẻ yêu thích công nghệ và lập trình. Bạn vẫn còn thắc mắc muốn được giải đáp? Đợi đến thứ 6 tuần sau, 13/1 để xem nhân tố bí ẩn lộ diện tiếp theo là ai nhé!

Xem các vị trí tuyển dụng lập trình IT tại đây

1...224225226...230Page 225 of 230