Categories
AI

Software Builder & AI (Phần 1): Những sự xâm lấn đầu tiên

Status này dành cho những người thuộc “tộc” BUILDER, là tộc người mà luôn bị thôi thúc lúc nào cũng xây dựng một cái gì đó. Trong loạt bài “SOFTWARE BUILDER & AI” để mở màn năm 2025 với dòng sự kiện chính là AI này, mình chỉ đề cập đến một khu vực nhỏ xíu là BUILDER trong lĩnh vực phát triển phần mềm.

Trong thế giới phần mềm, người của tộc BUILDER thường có cái chức danh là Product Manager hoặc Product Owner, mà dân gian hay gọi là “Ông chủ” của phần mềm. Người này sẽ chịu trách nhiệm chính trong việc phát triển và hoàn thiện phần mềm theo đúng ý đồ ban đầu.

Trước đây, bản thân người của tộc BUILDER thường không tự thiết kế giao diện hoặc ngồi lập trình (code) các tính năng mà phải luôn hợp tác với người của tộc CODER (Ông code) và tộc DESIGNER (Bà thiết kế). Quá trình hợp tác giữa 3 tộc này chính là yếu tố quyết định cho tốc độ và chất lượng của phần mềm được tạo ra.

Suốt hàng ngàn năm qua, thế giới phần mềm vẫn luôn diễn ra như vậy. Thỉnh thoảng có 1 số ít người tộc BUILDER có khả năng lập trình và thiết kế, dẫn đến quá trình làm phần mềm diễn ra nhanh hơn. Tứng là một người như vậy, và 10 năm trước đây, việc có 3 khả năng này một lúc là một lợi thế rất lớn, mà giang hồ hay gán cho mấy tay này là “Nhà khởi nghiệp công nghệ”.

Tuy nhiên, thế giới phần mềm đã có một sự thay đổi kinh thiên động địa trong vài tuần trăng gần đây, đó là sự xuất hiện của AI và chúng ngày càng thông minh. Người của tộc BUILDER giờ đây đã có thể trang bị các năng lực của tộc CODER và DESIGNER chỉ với vài chục đôla / tháng và không còn quan tâm đến “tâm trạng” của 2 tộc kia khi hợp tác.

Hơn 1 tháng qua, Tứng đã tự trải nghiệm việc đưa AI vào quy trình làm phần mềm và thấy rằng mối đe doạ cho tộc CODER và DESIGNER là hoàn toàn có thật, và nếu người của hai tộc này không sớm trang bị & thích nghi với AI, để vượt lên những cá nhân yếu kém, lạc hậu thì không sớm thì muộn trong 1 vài năm tới sẽ bị thay thế bởi những người giỏi hơn, hoặc thậm chí đáng sợ hơn là bị người của tộc BUILDER thay thế.

Sau thời gian trải nghiệm thực chiến với AI thì Tứng rút ra có “2 kỹ năng cốt lõi” mà nếu các bạn thuộc tộc nào đi nữa, nếu được trang bị từ bây giờ thì sẽ khó mà bị thay thế. 2 kỹ năng này là gì và tại sao nó lại quan trọng như vậy, đón đọc ở bài tiếp theo trong loạt bài này nhé.

Categories
DevOps

System Design (Thiết kế hệ thống)

Trong bài chia sẻ về kiến trúc Microservices cho các bạn sinh viên tuần trước, mình có nói rằng ở công ty công nghệ thông thường thì có thể có hàng chục developer, nhưng chỉ có 1 hoặc 2 system designer (Nhà thiết kế hệ thống) và tất nhiên vị trí này nhìn chung sẽ được săn đón và bổng lộc cao hơn developer.

“Từ một developer trở thành một system designer mất bao lâu?” là câu hỏi mà một bạn sinh viên đã đặt ra cho Tuấn trong buổi chia sẻ này và thiết nghĩ đây là một câu hỏi hay và câu trả lời của mình sẽ giúp các bạn định hướng được chặn đường phát triển của một developer trong tương lai.

Một developer có thể có nhiều con đường phát triển sự nghiệp, trở thành một system designer là một lựa chọn không tệ. Hiện nay, bạn có thể khá dễ dàng để tuyển một developer, nhưng tuyển những vị trí system designer rất là khó, và thông thường ở những vị trí như CTO (giống Tứng) mới có skill này (flex tí ^^!).

