Trong những năm gần đây, ngày càng nhiều người bắt đầu quan tâm đến việc học code.
Mọi người tự tìm cách vào con đường lập trình thông qua các khóa học online hoặc qua các buổi gặp mặt offline hoặc chỉ đơn giản là tự nỗ lực.
Các trang web như code.org, codecademy và freeCodeCamp đang ngày càng trở nên phổ biến hơn. Các trang web này có rất nhiều khóa học viết code và cũng sẵn có trên cả YouTube.
Nhưng việc viết code không hề dễ dàng. Dưới đây là một số thách thức mà tất cả chúng ta phải đối mặt khi học.
1. Tìm ra tổng thời gian “tối ưu” để code mỗi ngày.
Nếu bạn đang tự học code, thì khả năng là bạn còn gánh những trách nhiệm khác trong cuộc sống nữa.
Bạn có thể có một công việc bán thời gian, một công việc toàn thời gian, hoặc bạn có thể ở cùng cha mẹ. Vấn đề là mọi người đều bận rộn trong cuộc sống. Vì vậy, làm thế nào để bạn tìm thời gian code hàng ngày?.
Một số người có thể nói rằng: “À, nếu bạn đủ chuyên tâm, bạn luôn có thể tìm thấy thời gian.” Đúng vậy. Tôi đồng ý với điều đó.
Tiếp ngay sau, câu hỏi sẽ là: “Bạn dành bao nhiêu thời gian để code mỗi ngày? Nếu mỗi ngày tôi chỉ có thể chuyên tâm trong nửa giờ , thì vẫn được đúng không? ”
Đây là câu hỏi mà chỉ bản thân bạn mới có thể trả lời. Rất khó để ước tính số giờ mỗi ngày để bạn code sao cho đủ. Để vừa gọn và vừa dễ dàng, một số người đề nghị cho việc này là 15 phút . Đây là thời gian đủ tốt.
Ở khía cạnh khác, tôi cũng đã nghe những lập trình viên trong vòng một năm hoặc lâu hơn dành 9 hoặc 10 giờ để code mỗi ngày. Nếu bạn muốn có động lực, bạn có thể đưa ra một nhìn nhận từ việc này.
Điểm mấu chốt là đây: chỉ có bản thân bạn mới biết bạn có thể code hàng ngày bao lâu và làm thành thói quen mà không bị đốt cháy giai đoạn. Phần cuối cùng thực sự quan trọng. Nhà sáng lập freeCodeCamp, Quincy Larson đã từng nói trên twitter của mình:
“It is not about your daily progress, it is about progress daily.”
(Tạm dịch: Không phải biến nó thành công việc hàng ngày, mà biến nó thành sự tiến bộ hàng ngày)
Đây là một đoạn video về một senior developer, ông ấy đã ở trong lĩnh vực công nghệ trong nhiều thập niên , ông ấy nói về việc các lập trình viên phải làm nhiều đến mức nào mỗi ngày trong khi họ đang làm việc.
Nó sẽ không phải là tiêu chuẩn vàng, nhưng nó sẽ cung cấp cho bạn một ý tưởng về cách để thiết lập cho mình một cái nhìn thực tế, và quan trọng nhất là có kế hoạch chắc chắn khi bắt đầu học code hàng ngày.
2. Tìm sự cân bằng giữa “chưa đủ tiến bộ” và “đốt cháy giai đoạn”.
Đối với cá nhân tôi, tôi đã vật lộn với điều này rất nhiều.
Có những ngày tôi không thể hiểu được một khái niệm hoặc bất kỳ đoạn code nào từ cuốn sách mà tôi đã đọc. Tôi không thể nào hiểu nó. Tôi chắc là đã bị đốt cháy giai đoạn đến mất tệ hại , đến nỗi tôi phải bình tĩnh lại, đi đến ban công và hít một hơi thật sâu.
Từ thời điểm đó trở đi, tôi luôn nhắc nhở bản thân mình đừng làm việc quá sức tới mức không tìm lại được bản thân.
Lập trình không phải là dễ dàng. Nó đòi hỏi bạn phải tập trung, đặc biệt là khi bạn đang học những thứ mới. Đó là việc đánh thuế về tinh thần và có những lúc bạn không thể tính toán được – tại sao code của bạn không hoạt động hoặc thậm chí là ngược lại.
Tôi nhận ra mình làm việc hiệu quả nhất bất cứ khi nào bản thân thực sự tập trung vào vấn đề đang làm ngay lúc đó, nhưng chính lúc đó tôi đã thực sự thư giãn, tận hưởng toàn bộ quá trình.
Những lúc khi tôi :
Tìm thấy một vấn đề tôi cần phải giải quyết.
Tìm thấy giải pháp thông qua diễn đàn online.
Đã thử một loạt các cách khác nhau để giải quyết vấn đề chỉ để để tìm ra một cách đúng.
Đã giải quyết hết vấn đề.
Để đối phó với thực tế nhiều thứ chúng ta đang học khá là phức tạp (cấu trúc dữ liệu và giải thuật), tôi đã phát triển quy tắc 50/50 này bất cứ khi nào tôi học code.
Tôi sử dụng 50% thời gian để thực hiện các công việc khó , nghiên cứu các khái niệm, giải thuật cơ bản và những thứ tương tự. 50% thời gian còn lại tôi đang làm dự án của riêng mình, các dự án mà tôi thực sự đam mê. Vì vậy, có một sự cân bằng khi nói đến việc nghiên cứu hàng ngày của tôi.
Vì lẽ đó, để tiếp tục , bạn cần yêu cái mà bạn làm. Điều này dẫn chúng ta đến nội dung chính tiếp theo.
3. Thật sự thích thú với những gì bạn đang làm là cách duy nhất để vượt qua tất cả những trở ngại.
Đôi khi sự thật chỉ đơn giản là vậy. Nếu bạn yêu thích con đường bạn đang nắm bắt, yêu công việc bạn đang làm, yêu hướng bạn đang đi … bạn không cần sự thừa nhận từ thế giới bên ngoài.
Loại tình yêu này không thể được mượn hoặc thay thế, hoặc thậm chí tệ hơn, giả mạo.
4. Tiếp tục quay lại code ngay sau khi hoàn thành các công việc khác hằng ngày.
Thực tế là khi nói đến tự học, chưa bao giờ chỉ là bản thân bạn, ở đó, học tập.
Trong cuộc sống, tất cả chúng ta đều có đầy đủ bổn phận mà chúng ta được giao phó. Bạn có thể là chồng, hoặc vợ hoặc cha mẹ của ai đó. Bạn cần phải chăm sóc gia đình , hoặc bạn có một công việc bạn cần phải tham gia. Hoặc có thể bạn là sinh viên cần hoàn thành bằng tốt nghiệp hoặc bậc học.
Với tất cả các bổn phận đặt trên vai chúng ta, đâu là nơi chúng ta tìm ra thời gian để code?
Sự thật là đôi khi bạn không có hoặc chỉ đơn giản là không thể. Có những lúc tôi bỏ qua code. Thời gian “ngưng code” dài nhất của tôi là hai tháng.
Nhưng sau đó, tôi quay lại code ngay lập tức. Và tôi phát hiện ra rằng tôi đã quên rất nhiều thứ mình đã học. Nó có thể gây bực bội khi bạn lấy lại cùng một cuốn sách , và đơn giản bạn không biết làm thế nào tiếp theo. “Chúa ơi, tôi có thực sự phải đọc lại tất cả các chương và làm lại tất cả các yêu cầu không?”
Đấy là lúc bạn chỉ cần phải kiên trì và phải nghiền nó ra.
Bạn cần phải tự nhủ: “Được rồi, giờ học đầu tiên này có vẻ thật sự chậm và không mấy hiệu quả. Nhưng được rồi, tôi sẽ tiếp tục học thêm nữa vào ngày mai. ”
Không còn cách nào ngoài việc tiếp tục, không ngừng và cố gắng cho vấn đề này. Tham gia diễn đàn hoặc Twitter và bày tỏ tâm sự của bạn. Nhưng một khi bạn đã làm xong, quay trở lại để code ngay lập tức.
5. Duy trì tạo động lực cho mình bằng mọi cách.
Tự học rất khác nhau với việc đến trường. Không có ai xung quanh bạn khi bạn đang code. Không bạn cùng lớp, không có tương tác xã hội, bạn không thể thấy “nghi lễ trọng đại” đang chờ bạn ở cuối đường hầm. Hầu hết thời gian bạn làm một mình ,cũng như ở một mình.
Vì vậy, bạn cần phải tìm động lực để giữ cho mình tiến lên phía trước.
Tôi dành toàn thời gian để kiểm tra (r / macsetups) ,bởi vì có nhiều các lập trình viên ở đó. Và họ đang sử dụng chung tất cả các phần cứng mạnh mẽ để tạo ra phần mềm. Không có gì đáng khen hơn thế.
Cũng tự thưởng cho bạn, và làm việc này trở thành một thói quen.
Nó có thể nhỏ, hoặc nó có thể lớn. Nó có thể là được tắm nước nóng vào cuối ngày, hoặc một thức uống lạnh. Hãy nói với bản thân rằng bạn đang làm một công việc tuyệt vời. Điều này cần thiết khi học lập trình. Treo bức ảnh này lên tường trước mặt bạn – bởi vì bạn phải tin vào một ngày bạn có thể là người đang ngồi trước mặt nó.
6. Đừng rơi vào sai lầm “học tập chỉ vì mục đích học” Đi phỏng vấn, gặp gỡ và nộp đơn xin việc.
Có những lúc chúng ta có thể lạc trôi khi học code. Tôi cảm thấy có những khoảnh khắc mà bạn chỉ muốn lười biếng. Không phải theo cách bạn không muốn học nữa , nhưng theo cách mà bạn âm thầm hy vọng chỉ cần ngồi trước màn hình cả ngày, bạn không phải đối mặt với thử thách thực sự: Kiếm một công việc với tư cách là nhà phát triển .
Đừng rơi vào suy nghĩ sai lầm rằng “Tôi dự định học cho đủ tốt. sau đó tôi sẽ nghĩ về việc làm khi đã sẵn sàng. ”
Để tiếp cận với khách hàng tiềm năng, kể cả xây dựng trang web miễn phí cho gia đình và bạn bè. Đây là điều tôi nên làm thường xuyên hơn.
Do đó, lần sau khi bạn tham gia phỏng vấn, bạn có trình bày loại công việc bạn đã làm. Nó sẽ thêm giá trị vào hồ sơ lý lịch của bạn. Bước đầu tiên luôn khó khăn nhất. Nhưng bạn phải làm điều đó như không có vấn đề gì.
Tất cả những điều trên là những thử thách và tình huống bạn sẽ phải đối mặt trên con đường để trở thành lập trình viên. Chấp nhận chúng, đối mặt chúng với thái độ đúng đắn – những rào cản bạn đối mặt chỉ có thể làm cho bạn mạnh mẽ và tốt hơn.
Cuối cùng nhưng không kém phần quan trọng, code vui vẻ! Tận hưởng những gì bạn đang gầy dựng, cho dù đó là dự án của bạn hay tương lai của riêng bạn.
Agile là gì? Scrum là gì? Hiện nay Agile là phương thức phát triển phần mềm được nhiều doanh nghiệp sử dụng, đặc biệt là Scrum. Bài viết này sẽ giải thích các khái niệm cơ bản nhất cũng như những giá trị cốt lõi về Agile và Scrum hiểu được lí do tại sao nó lại được sử dụng phổ biến đến vậy.
Agile là gì?
Agile là một phương pháp phát triển phần mềm linh hoạt, là một hướng tiếp cận cụ thể cho việc quản lý dự án phần mềm. Nó gồm một quá trình làm việc tương tác và tích hợp để có thể đưa sản phẩm đến tay người dùng càng nhanh càng tốt.
Trong các dự án phần mềm, đặc biệt là các dự án chúng ta sẽ gặp rất nhiều khó khăn trong việc thu thập đầy đủ và chính xác các requirements của product để lập plan tốt ngay từ đầu. Có quá nhiều vấn đề gây ảnh hưởng đến việc phát triển phần mềm mà chúng ta không lường trước được. Ví dụ như những vấn đề có thể đến từ những yếu tố như kinh doanh, kỹ thuật, con người, thời gian ra mắt ….
Những phương pháp phát triển phần mềm theo cách truyền thống ngày càng bộc lộ nhiều nhược điểm và tỷ lệ các dự án thất bại cao trong thời kỳ bùng phát của ngành công nghệ. Nhận ra vấn đề đó, một số cá nhân và công ty riêng lẻ đã đưa ra các phương pháp phát triển phần mềm hiện đại hơn và khác nhau để thích ứng với tình hình mới.
Những phương thức phát triển phần mềm này giúp phần nào giải quyết được một số vấn đề nhưng lại phát sinh vấn đề khác về sự cộng tác, kỹ thuật, công cụ, hướng phát triển, chia sẻ ….
Bản tuyên ngôn Agile (Agile Manifesto)
Vào năm 2001, bản tuyên ngôn Agile (Agile Manifesto) đã được thống nhất và ra đời bởi một nhóm người có uy tính trong phát triển phần mềm:
1. Cá nhân và sự tương tác hơn là quy trình và công cụ
Đặt trọng tâm vào con người và sự tương hỗ giữa những thành viên trong team. Nếu dự án có những thành viên có năng lực, chịu làm việc cùng nhau thì sẽ mang đến thành công cho dự án.
Nếu dự án của bạn có quy trình làm việc tốt, được hỗ trợ bởi những công cụ tốt nhất nhưng những thành viên không thống nhất hoặc cùng nhìn về một hướng thì khả năng dự án thất bại là rất lớn. Nói điều này không có nghĩa là phủ nhận tầm quan trọng của quy trình và công cụ nhưng trong Agile nó được đặt sau yếu tố con người.
Quy trình là các thủ tục cần thiết để phát triển dự án như thiết kế, sau đó đến lập trình, rồi kiểm tra QA/QC. Hay để đưa ra một chức năng nào đó cần phải có sự đồng ý của bộ phận QA/QC …. Quy trình này do mỗi công ty quy định và bắt buộc các nhân viên khi tham gia vào dự án phải tuân thủ.
Công cụ là phần mềm được sử dụng trong dự án như : Phần mềm quản lý công việc, phần mềm quản lý source code, phần mềm quản lý lỗi… Có rất nhiều công cụ được sử dụng để hỗ trợ một tổ chức vận hành.
2. Phần mềm chạy tốt hơn là tài liệu đầy đủ
Trong một số quy trình phát triển phần mềm, việc tạo ra và cập nhật các tài liệu về sản phẩm là bắt buộc. Nhóm lập trình viên không thể hoặc không đồng ý tiến hành công việc nếu không có tài liệu đặc tả về yêu cầu, thiết kế hệ thống.
Nhóm kiểm thử thì yêu cầu tài liệu về sản phẩm để có thể viết trường hợp kiểm thử và kiểm thử được. Nhóm QA đòi tất cả các tài liệu phải được viết trước khi sản phẩm được giao cho khách hàng nếu không thì không đủ điều kiện, chuẩn để giao sản phẩm cho khách hàng.
Việc viết tài liệu thật ra rất mất nhiều thời gian và được cho là rất chán. Ý tưởng ở đây là tại sao mình phải tập trung quá nhiều cho việc không cần thiết mà không dành thời gian đó để trao đổi để hiểu thêm về công việc phải làm. Sau đó đúc kết và chỉ viết những gì mà mọi người cần đọc.
3. Cộng tác với khách hàng hơn là đàm phán hợp đồng
Ta luôn nghe các câu này “Khách hàng là thượng đế” hay “khách hàng luôn luôn đúng”. Tuy nhiên thì khách hàng có nhiều dạng. Cách duy nhất để có thể làm việc tốt là phải cộng tác với khách hàng để hiểu được khách hàng muốn gì và cần gì để có thể tư vấn và điều chỉnh thay vì chỉ dựa vào những điều đã quy định trong hợp đồng.
Trao đổi và thảo luận với khách hàng về sự cần thiết có hay không của một chức năng trong sản phẩm, từ đó quyết định là có nên làm hay không. Tất nhiên để thuyết phục khách hàng thì cần có số liệu nghiên cứu cụ thể chẳng hạn.
4. Phản hồi với sự thay đổi hơn là bám theo kế hoạch
Có một điểm chung là hầu hết những dự án đều có sự thay đổi điều chỉnh khi triển khai. Sự thay đổi đó có thể là thay đổi về requirements, thay đổi tech stack, thay đổi nhân sự, thay đổi deadline, thay đổi phương thức làm việc… mặc dù kế hoạch đã được định ra rõ ràng từ đầu.
Agile không khuyến khích cho sự thay đổi nhưng khuyến khích chúng ta tập thích nghi với thay đổi.
Một trong các nguyên tắc cơ bản của agile là “phần mềm chạy tốt chính là thước đo của tiến độ”. Nguyên tắc này giúp nhóm dám loại bỏ đi các công việc dư thừa không trực tiếp mang lại giá trị cho sản phẩm.
Để vận hành được cơ chế “làm việc dựa trên giá trị”, nhóm agile thường làm việc trực tiếp và thường xuyên với khách hàng, cộng tác trực tiếp với họ để biết yêu cầu nào có độ ưu tiên cao hơn, mang lại giá trị hơn sớm nhất có thể cho dự án. Nhờ đó các dự án agile thường giúp khách hàng tối ưu hóa được giá trị của dự án. Một cách gần như trực tiếp, agile gia tăng đáng kể độ hài lòng của khách hàng.
12 nguyên tắc trong Agile software development
Nguyên tắc trong phát triển phần mềm Agile được trình bày trong Manifesto Agile và mô tả các giá trị và nguyên tắc cốt lõi của phương pháp phát triển Agile. Dưới đây là 12 nguyên tắc chính trong Agile software development:
Khách hàng hài lòng bằng cách cung cấp phần mềm có giá trị cao: Cung cấp phần mềm có giá trị cao, liên tục và sớm để đáp ứng nhu cầu của khách hàng và cải thiện sự hài lòng của họ.
Thay đổi yêu cầu là điều bình thường: Đón nhận và thích ứng với thay đổi yêu cầu, ngay cả khi phát triển ở giai đoạn muộn. Điều này giúp cung cấp giá trị tốt nhất cho khách hàng.
Phát triển phần mềm liên tục và thường xuyên: Cung cấp phần mềm có thể hoạt động một cách thường xuyên và liên tục, từ vài tuần đến vài tháng, với một chu kỳ phát triển ngắn hơn.
Hợp tác chặt chẽ giữa các bên liên quan: Hợp tác liên tục giữa các nhà phát triển và các bên liên quan (bao gồm khách hàng và các thành viên nhóm) trong suốt quá trình phát triển.
Xây dựng dựa trên đội ngũ tự quản lý và có động lực cao: Xây dựng dự án xung quanh các đội ngũ tự quản lý và có động lực cao. Đảm bảo rằng các thành viên đội ngũ có thể tự tổ chức và có đủ kỹ năng và sự tự tin để hoàn thành công việc.
Tạo ra phần mềm có thể hoạt động được: Phần mềm hoạt động là mục tiêu chính. Các bản phát hành nhỏ và có thể hoạt động là ưu tiên hàng đầu.
Thiết kế đơn giản và tối ưu: Thiết kế phần mềm đơn giản, với tối đa tính năng cần thiết để đáp ứng nhu cầu hiện tại. Tập trung vào việc giảm thiểu công việc chưa cần thiết và tối ưu hóa hiệu suất.
Tốc độ phát triển và khả năng duy trì cao: Duy trì khả năng phát triển nhanh chóng và có khả năng thay đổi dễ dàng. Điều này bao gồm việc duy trì mã nguồn đơn giản, dễ hiểu và có thể dễ dàng thay đổi khi cần thiết.
Phản hồi sớm và liên tục từ khách hàng: Nhận phản hồi thường xuyên từ khách hàng để đảm bảo rằng phần mềm đáp ứng nhu cầu và mong muốn của họ. Phản hồi nhanh chóng giúp điều chỉnh và cải thiện sản phẩm liên tục.
Kỹ thuật và thiết kế tốt: Khuyến khích kỹ thuật tốt và thiết kế phần mềm tốt, giúp duy trì sự nhất quán và chất lượng của mã nguồn. Đầu tư vào kỹ thuật và thiết kế sẽ giúp sản phẩm cuối cùng có chất lượng cao hơn.
Tạo môi trường làm việc tích cực: Tạo ra một môi trường làm việc tích cực, nơi các thành viên trong nhóm có thể giao tiếp mở, hỗ trợ lẫn nhau và làm việc cùng nhau hiệu quả.
Đánh giá và cải tiến thường xuyên: Đánh giá thường xuyên các quy trình làm việc, công cụ và kỹ thuật. Cải tiến liên tục giúp nâng cao hiệu suất nhóm và chất lượng sản phẩm.
Những nguyên tắc này giúp các nhóm phát triển phần mềm Agile đáp ứng nhanh chóng với sự thay đổi, duy trì chất lượng sản phẩm, và cải thiện hiệu quả công việc qua việc làm việc hợp tác và có tổ chức.
8 đặc trưng của Agile
Agile là một phương pháp phát triển phần mềm linh hoạt, nổi bật với khả năng thích ứng và phản ứng nhanh với thay đổi. Dưới đây là các đặc trưng chính của Agile:
Cung cấp sản phẩm làm việc sớm và thường xuyên
Agile tập trung vào việc cung cấp các phiên bản sản phẩm làm việc một cách sớm và liên tục. Thay vì chờ đợi đến cuối dự án để hoàn thành, Agile khuyến khích giao hàng các sản phẩm có thể sử dụng được trong các chu kỳ ngắn, thường là vài tuần đến vài tháng. Điều này giúp đánh giá và điều chỉnh sản phẩm dựa trên phản hồi thực tế từ người dùng và môi trường.
Đánh giá và ưu tiên liên tục
Trong Agile, việc đánh giá và ưu tiên công việc là một quá trình liên tục. Điều này đảm bảo rằng các phần của dự án được chọn và phát triển dựa trên giá trị hiện tại và phản hồi từ người dùng, thay vì theo một kế hoạch cứng nhắc ban đầu. Quyết định về các bước tiếp theo được đưa ra dựa trên dữ liệu mới nhất và thay đổi trong yêu cầu của khách hàng.
Giới hạn công việc đang thực hiện
Để tăng cường hiệu quả và khả năng phản ứng, Agile khuyến khích giới hạn số lượng công việc đang thực hiện đồng thời. Việc này giúp đội ngũ tập trung hoàn thành một nhiệm vụ trước khi bắt đầu nhiệm vụ khác, giảm thiểu công việc chưa hoàn thành và tối ưu hóa năng suất.
Kiến trúc phát triển dần và kiểm thử tự động
Agile khuyến khích xây dựng kiến trúc hệ thống đơn giản và dễ thay đổi, bắt đầu với các yếu tố cơ bản và mở rộng dần theo yêu cầu thực tế. Để đảm bảo chất lượng và tính ổn định, kiểm thử tự động là một phần không thể thiếu trong quy trình phát triển Agile.
Nhóm làm việc tự quản lý và đa chức năng
Các đội Agile thường là các nhóm nhỏ, tự quản lý và có thành viên từ nhiều lĩnh vực khác nhau, giúp họ có khả năng tự tổ chức và thực hiện các quyết định cần thiết để hoàn thành dự án. Điều này giúp nhóm có sự linh hoạt và nhanh nhạy trong việc phản ứng với thay đổi và thách thức.
Hợp tác chặt chẽ giữa khách hàng và nhà phát triển
Sự hợp tác liên tục giữa khách hàng và đội phát triển là trọng tâm của Agile. Khách hàng có cái nhìn sâu sắc về giá trị của sản phẩm, trong khi đội phát triển hiểu rõ các tùy chọn thực hiện và rủi ro. Việc duy trì sự hợp tác chặt chẽ giúp đảm bảo rằng sản phẩm cuối cùng đáp ứng được mong đợi và yêu cầu thực tế.
Tính minh bạch
Trong môi trường Agile, thông tin quan trọng về quá trình phát triển phải được minh bạch và dễ dàng tiếp cận đối với tất cả các thành viên trong nhóm. Điều này giúp duy trì sự đồng thuận và đảm bảo rằng mọi người đều có thể theo dõi tiến trình và hiểu rõ các mục tiêu và quyết định.
An toàn
An toàn là một yếu tố quan trọng trong Agile, bao gồm an toàn xã hội, an toàn trong nhóm và an toàn kỹ thuật. Đội ngũ cần phải có không gian an toàn để thử nghiệm và sáng tạo mà không lo lắng về sự thất bại, và hệ thống cũng cần được thiết kế để giảm thiểu ảnh hưởng của các lỗi hoặc sự cố.
Các Phương Pháp Agile Phổ Biến
Scrum: Scrum tập trung vào việc quản lý dự án qua các vòng lặp gọi là “sprints”, thường kéo dài từ 2 đến 4 tuần. Nó yêu cầu các nhóm làm việc nhanh chóng và liên tục cải tiến sản phẩm.
Kanban: Kanban sử dụng bảng để quản lý công việc và tối ưu hóa quy trình bằng cách giới hạn số lượng công việc đang thực hiện đồng thời. Nó giúp cải thiện hiệu suất và giảm thiểu thời gian hoàn thành công việc.
Extreme Programming (XP): XP nhấn mạnh vào việc cải thiện chất lượng phần mềm qua các kỹ thuật như lập trình đôi (pair programming) và phát triển dựa trên kiểm thử (test-driven development).
Lean Software Development: Được lấy cảm hứng từ sản xuất Lean, phương pháp này tập trung vào việc giảm lãng phí và tối ưu hóa quy trình phát triển phần mềm để tạo ra giá trị tối đa cho khách hàng.
Crystal: Crystal là một phương pháp linh hoạt, điều chỉnh quy trình phát triển dựa trên quy mô và mức độ rủi ro của dự án. Nó phù hợp với các dự án có nhu cầu và tình huống đa dạng.
Feature-Driven Development (FDD): FDD tập trung vào việc phát triển các tính năng cụ thể từ góc nhìn của người dùng cuối, với sự chú trọng vào việc lập kế hoạch và triển khai các tính năng chính trong sản phẩm.
Cùng tìm hiểu chi tiết hơn về Scrum – Phương pháp Agile phổ biến nhất hiện nay:
Scrum là gì?
Scrum là một “bộ khung làm việc” cơ bản để tiếp cận những công việc phức tạp. Dựa trên bộ khung này, nhóm làm việc có thể áp dụng những quy trình, kỹ thuật khác nhau cho công việc của mình… Nó là một thành viên của họ Agile.
Credit: Scrum.org
Scrum có ích gì cho phát triển phầm mềm hiện nay
Nó giúp loại bỏ những công đoạn phức tạp và chỉ tập trung vào những công đoạn cần thiết đáp ứng được nhu cầu của khác hàng đưa ra. Ba yếu tố nòng cốt tạo thành một mô hình quản lý tiến trình thực nghiệm gồm: sự minh bạch (transparency), thanh tra (inspection) và thích nghi (adaptation).
Ba giá trị cốt lõi của Scrum
1. Minh bạch
Muốn áp dụng thành công Scrum, các thông tin liên quan đến quá trình phải mình bạch và thông suốt. Các thông tin có thể là tầm nhìn của sản phẩm, yêu cầu của khách hàng, tiến độ công việc, các rào cản khác…
Từ đó mọi thành viên ở vai trò khác nhau có đầy đủ thông tin cần có để tiến hành quyết định trong việc nâng cao hiệu quả công việc.
2. Thanh tra
Phải thường xuyên thanh tra các hoạt động trong Scrum và tiến độ đến đích để phát hiện các bất thường không theo ý muốn. Tần suất thanh tra không nên quá dày để khỏi ảnh hưởng đến công việc. Công tác thanh tra khi được thực hiện bởi người có kĩ năng tại các điểm quan trọng của công việc sẽ giúp cải tiến liên tục trong Scrum.
3. Thích nghi
Scrum mang lợi thế là tính linh hoạt rất cao, nhờ đó mang lại tính thích nghi cao. Dựa vào thông tin liên tục và minh bạch từ quá trình thanh tra và làm việc, Scrum có thể cho lại các thay đổi tích cực, nhờ đó mang lại thành công cho dự án.
Lợi ích mà Scrum mang lại
Tính minh bạch, kiểm tra, và thích nghi là 3 nền tảng cơ bản của Scrum. Và dưới đây là những lý do tại sao nên dùng Scrum.
Cải thiện chất lượng phần mềm, dễ học và dễ sử dụng.
Rút ngắn thời gian phát hành phần mềm, cho phép khách hàng sử dụng sản phẩm sớm hơn.
Nâng cao tinh thần đồng đội, tối ưu hóa hiệu quả và nỗ lực của đội phát triển.
Gia tăng tỷ suất hoàn vốn đầu tư (ROI)
Tăng mức độ hài lòng của khách hàng
Kiểm soát dự án tốt, cải tiến liên tục
Giảm thiểu rủi ro khi xây dựng sản phẩm
Các khái niệm cơ bản Scrum
1. Scrum Team
Scrum team chia làm 3 vai trò bao gồm những thành phần sau:
Product Owner: Nhiệm vụ của Product Owner là đảm bảo việc quản lý những công việc còn tồn đọng (Product backlog) của việc phát triển sản phẩm phần mềm. Product Owner phải liên tục cập nhật thông tin cho các thành viên trong team để họ hiểu về yêu cầu hay các tính năng cần có của sản phẩm ngay cả khi họ không trực tiếp phát triển tính năng đó.
Development Team: là những lập trình viên sẽ tham gia vào việc phát triển từng tính năng cụ thể. Các lập trình viên này có thể sẽ có kỹ năng khác nhau và một số sẽ giỏi về những kỹ năng nhất định. Tuy nhiên khi sử dụng Scrum thì tất cả các thành viên của Development Team yêu cầu phải có khả năng làm việc thay thế vị trí của nhau và không ai chỉ chịu trách nhiệm phát triển một (hoặc một số) tính năng nhất định.
Scrum Master: sẽ chịu trách nhiệm cho việc lên kế hoạch để phân công công việc, sắp xếp thứ tự ưu tiên giải quyết những công việc tồn đọng nào có trong Backlog trước, tổ chức các buổi họp với Product Owner để theo dõi tình hình và nắm thông tin cần thiết.
2. Sprint
Sprint là mộ phân đoạn lặp đi lặp lại trong quy trình phát triển phần mềm, có khung thời gian thường là 1 tháng (từ 1 – 4 tuần) mà theo đó sản phẩm sẽ được release phiên bản mới. Khi một Sprint kết thúc thì Scrum Master cần phải chuyển trạng thái của nó sang Done.
Khi bắt đầu một Sprint thì Scrum Master cần đưa ra mục tiêu của Sprint đó và mục tiêu này không được phép thay đổi cho tới khi Sprint hoàn thành. Tuy nhiên Product Owner vẫn có quyền huỷ một Sprint trước thời hạn kết thúc của nó.
Mặc dù để làm điều này thì Product Owner cần sự đồng thuận của Development Team cũng như Scrum Master. Sau khi một Sprint kết thúc thì các bên sẽ dựa trên kết quả của Sprint đó để lên kế hoạch cho Sprint tiếp theo.
3. Sprint Planning
Đây là bước đầu tiên cần phải thực hiện trước khi một Sprint bắt đầu. Development team họp với Product Owner để lên kế hoạch cho một sprint. Những công việc nào cần phải được hoàn thành trong Sprint này và làm sao để có thể hoàn thành những công việc này.
Sau khi thống nhất được số lượng công việc, thời gian hoàn thành thì chúng ta có thể bắt đầu Sprint. Trong khi thực hiện một Sprint chúng ta sẽ phải có những buổi họp được gọi là Daily Sprint hay Daily Meeting.
4. Daily Sprint
Các buổi họp Daily Sprint thường kéo dài khoản 15 phút, trong buổi họp này tất cả các thành viên sẽ lần lượt báo cáo lại:
Những gì họ đã làm được ngày hôm qua
Những gì họ cần làm ngày hôm nay
Những khó khăn mà họ gặp phải
Mỗi buổi họp này sẽ giúp việc dự kiến được kế hoạch đưa ra trong Sprint đang làm sẽ tiến triển ra sao và liệu có cần phải cập nhật lại bản kế hoạch đã đưa ra hay không. Tất nhiên cần nhớ rằng việc thay đổi kế hoạch này không bao gồm thay đổi mục tiêu đã đưa ra của Sprint.
Ví dụ bạn có thể tăng thêm thời gian để hoàn thành một chức năng và qua đó khiến Sprint phải kéo dài hơn dự kiến. Tuy nhiên mục tiêu của Sprint là cho phát hành một phiên bản mới cần được giữ nguyên.
5. Sprint Review
Là công việc được thực hiện bởi nhóm phát triển và product owner ở cuối mối Sprint nhằm đánh giá lại kết quả thực hiện được. Từ lúc Sprint mới hoàn thành và qua đó đưa ra những chỉnh sửa, thay đổi cần thiết ở Sprint sau.
6. Sprint Restrospective
Dưới sự trợ giúp của Scrum master, team phát triển sẽ tổng kết những kiến nghị và đánh giá từ bước Sprint Review ở trên để đưa ra những cải tiến nhằm nâng cao hiệu quả làm việc cũng như sản phẩm.
Scrum sử dụng các công cụ rất đơn giản nhưng hiệu quả để trợ giúp công việc.
Product backlog
Đây là danh sách ưu tiên các tính năng (feature) hoặc đầu ra khác của dự án. Có thể hiểu như là danh sách yêu cầu (requirement) của dự án.
Product Owner chịu trách nhiệm sắp xếp độ ưu tiên cho từng hạng mục (Product Backlog Item) trong Product Backlog dựa trên các giá trị do Product Owner định nghĩa (thường là giá trị thương mại – business value).
Sprint backlog
Đây là bản kế hoạch cho một Sprint; là kết quả của buổi họp lập kế hoạch (Sprint Planning).
Với sự kết hợp của Product Owner, nhóm sẽ phân tích các yêu cầu theo độ ưu tiên từ cao xuống thấp để hiện thực hóa các hạng mục trong Product Backlog dưới dạng danh sách công việc (TODO list).
Burndown Chart
Đây là biểu đồ hiển thị xu hướng của dự án dựa trên lượng thời gian cần thiết còn lại để hoàn tất công việc.
Burndown Chart có thể được dùng để theo dõi tiến độ của Sprint (được gọi là Sprint Burndown Chart) hoặc của cả dự án (Project Burndown Chart).
Biểu đồ burndown không phải là một thành tố tiêu chuẩn của Scrum theo định nghĩa mới, nhưng vẫn được sử dụng rộng rãi do tính hữu ích của nó.
Các công cụ quản lý dự án theo Agile mà bạn nên biết
Trello
Trello là một trong những ứng dụng quản lý dự án nổi tiếng và được sử dụng nhiều nhất. Nó có cả tài khoản miễn phí và cao cấp mang đến cho bạn cơ hội tuyệt vời để sử dụng hầu hết các chức năng phổ biến.
Cấu trúc của Trello dựa trên phương pháp kanban. Tất cả các dự án được đại diện bởi các bảng, có chứa danh sách. Mọi danh sách đều có các thẻ lũy tiến mà bạn được tạo dưới dạng kéo và thả. Người dùng có liên quan đến bảng, có thể được gán cho thẻ.
Tóm lại, nó có nhiều tính năng hay, nhỏ nhưng không kém phần hữu ích: viết bình luận, chèn tệp đính kèm, ghi chú, ngày đáo hạn, danh sách kiểm tra, nhãn màu, tích hợp với các ứng dụng khác, v.v. Ngoài ra, Trello được hỗ trợ bởi tất cả các nền tảng di động. Trello là công cụ có thể được sử dụng cho cả công việc và các quy trình cá nhân.
JIRA
JIRA là một công cụ được phát triển để theo dõi lỗi, theo dõi vấn đề và quản lý dự án cho các quy trình phát triển phần mềm và di động. Bảng điều khiển JIRA có nhiều chức năng & tính năng hữu ích có thể xử lý các vấn đề khác nhau một cách dễ dàng.
Một số tính năng và sự cố chính: loại sự cố, quy trình làm việc, màn hình, trường, thuộc tính vấn đề. Một số tính năng bạn sẽ không tìm thấy ở nơi khác. Bảng điều khiển trên JIRA có thể được tùy chỉnh để phù hợp với quy trình kinh doanh của bạn.
Asana
Asana là công cụ quản lý công việc cho phép các nhóm chia sẻ, lập kế hoạch, tổ chức và theo dõi tiến trình của các nhiệm vụ mà mỗi thành viên đang thực hiện. Nó đơn giản, dễ sử dụng và miễn phí cho tối đa 30 người dùng trong một nhóm.
Như tất cả các nền tảng phần mềm quản lý dự án Agile trước đây với mục tiêu chính là cho phép quản lý các dự án và nhiệm vụ. Điều đáng chú ý là bạn không cần phải có email để sử dụng Asana. Mỗi nhóm có thể tạo nơi làm việc sẽ chứa các dự án và nhiệm vụ của dự án: mỗi tác vụ có thể có ghi chú, nhận xét, tệp đính kèm và thẻ.
Công cụ này có thể được sử dụng cho các quy trình nhỏ và cho các quy trình lớn mà không có bất kỳ giới hạn nào trong các ngành hoặc bộ phận.
Cleeksy
Cleeksy là một phần mềm quản lý dự án chú trọng vào cộng tác và làm việc hiệu suất cao trong thời kỳ số, đã có mặt trên cả giao diện desktop và di động. Cleeksy cung cấp tính năng quản lý dự án theo sprint cho những team đang hoạt động theo phương pháp Agile (Kanban, Scrum…). Từ đó, bạn dễ dàng tạo và quản lý các backlog dự án, chia nhỏ thành các sprint ngắn hạn, bám sát tình hình thực tế, linh hoạt điều chỉnh để đáp ứng tốt hơn những thay đổi trong yêu cầu của khách hàng và thị trường.
Đối với các team làm remote hay hybrid, team cũng dễ dàng cộng tác liền mạch trên 1 nền tảng khi dễ dàng giao-nhận việc và thực thi, phê duyệt, trao đổi, báo cáo trong những buổi retro và rút gọn thời gian làm các đầu việc thủ công bằng tự động hoá.
Bạn có thể bắt đầu 30 ngày dùng thử miễn phí nền tảng vận hành doanh nghiệp Cleeksy không giới hạn tính năng. Phiên bản FREE không giới hạn thời gian.
Resource cho bạn tìm hiểu về Agile và Scrum:
Việc làm, tuyển dụng Agile: Có rất nhiều tại TopDev với mức lương cực hấp dẫn.
Scrum.org: đầy đủ kiến thức cơ bản, nâng cao về Scrum và các chứng chỉ Scrum.
Agile Manifesto: cơ bản về Agile, tuyên ngôn Agile cho người mới bắt đầu.
Bạn cần lưu ý rõ điều này Agile không phải là “một phương pháp” mà là tư duy, cách tiếp cận, là tập hợp những phương pháp, sự thực hành dựa trên những giá trị và nguyên tắc nêu ra trong bản tuyên ngôn Agile.
Bước vào Ekino nghĩa là bạn gia nhập đội ngũ làm việc với cuộc cách mạng kỹ thuật số trong các công ty khởi nghiệp cũng như các tập đoàn lớn.
Ekino đang tham gia vào các dự án cho khách hàng châu Âu và khách hàng châu Á, như AccorHotels, BNP Paribas, ACB, Arval, Carmignac, Volkswagen, Bolloré Logistics … hỗ trợ khách hàng của mình, từ các công ty lớn đến các công ty khởi nghiệp, trong việc tạo ra hoặc chuyển đổi mô hình kinh doanh của họ trong kỷ nguyên kỹ thuật số. Khách hàng lựa chọn Ekino vì sự chuyên môn sâu về kỹ thuật số và trên tất cả là sự gắn kết và chuyên nghiệp trong đội ngũ.
Ekino tin tưởng rằng sự phát triển của bạn và công ty luôn đồng hành với nhau. Do đó Ekino tạo điều kiện cho khát vọng nghề nghiệp của Technical Project Manager: Tại đây, không có con đường được định sẵn. Nguyên tắc quản lý dựa trên sự tin tưởng, tự chủ, tự do để thử nghiệm các ý tưởng của bạn, để bạn rút kinh nghiệm và cải thiện tốt hơn từ những sai lầm.
Trải nghiệm ngày hôm nay, công nghệ ngày mai – cơ hội mở rộng dành cho các Technical Project Manager (Agile, Waterfall)
Năm 2013, Ekino xây dựng đội ngũ chuyên gia kỹ thuật tại Việt Nam, cùng hợp tác với các trụ sở Ekino khác của Ekino trên toàn thế giới để cung cấp những giải pháp phù hợp nhất đến khách hàng. Năm 2015, Ekino gia nhập Tập đoàn Havas để tăng cường giải quyết những thách thức kỹ thuật số mà các thương hiệu phải đối mặt ngày nay. Đóng vai trò quan trọng trong việc thúc đẩy sự phát triển của tập đoàn Havas, cùng với những nỗ lực không ngừng, năm 2016, trụ sở Ekino tại Pháp được công nhận là một trong những nơi tuyệt vời nhất để làm việc.
Tính đến nay, Ekino đã có kinh nghiệm hơn 10 năm trong ngành, 7 văn phòng trên toàn thế giới và hơn 500 nhân tài giàu kinh nghiệm và đam mê với kỹ thuật. Hiện nay, Ekino tại Việt Nam chào đón các Technical Project Manager tham gia vào đội ngũ để có cơ hội cùng trải nghiệm:
Là cầu nối giao tiếp chính với khách hàng, chuyên gia tư vấn kỹ thuật từ Pháp để đảm bảo rằng các dự án đáp ứng yêu cầu và sự hài lòng của khách hàng;
Phối hợp với Trưởng nhóm kỹ thuật trong việc giải quyết các vấn đề kỹ thuật dự án;
Phối hợp với nhóm kiểm thử phần mềm để xác định / điều chỉnh quy trình phát triển phần mềm;
Phối hợp với nhóm quản trị hệ thống CNTT để đảm bảo các dự án vận hành trôi chảy;
Hướng dẫn, huấn luyện, đánh giá hiệu suất cho các thành viên trong dự án;
Đãi ngộ, phúc lợi “có tâm và có tầm” cùng đội ngũ đam mê trải nghiệm, định hướng tương lai dẫn đầu
Vì con người là giá trị quan trọng nhất đối với Ekino, đến với Ekino đội ngũ nhân viên sẽ có cơ hội làm việc với các công nghệ mới, các dự án đầy thách thức, huấn luyện tại chỗ và các chương trình đào tạo về ngôn ngữ, kỹ thuật và kỹ năng mềm.
Đội ngũ Ekino là những người cùng niềm đam mê công nghệ, luôn tạo điều kiện cho tất cả thành viên phát triển trong môi trường thân thiện và hướng đến sản phẩm. Chính sự đam mê này là động lực giúp Ekino luôn ở vị trí dẫn đầu, thông qua tầm nhìn năng động và chia sẻ: trải nghiệm ngày hôm nay, công nghệ của ngày mai.
Giá trị con người luôn được đề cao trong đội ngũ Ekino, thành viên tại mái nhà này luôn được trao tặng những chính sách đãi ngộ hấp dẫn, đặc biệt là mức lương cạnh tranh cao hơn so với những công ty trong nước:
Offer hấp dẫn xứng đáng năng lực bản thân;
Đánh giá năng lực hằng năm để khen thưởng, công nhận những nỗ lực phát triển;
Đảm bảo chế độ BHXH, BHYT, BHTN… đầy đủ theo quy định của công ty;
Thưởng cuối năm và thưởng theo kết quả thực hiện công việc;
Cải thiện kỹ năng liên tục với các công nghệ mới, các dự án đầy thách thức, chương trình đào tạo tại chỗ;
Cơ hội làm việc tại Pháp theo yêu cầu nhiệm vụ và dự án;
Các hoạt động gắn kết tại nơi làm việc (du lịch hằng năm, câu lạc bộ thể thao …): nâng cao tinh thần làm việc nhóm và tạo điều kiện hài hòa cuộc sống và công việc của bạn.
Đừng chần chừ nữa, bạn hãy nhanh tay ứng tuyển chiếc vé để gia nhập với chúng tôi – mái nhà “Greatest Place to Work”, nơi bạn không chỉ thăng tiến trên con đường nghề nghiệp mà còn được trao tặng những trải nghiệm dẫn đầu công nghệ, tỏa sáng tiềm năng!
Có nhiều cuộc thảo luận nào là JS không theo quy tắc, không ổn định, liên tục cập nhật khiến độ ổn định không cao. Nhưng các bản thăm dò đều cho thấy Javascript thống lĩnh, có thể nói rằng ngôn ngữ này đang là Fullstack nhất, nào là server side, client side, mobile app thậm chí là desktop app (VS Code là một ví dụ điển hình nhất). Vì vậy, ngưng lo ngại và hãy yêu quý nó!
Các bản update lớn sẽ được ra cẩn trọng hơn
ES6 quá lớn để cộng đồng ECMAScript quyết định cho ra các bản release nhẹ nhàng hơn. Đây là lí do mà ES6 cũng được gọi là ES2015, và đây là bản release đầu tiên của năm này – từ nay năm nào cũng sẽ có release. Nó dễ nắm bắt hơn, hiệu năng cao hơn và dễ sử dụng.
Có lẽ bạn follow rất nhiều người trên Facebook. Một số leader chia sẻ sắp đến sẽ có xu hướng gì, và thế là mọi người đều đổ xô dùng nó. Có thể họ thích hiển thị các snippet dùng các API mới nhất mà không giống với tiêu chuẩn.
Có lẽ họ có lí do riêng. Bạn thì không. Đừng rơi vào cái bẫy của những thứ lấp lánh, và tập trung vào công việc.
Không phải tuần nào cũng có framewok mới đâu
Có nhiều lời đồn thổi rằng “sẽ có library mới hằng tuần”. Điều đó đúng, có cả triệu người đang sử dụng JavaScript và nó rất tuyệt vời, mang đến sự cải tiến, bởi JavaScipt có cả một hệ sinh thái phong phú.
Nhưng có một thứ cần lưu ý đó là những thứ quan trọng thì không thay đổi nhiều.
React được 5 tuổi.
Vue được 4 tuổi.
4 năm là một hành trình dài trong ngành công nghệ. Chúng là các công nghệ ổn định. Học nó ngay, nó sẽ còn ở đây lâu.
Bạn vẫn còn rất nhiều thời gian để master được bất kì framework nào trên, vì chúng sẽ còn ở đây rất lâu.
Vài năm trước jQuery được dùng ở khắp nơi, giờ đây thì hiếm khi có project nào đi từ nó.
Vào năm 2013 Backbone.js rất hot. Giờ thì nó đã biến mất khỏi cuộc chơi.
CoffeeScript, dường như đã biến mất khỏi trái đất.
Ember.js, Angular.js và Meteor cũng đã xuất hiện và nổi tiếng được vài năm, giờ đây lại phải nhường ngôi cho React, Vue và Angular (hoàn toàn khác với Angular.js).
Chu kì của các framework nổi tiếng thường kéo dài khoảng vài năm. Tôi vẫn còn rất nhiều app Ember.js hoạt động còn tốt, và không cần phải update nếu chúng làm tốt việc của mình, và tôi cũng không có ý định đụng nó.
Công nghệ phát riển rồi trưởng thành, rồi nó sẽ dần quen với sự nổi tiếng và yếu dần.
Nếu bạn sử dụng jQuery, bạn không hề ngốc
Nếu bạn đọc đủ nhiều, bạn master 1 framework nào đó, bạn sẽ biến công việc trở nên dễ dàng. Những người không hiểu sâu sẽ luôn muốn chúng ta thay đổi này nọ.
Sau khi đã sử dụng PHP, tôi đã quen với việc người ta chê bai một cái gì đấy về ngôn ngữ này. Thậm chí đến Go, nổi tiếng về sự đơn giản dễ dùng của nó cũng bị người đời chê bai đến lên bờ xuống ruộng.
Để bạn dễ hình dung, tôi sẽ trích một tweet của Pieter Levels, người đã gây dựng cơ nghiệp chỉ nhờ một file PHP.
Nhưng nếu là ma mới, và bạn nghe rằng ai đó nói bạn đã chọn một tool cũ, thì bạn nên xài React thay thế.
Hãy lờ nó đi.
Chỉ cần nhớ rằng: cái gì hỗ trợ bạn tốt, thì nó là sự lựa chọn đúng đắn.
Nếu nó hỗ trợ tốt cho bạn, thì nó là của bạn.
Đa số thì công nghệ được build nên bởi các ông lớn công nghệ có nhu cầu, khác với cái của bạn, hoặc của team bạn. Hãy chọn cái bạn hiểu rõ, và tạo ra sự khác biệt kể cả khi không dùng các edge tech phổ biến.
Giờ đây có lẽ bạn không cần jQuery nữa. Nhưng dưới dạng framework – thuần JavaScript sẽ rất hợp.
Một phần khác của vấn đề đó là đừng sử dụng công nghệ nào chỉ làm bạn cảm thấy thông minh hơn. Hãy hiểu nó hơn. Và học cách khi nào thì sử dụng framwork hoặc library để hỗ trợ bạn.
Bạn không có nghĩa vụ phải biết mọi thứ. Tìm điểm cân bằng cho chính mình.
Nghe cứ như một câu quote đâu đó trên Facebook, thật sự là chẳng ai biết mọi thứ cả. Không ai có thể học hết những thứ đang có về frontend development cả. Trường học này sẽ kéo dài cả cuộc đời. Chắc chắn phải có cách hợp lý để tốt nghiệp luôn bây giờ.
Chọn loại tech có tư liệu thân thiện với user
Không phải tự nhiên mà React và Vue có nguồn tư liệu tuyệt vời.
Đó là phần chủ chốt trong sự thành công của họ.
JavaScript sẽ tiến hóa lần nữa
Năm ngoái ECMAScript đã ra mắt await/async và từ đó là feature được sử dụng rất phổ biến. Code dựa trên promise trông hơi tệ, như thể bạn phải viết lại từ đầu đến đuôi.
Đừng làm thế, thay vì thế hãy sử dụng các feature mới trong code bạn viết.
Điều tương tự sẽ xảy ra trong năm nay, bằng ES2018. Mọi người sẽ nói về nó một hồi, và rồi sẽ quay lại làm việc rồi sẽ đến ES2019.
Hãy trân trọng sự thay đổi. Nó tốt hơn nhiều so với việc đặt cược vào nó rồi sa vào những cái không liên quan: JavaScript is here to stay!
Học từ những cái căn bản và tự quyết định lối riêng
Develop trên Web Platform đòi hỏi nhiều sự tìm tòi học hỏi cái mới, kể cả việc tìm xem nó có khả thi không.
Đôi khi chỉ cần học 20% thời gian của 80% những thứ bạn cần là đủ, không cần phải đào quá sâu vào những edge case.
Cuộc hành trình bắt đầu
JavaScript vẫn còn khá trẻ so với những ngôn ngữ khác, những đã rất phổ biến và đã có thể thay đổi ngọan mục trong những năm vừa qua. Hằng ngày nó đã thu nạp về rất nhiều developer tài năng, và chỉ cần tưởng tượng về nó trong vòng 20 năm tới thôi cũng thấy thú vị. Con đường nghề nghiệp của các lập trình viên Javascript thì khỏi phải bàn tới, các công ty công nghệ lớn luôn có vị trí việc làm JS lương cao ngất ngưỡng.
Thực ra thì, việc xác định ngày bắt đầu chính xác cho Mobile Gaming là điều không dễ dàng. Tuy nhiên nếu chúng ta xem nó như một ngành công nghiệp có điểm bắt đầu và kết thúc, thì đó có lẽ là năm 1997 – năm mà Snake trở thành Mobile Gaming chính thống đầu tiên trên xuất hiện trên điện thoại.
Trong thời kỳ bắt đầu, mọi người đều nghĩ điện thoại di động chỉ dùng cho việc liên lạc và kết nối, và nó việc giải trí với các trò chơi trên nó chỉ là thứ yếu sau hầu hết các PC và máy chơi game. Nhưng trong hai mươi năm qua, trò chơi di động đã chuyển từ các pixel nhấp nháy của Snake sang toàn bộ thế giới ảo được kết nối cùng lúc bởi hàng ngàn người trên toàn cầu, biến các công ty game di động thành doanh nghiệp tỷ đô trong quá trình này. Và bây giờ, chúng ta có thể nói rằng tương lai của Mobile Gaming chính là tương lai của các Trò chơi. Bây giờ, rõ ràng rằng tương lai của trò chơi di động là tương lai của trò chơi.
Vậy nên, nếu chúng ta đã có những thay đổi rất đáng kể trong 2 thập kỷ qua, vậy thì tương lai của Mobile Gaming sẽ ra sao trong 5 năm nữa? Và điều đó sẽ được trả lời thông qua loạt series mới “Future of Mobile Gaming”. Thông qua loạt bài viết này, chúng ta sẽ có cái nhìn tổng quan về từng khía cạnh cụ thể của tương lai Mobile Gaming, từ thay đổi phần cứng và triển khai 5G cho đến vai trò ngày càng tăng của công nghệ mới nổi như AI và VR. Cuối cùng là một bức tranh về tương lai mà các nhà phát triển, nhà xuất bản và những người đam mê chơi game có thể sử dụng để dự báo kế hoạch của riêng họ.
Vì vậy, nếu chúng ta đạt được điều đó trong hai thập kỷ, thì tương lai đó có gì cho trò chơi di động trong 5 năm nữa? Đó là câu hỏi mà chúng tôi sẽ trả lời trong loạt bài mới của chúng tôi, Tương lai của trò chơi di động.
Như đã đề cập ở trên, chúng ta sẽ bắt đầu câu chuyện của mình vào năm 1997, khi Snake trở thành trò chơi di động thực sự đầu tiên sau khi đưa vào điện thoại Nokia 6110. Từ đó, cơ sở hạ tầng để chơi game trên thiết bị di động đã được triển khai với việc thiết lập Giao thức Internet không dây (WiFi) trước khi ngành công nghiệp tiến một bước nhảy vọt với việc ra mắt App Store iOS vào năm 2007, theo sát là Android Market của Google ( hiện được gọi là Google Play Store).
Đến năm 2012, điện thoại thông minh ở Mỹ đã vượt qua mức chuẩn phổ biến 50% và các báo cáo dữ liệu đáng tin cậy đầu tiên về hoạt động của App Store được ghi lại. Và điều này đã thể hiện rằng ngay từ đầu, rõ ràng các nhà phát hình và xuất bản trò chơi sẽ đóng vai trò quan trọng, cùng với người chơi sẽ giúp cho Mobile Gaming phát triển trọng Vũ trụ Gaming.
Chơi game trên thiết bị di động đã dần trở thành xu hướng, nhưng mãi đến năm 2016, doanh thu trò chơi trên thiết bị di động đã vượt qua máy chơi game và PC, đưa ngành công nghiệp từ giai đoạn trứng nước đến khi trưởng thành chỉ sau 20 năm:
Đó là một chặng đường dài nhưng đầy những tín hiệu tích cực và hiệu quả, điều đó đã tạo nên 1 nền tảng vững chắc cho Mobile Gaming sẵn sàng với những bước đột phá mới.
Hiện tại của Mobile Gaming: 2017 – 2019
Mặc dù nhiều người vẫn còn nghi ngờ vị trí của Mobile Gaming trong Gaming Universe nhưng
điều đó dần đã bị loại bỏ vào năm 2017. Đáng chú ý nhất là sự nổi lên của các game Battle Royale như Fortnite và PUBG Mobile đã chứng minh rằng công nghệ cuối cùng đã phát triển đến mức trải nghiệm chơi game trên thiết bị di động giữa console / PC và di động đã gần như là một, và phần thưởng dành cho các nhà phát triển là hấp dẫn. Tính đến mùa hè năm 2018, một mình Fortnite đã thu về hơn 100 triệu đô la mỗi tháng và đó chỉ là doanh thu trực tiếp cho nhà xuất bản.
Nhưng dù các trò chơi sinh tồn tiếp tục thu được sự quan tâm, thì đó cũng chỉ là một phần trong một bức tranh của Mobile Gaming. Năm vừa qua đã chứng kiến những tựa game bom tấn mới như Harry Potter: Wizards Unite và Jurassic World Alive, báo hiệu ngành công nghiệp đã hồi sinh và đầu tư vào công nghệ mới như AR với đại diện tiêu biểu là Pokemon Go.
Đồng thời, các trò chơi hyper-casual như Love Balls và Helix Jump đã trở thành những hiện tượng theo cách riêng của họ bằng cách cung cấp trải nghiệm dễ dàng truy cập nhưng rất hấp dẫn cho người chơi trên toàn thế giới.
Chơi game trên thiết bị di động đã trở nên mạnh mẽ hơn trong giai đoạn này. Các trò chơi đã có 1 bước tiến dài vào nền văn hóa nhân loại, và tất cả dấu hiệu cho thấy ngành công nghiệp này chỉ mới bắt đầu.
Và tương lai của Mobile Gaming: 2019 – …
Đã đến lúc chúng ta hướng sự chú ý về tương lai. Đối với loạt bài này, chúng ta sẽ nói về tương lai gần, như trong năm năm tới. Với tốc độ tiến bộ đáng kinh ngạc của công nghệ, mọi dự đoán ngoài khung thời gian đó có thể không khả thi hoặc xảy ra quá nhanh.
Như đã nói, sự phát triển của khoa học dữ liệu đã giúp dự báo một cách chính xác và khả thi hơn bao giờ hết. Kết hợp điều này với chuyên môn trong ngành và kiến thức về các xu hướng chính sắp tới như triển khai 5G, một bức tranh tương lai càng rõ ràng hơn bao giờ hết. Chúng ta sẽ thấy việc chơi game tiếp tục phát huy những tiến bộ về phần cứng và mạng, cùng với những tiến bộ khác như AI, sẽ mang lại trải nghiệm cá nhân hóa cao, đưa game di động vào mọi khoảnh khắc của cuộc sống.
Nhìn chung, sự tăng trưởng ở các thị trường đã phát triển và mới nổi sẽ giúp thúc đẩy chơi game trên thiết bị di động lên tầm cao hơn nữa khi các trò chơi được dự đoán là hạng mục cao nhất cho chi tiêu của người tiêu dùng vào năm 2023. Và sau đây là một số dự đoán:
Chi tiêu tiêu dùng toàn cầu hàng năm trong các trò chơi di động lên tới 100 tỷ đô la vào năm 2021.
Tổng số thiết bị di động để chơi game lên tới 6 tỷ vào năm 2022.
APAC sẽ chiếm phần lớn tổng doanh thu trò chơi toàn cầu vào năm 2023.
Từ một trò chơi đình đám đầu tiên vào thập niên 90 đến một tương lai – nơi doanh thu trò chơi trên thiết bị di động đã vượt qua đáng kể PC và máy chơi game, đây chính là cốt lõi của ngành công nghiệp trò chơi. Và đó còn là một bước chuyển mình nhanh chóng giữa quá khứ, hiện tại và tương lai của Mobile Gaming.
Topdev Blog via applovin.com
Tháng 6 này các chuyên gia, chủ nhân của nhiều ứng dụng nổi tiếng sẵn sàng hội tụ tại Vietnam Mobile Day 2019 và truyền đạt hàng trăm bí kíp làm app tại chuỗi sự kiện thường niên được giới devs công nhận và phát triển mạnh mẽ trong 9 năm qua, đừng bỏ lỡ những giá trị hữu ích mà VMD2019 do TopDev tổ chức năm nay nhé!
Bắt đầu với những kĩ năng quan trọng nhất của thế kỉ 21.
Chúng ta ngày càng bận rộn. Có rất nhiều thứ sẽ xảy ra với cuộc sống cá nhân cũng như nghề nghiệp nhưng trên hết, vài thứ như trí thông minh nhân tạo bắt đầu thời kì phát triển và bạn sẽ nhận ra rằng các kĩ năng của bạn sẽ hết hạn trong ít nhất 2 năm tới.
“Các kiến thức và kĩ năng của một full-stack developer sẽ không bao giờ đủ khi ngữ cảnh mọi thứ thay đổi. Trong 2 năm tới đây, full-stack cũng không được gọi là full-stack nếu không có kĩ năng AI.”
Đã đến lúc phải hành động tôi tự nghĩ đến việc tự nghiên cứu AI từ đâu. Và tôi đã làm những gì tôi cho là đúng đắn – cập nhật các kĩ năng của tôi như là 1 lập trình viên, mindset của tôi như 1 người làm product và triết lí của tôi như một doanh nhân để trở thành người theo định hướng data.
Như Spiros Margaris – nhà đầu tư mạo hiểm nổi tiếng và lãnh đạo tư tưởng trong AI và Fintech đã nói với tôi “Nếu các công ty và startups chỉ dựa vào thuật toán AI và Machine Learning tiên tiến thì sẽ không bao giờ là đủ. AI không phải là một lợi thế cạnh tranh nhưng nó chắc chắn là một điều bắt buộc. Bạn đã bao giờ nghe ai đó nói rằng họ sử dụng điện lại là lợi thế cạnh tranh chưa?
Xây dựng neural network
Lời khuyên phổ biến là hãy đăng kí khóa học của Andrew Ng trên Coursera. Đây là một nơi tuyệt vời để bắt đầu nhưng tôi lại nhận thấy rất khó khăn để tỉnh táo trong thời gian dài. Tôi không nói đây là 1 khóa học tồi tệ, nhưng tôi rất tệ khi phải tập trung vào giảng viên. Cách tôi học luôn thông qua thực tiễn, vậy nên tôi nghĩ việc tự nghiên cứu AI từ đâu? tại sao không thực hiện ngay mạng lưới thần kinh của riêng mình.
Tôi không nhảy thẳng tới mạng lưới neutral bởi vì luôn có vài cách khác tốt hơn để học. Tôi đã cố làm quen bản thân với tất cả các từ trong miền để tôi có thể học nói các ngôn ngữ.
“Bài tập đầu tiên không phải là học mà là làm quen”
Với background về Javascript và NodeJS, tôi không muốn thay đổi chuyên môn của mình. Vì vậy, tôi đã tìm kiếm một module mạng lưới thần kinh tên ngôn ngữ và sử dụng nó để thực hiện một cổng AND với một input giả. Lấy cảm hứng từ hướng dẫn này, tôi chọn vấn đề là cho bất kì input X,Y và Z nào thì output cũng nên là X và Y.
var nn = require('nn')
var opts = {
layers: [ 4 ],
iterations: 300000,
errorThresh: 0.0000005,
activation: 'logistic',
learningRate: 0.4,
momentum: 0.5,
log: 100
}
var net = nn(opts)
net.train([
{ input: [ 0,0,1 ], output: [ 0 ] },
{ input: [ 0,1,1 ], output: [ 0 ] },
{ input: [ 1,0,1 ], output: [ 0 ] },
{ input: [ 0,1,0 ], output: [ 0 ] },
{ input: [ 1,0,0 ], output: [ 0 ] },
{ input: [ 1,1,1 ], output: [ 1 ] },
{ input: [ 0,0,0 ], output: [ 0 ] }
])
// send it a new input to see its trained output
var output = net.send([ 1,1,0])
console.log(output); //0.9971279763719718
Theo ý kiến của cá nhân tôi, đây là một trong những bước xây dựng thành công nhất mà tôi đã làm. Khi output đạt đến 0.9971, tôi nhận ra rằng network đã học cách để làm một hệ thống AND và phớt lờ các input bổ sung của mình.
Đây là lí do chính của Machine Learning. Bạn đưa máy tính một set data và nó điều chỉnh các thông số nội bộ để đạt được khả năng trả lời câu hỏi trên dữ liệu mới trong khi lỗi được giảm đi từ cách máy tính quan sát từ dữ liệu gốc
Sau này tôi mới biết phương pháp này được gọi là Gradient descent.
Chuẩn bị kĩ càng cho trí tuệ nhân tạo
Một khi đã tràn đầy tự tin sau khi làm xong chương trình trí tuệ nhân tạo đầu tiên, tôi muốn biết mình có thể làm gì hơn với machine learning với tư cách là một developer.
Sử dụng data một cách hạn chế để dự đoán đội nào sẽ tháng một IPL match cho trước sử dụng multivariate linear regression. (Các dự đoán không tốt lắm nhưng nó cũng rất tuyệt)
Sau đó thực hiện rất nhiều demo trên Google Machine Learning cloud để xem AI có thể làm những gì (nó tốt đủ để Google thực hiện như một sản phẩm của SaaS)
Tôi còn tình cờ biết được AI Playbooks, một resource khá tốt bởi Andreessen-Horowits, quỹ đầu tư mạo hiểm. Thật sự là một những resources tiện dụng nhất cho developers và doanh nhân
Tôi có đọc được post này của Hackernoon về cách các showrunners tại Silicon Valley built Not HotDog app. Đây là một trong những ví dụ dễ tiếp cận nhất của deep learning mà chúng ta có thể làm.
Cộng thêm blog của Andrej Karpathy – Giám đốc AI của Tesla. Mặc dù tôi không hiểu nhiều và cảm thấy nhức đầu, tôi nhận thấy là sau khi cố gắng tìm hiểu nhiều lần nữa tôi cuối cũng cũng có thể hiểu được một vài khái niệm
Với một vài lời động viên, tôi bắt đầu thực hiện một vài hướng dẫn nguyên văn của deep learning (Copy & Paste) và cố gắng train model và run code trên machine của tôi. Đa số đều thất bại bởi vì đa số các model đều tốn thời gian training cao và tôi không có một cái GPU
Toàn bộ quy trình này được tập trung xung quanh việc tiêu thụ thụ động content và xây dựng tài liệu tham khảo trong tâm trí của bạn để lúc sau tôi có thể sử dụng khi khách hàng thực sự của tôi gặp vấn đề.
Là một fan cứng của bộ phim Her, tôi muốn build chatbots. Tôi đã chấp nhận thử thách và xoay sở để build một con sử dụng Tensorflow trong ít hơn 2 tiếng. Tôi đã vạch ra kế hoạch chuyến đi này ở một trong các bài viết của tôi nhiều ngày trước.
May mắn là bài viết này được viral rất tốt và được đề cử tại TechinAsia,CodeMentor và KDNuggets. Cá nhân tôi cảm thấy rất vinh hạnh về điều đó vì tôi chỉ mới bắt đầu viết Tech Blog thôi. Nhưng tôi nghĩ bài biết đó là một trong những đánh dấu trong sự nghiệp học hỏi về AI của tôi.
Tôi đã kết bạn được với rất nhiều người trên Twitter và Linkedin với những người mà tôi có thể hỏi cách tự nghiên cứu AI từ đâu, bàn luận về AI sâu và rộng và thậm chí có thể thoát khỏi những thứ tôi đã từng bị rối. Tôi đã nhận được một vài lời đề nghị để thực hiện ác dự án tư vấn và phần tuyệt vời nhất là các bạn lập trình viên trẻ và người mới bắt đầu AI đã bắt đầu hỏi tôi về cách tôi bắt đầu AI như thế nào.
Điều mang tôi tới việc viết bài này là để giúp mọi người tham khảo kinh nghiệm của tôi và bắt đầu nhưng dự án của chính họ.
“Bắt đầu là một trong những phần thách thức nhất của bất kì hành trình nào”
Salt & Pepper
Điều này thực sự không dễ dàng khi bắt đầu hiện thức hóa câu hỏi tự nghiên cứu AI từ đâu? Khi tôi bắt đầu cảm thấy bế tắc với Javascript, tôi nhảy sang Python và mất cả đêm để tìm cách code. Tôi bắt đầu hơi kích thích khi các mẫu của tôi không train được trên máy i7 hoặc sau nhiều giờ trainning, chúng sẽ trả về các kết quả mập mờ như khả năng thắng 50-50 của 1 trận Cricket. Học về AI không giống như học về một web framework.
Đó là một kĩ năng mà yêu cầu nhận thức về mọi thứ ở mức độ tính toán cực nhỏ và tìm kiếm ra cái gì quan trọng hơn với output của bạn – code hay data của bạn.
AI cũng không phải chỉ là một môn học. Nó là một cụm từ sử dụng cho mọi thứ từ vấn đề hồi qui đơn giản đến robot sát nhân sẽ giết chúng ta một ngày nào đó. Giống như mọi quy luật chúng ta phải tuân theo, có thể bạn sẽ muốn cherry-pick những vấn đề của AI mà bạn muốn giỏi như Computer Vision, hay Natural Language Processing hay God Forbid, thống trị thế giới.
Trong một cuộc trò truyện với Gaurav Sharma từ Atlantis Capital, một người leader có danh tiếng trong lĩnh vực AI, Fintech và Crypto, anh ấy tâm sự với tôi rằng:
Trong thời kì của trí tuệ nhân tạo, “trở nên thông minh” sẽ mang một ý nghĩa hoàn toàn khác. Chúng ta cần con người thể hiện một tư duy cao cấp hơn, sáng tạo và suy nghĩ và các công việc yêu cầu sự ràng buộc về cảm xúc cao.
Việc các máy tính nhanh chóng học cách làm việc bằng chính bản thân nó sẽ làm bạn phấn khích vô cùng. Kiên nhẫn và luôn tự chất vấn bản thân là 2 nguyên lí quan trọng mà bạn nên nhớ.
Đây là một hành trình rất rất dài hơi, rất mệt mỏi, kiệt sức và tốn thời gian ngoài ý muốn.
Nhưng phần tốt là, như mọi hành trình trên thế giới, hành trình này cũng bắt đầu từng bước một.
Nếu như một ngày, bạn thức dậy và quyết tâm trở thành một nhà văn giỏi, bạn chắc hẳn đã nghe tới 2 lời khuyên: viết thật nhiều vào và đọc nhiều hơn cả viết nữa.
Trong lập trình, nhiều người viết code nhưng hiếm có người dành thời gian đọc code, đặc biệt là những dòng code ngoài phần công việc của họ. Đó thật sự là một sai lầm lớn. Khi còn chưa muộn, hãy hành động giống như một coder đầy tham vọng và đọc thật nhiều code vào.
Đọc nhiều và đọc thường xuyên là điều khác biệt giữa một software engineer bình thường và một software engineer giỏi.
Tại sao tôi phải đọc code?
Những nhà văn vĩ đại đều học từ những nhà văn mà họ đã từng đọc. Ví dụ như Joan Didion, người đã viết những câu trong Hemingway ở tuổi 16 để học cách viết câu. Hay như Abraham Lincoln, người đã làm thơ trữ tình dựa trên cuốn kinh thánh King James mà ông yêu thích.
Tương tự như thế, nhìn nhiều code thực tế sẽ mở mang kiến thức của bạn để có thể tự viết code. Đọc code của người khác sẽ thấy được chức năng của các ngôn ngữ lập trình mới và nhiều thể loại code khác nhau.
Đọc dependencies của bạn sẽ giúp bạn làm việc năng suất hơn. Bạn sẽ biết được đầy đủ chức năng mà dependencies của bạn cung cấp. Bạn sẽ biết chính xác cách chúng hoạt động và chúng đang tradeoff cái gì. Bạn sẽ biết nơi để debug khi có lỗi xảy ra.
Đọc code một cách thoải mái cũng hạn chế bớt sự “ảo tưởng” đối với code của chính bạn. Bạn đọc càng nhiều, bạn càng cảm thấy code của người khác thú vị, thì bạn càng muốn làm code của bạn tốt hơn. Sự thay đổi này sẽ làm giảm khả năng bạn bị mắc hội chứng “not invented here”.
Chú thích: “Hội Chứng Not InventedHere” là khuynh hướng của một nhóm chủ thể quá tin tưởng vào những kiến thức độc đoán trong lĩnh vực của mình, từ đó chối bỏ những ý tưởng mới từ cá thể bên ngoài, đến mức tổn hại cả năng lực hoạt động của chính bản thân nó.
Nếu bạn là một người lập trình web, một data engineer hay một nhà mật mã học, trau dồi việc đọc thường xuyên sẽ dạy bạn các công cụ và sản phẩm khác với những công việc thường ngày của mình.
Đối với một web front-end, đọc một phần nhỏ codebase của raytracer sẽ đưa bạn đến một loạt các ràng buộc khác nhau. Đối với một database engineer, đọc code web trừu tượng cao có thể cho bạn biết người dùng của mình đang nghĩ gì. Còn đối với tất cả các kỹ sư phần mềm, bạn sẽ tìm được giá trị trong việc đọc ngôn ngữ lập trình khác với ngôn ngữ mà bạn đang dùng.
Như Donald Knuth nhấn mạnh: “đọc code thực sự đáng giá vì những thứ nó đem lại. Bạn đọc càng nhiều code từ người khác, bạn càng có khả năng phát minh ra nhiều thứ trong tương lai…”
Dưới đây là cách đọc code “không đau đớn” và năng suất nhất có thể dành cho bạn.
Hướng dẫn đọc code
Tiếp cận một nguồn code như cách mà bạn đọc một cuốn sách – Đọc từ đầu đến cuối – và nó thường không thành công (trớ trêu thay đây lại là cách duy nhất máy tính tự đọc code)
Đọc từ đầu nghĩa là bỏ qua context quan trọng và không có ý nghĩa đối với cấu trúc sau này. Đọc thụ động – bạn sẽ không thể kiểm tra hoặc sửa lỗi – sẽ cản trở bạn thực sự đi sâu vào các dòng code.
Không giống một cuốn sách, hầu hết những người bạn của mình đấu tranh để đọc code mà không có mục tiêu cụ thể. Trước khi đọc một codebase mới, hãy chắc chắn rằng bạn có mục tiêu muốn đạt được. Điều này sẽ làm cho codebase trở nên dễ quản lý hơn và tạo động lực để vượt qua khi bạn thấy nó khó quá.
Mình sử dụng phương pháp RSDW để đọc bất cứ codebase khó hiểu nào:
Run: dịch, chạy thử và hiểu code đang làm gì
Kiểm tra Structure: học cấu trúc level cao và xem các bài test tích hợp quan trọng.
Dive in: theo các luồng chính và đọc các cấu trúc dữ liệu quan trọng.
Write tests: Viết thử và ưu tiên các tính năng đơn giản và sửa lỗi.
Phương pháp RSDW chỉ là khởi động, nhưng về sau, bạn nên tự tìm cách riêng cho mình. Một vài người thề chỉ viết test và sửa lỗi, trong khi người khác luôn thích bắt đầu bằng việc xem các test tích hợp trước.
Thôi thì quay lại với phương pháp RSDW của mình nhé.
Run
Bước đầu trong việc đọc code không hẳn là đọc cho lắm. Chúng ta cần phải sử dụng phần mềm.
Đọc code chỉ khi bạn hiểu chức năng phần mềm cung cấp. Trong giai đoạn này, bạn nên nhìn tổng quan code và hiểu input và output có gì.
Sử dụng phần mềm bắt bạn phải làm nó chạy. Điều đó cũng có nghĩa là theo dõi các dependencies và, đối với một vài ngôn ngữ nhất định là phải dịch code. Đối với các thư viện, nó có nghĩa là gọi một vài chức năng phổ biến. Đây là thời điểm chạy thử nghiệm và xem các thông báo đầu ra.
Nếu bạn gặp vấn đề khi hệ thống chạy lần đầu, đó là thời điểm tốt nhất để ghi lại cho người khác cần những gì để chạy phần mềm.
Tiếp đến là xác định các phần quan trọng nhất của code. Quá trình này khác xa so với việc đọc sách. Thay vì bắt đầu lúc bắt đầu, bạn phải đi xung quanh để tìm các mối quan hệ chính trong code.
Bắt đầu với việc hiểu cấu trúc của code. Tối thiểu có thể chạy một vài tool tự động (như tree và cloc) để tìm ra ngôn ngữ và file của codebase.
Để xác định các file chính, nhìn vào các file nhiều sửa đổi nhất và sử dụng bất kỳ tool nâng cao nào khác cũng được. Xem lại các bài test tích hợp quan trọng, liệt kê các chức năng có thể gọi tên. Đánh dấu các bài test này để sau.
Có 1 cách dễ dàng để rút ngắn quá trình này: Tìm một ai đó đã từng làm việc với loại code này trước đây.
Hiểu cấu trúc là nhiệm vụ đầu tiên cho việc đọc code.
Deep Dives
Khi bạn đã có đất rồi, thì đào thôi.
Khi đọc code, bạn nên nhìn vào code flow (Nhìn các action đang được tạo ra) và cấu trúc dữ liệu / các đối tượng (nơi mà kết quả chạy được lưu trữ)
Chọn từ 3-5 dòng quan trọng bạn thấy từ bài test tích hợp chính, PRs quan trọng hoặc lúc bạn xem lại tệp nguồn. Sau đó đào sâu hơn. Bắt đầu từ đỉnh của một action đặc biệt và cứ đi theo các dòng code. Một vài lập trình viên thích dùng các trình gỡ lỗi. Những người khác thì thích tạo sơ đồ UML hay đồ thị flame hơn.
Lần khác mình sẽ dừng tại điểm smack dab ở giữa một chức năng quan trọng, và tìm cách đi đến stack để hiểu cách làm sao mình đến được đó. Nếu bạn quyết định làm theo code một cách thủ công, nhớ thiết lập sẵn trình soạn thảo của bạn cho phép bạn sử dụng “go to definition” và “find all references” một cách nhanh chóng.
Đối với cấu trúc dữ liệu, xem lại loại dữ liệu và khi nào các biến chính được bật. Sử dụng trình gỡ lỗi để truy vấn những cấu trúc dữ liệu này vào những thời điểm quan trọng.
Ngoài các bài test tích hợp, cách tốt để tiếp cận một codebase mới chính là review lại các pull request quan trọng. PRs thường dễ hiểu hơn, vì chúng gói gọn trong một tính năng tách biệt. PRs cũng cung cấp nền tảng narrative ngoài lý do và cách bổ sung code.
Trong quá trình đào sâu này, mình mở 2 doc markdown. Doc đầu là “level up my coding” nơi mình liệt kê các cú pháp mới mà mình thấy và các mẫu code mình thích khi tự học (người khác gọi nó là bảng kê). Cái doc thứ 2 để liệt kê các câu hỏi quan trọng mình dành cho những lập trình viên của codebase mình đang đọc. Ở giai đoạn này, mình cũng thêm vào documentation khi tôi thấy gaps.
Quá trình deep dives này thường sẽ hiệu quả hơn nếu bạn thực hiện cùng với một người nào đó biết về code. Nếu mình chỉ có ít thời gian với một lập trình viên trên project, mình luôn để họ theo dõi mình qua các flow chính. Khi mình đã hiểu căn bản một ít dòng chính, sẽ dễ dàng hơn khi mình tự đào.
Không giống trong văn chương, nơi đọc và viết là 2 cái tách biệt, một phần quan trọng của đọc code chính là viết code. Nếu không viết code, bạn không thể hiểu được một codebase. 2 cách tiếp cận dễ dàng để bắt đầu là viết test và giải quyết các feature/bug.
Viết test thử là một hình thức đọc tích cực, bắt bạn phải chú ý đến input và output của một tương tác cụ thể. Viết code giúp hằn sâu code trong đầu bạn – cái mà việc đọc không thôi thì không thể làm được.
Đối với mình, test từng phần là cách dễ dàng để bắt đầu. Khi mình thành thạo một số base, mình có thể chuyển sang test tích hợp để hiểu hơn về codebase. Thỉnh thoảng mình sẽ viết lại một test tích hợp đã có, để thử xem mình có hiểu cách một call quan trọng hoạt động hay không.
Một cách tiếp cận khác dễ dàng hơn đó là viết tính năng đơn giản hoặc address những lỗi dễ. Cả 2 cách này không yêu cầu bạn phải có kiến thức đầy đủ về codebase, nhưng vẫn bắt bạn phải “đối đầu” với code. Đóng góp cách sửa bug và tài liệu liên quan cũng là một cách dễ dàng để trả lại dependencies.
Những phương pháp này giúp bạn nhanh chóng hoàn thành khi bận đang cần. Bằng cách áp dụng RSDW nhiều hơn với một vài bài học mở rộng, việc đọc code sẽ đỡ khó khăn hơn nhiều.
Một vài tips đọc
Phương pháp RSDW không phải là duy nhất. Các engineer có thể tìm ra cách riêng mà họ thích để đào sâu vào một codebase mới (Quá trình đọc cũng thay đổi đáng kể tuỳ theo ngôn ngữ, các tool có sẵn và loại codebase bạn đang muốn)
Mặc dù vậy, phương pháp RSDW cũng là cách tiếp cận tốt khi bạn thấy code mới. Nó cũng kích thích sự thú vị khi đọc code, có thể là viết test hoặc chủ động sử dụng một trình gỡ lỗi để truy vấn cấu trúc dữ liệu. Quá trình đọc code khác xa so với quá trình đọc một cuốn sách.
Bạn cũng sẽ tìm đọc code mới một cách hứng thú. Bạn lưu lại các dòng code và cố gắng giữ đồng thời hàng chục cấu trúc dữ liệu và chức năng mới trong đầu. Đừng ngại nghỉ giải lao 1 tí khi bạn gặp một codebase mới. Khi mình bắt đầu với 1 codebase mới, một vài giờ rảnh trong ngày để đọc là tất cả những gì mình cần để năng suất hơn.
Mặc dù nó rất quan trọng để phát triển các kỹ năng đọc tốt, nhưng cũng quan trọng không kém khi suy nghĩ về những gì bạn đã đọc.
Bạn nên đọc code gì?
Khi bắt đầu sự nghiệp, mình tin rằng 60% thời gian của bạn nên dành cho việc đọc code. Có thể 1/3 trong số đó là code khác với codebase bạn sẽ build. Chắc hẳn là phải tốn rất nhiều thời gian, vậy chúng ta nên đọc gì?
Cách dễ nhất để bắt đầu đọc, và với ROI cao nhất, là học các dependency của bạn. Nội bộ hoá cách dependency của bạn làm việc để bạn dễ debug hơn trên toàn bộ hệ thống.
Một cách khác giúp mang lại năng suất cao khác là chọn một hệ thống quan trọng ở công ty của bạn mà bạn giao tiếp, và thử đọc qua nó. Điều này không chỉ đem lại giá trị cho công việc của bạn, mà các codebase chuyên nghiệp thì khác với codebase nguồn mở.
Ngoài các hệ thống mà bạn tương tác trực tiếp, hãy luôn sẵn sàng để đọc nhiều hơn nữa. Những ngày đầu trong sự nghiệp của mình, mình khuyên các bạn nên dành 1 giờ đồng hồ mỗi sáng hoặc mỗi tối để đọc code ngoài công việc hằng ngày của bạn. Nghe khá đau đớn vì sau một ngày làm việc mệt mỏi rồi, nhưng hãy cố gắng lượm nhặt codebase bạn thích và đào sâu vào nó trong 1 tuần thử nhé.
Ví dụ, Redis là nguồn nổi tiếng để bắt đầu học C. Để dễ đọc hơn và đọc được nhiều codebase phức tạp hơn, cách đơn giản là bắt đầu đọc từ subsystem cụ thể.
Các dự án phụ cũng là một cách tốt để đọc code, vì chúng buộc bạn phải học một thế giới khác. Bạn sẽ cần đọc nhiều dependency mới và khám phá những codebase khác nhau để biết mình đang build cái gì. Mặc dù không có vẻ là đọc cho lắm, nhưng đó là dự án mà có thể bắt bạn chủ động đọc những thứ bạn sẽ dùng.
Ngoài công việc, bạn nên đọc nhiều tools khác với những gì bạn đang làm. Nếu bạn đã quen với abstraction level cao, hãy học 1 (hoặc 3) abstraction level thấp hơn. Nếu bạn đang làm việc với 1 ngôn ngữ, chọn một ngôn ngữ khác để đọc vào lúc rảnh.Nếu bạn luôn nghĩ về 1 constraint (vd: thời gian để làm mới màn hình tiếp theo trong graphics programming), tìm một constraint khác (vd: tiết kiệm tuổi thọ pin cho lập trình mobile).
Một cách tiếp cận tốt khác để đọc code đó là đọc và viết lại từ những coder và bạn yêu thích. Trường hợp của Didion hồi trẻ đã viết nên Hemingway hoặc Hunter Thompson viết Great Gatsby, hoặc code của antirez/ gaearon/ mrdoob bắt đầu với 1 thư viện đơn giản. Đọc code khác của họ. Luôn cập nhật công việc gần đây nhất của họ.
Stephen King nói với các nhà văn rằng: “Nếu bạn không dành thời gian để đọc, bạn sẽ không có thời gian (hoặc công cụ) để viết, đơn giản vậy thôi”. Cũng tương tự thế đối với các kỹ sư phần mềm, viết code sạch có lẽ là điều vui nhất, nhưng chủ động đọc code mới là điều khiến bạn bứt phá ra khỏi vỏ bọc trước giờ.
Dù cho bạn ở bất cứ cấp độ nào thì bạn vẫn có thể làm trở thành lập trình viên game. 2 năm trước, tôi nghĩ rằng điều đó là không thể, nhưng vẫn thử làm (cho biết). Đó cũng là điều khó khăn nhất mà tôi từng làm nhưng kết quả nhận được thì vô cùng xứng đáng. Giờ đây, tôi nhận ra việc làm game giống như bất kỳ kỹ năng nào – bạn chỉ trở nên tốt hơn bằng cách làm thử => thất bại => cải thiện
Lập trình game (game development) là quá trình tạo ra một sản phẩm trò chơi hoàn chỉnh, bao gồm các giai đoạn cơ bản như hình thành ý tưởng, thiết kế, xây dựng, kiểm thử và phát hành sản phẩm cuối cùng. Trong quá trình tạo ra một trò chơi, điều quan trọng là phải xem xét các yếu tố như cơ chế chơi game, hệ thống phần thưởng, sự tương tác của người chơi và thiết kế các cấp độ trong trò chơi. Những yếu tố này kết hợp với nhau để tạo nên trải nghiệm thú vị và hấp dẫn cho người chơi.
Lập trình game thường sử dụng các ngôn ngữ lập trình như C++, C#, Python, và JavaScript, cùng với các công cụ phát triển game như Unity, Unreal Engine, Godot, và GameMaker Studio. Các công cụ này cung cấp các framework và thư viện để giúp lập trình viên dễ dàng tạo ra các yếu tố trong game mà không cần phải xây dựng từ đầu.
Mỗi người sẽ có một cách riêng. Một số có thể soạn tài liệu lên đến 60 trang. Những người khác, giống như tôi, chỉ viết một trang ghi chú khá cẩu thả, chỉ có thể một mình hiểu. Thành thật thì tôi không biết điều gì tốt nhất cho bạn nhưng tôi có thể đưa ra gợi ý về những gì cần viết:
Hook – mồi câu: Điều gì làm cho ý tưởng trò chơi của bạn tuyệt vời? Đối với tôi, đây là điều quan trọng nhất để viết ra. Một khi bạn nắm bắt được điều này, bạn có thể viết xuống ba điểm tiếp theo dễ dàng hơn nhiều. Trò chơi của bạn có phải là thứ kích thích tư duy không? Hay gây tranh cãi? Là nó có một kết cục bất ngờ? Hoặc, nó đang làm điều gì đó chưa bao giờ được thực hiện trước đây?
Mechanic – Cách chơi: Người chơi của bạn cần phải làm gì? Và vì mục đích gì? Đây chính là phần gameplay của bạn. Nó có thể đơn giản như cách nhấn QWOP để di chuyển trong trò chơi QWOP, hay bấm các nút để trò chuyện trong Mystic Messenger, tới hàng tấn combo wombo nút bấm trong Dwarf Fortress.
Story – Cốt chuyện: Người chơi nên nhớ về cốt chuyện của trò chơi như thế nào? Những cảm xúc nào họ nên có khi hoàn thành trò chơi của bạn? Mỗi trò chơi đều có một câu chuyện. Có thể là những con số trong 2048, hay xây dựng một quốc gia trong Civilization, hoặc những tương tác thầm lặng trong Monument Valley. Hãy nghĩ về câu chuyện sẽ được người chơi cảm nhận trong trò chơi của bạn.
Mood – cảm xúc: Trò chơi của bạn tạo ấn tượng gì? Hình ảnh? Âm thanh? Ấn tượng đầu tiên rất là quan trọng. Ấn tượng đầu tiên sẽ cuốn người chơi vào trò chơi. Có lẽ, bạn sẽ cung cấp cho trò chơi của bạn một sự rung cảm retro với đồ họa pixel và âm nhạc chiptune.
Bạn gặp khó khăn để nghĩ ra một ý tưởng hay ho, đừng lo bạn không phải là người duy nhất…
Hãy tham gia game hackathon/jam. Bạn và những người tham gia khác sẽ được giao nhiệm vụ tạo ra trò chơi trong một khoảng thời gian ngắn. Trong suốt quá trình đó, bạn sẽ được hỗ trợ từ những jammer khác. Bạn sẽ cảm thấy vô cùng phấn khích và sáng tạo cứ thế tuôn ra thôi. Nếu không biết bắt đầu từ đâu? Hãy thử Ludum Dare, một trong những game hackathon/jam lớn nhất.
Giữ một danh sách các ý tưởng. Tôi và các nhà phát triển khác luôn ghi lại ý tưởng của mình. Bằng cách đó, chúng ta có thể tham khảo lại khi bị bí ý tưởng mới.
Khi nảy ra ý tưởng mới, hãy dừng mọi thứ bạn đang làm và viết ý tưởng đó xuống.
Resources
Để làm việc:
Google Drive
GitHub () Cần có git và Unity .gitignore.
Unity Collab. Dễ nhất trong cả ba nhưng phiên bản free có nhiều giới hạn.
Nếu bạn đã lên kế hoạch cho ý tưởng của mình; xin chúc mừng, bạn đã làm được khá tuyệt vời! Bây giờ, bạn có thể phát triển trò chơi thực sự.
(Nếu bạn không biết cách viết code, tôi khuyên bạn nên thực hiện bước 3, Code, trước Art)
Không biết làm thế nào để vẽ? Đừng sợ. Bất cứ ai cũng có thể vẽ ra một thứ đẹp đẽ với 3 nguyên tắc hình ảnh cơ bản: màu sắc, hình dạng, không gian.
UI
Hãy suy nghĩ về cách bạn có thể làm cho nó trở nên độc đáo – có một bảng phối màu riêng biệt, phông chữ, hình dạng và (các) biểu tượng – nhưng vẫn thực tiễn. Những thông tin quan trọng có thể đọc rõ và dễ hiểu hay không? Có gặp phải vấn đề phân tâm do màu sắc / phông chữ / biểu tượng?
2D animation
Bạn có hai lựa chọn:
Bone-based. Vẽ ra từng khung hình của animation. Đối với điều này, bạn nên sử dụng các sprite sheet với TexturePacker (hoặc nếu bạn đang sử dụng Unity, thì xài Sprite Packer).
Bone-based. Vẽ từng chi tiết động, sau đó tạo hiệu ứng cho vị trí. Có thể nhanh hơn, dễ dàng hơn và tiết kiệm bộ nhớ. Nếu bạn đang thực hiện 2D và sử dụng Unity, hãy thử chỉnh sửa các trục sprites hoặc Anima2D.
Misc
Dưới đây là một số mẹo miscellaneous art tip áp dụng không chỉ trong trò chơi mà còn trong các phần mềm khác.
Tile patterned asset để tạo hình ảnh lát gạch và lưu bộ nhớ.
9-patch/9-slice asset với các đường viền không thể mở rộng được nhưng bên trong thì có thể mở rộng để tạo các hình ảnh có thể mở rộng và giúp tiết kiệm bộ nhớ.
Đặt kích thước của từng asset là bội số của 4 hoặc lũy thừa là 2 để tiết kiệm bộ nhớ. Điều này phụ thuộc vào cách bạn đang nén asset.
Nếu bạn đang sử dụng Photoshop, hãy sử dụng “File > Export > Layers to Files” để xuất nhanh mỗi layer dưới dạng tệp (ví dụ: PNG, JPEG).
Bước đầu tiên của bạn? Quyết định về một game engine và một IDE (Integrated Development Environment – về cơ bản, nó là một ứng dụng cho phép bạn viết mã).
Bước thứ hai? Lập trình.
Bạn không biết cách viết code? Đừng lo lắng. Bạn có thể học.
Những nguyên tắc cơ bản của CS này là đủ để bắt đầu. (Tất cả các ví dụ code ở đây là trong C ++, một trong những ngôn ngữ chính mà framework phát triển game Unity 3D sử dụng.)
1) Kiểu dữ liệu (Data type) và biến (variable). Bản chất của Code chính là Data. Data đó được lưu trữ trong các biến. Bạn có thể khai báo một biến như sau:
int i = 0;
Trong đó, int là kiểu dữ liệu. i là tên biến. Và = 0 gán 0 là giá trị biến.
Vậy đây là gì?
string s = "pusheen is best cat";
string là kiểu dữ liệu. s là tên biến. Và “pusheen is best cat” là giá trị biến.
Một số kiểu dữ liệu phổ biến: int và long là số nguyên. `float và double là số thập phân. Và chuỗi (string) là bất kỳ câu nào.
2) If statement. Nếu câu lệnh đánh giá nếu một điều kiện nhất định là đúng. Nếu có, thì code bên trong câu lệnh if sẽ được chạy:
if (true){ //true is always true!
doThings(); //I'm inside the if statement's brackets; run me!
}
Nếu điều kiện không đúng, sẽ chuyển qua đánh giá các điều kiện else ifkhác nếu có:
int i = 1;
if (i == 0){
doThings();
}
else if (i == 1){
doOtherThings(); //I'm gonna be run!
}
Hoặc, chỉ cần chạy một số mã khác với else:
int i = 60000;
if (i == 0){
doThings();
} else {
doOtherThings(); //I'm still gonna be run.
}
3) For/while loop. Trong khi các vòng lặp code tiếp tục khi một điều kiện nhất định vẫn đúng, khi điều kiện là sai, vòng lặp while loop sẽ thoát.
while (someBool == true){ //condition
doThings(); //We'll keep doing things until someBool is false
}
Vòng lặp while loop này sẽ chạy trong bao lâu?
while (true){
doThings();
}
Đối với vòng lập là while loop trong đó:
int i = 0;
while (i < condition){
doThings();
i++; //increment after doing things
}
Điều đó tương đương với:
for (int i = 0; i < condition; i++){
doThings();
}
4) Cấu trúc dữ liệu cơ bản: Chúng ta có dữ liệu và giờ thì cần phải đánh giá và sử dụng dữ liệu đó. Ngoài ra, ta cũng có thể lưu trữ dữ liệu đó thành một dạng cấu trúc – hay còn gọi là cấu trúc dữ liệu. Cấu trúc dữ liệu bạn nên biết là arrays,lists,queues,stacks, vàsets.
Ví dụ nhanh về Arrays:
/*
Say you have numbers 0 through 9 that you want to store somewhere. You can store it in an array!
*/
int[] arr = new int[10];
/*
The [] brackets declare an array. We assign a new array to arr of size 10 - that means it can hold 10 elements. Arr now looks like this:
arr = [ 0 0 0 0 0 0 0 0 0 0 ]
*/
for (int i=0; i<10; i++){
arr[i]=i; //We assign whatever i is to the the ith index of arr.
//Did you know data structures' indices start at 0?
}
/*
After the for loop, our array data structure should look like this!
arr = [ 0 1 2 3 4 5 6 7 8 9 ]
*/
5) Functions và exceptions: Các Function về cơ bản là một dòng mã nhỏ mô tả một chuỗi mã lớn. Ví dụ: nếu bạn call:
EatBread();
và EatBread() trông như thế này:
void EatBread(){ //<---this is a function.
breadAte=true;
printf("I CAN FEEL THE CARBS COURSING THROUGH MY BODY");
}
Sau đó, lệnh gọi EatBread() thực sự là một cuộc gọi đến hai câu lệnh trong EatBread() function.
Nếu bạn làm điều gì đó không đúng, exception sẽ xuất hiện. Chúng là những lỗi màu đỏ giận dữ ở đó để cho bạn biết hãy revise lại nó.
Để tìm hiểu thêm về các function, hãy vào đây; cho trường hợp exception, hãy vào đây.
Sau đó, có những thứ khác bạn nên biết:
6) Ngôn ngữ lập trình. Bạn sẽ viết code bằng ngôn ngữ nào? C ++? Javascript? C #? Mỗi ngôn ngữ được viết hơi khác nhau và có thể cho phép bạn làm những việc khác nhau.
7) API (Giao diện lập trình ứng dụng)( Xem thêm API là gì?). Khi bạn biết những điều cơ bản, bạn sẽ phải tìm hiểu API cụ thể của công cụ trò chơi của mình. Về cơ bản, các API là một loạt các công cụ mạnh mẽ được bao bọc trong các lớp và chức năng đơn giản mà bạn có thể gọi. API giúp cuộc sống dễ dàng hơn. Cách dễ dàng hơn.
8) Nhìn vào một dự án có sử dụng game engine mà bạn đã chọn. Unreal và Unity đều có rất nhiều dự án miễn phí mà bạn có thể tham khảo. Điều này sẽ cho phép bạn khám phá cách mọi thứ kết hợp với nhau. Ngoài ra, bạn có thể xây dựng ý tưởng trò chơi của riêng mình.
if (you.getThisFar()==true){
veryProud=true;
you.didIt(); //CURRENT MOOD: THE SHKEST
}
Lời khuyến khích: Tôi biết việc viết code là đáng sợ lúc đầu khi bạn gặp phải những rào cản liên tục thất bại. Nó không có nghĩa là bạn dở code mà đó là một thách thức, bạn sẽ phải thất bại để có được thành công.
Nhưng nó cũng như bất kỳ kỹ năng nào khác khi bạn sẽ tốn thời gian để học hỏi và thuần thục. TopDev Blog sẽ vẫn còn cập nhật thêm thông tin về tự học lập trình Game cho các bạn sau nhé!
Điểm hấp dẫn nhất của PHP theo mình là Array, và hầu như trong code, mọi thứ đều là key => value. Do vậy mà bạn biết thêm những hàm built-in rẳng của PHP, mà xử lý cho lẹ là điều hết sức quan trọng. Nếu không, thay vì tập trung vào cái cần làm, bạn lại hì bục sáng tạo ra những cái hàm, ban đầu chỉ là để cho xong task, hoặc là xa hơn là để tự sướng. Nhưng kết quả là, rất ức chế cho thằng khác, vì nó phải suy nghĩ cái đó là cái gì? – Đây là note khá hay mình dẫn từ 1 post của bạn Trần Phong Phú (Fullstackdev tại Sendo). [Xem thêm bài blog về associative array]
Mình vô tình đọc được 1 bài tuts hay của tác giả Anton Bagaiev nên lược dịch lại cho các bạn đọc, không bổ bề ngang cũng bổ bề dọc, chúc các bạn thu được kiến thức hữu ích.
Trong bài tutorial này, mình sẽ liệt kê các hàm xử lý mảng thông dụng trong Php kèm theo ví dụ và cách sử dụng tốt nhất. Đã lập trình Php thì cần biết làm sao sử dụng và làm sao để phối hợp các hàm xử lý mảng để cho code dễ đọc và ngắn gọn hơn.
Cơ bản
Bắt đầu bằng 1 hàm cơ bản để xử lý keys và values của mảng. Một trong số đó là array_combine(), nó tạo 1 mảng kết hợp bằng cách trộn keys của 1 mảng này và values của 1 mảng khác, với điều kiện 2 mảng này bằng nhau.
Như bạn đã biết, hàm array_values() trả về 1 mảng các giá trị đã xác định, array_keys() trả về 1 mảng các key đã cho trước, và array_flip() chuyển đổi ngược lại các keys tương ứng với values :
Cấu trúc này hoạt động hoàn hảo với các hàm như preg_slit() hoặc explode(). Ngoài ra, bạn có thể bỏ qua một số tham số (parameters), nếu bạn không cần định nghĩa chúng:
Với hàm extract(), bạn có thể xuất một mảng kết hợp sang các biến. Đối với mỗi phần tử của một mảng, một biến sẽ được tạo ra với tên của key và value như là một giá trị của phần tử:
Lưu ý rằng extract() không an toàn nếu bạn làm việc với dữ liệu người dùng (như trả kết quả theo yêu cầu), vì vậy tốt hơn là sử dụng chức năng này với EXTR_IF_EXISTS và EXTR_PREFIX_ALL.
Ngược lại extract() là hàm compact(), tạo một mảng kết hợp từ các biến:
Một hàm tuyệt vời cho việc lọc mảng, và nó là array_filter(). Truyền mảng vào như là tham số đầu tiên và một hàm anonymous như là tham số thứ 2. Trả về giá trị là true trong hàm callback nếu bạn muốn lấy phần tử trong mảng, hoặc false nếu không muốn:
Bạn có thể lấy ra những giá trị duy nhất (unique values) từ 1 mảng bằng cách sử dụng array_unique(). Xem ví dụ để hiểu rõ hơn nhé, chứ không biết diễn tả sao hết:
Với array_column(), bạn có thể lấy các giá trị theo cột từ 1 mảng đa chiều, giống như kết quả trả về từ SQL database hoặc import từ file CSV. Chỉ cần truyền vào 1 mảng và tên của cột:
Bắt đầu từ PHP 7, array_column() trở nên mạnh mẽ hơn, bởi vì nó được phép xử lý một mảng của các đối tượng (array of objects). Vì vậy làm việc với 1 array of models (thông cảm, cái này mình không biết diễn tả bằng tiếng Việt ra sao hết) trở nên dễ dàng hơn:
Sử dụng array_map(), bạn có thể apply 1 callback cho tất cả các phần tử của mảng. Bạn truyền vào tên hàm hoặc hàm không xác định (anonymous function) để nhận được 1 mảng mới dựa trên mảng đã cho:
Có một câu chuyện từ lâu là không có cách nào để truyền values và keys của mảng vào 1 callback, nhưng ta có thể bắt được chúng:
$model = ['id' => 7, 'name'=>'James'];
$callback = function($key, $value) {
return "$key is $value";
};
$res = array_map($callback, array_keys($model), $model);
print_r($res);
// Array
// (
// [0] => id is 7
// [1] => name is James
// )
Nhưng bạn thấy đấy, trông code nhìn dơ dơ. Tốt nhất là nên sử dụng array_walk() để thay thế. Hàm này tuy nhìn giống array_map(), nhưng nó hoạt động theo phương thức khác. Đầu tiên, một mảng tham chiếu được truyền vào, array_walk() không hề tạo ra 1 mảng mới nào, mà nó thay đổi mảng tham chiếu đó. Vì vậy đối với mảng nguồn (source array), bạn có thể truyền vào giá trị của mảng tham chiếu trong 1 callback, từ đó keys của mảng đó cũng có thể được truyền vào dễ dàng (đọc nhức đầu quá, xem vd là rõ ngay ấy mà):
$fruits = [
'banana' => 'yellow',
'apple' => 'green',
'orange' => 'orange',
];
array_walk($fruits, function(&$value, $key) {
$value = "$key is $value";
});
print_r($fruits);
// Array
// (
// [banana] => banana is yellow
// [apple] => apple is green
// [orange] => orange is orange
// )
Cách tốt nhất để merge 2 hoặc nhiều mảng trong PHP là sử dụng hàm array_merge(). Phần tử của các mảng này sẽ được merge với nhau, keys mảng này sẽ tương ứng values mảng kia:
Để so sánh 1 mảng nguồn với 1 mảng khác (hoặc nhiều mảng) để trả về 1 mảng chứa sự khác nhau của mảng nguồn đó so với mảng cần so sánh, dùng array_diff(). Dùng array_intersect() để so sánh hai mảng trả vê các giá trị giống nhau:
Bạn nên nhớ rằng mọi chức năng phân loại trong PHP đều hoạt động với các mảng bởi tham chiếu và trả về true khi thành công hay false khi thất bại. Có một chức năng sắp xếp cơ bản được gọi là sort(), và sắp xếp các giá trị theo thứ tự tăng dần mà không lưu keys. Hàm phân loại có thể được thêm vào bởi các ký tự sau:
a, sort preserving keys
k, sort by keys
r, sort in reverse/descending order
u, sort with a user function
Bạn có thể thấy các kết hợp của các chữ cái này trong bảng sau:
Ma thuật thực sự bắt đầu khi bạn bắt đầu kết hợp các hàm xử lý mảng. Đây là cách bạn có thể cắt và xóa các giá trị rỗng chỉ bằng một dòng code với array_filter() và array_map():
Như bạn thấy, hiểu biết về các hàm xử lý mảng sẽ làm cho code ngắn hơn và dễ đọc hơn. Tất nhiên là PHP có nhiều hàm xử lý mảng khác, tuy nhiên trong bài tuts này chúng ta có thể hiểu rõ được cơ bản nhất để cho code ngon hơn.
Trước khi chúng ta đi sâu hơn vào Tối ưu hóa App Store, điều quan trọng đầu tiên là phải hiểu đúng những khái niệm cơ bản. Nếu bạn là người mới bắt đầu với Mobile App Marketing, bạn nên dành một chút thời gian để tìm hiểu kĩ hơn về các khái niệm sau:
*Mobile marketing có thể hiểu đơn giản là cách tiếp thị quảng cáo sản phẩm, thông tin dịch vụ, … qua các thiết bị di động như điện thoại smartphone, máy tính bảng tablet, … tới khách hàng.
*Mobile marketing có nhiều cách để bạn có thể thực hiện chiến dịch quảng cáo của mình. Tùy vào đối tượng khách hàng, lĩnh vực hoạt động hay ngân sách mà bạn có thể chọn cho mình loại hình phù hợp. Ví dụ như QR Codes, Location-based Marketing, Mobile Search Ads, SMS Marketing và không thể thiếu là In Game Mobile Marketing và App-based Marketing.
* App-based marketing: các bạn có thể hiểu đây là hình thức quảng cáo trên điện thoại qua các ứng dụng mobile, thông qua các advertisers bạn sẽ đưa quảng cáo của mình thông qua một ứng dụng mobile của bên thứ 3, loại hình Mobile marketing này rất phổ biến trên thế giới hiện nay vì khả năng tương tác lớn khi hơn 80% sử dụng mobile bạn đều phải sử dụng liên quan đến ứng dụng (apps).
* In game mobile marketing: cũng là giải pháp mobile marketing quen thuộc, nếu bạn để ý khi sử dụng smartphone của mình chơi game bạn sẽ gặp loại quảng cáo này có thể là banner ads nhỏ trong game,1 pop-up full page, hoặc một đoạn video ngắn….
Khi ứng dụng của bạn được phát triển và bạn đã quen thuộc với những khái niệm cơ bản trên về tiếp thị ứng dụng, bạn phải quyết định nơi để phát hành ứng dụng hoặc trò chơi của mình. Bạn có thể chọn Google Play hoặc Apple App Store hoặc thậm chí bạn có thể quyết định làm cả hai. Nhưng hãy xem qua hai cửa hàng này có gì rồi quyết định nhé.
iOS vs Android – Cửa hàng Google Play vs Apple App Store
Cả hai cửa hàng đều có chung một mục đích: họ cung cấp một nền tảng để người dùng tìm kiếm các ứng dụng hoặc trò chơi và tải chúng xuống. Tuy nhiên, điều này không có nghĩa là chúng hoạt động như nhau. Trong chương này của hướng dẫn ASO, chúng ta sẽ tìm hiểu lịch sử, sự khác biệt chính và thuật toán của cả hai cửa hàng.
– Lịch sử
Với việc con người sử dụng điện thoại di động ngày càng thường xuyên, ngành công nghiệp ứng dụng bắt đầu bùng nổ. Theo đó, Apple App Store đã chứng kiến sự gia tăng số lượng ứng dụng từ 800 kể từ khi ra mắt năm 2008 lên 2 triệu vào năm 2018 (Nguồn Statista). Tương tự, số lượng ứng dụng có sẵn trên Google Play đã lên tới 3,6 triệu vào tháng 3 năm 2018. Rõ ràng là sự cạnh tranh trên thị trường rất mạnh. Điều này dẫn đến điểm tiếp theo:
– Xu hướng năm 2022
Đến bây giờ, các ứng dụng có tỷ lệ sự cố cao (high crash rates) và ít khi cập nhật ứng dụng sẽ được coi là chất lượng kém và do đó có thứ hạng thấp hơn. Các ứng dụng được cập nhật thường xuyên mà mọi người sử dụng thường xuyên hơn sẽ được đánh giá cao và xuất hiện top đầu trong kết quả tìm kiếm.
Đó là lý do tại sao cần có một quản lý ứng dụng hiệu quả. Các công cụ như App Radar giúp bạn theo dõi các thay đổi và chuẩn bị các bản cập nhật với ít công việc hơn và tác động nhiều hơn.
– Sự khác biệt chính
Một trong những khác biệt chính liên quan đến khía cạnh xuất bản/phát hành các ứng dụng (publishing).
Trong khi Google Play cho phép bạn phát hành các bản cập nhật và thực hiện các thay đổi mà hầu như không bị trì hoãn thời gian, mỗi ứng dụng trên Apple App Store phải trải qua quá trình xem xét. Chu trình xem xét thường mất tới 24 giờ và liên quan đến việc kiểm tra các khía cạnh kỹ thuật, nội dung và thiết kế. Các ứng dụng trên Google Play thường được xem xét sau khi ứng dụng được khởi chạy.
– Thuật toán xếp hạng khác nhau.
Mặc dù từ khóa (keyword) đều quan trọng trong cả hai cửa hàng, nhưng chúng được đánh giá khác nhau. Google Play hoạt động tương tự như chính Google. Điều này có nghĩa là nó xem xét tất cả các yếu tố văn bản của ứng dụng của bạn khi lập chỉ mục từ khóa.
Apple App Store thì cung cấp một trường để chỉ định từ khóa của bạn. Trong một số trường hợp, nó thậm chí còn lấy chúng từ đối thủ và tên danh mục của bạn. Ngược lại với Google Play, không nên lặp lại các từ khóa trong phần tiêu đề và từ khóa của bạn.
Các yếu tố xếp hạng của Apple App Store và Google Play Store
Google Play và Apple App Store sử dụng các thuật toán rất chi tiết và tinh vi để sắp xếp kết quả tìm kiếm. Mặc dù các thông tin sau chưa được xác nhận chính thức nhưng có thể suy ra các yếu tố ảnh hưởng đến thứ hạng của cửa hàng ứng dụng:
4. Tối ưu hóa App Store được thực hiện như thế nào?
Sau khi quyết định nơi bạn muốn phát hành ứng dụng của mình, bây giờ là lúc để bắt đầu công việc.
– Điều đầu tiên: Thiết lập chiến lược ASO rõ ràng
Hãy tiến hành các nghiên cứu và khảo sát về thị trường của bạn. Điều quan trọng là phải hiểu khách hàng và sử dụng những hiểu biết cho ứng dụng và các thông tin liên quan. Những từ khóa nào họ đang sử dụng khi tìm kiếm các ứng dụng tương tự như của bạn? Họ đang nói ngôn ngữ nào? Khi bạn có thông tin này, bạn có thể chuyển sang bước tiếp theo.
– Đặt tên cho ứng dụng của bạn
Tên ứng dụng của bạn (còn gọi là Tiêu đề ứng dụng) là những gì mọi người dùng nhìn thấy đầu tiên. Đó là lý do tại sao một trong những điều quan trọng nhất là đặt tên ứng dụng một cách khôn ngoan. Đảm bảo rằng Tiêu đề ứng dụng của bạn có liên quan đến ứng dụng của bạn, dễ đọc và độc đáo. Nếu tiêu đề hấp dẫn, mọi người sẽ nhớ nó, điều này sẽ mang lại cho ứng dụng của bạn giá trị nhận dạng cao hơn. Khi chọn đúng tên, đừng quên xem xét số lượng ký tự.
– Biết cách thực hiện nghiên cứu từ khóa (Keyword Research) cho Ứng dụng di động của bạn
Mục tiêu ở đây là thiết lập một bộ từ khóa mà bạn muốn tìm thấy trong các cửa hàng ứng dụng.
Khi thực hiện nghiên cứu từ khóa của bạn hãy xem xét các câu hỏi sau:
Các tính năng chính của ứng dụng hoặc trò chơi của bạn là gì?
Các từ đồng nghĩa mô tả các tính năng là gì?
Các ứng dụng tương tự được gọi là gì?
Danh mục ứng dụng của bạn là gì?
Những thuật ngữ nào mọi người thường sử dụng trong thể loại này?
Tìm kiếm các từ khóa phù hợp là một quá trình đang diễn ra, vì vậy đừng bỏ qua bộ từ khóa của bạn. Có rất nhiều Công cụ Tối ưu hóa App Store có thể giúp bạn điều đó. Ứng dụng Radar là một trong những ứng dụng toàn diện nhất trên thị trường. Nó cung cấp một giao diện gọn gàng nơi bạn có thể theo dõi các từ khóa của mình, đánh giá chúng và nhận các mẹo tùy chỉnh để cải thiện thứ hạng của bạn.
– Viết mô tả ứng dụng của bạn
Mô tả ứng dụng là một phần thiết yếu khác trong siêu dữ liệu ứng dụng của bạn. Nó cung cấp cho người dùng thông tin về những gì ứng dụng của bạn nói về và cung cấp một cái nhìn tổng quan về các tính năng chính của nó. Ngoài ra, mô tả ứng dụng không chỉ phù hợp với người dùng mà còn cho thuật toán lưu trữ ứng dụng.
Đặc biệt đối với cửa hàng Google Play, đây là nơi Google tìm thấy các từ khóa để lập chỉ mục cho ứng dụng. Có một lưu ý là không nên đặt tất cả các từ khóa của bạn vào mô tả mà không có sự liên kết nào cả. Cố gắng kết hợp các từ khóa của bạn vào câu một cách tự nhiên. Bằng cách này, mô tả sẽ gây hấp dẫn cho người đọc và cải thiện tìm kiếm trên thuật toán.
Mô tả trong Apple App Store ít liên quan hơn về các từ khóa vì bạn có thể chỉ định chúng trong thông tin bổ sung thêm. Tuy nhiên, đây vẫn là một cách tuyệt vời để thuyết phục người dùng tiềm năng tải xuống ứng dụng của bạn.
Lý tưởng nhất, mô tả của bạn là thông tin, dễ hiểu và có cấu trúc rõ ràng. Bạn có thể sáng tạo và sử dụng các gạch đầu dòng cũng như biểu tượng cảm xúc nhưng chỉ cần nhớ rằng mô tả được giới hạn ở 4000 ký tự (ở cả hai cửa hàng) là được.
– Chọn biểu tượng ứng dụng phù hợp bằng thử nghiệm A / B
Bây giờ bạn đã biết những điều cơ bản về cách viết để làm cho ứng dụng của bạn hiển thị, đã đến lúc nhìn vào một vấn đề khác của nó: hình ảnh.
Biểu tượng ứng dụng của bạn là thứ thu hút nhiều sự chú ý và có thể là một trong những lý do chính khiến mọi người nhấp vào kết quả tìm kiếm. Do đó, nó được coi là một yếu tố quan trọng khác của tối ưu hóa cửa hàng ứng dụng.
Khi thiết kế biểu tượng ứng dụng của bạn, hãy nghĩ về ứng dụng của bạn nói về cái gì và làm thế nào bạn có thể truyền đạt trực quan điều đó. Nếu ứng dụng hoặc trò chơi của bạn vui tươi, biểu tượng của bạn sẽ phản ánh điều đó.
Một cách tuyệt vời để kiểm tra những gì thực sự hoạt động cho đối tượng mục tiêu của bạn là thử nghiệm A / B. Ý tưởng đằng sau nó là tạo ra nhiều biến thể biểu tượng hơn và tìm ra cái nào có nhiều nhấp chuột nhất. Ví dụ, có thể thú vị để kiểm tra màu sắc hoặc ký tự mà người dùng của bạn thích. Khi bạn có thông tin này, bạn có thể điều chỉnh biểu tượng của mình cho phù hợp.
– Chuẩn bị ảnh chụp màn hình & video
Có nhiều thứ để giao tiếp trực quan hơn chỉ là biểu tượng ứng dụng. Khi bạn đưa người dùng đến trang ứng dụng của mình, bạn phải thuyết phục họ tải xuống. Mặc dù Screenshots và Video có thể không ảnh hưởng trực tiếp đến xếp hạng ứng dụng của bạn, nhưng chúng đóng một phần trong tối ưu hóa chuyển đổi – đây là một yếu tố quan trọng của Tối ưu hóa cửa hàng ứng dụng.
Screenshot của ứng dụng và video cung cấp cho bạn cơ hội để thể hiện chức năng của ứng dụng và trò chơi, đồng thời cũng thể hiện cái nhìn trực quan về nó.
Trên thực tế, khoảng 50% mọi người dựa trên quyết định của họ về ấn tượng đầu tiên, đó là lý do tại sao bạn cần chú ý đến chi tiết với hình ảnh của mình.
Khi nói đến screenshot, trước tiên bạn có thể chọn giữa bố cục Chân dung và Phong cảnh. Nói tóm lại, điều này có nghĩa là bạn có thể quyết định xem bạn muốn có một ảnh chụp màn hình dọc hay ngang. Tương tự như biểu tượng của bạn, có thể là một ý tưởng tốt để tìm ra những gì hoạt động tốt nhất với thử nghiệm A / B. Nói chung, Screenshot được thiết kế tốt sẽ cung cấp cho người dùng bản xem trước ứng dụng của bạn và thậm chí có thể kể một câu chuyện trực quan.
Kể chuyện bằng hình ảnh cũng có thể được sử dụng trong video của bạn. Chúng được gọi là Xem trước ứng dụng trong Apple App Store (trước đây gọi là App Store Connect hoặc iTunes Connect) hoặc Video trên App Store trong Google Play.
– Danh sách ứng dụng và bản địa hóa
Sau khi đã chuẩn bị danh sách những thứ cần thiết cho ứng dụng của mình cùng với hình ảnh và video, đã đến lúc phải thực hiện bước tiếp theo. Bạn có thể đã làm tất cả những điều đó cho tiếng Anh, nghĩ rằng mọi người đều tìm kiếm các ứng dụng bằng tiếng Anh, phải không? Nhưng điều này không hoàn toàn đúng.
Nếu bạn muốn đưa ứng dụng hoặc trò chơi của mình ra toàn cầu, bạn phải điều chỉnh nó cho phù hợp với thị trường. Chúng tôi gọi đây là nội địa hóa hoặc ASO quốc tế. Điều này không có nghĩa là bạn phải bắt đầu lại từ đầu. Bạn có thể sử dụng siêu dữ liệu, từ khóa hoặc ảnh chụp màn hình hiện có của mình và bản địa hóa chúng sang các ngôn ngữ khác.
Với bản địa hóa, bạn có thể cải thiện khả năng hiển thị tìm kiếm của cửa hàng ứng dụng và mở rộng đối tượng mục tiêu của mình. Về cơ bản, bạn làm cho ứng dụng của bạn có sẵn cho người dùng tìm kiếm bằng tiếng mẹ đẻ của họ. Trình bày ứng dụng của bạn cho nhiều đối tượng người dùng hơn có thể giúp cải thiện nhiều lượt tải xuống và doanh thu hơn.
– Xếp hạng & Đánh giá ứng dụng
Phản hồi từ người dùng của bạn là một phần không thể thiếu của ASO. Cả hai cửa hàng đều xem trọng đến các bình luận và đánh giá người dùng để lại cho ứng dụng của bạn. Xếp hạng của bạn càng tốt, ứng dụng của bạn càng được các cửa hàng xem xét và xếp hạng càng cao.
Người dùng có xu hướng để lại đánh giá cho ứng dụng họ thích. Tuy nhiên, bạn cũng có thể khuyến khích họ làm như vậy trong chính ứng dụng. Nếu bạn có một trò chơi, thời điểm tốt để yêu cầu đánh giá sẽ là sau khi chiến thắng một trò chơi. Nhưng hãy cẩn thận, bạn có thể bị phạt nếu bạn đẩy mạnh vấn đề này thường xuyên. Ví dụ, trên iOs, bạn có thể yêu cầu đánh giá tối đa ba lần một năm.
Vietnam Mobile Day 2021 – nơi hội tụ những chuyên gia trong lĩnh vực ứng dụng sẽ cùng bạn chinh phục những bảng xếp hạng trên App Store, đừng bỏ lỡ nhiều topic hay tại VMD2019 do TopDev tổ chức năm nay nhé!
Buffer là vùng lưu trữ dữ liệu tạm thời và thường được lưu trữ trong bộ nhớ tạm (RAM). Công nghệ này hiện nay được áp dụng rất nhiều trên các website nghe nhạc, xem phim hay các ứng dụng livestream.
Các ứng dụng của Buffer
Ví dụ khi bạn xem video trực tuyến hay nghe nhạc trực tuyến thì có hai cách để trình duyệt tải dữ liệu này:
Tải hết toàn bộ dữ liệu của video, nhạc rồi mới chạy.
Tải từng phần của video, nhạc và chạy từng phần nôi dung mỗi khi dữ liệu được tải về máy. Ta có thể hiểu là khi này data của toàn bộ video hay nhạc được băm nhỏ rồi tải về lưu trong bộ nhớ tạm của trình duyệt, player của trình duyệt sẽ lấy dữ liệu đã tải này xử lý thành âm thanh hình ảnh rồi phát cho bạn xem. Dữ liệu tải đến đâu thì play đến đấy, nếu bạn xem nhanh quá thì phải chờ dữ liệu được tải thêm cho đến khi hoàn thành.
Với cách thứ hai thì từng phần dữ liệu video, nhạc được chia nhỏ tải về máy được gọi là buffer.
Vai Trò Của Buffer (Và Tại Sao Cần Sử Dụng Buffer)
Cách đầu tiên khi ta tải video của trình duyệt ở trên sẽ khiến người dùng phải chờ đợi một thời gian trước khi dữ liệu của toàn bộ video được tải về toàn bộ. Trong trường hợp dung lượng đoạn video có kích cỡ lớn (dài vài giờ đồng hồ có thể lên đến cả Gb) thì cách làm này sẽ khiến người dùng phải đợi rất lâu để có thể bắt đầu xem video. Thường thì cách này được ứng dụng từ xa xưa khi các công nghệ streamming chưa có.
Cách làm thứ hai thì người dùng có thể xem ngay nội dung video khi từng phần chia nhỏ dữ liệu của video (buffer) được tải xuống máy. Trường hợp tốc độ tải về từng phần nhỏ dữ liệu này nhanh hơn tốc độ xem video của người dùng thì khi đó người dùng sẽ có thể coi video một cách liên tục mà không bị giật.
Cache là gì?
Cache là kỹ thuật lưu lại những dữ liệu đã được xử lý vào 1 bộ nhớ tạm. Bộ nhớ tạm này sẽ có tốc độ truy suất nhanh (RAM, hoặc local storage của client). Những lần sau cần dùng thông tin thì chỉ cần truy suất ngay từ bộ nhớ tạm mà không cần phải làm thêm gì.
Sự khác biệt giữa Buffer và Cache?
Buffer giống Cache ở điểm là nó cũng lưu data ở bộ nhớ tạm. Tuy nhiên Buffer được sử dụng chủ yếu để giảm thời gian chờ giữa việc nhận và xử lý dữ liệu bởi một thiết bị nào đó, data được băm nhỏ, tải đến đâu xử lý đến đó.
Cache được sử dụng dựa trên nguyên tắc cùng một dữ liệu sẽ được truy cập nhiều lần do đó data được lưu trữ trong cache sẽ làm giảm phần lớn thời gian truy cập, đỡ phải tải dữ liệu lại một lần nữa.
IDE là gì? – IDE viết tắt là từ (Integrated Development Environment) là môi trường tích hợp dùng để viết code để phát triển ứng dụng. Ngoài ra IDE tích hợp các tool hỗ trợ khác như trình biên dịch (Compiler), trình thông dịch (Interpreter), kiểm tra lỗi (Debugger), định dạng hoặc highlight code, tổ chức thư mục code, tìm kiếm code…
Các môi trường IDE thường bao gồm
Một trình soạn thảo mã nguồn (source code editor): dùng để viết mã.
Trình biên dịch (compiler) và/hoặc trình thông dịch (interpreter).
Công cụ xây dựng tự động: khi sử dụng sẽ biên dịch (hoặc thông dịch) mã nguồn, thực hiện liên kết (linking), và có thể chạy chương trình một cách tự động.
Trình gỡ lỗi (debugger): hỗ trợ dò tìm lỗi.
Ngoài ra, còn có thể bao gồm hệ thống quản lý phiên bản và các công cụ nhằm đơn giản hóa công việc xây dựng giao diện người dùng đồ họa (GUI).
Nhiều môi trường phát triển hợp nhất hiện đại còn tích hợp trình duyệt lớp (class browser), trình quản lý đối tượng (object inspector), lược đồ phân cấp lớp (class hierarchy diagram),… để sử dụng trong việc phát triển phần mềm theo hướng đối tượng.
Phân theo số lượng các ngôn ngữ được hỗ trợ, ta có thể chia các môi trường phát triển hợp nhất được sử dụng rộng rãi ngày nay thành hai loại:
Môi trường phát triển hợp nhất một ngôn ngữ: làm việc với một ngôn ngữ cụ thể, ví dụ: Microsoft Visual Basic 6.0 IDE.
Môi trường phát triển hợp nhất nhiều ngôn ngữ: có thể làm việc với nhiều ngôn ngữ lập trình, ví dụ: Eclipse IDE, NetBeans, Microsoft Visual Studio.
IDE và Text Editor
IDE giúp cho bạn dễ dàng và thuận tiện hơn trong việc phát triển ứng dụng mặc dù không cần IDE bạn vẫn có thể viết mã nguồn được, bởi vì thực chất để mã nguồn của một ngôn ngữ lập trình nào đó chạy được, ta chỉ cần trình biên dịch (compiler) tương ứng của ngôn ngữ đó là được.
Ví dụ bạn có thể lập trình C/C++ bằng Notepad hoặc Microsoft Word của Windows, sau đó lưu nó lại thành một file .cpp và dùng Compiler của C/C++ để biên dịch file đó là xong.
Nhưng làm như vậy sẽ rất mất thời gian và không hiệu quả đối với các chương trình lớn có cấu trúc phức tạp, IDE được sinh ra để giúp đỡ lập trình viên, nó tích hợp sẵn các tool cần thiết giúp lập trình ứng dụng trở nên dễ dàng, nhanh chóng và ít bị mắc lỗi hơn.
IDE tích hợp sẵn trình biên dịch hoặc trình thông dịch bên trong nó giúp bạn thực thi code trực tiếp khi đang lập trình ứng dụng, tiêu biểu như Visual Studio, Esclipe, Xcode, Android studio…v.v.
Text Editor không tích hợp sẵn trình biên dịch hoặc trình thông dịch bên trong nó, nghĩa là muốn chạy được ứng dụng, bạn phải dùng riêng compiler bên ngoài. Những Text Editor này thường dùng cho phát triển ứng dụng web, tiêu biểu như Sublime text, Atom, Bracket, Notepad++, VScode…v.v.
Ngoài ra tùy vào từng loại ngôn ngữ lập trình sẽ có những Text chuyên biệt dành riêng cho nó, ví dụ như Pycharm cho Python hay PhpStorm cho PHP. Tuy nhiên hiện tại các text editor mới như Sublime text, Atom, VScode cũn
g có rất nhiều plugin hoặc extension support đầy đủ ngôn ngữ mà bạn đang code.
Một số phần mềm ứng dụng IDE cho bạn
Microsoft Visual Studio
Xcode
Netbeans
IntelliJ IDEA
Eclipse
Kỹ năng cần thiết để sử dụng IDE
Dựa trên môi trường IDE, bạn cần có kỹ năng trong khi phát triển ứng dụng: ngôn ngữ lập trình như PHP, JavaFX, C / C ++, JavaScript, Perl, Ruby và hơn thế nữa. Ngoài ra, bạn cũng nên ham hiểu thêm đến 36 ngôn ngữ lập trình khác như Visual Basic, .NET, C #, F #, JavaScript, TypeScript
Chuyện bị tấn công DDoS là chuyện thường ngày ở huyện, gần như là một trong những vấn đề nhức đầu cho bất kỳ website nào. Vấn đề này hiện nay vẫn chưa được giải quyết một cách triệt để.
Một trong những giải pháp cực kỳ hiệu quả hiện nay vừa được Google cho ra mắt đó với tên gọi Google’s Project Shield chỉ cần 30 phút để setup theo hướng dẫn optimization trong 2 ngày tiếp theo, chắc chắn website của bạn sẽ không có vấn đề gì cả.
Đây là một trong những phương thức “install and forget” giúp bạn cài đặt dễ dàng về quên đi những vấn đề tấn công DDoS cực kỳ phiền phức. Hãy cùng xem qua nó là gì nhé
Tính năng
Về cơ bản Project Shield được xây dựng trên cơ sở vật chất của Google, tạo ra nhiều lớp phòng thủ cho hệ thống, giúp chống lại các đợt tấn công DDoS. Bao gồm cả 3/4 và layer 7 attacks.
Bảo vệ không giới hạn
Bất kể website của bạn ở mức độ nào, Project Shield sẽ cung cấp những tính năng bảo vệ miễn phí cho tất cả các loại trang như tin tức, báo chí, luật nhân quyền, bầu cử, và kể cả monitoring.
Customizable caching
Project Shield caches giúp tăng cường sức đề kháng cho các DDoS defense từ đó cũng giúp cải thiện site performance, Bạn cũng có thể tuỳ chỉnh cache setting cho phù hợp với nhu cầu của website nhà mình.
Ngoài ra nó cũng có một số tính năng khác có thể kể đến như: real-time analytics, SSL support, Google support, bare admin support, và gồm cả những tính năng hỗ trợ rất tối ưu khác mà bạn sẽ được hưởng.
Nếu hệ thống phát hiện bạn đang bị tấn công, phía Google sẽ ngăn cản request lạ những hành vi đáng ngờ khác vào hệ thống server của bạn. Họ sẽ dùng hệ thống multi-layer filering system để lọc những thứ nguy hại này, ứng dụng chúng cho việc phòng thủ DDoS defenses cho cả network và của cả trung tâm dữ liệu.
Reverse proxy trong cơ sở dữ liệu của Google.
User request sẽ vào hệ thống Google’s network gần với vị trí của người dùng cuối, sau đó chúng sẽ được proxied qua cơ sở dữ liệu cloud data center của Google. Điều này giúp tăng performance và giảm độ latency.
Nội dung được đưa lại cho phía người dùng.
Chúng tôi lấy nội dung trang web yêu cầu hoặc từ bộ nhớ cache của chúng tôi hoặc từ máy chủ của bạn và gửi lại cho người sử dụng. Bằng cách rót content từ bộ nhớ cache, chúng tôi sẽ giảm tải trên máy chủ của bạn, đồng thời cũng cải thiện hiệu suất cho người dùng cuối (end-user).
Và đó chỉ là một trong số những tính năng tối ưu của sản phẩm này có thể đem lại cho người dùng. Các bạn có thể thử tự mình cài đặt và sử dụng, đây chắc chắn sẽ là một trong những công nghệ vượt trội nhất trong năm nay.
Code review là một bài tập thực hành tìm lỗi, bug và các lỗi khác mà người viết dễ bỏ qua khá hiệu quả. Review giúp cải thiện chất lượng chung của code, nhưng cũng là một cách hiệu quả để chia sẻ kiến thức và thông tin. Phần làm của các junior dev phải được các senior xem qua, nhưng bên cạnh đó các junior cũng nên được review. Dưới đây là lí do tại sao.
Trong mọi project có những mà một dev mới vào team cần thời gian để làm quen sử dụng. Chúng bao gồm các code mẫu và cách tổ chức project, testing, build, triển khai và các cách làm việc nhóm hợp lí. Đặc biệt trong các project lớn, các “ma mới” phải đối mặt với một thử thách lớn đó là hiểu được cấu trúc hiện tại và các quyết định về design cũng như lí do đằng sau các quyết định đó.
Chúng ta có thể thấy được cả khía cạnh về kĩ thuật và cách làm việc thông qua project. Tuy nhiên, việc ứng dụng các feature mới hoặc fix bug trong code base mới vẫn còn nhiều thách thức. Liệu có cách nào khác để học theo những người đã có kinh nghiệm trong cũng một project?
Để cho các dev trẻ xem các công trình của các senior là một cách học thật sự hiệu quả. Nó không chỉ giúp họ tham khảo được các quyết định về design và kết cấu tốt hơn cũng như thực hành về màu và code, nó còn cho họ thấy cách chúng được áp dụng vào một project thật mà dev làm việc. Với người được review, cũng chả có mất mát gì khi có thêm một người nữa xem code của bạn kể cả khi người review không có kinh nghiệm. Sự thật là, những người không có kinh nghiệm thường sẽ nhìn project đó theo một khía cạnh khác và mới hơn.
Dạng review này sẽ đem lại nhiều lợi ích cho các junior dev. Tuy nhiên, nó cũng có lợi cho cả project nữa. Rõ ràng là các dev sẽ quen việc nhanh hơn, nhưng việc review cũng mang lại cho project một cách nhìn nhận khác với những gì trực tiếp từ task hiện tại.
Có thời gian tôi làm việc cho một UX Consultancy khá nổi tiếng (Top10 UX Consultancy lớn nhất Úc), khách hàng của công ty trải rộng trong nhiều lĩnh vực (tài chính, technology, telecommucation,…).
Nói thêm một chút về mô hình công ty này vì nó khá thú vị và (hình như) chưa có ở Việt Nam – ít ra là trong ngành UX.
Công việc chủ yếu của chúng tôi là đến trực tiếp trụ sở của khách hàng và làm việc (gọi là onsite), thường là mỗi người sẽ được giao một dự án và trực tiếp lead team của khách hàng (gọi là inject).
Tùy theo industry và quy mô của công ty khách hàng mà: khi thì chúng tôi sẽ lead một team Dev, khi thì sẽ lead một team UX Design (đóng vai trò như một UX Lead), thậm chí có trường hợp là one man show luôn (tự xử hết). Đến khi deliver sản phẩm là coi như xong dự án, lại tiếp tục đi dự án khác. Industry tôi phụ trách là FinTech (Financial Technology) nên thường môi trường là các ngân hàng và thường làm việc chung với team UX Design.
Công việc này khá thú vị vì:
1. Được làm việc với rất nhiều môi trường khác nhau, nhiều ngành nghề khác nhau. 2. Khác với mô hình Agency, Consultancy khi đến làm việc với khách hàng là với tư cách là một chuyên gia nên rất được cưng chiều và trao rất nhiều quyền. Chính điều này tạo điều kiện rất thuận lợi cho chúng tôi làm việc (và dĩ nhiên expectation của khách hàng cũng rất cao). 3. Đi rất nhiều nơi (nhờ thời gian làm việc ở đây mà tôi được đi nhiều nơi ở nước Úc) và thường đi lại ăn ở rất sướng.
Đổi lại thì kỳ vọng của khách hàng đặt lên vai cũng rất lớn.
Do tính chất công việc là phải tự thân lead dự án của khách hàng nên trước giờ công ty tuyển rất kỹ, trung bình các bạn đồng nghiệp của tôi có tối thiểu 10-15 năm kinh nghiệm trực tiếp trong ngành. Tuy nhiên thời gian gần đây công ty phát triển quá nhanh, mà nhân lực lại không đủ dẫn đến yêu cầu tuyển dụng giảm đi (trước đây trung bình khoảng 5 vòng thì bây giờ còn 3 vòng), trước đây sau khi tuyển dụng phải có gần 1 tháng induction mới ra field thì gần đây chỉ sau một tuần cá biệt có trường hợp vài ngày là ra field luôn.
Vì tình hình như vậy nên phát sinh một câu chuyện làm tôi rút tỉa được một kết luận muốn chia sẻ với mọi người (sẽ kết luận cuối bài).
—
Cách đây không lâu, tôi phụ trách tư vấn một dự án khá lớn cho ANZ (vì dự án này mà tôi có được nửa năm ở Melbourne). Giai đoạn gần cuối dự án công ty tăng cường thêm một người nữa để phụ tôi một mảng trong dự án. Vì ANZ xem bạn là consultant nên sau vài ngày đầu tiên họ bắt đầu giao cho bạn lead một team.
Tôi cũng không để ý nhiều vì bản thân cũng phải đang chạy trối chết để kịp deadline bên mảng của tôi, thế là để bạn tự bơi. Sau này nhìn lại mới nhớ là bạn đã rất stress, gần như ngày nào cũng trong trạng thái căng thẳng, vò đầu bứt tai ở lại văn phòng rất trễ.
Crisis bắt đầu là khi hầu hết những lần bạn facilitate hay present các concept thì (thay vì manage và facilitate các stakeholders) bạn lại bị các stakeholders của khách hàng quay như chong chóng. Đỉnh điểm là trong một lần bạn present một module quan trọng trong dự án và (như mọi lần) bị các stakeholder quay cho đến khi Innovation Director có mặt ở đó và vì quá bực mình đã gửi một email complaint về công ty (lưu ý là vị trí Innovation Director của một ngân hàng lớn rất-rất-rất là bự và bạn này mà buồn thì không tốt tí nào cho công ty).
Sau đó thì các bạn Director bên công ty tôi phải nhảy vô và dập lửa, chuyện dập lửa xin không tả nhiều ở đây. Nhưng nói chung là đợt đó là một trong những crisis lớn của công ty.
Sau này hỏi thì mới biết là background của bạn cũng không phải là tệ. 7 năm làm việc ở một số công ty, sau đó thì hơn 5 năm dạy về mảng này ở một trường đại học ở Anh, rồi 2 năm gần nhất thì là giảng viên của một trường đại học khác (khá nổi tiếng) ở Úc – xin phép không nêu tên. Vấn đề ở đây là suốt hơn 7 năm gần nhất thì bạn chỉ dạy học và những kiến thức bạn có chỉ là lý thuyết.
Vì vậy khi đụng dự án thực tế thì bạn bị vấn đề, rồi càng bê lý thuyết cứng ngắt thì lại càng chết.
—
Bản chất công việc UXD về cơ bản chỉ có 3 bước: Think > Build > Test > Improve (tạm dịch: Ý tưởng > Xây dựng > Kiểm tra > Nâng cấp) và cứ vậy lặp đi lặp lại.
Cũng như bản chất công việc UX, cách trau dồi kiến thức của người làm UX cũng tương tự như vậy. Học cũng như bước đầu tiên (Think), không quan trọng là bạn đã học bao nhiêu trường, bao nhiêu khóa, đọc bao nhiêu quyển sách về UX, xem bao nhiêu bài nói chuyện của các chuyên gia trên YouTube,… tất cả chỉ là lý thuyết và đều vô nghĩa nếu không có các bước trải nghiệm thực tế còn lại. Đặc biệt là trong ngành này các kiến thức vừa học xong thì đã cũ.
Cho nên:
– Dành cho các bạn tự học, đừng chỉ suốt ngày tập trung đọc lý thuyết, hãy áp dụng ngay những kiến thức mình có được lên những sản phẩm mình đang làm việc. Nếu không có thì tạo ra những sản phẩm theo dạng hobby rồi ứng dụng. Một thử nghiệm fail giá trị gấp nhiều lần đọc 10 bài viết do người khác kể lại.
– Đặc biệt với những ai đi dạy hoặc đi chia sẻ, nên chia sẻ từ những kinh nghiệm thực tế chứ nếu chỉ ngồi đọc xong đi nói lại thì “tam sao thất bản” người nghe còn chết nặng hơn.
Có thể kể đến 5 nền tảng lớn nhất trên thế giới hiện nay là Microsoft, Oracle, Intel, SAP và Salesforce được định giá lên tới 911 tỷ USD. Trong khi đó các nền tảng tích hợp giữa giao dịch và sáng tạo như Apple, Google, Facebook, Amazon, Alibaba và XiaoMi có giá trị lên đến 2.000 tỷ USD.
Tại Việt Nam, các nền tảng thương mại đang phát triển mạnh. Cạnh tranh khốc liệt có nêu tại Báo cáo là nền tảng về e-logistics, tức mảng gọi xe, giao nhận, với các ‘anh tài’ như Grab, Go-Viet, FastGo, Be, Now, AhaMove… Các mảng khác như đời sống, sức khỏe, kinh doanh cũng có những đơn vị như Jupviec, eDoctor, Luxstay, Homedy, Chili…
***
Vừa qua TopDev đã công bố Báo cáo Vietnam IT Landscape 2019 đem đến cái nhìn toàn cảnh về các ứng dụng công nghệ góp phần thay đổi cuộc sống đến từ các công ty công nghệ tại Việt Nam. Những số liệu và thông tin dùng trong bản báo cáo này được cung cấp từ các chuyên gia, diễn giả, nhà nghiên cứu, doanh nghiệp tham gia các hoạt động employer branding, networking và marketing tại Việt Nam, cũng như những thông tin được lựa chọn và tổng hợp từ dữ liệu của TopDev.
Có thể nói nguyên lí REST và cấu trúc dữ liệu RESTful được biết đến rộng rãi trong giới lập trình web nói chung và lập trình ứng dụng nói riêng.
Có thể nói bản thân REST không phải là một loại công nghệ. Nó là phương thức tạo API với nguyên lý tổ chức nhất định. Những nguyên lý này nhằm hướng dẫn lập trình viên tạo môi trường xử lý API request được toàn diện.
Để hiểu rõ hơn về RESTful API ta sẽ đi lần lượt giải thích các khái niệm API, REST hay RESTful.
RESTful API là một tiêu chuẩn dùng trong việc thiết kế API cho các ứng dụng web (thiết kế Web services) để tiện cho việc quản lý các resource. Nó chú trọng vào tài nguyên hệ thống (tệp văn bản, ảnh, âm thanh, video, hoặc dữ liệu động…), bao gồm các trạng thái tài nguyên được định dạng và được truyền tải qua HTTP.
API (Application Programming Interface) là một tập các quy tắc và cơ chế mà theo đó, một ứng dụng hay một thành phần sẽ tương tác với một ứng dụng hay thành phần khác. API có thể trả về dữ liệu mà bạn cần cho ứng dụng của mình ở những kiểu dữ liệu phổ biến như JSON hay XML.
REST (REpresentational State Transfer) là một dạng chuyển đổi cấu trúc dữ liệu, một kiểu kiến trúc để viết API. Nó sử dụng phương thức HTTP đơn giản để tạo cho giao tiếp giữa các máy. Vì vậy, thay vì sử dụng một URL cho việc xử lý một số thông tin người dùng, REST gửi một yêu cầu HTTP như GET, POST, DELETE, vv đến một URL để xử lý dữ liệu.
RESTful API là một tiêu chuẩn dùng trong việc thiết kế các API cho các ứng dụng web để quản lý các resource. RESTful là một trong những kiểu thiết kế API được sử dụng phổ biến ngày nay để cho các ứng dụng (web, mobile…) khác nhau giao tiếp với nhau.
Chức năng quan trọng nhất của REST là quy định cách sử dụng các HTTP method (như GET, POST, PUT, DELETE…) và cách định dạng các URL cho ứng dụng web để quản các resource. RESTful không quy định logic code ứng dụng và không giới hạn bởi ngôn ngữ lập trình ứng dụng, bất kỳ ngôn ngữ hoặc framework nào cũng có thể sử dụng để thiết kế một RESTful API.
RESTful hoạt động như thế nào?
REST hoạt động chủ yếu dựa vào giao thức HTTP. Các hoạt động cơ bản nêu trên sẽ sử dụng những phương thức HTTP riêng.
GET (SELECT): Trả về một Resource hoặc một danh sách Resource.
POST (CREATE): Tạo mới một Resource.
PUT (UPDATE): Cập nhật thông tin cho Resource.
DELETE (DELETE): Xoá một Resource.
Những phương thức hay hoạt động này thường được gọi là CRUD tương ứng với Create, Read, Update, Delete – Tạo, Đọc, Sửa, Xóa.
Hiện tại đa số lập trình viên viết RESTful API giờ đây đều chọn JSON là format chính thức nhưng cũng có nhiều người chọn XML làm format, nói chung dùng thế nào cũng được miễn tiện và nhanh.
Authentication và dữ liệu trả về
RESTful API không sử dụng session và cookie, nó sử dụng một access_token với mỗi request. Dữ liệu trả về thường có cấu trúc như sau:
{
"data" : {
"id": "1",
"name": "TopDev"
}
}
Status code
Khi chúng ta request một API nào đó thường thì sẽ có vài status code để nhận biết sau:
200 OK – Trả về thành công cho những phương thức GET, PUT, PATCH hoặc DELETE.
201 Created – Trả về khi một Resouce vừa được tạo thành công.
204 No Content – Trả về khi Resource xoá thành công.
304 Not Modified – Client có thể sử dụng dữ liệu cache.
400 Bad Request – Request không hợp lệ
401 Unauthorized – Request cần có auth.
403 Forbidden – bị từ chối không cho phép.
404 Not Found – Không tìm thấy resource từ URI
405 Method Not Allowed – Phương thức không cho phép với user hiện tại.
410 Gone – Resource không còn tồn tại, Version cũ đã không còn hỗ trợ.
415 Unsupported Media Type – Không hỗ trợ kiểu Resource này.
422 Unprocessable Entity – Dữ liệu không được xác thực
429 Too Many Requests – Request bị từ chối do bị giới hạn
Nên sử dụng Version
Luôn sử dụng version để khi bạn cần nâng cấp API mà vẫn hỗ trợ các API cũ.
Xây dựng API với Laravel
Lấy việc xây dựng api trên Laravel để làm ví dụ, trước khi đi vào ta tổng quan về Http Request.
HTTP Request
HTTP request có tất cả 9 loại method , 2 loại được sử dụng phổ biến nhất là GET và POST
GET: được sử dụng để lấy thông tin từ server theo URI đã cung cấp.
HEAD: giống với GET nhưng response trả về không có body, chỉ có header.
POST: gửi thông tin tới sever thông qua các biểu mẫu http.
PUT: ghi đè tất cả thông tin của đối tượng với những gì được gửi lên.
PATCH: ghi đè các thông tin được thay đổi của đối tượng.
DELETE: xóa tài nguyên trên server.
CONNECT: thiết lập một kết nối tới server theo URI.
OPTIONS: mô tả các tùy chọn giao tiếp cho resource.
TRACE: thực hiện một bài test loop – back theo đường dẫn đến resource.
RESTful Route
Viết Api thì sẽ khai báo router vào file routes/api.php thay vì sử dụng file routes/web.php. Các setting mặc cho file api.php trong laravel:
Url: những route được khai báo trong file này mặc định có prefix url là api (ví dụ: topdev.vn/api/products)
Middleware: mặc định sẽ được gán Middleware Group là api, trong file app/Http/Kernel sẽ thấy 2 middleware thuộc Middleware Group: api là throttle (giới hạn request / time) và bindings (model binding).
Có thể tùy chỉnh giá trị mặc định này trong method mapApiRoutes trong file app/Providers/RouteServiceProvider.php
Tạo các route để thực hiện các thao tác như CRUD (Create, Read, Update, Delete):
// Lấy list sản phẩm
Route::get('products', 'Api\ProductController@index')->name('products.index');
// Lấy detail sản phẩm theo id
Route::get('products/{id}', 'Api\ProductController@show')->name('products.show');
// Add sản phẩm
Route::post('products', 'Api\ProductController@store')->name('products.store');
// Update info sản phẩm theo id
# Sử dụng put nếu update toàn bộ các field
Route::put('products/{id}', 'Api\ProductController@update')->name('products.update');
# Sử dụng patch nếu update 1 vài field
Route::patch('products/{id}', 'Api\ProductController@update')->name('products.update');
// Xóa sản phẩm theo id
Route::delete('products/{id}', 'Api\ProductController@destroy')->name('products.destroy');
Mặc định route đã được gán middleware bindings, nếu muốn sử dụng model binding trong controller thì chúng ta sửa lại tham số trong route như sau:
Ngoài ra trong laravel cũng hỗ trợ chúng ta 1 cách khai báo ngắn gọn hơn:
//Nếu không muốn sử dụng toàn bộ method trong apiResource mọi người có thể chỉ định sử dụng 1 vài method bằng hàm only
Route::apiResource('products', 'Api\ProductController')->only(['index', 'show']);
//Hoặc nếu muốn loại bỏ đi 1 số method không dùng thì có thể sử dụng hàm except
Route::apiResource('products', 'Api\ProductController')->except(['show', 'update']);
Resource Controllers
Tương ứng với các Route RESTful đã khai báo ở trên, đặc biệt nếu dùng method apiResource thì laravel cũng hỗ trợ các method xử lí tương ứng trong controller.
Để tạo ra Resource Controllers chúng ta chạy lệnh sau
File ProductController tạo ra sẽ như sau<?php
namespace App\Http\Controllers\Api;
use Illuminate\Http\Request;
use App\Http\Controllers\Controller;
class ProductController extends Controller
{
/**
* Display a listing of the resource.
*
* @return \Illuminate\Http\Response
*/
public function index()
{
//
}
/**
* Store a newly created resource in storage.
*
* @param \Illuminate\Http\Request $request
* @return \Illuminate\Http\Response
*/
public function store(Request $request)
{
//
}
/**
* Display the specified resource.
*
* @param int $id
* @return \Illuminate\Http\Response
*/
public function show($id)
{
//
}
/**
* Update the specified resource in storage.
*
* @param \Illuminate\Http\Request $request
* @param int $id
* @return \Illuminate\Http\Response
*/
public function update(Request $request, $id)
{
//
}
/**
* Remove the specified resource from storage.
*
* @param int $id
* @return \Illuminate\Http\Response
*/
public function destroy($id)
{
//
}
}
Ngoài ra nếu muốn sử dụng model binding khi tạo Resource Controllers thì dùng lệnh bên dưới
File ProductController tạo ra sẽ như sau, chúng ta để ý tham số của các method show, update, destroy sẽ thay đổi 1 chút.
<?php
namespace App\Http\Controllers\Api;
use App\Models\Product;
use Illuminate\Http\Request;
use App\Http\Controllers\Controller;
class ProductController extends Controller
{
/**
* Display a listing of the resource.
*
* @return \Illuminate\Http\Response
*/
public function index()
{
//
}
/**
* Store a newly created resource in storage.
*
* @param \Illuminate\Http\Request $request
* @return \Illuminate\Http\Response
*/
public function store(Request $request)
{
//
}
/**
* Display the specified resource.
*
* @param \App\Models\Product $product
* @return \Illuminate\Http\Response
*/
public function show(Product $product)
{
//
}
/**
* Update the specified resource in storage.
*
* @param \Illuminate\Http\Request $request
* @param \App\Models\Product $product
* @return \Illuminate\Http\Response
*/
public function update(Request $request, Product $product)
{
//
}
/**
* Remove the specified resource from storage.
*
* @param \App\Models\Product $product
* @return \Illuminate\Http\Response
*/
public function destroy(Product $product)
{
//
}
}
Demo 1 đoạn code đơn giản trong controller kết hợp với model binding và route apiResource khi xây dựng API:
<?php
namespace App\Http\Controllers\Api;
use App\Http\Controllers\Controller;
use App\Models\Product;
use Illuminate\Http\Request;
class ProductController extends Controller
{
/**
* Display a listing of the resource.
*
* @return Product[]|\Illuminate\Database\Eloquent\Collection
*/
public function index()
{
return Product::all();
}
/**
* Store a newly created resource in storage.
*
* @param Request $request
* @return Product|\Illuminate\Database\Eloquent\Model
*/
public function store(Request $request)
{
return Product::create($request->all());
}
/**
* Display the specified resource.
*
* @param Product $product
* @return Product
*/
public function show(Product $product)
{
return $product;
}
/**
* Update the specified resource in storage.
*
* @param Request $request
* @param Product $product
* @return bool
*/
public function update(Request $request, Product $product)
{
return $product->update($request->all());
}
/**
* Remove the specified resource from storage.
*
* @param Product $product
* @throws \Exception
*/
public function destroy(Product $product)
{
$product->delete();
}
}
Mặc định khi sử dụng route apiResource thì dữ liệu trả về sẽ tự động được chuyển sang kiểu JSON và sẽ có status tương ứng nên chỉ cần return dữ liệu ra là được.
Còn nếu muốn tùy biến status trả về thì có thể tham khảo cách phía dưới có sử dụng class Illuminate\Http\Response để lấy status thay vì fix giá trị vào ví dụ như HTTP_OK tương ứng sẽ là 200
<?php
namespace App\Http\Controllers;
use App\Models\Product;
use Illuminate\Http\Request;
use Illuminate\Http\Response;
class ProductController extends Controller
{
/**
* Display a listing of the resource.
*
* @return \Illuminate\Http\JsonResponse
*/
public function index()
{
$products = Product::all();
return response()->json($products, Response::HTTP_OK);
}
}
Eloquent Resources
Khi xây dựng API, bạn có thể cần transform dữ liệu từ controller trước khi trả về cho người dùng ứng dụng của bạn, laravel cũng đã hỗ trợ điều này với Eloquent Resources
Để tạo ra 1 class chuyển đổi chúng ta chạy lệnh sau
php artisan make:resource Product
File app/Http/Resources/Product.php sẽ có nội dung như sau
<?php
namespace App\Http\Resources;
use Illuminate\Http\Resources\Json\JsonResource;
class Product extends JsonResource
{
/**
* Transform the resource into an array.
*
* @param \Illuminate\Http\Request $request
* @return array
*/
public function toArray($request)
{
return parent::toArray($request);
}
}
Mình sẽ tùy chỉnh dữ liệu trả về là chỉ có title và price
<?php
namespace App\Http\Resources;
use Illuminate\Http\Resources\Json\JsonResource;
class Product extends JsonResource{
/**
* Transform the resource into an array.
*
* @param \Illuminate\Http\Request $request
* @return array
*/
public function toArray($request){
return [
'title' => $this->title,
'price' => $this->price,
];
}
}
Ở controller thì mình sẽ sửa lại như sau
<?php
namespace App\Http\Controllers\Api;
use App\Http\Controllers\Controller;
use App\Models\Product;
use Illuminate\Http\Request;
use App\Http\Resources\Product as ProductResource;
class ProductController extends Controller{
/**
* Display a listing of the resource.
*
* @return Product[]|\Illuminate\Database\Eloquent\Collection
*/
public function index(){
$products = Product::all();
return ProductResource::collection($products);
}
/**
* Store a newly created resource in storage.
*
* @param Request $request
* @return Product|\Illuminate\Database\Eloquent\Model
*/
public function store(Request $request){
$product = Product::create($request->all());
return new ProductResource($product);
}
/**
* Display the specified resource.
*
* @param Product $product
* @return Product
*/
public function show(Product $product){
return new ProductResource($product);
}
/**
* Update the specified resource in storage.
*
* @param Request $request
* @param Product $product
* @return bool
*/
public function update(Request $request, Product $product){
return $product->update($request->all());
}
/**
* Remove the specified resource from storage.
*
* @param Product $product
* @throws \Exception
*/
public function destroy(Product $product){
$product->delete();
}
}
Ngoài giới hạn dữ liệu trả về như title hay price, laravel cũng hỗ trợ rất nhiều thứ như thêm relationships, data …, mọi người có thể đọc thêm docs trên Laravel.
Authorization
Hiện tại có 3 cơ chế Authorize chính:
HTTP Basic
JSON Web Token (JWT)
OAuth2
Tùy thuộc vào service của bạn, mà hãy chọn loại Authorize có mức độ phù hợp, cố gắng giữ nó càng đơn giản càng tốt.
Ai cũng biết việc viết API docs là cần thiết, tuy nhiên để có một API docs hoàn chỉnh cũng tiêu tốn khá nhiều thời gian. Nhất là trong lúc dự án gấp rút thì mọi người thường chỉ để API docs ở mức siêu cơ bản. Tham khảo thêm cách viết API Document.
API document là một phần tương tự như Unit Test vậy – lấy ngắn để nuôi dài.
Nếu không được chăm sóc kỹ, thì đến lúc maintain hoặc thay đổi spec thì hậu quả sẽ rất thảm khốc, dưới đây là một số lưu ý lúc viết docs:
Mô tả đầy đủ về params request: gồm những params nào, datatype, require hay optional.
Nên đưa ra các ví dụ về HTTP requests và responses với data chuẩn.
Cập nhật Docs thường xuyên, để sát nhất với API có bất cứ thay đổi gì.
Format, cú pháp cần phải nhất quán, mô tả rõ ràng, chính xác.
Tham khảo thêm các việc làm API lương cao hấp dẫn tại đây
Một thương hiệu công ty mạnh (Branding) sẽ là nền tảng quan trọng đầu tiên để xây dựng một thương hiệu nhà tuyển dụng (Employer Branding) mạnh. Ai mà chả muốn làm việc cho một công ty có tên tuổi!
Tuy nhiên một thương hiệu công ty mạnh mới chỉ là nền tảng chứ chưa phải quyết định tất cả đến khả năng thành công của một thương hiệu nhà tuyển dụng hấp dẫn (về lâu dài). Khách hàng của thương hiệu nhà tuyển dụng là những người làm thuê (employee).
Họ rất khác với khách hàng mua sản phẩm của công ty. Ngoài uy tín của thương hiệu công ty họ còn nhiều mong muốn và nhu cầu khác nhau. Một trong những thứ quan trọng nhất đó là ai là sếp trực tiếp của họ. Trên thực tế có nhiều cá nhân chọn nơi làm bến đỗ sự nghiệp của mình vì tên tuổi của CEO/ Manager hơn là tên tuổi của công ty. Ngược lại cũng có nhiều người không bỏ công ty để ra đi. Họ bỏ người lãnh đạo mà họ cho là không đủ tâm tài hoặc nhiều khi đơn giản là không phù hợp.
Các hoạt động này với mục tiêu khác hẳn với một chiến dịch tuyển dụng thông thường (đem về hồ sơ) là đem về nhận diện, top of mind, trust, transparency… để sau này khi có ý định thay đổi công việc, họ sẽ nghĩ đến công ty đó đầu tiên bởi những ấn tượng về văn hóa công ty cũng như những công nghệ mà công ty đó đang thực hiện.
Ngoài ra, việc tăng cường các lớp senior/ tech lead cởi mở hơn trong hoạt động Tech Sharing trong nội bộ & các sự kiện công nghệ cũng đang được nhiều công ty tiến hành với cường độ thường xuyên hơn có nêu tại Báo cáo như: Tiki, Sun* Inc, Knorex, Shopback, LINE, Grab,…
***
Vừa qua TopDev đã công bố Báo cáo Vietnam IT Landscape đem đến cái nhìn toàn cảnh về các ứng dụng công nghệ góp phần thay đổi cuộc sống đến từ các công ty công nghệ tại Việt Nam. Những số liệu và thông tin dùng trong bản báo cáo này được cung cấp từ các chuyên gia, diễn giả, nhà nghiên cứu, doanh nghiệp tham gia các hoạt động employer branding, networking và marketing tại Việt Nam, cũng như những thông tin được lựa chọn và tổng hợp từ dữ liệu của TopDev.
Xamarin được xây dựng vào tháng 5 năm 2011 bởi các kỹ sư đã tạo ra Mono, Mono cho Android và MonoTouch, mục đích là triển khai chạy ứng dụng trên nhiều nền tảng của Common Language Infrastructure (CLI) và Common Language Specifications ( Thường được gọi là Microsoft .NET).
Dựa trên ngôn ngữ C#, các nhà phát triển có thể sử dụng các công cụ Xamarin để viết các ứng dụng Android, iOS trên cùng một code project.
Là 1 nền tảng lập trình ứng dụng di động cross-platform (có nghĩa là code một lúc có thể chạy trên được cả iOS lẫn Android), Xamarin có những đặc điểm riêng biệt, hiếm có so với các frameworks hiện tại trên thị trường khi mà khả năng native access và trải nghiệm người dùng native vẫn đang bị đặt nghi vấn.
Tái sử dụng code tại nhiều chỗ, giảm thời gian làm ứng dụng trên nhiều nền tảng
Xamarin sử dụng ngôn ngữ C# cùng với framework.Net để tạo ra ứng dụng cho mọi nền tảng bất kì. Khi bạn tạo ứng dụng di động trên Xamarin, bạn sử dụng cùng ngôn ngữ là C#, API và cấu trúc dữ liệu hay logic của ứng dụng nên thường là 90% code chức năng có thể được dùng trên iOS và Android.
Qua đó có thể giảm đáng kể chi phí và thời gian phát triển ứng dụng di động cho 2 nền tảng phổ biến nhất. Ngoài ra có nhiều IDE hỗ trợ rất tốt mà miễn phí với nó như Xamarin IDE (dành cho Mac) hay Visual Studio (dành Windows).
Performance gần như native
Các số liệu performances là tương đương khi so sánh với các số liệu performance của Java cho Android và Objective-C hoặc Swift cho ứng dụng phát triển ứng dụng iOS native. Hơn thế nữa, performance của Xamarin liên tục được cải thiện để phù hợp hoàn toàn với tiêu chuẩn của lập trình native.
Ngoài ra, nền tảng Xamarin cung cấp thêm các giải pháp để testing và theo dõi hoạt động của ứng dụng. Xamarin Test Cloud kết hợp với công cụ Xamarin Test Recorder cho phép bạn chạy các UI test tự động và xác định các vấn đề về performance trước khi ứng dụng release. Tuy nhiên, dịch vụ này có tính phí nhưng cũng đáng lưu tâm.
Hỗ trợ tất cả phần cứng
Với Xamarin, giải pháp của bạn sẽ giúp cách chức năng của ứng dụng đạt được native-level, loại trừ tất cả vấn đề tương thích với phần cứng, sử dụng plugins và APIs đặc biệt để làm việc với các chức năng thiết bị thông thường đa nền tảng. Ngoài khả năng truy cập vào API riêng biệt cho mỗi nền tảng, Xamarin còn hỗ trợ liên kết với thư viện native. Từ đó, functionality được tối ưu hóa và đạt được mức độ native tốt hơn với ít chi phí hơn.
Nhiều thư viện hỗ trợ làm ứng dụng cực nhanh có sẵn
Component Xamarin cung cấp đến hàng ngàn UI controls tùy chỉnh, các charts, biểu đồ, themes đa dạng và các chức năng mạnh mẽ khác có thể được thêm vào ứng dụng chỉ với vài cú click. Điều này bao gồm quá trình xử lý payment built-in (như Stripe chẳng hạn), tích hợp Beacons và các thiết bị di động, các services notification box push, giải pháp lưu trữ đám mây, các tính năng streaming multimedia và hơn thế nữa.
Hỗ trợ chậm các updates mới nhất của các hệ điều hành mobile
Điều này phụ thuộc hoàn toàn vào đội ngũ developer của Xamarin. Khi iOS hoặc Android tung ra các phiên bản mới, phải mất một khoảng thời gian để thực hiện những thay đổi hay đưa vào một plugins mới, v.v.. Mặc dù Xamarin khẳng định sẽ hỗ trợ cùng lúc với những cập nhật mới nhất nhưng vẫn có những thời điểm bị trì hoãn.
Giới hạn truy cập vào thư viện mã nguồn mở
Native development giúp thói quen sử dụng công nghệ mã nguồn mở trở nên quen thuộc, rộng rãi hơn. Với Xamarin, cả developer đều phải sử dụng duy nhất môt component được cung cấp bởi Xamarin và một số mã nguồn mở .Net.
Trong khi native development có rất nhiều lựa chọn thư viện opensource cho ứng dụng phát triển điện thoại Android và iOS. Rất tiếc là vẫn còn nhiều native library ngon vẫn chưa hỗ trợ cho Xamarin.
Vấn đề hệ sinh thái của Xamarin
Dĩ nhiên, cộng đồng Xamarin ít hơn so với cộng đồng của iOS hay Android nên để tìm kiếm được 1 developer Xamarin có kinh nghiệm là chuyện không dễ dàng gì dù Xamarin là nền tảng được phát triển nhờ sự hỗ trợ từ Microsoft.
Theo nhiều nguồn, cộng đồng Xamarin chiếm 10% cộng động lập trình mobile toàn cầu.
Apps thực hiện chậm hơn và yêu cầu nhiều dung lượng hơn trên thiết bị
Ứng dụng Xamarin lớn hơn, nặng hơn so với ứng dụng native. So sánh với ứng dụng native nó chiếm nhiều hơn vài Mb so với Java/Objective C tương ứng. kích thước của một ứng dụng code bằng xamarin là 5Mb, trong khi code bằng Objective C chỉ chiếm 200 Kb. Càng sử dụng nhiều API, càng nhiều lưu trữ bị chiếm trên thiết bị.
Tổng kết
Nhiều developer đã sử dụng Xamarin như là một công cụ phát triển ứng dụng. Được support bởi Microsoft, bạn sẽ an tâm hơn khi đào sâu nghiên cứu cũng như học cách làm ứng dụng nhanh hơn. Ngôn ngữ C# lại dễ học và dễ hiểu, làm web hay app để trở nên dễ dàng hơn bao giờ hết.
Hiện nay có rất nhiều các nền tảng Hydrid để hỗ trợ làm app trên nhiều nền tảng như React Native (Sử dụng Javascript) support bởi Facebook, Flutter (Sử dụng ngôn ngữ Dart, xem thêm Flutter là gì?) được support bởi Google…nên bạn chắc chắn sẽ đắng đo lựa chọn nên dùng nền tảng nào.
Lời khuyên của TopDev là nếu bạn chuyên sâu vào ngôn ngữ lập trình nào thì hãy chọn nền tảng đó mà base. Và hybrid chỉ thật sự phù hợp với các ứng dụng đơn giản, không có quá nặng về UI hoặc app có độ lớn vừa phải. Khi gặp ứng dụng đòi hỏi sự phức tạp, hãy cân nhắc native bạn nhé.
JSON là viết tắt của JavaScript Object Notation, là một kiểu định dạng dữ liệu tuân theo một quy luật nhất định mà hầu hết các ngôn ngữ lập trình hiện nay đều có thể đọc được. JSON là một tiêu chuẩn mở để trao đổi dữ liệu trên web.
Định nghĩa
Định dạng JSON sử dụng các cặp key – value để dữ liệu sử dụng. Nó hỗ trợ các cấu trúc dữ liệu như đối tượng và mảng. Ví dụ một tập tin có tên topdev_info.json với nội dung như ở dưới đây sử dụng format kiểu JSON để lưu trữ thông tin:
{
"name" : "TopDev",
"title" : "Việc làm IT cho Top Developers",
"description" : "là hệ sinh thái bao gồm cộng đồng các Top Developers."
}
Ta có thể thấy cú pháp của JSON có 2 phần đó là key và value:
Chuỗi JSON được bao lại bởi dấu ngoặc nhọn {}
Các key, valuecủa JSON bắt buộc phải đặt trong dấu nháy kép {“}, nếu bạn đặt nó trong dấu nháy đơn thì đây không phải là một chuỗi JSON đúng chuẩn. Nếu trường hợp trong value của bạn có chứa dấu nháy kép " thì hãy dùng dấu (\) để đặt trước nó, ví dụ \"json là gì\".
Nếu có nhiều dữ liệu thì dùng dấu phẩy , để ngăn cách.
Các key của JSON bạn nên đặt chữ cái không dấu hoặc số, dấu _ và không có khoảng trắng., ký tự đầu tiên không nên đặt là số.
File json có thể được lưu với bất kỳ phần mở rộng nào, tuy nhiên thông thường thì nó được lưu dưới phần mở rộng là .json hoặc .js.
JSON ban đầu được phát triển để dành phục vụ cho ứng dụng viết bằng JavaScript. Tuy nhiên vì JSON là một định dạng dữ liệu nên nó có thể được sử dụng bởi bất cứ ngôn ngữ nào mà không bị giới hạn.
Giá trị key trong JSON có thể là chuỗi (string), số (numner), rỗng (null), mảng (array), hoặc đối tượng (object).
Object trong Json được thể hiện bằng dấu ngoặc nhọn {}. Khái niệm Object trong Json cũng khá tương đồng với Object trong Javascript. Tuy nhiên, Object trong Json vẫn có những giới hạn như:
Key: phải luôn nằm trong dấu ngoặc kép, không được phép là biến số.
Value: Chỉ cho phép các kiểu dữ liệu cơ bản: numbers, String, Booleans, arrays, objects, null. Không cho phép function, date, undefined.
Không cho phép dấy phẩy cuối cùng như Object trong Javascript.
Đó là khi bạn muốn lưu trữ dữ liệu đơn thuần dưới dạng metadata ở phía server. Chuỗi JSON sẽ được lưu vào database và sau đó khi cần dữ liệu thì sẽ được giải mã. Ví dụ với PHP, nó cung cấp các hàm liên quan đến JSON để mã hóa hoặc giải mã là json_encode và json_decode.
Một trường hợp khá phổ biến trong JavaScript mà dữ liệu được định dạng theo format JSON xuất hiện đó là trong các AJAX request.
Ví dụ bạn tạo tập tin topdev_info.json ở thư mục gốc của server (để khi request vào URL http://localhost/topdev_info.json thì server trả về nội dung của tập tin này) và sau đó bạn tạo một tập tin topdev_ajax.html với nội dung như sau:
Đoạn code trên sử dụng $.ajax() để gửi AJAX request lên server lấy về nội dung file topdev_info.json. Sau khi lấy về nội dung tập tin này thành công, dữ liệu sẽ được chuyển vào biến response.
Nếu bạn mở developer console của trình duyệt lên (nhấn phím F12) bạn sẽ thấy kiểu dữ liệu của biến response này được JavaScript object với các thuộc tính như name, title, decription.
Bài viết liên quan về JSON, tham khảo thêm ở đây nè:
Hy vọng với bài viết này bạn sẽ hiểu rõ hơn về JSON là gì cũng như các ứng dụng và cấu trúc của nó như thế nào. Đừng quên cập nhật thêm các nội dung mới hữu ích cho các Dever tại TopDev Blog nhé! Cảm ơn các bạn vì đã luôn ủng hộ chúng tớ.