Đã từng có không ít các thông tin bàn luận xoay quanh vấn đề lỗi thiết kế và tính không nhất quán của lập trình ngôn ngữ PHP. Vào năm 2012, một bài viết chia sẻ từ blogger Eevee đã được viết với tiêu đề “PHP: Một ngôn ngữ có thiết kế rất tồi”. Từ đó cuộc tranh luận về nhược điểm của ngôn ngữ lập trình này bắt đầu nhiều hơn: “Không có một triết lý thiết kế rõ ràng”, “PHP không tập trung như các ngôn ngữ khác”, “PHP thật tệ”…
Tuy nhiên, chúng ta tự hỏi với vô số những ý kiến trái chiều ấy tại sao PHP lại vẫn được nhiều người sử dụng và phổ biến đến vậy? Theo W3Techs, có đến 82% website trong thế giới internet dùng ngôn ngữ lập trình PHP. Ngay cả các trang web nổi tiếng như Wikipedia, Facebook, WordPress…cũng đều đang được chạy bởi chính ngôn ngữ này.
Vậy điều gì đã khiến độ hot của PHP vẫn chưa hề giảm nhiệt?
Phổ biến và dễ tiếp cận
Theo CEO của công ty Zend Technologies, ông cho biết: “PHP cho đến nay là ngôn ngữ lập trình web phổ biến nhất”. Với Josh Lockhart, một nhà phát triển web tại Media Campaigns, ông nhấn mạnh PHP được xem là một trong những ngôn ngữ lập trình web đơn giản và dễ diếp cận nhất ngày nay.
Với tất cả những gì liên quan đến website, PHP đều có thể được áp dụng vào. Cấu trúc và câu lệnh của PHP cũng giống với C, Java nên bạn có thể dễ dàng nắm vững trong một thời gian ngắn nếu thường xuyên thực hành nhiều bài tập và dự án nhỏ. Xét về mức độ hiệu suất, khả năng mở rộng thì PHP được đánh giá rất cao; hơn nữa chi phí lại luôn luôn rất thấp. Facebook ban đầu được xây dựng bằng ngôn ngữ PHP và về sau đã thống lĩnh trang mạng xã hội vượt mặt cả trang Myspace đã được ưa chuộng rất nhiều trước đó. Hiện tại thì Facebook chính là trang web có lượng người truy cập lớn thứ 2 trên thế giới.
Sự lớn mạnh của cộng đồng PHP đã chứng tỏ mức độ phổ biến và chất lượng của chính ngôn ngữ này. Thêm vào đó, các phiên bản cải tiến mới cũng như các version cập nhật đã giúp cho PHP càng trở nên linh hoạt trong việc hoàn thiện.
PHP còn hỗ trợ nhiều Framework mang tính năng mạnh mẽ: Laravel, Yii, Phalcon, CakePHP, Zend,… và mô hình OOP thích hợp. Với các phiên bản phát triển mới trong tương lai thì PHP sẽ cải tiến thêm hiệu suất mang khả năng ứng dụng cao.
Nhu cầu tuyển dụng lớn
Sau Java thì PHP là ngôn ngữ lập trình phổ biến đứng trong top 5 ngôn ngữ lập trình được sử dụng nhiều nhất trong các năm qua theo khảo sát của StackOverFlow.
Khi gõ tìm kiếm nhanh trên trang web việc làm công nghệ Dice.com gần đây thì trang đã cho hiển thị khoảng 19,072 công việc liên quan đến PHP, đứng top 3 chỉ sau Java và Python. Điều này cho thấy rất rõ PHP đang không ngừng gia tăng số lượng công việc gần bằng các ngôn ngữ lập trình khác.
Ngay tại Việt Nam ở 3 khu vực thành phố lớn có rất nhiều công ty đang tuyển dụng việc làm it PHP Developer.
Cuối cùng, bạn đã hiểu lý do tại sao mười người mười ý nhưng độ hot PHP vẫn chưa hề giảm rồi chứ?
Gặp gỡ anh Chu Sĩ Nguyên – Phó Tổng Giám Đốc của SK-Global, một startup khởi nghiệp năm 2016, chuyên xây dựng những Giải Pháp phục vụ cộng đồng với thế mạnh về kỹ thuật thực tế tăng cường (AR), cũng như thâm niên lâu năm trong lĩnh vực Outsourcing trong các lĩnh vực tài chính tiền tệ
Hãy cùng TopDev lắng nghe những chia sẻ thực tế đến từ quá trình hơn 10 năm làm việc.
Q: Chào anh, anh có thể chia sẻ những khó khăn trong quá trình Startup không?
Khó khăn này có lẽ là khó khăn chung của các Startup, đó là việc bài toán cân bằng giữa outsourcing và product. Làm outsourcing quá nhiều thì dễ đánh mất lý tưởng của công ty, còn làm product nhiều thì lại thiếu ngân sách hoạt động.
Hiện tại, giải pháp mà SK Global hướng đến là tìm ra mô hình mới, tách bạch rõ ràng giữa 2 team Product và Outsourcing trong nội bộ công ty, mỗi team có một sứ mệnh rõ ràng chứ không trộn lẫn như bây giờ.
Q: Anh đánh giá như thế nào về các dự án Outsourcing Việt Nam hiện nay?
Mình không nói về các dự án Việt Nam mà tập trung vào các dự án mình đã làm. Nhìn chung giá cả Việt Nam vẫn cạnh tranh được với các nước khác, kể cả Ấn Độ & Trung Quốc. Mình làm rất dàn trải, việc gì cũng làm được nhưng chưa sâu, sâu ở đây có thể hiểu là sâu ở mặt quy trình.
Ví dụ mình chủ yếu chỉ tham gia vào những giai đoạn như phát triển, testing. Những giai đoạn mang đến “linh hồn” và “bản sắc” cho dự án như lên ý tưởng, thiết kế, core library thì hầu như rất hiếm khi được tham gia.. Đến bây giờ, sau 10 năm thì thực tế này vẫn đang tiếp diễn, đối tác tìm đến mình chủ yếu vẫn là do giá thành rẻ.
Q: Một developer muốn vào SK Global thì cần những kĩ năng, kiến thức gì?
Mình tuyển dụng cũng khá nhiều, tùy theo mục đích là làm Product hay làm Outsourcing. Trong đó, hai yếu tố quan trọng là khả năng tự học và khả năng làm việc độc lập. Các công ty khác đánh giá cao khả năng làm việc theo nhóm nhưng theo quan điểm của SK Global thì người làm việc độc lập được thì mới làm teamwork được. Còn khả năng tự học là điều chắc chắn vì SK Global không tuyển một bạn biết hết tất cả mà cần các bạn có nền tảng tốt để có thể tự học được.
Q: Với các dự án riêng của SK Global thì anh có mong đợi kĩ năng/ công nghệ nào đặc biệt từ phía lập trình viên?
Tất nhiên khi tuyển dụng mình phải ưu tiên ứng viên có kĩ năng đáp ứng được nhu cầu công việc lúc đó, nhưng trên hết ứng viên phải có nền tảng tốt về lập trình và thiết kế lập trình. Ngoài ra mình cũng ưu tiên những bạn vững về Javascript, mình nghĩ Javascript sẽ được cộng đồng hậu thuẫn nhiều trong tương lai.
Q: Một lập trình viên làm Product và một lập trình viên outsource thì khác nhau ở điểm nào?
Trong 1 năm làm việc vừa qua, mình đã nhận ra là khác nhau hoàn toàn. Bản thân mình cũng xuất thân từ Outsourcing, thì cái khó nhất của các bạn Outsourcing trước khi chuyển qua Product là tư duy sáng tạo.
Mình đã quen với việc làm bài tập từ thời còn đi học: chỉ làm những gì mà người ta yêu cầu, chỉ làm những gì mình thấy rõ ràng để làm. Thời gian đầu các bạn làm ở SK Global thì hầu hết các bạn đều không làm được vì chỉ nghĩ công việc của mình như là một coder, nhưng khi làm Product các bạn phải can thiệp vào tất cả các khâu từ giai đoạn ý tưởng, thiết kế đến khi thành phẩm.
Các bạn phải tự đóng vai trò là khách hàng, tự đặt ra những chuẩn mực cho dự án, học từ những feedback trực tiếp từ khách hàng, chịu thất bại và tiếp tục phát triển tiếp. Quan trọng nhất phải có ý thức mình là chủ sở hữu của sản phẩm để có thể tâm huyết tạo ra dược sản phẩm tốt nhất. Điều này khác rất nhiều so với làm Outsourcing.
Q: Anh có ví dụ nào thực tế đến từ Product mà SK Global đang làm không?
SK-GLOBAL sắp ra mắt ứng dụng cho phép người dùng thử mắt kính ảo theo thời gian thực ngay trên thiết bị di động. Mình nghĩ mọi người sẽ rất bất ngờ về khả năng mang đến trải nghiệm y như thật của ứng dụng này.
Từ lúc ban đầu khi ý tưởng chưa có, công ty có tổ chức một số buổi brainstorm, hackaton để thu thập ý kiến của mọi người nhưng kết quả không được tốt mấy do mọi người chưa quen với việc tự nghĩ ra cái để làm.
Nhưng dần dần sau khi trải qua tất cả các khâu của dự án, tư duy va cách làm Product của mọi người dần dần được hình thành. Mình nghĩ dự án Product tiếp theo sẽ được hình thành từ chính ý tưởng của các bạn trong công ty.
Q: SK Global có mối quan hệ thân thiết với các công ty Nhật, thì không biết môi trường/ văn hóa làm việc giữa Nhật Bản và Việt Nam có những điểm khác biệt nào, nhất là đối với developer?
Môi trường làm việc thật ra không có gì quá khác biệt trong môi trường Internet như hiện nay. Cơ sở vật chất Việt Nam cũng không thiếu thốn gì so với nước bạn.
Nhưng văn hóa làm việc thì khác. Người Việt Nam có khuỵnh hướng là không đi đến tận cùng, không có nhu cầu sự hoàn hảo, không có lý tưởng làm sao cho sản phẩm của mình là số 1 trên thế giới.
Q: Nguyên nhân nào dẫn đến thực tế này? Có phải vì dev Việt mình chưa có đủ đam mê…?
Đúng vậy, vì các bạn làm Outsourcing, sản phẩm là của người ta nên mình không cần bỏ quá nhiều công để làm cho hoàn hảo. Thứ hai là xuất phát văn hóa của mình là hay tự thỏa mãn, không đến nơi đến chốn. Ngoài ra, nếu trong công ty Outsourcing thì đa phần mình không có điều kiện, không có cơ hội để thực sự tâm huyết với sản phẩm đó.
Q: SK Global có các khóa training nào cho nhân viên?
Hiện tại công ty có gửi các bạn đi training rất nhiều, nhưng không tập trung vào kiến thức lập trình, vì công nghệ phát triển quá nhanh nên các trường khó dạy tốt và cơ bản các bạn cũng có khả năng tự học rồi.
Chủ yếu vẫn là học Marketing và Design.
Q: Ngoài những vấn đề chuyên môn thì anh có thể mô tả thêm về văn hóa công ty?
Mình muốn tạo ra môi trường làm việc có cơ sở vật chất tốt nhất cho các bạn. Thêm nữa, công ty không có rào chắn giữa người lao động và người sử dụng lao động, mình rất dị ứng tạo ra không khí cấp trên, cấp dưới. Dự án là của mọi người, ai cũng có vai trò, sức ảnh hưởng riêng và cùng nhau hoàn thành dự án. SK Global cũng rất flexible về thời gian làm việc.
Thay đổi công việc là điều gì đó dễ khiến chúng ta hoảng sợ vì mức độ mạo hiểm của nó. Càng lớn tuổi, rủi ro khi chuyển sang một lĩnh vực khác càng lớn. Thời điểm bắt đầu là khó khăn nhất vì bạn phải cạnh tranh với người trẻ hơn, thành công hơn. Đừng lo, đừng nảng lòng. Dấn thân vào công nghệ ở tuổi 30 (hoặc bất kỳ độ tuổi nào) cũng có thể trở thành một cuộc phiêu lưu kì thú với những trải nghiệm đáng nhớ, những con người thú vị và những cơ hội tuyệt vời.
Hôm nay là sinh nhật thứ 32 của tôi và tôi đang nhìn lại một năm phiêu lưu của mình…
Khi 20 tuổi, tôi đã từng chắc mẩm rằng, trước 32 tuổi, tôi sẽ có tất cả. Tôi đã tưởng tượng mình trong tương lai là người phụ nữ có một cuộc sống, sự nghiệp tuyệt vời, mang giày gót cao và sở hữu kế hoạch cuộc đời hoàn hảo.
Tôi hiện tại đang mặc chiếc áo T-shirt quá khổ của chồng tôi, và gương mặt makeup từ ngày hôm qua. Tôi có một cuộc sống tuyệt vời mặc dù nó khác với những gì tôi đã lên kế hoạch ban đầu và sự nghiệp của tôi chỉ mới bắt đầu. Tôi hầu như không mang giày cao gót vì tôi thích những đôi thoải mái…
Hành trình đến với công nghệ của tôi là một câu chuyện dài và phức tạp, có cả nước mắt và tuyệt vọng. Ban đầu, tôi đã trở thành một nhà ngôn ngữ học. Mọi thứ đã được lên kế hoạch và tôi đã trở thành một nhà khoa học, đi khắp thế giới, dịch văn bản cổ và giảng dạy tại các trường đại học có uy tín. Sau đó, mẹ tôi bị ung thư và không điều gì trong số đó trở nên quan trọng với tôi. Cuộc sống của tôi đã dừng lại trong 2 năm rưỡi cho tới khi mẹ tôi mất vì ung thư. Tôi sụp đổ hoàn toàn- đại học không thành vấn đề, trình độ của tôi không thành vấn đề, tôi không có kế hoạch nào và tôi đã mất tất cả.
Sau khi mất một thời gian khá dài để ổn định lại cuộc sống, tôi bắt đầu suy nghĩ về việc trở thành Web Designer. Tôi đã làm điều này trong phần lớn cuộc đời của mình nhưng chưa bao giờ nghĩ rằng tôi nghĩ sẽ biến nó thành sự nghiệp thực sự. Vì vậy, tôi bắt đầu tham gia chương trình 2-năm, nơi tôi đã biết đến Manuel Matuzovic – người giáo viên đầu tiên cũng đồng thời là một người bạn, người cố vấn của tôi. Anh đặt ra thách thức cho tôi và nhận ra tham vọng muốn làm cho một cái gì đó của bản thân tôi.
Tôi đã làm việc trong vai trò developer toàn thời gian trong gần một năm và dưới đây là những bài học của tôi khi bắt đầu trở thành developer ở tuổi 30.
Mọi người đều còn quá trẻ!
Khi tôi làm dev lần đầu, tôi là Junior lớn tuổi nhất trong công ty. Đây là một kinh nghiệm rất kỳ quặc, đặc biệt là khi tôi đã từng nắm giữ các vị trí quản lý phụ trách hơn 60 người, trước khi chuyển sang làm developer.
Tôi luôn cảm thấy mình sẽ không bao giờ bắt kịp với các đồng nghiệp của mình những người đã dẫn trước tôi hang ngàn dặm. Cảm giác này kéo dài mãi cho tới khi tôi tìm thấy vị trí thích hợp dành cho mình, thứ tôi thực sự giỏi, cảm giác đó bắt đầu giảm dần từng chút một.
Vì vậy, lời khuyên của tôi là: Trở nên giỏi ở một cái gì đó bạn thích, sự tự tin đi kèm với thực hành.
Hội chứng Imposter là có thật
Bạn thật sự không thể lừa lọc trong ngành lập trình đâu. Gửi code đi để reviews là một cơn ác mộng với những người mắc chứng sợ hãi như tôi. Tôi liên tục cảm thấy như một kẻ thất bại hoàn toàn và không bao giờ có thể làm tốt hơn. Chìa khóa để khắc phục điều này là trò chuyện. Tôi nói chuyện với leader của mình về cảm giác bất an và mong nhận phản hồi của ông về khả năng học hỏi và chất lượng code của tôi. Tôi đặt câu hỏi khi tôi không hiểu điều gì đó và tiếp tục học hỏi từ anh ấy cũng như những người khác. Điều này thực hiện được vì tôi có một ông chủ tốt và những người đồng nghiệp tuyệt vời. Họ khiến tôi cảm nhận được sự tự tin mỗi lần đặt câu hỏi.
Tất cả là về vấn đề con người
Giống như bất kỳ công việc nào khác, việc trở thành một developer là câu chuyện xoay quanh con người. Đồng nghiệp, khách hàng, user của bạn.
Tôi đã gặp một số người tuyệt vời tại hội nghị công nghệ. Ngành công nghiệp này thực sự có một số nhân vật “đáng sợ” và tôi vẫn còn sợ cách họ đối xử với nhau. Tất nhiên, những điều không hay này xảy ra trong ngành công nghệ (cũng như trong các ngành công nghiệp khác) nhưng tôi cảm thấy như có một cuộc tranh luận ở đây và mọi người đều ý thức được những gì họ nói. Chúng ta có rất nhiều thứ để cải thiện và mọi người vẫn đang cố gắng.
Không dừng lại một cái nghề
Đối với tất cả các công việc khác, khi ngày làm việc kết thúc, tôi rời văn phòng trở về nhà để cố gắng và không nghĩ về công việc. Bây giờ, tôi thường không về nhà, mà đi thẳng đến những buổi meetup sau giờ làm vài lần một tuần. Vào cuối tuần tôi tham gia hackathons, các hội nghị hoặc các sự kiện.
Trở thành developer tích lũy được rất nhiều kinh nghiệm xã hội và công việc không dừng lại khi bạn rời khỏi văn phòng. Là developer có nghĩa là liên tục liên tục tìm hiểu, không ngừng học hỏi, tham gia các sự kiện, trau đổi với những developer khác, thử nghiệm, xây dựng, cố gắng, thất bại, sửa chữa và cải tiến.
Đây có thể là một thách thức lớn cho những người tham gia vào ngành công nghiệp khi lớn tuổi vì đa phần chúng tôi đã có gia đình và ít thời gian để tham dự các sự kiện. Những ngày đầu tôi gần như không thể cân bằng được giữa gia đình với công việc. Vì vậy tôi giới hạn mình chỉ tham dự 1-2 buổi họp mỗi tuần và dành thời gian cuối tuần cho chồng tôi và bạn bè
Được nói chuyện trước mọi người là niềm hạnh phúc
Tôi là người tham vọng, vì vậy việc tham gia vào lĩnh vực công nghệ là 1 thành công với tôi. Và mặc dù chưa bao giờ có kế hoạch để nói chuyện trước công chúng, tôi may mắn được trở thành một diễn giả công nghệ ở Vienna, tôi tham gia nói chuyện tại những buổi meetup và gần đây nhất là tại một cuộc hội thảo trước hơn 1000 người. Có thể nói về tuổi tác và kinh nghiệm không quan trọng bằng việc tôi được đứng trước mọi người và nói về những gì tôi thích. Tôi cũng đã bắt đầu giảng dạy những gì tôi biết cho người khác. Tôi tự hỏi rằng liệu mình có đủ tự tin để làm điều này lúc tôi 22
Vì vậy, sau tất cả, đó là một chuyến đi tuyệt vời và tôi mong muốn trải nghiệm nhiều hơn trong ngành công nghiệp này với tất cả những con người tuyệt vời và những điều tuyệt vời mà nó đã dạy tôi. Tôi liều lĩnh tham gia cuộc phiêu lưu mạo hiểm này và cho đến nay có vẻ như tôi đã quyết định đúng. Tôi thực sự biết ơn tất cả những người đã ủng hộ quyết định của mình, đặc biệt là chồng tôi.
Điều gì giữ tôi ở lại?
Hy vọng những buổi nói chuyện trước công chúng, những thách thức trong lập trình, các hội nghị lớn, những cái ôm từ những con người tuyệt vời và khả năng đạt được mục tiêu trong công việc là tổng hòa những điều giữ tôi lại với công việc này. Vì vậy, nếu bạn có ý định thay đổi công việc nhưng cảm thấy rằng mình quá già, hãy để tôi nói với bạn một điều: Bạn không bao giờ quá già để trở nên hạnh phúc và thành công, để tận hưởng công việc và để gặp những người mới qua công việc. Bạn xứng đáng được hạnh phúc và làm việc trong một lĩnh vực mà bản thân thật sự đâm mê. Chúc bạn may mắn!
Nếu mới làm quen với React, bạn hẳn đã nghe qua “Higher Order Components” và “Container” component. Và tự hỏi rằng sao mọi người có vẻ quan tâm đến bọn này cũng như cách chúng hoạt động ra sao.
Là một nhân viên bảo trì cho Apollo’s React integration – Open source library nổi tiếng với High Order Components. Tôi cũng phải mất một thời gian mới có thể hiểu rõ về chúng.
Vì thế mà hi vọng bài viết này sẽ cung cấp thông tin hữu ích cho bạn về Higher Order Components
React re-primer
Đầu tiên, trước khi đọc bài viết này, bạn cần sẽ biết chút đỉnh về React. Nếu có thời gian thì hãy vào xem bài viết của Sacha Greif’s5 React Concepts. Do tôi muốn giữ mọi thứ ngắn gọn cho dễ đọc nên sẽ chỉ tóm tắt vài điều bạn cần phải biết về React.
Một React Application bao gồm một set của components. Component là tập hợp các input properties (props) và cho ra HTML vốn được rendered lên màn hình hiển thị. Khi component’s props thay đổi thì nó sẽ re-render và HTML cũng bị thay đổi.
Khi user tương tác với HTML thông qua một event gì đó như click chuột, component sẽ xử lí quá trình trên nhờ vào callback prop để thay đổi internal state. Hành động trên cũng sẽ khiến cho các state re-render.
Điều đó còn được gọi là component lifecycle, khi component lần đầu tiên được render, và gắn vào DOM cũng như thông qua các props mới, etc.
Component’s render function giúp trả lại một hoặc nhiều component khác. Từ đó tạo ra một nhánh cây – view tree. Nói cách khác, khi tương tác diễn ra sẽ dẫn đến việc các component phản ứng theo trình tự và qui định.
React UI vs statefulness
Có lẽ giờ thì cách này đã trở nên lỗi thời nhưng hồi trước, mọi thứ đều được phân biệt một cách rõ ràng vào 3 nhóm Models, Views và Controllers. Nhiệm vụ của một View là render và xử lý tương tác của người dùng trong khi Controller sẽ chuẩn bị Data cần thiết.
Tuy nhiên, nhiều developer bắt đầu dùng tới functional stateless components trên React. Chúng là các “pure” component chỉ thực hiện việc chuyển đổi props thành HTML và callback props dựa trên các tương tác của user đưa ra
Nói cách khác bạn có thể xem chúng là functional, như vậy view tree cũng được xem là một function khổng lồ dành riêng cho việc chuyển đổi Props thành HTML.
Một lợi thế nổi bật của functional stateless component là vì chúng rất dễ để test và đơn giản. Nói cách khác, nó dễ phát triển và check phát hiện bug nhanh chóng.
Thế nhưng không có nghĩa bạn sẽ luôn dùng tới chúng. Bởi UI cần có state, và như vậy bạn sẽ phải dùng tới class-based components. Vấn đề sẽ bắt đầu trở nên phức tạp hơn khi “global state” của UI dính dáng vào view tree.
Global State
Global state của UI là state không trực tiếp liên kết với chỉ duy nhất một component. Nó thông thường bao gồm 2 phần:
Phần data trong ứng dụng của bạn vốn đến từ server. Thông thường các thông tin này được sử dụng cho nhiều vị trí khác nhau chỉ không phải cho một component duy nhất.
Global UI state – ta thường gắn nó với component ở vị trí cao nhất trong app của bạn và cho phép các component cấp thấp sử dụng nó nếu cần. Và những thay đổi sẽ được đưa ngược lại lên state, quá trình này con được gọi callback.
Phương thức này lại không được tốt bởi do nó sẽ chở nên chậm chạp nhanh chóng. Đó là bởi vì component gốc cần biết và hiểu hết tất cả yêu cầu đưa ra của toàn bộ các thành viên trong view tree.
Containers và Presentational Components
Vấn đề trên thường sẽ được giải quyết bằng cho phép component truy cập global state từ bất cứ đâu trong view tree.
Nói cách khác, ta sẽ chia component thành nhóm được phép kết nối với global state và nhóm không.
Các “pure” components thuộc nhóm không sẽ dễ hiểu và test hơn (đặc biệt nếu chúng là functional stateless component). Nói cách khác khi chúng trở thành “impure” – làm nhiều chức năng khác thì sẽ khó hơn cho việc phát triển và test chúng.
Vì thế mà ta sẽ chia những “impure” component đó thành 2 phần:
Container component: Chuyên làm những việc mờ ám cho global state
Presentational component: Không làm cho global state
Và giờ đây ta có thể xem các component này như “Pure” bởi ra chi cách những phần phải làm việc đen tối cho global state vào một container.
Container
Bạn sẽ thấy việc viết ra container rất là thú vị bởi dù nó thuộc component, thế nhưng lại chả giống gì bởi:
Lấy và đưa một phần của global state cho các component cần
Chạy one data-accessing query và đưa ra kết quả cho các component cấp thấp hơn
Nói khác, chỉ một phần của component mà container chỉ định sẽ được render, đồng thời các component đó cũng phải có liên kết với container.
Tổng quát hóa Container
Các container khác nhau tùy thuộc vào loại component mà chúng liên kết với và loại data mà chúng lấy từ global state. Trong Redux, một container sẽ như sau:
// This is a vastly simplified implementation of what a Redux container would do
class MyComponentContainer extends Component {
mapStateToProps(state) {
// this function is specific to this particular container
return state.foo.bar;
}
render() {
// This is how you get the current state from Redux,
// and would be identical, no mater what mapStateToProps does
const { state } = this.context.store.getState();
const props = this.mapStateToProps(state);
return <MyComponent {...this.props} {...props} />;
}
}
Tuy rằng container này sẽ có hết mọi tính năng như một Redux container thực thụ, bạn cũng có thể thấy ngoài mapStateToPropsvà MyComponent, chúng ta phải ghi nhập mã lệnh mỗi khi viết một Redux-accessing container.
Cách tạo ra Container
Bạn sẽ ngạc nhiên khi biết rằng khá dễ để viết một function chuyên generate container component dựa trên những thông tin thích hợp.
function buildReduxContainer(ChildComponentClass, mapStateToProps) {
return class Container extends Component {
render() {
const { state } = this.context.store.getState();
const props = mapStateToProps(state);
return <ChildComponentClass {...this.props} {...props} />;
}
}
}
Đó là Higher Order Component (HOC), một function chuyên lấy một component và các thông tin khác nhằm tạo ra container cho chính component đó.
Gọi là high order là bởi vì đây là function có cấp cao. Nói cách khác, bạn ó thể xem React Components như những function tạo ra UI. Không chỉ thể mà nó vẫn xài được cho functional stateless components và cả pure stateful presentational component.
Một số ví dụ cho HOC
Redux’sconnect function có lẽ được biết đến nhiều nhất, `buildReduxContainer` function trong bài viết này chính là một phiên bản dỏm dựa trên nó.
React Router’swithRouter function với tính năng lấy router từ context để biến thành thành prop cho các component.
react-apollovới interface chính là graphql HOC, khi được cung cấp component và GraphQL query sẽ đưa ra kết quả dành cho query và component đó.
Higher order component chính là trái tim của việc phân chia components theo function để giải quyết chúng. Ở các phiên bản của React trong quá khứ, ta phải dùng đến classes và mixins để reuse code, thế nhưng trong tương lai, higher order components sẽ ảnh hưởng mạnh mẽ hơn trong quá trình phát triển của React.
Nếu bạn lo lắng về sự phức tạp thì đừng lo bởi team phát triển React đã dày công nghiên cứu và cải thiện giúp cho chúng trở nên đơn giản hơn ngay cả cho cả người mới.
“Một làn sóng mới đang đến. Con người sẽ bị đánh cắp hết việc làm. Tuy nhiên, những người bắt kịp với làn sóng này sẽ trở nên giàu có và thành công hơn”.
Jack Ma – nhà sáng lập tập đoàn thương mại điện tử hàng đầu thế giới Alibaba, đã nhìn thấy trước sự thay đổi lớn trong kỷ nguyên công nghệ toàn cầu. Trả lời phỏng vấn trên CNBC, vị tỷ phú này cho rằng trong 30 năm tới, trí thông minh nhân tạo (AI) sẽ vượt qua kiến thức của con người dẫn đến hệ quả là chúng ta sẽ dần mất hết việc làm vào tay robot.
“Một làn sóng mới đang đến. Con người sẽ bị đánh cắp hết việc làm. Tuy nhiên, những người bắt kịp với làn sóng này sẽ trở nên giàu có và thành công hơn”, Ma nói.
Ngược lại, đối với những người tụt hậu phía sau, chắc chắn tương lai sẽ rất “thảm khốc”.
Theo vị tỷ phú này, trung tâm của kỷ nguyên công nghệ đang phát triển như vũ bão chính là dữ liệu (data). Do đó, ông dự đoán trong tương lai, thị trường việc làm sẽ ưu tiên những kỹ năng liên quan đến dữ liệu và việc phân tích dữ liệu.
“Thế giới đang chuyển dần sang data hóa. Tôi nghĩ chúng ta đang sống trong giai đoạn khởi đầu của thời đại bùng nổ dữ liệu”, Jack Ma cho biết.
Là một trong những tập đoàn công nghệ hàng đầu thế giới, Alibaba nắm giữ khối lượng dữ liệu khách hàng khổng lồ. Rất nhiều người trong số đó ghé thăm website của Alibaba hàng trăm lần mỗi ngày. Chính điều này đã cho Jack Ma thấy bước chuyển biến trong một thập kỷ tiếp theo của thế giới.
“Chúng tôi nghĩ rằng dữ liệu sẽ trở thành một phần quan trọng trong cuộc sống của con người trong tương lai. Ngày mai, với sự trợ giúp của Internet, tất cả mọi thứ đều có thể kết nối với nhau”, người đứng đầu Alibaba chia sẻ.
Trên thực tế, Jack Ma không phải là nhà lãnh đạo duy nhất nhấn mạnh tầm quan trọng của kỹ năng phân tích dữ liệu. Elon Musk – CEO của Telsa và SpaceX cũng đang thực hiện một dự án liên kết não người với máy tính nhằm cải tiến tốc độ xử lý dữ liệu vốn đang “chậm chạp đến khó tin” của não người.
Nhà đồng sáng lập Microsoft Bill Gates cũng nói rằng khả năng khai thác thông tin sẽ giúp chuyển đổi vấn đề sức khỏe toàn cầu và ngăn chặn sự phát triển của nhiều dịch bệnh.
Chủ tịch Eric Schmidt
Eric Schmidt – Chủ tịch Tập đoàn Alphabet (công ty mẹ của Google) và Jonathan Rosenberg – Cố vấn cấp cao cho CEO Larry Page đều đồng ý rằng phân tích dữ liệu là kỹ năng hàng đầu mà mọi sinh viên trẻ đều nên học.
“Phân tích dữ liệu, ý tôi là những kiến thức cơ bản về cách thức hoạt động của dữ liệu thống kê, hay cách mà mọi người đưa ra kết luận sau khi phân tích khối lượng dữ liệu lớn”, Schmidt nói.
“Tôi cho rằng kiến thức cơ bản về phân tích dữ liệu là cực kỳ quan trọng với thế hệ những người trẻ tiếp theo. Bởi đó chính là thế giới mà các bạn sắp bước vào”, Chủ tịch Alphabet nhấn mạnh.
Bạn chỉ có 24 chỗ cho app icon trên màn hình iPhone, hoặc 28 nếu là iPhone 7 nên việc tạo ra app icon hoàn hảo là một bước quan trọng để thu hút sự quan tâm của người dùng.
Tôi đã từng gặp 1 user để màn hình chính là các app icon gồm tất cả chữ cái trong bảng chữ cái, nhưng không phải ai cũng vậy. Đối với đa số người tải ứng dụng, app icon là nơi tiếp xúc đầu tiên giữa người dùng với ứng dụng mới.
Nếu app icon xấu, người dùng sẽ xóa ứng dụng hoặc ẩn ứng dụng trong một thư mục ở nơi nào đó mà họ dễ dàng quên đi. Vậy có thể làm gì để đảm bảo rằng app icon của mình là “nữ hoàng của cuộc chơi” chứ không không phải là “cô gái nhút nhát”?
Rất nhiều bài báo khoa học đã nghiên cứu ý nghĩa đằng sau việc chọn màu cho app icon của bạn. Thậm chí đã có người tạo ra biểu đồ các màu phổ biến nhất dùng cho app icon.
Biểu đồ này hàm chứa 2 ý nghĩa: sử dụng chủ yếu các màu như đỏ, xanh hoặc có thể là màu xanh lá cây cho app icon như 1 giải pháp khá an toàn. Mặt khác, bạn có thể chọn màu hồng, tím hoặc màu vàng để nổi bật hơn một chút.
Đương nhiên, mỗi lựa chọn đều có những ưu và nhược điểm riêng. Những gì an toàn và quen thuộc thì dễ bị quên lãng, trong khi việc phá vỡ khuôn khổ tiềm ẩn nguy cơ quá khác biệt và không hài hòa với những ứng dụng khác.
Sử dụng 1 kí tự (hoặc Không …)
Từ kí tự ‘F’ của Facebook và ‘H’ của Hotels.com chữ “D” trong Dailymotion và ‘S’ của Skype, không ít các app sử dụng chữ cái đầu tiên trong tên công ty cho ứng dụng của mình,
Đây chắc chắn là một giải pháp thông minh và đơn giản nhưng không phải là không có rủi ro nếu tên ứng dụng của bạn bắt đầu bằng một kí tự rất phổ biến.
Hãy suy nghĩ về các app trên thị trường, đặc biệt nếu bạn đang cạnh tranh trực tiếp với những ứng dụng đó. Hãy lựa chọn một hướng đi khác nếu không muốn bị nhầm lẫn hoặc thậm chí là đồng nhất với họ.
Có lẽ, sự gắn kết quá lâu của Skype với chữ ‘S’ trong hình ảnh đám mây, đã khiến Skyscanner đưa ra biểu tượng trừu tượng nhỏ gọn cho app icon của họ.
Sử dụng chữ cái là một sự lựa chọn rất an toàn, đặc biệt nếu logo ứng dụng có một phông chữ đặc biệt được liên quan đến nó.
Lấy ví dụ như kí tự “F” của Facebook trở nên đặc biệt dễ nhận biết nhờ vào sự kết hợp giữa logo công ty với phiên bản sửa đổi của phông chữ Klavika Bold.
Nhưng dường như ngay cả Facebook cũng không thể quyết định xem chữ cái hay biểu tượng thì phù hợp nhất với app icon mà Facebook đang xây dựng. Tại sao người ta lại đưa tia chớp của Harry Potter trở thành icon Messenger thay vì sử dụng chữ ‘m’ trong đoạn thoại bong bóng?
Sử dụng sơ đồ phối màu tương tự
Điều tồi tệ hơn cả app icon xấu, đó là một biểu tượng ứng dụng đẹp nhưng chứa đựng nội dung không hấp dẫn và lỗi thời. Ấn tượng đầu tiên rất quan trọng, nhưng nếu bạn không thể đáp ứng được yêu cầu khách hàng đặt ra bạn sẽ thất bại.
Dưới đây là tip chỉ dẫn từ Dan Counsell – người đã đưa ra các ví dụ về cách Ember và Clear giữ sự nhất quán từ khi mở ứng dụng tới lúc người dùng thực sự sử dụng nó:
Mặc dù vậy, điều này không có nghĩa rằng tất cả mọi thứ phải được thực hiện chính xác như nhau.
Chẳng hạn, Take Words With Friends đã bổ sung thêm một trái tim và cỏ ba lá vào biểu tượng ứng dụng cho Ngày Valentine và Ngày của Thánh Patrick. Đây chắc chắn là giải pháp rất phù hợp, miễn là người dùng cập nhật ứng dụng thường xuyên, kịp thời.
Và đây là kết quả:
Phản ánh mục đích của ứng dụng
Bạn có nhớ khi Instagram thay đổi biểu tượng? Nhiều người không biết rằng Instagram đã có app icon trước khi thay đổi thành một cái máy ảnh màu nâu với dải cầu vồng mà mọi người đều biết và yêu thích.
Lý do đưa ra cho việc thay đổi logo đầu tiên: “Biểu tượng cũ không liên quan gì đến Instagram”. Với ý nghĩ đó, thật là dễ hiểu tại sao Instagram lại quyết định thay đổi bộ logo thành:
Biểu tượng máy ảnh nâu cổ điển gợi nhớ những bức hình được chụp bởi chiếc máy ảnh Polaroid, và không có liên quan gì đến tương lai của ngành nhiếp ảnh. Và với 80 triệu ảnh được chia sẻ mỗi ngày trên Instagram, đó là chính xác là những gì Instagram đã làm được – cho dù bạn thích hay không
Kết luận
Thật đáng thất vọng, nhưng như đã dự đoán, không có lựa chọn nào được đánh giá là tốt nhất để tạo ra một app icon hoàn hảo cả.
Những lời khuyên trên tuy rất hữu ích, nhưng lại không hề đơn giản, như việc bạn cài đặt đồng hồ – ví dụ, 1 ứng dụng dành cho trẻ em hoặc thanh thiếu niên trông rất khác với ứng dụng dành cho doanh nhân hoặc người về hưu
Hầu hết các Founders, app creators… xây dựng sản phẩm hoặc ứng dụng để giải quyết một vấn đề gặp phải trong cuộc sống. Nói cách khác, bạn có thể trở thành đại diện tốt cho chính thị trường mục tiêu của bạn. Hãy suy nghĩ về các app icon mà bạn cảm thấy bị thu hút, hoặc ít nhất bạn cũng phải có tấm lý sẵn sàng để app icon trên màn hình chính của mình. Đó chính là cách xây dựng app icon thành công.
Và, thậm chí nếu bạn kết thúc với một app icon thực sự đáng thất vọng thì ít ra nó cũng có thể “nổi tiếng” trên Reddit.
Đó là vào một bữa sáng bình thường như mọi người tại San Francisco, Louis cảm thấy thật tự tin khi bước vào quán ăn ưa thích của mình để mua một cốc cafe. Anh dạo bước đi đến công ty của mình, ánh mặt trời rạng rỡ như đang chào đón anh. Tất cả bắt đầu từ căn hộ nhỏ bé của Louis, nơi anh và đồng nghiệp bỏ ra tới 3 tháng code để tạo ra Saas, và giúp cho công ty có nguồn thu nhập khủng lên tới $10M hàng năm.
Chỉ vài ngày sau đó (diễn ra vào tháng 2, 2016), giá cổ phiếu của SaaS giảm tới hơn 30%. Khiến cho một số công ty công nghệ như Tableau bị giảm giá trị tới hơn một nửa. Một phần nguyên nhân là do Linkedin liên kết với Microsoft. Buổi sáng thứ hai tiếp theo không còn ấm áp nữa, Louis phải che người với chiếc áo khoác của anh khi cơn gió lạnh như băng cứa vào người anh. Đó cũng là lúc Cloud 3.0 được tung ra.
SaaS đang dần chết đi
Cloud vốn luôn thân thiện đối với các doanh nhân, đặc biệt là sau khi Salesforce được khai sinh. Một môi trường vô cùng màu mỡ cho các công ty bởi dịch vụ tốt, set up dễ dàng, quản lí lại cực đơn giản. Sản phẩm làm ra được cải thiện nhanh chóng và làm hài lòng khách hàng.
Tuy nhiên như Gil Dibner đã nói – sự thành công của SaaS lại chính là nguyên nhân dẫn đến sự tàn lụi của chính nó:
Bởi tính sẵn có và áp dụng hàng loạt từ cloud-based (SaaS) technology khiến cho việc tạo ra các software system cao cấp trở nên quá dễ dàng, nhanh chóng và rẻ đến mức khiến cho giá trị của chúng bị mất đi. Chính do việc software tràn lan đã khiến cho giá trị thu được từ software biến mất. Nói cách khác, khả năng viết và deploy code không còn là một giá trị cốt lõi nữa.
Trong thời đại của cloud và open source, việc kiếm tiền từ bán các sản phẩm software cao cấp có sử dụng cloud làm kênh phân phối trở nên khó khăn hơn bởi sự hiện diện của open source. Các công ty chỉ biết tập trung vào phát triển sản phẩm mà không quan tâm đến vấn đề của người dùng sẽ rất khó mà thành công được.
Chính Louis và các doanh nhân khác đã không thấy được 2 vấn đề rất lớn đối với cách kinh doanh mới của họ: Chi phí cho Stacking và Switching
Stacking
Các đế chế phần mềm trong quá khứ như Oracle, SAP, etc – có con đường phát triển rất dễ dàng: turn-key M&A. Họ mua những công ty phần mềm đang lên, cắt bớt quỹ tiền cho việc phát triển sản phẩm và sử dụng đội ngũ sale của mình để đẩy mạnh việc phân phối. Thế là chỉ trong một đêm, công ty với giá trị $10M sẽ tăng chóng mặt lên $50M hoặc $100M.
Thế nhưng giờ đây, với SaaS,software vẫn luôn được cải thiện, phát triển và quản lí bởi product và engineering teams. Giá trị của hợp đồng (tính theo tháng) sẽ bị giảm so với chi phí tìm kiếm khách hàng. Như vậy để có lời thì phải đầu tư rất nhiều, và chỉ có khách hàng lâu năm, hài lòng với sản phẩm mới sẵn sàng bỏ tiền ra mua.
Như vậy với SaaS, team phải nhỏ để tiền lãi được nhiều hoặc qui mô đủ lớn để có thể tạo ra tiền lời. Mọi thứ còn lại sẽ chỉ khiến cho bạn bị lỗ vốn.
Như vậy việc Stacking doanh thu không còn đơn giản như xưa nữa.
Switching
Các công ty SaaS sẽ luôn có khách hàng mới tìm đến, họ đều rất dễ tính, không phải tốn công sức để mồi chài thu hút. Tuy nhiên điều đó cũng đúng với các đối thủ của SaaS. Không những thế, nhiều công ty còn muốn việc khách hàng thay đổi lựa chọn dễ dàng hơn để họ có thể thu hút được nhiều người dùng tìm năng. Tuy nhiên điều đó càng khiến user thiếu đi sự trung thành đối với sản phẩm.
Peter cảm thấy vô cùng chán nản bởi các khách hàng không hề muốn sử dụng software của công ty bởi nó quá rắc rối và tốn công khi phải thay đổi một software. Do đó, Peter và team của mình đã tạo ra một phần mềm làm cầu nối để giúp cho việc switch sử dụng SaaS. Và khi developer được chạm vào nó, việc kết nối trao đổi ngay lập tức đạt tới một level hoàn toàn mới.
Sự thành công của SaaS lại chính là thứ đã giết chết nó bởi thời gian và chi phí bỏ ra để phát triển một software đã bị giảm đi rất nhiều. Khiến cho nhiều công ty như bị lạc vào vùng đất cằn cỗi, không đủ lớn để có thấy tạo ra lợi nhuận, cũng không có khả năng phát triển bởi quá nhiều đối thủ đến từ đủ các nhóm như cao cấp, trung cấp và bình dân.
Khi Google tung ra tool trợ giúp tạo ra ứng dụng, giúp cho việc thay thế và phát triển ứng dụng không còn là điều lạ lẫm nữa, chúng ta đều biết nó sẽ khiến bộ mặt của IT thay đổi hoàn toàn.
Bước vào thời đại của Cloud 3.0
Phiên bản tiếp theo của Cloud software sẽ châm ngòi nổ cho các nhà cung cấp đưa ra các offer mới. Tuy nhiên nó sẽ không còn giống như cũ – mà thay vào đó là các team phát triển nhỏ kèm theo các software đi kèm với nhiều dịch vụ kỹ lưỡng.
Sự khác biệt của các công ty dùng Cloud 3.0:
Kết nối từ mọi nơi: Chỉ với một click, bạn đã có thể kết nối với tất cả các platforms với những nguồn dữ liệu liên quan cũng như các tool vô cùng mạnh mẽ.
Open platform: APIs được phát triển hoàn thiện với đa dạng các function, kèm theo khả năng lưu trữ core data.
Programmatic: Không còn lo lắng về interfaces, dashboards hoặc logins
III: Solution Ecosystem – Cung cấp giải pháp cho các developer
Có lẽ sẽ không có gì đáng ngạc nhiên khi Salesforce — công ty sáng lập ra “The Cloud”, sẽ trở thành kiểu mẫu cho các công ty thế hệ tiếp theo bởi:
Nó là một lược đồ chuẩn cho CRM data
Dễ dàng tích hợp với hàng trăm giải pháp
Mối quan hệ với hàng nghìn nhà thầu chuyên gia trong phát triển software.
Tin rằng sự tiến hóa của ngành IT sẽ càng mạnh mẽ hơn khi mối quan hệ giữa các developer và nhà đầu tư ngày càng khăn khít hơn. Hãy tưởng tượng xem, hàng triệu công ty được trợ giúp bởi các nhà thầu và chuyên gia hàng đầu về giải pháp.
Các khách hàng của Louis bắt đầu muốn từ bỏ sản phẩm của công ty bởi mức giá không còn phù hợp. Đây cũng đánh dấu thời đại lụi tàn của SaaS khi số lượng các công ty phát triển ngày càng ít đi. Giờ đã xa rồi cái thời đại bỏ tiền đầu tư một cách mù quáng mà thay đó là sự phát triển giữa mối quan hệ các công ty và nhà đầu tư.
Vì thế các CEO hãy luôn tự hỏi bản thân về sản phẩm của mình. Nó đặc biệt ở điểm nào? Liệu có thích hợp với thị trường không? Làm cách nào để ngăn chặn việc copy sản phẩm của mình và bị bán ra với giá chỉ bằng 1/10 của thị trường? Có thể bạn và Louis cũng đang trăn trở câu hỏi tương tự…..
Bài viết này được dịch từ nguồn http://qiita.com mà theo mình khá hữu ích đối với web developer muốn tối ưu hoá website (SEO) với các search engine (bộ máy tìm kiếm) như Google, Bing, …
Trong khi đang làm việc tại công ty Basic (1 công ty của Nhật hoạt động trong lĩnh vực Web & Media Marketing, vận hành 2 website ferret và ferretOne), tôi được giao nhiệm vụ tối ưu hoá công cụ tìm kiếm cho website phocase (1 website bán phụ kiện điện thoại), để hoàn thành công việc này tôi đã phải tìm hiểu và học thêm các kiến thức, tiện đây xin được tổng hợp lại và chia sẻ với các bạn những điều cần nhớ về SEO với vai trò là 1 kỹ sư.
TLDR; Bài viết này dành cho nhiều đối tượng nên tương đối dài, hãy chọn lọc các kiến thức cần thiết cho mình thôi nhé :v
★ Bạn có thể nhận được gì khi đọc bài viết này ?
Sự tương tác giữa các Marketer và Director trở nên dễ dàng hơn
Nhận biết các đoạn code mà vô tình làm giảm thứ hạng của website trên bộ máy tìm kiếm
Đề xuất các giải pháp SEO có thể thực hiện được ở phía Developer
Nắm bắt được bức tranh/bối cảnh SEO năm 2017
Nắm bắt chính xác tài liệu được Google chính thức công khai
Có thể tìm kiếm rất nhiều thông tin trên các trang web, nhưng tối thiểu thì hãy thực hiện những chính sách được Google đưa ra về rule của 1 website.
Hãy tìm kiếm trong Search Console Help các từ khoá liên quan tới các công việc đã thực hiện từ trước, rất có thể bạn sẽ phát hiện ra những kỹ thuật bị bỏ sót mà mình không hề nghĩ tới.
Chẳng hạn nếu như bạn có sử dụng thẻ alt với ảnh trên website, thì tôi khuyên bạn nên thử tìm kiếm trong Search Console Help các ảnh đã được đánh tag trước đó.
Việc nhồi nhét quá nhiều keyword trong thẻ alt có thể khiến search engineer đưa vào danh sách spam, đây cũng có thể là cách để bạn phòng tránh việc đó. Search Console Help
Chính sách của Google đối với Mobile Site
Mobile First Index (MFI)
Ngày 5/11/2016, Google chính thức công bố chính sách của mình đối với Mobile site: Mobile-first Indexing
Về cơ bản, cho tới thời điểm hiện tại ngoài rank được đánh cho các website hướng PC Desktop, Google còn bổ sung thêm rank cho các website chú trọng nội dung và thiết kế tới SP (Smart phone)
Ngày 5/4/2017, Tại hội nghị Next10x Conference, Các kỹ sư của Google đã chính thức công bố mục tiêu áp dụng vào trong năm nay, tuy nhiên chưa công bố chính thức khoảng thời gian.
Trước khi áp dụng MFI (Hiện tại)
PC Search: Hiển thị theo trình tự của rank cho nội dung PC site
SP Search: Hiển thị theo trình tự của rank cho nội dung PC site
Sau khi áp dụng MFI (Chưa xác định thời gian)
PC Search: Hiển thị theo trình tự chú trọng vào rank cho nội dung SP site (Không có nghĩa là không tính đến rank của PC site)
SP Search: Hiển thị theo trình tự của rank cho nội dung SP site
★ Các site có khả năng chịu ảnh hưởng:
Có sự khác biện lớn giữa phiên bản PC và SP
Còn nhiều thông tin tồn tại trên phiên bản cho PC nhưng lại ko có trên phiên bản SP
Đã hỗ trợ và có chiến lược SEO cho PC site nhưng lại chưa có cho SP site
Ngoài header vs footer ra, các nội dung chính là khác nhau
Cấu trúc HTML khác nhau
Tốc độ hiển thị cho SP site quá chậm
Mobile Friendly
Ngày 21/4/2015, Google công bố : thứ tự xuất hiện trên kết quả tìm kiếm có liên quan tới UI, UX trong trường hợp truy cập trang web trên Smart Phone Device Rolling out the mobile-friendly update
Chỉ ảnh hưởng tới thứ tự xuất hiện kết quả tìm kiếm trên Mobile Device
Ảnh hưởng trong phạm vi toàn bộ các ngôn ngữ trên thế giới
Áp dụng cho các page riêng rẽ, chứ không phải toàn bộ trang web
Nếu như website đó không được coi là Mobile Friendly sẽ có thứ tự thấp và không được ưu tiên xuất hiện trên kết quả tìm kiếm. Điều này có tác động trực tiếp tới doanh thu của các website thương mại điện tử (EC site)
Sử dụng website sau, có thể kiểm tra tính thân thiện với thiết bị mobile của 1 trang web Mobile Friendly Check
★ Các hạng mục cần kiểm tra
Font size có thích hợp (>= 16px) không?
Có sử dụng thẻ meta và chỉ định viewport cho mobile không?
Khoảng cách của các liên kết có bị quá hẹp không? (phòng ngừa lỗi)
Nội dung trang web có bị tràn ra ngoài màn hình không?
Website có được hiển thị trong vòng 3s không? (Nếu việc hiển thị tốn quá > 3s, thì 40% người dùng sẽ thoát trang web đó)
Đối với các website không thoả mãn tối thiểu các điều kiện trên sẽ có thể có có thứ hạng thấp trong kết quả tìm kiếm.
★ Mobile Friendly Support & Yêu cầu craw lại website
Bằng cách sử dụng GoogleSearchConsole, bạn có thể nắm rõ được chi tiết các thành phần trên website mình không thoả mãn các hạng mục kiểm tra phía trên. Google Webmaster Home
Sau khi giải quyết các vấn đề trên, hãy gửi yêu cầu cho Google crawl lại các URL đó.
Chi tiết các bạn có thể tham khảo link sau về việc Yêu cầu Google crawl lại các URL
★ Các hạng mục để đánh giá về UX
First view của trang web sẽ được hiển thị trong vòng 1 giây (Google recommended)
Chuẩn bị riêng biệt kích thước hình ảnh với PC Site, để giảm dung lượng của một trang web
Sử dụng công cụ YUI Compressor và JSMin để rút ngắn đoạn code dài như thư viện
Thiết lập các nội dung có thể tab được lớn hơn 48px
Để xác nhận tốc độ hiển thị của web site, bạn có thể dụng công cụ: PageSpeed Insights
★ Chuyển tiếp quảng cáo
Đối với các quảng cáo chuyển tiếp thì đến khi hiển thị target page, thì hiển thị quảng cáo với link [Skip this page] giống như ảnh bên dưới, từ tháng 11 năm 2016 sẽ vi phạm điều luật của Google.
Được sử dụng như Sitemap, có format tương tự RSS và Atom trong RSS Reader.。
★ Lợi ích khi đăng ký Feed
Chỉ URL được cập nhật gần đây nhất được đăng ký.
Tần suất Crawl cao hơn Sitemap thông thường
Việc thông báo cho Google các Page được create/update gần đây nhất là một phương pháp sử dụng Feed có tần suất Crawl cao hơn một cách hiệu quả.
★ Thực hiện index theo thời gian thực dựa vào PubSubHubbub (PuSH)
Một cách để thực hiện index realtime khác đó là: Sử dụng phương thức PubSubHubbub (hay còn gọi là PuSH) giúp thông báo tới Google các thay đổi tại thời điểm mà các trang được update.
Trường hợp code bằng PHP, có thể sử dụng file được Download từ thư viện sau đây: pubsubhubbub-php-master/library/publisher.php
require_once './publisher.php' ;
$publisher = new Publisher('http://pubsubhubbub.appspot.com/');
$publisher->publish_update('http://example.com/article/1');
Đăng ký Sitemap
★ HTML Sitemap
Sitemap cho người sử dụng truy cập trang web
Thường xuyên quản lý để tránh các liên kết lỗi
Việc phân loại sẵn các Category giúp cải thiện khả năng sử dụng
★ XML Sitemap
Việc tạo sẵn một Sitemap có định dạng XML chính là công cụ đắc lực, trợ giúp Search Engine index website của bạn
Dưới đây là các loại Sitemap:
Loại File XML
Vai trò
sitemap.xml
Mô tả cấu trúc website, bao gồm cả mobile sitemap
movie.xml
Hiển thị các nội dung video trong tìm kiếm
image.xml
Hiển thị các nội dung ảnh trong tìm kiếm
news.xml
Khai báo các tệp tin được gửi tới Google News
Với mỗi file XML được cài đặt chính xác, góp phần xúc tiến việc index website của bạn
Tuy nhiên nếu crawler không visit, chúng ta cần thực hiện cải thiện lại Sitemap đã tạo trước đó
Trên SP site việc giới hạn quyền truy cập webiste mobile trên device = .htaccess có thể khiến Search Engine Bot không vô được, vì vậy hãy cho phép Googlebot-Mobile có quyền truy cập.
Trong thực tế, đối với việc create/submit Sitemap chúng ta có thể tham khảo thêm tại link Build and submit a sitemap , có hướng dẫn chi tiết các loại tool giúp tạo và test sitemap, rất tiện lợi.
★ Video, Image Sitemap
Việc Crawler thu thập thông tin tìm kiếm liên quan tới Video và Ảnh là tương đối khó khăn, do đó chúng ta cần sử dụng Sitemap chuyên dụng có chứa thông tin cho Video và Image.
Về cách create thì bạn có thể tạo file XML chỉ chứa các video và ảnh mới tạo hoặc bổ sung chúng vào 1 file XML đã tồn tại đều ok, tuy nhiên hãy thiết lập một sitemap chứa nhiều thông tin. Sitemap Protocol : Video extension, Title, Duration, Description
Hơn nữa, bằng cách sử dụng Video Sitemap, khi tiến hành tìm kiếm Video lẫn Image trong Search Engine, Video có thể được tìm thấy trong kết quả.
Ví dụ file movie.xml như sau:
Khi vận hành 1 EC site (Website thương mại điện tử) sử dụng Image Sitemap, doanh nghiệp có thể thu hút và tiếp cận được đối tượng người dùng tìm kiếm sản phẩm muốn mua bằng ảnh trên máy tìm kiếm.
Những điều cần lưu ý khi sử dụng tag HTML
【Title】
Trong SEO, thẻ Title là một trong số những thẻ tag có tầm ảnh hưởng nhất, Trong 1 page chỉ được có 1 thẻ title trong head tag. index.html
<head>
<title>Page title</title>
</head>
Nếu trong thẻ title có từ khóa tìm kiếm của user sẽ được bôi đậm trên kết quả tìm kiếm
Mỗi Page nên có 1 thẻ title với nội dung khác nhau
Trên kết quả tìm kiếm của Search Engine sẽ chỉ hiển thị tối đa ~32 ký tự trong nội dung của thẻ title
Nếu trong thẻ title có chứa các từ khóa không cần thiết sẽ làm giảm trọng số của từ khóa mong muốn được tìm kiếm
Nên lựa chọn nội dung của thẻ title sao cho dựa vào đó có thể đoán được phần nào nội dung của web page
Cần lưu ý rằng trên Search Engine sẽ chỉ hiển thị khoảng 32 ký tự cho tiêu đề (title) của 1 website, và thậm chí là 24 ký tự khi người dùng tìm kiếm trên thiết bị di dộng.
Nếu đặt tiêu đề cho page không liên quan tới nội dung của page sẽ làm giảm lượng người dùng truy cập, dẫn tới rank website bị giảm. Cho dù người dùng có truy cập vào nhưng do nội dung chính và tiêu đề không giống nhau, họ sẽ mau chóng rời đi -> tỷ lệ bounce rate sẽ ngày càng tăng.
【Description】
Trước tiên khi thiết lập Description, nội dung hiển thị trên search engine sẽ thay đổi tại đây:
Việc thêm mô tả cho nội dung mà người dùng mong muốn tìm kiếm, góp phần làm tăng tỷ lệ click rate trên search result.
Tuy nhiên nếu xét về mức độ ảnh hưởng về ranking trong thứ hạng xuất hiện trên Search Engine thì có vẻ là không lớn lắm.
Hơn nữa ở thời điểm hiện tại dù không có mô tả rõ ràng cho page thì Google cũng hiện thị Description mà nó tự động tạo ra cho web page.
Dựa vào các mô tả mà Google tự động sinh ra cho trang web, với các trường hợp đưa ra Description phán đoán chính xác thông tin trên website:
Khuyến khích để Google tự động tạo description cho web page
Các page khác nhau phải có nội dung khác nhau
Nội dung description cần nhất quán với title tag
Trên search engine chỉ hiển thị khoảng 124 ký tự cho phần description
Khi tìm kiếm bằng thiết bị di động thì chỉ hiển thị khoảng 80 ký tự cho phần description
Không bắt buộc văn phong phải chính xác tuy nhiên nội dung của tag phải rõ ràng, chuẩn xác.
Do việc lạm dụng thẻ h1 quá nhiều dẫn tới Google đã hạ chỉ số đánh giá của nó, tuy nhiên do vẫn còn xuất hiện trên kết quả tìm kiếm, nên đối với SEO vẫn còn khá quan trọng.
Mỗi page chỉ nên có 1 thẻ h1
Mặc dù Google có công bố chính thức rằng có thể thiết lập nhiều thẻ h1, tuy nhiên nếu làm vậy sẽ gây khó khăn cho việc nhận biết chủ đề của nội dung web page
Có thể thiết thể ảnh bên trong thẻ tag h1
/iphone6/?color="white"
<h1>
<img src="/images/iphone6_white.jpg" alt="Danh sách bao da cho điện thoại iPhone 6 được nữ giới ưa chuộm" />
</h1>
Với cách đặt ảnh như trên thì nó cũng được nhận diện như 1 phần của h1 tag, do đó hãy mô tả chính xác ảnh bằng cách thêm nội dung vào thuộc tính alt (văn bản thay thế).
★ Keyword truyền tải bởi TDH (Title Description H1)
Nếu bạn đặt từ khóa mình muốn SEO trong tất cả các thẻ TDH（Title Description H1）sẽ là cách đầu tiên giúp Google nhận biết chính xác từ khóa cần SEO.
Do đó, cần xem xét 3 thẻ trên có chứa từ khóa mình cần lên top không?
Lưu ý với thẻ【img】và thuộc tính 【alt】
Bằng cách sử dụng thuộc tính alt mô tả nội dung trong ảnh và video, thì người khiếm thị (Sử dụng tính năng đọc văn bản) hoặc người dùng có tốc độ mạng internet chậm cũng có thể dễ dàng nhận được thông tin về website của bạn, điều này được Google đánh giá rất cao.
<img src="puppy.jpg" alt=""/>
<img src="puppy.jpg" alt="puppy dog baby
dog pup pups puppies doggies pups litter puppies dog retriever
labrador wolfhound setter pointer puppy jack russell terrier
puppies dog food cheap dogfood puppy food"/>
Việc nhồi nhét quá nhiều từ khóa vào thuộc tính alt dẫn tới việc bị google nhận diện thành Spam content.
Cách sử dụng tối ưu thẻ img với thuộc tínhalt
<img src="puppy.jpg" alt="puppy"/>
<img src="puppy.jpg" alt="Dalmatian puppy playing fetch">
Nếu có thể thì tốt nhất hãy mô tả bằng câu văn thay vì chỉ sử dụng 1 từ khóa cho các img tag.
★ Các hạng mục khác được khuyến khi khi sử dụng thẻ 【img】 (Không bắt buộc)
Thống nhất file name và nội dung thuộc tính alt
Có thể thiết lập nội dung trong alt mà không có khoảng trắng
Cố gắng thiết lập mô tả cho ảnh sao cho gần với nội dung trong bức ảnh đó nhất có thể
Các ảnh tương tự nhau thì nên để trong cùng 1 thư mục host
Nếu một ảnh giống nhau được sử dụng ở nhiều nơi, thì hãy mô tả thật chi tiết ảnh đó trên website của mình, khi đó Google sẽ nhận diện ảnh của site bạn là original image, và hiển thị trên search result !
★ Khả năng index và thu thập dữ liệu ở cùng thời điểm
【Khả năng thu thập dữ liệu】
Để crawler của GoogleBot dễ dàng thu thập dữ liệu, chúng ta cần
Cấu trúc, sử dụng thẻ HTML phải đúng chuẩn
Với các page có nội dung liên quan cần có liên kết tới nhau, để đảm bảo khả năng crawler trải dài trên toàn bộ website
【Khả năng index – đánh chỉ mục tìm kiếm】
Nếu đã chuẩn bị sẵn các thuộc tính alt cho ảnh, âm thanh, video trên website của mình thì khi GoogleBot crawl sẽ index được chính xác nội dung của chúng.
【a】tag
Hãy thiết lập chuẩn xác anchor link (text), việc này sẽ giúp truyền tải thông tin tới Google dễ dàng hơn.
Các implement có thể ảnh hưởng tới khả năng crawler
Sử dụng javascript để di chuyển tới link cần vô (Google có khả năng nhận biết điều đó)
Tìm kiếm bên trong website bằng cách gửi form
Link content sử dụng FLASH
【rel=”next” or “prev”】
Khi thiết lập Pagination cho website cần chỉ định thuộc tính rel với giá trị next hoặc prev
★ rel=”prev/next” được xếp hạng ưu tiên hơn rel=”canonical”
Cho dù bạn có để link trên các page 2, 3, 4 về page 1 bằng thuộc tính canonical, thì next và prev vẫn được đánh giá ưu tiên hơn canonical, do đó với các URL không có parameter giống nhau như bên dưới sẽ không được tính là next và prev.
// page=
http://example.com/iphone7?color=red&page=1
http://example.com/iphone7?color=red&page=2
http://example.com/iphone7?color=red&page=3
http://example.com/iphone7?color=red&page=4
// viết tắt p=
http://example.com/foo.html
http://example.com/foo.html?p=2
http://example.com/foo.html?p=3
// Sử dụng URL path thay thế cho param page
http://example.com/foo/1/
http://example.com/foo/2/
http://example.com/foo/3/
★ Các điểm cần lưu ý
1 page chỉ được phép có 1 next và 1 prev
Absolute path thì ngon hơn Relative path URL (Không bắt buộc)
Trường hợp hiển thị kết quả tìm kiếm của 1 page có sử dụng điều kiện filter, thì ở trong trang điều kiện đó cũng cần bổ sung thuốc tính next và prev
Nếu bạn không muốn hiển thị một page trên kết quả tìm kiếm, hãy học cách sử dụng canonical
【rel=”nofollow”】
Với các target link có gắn thuộc tính rel="nofollow" sẽ không được search engine visit. Thuộc tính này xuất hiện ở thẻ meta và thẻ a.
Hơn nữa, khi GoogleBot visit target link, nó cũng tính toán độ tin cậy của các target link trên website và đánh giá thứ hạng site đó.
★ Khuyến khích sử dụng “nofollow” với link trỏ tới các website sau
Các bảng tin và ô comment có thể được người dùng nhập
Liên kết tới bookmark site
Liên kết tới ranking site
Liên kết khi nhận được đánh giá bằng tiền
powerd by... link
★ Các liên kết có thể gây ảnh hướng xấu tới website cần lưu ý
Các link mà người dùng không nhìn thấy, bị ẩn đi cũng như không click được
Liên kết qua lại bằng các trang web hỗ trợ liên kết lẫn nhau
Các liên kết đến các trang web được Google xác định là có mã nguồn độc hại
Sử dụng【robots.txt】để không bị crawl thừa
Nếu không muốn search engin crawl trong những trường hợp dưới đây, hãy thiết lập file robot.txt
Các web page có chất lượng thấp, các web page không muốn xuất hiện trên kết quả tìm kiếm
File robots.txt được đặt ở thư mục gốc (root directory) của website, Các Bot search engine sẽ tự động đọc và lấy ra.
Hãy sử dụng nó khi bạn có chủ ý muốn 1 page nào đó trên website của mình không xuất hiện trên kết quả tìm kiếm của Google.
★ Điểm khác biệt với robots.txt
Sử dụng robots.txt đồng nghĩa với việc không cho Bot Search Enginer thu thập dữ liệu cũng như xếp hạng page đó.
Trong khi sử dụng noindex thì sau một thời điểm nào đó khi link tới website của bạn được share nhiều trên mạng xã hội, thì SEO rank vẫn còn và link tới web page đó vẫn được xếp hạng.
★ Mục đích chính của việc sử dụng “noindex”
Với các page chất lượng thấp, nếu có gắn thuộc tính noindex sẽ ko bị xếp hạng thấp website
Support các page chưa được setting trong robots.txt cho tới thời điểm hiện tại
404 Page (Thiết lập ở các page trả về status lỗi 404)
Rich Snippets là đoạn thông tin đặc biệt dùng để hiển thị các thông tin thêm có trong những bài viết đặc biệt (bài đánh giá, sản phẩm, ứng dụng, công thức nấu ăn, địa chỉ công ty..v.v..) trên các máy tìm kiếm (Google, Yahoo, Bing) nhằm cung cấp thêm những thông tin giá trị đến người tìm kiếm giúp họ xác định kết quả tìm kiếm mà họ đang cần. Nhìn vào kết quả tìm kiếm sau, ta thấy có một điều rất đặc biệt: Xuất hiện ảnh thumbnail trong kết quả :v
Rich Snippets có 10 loại phổ biến sau:
Author
Breadcrumbs
Event
Organizations
People
Products
Recipes
Review
Software Application
Facebook Share
Việc sử dụng các markup bằng cấu trúc được công bố trên schema.org sẽ làm tăng khả năng hiển thị rich snippet trên kết quả tìm kiếm của google.
Hiện tại thì rich snippet không ảnh hưởng tới rank của 1 website, tuy nhiên có thể ảnh hưởng tới thứ hạng trong kết quả tìm kiếm: Google Webmaster Central office-hours hangout
Ví dụ về 1 page có hiển thị snippets
<section itemscope itemtype="http://schema.org/Game">
<h1>Monster Hunter Game Series</h1>
<span itemprop="name">Monster Hunter Double Cross</span>
<p itemprop="description">Latest Monhan Series with 6 large main Monsters</p>
<div itemprop="author" itemscope itemtype="http://schema.org/Corporation">
<p itemprop="name">CONAMI</p>
<p itemprop="email">example@conamikan.jp</p>
</div>
</section>
Những lưu ý về URL (Đường dẫn)
【Soft 404】
Tình trang một page có status=200 nhưng nội dung page đó lại cho biết URL này không tồn tại được gọi là soft 404
Việc hiển thị 1 web page có nội dung giống nhau nhưng với nhiều URL khác nhau trên trình duyệt xảy ra khá phổ biến. Tuy nhiên, nếu việc này xảy ra với Google search engine thì có thể website của bạn sẽ bị áp dụng các hình phạt làm giảm thứ hạng tìm kiếm. Chính vì lẽ đó chúng ta cần chuẩn hóa lại URL.
★ Các lợi ích có được khi quy chuẩn hóa đường dẫn
Giả sử: Việc url một website có chứa www và ko chưa www được coi là các page khác nhau
Vấn đề: Lúc này việc đánh giá rank cho website bị phân tán giữa các link có và ko có www
Hướng giải quyết: Có thể chuyển hướng (301 redirect) các page có www sang page ko có www
Khi thay đổi tên miền/url, hãy sử dụng chuyển hướng 301 sang đường dẫn mới
Từ sau khi thiết lập 301 Redirect, có thể mất tới một tháng đẻ Bot Search crawl lại website
★ Ví dụ sử dụng 301 Redirect
Sử dụng 301 Redirect trong việc có và không có www trên URL
Loại bỏ việc thêm index.html vào sau URL
Trường hợp Pagination /search/?page=1 và /search/ hiển thị nội dung giống nhau
Trường hợp có và ko có dấu slash (/) sau URL. Ex: /search/ và /search
Lưu ý khi code: tùy vào chức năng của trình duyệt web, nếu thực hiện điều hướng 301 từ 1 URL tới 1 URL nhất định thì việc di chuyển page này sẽ được lưu vào cache cho tới khi trình duyệt xóa nó đi.
【Canonical】
Cùng một nội dung tương tự nhau (Có thể là 1 bài viết được chia làm nhiều phần), thì không chỉ người dùng mà Google Bot cũng muốn biết bài viết nào là bài viết gốc, câu trả lời cho vấn đề này chính là thuộc tính rel=”canonical”.
Mặt khác chắc hẳn bạn cũng gặp phải trường hợp Single Page và Search Page có chứa 1 lượng lớn nội dung trùng lặp. Nhờ việc thiết lập canonical cho 1 page, mà ta có thể ngăn ngừa được việc Google đánh tụt thứ hạng tìm kiếm từ nội dung bị trùng lặp
Ví dụ khi website có 2 phiên bản cho Desktop và Mobile:
canonical dùng để thông báo với Search Engine đâu là page gốc (original page). Có thể ví như quan hệ n:1 alternate trở thành quan hệ 1:1 khi cùng tham chiếu tới canonical và alternate
Thuộc tính canonical và alternate trên website https://ferret-plus.com/1426 đã giúp Bot Search Engine biết được phiên bản nào là website dành cho thiết bị di động.
Cloaking
Cloaking là sự che đậy hay che dấu một cái gì đó. Trong kỹ thuật SEO thì cloaking ám chỉ hành động của webmaster che dấu bot của search engine như Google crawl các nội dung mà người dùng nhìn thấy, đồng thời đề xuất cho các cậu Bot nhìn thấy các nội dung được Onpage optimize tốt nhằm mục đích đạt được các vị trí cao trên Search Engine.
Việc tồn tại các thông tin trên website mà hiển thị giữa GoogleBot và người sử dụng khác biệt nhau sẽ ảnh hưởng tới thứ hạng hiển thị của website trên kết quả tìm kiếm. (Website có hành vi này sẽ bị google áp dụng các hình phạt)
Website khi truy cập = PC hiện ra thông báo「Hãy truy cập bằng smart phone」, dù cho khi User-Agent là smart phone truy cập có hiển thị chính xác đi chăng nữa cũng rất có thể bị Google hiểu là Cloaking ???
Website ở tình trạng bị hack cũng có thể bị đưa vào trạng thái Cloaking, hãy thường xuyên quan sát log để tìm ra các hành động khả nghi và tiến hành deploy lại nếu cần.
Đánh giá độ ổn định của URL
Các bộ máy tìm kiếm có tiêu chí để xếp hạng URL là: URL đã cung cấp thông tin cho người sử dụng trong một thời gian dài bao lâu?.
Do đó khi bạn thay đổi URL, sử dụng 301 Redirect thì cũng ko có gì đảm bảo là toàn bộ ranking của URL trên site cũ sẽ được chuyển hết sang URL site mới.
★ Các hạng mục cần kiểm tra khi thiết kế URL
Có chứa ext của file như .php hay không ? Việc này sẽ gây ảnh hưởng nếu chuyển framework ví dụ từ CakePHP sang Rails chẳng hạn.
Có thể dùng dấu – hoặc _ trong URL, tuy nhiên Google khuyến khích sử dụng dấu – để phân tách từ khóa
Toàn bộ ký tự trong URL phải được viết thường
URL dài cũng không vấn đề (Sẽ giải thích sau)
URL không nên chia quá nhiều cấp, nằm sâu trong nhiều directory
Chứa từ khóa thì càng tốt (Có thể chứa tiếng Nhật)
URL không die cho dù sau này có áp dùng nhiều thay đổi SEO đi chăng nữa
Không sinh ra duplicated content
★ Đảm bảo việc thiết kế URL không sinh ra nội dung trùng lặp
Web Page bên dưới sinh ra nội dung trùng lặp, dó đó kiểu thiết kế URL này không được khuyến khích
Ví dụ：Anime Home Page
Hero list page
All characters list page
Khi đó giả sử ta có nhân vật tên là “yamada”, khi đó nội dung 2 trang sau là giống nhau và đều mô tả về “yamada”
heros/yamada.html
characters/yamada.html
Cùng 1 nội dung nhưng lại khác URL là một thiết kế tồi và bị xếp vào duplicated content.
URL dài cũng không vấn đề
Theo Google công bố thì độ dài của URL có thể ngắn hoặc dài tùy ý
Độ dài của URL thì không ảnh hưởng tới ranking
Tuy nhiên cần đủ để nhận diện được URL
Mặc dù không ảnh hưởng tới SEO, tuy nhiên trình duyệt IE chỉ support URL có độ dài tối đa 2083 ký tự, nên hãy setting URL length <= 2083
★ Các khuyến khích về URL:
Vì URL là thứ hiển thị trên kết quả search, nên hãy chọn các từ đơn trong URL có liên quan tới nội dung bài viết
Khi URL có chứa từ ngữ trùng với từ khóa mà user search thì sẽ được bôi đậm trên kết quả
Search engine sử dụng dấu “–” để tách từ, nên URL cũng nên sử dụng dấu “–” để ngăn cách các từ khóa trong nó.
Mặt khác việc sử dụng quá nhiều GET parameter như ?color=2 trong URL có thể khiến URL khó nhớ, dễ nhầm lẫn, và khó chia sẻ. Dẫn tới việc truy cập phải URL không chính xác nếu không đủ parameter.
Cấu trúc liên kết cần được chú trọng hơn cấu trúc thư mục
Như bạn đã biết, hai đường dẫn trên đều là 2 đường dẫn tối ưu cho SEO. Đường dẫn thứ nhất là đường dẫn kiểu file name và đường dẫn thứ hai là đường dẫn theo kiểu thư mục. Câu hỏi đặt ra ở đây là đường dẫn nào tốt hơn?
★ Nếu cấu trúc thư mục quá sâu có thể khiến Bot ko crawl được
Tham khảo link : https://support.google.com/webmasters/answer/156184?hl=vi
Google Bot sẽ crawl theo thứ tự từ nông tới sâu, dó đó URL ở các cấp sâu mà không được liên kết tới bởi page nào trong site có thể rơi vào tình trạng được crawl chậm và không được đánh index.
Với tư cách là developer, bạn đừng quên tạo các link trong site internal liên kết tới các page quan trọng của site.
Lưu ý: Việc tạo cấu trúc thư mục đơn giản chỉ giúp cho Google Bot crawl dễ dàng hơn chứ không ảnh hưởng tới thứ hạng trên Search Result.
★ Cấu trúc liên kết ảnh hưởng tới SEO
Cấu trúc liên kết được tóm gọn trong câu sau: “Khi bạn click vào liên kết bao nhiêu lần cũng vẫn access được page đó”.
Cấu trúc link nếu vượt quá 5 cấp có thể khiến Google index chậm. Về cơ bản chỉ nên setting dưới 4 cấp đổ lại.
Theo kỹ sư John Muelle từ Google thì việc thêm params vào URL của các dynamic page để dễ dàng thay đổi nội dung được khuyến khích.
Just wanted to add that from Google’s point of view, the clean, parameterized URL is generally preferred to any unnecessary URL-rewriting. If you want a nice-looking URL-line in search, use breadcrumb markup instead.
Tuy nhiên trên kết quả search thì với những page động sử dụng params để thay đổi nội dung cần thiết lập thêm Canonical để tránh xảy ra hiện tượng duplicated content.
Dùng GET params sẽ làm giảm index
Việc sử dụng quá nhiều GET params có thể làm khả năng index giảm đi, do đó cần tránh thêm quá nhiều param là URL quá dài, hoặc thực hiển chuyển đổi url động sang url tĩnh với param ngắn hơn.
★ Chuyển đối URL tĩnh
Việc chuyển đổi URL động sang tĩnh có thể hiểu đơn giản như sau: loại bỏ bớt GET params, chuyển nó vào path của URL
Theo nguồn tin chính thức từ Google thì việc 1 website có quá nhiều page không được chú trọng vào nội dung sẽ được coi là 1 website vô nghĩa, chỉ nên tập trung vào 1 số lượng page có nội dung được chú trọng thay vì tạo ra hàng loạt các page có nội dung nghèo nàn.
★ Site ranking
Thông tin chỉ được tồn tại/sở hữu duy nhất bởi website
Có chứ nhiều nội dung dễ hiểu như ảnh và video
Mô tả thông tin chi tiết, rõ ràng và dễ hiểu
Khi implement các page động thì số lượng page được index sẽ tăng lên, do đó cần xác định trước số lượng tối đa page sẽ được sinh ra.
★ Cách thức đối ứng
Sử dụng chức năng URL parameter trong Google Search Console
Xuất phát từ lĩnh vực thương mại điện tử, công ty Exocomets (Thủy Lâm Ngân) tuy mới thành lập nhưng đã mang trong mình tham vọng trở thành sàn giao dịch B2B dành cho các doanh nghiệp Việt với hệ thống hiệu quả, hiện đại, bảo mật và thân thiện. CEO của Exocomets đã có cuộc gặp gỡ thân mật với TopDev để cùng trao đổi, chia sẻ những quan điểm cá nhân về lập trình viên Việt Nam nói chung và tầm nhìn đối với riêng công ty Exocomets.
1/ Chào anh, anh có thể giới thiệu sơ về đội ngũ công ty hiện nay?
Exocomets hiện có bộ máy nhân sự chính và đang tuyển dụng thêm các vị trí nhân sự còn lại. Chủ yếu đang tìm kiếm vị trí web developer.
2/ Theo anh thì thị trường E-commerce có thực sự bão hòa khi đang ngày càng nhiều công ty gia nhập vào cuộc chơi?
Thị trường E-commerce Việt Nam rất tiềm năng với các công ty lớn ở nước ngoài và ở Việt Nam gia nhập ngành, tạo nên nhiều cơ hội và thách thức. Công ty E-commerce phải có nguồn vốn lớn, kĩ thuật tốt, dịch vụ khách hàng hiệu quả nếu không bị loại bỏ khỏi cuộc chơi.
Các bạn dev phải có trách nhiệm xây dựng 1 hệ thống chất lượng, sáng tạo, tiện ích cho người dùng. Hầu hết các trang E-commerce đều khá giống nhau có thể là vì 90% công nghệ đều giống nhau. Nhưng điều quan trọng nhất là phải quan tâm đến người dùng cuối.
3/ Theo anh thì các bạn lập trình viên trong lĩnh vực E-commerce có cần những kiến thức riêng/ công nghê riêng so với các lĩnh vực khác không?
Ngoài lập trình chuyên môn, thì khả năng giao tiếp với các phòng ban cũng là điều rất quan trọng. Tất nhiên đây phải là khả năng lập luận theo ngôn ngữ business, chứ không dừng lại ở ngôn ngữ code.
Ngoài ra họ cần rèn luyện thêm kĩ năng quản lý dự án, kiến trúc hệ thống để hiểu được tổng quát bức tranh cụ thể là mình đang ở vị trí nào, hiểu tiến độ, mục tiêu dự án thì mới có thêm hứng thú, đam mê trong công việc. Ví dụ những bạn muốn tìm tòi về E-commerce, trước tiên cần học và nắm bắt thật chắc những kiến thức về cơ sở dữ liệu để có thể phát triển nền tảng này.
4/ Nhận định chung của anh về chất lượng của web developer tại Việt Nam như thế nào?
Trình độ chuyên môn các bạn ấy giỏi, luôn muốn học hỏi những ngôn ngữ mới, những kiến thức mới trong lĩnh vực IT. Nhưng còn yếu trong chuyên môn sâu, cứ 1-2 năm lại nhảy qua những ngôn ngữ khác.
Để giỏi được 1 lĩnh vực nào đó, cần có ít nhất 3 năm rèn luyện trong ngôn ngữ đó. Cũng như học Tiếng Anh 1-2 năm có thể biết về cơ bản nhưng nếu 2 năm sau chuyển sang tiếng Nhật thì không thể hiểu sâu được.
Điều này có điểm lợi là biết nhiều thứ nhưng điểm yếu là thiếu chuyên môn, hiểu chưa sâu và sẽ gặp rắc rối khi gặp hệ thống lớn.
Ngoài ra, developer cần rèn luyện thêm ở Tiếng Anh ở mức độ trung bình khá trở lên, để giao tiếp được với các đối tác nước ngoài, đọc tài liệu nước ngoài… như vậy, các bạn mới có thể hội nhập với thế giới.
4/ Có nhiều người cho rằng dev Việt tuy chuyên môn tốt nhưng chưa có quy trình làm việc đúng & đa phần công ty phải đem về đào tạo lại…
Điều này không hoàn toàn thuộc về các dev, mà trách nhiệm phụ thuộc vào các nhà lãnh đạo trong đội ngũ IT. Những nhà lãnh đạo cần thiết lập quy trình, cần có business flow, phương pháp quản trị…
5/ Exocomets có xây dựng phương pháp công nghê chung nào khi làm sản phẩm hay phụ thuộc vào yêu cầu từ phía khách hàng?
Với kinh nghiệm và kiến thức đã có của đội ngũ lãnh đạo, Exocomets ưu tiên triển khai 3 phương pháp quản trị và điều hành bộ máy CNTTlà TOGAF-9(The Opening Group Architecture Framework), PRINCE2 và ITIL (Information Technology Infrustructure Library) – phương pháp quản trị hệ thống cùng đội ngũ phân tích, mang đến những giải pháp lưu loát hỗ trợ đội ngũ quản lý cách sử dụng công cụ công nghệ hiệu quả.
6/ Mục tiêu, lộ trình phát triển của 1 lập trình viên tại Exocommets là như thế nào?
Trong quá trình tuyển dụng, EXOCOMETS nhận thấy rằng tố chất quan trọng nhất của một developer là tinh thần ham học hỏi và đam mê giải quyết tận gốc vấn đề. Chúng tôi cũng hiểu rằng, bất cứ nhân tố quan trọng nào cũng cần môi trường thích hợp để phát triển và học hỏi. Vì thế, khi làm việc tại EXOCOMETS, sau 2 tháng hòa nhập với văn hóa công ty, các bạn sẽ được tham gia vào những buổi training và workshop để trau dồi và nâng cao kiến thức kỹ năng.
7/ Anh có thể chia sẻ thêm về văn hóa công ty không?
Văn hóa công ty nằm trong giá trị cốt lõi mà Exocomet sẽ xây dựng, đó chính là PIRI thể hiện tinh thần PASSION- niềm đam mê, INNOVATION – thể hiện môi trường thoải mái đóng góp ý kiến, sáng tạo, RESPONSIBLE – trách nhiệm với bản thân, với thành viên trong công ty, trách nhiệm với khách hàng và INTEGRITY: trung thưc, chính trực.
Exocomets muốn tạo môi trường làm việc thoải mái, mỗi buổi sáng lại có nguồn hứng đóng góp cho công ty, không quá thân cũng không thể quá xa lạ. Đặc biệt Exocomets sẽ là 1 công ty mà tất cả các thành viên đều có cơ hội phát triển.
Chia sẻ thêm từ các bạn nhân viên Exocomets thì môi trường giữa nhân viên với sếp sẽ tùy theo giai đoạn. Khi làm việc cần có khoảng cách để các bạn làm việc hiệu quả hơn. Ngoài giờ làm việc thì vui vẻ với nhau, tạo cảm hứng cho mỗi ngày làm việc.
Nhật Bản từ lâu được biết đến là một trong các nước dẫn đầu thế giới về lĩnh vực khoa học và công nghệ. Và đội ngũ nhân sự lớn chính là một chìa khóa để phát triển cho nền tảng này. Để đáp ứng được nhu cầu của thị trường, Nhật Bản hiện đang hợp tác với rất nhiều quốc gia khác để giải quyết các vấn đề về nguồn nhân lực, trong đó không thể không nhắc đến Việt Nam.
Với dự báo năm 2020, Nhật Bản sẽ có thể thiếu hụt khoảng 50.000 nhân lực trong lĩnh vực IT (Dự báo của Bộ Kinh tế Công thương Nhật Bản – METI), do đó họ luôn không ngừng phải bổ sung nguồn nhân lực từ các nước khác, và Việt Nam chính là đối tác lớn thứ 2 của Nhật Bản trong lĩnh vực gia công phần mềm (vượt cả Ấn Độ đến 13,7%).
Trong thời điểm hiện tại, nguồn nhân lực lập trình tại Việt Nam được phía Nhật Bản đánh giá có chất lượng rất tốt. Chính sự nhiệt huyết, tận tâm trong công việc và khả năng ứng biến cao mà trình độ kỹ thuật của đội ngũ lập trình tại Việt Nam có thể sánh ngang với những lập trình nước Nhật. Theo lời của Tổng Giám đốc Tập đoàn Nissen, ông Nobuyuki Ichiba khẳng định: “Những kỹ sư Việt Nam khi nghe khách hàng nói cũng cần hiểu chính xác điều họ muốn. Kỹ sư Việt không chỉ giỏi về kỹ thuật mà còn có cảm nhận tinh tế, nếu kết hợp được hai phẩm chất này và thêm phán đoán của bản thân thì các bạn trẻ sẽ rất thành công”.
Liệu bạn có muốn mở rộng con đường sự nghiệp lập trình của mình tại Nhật? Chắc chắn đây sẽ là cơ hội “vàng ngọc” mang lại cho bạn không ít kinh nghiệm quý giá cũng như mức thu nhập “không hề ít”.
Nếu bạn có khoảng 2 năm kinh nghiệm làm việc trong lĩnh vực C++ thì đừng bỏ qua một trong những cơ hội được làm việc tại Nhật với mức thu nhập mỗi năm có thể lên đến 43,000USD: Game Developer (C++).
Bên cạnh đó, bạn sẽ còn nhận được nhiều đãi ngộ cực hấp dẫn “không nỡ chối từ”:
Lương theo tháng: $2000 – $3500
Lương theo năm: 3,000,000～6,000,000 JPY/ năm (27,000 ~ 43,000 USD/năm)
Nhân viên chính thức được tăng lương 2 lần/năm và thưởng 1 lần/năm.
Hỗ trợ chi phí đi lại tại Nhật.
Hỗ trợ bảo hiểm tại Nhật.
Nghỉ 2 ngày/ tuần và các ngày nghỉ lễ của Nhật.
Các kì nghỉ khác của Nhật như tuần lễ vàng, lễ Obon hè, lễ Tết dương lịch.
Làm thêm giờ và làm thêm ngày nghỉ bạn còn sẽ được tính thêm lương
Tôi không đồng tình với những người không chuyên về lĩnh vực khoa học, công nghệ khi họ cho rằng, chuyện gì mà người khác làm được thì bản thân mình cũng làm được, như Facebook chẳng hạn. Nghe có vẻ hợp lý nhưng thực ra lại phi thực tế. Tại sao vậy?
Họ sở hữu dữ liệu
Như tôi đã thảo luận trong bài viết gần đây nhất về APIs, các công ty lớn như Facebook sở hữu toàn bộ các dữ liệu độc quyền. API mà họ có cho phép bạn truy cập một số thông tin, nhưng đó chỉ là những thông tin công ty muốn bạn truy cập. Biểu đồ bạn bè của Facebook rất có giá trị đối với công ty của họ, nhưng họ chỉ tiết lộ một phần thông qua API.
Ví dụ: Facebook cho phép bạn có được danh sách bạn bè của người dùng nếu họ cũng là người dùng của bạn. Bạn không thể truy cập vào những người chưa từng sử dụng ứng dụng. Ví dụ Spotify sẽ hiển thị âm nhạc mà bạn bè bạn đang nghe, nhưng Spotify không biết thông tin gì về những người không phải là bạn của bạn. Điều này ngăn cản bạn thực hiện một số tính năng mà chỉ riêng Facebook mới làm được.
Họ sở hữu các Platform
Nếu sản phẩm của bạn hoạt động trong environment của một công ty khác, chẳng hạn như hệ điều hành Android của Google, iWatch của Apple hoặc Alexa của Amazon, thì bạn chỉ có thể làm những gì công ty đó cho phép làm.
Gần đây tôi đã xây dựng một ứng dụng Alexa để tìm hiểu về nền tảng mới của Amazon. Tôi nhận ra Alexa ràng buộc các developer khá chặt chẽ, chúng tôi không được quyền truy cập nhiều tính năng mạnh mẽ mà Alexa sử dụng cho các built-in skills. Ví dụ: người dùng phải gọi ứng dụng bằng cách nói, “Alexa, yêu cầu [tên ứng dụng] …” thay vì chỉ nói về những gì bạn muốn. Tôi có thể hỏi “Alexa, thời tiết hôm nay như thế nào?” Bởi vì thời tiết là điều mà Amazon đã xây dựng trong các platform mà họ sở hữu, nhưng nếu tôi đang xây dựng một ứng dụng tương tự, người dùng sẽ phải gọi nó bằng cách nói “Alexa, hỏi ứng dụng Awesomest Weather của Adam thời tiết hôm nay như thế nào?”
Một số công ty lại lựa chọn các giải pháp sáng tạo. Snapchat không sở hữu iOS hoặc Android và app developers từ những nền tảng này không thể ngăn cản người dùng chụp màn hình. Có vẻ như đây là một vấn đề cơ bản với một ứng dung nổi tiếng sở hữu các bài posts mang tính tạm thời. Thay vào đó, Snapchat đã sử dụng khả năng nhận biết tình huống khi người dùng chụp ảnh màn hình, từ đó xây dựng cơ chế cảnh báo người dùng nhằm hạn chế thao tác chụp ảnh màn hình này.
Họ có hàng ngàn kỹ sư
Giả như bỏ qua các yếu tố kĩ thuật, thì đội ngũ chỉ có 3 kỹ sư của bạn cũng không thể cạnh tranh được với các ông lớn như Facebook. Các team nhỏ tuy hoạt động linh hoạt nhưng đối với một số thử thách kỹ thuật có quy mô lớn như Google Maps, bạn thực sự cần sở hữu một đội ngũ đủ để hoàn thành các dự án tầm cỡ.
Họ có nhiều tiền
Nguồn tài nguyên máy tính (computing resources) đang dần rẻ hơn, và các dịch vụ lưu trữ đám mây như AWS hỗ trợ việc thuê các thiết bị phần cứng 1 cách dễ dàng. Tuy nhiên, một số tasks – đặc biệt là các tác vụ xử lý dữ liệu lớn – sẽ tiêu tốn của các công ty nhỏ khá nhiều tiền. Trong những trường hợp này, kỹ sư của bạn phải có khả năng tinh giảm những con số với chi phí ước lượng cụ thể, để bạn đưa ra được những quyết định tiếp theo.
Họ sở hữu bằng sáng chế
Tôi chưa gặp nhiều vấn đề về bằng sáng chế trong công việc của mình, nhưng có một số trường hợp, các kỹ sư nhưng không được phép thực hiện vài thao tác kĩ thuật vì lý do sáng chế. Bằng sáng chế phần mềm là một chủ đề nhạy cảm, khi nhiều chuyên gia phần mềm nhận định rằng chúng được trao cấp một cách quá tùy tiện. Thậm chí nhiều công ty lớn, kể cả những công ty sản xuất vũ khí cũng được cấp bằng sáng chế, và một số đã hứa sẽ chỉ sử dụng bằng sáng chế để dự phòng. Vì một số bằng sáng chế có quy định rất lỏng lẻo, rất nhiều công ty đang vi phạm các bằng sáng chế mà họ thậm chí không biết. Lời khuyên tốt nhất là bạn nên nghiên cứu xem liệu ứng dụng của mình có bị ảnh hưởng một chút nào đó từ các công ty lớn sở hữu bằng sáng chế có liên quan hay không.
Các thuật toán đang giữ vai trò trung tâm trong cuộc cách mạng công nghiệp 4.0. Giải thích một cách ngắn gọn, thuật toán là chìa khóa để tăng năng suất của nhân lực.
Thị trường cần nhưng đang thiếu
Hoàng, một lái xe Grab, đã chuyển từ một hãng taxi trong nước sang lái Grab vì: không có cảm giác “về nhì” – chữ mà cánh tài xế dùng để chỉ việc đón hụt khách. Thuật toán cài đặt trên máy chủ điều hành của Grab tìm cách kết nối giữa tài xế và khách gần nhất, giúp cho tổng quãng đường di chuyển của toàn hệ thống giảm xuống. Trong khi hiệu suất vận tải của taxi truyền thống chỉ cỡ 40%, taxi di chuyển 100km nhưng chỉ thực sự chở khách 40km, thì với Grab con số này là trên 75%, thuật toán đã giúp tăng 87% năng suất của tài xế.
Năm 2011, một nhóm các bạn trẻ Việt Nam đã phát triển một thuật toán nén dữ liệu video đủ tốt để phát theo chuẩn HD qua đường truyền 3G, công ty VP9 với các sản phẩm dùng phần cứng nén video ra đời, với các sản phẩm: đầu phát truyền hình internet, camera giám sát, truyền hình trực tuyến,… năm 2017, công ty đặt mục tiêu doanh số 2.000 tỉ VNĐ.
Trong lĩnh vực quảng cáo trực tuyến, VCCorp vận hành hiệu quả hệ thống Admicro của họ dựa trên thuật toán phân tích nội dung văn bản và phân loại người dùng. Các doanh nghiệp công nghệ có tiếng như Viettel, FPT, CMC cũng tuyển dùng hàng nghìn nhân lực để xây dựng các thuật toán xử lý dữ liệu và trí tuệ nhân tạo xử lý các vấn đề của họ và khách hàng.
Xét về quy mô thị trường lao động, nhu cầu nhân lực có trình độ thuật toán ở Việt Nam là khá lớn, nhưng việc đầu tư cho dạy và học thuật toán dường như chưa có sự phát triển tương xứng; các giáo trình môn học thuật toán vẫn không có nhiều thay đổi so với hàng chục năm trước.
Những sân chơi thúc đẩy phong trào học thuật toán bị đóng khung trong khuôn khổ nhà trường, chủ yếu là các cuộc thi lập trình hàng năm để lấy thành tích về cho nhà trường. Kết thúc cuộc thi, thí sinh ít có cơ hội sử dụng và phát triển những kĩ năng thuật toán đã được học.
Tầm nhìn của những người trong cuộc
Nhiều doanh nghiệp đã chủ động bắt tay vào giải quyết vấn đề này bằng cách thúc đẩy những sân chơi của riêng họ, gần đây nhất phải kể đến cuộc thi Lập trình Quốc tế Samsung – SCPC 2017 – một sân chơi mở dành cho tất cả các sinh viên đang theo học tại các trường đại học, học viện trên toàn quốc. Không những thế, khi kết thúc cuộc thi, thí sinh lại có thể tiếp tục được hỗ trợ, cấp học bổng và đào tạo nâng cao để thêm hoàn thiện năng lực lập trình thuật toán – tấm bằng quan trọng cho nhân lực của kỉ nguyên cách mạng công nghiệp 4.0.
Sự kiện Thuật Toán – Tế bào gốc của AI, Machine Learning & Blockchain quy tụ các chuyên gia hàng đầu các siêu sao thuật toán từng dẫn dắt đội tuyển tham dự cuộc thi Thuật Toán Chung kết thế giới ACM-ICPC World Finals danh giá của giới lập trình.
Phát biểu tại lễ phát động cuộc thi này, ông Huh Chang Wan – Phó Tổng Giám đốc Samsung Electronics Việt Nam nhấn mạnh: “Từ năm 2015, Samsung Điện tử đã tổ chức cuộc thi lập trình Samsung Collegiate Programming Cup tại Hàn Quốc. Năm nay, lần đầu tiên cuộc thi mang đến những cơ hội cho sinh viên Việt Nam và sinh viên Ấn Độ cùng đến thi tài tại vòng chung kết diễn ra tại Hàn Quốc. Chúng tôi mong muốn tạo bước đệm để những tài năng trẻ trong lĩnh vực công nghệ thông tin phát huy năng lực cũng như khẳng định vị thế của Việt Nam trên thị trường lao động quốc tế”.
Với SCPC 2017, sinh viên Viêt Nam có cơ hội được tham gia sân chơi quốc tế để tiếp cận, tìm hiểu và trang bị thêm các kỹ năng về lập trình, giải quyết thuật toán, xây dựng ý tưởng, tư duy logic, đồng thời ứng dụng kiến thức lập trình vào cuộc sống, bắt kịp xu thế của cuộc cách mạng công nghiệp lần thứ 4.
Tầm nhìn của lãnh đạo Samsung về lập trình thuật toán tương đồng với suy nghĩ của nhiều CEO các công ty công nghệ; như ông Nguyễn Mạnh Hùng, tổng giám đốc Viettel đã từng mong muốn “xây dựng Việt Nam thành dân tộc lập trình với 90 triệu dân”; hay là Bill Gates, thậm chí còn làm một video kêu gọi thế hệ trẻ học lập trình.
Dù có vẻ mơ hồ, nhưng các thuật toán tác động to lớn đến cuộc sống nhân loại hơn suy nghĩ của đa số mọi người.
Ít ai biết, Internet, bản chất là một thuật toán định tuyến gói tin được phác thảo từ năm 1978. Nếu không có các thuật toán nén dữ liệu, chúng ta không thể thoải mái nghe nhạc hay xem video trực tuyến. Và nếu không có thuật toán lựa chọn các bài viết phù hợp, trang facebook của bạn sẽ tràn ngập những bài viết vô bổ hoặc quảng cáo không đâu.
Thị trường đang rất cần những lập trình viên có năng lực thuật toán, và những người trẻ Việt Nam đang rất cần những cơ hội được cọ sát, giao lưu trong lĩnh vực này.
Đến với sự kiện Topdev Techtalk “Algorithms: Tế bào gốc của AI, Machine Learning, Blockchain…và con đường sự nghiệp của bạn”, bạn sẽ được nghe chia sẻ từ chính các siêu sao thuật toán đã dẫn dắt đội tuyển tham dự cuộc thi Thuật Toán Chung kết thế giới ACM-ICPC World Finals danh giá của giới lập trình:
Diễn giả Nhân Nguyễn – Cựu kỹ sư Google đồng thời là nhà đầu tư thiên thần của hơn 10 Tech startups
Diễn giả Phạm Nguyễn Sơn Tùng – Founder BigOCoding, trrường dạy thuật toán chuyên sâu số 1 hiện nay
Khách mời đặc biệt
Cùng với các diễn giả khách mời khác sẽ đem đến cho cộng đồng một bức tranh toàn cảnh về vai trò của Algorithms đến tương lai ngành công nghệ, cách bắt đầu và đào sâu Algorithms!
Thời gian – Địa điểm: – Liberty Central SaiGon Citypoint Hotel – 59 Pasteur, Q.1, TP.HCM ngày 24/6/2017
– Tại Hà Nội ngày 2/7/2017
Trước khi làm CEO của Yahoo và bán công ty này cho Verizon sau 5 năm, Marissa Mayer có sự nghiệp đầy tiếng vang tại thung lũng Silicon…
Business Insider cho biết Marissa Mayer sinh năm 1975 tại thị trấn Wausau, Wisconsin, Mỹ, trong gia đình có bố là kỹ sư và mẹ là giáo viên.
Ở trường, Mayer sớm chứng tỏ năng khiếu trong môn toán và khoa học nhưng lại là học sinh khá rụt rè và hướng nội.
Sau khi tốt nghiệp trung học, Mayer nộp hồ sơ vào 10 trường đại học và đều được nhận, trong đó gồm các trường danh tiếng như Harvard, Yale và Stanford. Bà đã chọn Đại học Stanford nhưng với ước mơ ban đầu là trở thành bác sĩ.
Tuy nhiên, mục tiêu cuộc đời của Mayer thay đổi khi bà tham gia lớp khoa học máy tính. Mayer đã chuyển sang ngành Symbolic Systems (SSP) tập trung vào máy tính và tư duy. Một số cựu học sinh trường Stanford theo học ngành này gồm có Reid Hoffman (LinkedIn), Scott Forstall (Apple) và Mike Krieger (Instagram).
Sau khi tốt nghiệp đại học, Mayer nhận được tới 12 lời đề nghị việc làm, trong đó có Google, khi có mới là một công ty khởi nghiệp nhỏ.
Thời điểm đó, theo tính toán của mình, Mayer cho rằng khả năng tồn tại của Google chỉ là 2%. Tuy nhiên, sau đó, ấn tượng với những người làm việc tại Google cùng những điều có thể học được ở đó, Mayer quyết định đầu quân cho công ty này và đã cống hiến ở đây suốt 13 năm.
Trong 2 năm đầu tại Google, Mayer thường làm việc 100 giờ mỗi tuần, đồng thời giảng dạy tại trường đại học Stanford.
Sau đó, bà nhanh chóng thăng tiến. Khởi đầu là nhân viên bán thời gian của đội phát triển giao diện người dùng, bà nhanh chóng trở thành quản lý sản phẩm. Năm 2003, Mayer phụ trách mảng phát triển sản phẩm và người dùng của Google, bao gồm công cụ tìm kiếm.
Năm 2005, bà được bổ nhiệm làm phó chủ tịch phụ trách sản phẩm công cụ tìm kiếm và trải nghiệm người dùng của Google.
Mayer từng có thời gian ngắn bí mật hẹn hò với người đồng sáng lập Google, Larry Page. Mối quan hệ của họ được mô tả là “hai người trầm lặng âm thầm hẹn hò”.
Tuy nhiên, phong cách quản lý chi tiết và dựa trên số liệu của Mayer khiến nhiều người bất mãn. Một số đó là Amit Singhal, người đứng sau các thuật toán của công cụ tìm kiếm này. Ông này tới gặp trực tiếp Larry Page và đề nghị loại Mayer khỏi đội công cụ tìm kiếm.
Cuối cùng, Singhal lại là người rời Google và sang làm việc cho công ty khởi nghiệp Uber.
Còn Mayer chuyển sang quản lý đội Google Maps và phát triển sản phẩm tại thị trường Mỹ. Dù vẫn là lãnh đạo cấp cao nhưng nhiều người coi việc điều chuyển đó là “giáng chức” bởi bà không còn phụ trách công cụ tìm kiếm – sản phẩm quan trọng nhất của Google.
Năm 2011, Mayer chính thức rời Google và nhận được lời mời làm CEO của hội đồng quản trị Yahoo. Một số người cũng được cân nhắc cho vị trí này gồm Nikesh Arora, Giám đốc Kinh doanh của Google và Eddy Cue, Phó chủ tịch phụ trách dịch vụ và phần mềm của Apple.
Dù một số người phản đối việc tuyển dụng Mayer, cho rằng bà không có nhiều kinh nghiệm quản lý tài chính của một công ty và thiên về phát triển sản phẩm hơn là một CEO quản lý vận hành. Tuy nhiên, cuối cùng, bà vẫn được bầu làm CEO mới của Yahoo.
Mayer chính thức trở thành CEO Yahoo vào tháng 7/2012 và được kỳ vọng mang lại làn gió mới, vực dậy hãng công nghệ khổng lồ đang trên bờ vực sụp đổ.
Bà nhanh chóng cơ cấu lại bộ máy lãnh đạo của Yahoo và thay thế bằng người của mình. Tháng 8/2013, một năm sau khi Mayer lên làm CEO, cổ phiếu Yahoo tăng từ 15,74 USD/cổ phiếu lên khoảng 28 USD.
Thành công đó một phần là nhờ số cổ phần Yahoo nắm giữ tại Alibaba. Mayer càng yên ổn hơn khi hãng thương mại điện tử khổng lồ của Trung Quốc thực hiện IPO (niêm yết cổ phiếu lần đầu) vào năm 2014.
Dù vậy, Mayer cũng được công nhận đã giúp cải thiện đáng kể hoạt động của Yahoo, từ thiết kế sản phẩm, lượng người dùng cho tới các ứng dụng cốt lõi. Một số người còn cho rằng bà đã thay đổi văn hóa tại Yahoo và khơi lại nguồn hứng khởi tại công ty này.
Tuy nhiên, doanh thu ở các mảng kinh doanh cốt lõi của Yahoo không có dấu hiệu cải thiện.
Chưa kể, Mayer mất đi nhiều lãnh đạo chủ chốt như Giám đốc Marketing (CMO) Kathy Savitt và Giám đốc Kỹ thuật số (CDO) Jackie Reses. Nhiều người cũng tỏ ra hoài nghi chiến lược thâu tóm của Mayer khi chi gần 3 tỷ USD mua lại các công ty khởi nghiệp như Tumblr và Polyvore.
Đầu năm 2016, xuất hiện lời đồn đoán cho rằng nhiều công ty từ Comcast, Disney, AT&T… đang dòm ngó thâu tóm Yahoo. Tháng 7 năm đó, Verizon chính thức công bố thương vụ mua lại công ty này với giá 4,83 tỷ USD.
Sau thương vụ này, mảng kinh doanh cốt lõi của Yahoo sẽ hợp nhất với công ty AOL của Verizon để thành lập công ty mới có tên “Oath”. Yahoo sẽ giữ lại số cổ phần tại Alibaba và Yahoo Nhật Bản, để gộp thành một công ty độc lập có “Altaba”.
Cuối năm 2016, lỗ hổng bảo mật khiến Yahoo bị tấn công trên quy mô lớn gây ảnh hưởng tới 1 tỷ người dùng. Vụ việc này giúp Verizon giảm giá thương vụ mua lại Yahoo xuống còn 4,48 tỷ USD.
Ngày 13/6, Yahoo hoàn tất thương vụ bán mình cho Verizon và bà Mayer cũng chính thức rời khỏi công ty này, kết thúc 5 năm thất bại.
Vào thuở sơ khai, Programmer đã tạo ra code và Documentation. Khi đó, Documentation vốn rất mơ hồ, chứa đựng hiểu biết về functions, đã được cất dấu khỏi các developer mới tập tõm bước vào nghề.
Và Programmer cất tiếng nói – “Hãy tạo ra nhiều code hơn”. Thế là, code sinh sôi nảy nở, một số quá tốt chúng liền tiến hòa thành Framework.
Như vậy đấy thưa quí ông quí bà, con trai và con gái, người ngoài hành lẫn siêu anh hùng, đó là cách mà các phần mềm ra đời. Chúng như những đứa trẻ sơ sinh, lớn lên nhờ vào bàn tay chăm sóc của các developer. Và nếu như có lúc bạn cảm thấy mình không đủ khả năng thì hãy cầu cứu đến StackOverflow, ngài sẽ ban cho bạn mọi thứ để trở thành một developer thật thụ.
Thật không may, là chúng ta cũng trở nên quá phụ thuộc vào StackOverflow. Từ junior đến senior developer, programmer, coder, bất cứ ngành nghề gì đều có sự hiện diện của StackOverflow. Vì một số lí do nào đó mà giờ để xin việc liên quan đến IT cũng yêu cầu bạn phải có tài khoản hoạt động trên StackOverlow.
Aura thần thánh
Gần như là mọi người nhân sự mà tôi quen biết, đặc biệt là bên Linkedln, đều tin rằng một developer giỏi khi họ có đóng góp liên quan tới code trên StackOverflow. Chẳng khác gì việc có được danh hiệu khen thưởng danh giá chả thua gì bằng đại học từ MIT hay Harvard vậy.
Cây đũa phép “kinh nghiệm”
Giờ đây việc bạn có thể trả lời và đóng góp trên StackOverflow còn được dùng như thước đo đánh giá kinh nghiệm. Không cần biết là liệu câu hỏi đó củ chuối thế nào? hay việc có hàng trăm câu trả lời tùy theo sự khác nhau trong thông tin được cung cấp. Miễn là có đóng góp là bạn đã được xem là một developer kinh nghiệm đầy mình rồi.
“Vương miệng xã hội”
“Tôi là người có đóng góp thuộc hàng top của StackOverflow đây!” – hắn nói khi tỏ vẻ “khiêm tốn” chấp nhận sự chào đón nồng nhiệt từ khắp mọi công ty công nghệ trên thế giới. Mãi cho đến khi mọi chuyện vỡ lẽ ra, và hắn chẳng khác gì một ông vua trần như nhộng, chả biết gì về IT ngoài những thông tin vụn vặt mà bạn luôn đọc trên báo lá cải. Và thế là hắn trở thành trò cười cho thiên hạ.
Những mẫu chuyện trên có thể khiến bạn phì cười. Nhưng trên hết, nó như một hồi chuông báo động, cho ta thấy sự điên rồ khi phải làm trong một ngành công nghiệp mà việc chấp nhận giá trị ảo, không thiết thực lại trở nên ngày càng phổ biến hơn. Càng nực cười hơn khi nhiều người còn quả quyết rằng StackOverflow sẽ tồn tại và phát triển rực rỡ hơn 20 năm nữa. Chẳng phải công nghệ đã từng dạy chúng ta rằng đừng bao giờ tin vào những giả thiết khi vẫn chưa có bằng chứng chắc chắn? Liệu ta đã quên rằng ngay cả các ông trùm công nghệ như Amazon vẫn gặp thất bại hay một trang website, mạng xã hội vẫn có thể biến mất một cách đột ngột? Có mấy ai từng nhớ tới cái thời huy hoàng của AltaVista hay Yahoo? Vậy mà giờ đây, một lần nữa chúng ta lại khuyến khích thế hệ trẻ tiếp tục phụ thuộc vào StackOverflow. Trong khi lại dè bỉu nhưng developer có hướng đi khác như tự học trên các diễn đàn khác hoặc là cả việc mua sách về đọc.
Giờ đây bạn phải lên StackOverflow, tham gia và đóng góp thì mới được công nhận là một developer giỏi. Đó là một điều vô cùng điên rồ.
Có người từng nói “Đường xuống địa ngục luôn bắt đầu với lời hay ý đẹp”. Sự thật là, mặc dù có nhiều thành viên bẩn tính, vẫn có rất nhiều StackOverflow user là người tốt, sẵn sàng cống hiến thời gian của họ để giúp đỡ người khác. Họ cũng là những chuyên gia hàng đầu, không chỉ có nhiều năm kinh nghiệm mà còn rất am hiểu thế giới lập trình. Tuy nhiên, đó cũng là nguyên nhân dẫn đến vấn đề nhức nhối tại StackOverflow. Nó tồn tại là bởi vì sự thất bại của người thầy khi không thể chỉ dạy cho học sinh, sự yếu kém của các programmer khi không thể cho ra những documentation chất lượng.
Là một lập trình viên, chúng ta luôn quên mất rằng cái thật sự đáng giá của một ứng dụng là quá trình suy nghĩ, chất xám đổ vào nó chứ không là những dòng code. Thế nhưng chúng ta đã tự lơ đãng, bỏ bê đi việc viết ra những documentation thật sự hay và có ích.
Điều thật sự đáng buồn khi chúng ta có hàng tỷ tỷ framework, hàng trăm ngôn ngữ lập trình, không kể xiết số lượng library và plugin, thế nhưng khi nhắc đến documentation thì liệu bạn có thể liệt kê ra hơn số đầu ngón tay hay không?
Có thể đây là một ý kiến trái chiều nhưng StackOverflow thật sự không giải quyết được vấn đề thật sự, và càng không nên được xem như một chuẩn để đánh giá một developer. Nó là một biểu hiện của đại dịch đang lan tràn trong thế giới IT. StackOverflow chăm đút, bón cơm quá kĩ cho các developer, khiến họ mất đi khả năng tự giải quyết những vấn đề dù là nhỏ nhặt nhất. Đó là một sự thật phũ phàng khi có đến hơn một nữa số người dùng trên Stack Overflow mang danh nghĩa developer mà lại không thể giải thích code của chính họ chứ nói chi đến việc nhắc đến quá trình suy nghĩ, đưa ra ý tưởng cho ứng dụng mà họ đang phát triển. Tất cả là do sự nghèo nàn trong chất lượng của documentation khiến cho các developer phải tìm kiếm sự giúp đỡ.
Khoa học đã chứng mình chúng ta nhớ lâu khi bỏ nhiều công sức để có được thông tin đó, nếu không thì cũng như bụi đứng trước gió mà thôi. Để trở thành một developer, chúng ta cần khả năng suy luận, giải quyết vấn đề và đưa ra được giải pháp xác đáng.
Vì thế, tôi tin rằng documendation nên và phải được xem như một phần quan trọng để quyết định chất lượng của phần mềm.
Tại sự kiện đình đám WWDC, Apple cho biết họ đã trả cho các developer với khoảng tiền cực khủng, lên tới 70 tỉ đô (tiền chi cho nằm ngoái chiếm khoảng 30%). Đó là mức tăng rất lớn khiến chúng tôi vô cùng ngạc nhiên bởi người dùng đâu có chi nhiều cho ứng dụng đến vậy. Bản thân tò mò muốn biết được thu nhập khủng đó đến từ đâu, tôi đã vào App Store để kiểm tra các top ứng dụng.
Bước 1: Chạy theo đồng tiền
Khi tôi vào xem các ứng dụng trong mục Productivity, một điều dễ nhận thấy là hầu hết chúng đều là sản phẩm của các ông lớn công nghệ đình đám như Dropbox, Evernote, và Microsoft. Thế nhưng đứng ở vị trí thứ 10 lại là một app với tên gọi là “Mobile protection :Clean & Security VPN”.
Bởi cái tên nghe quá củ chuối lại chữ in hoa in thường không nhất quyết cũng như ngữ pháp quá tệ, tôi thầm nghĩ hẳn là thuật toán của Apple bị lỗi rồi. Điều đáng kinh ngạc là khi dùng Sensor Tower để kiểm tra ứng dụng, tôi hoàn toàn bị shock với con số lên tới $80,000 hàng tháng. Giờ thì tôi thật sự tò mò về nó.
Khi vào xem thử developer là ai thì ứng dụng chỉ hiện ra duy nhất một dòng “Ngan Vo Thi Thuy”. Chờ đã! Vậy là VPN service này được làm bởi một cá nhân duy nhất mà không cần đến sự trợ giúp từ các ông lớn, tập đoàn công ty công nghệ ư? Cực kì nguy hiểm. Như bạn đã biết, VPN ám chỉ việc route toàn bộ lượng internet traffic của bạn thông qua một nhóm thứ ba (3rd party). Nói cách khác, trong trường hợp này, một người hoàn toàn xa lạ, với trình độ ngữ pháp cực kì tệ, cũng như không hề có hợp tác với bất cứ công ty nào, muốn co quyền truy cập vào toàn bộ internet traffic của bạn.
Một điều đáng sợ khác nằm ở thông tin về ứng dụng này:
Theo như hình trên thì “Mobile protection :Clean & Security VPN” có đầy đủ tính năng – bao gồm kể cả “dupplicate” contacts và “Quick & Full Scan Internet Security”. Nghe đúng là ảo diệu.
Càng đáng ngờ hơn là khi nhìn vào đám review đầy 5 sao.
Tôi tự hỏi cái app này đã sống được bao lâu rồi? Theo Sensor Tower thì nó nằm trong top 20 từ ngày 20 tháng 4 (tức là tới hơn 2 tháng trời)
Bước 2: Lừa đảo người dùng
Tò mò vì sao mà cái ứng dụng này lại lên top được, tôi thử donwload về, và sau đây là lúc tôi mở app lên lần đầu tiên.
Đúng rồi đấy, bạn không hề nhầm đâu. Cái ứng dụng này đòi bạn phải cho phép nó truy cập vào danh sách liên lạc để quét contact trước. Tất nhiên là tôi đâu có điên mà cho phép nên bấm vào từ chối. Ngay sau đó, ứng dụng báo động rằng điện thoại của tôi đang gặp nguy hiểm. Rồi bảo là phải dùng Quick và Full Scan để đảm bảo an toàn internet cho tôi.
Khi bấm vào “Device Analyze” thì ứng dụng hiện ra lượng memory và storage còn trống. Một tính năng đúng chuẩn vô dụng. Còn nếu vào Quick Scan and Full Scan thì lại cho thấy “Your contact is cleaned. No dupplicated found.”
Ôi trời, không phải dupplicates mà là duplicates.
Sau khi bấm vào “Secure Internet” ngay lập tức app đưa ra lời mời gọi chơi game… bắn bong bóng. Dù tôi chả làm gì để được “thưởng” thế nên tạm thời tôi từ chối và quay về lại mục “Secure Internet”.
Tất nhiên là tôi chấp nhận dùng thử, hàng “FREE TRIAL” mà.
Touch ID? “Full Virus, Malware scanner”? Tôi chắc rằng việc một app scan tìm virus từ dữ liệu điện thoải của tôi là bất khả thi bởi những ứng dụng như sandboxed vậy.
Đã thế còn “You will pay $99.99 for a 7-day subscription”. Nói cách khác tôi sẽ phải trả tới $100 hàng tuần để cho một kẻ lừa đảo được quyền truy cập vào lượng internet traffic của mình.
Bước 3: Lãi ròng tăng theo thời gian
Giờ thì tôi đã hiểu vì sao cái app này lại kiếm được tới hơn $80,000 một tháng. Với cái mức phí $400 hàng tháng thì chỉ cần 200 người bị lừa đã đủ để nó đạt chỉ tiêu rùi. Và Apple thì sẽ thu phí 30%, tức là $288,000 chỉ từ app này.
Bạn có thể cho rằng ai mà lại đi download cái app này rồi lại sẵn tiền móc hầu bao ra nữa chứ.
Có thể là bạn và tôi điều không click vào mấy cái ad rẻ tiền vậy nhưng đừng quên rằng Google Ad vẫn cán mốc tới $700 tỉ năm nay. “Mobile protection :Clean & Security VPN” nằm trong top 10 app nổi tiếng nhất của mục free productivity ứng dụng với hơn 50,000 lượt download chỉ trong tháng tư.
Như vậy 200 người trả tiền chỉ chiếm 0,4%, vốn rất dễ đạt được với con số hơn 50000 lượt donwload. Và bạn cũng nên tính đến việc rất nhiều người dùng mù về công nghệ, vô tình (cố tình) trả phí cho cái “free trial” này.
Dù vậy, đến 50000 lượt download thì hẳn App Search Optimization của nó phải rất tốt:
Ngay lập tức hiện ra là “Protection for iPhone — Mobile Security VPN”. Nó vốn là một app khác nhưng điều khá hay là nó lại là In-App Purchase, xếp hạng #33 cho Top Grossing trong mục Business.
Hóa ra bọn lừa đảo này lợi dụng tính năng App Store Search Ads product, bởi nó chưa có filter cũng như sàn lọc ads. Hóa ra các ứng dụng này vốn có thể gọi là ads của chính chúng, với quảng cáo chèo kéo sử dụng app này trong app khác. Ngoài ra cách đặt tên chuối mà tôi đã nhắc đến phía trên cũng để phục vụ cho mục đích tạo keyword để tăng khả năng hiển thị trong mục search.
Làm cách nào để ngăn chặn chúng: Điều bạn có thể làm
Hãy chỉ người thân và bạn bè (không chuyên về IT và công nghệ) cách kiểm tra và tắt subscription. Còn nếu nó quá tệ nữa thì hãy cố gắng bắt hoàn tiền lại.
Report mấy cái ứng dụng lừa đảo. Cứ chọn mục “Feedback and Concerns” hoặc “Report a Fraud Concern”.
Share bài viết này để Apple và người quen của bạn đọc được
Làm cách nào để ngăn chặn chúng: Điều Apple có thể làm
Nhiều người cho rằng Apple đã biết về chúng nhưng hẳn là họ không nghĩ là vấn đề đó đáng lo đến mức tự tay mình phải vào cuộc hoặc là họ thấy có lợi nên cũng nhắm mắt cho qua. Dù sao đi nữa, thì tôi vẫn nêu ra một số phương pháp khả thi cho hãng:
Diệt trừ bọn lừa đảo và hoàn tiền lại cho người dùng: Cái này thì quá rõ ràng rùi. Chỉ việc thuê người làm việc dò và loại mấy cái app này ra. Việc này có thể mất thời gian nhưng không hề khó bởi mấy ứng dụng lừa đảo quá trắng trợn và rõ ràng, rất dễ để nhận ra.
Cải thiện UI trên Touch ID Subscriptions: Hãy khiến cho việc ấn vào để thực hiện giao dịch kéo dài trong 5 giây. Ngoài ra, việc review cũng nên phải được kiểm tra và chỉ hiện thỉ những review hữu ích.
Thắt chặt và kiểm tra các Review của Subscriptions: Qua việc trên, ta có thể nhận ra review giả là một trong những nguyên nhân khiến những ứng dụng này nổi lên nhanh đến vậy.
Thêm tính năng hủy subscription khi xóa app: Nhiều người dùng sao khi bị lừa cho biết dù họ đã xóa app nhưng vẫn phải trả tiền hàng tháng do chưa hủy subscription. Thiết nghĩ đây cũng là một tính năng rất cần thiết mà Apple nên có.
Quá trình hủy subscription dễ dàng hơn: Việc hủy subscription yêu cầu người dùng phải trải qua tới 9 bước. Thật sự là quá nhiều và không cần thiết.
Cải thiện Search Ads: Một trong những nguyên nhân chính khiến cho những cái app lừa đảo này vẫn sống khỏe là do hệ thồng search ads của Apple vẫn còn quá trẻ, người dùng không thể phân biệt được đâu là app và đâu là Ad. Vì thế tính năng chống lừa đảo, phân tích xác định xem những ad bị nghi ngờ có dấu hiệu lừa đảo là rất quan trọng.
Hãy vào cuộc: Nếu apple thật sự bắt tay vào trừng trị những kẻ lừa đảo này thì tin rằng việc những ứng dụng trên sẽ biến mất rất nhanh. Tuy vậy, tôi đặt giải pháp này ở cuối là bởi vì rất ít khả năng Apple sẽ làm vậy. Đó là bởi việc làm những app này không hề tốn nhiều công sức, và việc tệ nhất chỉ là bị xóa tài khoản thứ mà còn dễ làm hơn nữa. Việc kiện tụng và phạt thì lại khá tốn kém đối với Apple bởi số lượng những kẻ lừa đảo là quá nhiều.
Lời kết
Là một developer, niềm tự hào của tôi là khi tạo ra được những ứng dụng có giá trị cho người dùng. Không những thế, các app tốt là kết quả từ design, engineering, sale cũng như hàng trăm giờ làm việc cống hiến.
Vì thế mà việc có nhiều kẻ lợi dụng lập trình để tạo ra những app lừa đảo này thật sự khiến tôi đau lòng.
Nếu bất cứ ai tại Apple đọc được những dòng này, xin hãy làm điều gì đó để ngăn chặn chúng lại
Những ứng dụng giao tiếp với robot, dịch tự động, tra cứu thông minh, thống kê dự đoán…ra đời với những thuật toán phức tạp bên trong
Thuật toán tốt sẽ tối ưu performance làm server tiết kiệm RAM và CPU để phục vụ nhiều user hơn.
Thuật toán tốt sẽ làm ứng dụng di động của bạn đỡ ngốn pin, mượt và tốn ít thời gian phát triển
Dù bạn có thành thạo 10 ngôn ngữ lập trình, nhiều framework và công nghệ, nhưng tư duy thuật toán kém bạn sẽ mất cơ hội ngay từ vòng loại ở các công ty công nghệ lớn
Những bài toán lớn như Zalo/Whatsapp phục vụ hàng chục triệu người dùng nhưng tốn rấ ít tài nguyên
Bài toán crowdsourcing kết hợp xử lý ngôn ngữ tự nhiên giúp Google Translate dịch ngày càng hay.
Các bài toán về AI, Machine Learning, Blockchain…những công nghệ mà nhân loại đang trên đường hướng đến đều không thể vắng mặt những kỹ sư thông thạo thuật toán.
Chính vì vậy, thuật toán được xem như là nền tảng cần có của mọi lập trình viên, bất kể ngôn ngữ lập trình và nền tảng nào. Tuy nhiên, cộng đồng IT vẫn được chia làm hai luồng trái chiều khi nhắc về thuật toán như sau:
Thần thánh hoá thuật toán: Muốn lập trình giỏi phải giỏi thuật toán. Các công ty công nghệ lớn phỏng vấn về tư duy thuật toán trước khi quan tâm đến các kỹ năng khác mà?
Coi thường thuật toán: Chỉ cần căn bản đủ làm việc thôi, viết giao diện, if/ else/ continue/ while/ for là đủ rồi cần gì cao siêu?
Liệu điều này có đúng?
Đến với sự kiện Topdev Techtalk “Algorithms: Tế bào gốc của AI, Machine Learning, Blockchain…và con đường sự nghiệp của bạn”, bạn sẽ được nghe chia sẻ từ chính các siêu sao thuật toán đã dẫn dắt đội tuyển tham dự cuộc thi Thuật Toán Chung kết thế giới ACM-ICPC World Finals danh giá của giới lập trình:
Diễn giả Nhân Nguyễn – Cựu kỹ sư Google đồng thời là nhà đầu tư thiên thần của hơn 10 Tech startups
Diễn giả Phạm Nguyễn Sơn Tùng – Founder BigOCoding, trrường dạy thuật toán chuyên sâu số 1 hiện nay
Khách mời đặc biệt
Cùng với các diễn giả khách mời khác sẽ đem đến cho cộng đồng một bức tranh toàn cảnh về vai trò của Algorithms đến tương lai ngành công nghệ, cách bắt đầu và đào sâu Algorithms!
Thời gian – Địa điểm: – Liberty Central SaiGon Citypoint Hotel – 59 Pasteur, Q.1, TP.HCM ngày 24/6/2017
– Tại Hà Nội ngày 2/7/2017
Dan Wang – cây bút chuyên viết về công nghệ người Hong Kong đã viết một bài đăng trên blog khám phá lý do tại sao có quá ít người chọn học ngành khoa học máy tính. Con số này ít hơn rất nhiều so với những người học các lĩnh vực khoa học, kĩ thuật khác.
Đây là những lời giải thích phổ biến nhất cho hiện tượng này. Và ông Dan Wang nhận thấy nó vẫn chưa đủ để lý giải cho điều đó:
Khoa học máy tính là chuyên ngành khó. Nhưng nó không phải là quá khó hơn các ngành khoa học- kĩ thuật khác, nhiều trong số đó đang trở nên phổ biến.
Để trở thành 1 developer bạn không nhất thiết phải có bằng về khoa học máy tính. Tuy nhiên bằng cấp chắc chắn giúp bạn bước chân vào các công ty công nghệ lớn dễ dàng hơn so với các chuyên ngành khác.
Mọi người thường không bị ảnh hưởng bởi xu hướng khi xem xét chuyên ngành. Tuy nhiên, cũng có bằng chứng cho thấy ngày càng có nhiều người lựa chọn các lĩnh vực đang phát triển như chăm sóc sức khỏe. Vì vậy, điều này cũng không thể giải thích một cách đầy đủ tại sao nhiều người không tham gia vào lĩnh vực khoa học máy tính.
Ông Dan Wang tiếp tục nghiên cứu và bổ sung thêm 11 yếu tố ảnh hưởng. Nhưng không một yếu tố nào trong số những yếu tố này giải thích đầy đủ lý do tại sao có quá ít người theo học khoa học máy tính, ngay cả khi có rất nhiều công việc với mức lương hấp dẫn, uy tín cao.
Dù sao, nếu bạn đang là sinh viên đại học, hoặc đang có dự định bắt đầu kế hoạch sớm, tôi khuyến khích bạn nên chọn ngành khoa học máy tính.
Programming thực sự là nơi có rất nhiều công việc mới, và xu hướng này sẽ tăng tốc vì ngày càng có nhiều công việc được thực hiện bởi máy móc.
Bonus: Sáng nay tôi vừa phòng vấn bà Adriana Vecchioli – Virtual Reality Developer về những hướng dẫn VR của cô ấy và những thách thức trong quá trình xây dựng VR App
“Bạn có thể thấy rất nhiều thứ chỉ bằng quan sát”- Yogi Berra
Ben Horowitz’s từng đề cập trong cuốn “The Hard Thing about Hard Things” của ông bí quyết để trở thành một PM giỏi. Cuốn sách chứa đựng rất nhiều lời khuyên quí giá và hữu ích.
Khi đọc qua, tôi luôn liên tưởng đến điểm chung của những Product Manager tài năng mà tôi quen biết. Xin nói thêm là nhờ vào đặc thù nghề của mình kèm chút may mắn mà tôi từng được gặp qua hàng trăm Product Manager cũng như cộng tác làm việc với họ, một số còn là bạn thân của tôi nữa. Vì thế mà trong bài viết này, tôi sẽ đề cập đến những tính cách cần có của một Product Manager đến từ kinh nghiệm và góc nhìn của tôi khi làm việc cùng PM.
Đồng thời, tôi cũng sẽ không nhắc tới những điều quá hiển nhiên như “có tâm”, “tôn trọng nhân sự”, “không dành công” mà bài viết sẽ tập trung vào việc miêu tả một người Product Manager giỏi sẽ như thế nào. Sẽ không có ai có đủ hết tất cả những tính cách được liệt ra vì thế mà bạn cần phải xem và phát huy những thế mạnh của bản thân cũng như cải thiện những điều mình thiếu mà được đưa ra trong bài viết. Hơn nữa, mặc dù tôi dùng từ Product Manager thì thật ra là ám chỉ “product people” – những con người tài năng liên quan tới các vị trí như Product Managers, Program Manager, Designers, Developers, Marketing hoặc Sales.
Tôi cố tình không xếp hạng các tính cách bởi nó hoàn toàn tùy vào bạn cũng như môi trường xung quanh mà một số sẽ trở nên quan trọng hơn. Vì thế mà các bạn cứ xem nó như một bài hướng dẫn giúp bạn trở thành một Product Manager tài năng.
Jeff bắt đầu với khách hàng và tự hỏi nguyên nhân vì sao họ lại muốn dùng sản phẩm của mình cũng như vấn đề của họ là gì để phải cần mua sản phẩm – Simon Sinek nói về cách thức mà cô tiếp cận với người dùng thông qua những bài review vô cùng hữu ích và thú vị. Sau khi xác định được mục đích của sản phẩm, cô thu hút độc giả từ cách nhìn của bản thân.
“Hãy vững tin trong nhìn nhận nhưng uyển chuyển trong chi tiết” – Jeff Bezos
Làm ra sản phẩm để giải quyết vấn đề của bản thân
Jeff tin rằng sản phẩm tốt luôn là khi nó được tạo ra nhằm cho chính bản thân mình. Tuy rằng đây là một lời khuyên dành cho CEO nhưng tôi tin là nó vẫn đúng ở mọi vị trí khác. Nhờ vào việc tạo ra một sản phẩm mà cô có thể dùng, Jeff hiểu được suy nghĩ của một khách hàng và đồng cảm trước những điều họ mong muốn từ một sản phẩm. Hơn thế, Jeff cũng là người xài sản phẩm của mình mỗi ngày, thế nên, cô cũng được xem là tester quan trọng nhất trong team.
Đặt ra mục tiêu, cách thức, giao tiếp rõ ràng
Jeff luôn đề ra mục tiêu và xác định như thế nào là thành công đối với sản phẩm của cô cho team mình. Chúng bao gồm truyền cảm hứng, chất lượng và thực tiễn. Đây cũng là mục tiêu mà mọi người trong team của Jeff tin tưởng và muốn đạt được.
Hiểu rõ thị trường
Cô bạn tôi am hiểu về thị trường của sản phẩm mình. Không chỉ thế, còn biết rõ về đối thủ của mình và dùng sản phẩm của họ hằng ngày. Vì thế, Jeff thường xuyên chia sẻ và trao đổi thông tin và suy nghĩ của mình với các thành viên trong team về sản phẩm trên thị trường. Nhờ đó, mà cô hiểu được hướng đi cần thiết cho sản phẩm của Jeff.
Tìm người chỉ dạy, chỉ dạy cho người khác
Jeff tin rằng cách học tốt nhất là từ sự chỉ dạy của người đi trước. Cô tạo mối quan hệ với họ, không ngại bỏ công và tiền giúp đỡ họ. Ngoài ra, Jeff cũng đi chỉ dạy cho những người muốn học hỏi từ cô. Nhờ đó, quan điểm và tầm nhìn của Jeff ngày càng được mở rộng.
Xây dựng sự tin tưởng
Jeff được ngưỡng mộ bởi sự trung thực, khả năng đem lại sự tin cậy cho người khác. Jeff hiểu rõ sự khác biệt giữa lòng tin đích thực và tin tưởng mù quáng, nên luôn ưu tiên xây dựng một môi trường làm việc mà mọi người đều có thể giúp đỡ lẫn nhau. Lấy mình làm hình mẫu, Jeff lắng nghe và cố gắng thấu hiểu suy nghĩ, quan niệm và cách nhìn nhận của người khác.
Hiểu rõ cách làm
Jeff luôn hướng team về những ý tưởng thực tiễn, có khả năng thực hiện được. Nhờ vào kiến thức kĩ thuật của mình, Jeff giúp tạo ra một vòng lặp vô cùng hiệu quả giữa đưa ra ý tưởng và thực hiện nó.
Jeff không muốn dùng tới Machine Learning nếu có thể bởi sự phức tạp của nó nhưng vẫn rất quan tâm tới sự phát triển của công nghệ và ngay lập tức sử dụng nếu cảm thấy phù hợp với team.
Hãy đối đầu với khó khăn
Rất nhiều phương pháp giải quyết vô cùng sáng tạo được sinh ra từ những khó khăn tưởng chừng như vô vọng. Jeff hiểu rõ sự quan trọng của lựa chọn và việc tự cho rằng mình có thể làm mọi việc sẽ bị phản tác dụng. Vì thế mà cô tin rằng chỉ có vấn đề và khó khăn mới có thể kích thích sự phát triển và phá vỡ giới hạn để đạt được đỉnh cao mới.
Đầu tư chính là sức mạnh
Jeff không phải là con người toàn năng, thay vào đó lại có những thế mạnh riêng biệt để làm nổi bật mình. Jeff luôn đầu tư để phát triển chúng, cô hiểu rõ các ngành khác có thế mạnh là gì những vẫn giữ cho mình không bị cuốn vào chúng. Jeff có tài năng kết nối những thế mạnh của mình để làm nên sự độc đáo của bản thân.
Đặt ra ưu tiên
Jeff còn rất giỏi trong việc quản lí và đặt ra mục tiêu. Cô từng giải quyết được rất nhiều vấn đề chỉ bằng cách viết ra những việc cần phải làm và sắp xếp chúng theo độ quan trọng. Nói cách khác, Jeff là một chuyên gia về việc đặt ra mục tiêu và ưu tiên dựa theo tình huống. Cô không ngần ngại cắt bỏ các tính năng nếu nó giúp ứng dụng chạy tốt hơn (kể cả tính năng tốn rất nhiều công sức của team)
Jeff hiểu rõ việc cắt bỏ tính năng là chuyện không lạ lẫm gì, thế nhưng phải bắt cắt ở đâu. Để thực hiện được bước này, cô thường tự dự đoán những tình huống có thể xảy ra nhằm xác định được cách giải quyết tốt nhất.
Hãy dám xin lỗi chứ đừng chờ đợi
Project lớn luôn đồng nghĩa với việc phải đối mặt với những nguy cơ lớn. Jeff luôn chủ động trong việc chấp nhận phần lỗi về phía mình và xin lỗi ngay khi có thể chứ không chờ đợi. Mặc khác, cô tự lấy mình ra làm hình mẫu cho các thành viên trong nhóm làm theo, nhờ đó mà môi trường làm việc của công ty Jeff luôn được đánh giá rất cao.
Đừng sợ sự thay đổi
Jeff chấp nhận sự thay đổi như một phần tất yếu của quá trình sáng tạo, thường giúp đỡ và khuyến khích các thành viên trong nhóm thỏa sức sáng tạo và suy nghĩ một cách thoáng hơn.
Tò mò là tài sản vô giá của bạn
Jeff rất tò mò và ham học hỏi, không quan tâm là mình đúng mà chỉ thích thú với câu trả lời đúng. Vì thế mà Jeff rất quan tâm tới nhiều ý kiến và cách nhìn nhận khác nhau về cùng một vấn đề.
Data chính là sự thật
Mỗi khi phải đưa ra quyết định quan trọng, Jeff luôn ưu tiên việc thu thập thông tin và phân tích chúng. Cô làm một cách nghiêm túc, rất hiệu quả và sử dụng những tool trợ giúp mỗi khi có thể. Jeff hiểu Data chỉ sẽ cho ta biết một phần của câu chuyện và việc thu thập thông tin sẽ chỉ đạt được được một phần nào đó trước khi nó bắt đầu trở nên thiếu hiệu quả và lúc đó Jeff sẽ đưa ra quyết định của mình.
Đơn giản hóa mọi thứ
Khi gặp phải một vấn đề, Jeff sẽ chia nó thành nhiều phần nhỏ và đưa ra từng giải pháp cho chúng. Mỗi khi bắt đầu một bài diễn thuyết hoặc chia sẻ thông tin, cô luôn tự hỏi người nghe cần biết những gì? thay vì là tôi có thể nói cho họ nghe những điều đó không?. Jeff luôn tính trước những khó khăn mà cô có thể gặp phải nhưng tập trung nhiều hơn về những nguy cơ tiềm ẩn hơn là tự hỏi điều gì sẽ xảy ra.
Giá trị hơn là nói nhiều, ảnh hưởng hơn là số lượng, sáng tạo hơn là bắt lỗi
Jeff là một người rất chủ động, cô luôn là đưa ra hành động đầu tiên và kết thúc những cuộc tranh luận dài dòng ngay khi có thể. Jeff ưu tiên những giải pháp mang tính thiết thực và tốn ít thời gian nhất có thể. Cô cho rằng một ý tưởng mà lại thực tiễn luôn tốt hơn một ý tưởng tuyệt vời mà lại viễn vông. Jeff không ngại việc khó và sẵn sàng bắt tay vào làm mỗi khi team cần mình.
Quan sát từ nhiều khía cạnh
Hay còn gọi là “Systems Thinking”, Jeff có khả năng chú ý đến chi tiết một cách đáng kinh ngạc nhưng vẫn nhận ra được bức tranh toàn cục. Cô xác định được mục tiêu không chỉ ở ngắn hạn mà còn trong tương lai. Nhờ đó mà khả năng lãnh đạo của Jeff được đánh giá rất cao.
Có cách nhìn nhận, quan điểm rõ ràng nhưng không cứng đầu bám giữ nó
Lúc đương đầu với khó khăn cũng chính là khi quan điểm của chúng ta bị đem ra thử thách. Jeff có cách nhìn nhận rất rõ ràng, tuy đó là quan điểm của cô nhưng Jeff không bám víu lấy nó. Nhờ đó mà việc trao đổi diễn ra trong team rất dễ dàng và luôn có trật tự. Mỗi khi phải đưa ra ý tưởng mới, Jeff sẽ cùng với các thành viên trao đổi cũng như thử đặt mình vào quan điểm của người khác. Nhờ đó, với lượng thông tin và bằng chứng phù hợp, cô sẽ chọn ra được ý tưởng tốt nhất.
Tạo ra những sản phẩm hay, phù hợp với mục đích của mình
Jeff được xem là một chuyên gia tạo ra content – không chỉ là để ghi chép mà còn giúp đỡ, chia sẻ cũng như hỗ trợ ý tưởng. Cô hiểu tầm quan trọng của các thiết bị và tùy thuộc vào mỗi hoàn cảnh và vị trí của mình mà sẽ có một tool/sản phẩm phù hợp nhất để sử dụng. Vì thế, cô luôn sử dụng những thứ đơn giản nhất có thể và nó phải phù hợp với mục đích của Jeff.
Luôn đón nhận Feedback cũng như đưa ra feedback
Hãy cố gắng đưa ra những lời nhận xét càng chi tiết càng tốt. Ngoài ra, feedback nên hữu ích cho người nghe và đừng nên vì một động cơ nào cả. Câu hỏi bạn cần phải trả lời là liệu nó có giúp ích được không? chứ không phải là nên nói gì? Nhờ vào feedback mà sản phẩm không chỉ được cải thiện mà nó còn trở thành tâm điểm, lôi kéo sự chú ý. Vì thế Jeff luôn chia sẻ thông tin về công việc của mình sớm nhất có thể nhằm tránh việc ảnh hưởng tiêu cực từ việc thay đổi trong sản phẩm.
Nếu bạn là một CEO hoặc làm trong kinh doanh, khi nhắc tới việc “Scaling” bạn sẽ nghĩ rằng “Thật là tuyệt khi công ty có thể tăng qui mô làm việc của mình”
Còn nếu bạn là dev backend, thì khi nghe sếp nhắc tới “Scaling” là bạn sẽ muốn hét lên “Ôi thánh thần ơi! Liệu Platform của mình chịu nổi không?”
Là một CTO, scaling luôn là thứ khiến tôi điên đầu nhất. Nhớ lại hồi trước khi còn làm ở công ty cũ, sếp thông báo rằng công ty sẽ được featured trên Shark Tank, mọi người đều ăn mừng còn tôi thì sợ xám mặt luôn. Với hơn triệu lượt người dùng sẽ truy cập vào platform, ngay trong cùng một lúc đủ khiến mọi thứ hỗn loạn rồi. Đã thế đây lại là cơ hội duy nhất, chỉ có thể thành công.
Nguyên nhân chính khiến cho việc scaling cực kì áp lực là bởi vì nó không nhất quán: hệ thống của bạn có thể trông như hoạt động tốt chỉ mới một phút trước đó thôi nhưng với một lượng số người dùng tăng tiếp đó ngay lập tức khiến cho nó bị sập. Đã thế, bạn cũng không thể nói với CEO rằng ta phải giảm số lượng người dùng lại trừ khi bạn muốn được cho nghỉ việc. Ngoài ra, để giải quyết vấn đề về scaling còn khó khăn hơn việc gỡ bug rất nhiều lần, bởi bạn chỉ có thể copy toàn bộ production environment, cực kì tốn kém, hoặc là chạy performance test cho production vốn làm ảnh hưởng tiêu cực lên trải nghiệm của người dùng.
Một trong những lỗi mà các startup mắc phải là ra quyết định quá sớm khi mà bạn còn trong giai đoạn prototype như làm việc với outsourced developer nhằm tiết kiệm tiền. Và nếu bạn chọn sai database hoặc hosting platform, nó có thể tốn tới vài năm công sức chỉ để cải thiện và sửa chữa.
Nhiều người lầm tưởng rằng sử dụng các hosting platforms như AWS sẽ giúp giải quyết vấn đề scaling và chỉ cần nâng cấp phần cứng thôi. Tuy nhiên, AWS thực chất chỉ là một phần của quá trình và nó chỉ giúp việc scaling trở nên đơn giản hơn. Ngay cả full-service platforms như Heroku, Firebase, và Lambda cũng chật vật trong việc giải quyết vấn đề scaling. Mặt khác, qui mô càng lớn thì tiền tốn càng nhiều.
Điều đáng sợ nhất khi nói về scaling là tình trạng outage liên quan đến scaling thường diễn ra vào thời điểm then chốt như thời điểm ra mắt tầm cỡ, thời điểm đẩy Marketing… Và thường là khi nó đã xảy ra thì bạn chỉ có thể giảm thiểu thiệt hại bởi dù các developer làm việc ngày đêm thì bản fix chỉ xuất hiện sau một thời gian. Mà nếu có thì chắc là chỉ khi bạn giàu nứt vách và mua những phần cứng khủng để giải quyết một cách nửa vời.
Vì thế khi backend dev nói với bạn rằng cần thêm thời gian để hoàn thiện thì hãy nghe lời họ. Có thể nó khiến việc tung ra tính năng mới bị chậm cũng như phải bỏ đi một vài thứ nhưng thế thì còn đỡ hơn là khi sản phẩm tung ra thị trường và thất bại một cách ê chề.
Node 8 đã ra mắt và tôi nghe thiên hạ đồn rằng nó nhanh hơn phiên bản cũ. Tuy nhiên tất cả cũng chỉ là tin đồn và không có bất kì một số liệu thực tế nào để chứng minh điều đó.
May mắn thay, tôi có một trang React đang chạy trên Node 6 cùng với 2 tiếng đồng hồ để lãng phí nhằm kiểm chứng điều này.
Rất dễ dàng để nâng cấp lên Node 8 (chỉ khoảng 10 phút) mà không có bất cứ library nào bị break. Tôi đã install lên macOS với tập tin .pkg từ website, và mọi thứ đều diễn ra rất nuột. Mặc dù tôi vẫn phải remove bằng tay usr/local/lib/node_modules/.
Mọi thứ đều rất tốt cho đến hiện tại và có thể tôi sẽ thử sau trên một máy Windows.
Edit: Không thể tin được, mọi thứ còn nuột hơn trên Windows. Không hề có một bước manual nào, không có package nào bị break, không có một thông báo lỗi nào hiện lên.
Những số liệu so sánh thu thập được từ thử nghiệm này phù hợp với những trang React từ trung bình đến lớn với single page. Trên server cần có một JSON object với vài nghìn property và HTML return với 2113 DOM nodes.
Bắt đầu buổi thử nghiệm thôi.
Thời gian render server
Hãy bắt đầu với số liệu quan trọng nhất, thời gian cần để server render trang
Ở những lần thử đầu tiên, ta sẽ thấy không có sự khác biệt quá lớn giữa 2 phiên bản. Tuy nhiên khi chạy đến lần thứ 8, thời gian render gần như đã được định đoạt với 104ms của Node 6 và 80ms của Node 8.
Thời gian render giảm 23% là một con số rất đáng cân nhắc. Hay nói cách khác, chúng ta có thể giảm 23% phần cứng cần thiết để render site.
Tôi dự định sẽ yêu cầu các nhân viên upgrade lên Node 8 và giảm instance Amazon của chúng tôi xuống từ 25 còn 20, và quyên góp tháng tiền tiết kiệm đầu tiên cho Node.js.
Đây là một bài test tương tự trong Dev mode:
Chạy một test suite.
Suit này có khoảng 500 Jest dùng để thử nghiệm phần lớn về mounting và un-mounting những component của React, và dĩ nhiên chỉ cho JavaScriptery tổng quát.
Thời gian giảm khoảng 10%. Có lẽ sự cải thiện là không đáng kể bởi vì engine của JavaScript không hề có bất cứ hành động optimization nào (mỗi lần chạy đều là lần chạy mới từ Node). Tất nhiên đó chỉ là phỏng đoán của cá nhân tôi, nếu bạn biết nguyên nhân chính xác có thể comment ở bên dưới để mọi người cùng biết nhé.
Webpack build
Webpack build có một chút disk I/O, một vài Babel transpiling, JS uglifying/minifying, tất cả có kích thước khoảng 500KB JavaScript.
Không có quá nhiều điều để nói về cái này. Thời gian chạy giảm xuống khoảng 7%
Install NPM
Bây giờ tôi sẽ chuyển qua Windows, hệ điều hành thường được sử dụng nhất cho NPM. Có 40 packages trong package.json; 445 package tổng cộng trong cây dependency.
Trong những lần chạy đầu tiên, tôi remove các NPM cache và node_modulesdirectory trong project, vì vậy bài test fetch package thông qua internet.
Rất thú vị là NPM 3 dừng lại ở mức 7Mbps download, còn NPM 5 đạt đến 20 Mbps.
Tôi tiếp tục cho vào yarnđể bài test thêm phần thú vị
Tiếp đến, tôi chạy npm installvới npm cache nhưng node_modulessẽ bị remove giữa những lần chạy. Tôi đã tưởng rằng đây sẽ chủ yếu là disk I/O (copy từ cache vào project directory), nhưng rõ ràng có cái gì đó hơn thế nữa.
Trong cả 2 tình huống, NPM 5 khiến thời gian install giảm khoảng ⅓. Và cũng trong cả 2 trường hợp, Yarn đều nhanh hơn 1 cách đáng kinh ngạc.
Đó là tất cả những gì tôi test được.
Thật lòng mà nói, tôi đã từng nghĩ Node 8 sẽ chỉ cải thiện hiệu năng thêm vài %, và sẽ không bất ngờ nếu đó chỉ là những con số trên bàn giấy và không hề có thực ngoài đời. Nhưng sau buổi test này, việc Node 8 cắt giảm thời gian render xuống ¼ và thời gian install xuống ⅓ thật sự là rất đáng kinh ngạc.
Có thể nói đây là một tín hiệu rất đáng mừng, và tôi xin dành lời khen ngợi đến đội ngũ đã tạo ra sự phát triển này của Node.
À tí nữa thì quên, ngoài hiệu suất được cải thiện thì cũng có một vài tính năng mới đấy.