Kiến thức của một system designer sẽ rất là dàn trải và đòi hỏi nghiên cứu, thử nghiệm không ngừng nghỉ vì số lượng những công nghệ mới sinh ra liên tục, phải phân tích, đánh giá, so sánh các công nghệ và tìm ra những công nghệ phù hợp với lộ trình phát triển của công ty và tốt nhất là đi lên từ một developer.

Cho nên để từ một developer trở thành một system designer thì cần khoảng 5 năm theo đuổi lĩnh vực này, am hiểu về cách hệ thống vận hành và các thành phần trong một hệ thống liên kết với nhau thế nào, cũng như điểm mạnh, điểm yếu của các thành phần trong tổng thể hệ thống.

Do đó, nếu muốn xây dựng một đội ngũ công nghệ, trước tiên bạn phải tìm system designer, đừng tìm developer nếu không muốn nhiều vấn đề nhức đầu về sau.

Liệu mở một lớp dạy về System Design dành cho developer thì có ai học không ta ?!!!

Categories
DevOps Miscellaneous

Ghi chép về Devops #1

Sau 2 tuần mò mẫm trong Google Cloud, PHP, Apache, Go, Angular … để hỗ trợ một ông bạn kiểm soát lại toàn bộ hệ thống cũ do team dev quăng bom để lại, thì thấy nếu sản phẩm tech hay đội code trong nhà của mấy sếp mà có một trong bảy triệu chứng dưới đây thì nên bắt đầu lo sợ là vừa, vì có thể một ngày nào đó lại inbox Tứng và hỏi thuốc giải.

Các ý tưởng này chỉ là góc nhìn cá nhân dựa trên đống shit mà Tứng ngụp lặn bữa giờ, mong ace đừng ném đá và kì thị:

🚩 – Không có CI/CD, code được pull trực tiếp trên production server thông qua Git và chỉnh sửa trực tiếp bằng tay (rồi không biết có bị quên push ngược lên repo hay không)
🚩 – Không có tài liệu cài đặt hệ thống
🚩 – Cấu hình như URL, Key, IP… được set cứng trong source code (Ví dụ các so sánh if … else, switch…case…) hoặc nằm rải rác ở rất nhiều file khác nhau
🚩 – Không có Load Balancer routing vào các server bên trong (Ví dụ Haproxy, Traefik, Cloud Load Balancer..)
🚩 – Không sử dụng Docker (hay công nghệ tương tự) hoặc thực hiện `docker build…` tại máy của cha nội dev hoặc trên server rồi push trực tiếp lên Registry
🚩 – Source code được đóng gói và publish công khai trên Docker Hub.
🚩 – Web server (Apache, Nginx..) tự handle các xử lý liên quan SSL Certificate

Hy vọng sau status này thì team DevOps của mấy sếp có một vài ngày làm việc bận rộn hoặc…bỏ của chạy lấy người.

Categories
Miscellaneous

New Year’s Resolution of 2024

Hi yo!! Thế là hết năm 2023 rồi, như mọi năm thì hôm nay cũng ngồi lại điểm một số sự kiện chính trong năm qua của mình cũng như đưa ra những dự định cho năm mới.

Cứ tưởng sau khi bị Covid hành hạ từ 2022 thì năm 2023 sẽ khá hơn nhưng không hề. Kết thúc đại dịch Covid kèm với những sự kiện lớn đã khiến 2023 trở thành một năm đầy khủng hoảng và khó khăn trên mọi mặt trận. Tuy nhiên, chỉ là công ty nhỏ nên cũng không bị ảnh hưởng quá lớn. Nếu dùng một từ để chỉ hình dung về 2023 của Tuấn thì đó là từ “TE TUA”.

2023 – Một năm “te tua”

Về làm ăn thì với sự chủ quan của một người chưa từng bị ảnh hưởng bởi khủng hoảng kinh tế, lần đầu tiên bị hụt dòng tiền và kéo theo rất nhiều hệ luỵ liên quan đến thiếu tiền mặt và phải giảm nhân sự. Bên cạnh đó, nguồn khách hàng sụt giảm mạnh khiến cho việc tồn tại của công ty đôi khi trở nên khó khăn và phải thay đổi hoàn toàn kế hoạch kinh doanh nửa năm 2023 và cho đến 2024 để xử lý.

Có một may mắn là 2023 đã kịp đẩy mạnh outsourcing, tuy không quá nhiều dự án nhưng với 3 dự án cũng bù đắp phần nào doanh số do mảng cloud mang lại.

2023 cũng là năm đóng hoàn toàn mảng SaaS (Teamcrop, Basecrop & Movecrop) để tập trung cho dự án thử nghiệm Cropany. Tuy nhiên, do nhiều nguyên nhân khách quan và chủ quan khiến cho dự án này buộc phải kết thúc thử nghiệm và chờ thay đổi mới.

Với sự giảm quá nhanh về mặt doanh thu và hoàn toàn không có dòng tiền để xoay sở, khiến cho nhân sự không những không mở rộng mà còn phải thu hẹp, đây có thể coi là thất bại lớn của năm.

Về gia đình thì với áp lực lớn của việc làm ăn nên cũng không giúp ích nhiều cho gia đình và thời lượng OT cũng tăng hơn để đáp ứng kịp nhu cầu giảm nhân sự.

Về bạn bè thì thật may mắn luôn có những người trong giai đoạn này không ngại san sẻ những khó khăn, đúng là những người ân nhân của Tuấn và hy vọng trong tương lai sẽ có cơ hội báo đáp. Giai đoạn này chịu khó “lăn xả” hơn nên cũng có nhiều người bạn mới và mở rộng kết nối hơn trước đó và bớt hướng nội lại.

Về cá nhân thì không đọc nhiều sách như trước vì tâm trạng hoàn toàn không thể tập trung cho việc đọc mà chỉ dành tâm trí cho lập trình, thiết kế hệ thống và…kiếm tiền. Áp dụng và học được nhiều kỹ thuật mới cho xây dựng Headless Commerce cũng là một thành tựu bản thân trong năm nay.

Về mặt sức khoẻ thì đã làm được một việc mà suốt 10 năm qua chưa làm được đó là trong 4 tháng cuối năm 2023 đã cố gắng ăn kiêng, thể dục thể thao và đã giảm gần 8kg, thể trạng trở nên khoẻ khoắn hơn để code sáng đêm.

Kế hoạch 2024

Một khi đã thấy được các khó khăn và hiện trạng thì kế hoạch 2024 rất rõ ràng là khôi phục hoàn toàn tình trạng kinh doanh và duy trì thể trạng, sức khoẻ.

  • Triển khai 5 dự án outsourcing
  • Kết thúc thử nghiệm và ra mắt dự án Headless Ecommerce
  • Đọc 20 cuốn sách
  • Đi du lịch 2 lần
  • Giảm thêm 4Kg
  • Chia sẻ 3 lần tại các hội thảo Offline về công nghệ
  • Tăng 100% nhân sự.

Biết là mục tiêu đề ra để theo đuổi và có thể khó thực hiện, tuy nhiên có còn hơn không có mục tiêu và với những mục tiêu kể trên mình tin là sẽ thực hiện được.

Tàn dư của 2023 có thể sẽ còn kéo dài đến 2024, tuy nhiên chúng ta cần đón nhận một năm 2024 đầy hứng khởi và lạc quan để hoàn tất những dự định và mục tiêu của mình trong năm mới. Chúc các bạn tràn đầy năng lượng và sức khoẻ trong 2024.

HAPPY NEW YEAR!

Categories
DevOps

WEBSOCKET: TỪ SOCKETIO ĐẾN SOKETI

Khoảng 8 năm trước, từ lúc bỏ mô hình Server Side Rendering (jQuery, Ajax…) và bắt đầu xây dựng hệ thống dựa trên mô hình Microservices & Single Page App (SPA) và sử dụng hoàn toàn frontend bằng Reactjs thì cũng là lúc bắt đầu chơi với WebSocket cho các tính năng tương tác hai chiều (Client < — > Server) theo thời gian thực.

Hoạt động của WebSocket khá đơn giản: trình duyệt kết nối tới một Socket server, lắng nghe trên 1 (hoặc nhiều) channel mình khai báo rồi…chờ message trên channel đó. Server muốn gửi dữ liệu cho trình duyệt của user thì chỉ cần đẩy message vào channel này, trình duyệt sẽ tự động nhận message và xử lý (ví dụ như hiển thị thông báo trên trình duyệt hoặc một hành động khác.)

Nhiều người khi nghe nói đến Websocket thì chỉ nghĩ đến các tính năng realtime chat, nhưng Websocket có nhiều ứng dụng, trong đó mình sử dụng nhiều nhất cho 3 chỗ trên trình duyệt: Nhận thông báo mới (Notification), Cập nhật dữ liệu cache trên trình duyệt (Realtime Data Update) và Trạng thái online của user (Online Presence).

Các phần mềm hỗ trợ WebSocket Server

Thời bấy giờ không có nhiều lựa chọn, ứng cử viên sáng giá nhất là Socket.IO: Open Source – Miễn phí, tự cài đặt trên server riêng và Pusher: Cloud, không cần cài đặt gì hết và trả phí.

Socket.IO thì hầu như không có nhiều đồ chơi, ngoài việc chỉ hỗ trợ trình duyệt kết nối socket tới server, không có cơ chế xác thực (Authentication), muốn làm gì thì phải chủ động code tính năng hết. Do mình làm ứng dụng cho dự án SaaS và multi-tenant nên khối lượng code viết thêm nếu làm trên SocketIO là quá lớn nên buộc phải tìm giải pháp khác, và lúc này Pusher đã xuất hiện.

Pusher cung cấp cơ chế WebSocket với nhiều tính năng, trong đó có 2 tính năng nổi bật nhất là hỗ trợ Authentication xác thực user kết nối và Presence Channel để biết ai đang online/offline. Ngoài ra, Pusher còn cung cấp các thư viện tích hợp cho cả Javascript (gắn ở trình duyệt) và PHP (gắn ở server) để xác thực và trao đổi dữ liệu realtime giữa client và server được đơn giản và nhanh chóng, rút ngắn thời gian phát triển.

Có một bất lợi duy nhất của Pusher là…chi phí. Do đặc thù của một hệ thống Realtime là số lượng kết nối thường xuyên đến socket server, nên chi phí tính dựa vào số lượng kết nối. Sau khi đánh giá thì với chi phí của Pusher so với những lợi ích nó mang lại thì quyết định chọn Pusher.

Thay thế Pusher bằng Soketi

Mười ngày trước, nằm trong tuần lễ cải tổ hệ thống, trong đó có hạng mục nâng cấp phân hệ Pusher sau một thời gian dài sử dụng, thì thấy chi phí hiện tại không ổn nếu scale lên vài ngàn socket connection dựa trên Pusher, cũng như áp dụng cho các khách hàng outsourcing.

Thật may mắn là đã tìm ra Soketi, một open source cài đặt trên server của mình và cung cấp các tính năng gần như tương tự của Pusher. Và đặc biệt quan trọng là tương thích hoàn toàn với các thư viện kết nối ở phía Javascript và PHP, tức là không phải thay đổi cơ chế kết nối và lắng nghe message, chỉ cần cài Soketi (có hỗ trợ docker), sau đó thì config trỏ lại kết nối đến Soketi Websocket server vừa cài là xong.

Sau một tuần triển khai lên các môi trường dev và production cho các dự án thì thấy hoàn toàn ổn định, kết quả này cũng là cảm hứng cho bài viết chia sẻ công nghệ này. Hy vọng anh chị em có một hệ thống Websocket ngon, bổ rẻ để xây dựng các tính năng realtime cho môi trường web.

Categories
Technology

Vũ trụ Nextjs và Headless CMS

Sau nhiều ngày chờ đợi để xem NextJS có ra bản 13.5 hay không thì cũng không chịu được nữa (nằm ở v13.4 đã gần 3 tháng) và đành khởi công dự án xây dựng Public CMS Framework (hay nói kiểu nhà quê là làm cái website) với phiên bản NextJS 13.4.12.

Server Side Rendering (SSR) với PHP

Ở #Cropcom, mỗi một Public CMS Framework được xây dựng thì xác định tối thiểu phải 5 năm sau mới thay đổi công nghệ nên việc lựa chọn công nghệ nền ban đầu ảnh hưởng rất lớn đến trải nghiệm phát triển tính năng của team, cũng như phải “chịu đựng” trong quá trình xây dựng tính năng nếu lỡ nó lạc hậu hoặc team đó bỏ rơi không phát triển tiếp công nghệ nền.

Nếu bạn quan tâm thì Public CMS Framework gần nhất của công ty do Tuấn xây dựng là dựa trên PHP 7, sử dụng một phần của Symfony HTTPFoundation để xây dựng core, sử dụng Smarty cho tầng View (HTML, CSS..), còn layer Model & Controller thì kết nối đến hệ thống microservice theo cơ chế Headless CMS. Public CMS này thực ra hiện tại vẫn ổn vì nó tương thích hoàn toàn với khả năng Server Side Rendering (SSR) để tận dụng tối đa khả năng onsite SEO.

NextJS cho SSR & CSR trong tương lai

Hướng cũ này có một bất lợi duy nhất là, sẽ khó khăn nếu tiếp cận xây dựng các tính năng không cần SEO (sau màn hình đăng nhập) như thông tin tài khoản, các tính năng sau khi đăng nhập (submit này nọ, tương tác với thành viên khác…). Lỡ theo kiến trúc này nên phần lớn các tính năng đòi hỏi thuần Client Side Rendering (CSR) toàn phải xài jQuery và code chay, rất khó mở rộng theo nhánh này. Mà ngày nay, làm gì có website nào chỉ thuẩn SEO content, nếu vậy xài WordPress cho rồi, viết framework đồ chi.

Nếu muốn viết lại Framework mới cho Public CMS thì phải giải quyết được 2 bài toán là cần có SSR, hỗ trợ được các công nghệ CSR như Reactjs…để vừa đạt hiệu quả làm SEO, vừa hỗ trợ team dev phát triển tính năng một cách hiệu quả, nhanh chóng. Thế là đến với NextJS. Hiện tại sau hơn 4 năm chạy với Nextjs (từ nextjs 8.x đến nay thì phiên bản 13.4 được coi là siêu ổn để giải quyết 2 vấn đề lớn mà Tuấn cần giải quyết cho Public CMS của mình.

Lựa chọn UI Component Library

Tuy nhiên, sau khi trào lưu di dời sang Nextjs thì sẽ phát sinh 1 vấn đề khác là không có một bộ Component UI Library hoàn hảo. Và vấn đề này luôn là mối quan ngại khi xây dựng CMS với Nextjs bởi chưa có “cái nào” mà mình đánh giá là xài được. Radix UI thì có vẻ phức tạp, ngôi sao mới nổi Shadcn thì tạo ra các giao diện không mấy thân thiện với người dùng bình thường nên chủ yếu shadcn để xây các sản phẩm hơi hướng tinh giản và tech savy. Chưa kể nhiều UI Lib không tương thích với React Server Component.

Dường như vũ trụ Nextjs đã lắng nghe, và sau 1 ngày xây dựng thì dự án NextUI (không liên quan đến Vercel) hôm qua đã ra mắt phiên bản 2.0 với RẤT nhiều cải tiến mà sẽ dùng tốt cho NextJS 13 (dùng App Router). Việc thấy được sự ra mắt của NextUI 2.0 chính là cảm hứng cho mình chia sẻ bài viết này cũng như mọi người có thể hình dung xây dựng một Public CMS cần có nhiều yếu tố cân nhắc vì tính dài hạn và hướng người dùng (UX) & hướng dev (DX).

NextUI Website: https://nextui.org/

Trong tương lai nếu có lib nào xịn hơn thì sẽ xem xét và cân nhắc, nhưng cho đến hôm nay thì mình thấy NextUI là chân ái và sẽ apply cùng với TailwindCSS cho toàn bộ các design của CMS.

Categories
DevOps Technology

CHỌN CX HAY DX?

Dạo gần đây trên twitter có rất nhiều chỉ trích từ cộng đồng làm frontend về việc bản #Nextjs 13.4 cho tới 13.6 có trải nghiệm compile ở máy rất tệ khi sử dụng kiến trúc mới là App Router. Thời gian mỗi lần hot reload tính bằng giây và bản thân Tuấn đang phát triển cho hệ thống IDP của #cropany cũng thấy trải nghiệm tương tự, gần đây mỗi lần nhấn lưu là banh xác, chờ vài giây và compile vài ngàn module.

Việc này ảnh hưởng lớn đến #DX – hay gọi dễ hiểu là Trải nghiệm của lập trình viên (Developer Experience), cái được cộng đồng đánh giá công ty Vercel (hay dự án Nextjs) là một công ty có DX rất tốt, riêng mình nói về vụ DX thì Vercel là dẫn đầu thị trường thì nay lại bị chê bai rất nhiều.

Tuy nhiên, giá trị của kiến trúc App Router từ bản Nextjs 13.4 là không thể chối từ, nó đem lại trải nghiệm tốt hơn về thiết kế UI, Render flow (page, layout, template, server component, server action…) và cải thiện SEO ở mức tốt nhất cho các dự án CMS/Ecommerce. Đây cũng là lý do chính mà cả bộ sậu Vercel đầu tư rất nhiều vào kiến trúc App Router (thư mục “app”) để thay thế cho kiến trúc thư mục “pages” cũ. Những lợi ích này có giá trị rất lớn cho #CX – hay gọi dễ hiểu là Trải nghiệm của khách hàng (Customer Experience) 👍.

Các cuộc tranh cãi nổ ra kiểu nếu DX của App Router còn tệ hại như vậy thì chúng tôi sẽ bỏ đi, sẽ Vite + ReactJs, sẽ Angular, sẽ Gatsby 🤭…mà hoàn toàn phủ nhận giá trị của CX mà Nextjs mang lại.

Lịch sử đã cho thấy, chúng ta (developer) sẽ sẵn sàng đánh đổi 1 chút DX của mình để khách hàng được trải nghiệm tốt nhất. Chúng ta đã từng có giai đoạn dành cả tiếng đồng hồ để compile một phần mềm trong mỗi lần thử, dành cả ngày để render cái scene 3D cho đẹp hơn xí,… mà giờ có vài giây cũng kêu ca. Tuy nhiên, nếu sự chờ đợi dành cho quá trình phát triển để đem lại trải nghiệm cho khách hàng (CX) tốt hơn thì hoàn toàn xứng đáng. Vì trải nghiệm khách hàng khi sử dụng website tốt sẽ đem lại tiền cho doanh nghiệp.

Nói đi cũng phải nói lại, nếu DX của hệ thống tệ và đối thủ làm tốt hơn thì cộng đồng có thể quay lưng (như cách chúng ta đã quay lưng với nhiều thứ để đến với Nextjs). Hoặc nếu trong một dự án mà DX tệ thì sẽ ảnh hưởng không tốt đến nguồn lực dev của công ty. Mọi người sẽ tiếp cận dự án khó hơn, phát triển tính năng lâu hơn, chỉnh sửa, nâng cấp cũng vất vả…

Và sáng nay thật nhanh chóng, NextJs đã ra bản 13.4.8 với rất nhiều cải thiện để tối ưu cho DX sau rất nhiều càm ràm (và đòi bỏ đi) trên mạng. Quả thực, đi theo Nextjs từ bản 8.x tới giờ thì Nextjs không bao giờ làm ta thất vọng và phải nói trải nghiệm DX và CX từ Nextjs luôn làm ta ngạc nhiên và xứng đáng đầu tư toàn bộ stack ở cms/ecommerce đi theo Nextjs. Và việc release này cũng làm cảm hứng cho bài chia sẻ này.

Categories
Technology

Học Đại học CNTT nào?

Cách đây vài ngày có đọc một trao đổi trên Reddit về việc một OP hỏi là nên chọn học CNTT ở đại học Tôn Đức Thắng hay đại học FPT. Có khá nhiều ý kiến, chửi OP ngu có, chửi mấy thằng chửi người ta ngu cũng có và cũng có mấy ý khá thô nhưng thật đó là học trường nào ra cũng như nhau vì cũng không phải trường top và cầm tấm bằng tốt nghiệp của 1 trong 2 trường này là same same.

Tất nhiên sẽ có nhiều quan điểm bên ngoài là thời nào rồi mà còn phân biệt bằng đại học, miễn ra làm được việc là được, không nên kì thị blah blah…Vậy thì quý vị hãy nhìn xung quanh để xem vì sao các trường top được tranh giành ứng tuyển, những quản lý cấp cao hầu hết đều nằm ở trường top, hoặc mức lương trung bình của các bạn tốt nghiệp trường top sẽ cao hơn các bạn tốt nghiệp trường non-top.

Nhìn bề ngoài thì có vẻ kì thị, nhưng thực ra vấn đề lớn tạo nên điểm khác biệt ở hai môi trường này là “Bạn có gì trước khi vào trường top” và “Bạn sẽ có gì sau khi ra trường top”. Nếu xoay quanh 2 câu hỏi này thì sẽ dễ hình dung hơn vì sao có sự chênh lệch và phân biệt đối xử này từ thị trường tuyển dụng & việc làm IT.

Để vào trường top các bạn ít ra phải là một tay đáng gờm (bên cạnh sự may mắn, mấy ông rớt hay nói mấy ông đậu ăn hên) nên việc bạn học ở đâu không quan trọng (tất nhiên bạn sẽ chọn học trường top). Và với trí não (hoặc bà đãi) như vậy thì việc sau này đi làm gặp nhiều thuận lợi hơn là điều dễ đoán.

Tiếp đến, học trong trường top theo mình thấy được nhà trường đào tạo các môn ban đầu nhìn vào hoặc từ bên ngoài nhìn vào tưởng chừng như nhảm nhí, dư thừa nhưng thật ra càng đi làm mình càng thấy cực kì hay và thấy may mắn nhờ những môn học đó gieo vào đầu mình những hạt giống kiến thức nền tảng.

Ví dụ Tứng học khoa CNTT ở trường KHTN HCM (nghe nói trường này cũng đã từng đứng top), những môn mà lúc học thấy khá vô nghĩa như thời này mà còn học Assembly để làm gì, rồi còn học thiết kế mạch logic, toán rời rạc, mạng máy tính cơ bản, blah blah…Và được ca tụng nhất là môn Triết học. Riêng về cái triết học thì lúc học mình khá hứng thú tới khoảng 20-30% gì đó trong thời gian học (còn lại chủ yếu ngủ hoặc trốn) nhưng những bài học về triết học giờ ngẫm lại có ý nghĩa, ví dụ “Biến đổi về lượng dẫn đến biến đổi về chất”, nghe nhồi sọ nhưng thật ra nếu bạn làm ở ngành thiết kế hệ thống, với lượng truy cập ngày một lớn (lượng) thì bạn không thể dùng giải pháp hiện có mà phải thay đổi giải pháp (chất) để thích nghi, đó chỉ là một ví dụ nhỏ của việc học…triết học.

Do đó, nếu lỡ không được học ở một trường giúp tiếp cận các nền tảng công nghệ ở cấp độ cơ bản thì bạn có thể tự trang bị các kiến thức này. Việc tự trang bị kiến thức nền sẽ giúp bạn không cần bằng đại học trường top vẫn cạnh tranh với các ứng viên trường top, hay bà con thường gọi là “cần cù bù thông minh”.

Chỉ còn vài ngày nữa là đến kì thi, hy vọng các sĩ tử đạt được trường tốt mà mình ngắm.

Fighting!!!!

Categories
Miscellaneous

New Year’s Resolution of 2023

Vậy là lại đến ngày cuối cùng của năm, lại ngồi viết một vài dòng để tóm tắt lại năm vừa rồi cũng như đặt ra một số chỉ tiêu cho năm mới 2023.

Năm 2022 đánh dấu sự ảnh hưởng dài và rộng của Covid-19 đến xã hội, kéo theo ảnh hưởng đến toàn thị trường, trong đó có thị trường phần mềm mà Tuấn trực tiếp tham gia. Nếu dành một từ để miêu tả năm 2022 của Tuấn thì đó là CHÁN.

2022 – Một năm chán nản

Về làm ăn thì với mục tiêu ban đầu là không nhận thêm dự án outsourcing, đây là một chiến lược sai lầm của mình trong năm nay, kèm theo việc đánh giá thấp duy trì dòng tiền khiến cho dòng tiền rơi vào khủng hoảng, xoay sở để hết năm 2022 đúng là một trải nghiệm không muốn có, tuy nhiên cũng dạy cho mình nhiều điều về cách quản lý dòng tiền cũng như chiến lược kinh doanh từ nay về sau.

Do không đẩy mạnh nhận outsourcing nên đã ra mắt được phiên bản thử nghiệm của dự án Cropany, đây được coi là dự án chính của công ty trong 2023.

Nhân sự không tăng nhưng giảm bớt nên cũng coi là không thành công trong khâu mở rộng công ty. Tuy nhiên, việc không mở rộng team cũng coi là may mắn để giúp duy trì dòng tiền trong năm 2022 vừa qua.

Tuy nhiên, cũng có một chút thành tựu là đã di chuyển sang một văn phòng rộng lớn và thoải mái hơn, cũng như vào trung tâm (ở Quận 10) thay vì ở Q. Tân Phú như trước đây.

Về gia đình thì không đóng góp nhiều về mặt tài chính vì tập trung xoay sở để giúp công ty tồn tại. Tuy nhiên, có niềm vui là các con đã trưởng thành hơn một chút và học cùng trường.

Về bạn bè thì nhận ra xung quanh mình có nhiều người bạn tốt, sẵn sàng giúp đỡ trong những lúc mình gặp hoàn cảnh khó khăn.

Về cá nhân thì nhận thấy trình độ của bản thân vẫn được phát triển, xây dựng được một số kiến trúc phần mềm mới giúp ích nhiều cho việc xây dựng phần mềm. Số lượng sách đọc khá là ít (khoảng 20 cuốn) nên cũng chỉ là đọc ở mức cơ bản.

Về sức khoẻ thì không giảm được ký nào mà lại tăng 1 2 ký bởi vì áp lực quá lớn khiến không có tâm trạng để…giảm cân.

Kế hoạch 2023

Sau khi nhận ra được nhiều lỗ hổng trong chiến lược kinh doanh và phát triển sản phẩm nên hy vọng năm 2023 sẽ có các hướng phát triển an toàn và bền vững hơn.

  • Sẽ tập trung phát triển tiếp dự án Cropany để ra mắt một phần mềm quản lý công ty miễn phí top đầu VN.
  • Lấy lại phong độ đọc 50 cuốn sách.
  • Đi du lịch trong và ngoài nước ít nhất một lần
  • Đẩy mạnh nhận 5-7 dự án outsourcing, doanh thu tăng gấp 5 lần so với 2022.
  • Tham gia chia sẻ ít nhất 5 lần tại cuộc hội thảo / meetup offline
  • Viết một cuốn sách miễn phí về công nghệ để giúp người mới.
  • Tăng 100% nhân sự.

Như hầu hết mọi người, mục tiêu đặt ra để giúp mình đánh giá lại những gì kì vọng và đạt được để phát triển và hoàn thiện bản thân hơn. Tự thấy 2022 đã giúp mình học và hiểu được nhiều điều nên hy vọng 2023 sẽ là một năm thắng lợi và thành công.

Tuấn cũng hy vọng các bạn sẽ có một năm 2023 tràn ngập niềm vui và gặt hái thành công hơn nữa.

Categories
Mobile

Cài đặt môi trường React Native 0.70 trên Mac M1

Chào các bạn, hiện tại nếu làm theo các hướng dẫn trên web chính thức của reactnative.dev thì có thể bạn sẽ không thể cài đặt thành công môi trường để chạy được React native 0.70 trên M1.

Mình viết bài này để chia sẻ nhanh một số bước mà mình đã cài đặt môi trường thành công và chạy được React Native. Một số thông tin cấu hình của máy mình. Mac M1, hệ điều hành Ventura 13.0, React Native 0.70.

Ghi chú bằng tiếng Anh nên mọi người thông cảm:

Step 1: Install “rbenv”

> brew install rbenv

Step 2: install ruby 2.7.5 (React native 0.70 required)

> rbenv install 2.7.5

> rbenv global 2.7.5

Step 3: Update ~/.zshrc, append this line:

eval "$(rbenv init - zsh)"

Restart zsh

> source ~/.zshrc

Step 4: install sample project

> npx react-native init MyTestApp

(ESC on select cocoapod installations question). We will install later

Step 5: Go to ios

> cd ios

Step 6: Install cocoapods via brew

> brew install cocoapods

Step 7: Install ffi

> sudo gem install ffi 

(there is no need arch.. as online tutorials ^^!)

Step 8: pod install

Run bundle

> bundle install

Update current repository to latest version (to prevent olddate repo)

> arch -x86_64 pod repo update

Finally, run pod install

>  arch -x86_64 pod install