Topics and highlights
- Erlang automata part 2: Minh Lưu shared a practical breakdown of Erlang’s gen_statemachine vs gen_server, using a TCP-to-Redis connection module as a case study, implemented in Elixir for clarity.
- AI & market landscape: Minh Lê recapped AI agent products on Solana, emerging macro trends in Southeast Asia’s tech investment (e.g. challenger banks, neobanks), and how Y Combinator and a16z are repositioning around fintech and stablecoins.
- Research direction: The team discussed how recent AI and Web3 shifts align with internal priorities, reinforcing a focus on high-signal innovation zones and how to build for impact in 2025.
- Dwarves of the year & team awards: Celebrated contributors for embodying the AMA model, sharing AI research, and supporting team growth. Awards also highlighted excellence in consulting, performance, and community engagement.
- Hybrid work shift: Announced a post-Tết operational update, ending remote-by-default in favor of 3-days-a-week in-office commitment for Saigon, Hanoi, and Danang hubs. Emphasis on adaptability in a shifting tech market.
- Operation updates: Confirmed no referral bonus for 2025. 13th-month salary was processed based on average pay. Noted that profit-sharing would be paused due to cautious market outlook.
- Looking ahead: The team reflected on the importance of physical collaboration, the benefits of dense information zones, and emerging builder trends post-layoffs, from build-in-public to token-based MVPs.
Vietnamese transcript
[01:29] Ok anh em. Lâu quá mới lên sân khấu. Lịch trình hôm nay theo kế hoạch của anh Thành là có bốn bài như thường lệ. Thấy nhắc bốn bài như mọi khi, nhưng tí nữa có tổng kết nên anh chắc chen thêm một bài.
[07:48] Xíu đổi lịch trình nha anh Thành. Lịch cũ thì bên đó làm bài tiếp tục series Engineering, cái mà bên nghệ nhân đã chuẩn bị và trình bày. Nhưng anh thấy tạm thời dời lại. Chắc để tuần sau hoặc qua Tết.
[08:09] Gộp thành combo, từ từ giới thiệu cho anh em sau đợt hai tháng trước. Giờ mấy topic mở rộng thế nào, làm gì tiếp thì để sau. Lên phần Biên nha, phần hai của Minh Lưu về Erlang. Bữa trước cậu ấy làm bài rồi, giờ tính review lại ý kiến mọi người.
[08:32] Buổi trước mọi người thấy sao? Có còn nhớ gì không? Bài này 50-50. Bài Minh Lê thì chắc lấy bài Minh Lê lên xem thử.
[08:53] Lần này, bữa trước thấy anh em team bắt đầu viết, nhìn rất ok. Cuối cùng đăng hôm nay. Nên mình có hai, hoặc hai rưỡi topic cho mọi thứ. Thiếu mấy đứa rồi. Anh đâu rồi? Mấy nhóc kia đâu, biến hết rồi?
[09:34] Lên nào, lên tổng kết tí. Em ơi, anh đâu rồi? Đây nè. Rồi, đủ mặt, đủ mấy nhóc vô xem. Ừ, Tuấn, Tuấn đi chơi về vui không? Mua gì không? Tuấn trốn trong văn phòng rồi đúng không? Vui quá ha. Nếu đổi lịch thì làm bài Minh Lê trước nha. Hai tuần trước.
[10:32] Thấy mấy bài đã public rồi. Anh muốn nghe trực tiếp, xem chất lượng bài market report thế nào. Mọi người xem thử luôn, anh chen vô tí về thị trường. Tiếp theo là tổng kết, có vài chính sách muốn thông báo.
[10:54] Sắp tới có update nhỏ, rồi sau đó tổng kết năm. Inno viết bài rồi. Ngồi đọc chung xem sao. Rồi tới bài cuối của Minh Lưu. Chắc làm luôn, bài trước cũng là Minh Lưu.
[11:22] Bài trước của Minh Lưu nói về cái gì? Finite state machine trong Erlang đúng không? Hôm trước anh em còn nhớ gì không? Đánh giá sao, cho rating một phút. Còn nhớ nói gì không? Độ tập trung thế nào?
[11:57] Bài tháng trước hả? Minh Lưu làm về finite state machine. Còn nhớ nó quan trọng sao không? Nếu nhớ thì sao dùng Erlang khi Elixir cũng làm được? Huy Nho có bài đó không? Huy Nho có tham gia không? Anh thấy bên nhóm của em có nhắc tới làm state machine khá nhiều.
[12:26] Huy có góp mặt không vậy? Bên chỗ Minh Lưu là bên Yolo, tụi nó đang xài cái đó cho mấy dự án bên này, đúng không? Còn bên em thì ở Ascenda, cả hai chỗ đều có xài rồi. Làm cái framework, rồi làm cái controller, tới cả stage controller nữa, đúng không? Bên mình thì đang thử mấy cái đó, kiểu như là làm sao để tối ưu hóa được cái luồng xử lý state trong mấy dự án hiện tại.
[12:56] Chuyển kiểu round-robin đúng không? Bên này thì define mấy cái state trước, rồi cái state nó sẽ set một cái context, kiểu như là enter state hay state hiện tại là gì, để bên ngoài chỉ cần switch qua lại giữa các state thôi. Còn bên Yolo thì em chưa biết rõ lắm, em chưa xem kỹ bài của Minh Lưu.
[13:19] Chắc được ha? Ok, có mấy người mới nhảy vô luôn kìa, đông vui rồi đây. Vậy thì chắc cho Minh Lưu lên trước đi thôi. Minh Lưu chuẩn bị đi nha, Minh Lê ngồi đợi xíu. Lên nào, Minh Lưu, nhanh lên, nói một chút thôi cũng được, vì cái này cũng quan trọng, anh em cần hiểu rõ hơn về hướng đi này.
[13:41] Em có 10 phút thôi, 10 phút là ổn. Bài này nối tiếp cái trước đó, tí nữa em sẽ nhắc lại tại sao cái này nó quan trọng với team mình. Em muốn anh em thấm cái này thật kỹ, vì đây là một kỹ thuật không dùng nhiều trong Erlang, nên nó khá đặc biệt. Mấy cái này bên mình làm xong thì có thể áp dụng qua mấy dự án khác nữa.
[14:12] Order Minh Lưu nha, em có slide sẵn đây rồi. Để em review lại bài trước một chút cho anh em nhớ. Trong đó có cái behavior, tức là một pattern để mình define một cái module. Nó sẽ set sẵn một số hook, rồi mình dựa vào đó để xử lý các trường hợp cụ thể trong code, kiểu như là chuẩn bị trước một bộ khung cho mấy cái chức năng chính.
[14:49] Mình sẽ implement mấy cái hook đó. Hai cái phổ biến nhất là gen_server và gen_statemachine. Đa số module thì viết dưới dạng server là được rồi, đặc biệt với mấy cái state machine đơn giản thì gen_server đủ sức đáp ứng. Nhưng mà tùy trường hợp thì mình mới chọn cái nào, không phải lúc nào cũng xài bừa được đâu.
[15:14] Gen ở đây là viết tắt của generic, tức là generic server đó. Mình chỉ nên dùng gen_statemachine khi thật sự cần mấy tính năng nâng cao, ví dụ như insert event—tự chèn một event vào trong stage—or là cần trigger một cái action cụ thể khi switch giữa các stage. Cái này thì gen_server không làm được tốt bằng, nên phải cân nhắc kỹ.
[15:36] Khi chuyển từ stage này sang stage khác mà mình muốn nó tự động chạy một action sẵn, thì cái đó gọi là state entry. Hoặc là mấy cái liên quan tới timeout, kiểu như set thời gian chờ giữa các bước. Trong thực tế gen_statemachine thường được dùng khi mình muốn implement một cái gì đó persistent, tức là cần giữ trạng thái lâu dài.
[15:59] Ví dụ như TCP connection chẳng hạn, người ta hay dùng state machine để xử lý mấy cái này. Khi mình đã có một set các state cố định và cái connection đó cần persistent, thì lúc đó gen_statemachine là lựa chọn hợp lý nhất. Còn với mấy trường hợp bình thường khác thì gen_server là đủ rồi, không cần phức tạp quá. Hôm nay em sẽ code một ví dụ cụ thể để anh em hình dung rõ hơn.
[16:24] Như anh Minh có hỏi bữa trước, tại sao phải dùng Erlang trong khi Elixir cũng làm được cái này? Thì đúng là vậy thật, behavior trong Erlang thì bên Elixir cũng gọi lên được và implement tương tự luôn. Nên hôm nay em quyết định làm ví dụ bằng Elixir để anh em dễ so sánh, xem cái nào tiện hơn trong trường hợp này.
[16:49] Code bằng Elixir thì nhìn nó trực quan hơn một chút. Có slide không nhỉ? Slide về gen này đây, để em cho anh em xem thêm chi tiết, biết rõ hơn cách nó hoạt động. Ok, em chèn slide vô luôn. Hôm nay mình sẽ làm một module để connect TCP tới Redis server, giữ nó đơn giản thôi, chỉ có hai stage để dễ hiểu.
[17:34] Hai cái stage thôi, tức là nó sẽ là một module nằm giữa user và Redis server. Module này sẽ implement phương thức để connect tới đó và làm trong suốt quá trình connect tới server. Ví dụ, khi process của mình bắt đầu một connection tới server thì tất cả request từ user tới nó sẽ trả về trạng thái disconnect hết. User không biết process thật sự mình gọi tới server ra sao, chỉ thấy qua process của mình thôi. Nên nó có hai stage: thứ nhất, khi khởi động process lên thì nó ở trạng thái disconnect.
[18:21] Mình sẽ thiết lập một connection tới Redis server; sau khi connection thành công thì chuyển sang trạng thái connect. Còn nếu connection bị lỗi hay gặp vấn đề gì đó mà đứt, thì mình quay lại trạng thái disconnect và cố gắng restart lại connection. Những request, tức event request từ client, sẽ nhận dưới dạng event. Event có thể tới lúc disconnect hoặc connected; khi tới lúc disconnect thì mình chỉ đơn giản trả về cho client trạng thái là disconnect.
[18:41] Connection thì những request, tức event request từ client, sẽ được nhận dưới dạng một event. Event này có thể tới lúc disconnect hoặc connected. Khi tới lúc disconnect thì mình chỉ đơn giản trả về cho client trạng thái disconnect. Còn nếu tới lúc connected thì mình gửi request đó lên Redis server, lấy data trả về cho client. Tại sao cần dùng state machine? Vì mình cần mấy tính năng như insert event mà em vừa nói. Đây, mọi người thấy không, để em zoom lên.
[19:39] Trước tiên, mình implement behavior trên state machine, define cái data trong behavior này. Nó có hai thứ: State là stage thể hiện trạng thái của module, và Data chứa dữ liệu khi state chuyển đổi, mang theo một số data để xử lý trong module. Data gồm host, port để connect tới Redis DB, và request là map chứa danh sách ID của client cùng key là ID để biết trả về cho client nào. Khi start process này lên, việc đầu tiên là connect tới Redis server, chạy trong background và trả về trạng thái disconnect cho user.
[21:04] Trước tiên, mình define callback mode gồm hai thứ: State function—tức đặt tên hàm trong module theo tên stage, ví dụ stage disconnect thì module tự chạy vào hàm disconnect để xử lý dựa trên tên và số tham số—và state enter, tí em giải thích sau. Bắt đầu bằng hàm init, mình trả về next_event, tức module tự insert event internal_connect với data là host, port để connect tới Redis server, rồi trả ngay trạng thái disconnect. Khi trả về disconnect, nó chạy vào hàm disconnect để xử lý. Hàm disconnect với internal_connect sẽ mở TCP socket bằng gen_tcp tới Redis server, bắt đầu thiết lập connection trong background.
[21:49] Cái state enter thì tí em sẽ giải thích sau, ý nghĩa của state function là như vậy. Xong rồi mình bắt đầu bằng hàm init như hồi nãy em nói. Trong init thì làm gì? Đơn giản là khi bắt đầu hàm, mình dùng một term là next_event. Next_event là gì? Nó sẽ tự insert, tức module này tự chèn một event vào trong tay nó. Event này là internal_connect, dùng với data là host và port để connect tới Redis server, rồi trả về ngay lập tức trạng thái disconnect.
[22:43] Khi trả về trạng thái disconnect như vậy thì việc đầu tiên là nó chạy vào hàm disconnect để xử lý. Hàm disconnect với internal_connect này làm gì? Thứ nhất, nó mở một TCP socket bằng gen_tcp tới Redis server. Rồi mình chợt thấy hơi nhiều chi tiết quá, em gộp mấy hàm lại thử được không anh em? Anh chen vô cho anh coi mấy chỗ define hai cái stage của nó, coi hơi rối quá rồi. Chỗ nào define hai trạng thái đâu đây? Mọi người thấy đó, nó có cái list ở kia, mình có hai trạng thái thôi ha.
[23:48] Ở đây là hai trạng thái, bốn cái overlap function của disconnect và connect. Minh có bốn overload của connect, còn hai trạng thái thì bình thường thôi. Bên Elixir thì nó overload dựa trên param list đưa vào, nó biết chạy cái nào. Chỗ thứ hai là chỗ nào chuyển trạng thái đâu? Ờ, nó nằm trong từng hàm.
[24:42] Ví dụ hàm connect này, khi connect thành công thì nó trả về một atom next_stage, chuyển trạng thái sang connect ngay đây, cùng với data đó. Hiểu rồi, đây là chỗ gọi để chuyển từ state này sang state kia. Nhưng mà với mỗi overload function vậy, em gọi implicit thế này thì có đúng không ta? Thường mấy cái này sẽ có dạng controller để quản lý, chứ gọi chi tiết kiểu này nhìn hơi rối. Có 10 stage trong đây mà define xong gọi thì quản lý khùng luôn.
[25:01]
Cái ngay chỗ này nè, ngay backend của mình á. Vì state function thì mình có một cái gọi là handle_event function. Khi chuyển sang xài mode như thế này, mình chỉ cần define một function là handle_event thôi. Ví dụ vậy thôi, mình chỉ cần define xong là quản lý hết tất cả state trong cái function đó. Nếu muốn kiểu cách như vậy, nó cho mình lựa chọn giữa việc define function theo state hoặc define một handle_event function.
[26:14] Giờ kêu hình đâu, Bảo Hân Trần có nhìn vô cái này, có xài cái này bao giờ chưa? Để trực quan thì em có copy một cái thư viện connection, cũng tới TCP đây. Nó viết bằng gen_server, không xài state machine, theo kiểu button như vậy. Connect fail thì nó back off, rồi retry, cũng quản lý user trong một cái map. Nhưng nó hơi dài hơn tí, phải implement lại mấy thứ có sẵn ở bên này, như timeout chẳng hạn, nó phải tự implement lại hết. Rồi câu hỏi là chị hỏi em cũng mới học, mới làm cái này. Mình biết cái này lâu rồi đúng không, nhưng lúc tiếp cận thì thấy sao? Tại sao nó quan trọng? Nó define một số cách giúp mình làm tiện hơn, anh. Ví dụ như xử lý timeout, nó define dựa trên data mình trả về.
[27:47] Ví dụ thế này đây. Khi connection của mình bị drop, mình chạy vô hàm disconnect để xử lý, nó cho mình trả về một atom timeout cộng với thời gian. Sau khoảng thời gian đó, nó tự động chạy vô đây xử lý cho mình. Ừ, đây, nó giúp mình làm mấy cái đó tiện hơn. Thay vì viết bằng gen_server cũng được, nhưng sẽ dài hơn. Ok, ok, cảm ơn Minh. Minh Trần có hỏi gì không? Ai nữa?
[29:14] Nhờ Minh Trần code cái này nào, code Elixir nữa, nhờ anh biết có đụng tới đây chưa. Rồi đặt câu hỏi nha, phổ biến nhanh cho anh em: cái này nó như vậy, sự khác biệt cơ bản trong lập trình của nhóm mình, trong tất cả các ngôn ngữ lập trình hiện đại hiện tại thì không có ngôn ngữ nào có sẵn thư viện để quản lý state machine như con Erlang. Erlang là con duy nhất sinh ra để chạy mấy cái hệ máy tự động không xuất phát từ góc nhìn làm server đứng đó đợi gọi tới gọi lui theo mô hình client-server từ đầu.
[29:30] Con này sẵn đúng không? Với cái vụ mà nó build-in trong đây thì lúc em lập trình, nó ra được hai thứ. Thứ nhất là nó ép cả đội học ngôn ngữ này, có tooling này sẽ hình thành một mental model, một mô hình tư duy giống nhau. Gặp đúng trường hợp thì mình moi cái tool ra xài, suy nghĩ giải bài toán theo cách này.
[30:07] Lúc làm mấy cái model như C4 á, hồi đó cũng đụng tới đây thôi đúng không? Nó cung cấp cái tool cho mình. Thứ hai là nó unify tư duy lại với nhau. Tất nhiên gen_server thì vẫn code kiểu bình thường, anh em xài vẫn ok, không sao hết. Nhưng điểm đặc biệt của Erlang là có cái này.
[31:13] Khi team thấm rồi, quản lý code base dưới dạng state machine, chuyển state vòng vòng mấy cái object, thì nó giúp quản lý source tốt hơn. Tránh việc code implicit, đẩy code đi vòng vòng, hồi không biết mình chuyển qua đâu. Mình tập trung vào logic, vào góc nhìn nhiều hơn là lo cái data bên dưới nó thế nào. Chứ không thì lỗi xảy ra rất nhiều trong code base lớn, không nhìn theo kiểu này là lỗi đầy ra, phải đứng ra làm lại hết. Đó là lý do con này đặc biệt, với Erlang thì đặc biệt vậy thôi. Về Elixir, mấy cái thằng kia không build thư viện này lên, nên xài vẫn phải chọt trực tiếp trên Erlang.
[32:08] Ừ, thôi đó là tóm tắt nhanh bài của Minh Lưu. Nếu Minh Lưu làm bài tiếp theo, anh đề nghị làm cái gì phức tạp hơn xíu, thực tế hơn xíu. Bài kia có hai stage nhìn còn đơn giản. Hoặc kiếm mấy cái clip open source của tụi nó, quản lý state nhiều hơn. Có cái ví dụ của một nhóm nào đó, xài quản lý mấy WebSocket, nhiều stage lắm. Chỗ đó cũng có xài một phần gen_statemachine, một file lên tới ngàn dòng. Lúc gộp hàm lại thì thấy cấu trúc rõ ràng, không phải kiểu implement đẩy qua đẩy lại lung tung, có một con manager đứng quản lý. Anh em lâu lâu mất não quay lại nhìn vẫn dễ chịu hơn là nhìn mấy hàm tự đặt tên, nhìn mệt lắm.
[34:18] Cái chuyện hình thành mental model chung của một nhóm cực kỳ quan trọng. Cảm ơn Minh Lưu, mời Minh Lê. Dạ, để em coi em có bao nhiêu phút? 10 phút không? Ừ, 10 phút, tại em đang có bốn bài rồi hả? Lúc trước bên team consulting có ra ý tưởng viết series hàng tuần, mỗi tuần một bài tổng hợp thông tin liên quan tới bên test mình. Nhưng nó không sâu về test quá, chỉ chung chung. Bài đầu tiên em viết từ giữa tháng 12 năm ngoái, cover lại chuyện đợt Google ra Gemini 2.0, rồi Open AI ra model chain video.
[34:38] Mấy cái hình ảnh của nó cho người bệnh, hoặc mấy người khỏe mạnh đeo vào, như mấy cái đồng hồ anh em mình đeo để theo dõi nhịp tim ấy. Rồi bên consumer tập trung vào mấy cái bí mật, như mấy cái để render ra video giống con Sora. Ở trên crypto thì nó cũng gắn AI vào fintech, gaming, infrastructure này nọ.
[35:21] Bên Y Combinator cũng tương tự, họ kêu gắn AI vào mọi chủ đề hiện tại. Họ đang tập trung bảo mọi người nghiên cứu stablecoin. Lúc trước thì kêu làm Bitcoin với Ethereum để thanh toán, nhưng sau một thời gian thử nghiệm trên thị trường, họ thấy mấy cái đó không hợp lý. Nên giờ họ chuyển qua nghiên cứu hướng stablecoin, kiểu đủ thị phần để mấy công ty bỏ tiền nghiên cứu, rồi build giải pháp thanh toán.
[36:21] Ở đây em nói sơ về một product, một cái AI agent platform trên Solana. Họ khẳng định đây là nền tảng cho mình tạo mấy con AI agent. Mấy con AI agent này giúp quản lý ví, tạo coin, tự trade, nói chung là tự động hóa mấy thứ mà dân crypto với DeFi hay làm. Product này giúp người ta làm vậy dễ hơn với sự hỗ trợ của AI. Đó là bài thứ nhất, qua bài thứ hai. Bài thứ hai trong bốn bài, nhiều lắm. Giờ câu hỏi chính là qua bốn bài tháng vừa rồi, em nghĩ cái gì benefit team mình?
[37:13] Ừ, em nghĩ chắc mình đang đi đúng hướng, tập trung vào mấy công nghệ AI, làm quen với agent, blockchain này nọ. Nó đang phát triển rất mạnh, đang bùng nổ thị trường, rất hot. Sắp tới chắc cũng có nhiều product tập trung vào đó. Còn mấy mảng như Y Combinator hay a16z đề xuất thì hơi vượt xa tầm với của thị trường mình, nên cũng khó nhảy vào. Nhưng tuần vừa rồi em coi một cái thống kê sơ về nguồn tiền chảy ra chảy vào ở Đông Nam Á, quý cuối 2024 vừa rồi, thì đây là top mấy ngành đang được đổ tiền vào nhiều.
[38:23] Ngành thứ nhất là challenger banks. Nó khác ngân hàng truyền thống, tập trung hoàn toàn vào ngân hàng số. Ở Việt Nam mình hình như có một cái ngân hàng số, nhưng không được định nghĩa là challenger bank hoàn toàn. Như mấy thằng Timo này nọ, nó được gọi là neobank nhiều hơn. Challenger bank là kiểu có giấy phép hoạt động như ngân hàng thật, tự đưa ra sản phẩm mới trong ngân hàng số của nó.
[40:08] Còn neobank ở Việt Nam thường có ngân hàng truyền thống đứng sau, bật giấy phép, không tự phát hành sản phẩm ngân hàng được. Ở Đông Nam Á, mấy VC đang đầu tư mạnh vào challenger banks, vì họ nghĩ nó giải quyết vấn đề tiếp cận tài chính cho mấy vùng không có điều kiện, hơn là crypto.
[40:30] Nghe nói em có kiểm tra lương bổng, mấy con số lương phải trả cho ngành IT ở các nước Đông Nam Á. Bên Philippines đang có giá cả khá cạnh tranh, dân số thì đông, giáo dục cũng đang phát triển ổn. Ngành nhân lực IT của họ đông lắm, làm cho mấy công ty nước ngoài, tiếng Anh thì rất tốt, mà giá lại cạnh tranh hơn so với mấy nước Đông Nam Á như Việt Nam mình.
[41:26] Việt Nam mình vừa rồi quý 4 bị giảm đầu tư khá nhiều, tới hơn 80% luôn, còn Philippines thì tăng mạnh, phát triển lắm. Họ đang đẩy mạnh thương mại điện tử, mấy cái digital, giống kiểu mình cách đây 3-4 năm trước. Giờ họ được đầu tư nhiều. Ok, interesting, kéo lên trên tí. Vậy mấy phần trên anh thấy toàn liên quan tới tiền, đúng không? Banking, ngoại tệ, rồi finance, toàn dính tới tài chính. Đông Nam Á chắc đang đầu tư mạnh vào mấy ngành này.
[42:39] Nếu vậy, tuần tới mấy bữa nữa ngồi xem tiếp, soát thử danh sách tiềm năng, coi mấy cái ecosystem map hay system hiện tại của tụi nó, tìm được không? Dạ, để em kiếm thử, mấy report thường có mấy cái đó. Ừ, ok. Còn gì nữa ngoài cái này không? Thấy tuần này là tuần Giáng sinh, ít tin tức, cũng chán. Em có để mấy product blockchain mới, đang được người ta đổ tiền vào nhiều, lock vốn nhiều. Blockchain hả? Cho anh xem thử coi. Liquid rồi, ok, phút phút, tụi nó share trong kênh chat rồi, ok lắm.
[44:19] Nếu vậy có hướng này. Thật ra để viết bài này, anh thấy có góc nhìn thế này. Nếu được, mấy anh em ngồi xem, em có thể trả lời theo góc nhìn: slogan của team mình từ đầu là “empower innovation”. Tức là mình tìm mấy cái innovation đang xảy ra, để có cơ hội làm chung với tụi nó, hoặc hỗ trợ, thậm chí invest luôn thì quá đẹp. Cái interest lớn nhất khi anh em làm cái này là tìm xem innovation đang ở đâu. Thay vì điểm tin chung chung, em có thể chỉ rõ mấy điểm nhịp của market, chỗ này chỗ kia, innovation sẽ diễn ra ở đó. Trong đó, business model hay financial model là gì, trả lời đúng trọng tâm của mình, cũng là kiến thức dễ ping bài toán kinh doanh.
[47:25] Coi thử hướng đó nha. Ok, cảm ơn Minh nhiều. Trước giờ mình thiếu cái đó, kiến thức trôi nổi, không tập trung. Góc nhìn này sẽ giúp team hiểu rõ, khi soát dự án cứ nhìn kiểu: chỗ nào sale, chỗ nào có tiền. Cách nói khác là innovation đang ở đâu, mọi người làm gì mới ở đó. Ngành software của mình, chỗ nào đang build mới thì mình mới có cơ hội nhảy vào review. Còn mấy cái bùng nổ quá thì chỉ làm retainer, dán dự án, chán lắm. Ok, chắc hết phần này. Giờ tổng kết năm nhanh xíu. Mấy anh em ra ngoài offline là xong. Câu hỏi nhanh: Huy với Thành chuẩn bị mấy phần rồi, out hết chưa? Chắc hết rồi.
[47:50] Năm nay thị trường thay đổi nhiều quá, mấy cái assumption trước đây nó thay đổi hết, cũng không biết đâu mà lần. Nhân sự mình cũng có sự chuyển dịch tương đối, đúng không?
[48:53] Nhiều thứ định hướng của mình cũng shift đi, từ mô hình cũ tập trung vào enterprise, nhưng AI ra đời thì wipe hết thị trường luôn, đủ trò hết. Định hướng sắp tới mấy em nhìn chung thấy thị trường đang chuyển dịch theo hướng tiếp cận tài chính, blockchain. Nói chung AI đang hot, nhưng tính ứng dụng vào doanh nghiệp chưa nhiều lắm, đang bùng, mọi người thi nhau bùng thôi. Còn hướng chính vẫn là đánh về tài chính.
[49:55] Hướng đó thì vô tình Engineering của mình đi research cái đó, học cái đó, đang diễn ra nhiều. Nên Year-end hiện nay công bố luôn nhờ, có bao nhiêu giải? Năm nay team có bốn giải, còn một giải trong phần community. Vẫn có một giải cao nhất thuộc dạng kiểu vầy cơ. Còn mấy giải kia thì dạng honorable mention. Tất cả giải thưởng này rút ra là để vinh danh mấy bạn high performer trong năm vừa rồi qua các mảng chính của team mình. Chắc để công bố luôn, bảy giải từ bốn giải là gì?
[51:05] Một giải đội hả? Ba giải còn lại gì? Giải thứ nhất cho bạn execute cái model AMA của mình tốt nhất vừa rồi. Giải thứ hai thuộc về giải thí sinh cho team lead, bạn nào dẫn dắt team mình ok nhất, được number one. Giải thứ ba thì cho bạn perform tốt nhất ở bên phần consulting. Project có hai performance được anh em trong team đánh giá cao và khách hàng đánh giá cao vừa rồi. Giải thứ ba thì cho tập thể team nào đó perform cộng, có hai đầu: một là perform để ghép được phần inhousing, hai là nâng cao độ tin nhiệm và upsell thêm cho team đó.
[53:38] Giải cuối thì cho community, mấy bạn supporter không thuộc official team nhưng có setting với mình, tham gia hoạt động, sharing cá nhân. Ok, vậy là bốn cái đúng không? Developer of the Year tức là mô hình MMA: meaning, mastery, autonomy. Giải thứ hai dành cho hướng style research, là giải động team lead. Giải thứ ba là consulting, ba giải cá nhân và một giải đồng đội là dự án thấy có impact nhất. Mấy dự án khác không impact bằng thì không tính sau nhé. Cuối cùng là giải community, mà community ở đây đâu có ai đâu nhờ? Năm vừa rồi thấy ít mà, phải không? Ừ, thật ra là có bạn làm việc với team mình khoảng mấy tháng thôi.
[54:26] Rồi, chắc làm cái công bố nhanh thôi, mấy anh em in-out cái đó cho dễ, ok không? Chứ anh làm cho chuẩn thì lâu lắm, rồi tính tiếp. Cho xin cái reaction cái nào, zalo hay slack để mình capture lại nhờ. Hai con VIP kêu rồi, ok. Rồi, good. Giải thứ hai nhờ Thành công bố cái gì hay giải gì nhờ, cần soát tin rồi check, ok.
[55:58] Cho phút lead xin cái reaction. Ủa, còn setting này là cá nhân hả? Đúng rồi. Ok, có thể điểm sơ qua được không? Trước giờ performance mình thấy cũng như mấy năm trước thôi, không biết cụ thể sao, mời. Ừ, vừa rồi thì chắc tí nữa Huy sẽ cho comment chi tiết hơn. Nhưng đánh giá tổng quan mà Thành xem được của Phúc vừa rồi thì thực ra trước giờ, mấy năm trước Phúc đa phần làm internal project với consulting, chủ yếu đợt này qua làm bên team Yolo.
[57:21] Thực ra với role nó hơi yếu đúng không, so với expectation dạng depth của backend các thứ. Trước đó role của Phúc focus chủ yếu liên quan đến iOS thôi. Ban đầu thì ông này bên đó cũng skeptical về Phúc, nhưng thấy bảo adapt rất ok. Trong đâu đó năm sáu tháng, anh em bên đó chắc đánh giá ưng nhất, mà nghe nói cũng khó tính. Chi tiết thì chắc Huy có comment chính xác hơn, vì trong project của mình thì Huy chọn mà. Mắt em comment là sao, anh này comment về em mà. Thật ra em nghĩ mấy bạn làm thì cũng tương đối nhiều, mặt kháng giá, lập này nọ.
[58:46] Nhưng em nghĩ chỗ anh Thành chọn Phúc là vì thấy sự vừa expectation của mọi người tí. Lúc trước Phúc cũng có làm dự án, nhưng khá im, không giao tiếp vào xong thôi. Dù tài năng rất tốt, nhưng trong năm nay thì có nhiều cái vượt xa mức đó. Ví dụ thành quả là mấy cái style khác, loop rồi, đi mấy cái style JavaScript, TypeScript các thứ, dù lúc trước không liên quan lắm. Rồi còn liên quan đến việc bắt đầu có mấy cái cần soát với khách hàng, deadline kiểu này không ổn. Đỉnh nhất là vừa rồi, chỗ bảo muốn làm cái này, nhưng Phúc bảo không kịp đâu, từ từ làm. Đó là dấu hiệu ban đầu, rồi cũng bắt đầu có việc trọn Phúc cho mấy cái phát triển vừa bực hơn, ghê hơn, chứ không hẳn là nhất. Nhưng expectation của Phúc có vẻ tốt nhất. Ok, đúng là Superman ha. Phúc có lên phát biểu không?
[61:03] Chế độ này ngồi sao được, em gắn headphone vô. Em cũng thấy hơi bất ngờ, tự nhiên được cái này. Đang bắt xe xuống cái từ thiện, em cũng không biết nói gì, mà thấy có nhiều hết nghe rồi. Ô, Ngọc Thành vô nè, lâu mới gặp Ngọc Thành, nghe Phúc ơi. Thức nó sao giờ, nó mute luôn rồi. Ở ngoài đường thì hiểu cảm nghĩ là giải thứ hai, em nghĩ cái này có xứng đáng không, thấy hơi ngại, chào đúng không, khó quá. Đủ để anh nhận hội. Dạ, đúng rồi. Giải tiếp theo nhờ Huy, xin mời cho team, thì vô cho bên key team của bên Yolo. Ok, team Yolo tức là như nào?
[62:28] Là Yolo đang nghĩ nó là một cái tiêu biểu nhá. Ừ, đồng ý. Giải cuối cùng rồi, còn lại thì trao bạn này. Cho ai cũng cần đạt thì cũng có khoảng thời gian đâu đó 2-3 tháng làm intern với mình, chủ yếu là em research liên quan đến mấy thứ liên quan đến phần mềm.
[63:20] Thực ra trước đó, Đạt cũng có trước khi join mình làm intern thì cũng tương đối active trên server mình rồi. Kể cả sau khi kết thúc intern, vẫn tiếp tục với mấy cái về build trên AI. Những bài share thì được mấy anh em phía core fork, hướng lại tương đối nhiều. Một tiêu biểu mà bên cộng đồng mình đang muốn khai thác, và Đạt chắc nên phát biểu tí. Đạt ơi, team có dành phần quà community dành cho em, giờ đang thế nào, đang ở đâu rồi?
[64:26] Em đang ngoài đường, chưa tới giờ hết đi họp hết trơn rồi à? Em cảm ơn mọi người đã dành thời gian cho em. Phần lớn thì anh Tom với anh Thành giúp em rất nhiều trong câu chuyện onboarding với cả share lại cho team sao cho ok, kiểu có thể delivery được kiến thức cho mọi người. Còn gì nữa không? Dạ, chắc không, em nghĩ như vậy. Cảm ơn Đạt đã dành thời gian ha.
[65:11] Ở style với mấy anh em, việc mình đọc cái gì hay thì chia sẻ cho mọi người, rất là appreciate mấy phần của Đạt. Even là hiện tại, mấy anh em thấy trong hoạt động chia sẻ kiến thức trong team, cái đó là cái chính. Tại hướng đi innovation nó cứ thay đổi suốt, mình kiếm được người đồng điệu, cơ hội làm việc trực tiếp thì chưa đến. Nhưng về cái chung, thấy những thứ thú vị, mình ngồi chia sẻ với nhau, đó là cái rất đáng quý ha. Cảm ơn Đạt. Chắc tới giải cuối cùng, Thành ơi, rồi sau đó mình kết thúc.
[66:14] Giải Developer of the Year dành cho bé Biên đây. Anh em có in-out giùm cái. Biên ơi, bên đâu rồi? Xin cho biết lý do đề cử là như nào, xin mời. Từ từ anh em, ừ, rồi. Năm ngoái, năm trước nữa thì anh em đều biết, mọi người đâu đó mình có post một bài viết muốn execute theo model là AMA, viết tắt của mastery, autonomy, với cả meaning. Những cái để giải đáp thì thấy chủ yếu quan sát là bạn nào trong team execute được model đấy tốt nhất trong khoảng 1 năm trở lại.
[68:23] Cái gì đấy, một cái mà team đang muốn triển khai trong giai đoạn mà AI có thể giúp mình làm phần unit work, rồi solution với design system các thứ. Vừa rồi nó quan trọng hơn đấy. Biên là một trong những anh em ở đâu đó mà đang nghĩ là execute mấy cái gọi là ninh với core goal của team rõ ràng nhất. Mọi người rất ưng khi làm việc với Biên vừa rồi, thì đó là mấy cái chính.
[69:18] Mời Biên cho vài lời, xong rồi mình qua phần cuối cùng nhờ. Em ơi, theo comment của anh Thành thấy sao? Cảm ơn mọi người ơi, nếu có thay đổi gì thì cũng không sao rồi. Kết thúc ở đây nhé, phần của Biên dậy xong nhé.
[70:21] Giờ tí nữa trước khi mấy anh em họp mình ra quán hết năm với nhau, thì có vài cái mới để định hướng lại sau Tết. Buổi này là buổi gặp tuần như cuối rồi nha, tuần sau đâu có gặp đâu, đúng không? Tại mình giảm thời lượng xuống còn hai tuần một lần. Mấy cái topic đang share với nhau từ cái idea đầu là mình fit mấy cái keyword để ngồi coi tiếp, học tiếp, tìm hiểu những cái mới để phát triển bản thân. Hiện tại mình giảm thời lượng họp xuống còn hai tuần một buổi, thì buổi cuối tháng 1 rồi, chặp sau Tết mới bắt đầu có buổi khác ha.
[71:49] Hiện tại sau Tết, định hướng của team mình, mấy cái dự án mà tụi anh, phần Minh Lê á, nó vơi ra về chuyện innovation diễn ra ở những lĩnh vực như vậy. Bản thân mấy anh em trong team management cũng thấy cái đó, thật ra dự án như vậy đang dần về, mình đang build, làm hết trơn rồi. Cả những sản phẩm cũng theo hướng đó. Như vậy là sau Tết có một pha rất thú vị về chuyện làm startup, rồi build public cái trend mà sau khi nhiều engineer bị layoff. Có cái là mấy bạn đó chuyển qua tự build cho bản thân, tự kinh doanh, tham gia hội build public á, lo một cái token hoặc triển khai một quan alpha. Tự nhiên anh thấy cái flow ra, chuyện bốn thứ đó có điểm chung rất thú vị, vô tình hướng team đi theo hướng mà anh nghĩ từ đây đến giữa năm sẽ đẩy nhiều hơn, trên vực tài chính in general.
[73:07] Nếu add cái framework đó vô thì gần như nó là một button repeatable, mình vừa có thể làm consulting trên đó, vừa apply hết kiến thức engineering vốn trước giờ khi làm mấy sản phẩm bình thường. Sản phẩm trước giờ chỉ làm trên dataset là list hay array thôi, giờ mình sẽ làm nhiều thứ khác, giải bài toán scale lớn hơn, làm application nhiều hơn được ha. Nếu muốn tự detect, tự lo cái trend của mình cho thị trường đầu cuối thì vẫn được luôn. Cái hướng rất thú vị, chắc để sau Tết, mấy buổi họp kế tiếp sẽ bắt đầu tiết lộ cho anh em. Với định hướng đó thì kỳ vọng mọi người cũng theo đó, thường định hướng của team sẽ quyết định tới nhân sự rất nhiều.
[74:28] Nửa là sẽ đổi chính cho đầu năm sau. Với suy nghĩ như vậy, hiện nay anh muốn tạm thời quên đi cái chuyện team mình là team làm việc remote default nữa. Tức là không còn default là vô thì sẽ bị remote với nhau. Anh mong muốn sau mấy buổi qua, team mình sẽ setup lại sao cho mình sẽ sắp xếp lại cái loop của mình tí, với mấy dự án hiện nay đang hơi chểnh mảng, chưa biết giải quyết thế nào.
[75:15] Toàn bộ dự án hơi cảm giác nhẹ nhàng á, anh đang gắn cái mác đó là retainer rồi check, cứ vô trỏng ngồi bình thường bình thường. Thì muốn có một cái policy công bố với anh em: từ sau Tết, mọi người sẽ phải đảm bảo lên văn phòng, với các bạn đang ở Sài Gòn nhé. Ở Hub Sài Gòn, mình sẽ không còn set cái chuyện làm việc remote default nữa, mà sẽ làm việc theo hub được ha.
[76:07] Hai cái hub official đang có, even là ba cái: Sài Gòn, Đà Nẵng, Hà Nội, thì sẽ phải kiếm chỗ ngồi lại với nhau, resume lại physical connection. Anh em sẽ phải commit 3 ngày một tuần. Hub Long An thì sao? Hub Chân Giang mấy đó thua mấy đó thua mấy nơi. Trong giai đoạn vừa rồi, cảm giác khi mọi người làm remote thì có cái alone zone rất ok. Alone zone sẽ work khi kiến thức đã sẵn, không thay đổi.
[77:05] Nhưng khi thị trường thay đổi thì mức độ trao đổi thông tin với nhau, nơi nào diễn ra càng nhiều thì nhân sự ở đó sẽ dễ thích nghi và phát triển hơn. Vì vậy, mấy anh em đang làm remote có khả năng rất cao là sẽ bị tụt lại, chưa biết sao. Có tuyển lại đó, anh sẽ post lại requirement sau cho chỗ Tân Nhật hả, Tân Nhật đúng không? Sẽ sắp xếp lại. Mấy anh em giai đoạn vừa rồi làm remote, khi thị trường không thay đổi về kiến thức thì có alone zone để tập trung làm việc rất thoải mái. Nhưng khi thị trường đổi tí, nơi nào thông tin diễn ra nhiều hơn thì anh em sẽ phát triển dễ thích nghi hơn.
[77:43] Đó là lý do tại sao nó diễn ra như hiện tại. Hoặc mọi người phải cực kỳ active trên online, hoặc phải gặp nhau offline, đó là cái buộc ha. Với policy đó, anh em sẽ có 1 tháng để xem thử thứ của mình như nào. Với cái đà thị trường chuyển dịch, event là Meta mới layoff, mới bị magaling, không update thêm đống người, 50% của đó, 3600 người, bỏ hết. Tất cả doanh nghiệp đều rất skeptical về chuyện phát triển cái gì mới, nên cơ hội làm remote hoàn toàn đang hạn chế dần.
[78:35] Đang không request mấy anh em thay đổi liền, nhưng anh đang có kế tiếp trước về chuyện như vậy. Trước nhất, anh em đang ở Hà Nội và Sài Gòn sẽ phải đảm bảo ngồi với nhau. Anh sẽ cố gắng sắp xếp team theo khu vực để mọi người resume lại cái của mình ha.
[79:29] Đó là 3 ngày/tuần. Trước mắt giữa mấy anh em với nhau thì chỗ anh Thành sẽ… Anh Thành từ khoảng giữa năm thôi, không, anh Thành sẽ relocate lại về Sài Gòn là một. Huy Nguyễn thì đang run cái office ở Sài Gòn rồi. Mấy bạn hay lên office Sài Gòn không vấn đề gì lắm. Hiện tại sẽ test trước với cái đó, nó là policy chính thức luôn sau Tết nhé. Với mấy bạn mà tụi anh biết là đang ở Sài Gòn thì sẽ require cái đó ha.
[80:14] Đó là thay đổi chính nhất trong vận hành. Chuyện thứ hai có thay đổi nữa là năm nay sẽ không có ref sharing. Những năm trước thì mình có chương trình ref sharing, năm nay chỉ có lương tháng 13 thôi. Cách đây khoảng tiếng rưỡi là anh đã gửi lệnh đi rồi, giờ mấy anh em đã nhận được lương tháng 13 của mình rồi. Nó là trung bình lương 12 tháng thôi, bạn nào vô trước thì theo tháng, đủ là đủ. Còn sharing năm nay thì không có.
[81:26] Một chương trình khác, sharing là khi doanh thu giữ mức cũ hoặc cao hơn, thì thường anh sẽ chích ra bao nhiêu phần trăm trong doanh thu để chia lại theo mức seniority của bạn trong team. 8 năm thì khác, 5 năm thì số khác, mà năm nay sẽ không có cái đó ha. Toàn bộ điểm tin nhanh cơ bản của team sẽ có những thay đổi đó. Nếu anh em quan tâm hơn thì chỗ Inno có gửi một bài lên trên kia rồi. Mấy nay đọc hết chưa nhờ? Đây, mọi người nhìn màn hình nhé. Có bài điểm qua, anh thấy việc team vận hành hiện nay đang rất tốt, mọi thứ đã vào rượt với nhau hết rồi.
[82:41] Bây giờ chỉ có lựa chọn thị trường nào, cơ hội nào để có biến động lớn, đột biến về thu nhập thôi, đó là cái chính. Còn với mô hình, cách vận hành hiện tại thì anh nghĩ rất happy với những gì đang diễn ra nhé. Nếu không còn gì khác thì chúc anh em tối nay ăn tối nhẹ nhàng, tình cảm với nhau ở hai địa chỉ. Hẹn gặp lại sau Tết với kế hoạch chi tiết hơn, recruitment mới hơn, cũng như mở ra lĩnh vực mới về tài chính. Anh nghĩ cơ hội đột biến tài chính cũng sẽ nhiều đó ha.
English transcript
[01:29] Alright, folks. It’s been a while since we were on stage. According to Thành’s plan, there are four presentations today as usual. I heard Phát mention four, just like every other time. But since there’s going to be a recap later, I think Thành wants to squeeze in one more.
[07:48] Let’s shift the schedule a bit, Thành. Originally, the other team was going to continue the Engineering series the one the artisan group had prepared and presented. But I think for now, we’ll postpone that. Maybe next week or after Tết.
[08:09] We’ll bundle it into a combo session and gradually introduce it to everyone, especially after that two-month stretch. As for the expanded topics and what’s next, we’ll save that for later. Let’s move to Biên’s part this is the second part of Minh Lưu’s talk on Erlang. He already did one last time, and now we want to review and get everyone’s thoughts.
[08:32] What did you think of the last session? Do you still remember it? This time the vote is kind of split. I guess we’ll bring up Minh Lê’s talk to check it out.
[08:53] Last time, I saw a few folks in the team starting to write things up it looked pretty solid. In the end, it got published today. So we’ll probably have two, maybe two and a half topics in total for everything. A few people are still missing. Where’s Anh? Where are the others? Everyone’s disappeared?
[09:34] Alright, come on up. Let’s do a quick recap. Hey, where’s Anh? There he is. Okay, looks like we’ve got everyone. Let’s get the others in too. Tuấn, you back from your trip? Did you buy anything? You’re hiding in the office, right? Must’ve had fun. If we’re changing the schedule, then let’s start with Minh Lê’s session first. That was two weeks ago.
[10:32] I saw a few posts already went live. I’d like to hear it directly and get a sense of the market report quality. Let’s let everyone see it too. I’ll also chime in a bit with the market section. After that, we’ll do the wrap-up. There are a few policy updates I want to announce.
[10:54] There’s going to be a small update coming up. Then we’ll do a year-end wrap-up. Inno already wrote a post for that. Let’s read it together and see how it looks. After that, we’ll get to the final presentation by Minh Lưu. I think it’s the same one Minh Lưu did last time.
[11:22] What was Minh Lưu’s last session about again? Wasn’t it about finite state machines in Erlang? Do you still remember anything from that? How would you rate it, just a quick take, like in one minute. Do you remember what it covered? How focused it was?
[11:57] That was last month, right? Minh Lưu did a talk on finite state machines. Do you remember how important that was? If so, why use Erlang for it when Elixir can do the same thing? Did Huy Nho work on that one? Did he join the session? I remember your team mentioning a lot about building state machines.
[12:26] Was Huy involved? Minh Lưu’s team Yolo is using that stuff in their projects, right? And on your side, at Ascenda, I think both teams have already adopted it. They’re building a framework, then the controller, and even a stage controller, right? On our side, we’re also experimenting with those ideas trying to figure out how to optimize state processing flow in our current projects.
[12:56] Like using round-robin mode, right? On this side, we define the states first. Then each state sets a context, like whether it’s entering a state or which state it currently is, so the outside logic just switches between them. As for the Yolo side, I’m not too sure, I haven’t read Minh Lưu’s write-up in detail yet.
[13:19] That should be good, right? A few more folks just jumped in nice. Okay, let’s have Minh Lưu go first. Minh Lê, hang tight for a bit. Come on up, Minh Lưu. Just share a bit, it’s important. The team needs to understand this direction better.
[13:41] You’ve got 10 minutes. That should be enough. This session continues from the last one. In a moment, I’ll explain again why this matters for our team. I really want everyone to understand this deeply. It’s a technique not widely used in Erlang, which makes it a bit special. Once we figure this out, we can apply it to other projects too.
[14:12] Alright, Minh Lưu, you’re up. I’ve got the slides ready. I’ll review a bit from the previous session so everyone can recall it better. That one included a behavior pattern, basically a way to define a module. You predefine some hooks, then handle different scenarios based on those. It’s kind of like a scaffold for core logic.
[14:49] Then you implement those hooks. The two most common are gen_server and gen_statemachine. For most modules, you can just write a server. Especially for simple state machines, gen_server is usually enough. But depending on the use case, you have to be careful, don’t just use them interchangeably.
[15:14] “Gen” stands for “generic” generic server. You should only use gen_statemachine when you really need more advanced features. For example, inserting events manually into a stage, or triggering a specific action when transitioning between stages. Those are things gen_server doesn’t handle well.
[15:36] If you want to automatically run an action when entering a new stage, that’s called a state entry. Or when you want to set timeouts between steps. In practice, gen_statemachine is used when you’re building something persistent—something that needs to hold state over time.
[15:59] Like a TCP connection, for instance. State machines are commonly used for that. When you’ve already defined a fixed set of states and need the connection to persist, gen_statemachine is a solid choice. For simpler stuff, gen_server is enough—no need to complicate it. Today, I’ll walk you through an actual code example so it’s easier to understand.
[16:24] Like Minh asked last time why use Erlang when Elixir can already handle this? And yeah, that’s true. You can implement behavior in Elixir the same way you do in Erlang. So today, I’ll do the example in Elixir so everyone can compare and see which approach is more practical.
[16:49] Elixir code looks a bit more readable. Do we have the slides? Here’s the one on gen, let me show you more detail so you can see how it works. Okay, I’ll insert the slides now. We’ll build a module that connects to a Redis server over TCP. I’ll keep it simple, just two stages so it’s easier to follow.
[17:34] Two stages only. This module sits between the user and the Redis server. It implements methods to establish and maintain the connection. For example, when the process starts a connection, all user requests will return a “disconnected” status. The user has no idea what the actual connection state is they only see what the proxy process returns. So, two stages: when the process starts, it’s in “disconnected”.
[18:21] It’ll try connecting to Redis. If the connection succeeds, it switches to “connected”. If the connection fails or drops, it goes back to “disconnected” and retries. The incoming requests client event requests are received as events. These can arrive in either disconnected or connected state. If disconnected, we just return that state to the client.
[18:41] If connected, we forward the request to Redis, get the data, and return it to the client. Why a state machine? Because we need features like insert event, like I mentioned. Here let me zoom in so you can see.
[19:39] First, we implement the behavior in the state machine and define the data structure. It has two parts: State represents the current stage of the module, and Data carries information between transitions—like host, port for connecting to Redis DB, and a map of client requests with client IDs. When the process starts, the first step is to connect to Redis in the background, while returning “disconnected” to the user.
[21:04] First, we define the callback mode with two things: the state function which means naming the functions in the module according to the stage name, for example, if the stage is disconnect, then the module will automatically run the disconnect function to handle it based on the name and arity and the state enter, which I’ll explain in a bit. We start with the init function, which returns next_event, meaning the module will automatically insert an internal event called internal_connect, with data being the host and port to connect to the Redis server, and then it immediately returns the disconnect state. When it returns disconnect, it jumps into the disconnect function to handle things. The disconnect function with internal_connect will open a TCP socket using gen_tcp to connect to the Redis server and start setting up the connection in the background.
[21:49] The part about state enter, I’ll explain that in a bit. That’s what the state function means. After that, we begin with the init function like I mentioned earlier. What does it do? It’s simple: at the start of the function, we use a term called next_event. What’s next_event? It means the module will insert like automatically insert an event into its own queue. This event is internal_connect, using the data host and port to connect to the Redis server, and then immediately return the state disconnect.
[22:43] When it returns the disconnect state like that, the first thing it does is run the disconnect function to handle the logic. What does disconnect with internal_connect do? First, it opens a TCP socket using gen_tcp to connect to the Redis server. But then I realized there are too many details, so I thought maybe I should try combining a few of the functions. You mind if I jump in and show you the part where it defines the two stages? That part looks a bit messy. Where exactly are the two states defined? You can see here it has a list over there, and we just have two states.
[23:48] Here are the two states, and four overlapping functions between disconnect and connect. Minh has four overloads of connect, but only two states, which is normal. In Elixir, function overloading works based on the parameter list, so it knows which one to run. What about the part where the state transition happens? Oh right, it’s inside each function.
[24:42] For example, in this connect function, when the connection is successful, it returns an atom next_stage, which switches the state to connect right there, along with the data. Got it, that’s the part that triggers the state transition. But with each overload like that, calling it implicitly like this is that okay? Normally, stuff like this should have a controller to manage it. Calling each one like this feels a bit messy. If there are 10 stages and we define and call them all this way, it becomes impossible to manage.
[25:01] Right at this part here, in our backend. Since we’re using state functions, there’s something called a handle_event function. When we switch to this mode, we only need to define a single function called handle_event. Just one function to manage all the states in there. If you want to write it that way, the system lets you choose between defining per-state functions or defining one handle_event function.
[26:14] Now where’s the diagram, have you looked into this or used it before? For a clearer picture, I copied a connection library that also connects to TCP. It’s written using gen_server, doesn’t use a state machine. It’s built kind of like a button logic. If the connection fails, it backs off and retries. It also manages users inside a map. But it’s a bit longer, you have to reimplement some of the built-in things like timeout, for example. It doesn’t come built-in so you have to code that manually. And to answer the earlier question yes, I just recently learned and started working with this. I’ve known about it for a while, but only recently started applying it. So how did it feel when I actually got into it? Why is it important? Because it defines some structured ways that make things more convenient. For example, for handling timeouts, it defines that based on the data we return.
[27:47] Here’s an example. When your connection drops, it jumps into the disconnect function to handle it, and you can return an atom timeout along with a time value. After that time passes, it’ll automatically jump into this function to process it for you. Yeah, so it helps make these things more convenient. You could write it using gen_server too, but that would be a lot longer. Okay, okay, thanks Minh. Minh Trần, any questions? Anyone else?
[29:14] Let’s have Minh Trần code this, and code it in Elixir. Since you know it already, have you touched this part before? And ask questions to help spread the knowledge to the team. So here’s how it works: the fundamental difference in programming with our team is that among all the modern programming languages right now, none of them have a built-in library for state machine management like Erlang. Erlang is the only one that was born for running these kinds of automatic systems, not from the traditional client-server mindset where a server just sits there waiting for requests.
[29:30] This is built-in, right? And with this kind of built-in feature, when you write code, two things happen. First, it forces the whole team to learn this language, and once they start using the tooling, it shapes a shared mental model a way of thinking that everyone can follow. When you encounter the right use case, you pull out the right tool and solve the problem by thinking about it this way.
[30:07] Back when we were doing things like the C4 model, we were already touching this stuff, weren’t we? It gives you the tooling. The second benefit is that it unifies everyone’s mindset. Of course, you can still code using gen_server the traditional way, that’s totally fine. No problem with that. But what makes Erlang special is that it has this built in.
[31:13] Once the team really gets this, managing a codebase through state machines, switching between states and objects, helps you keep the codebase much more maintainable. You avoid writing implicit code, bouncing it around in different places, not knowing where the transitions are actually happening. Instead, you can focus more on the logic and the structure, rather than getting caught up in the underlying data. Otherwise, in big codebases, bugs will pile up everywhere, and if you don’t look at it with this kind of mindset, it gets messy fast. That’s why this thing is special. For Erlang, this is what makes it stand out. In Elixir, there’s no official library built like this, so you still have to call into Erlang directly.
[32:08] Alright, that was a quick wrap-up of Minh Lưu’s talk. If he’s going to do a follow-up session, I’d recommend something a bit more complex, something more realistic. The last example only had two stages, which still looked simple. Maybe look for some open-source code from other teams, ones that manage more complex state. There’s this example I saw from another group that manages WebSocket state—it had a ton of stages. That example also used gen_statemachine, and the file was over a thousand lines. When they consolidated the functions, the structure became clear it wasn’t just code pushing back and forth randomly. There was a dedicated manager handling everything. So even if you lose track and come back later, it’s still easier to read than trying to understand a bunch of functions with custom names. That gets exhausting fast.
[34:18] Building a shared mental model within a team is super important. Thanks, Minh Lưu. Now over to Minh Lê.
Yeah, let me check how many minutes I’ve got. Ten minutes, right? Okay, ten minutes. I think I have four posts already?
Back then, the consulting team had the idea of doing a weekly series—one post per week summarizing info related to our testing side. But it wasn’t too deep on testing more of a general roundup. The first one I wrote was back in mid-December last year. It covered the release of Google’s Gemini 2.0 and OpenAI’s model that generates video chains.
[34:38] They had visuals showing it applied to patients, or healthy people wearing something like smartwatches to track their heart rates like what we wear. In the consumer space, the focus was more on secret tech, like rendering video similar to Sora. On the crypto side, they’re also embedding AI into fintech, gaming, infrastructure, and so on.
[35:21] Same goes for Y Combinator. They’re also saying AI should be applied to everything right now. At the moment, they’re encouraging research into stablecoins. In the past, they were promoting Bitcoin and Ethereum for payments. But after testing it on the market, they realized it wasn’t a good fit. So now they’ve shifted to studying stablecoins—aiming for enough market share that companies would invest money into R&D and build payment solutions.
[36:21] Here I’ll briefly mention a product an AI agent platform on Solana. They’re positioning it as a platform to build AI agents. These agents help manage wallets, generate tokens, trade automatically basically automating the kind of stuff crypto and DeFi users normally do. This product helps people get it done easier with AI support.
That was the first post. Moving on to the second. Out of the four, there are a lot. Now the real question is out of the four posts from last month, what do I think actually benefits our team?
[37:13] Yeah I think we’re on the right path now focusing on AI tech getting used to agent stuff blockchain and all that it’s growing fast booming really hot right now probably gonna see a lot of products diving into that soon the other tracks like what Y Combinator or a16z suggest might be a bit out of reach for our market so harder to jump in but last week I saw this report about money flow in and out of Southeast Asia for Q4 2024 these were the top sectors getting capital.
[38:23] First one’s challenger banks different from traditional banks fully digital I think in Vietnam we’ve got one that’s sorta digital but it’s not really what they define as a challenger bank like Timo they usually call that a neobank challenger banks are the ones that have a banking license they can issue their own digital banking products.
[40:08] Neobanks in Vietnam usually sit under a traditional bank’s license so they can’t release their own banking products in Southeast Asia VCs are pouring money into challenger banks because they think it solves the access to finance problem in underserved areas more so than crypto.
[40:30] I checked salary data too for IT in Southeast Asia Philippines is super competitive big population education’s solid IT workforce is huge working with foreign companies English is good pricing better than Vietnam even.
[41:26] Vietnam saw a huge drop in Q4 over 80% down meanwhile Philippines is booming ecom’s growing fast all the digital stuff kinda like where we were three or four years ago now they’re getting the investment okay interesting scroll up a bit everything above sounds like it’s tied to money right banking currency finance heavy focus on finance seems like that’s where SEA is betting big.
[42:39] If that’s the case maybe next week we can sit down and go through some potential lists try finding those ecosystem maps or system overviews from them can we find that yeah I’ll look for it most reports have those yeah okay anything else besides that this week’s quiet it’s Christmas not much news kinda dull I did bookmark a few new blockchain products they’re getting heavy capital inflows and locked funds blockchain huh show me Liquid yeah hold on they shared it in the chat already it’s solid.
[44:19] If that’s the direction then for writing this post I think there’s a good angle if you can frame it this way our team’s slogan from the start has been empower innovation meaning we look for where innovation is happening to find ways to work with them support them even invest if we can biggest value from doing this is spotting where innovation is instead of broad headlines we can pinpoint where the market’s pulsing here and there that’s where innovation’s happening inside that what’s the business model financial model answer those clearly it lines up with our core direction and helps us analyze business cases better too.
[47:25] Try that angle yeah thanks Minh we’ve been missing that knowledge has been kinda scattered this perspective helps when we review projects just ask where’s the sale where’s the money another way to ask is where’s innovation happening who’s building something new there’s where we can jump in and give it a look the stuff that already exploded we just retain and patch it up boring stuff alright that’s it for this part now quick year-end wrap up everyone’s going offline after this quick one Huy and Thành got your sections ready done already looks like it.
[47:50] This year the market shifted so much all the assumptions from before are out the window even our own people have moved around a bit right
[48:53] Our direction’s also shifted we used to focus on enterprise but then AI came and wiped out the whole thing now there’s chaos heading into finance and blockchain is where the flow is AI’s booming yeah but actual enterprise use still low everyone’s just chasing hype main trend is still around finance.
[49:55] Turns out our engineering team’s been researching and learning those exact topics so for year-end announcements how many awards do we have team got four awards plus one from community there’s one top-level award too others are kind of honorable mentions these are to recognize high performers across key areas of our team okay let’s announce them seven awards based on four main ones right.
[51:05] One team award then three others first one’s for the person who executed the AMA model best second one’s team lead of the year whoever led their squad the strongest third one’s for top consulting performer two projects that got great feedback both from team and from the client third one’s also a team award either for successful inhousing or trust-building and upselling for that team.
[53:38] Final award goes to the community folks supporters who aren’t official team members but still worked with us joined activities shared stuff so that’s four right Developer of the Year is based on MMA model meaning mastery autonomy second is research-oriented team lead third is consulting three individual awards one team award for the most impactful project others that didn’t have impact won’t be mentioned last one’s the community award and wait who’s even in the community this year felt pretty quiet right yeah someone did work with us a few months though.
[54:26] Alright let’s do a quick announcement let people in-out easily okay if I make it formal it’ll take too long so let’s roll with it someone react on Zalo or Slack so we can screenshot it two VIPs already confirmed good okay second award Thành you got that one what was it again check the notes yeah.
[55:58] Lead give us a quick reaction wait is this one individual yeah okay can we do a brief overview so far performance looks about the same as previous years not sure on the details go ahead yeah Huy might add more in a bit from what Thành saw and how Phúc did honestly in previous years Phúc mostly worked on internal and consulting this year moved to team Yolo.
[57:21] Honestly his role was kinda light compared to backend expectations before he focused mostly on iOS at first folks were skeptical about him but heard he adapted well in like five six months the team over there seemed pretty happy with him and they’re known to be tough Huy probably has more accurate comments since it was his project wait is that your feedback Huy he’s talking about me well I think he handled quite a lot pushed back where needed made suggestions.
[58:46] I think Thành picked Phúc because he met people’s expectations before he’d finish projects but stay quiet didn’t really engage his skills were always good but this year went beyond that like picking up new styles getting into loops exploring JavaScript TypeScript stuff he hadn’t touched before plus started getting into deadlines client timelines and pushing back like recently someone asked if he could finish fast and Phúc said nope not gonna make it let’s do it slower that’s a good sign and then he started getting assigned tougher development tracks not necessarily best overall but his trajectory’s impressive alright Superman Phúc are you coming up to say something.
[55:58] Lead, give us a quick reaction. Wait, this one’s personal, right? Yeah. Okay, can we go over it briefly? So far performance seems like previous years, not sure on the details, over to you. Right, Huy might give a more detailed comment later. But based on what Thành saw about Phúc this past year, actually in previous years, Phúc mostly worked on internal projects and consulting. This time he moved over to the Yolo team.
[57:21] Honestly, the role was kind of weak compared to backend depth expectations. Before that, Phúc was mainly focused on iOS. At first the team over there was skeptical about him, but apparently he adapted really well. In five or six months, the team there seemed to rate him highly, and I heard they’re pretty tough. Huy probably has the more accurate comments, since it was his project. Hey, this guy’s commenting about me. Actually I think those who worked on this contributed a lot, handling pressure, estimates, all that.
[58:46] But I think Thành picked Phúc because he matched expectations well. He’d done projects before but stayed quiet, didn’t communicate much, just got it done. Super talented, but this year he went way beyond that. For example, picked up new styles, loops, worked with JavaScript, TypeScript, even though before he wasn’t really involved with those. He also started reviewing stuff with clients, catching issues with deadlines. The best was when someone wanted to rush something and Phúc said no way, it won’t make it, take it slow. That was a good sign, and then he started being trusted with tougher, more intense features. Not necessarily the best, but probably the most solid expectations-wise. Alright, Superman Phúc. You coming up to speak?
[61:03] How am I supposed to sit like this, I just plugged in my headphones. I was pretty surprised, honestly. Was catching a ride to go do charity stuff and didn’t expect this. Don’t really know what to say, but seems like a lot of people heard already. Oh hey, Ngọc Thành just joined, long time no see. Phúc, can you hear us? He’s muted, I guess. I’m outside right now, so this is the second award. Do I think I deserve it? A bit shy to say, but honored. Yes, that’s right. Next award is from Huy, let’s go ahead and present it to the Yolo core team. Okay, Yolo team meaning?
[62:28] Yolo’s considered a standout team. Yeah, agreed. This is the last award, the rest goes to this person. This one goes to someone who spent about 2–3 months interning with us, mostly researching software-related stuff.
[63:20] Actually, Đạt had already been pretty active on our server even before interning. Even after the internship ended, he kept contributing to AI builds. The posts he shared got forked and reshared quite a bit by core team members. A great example of someone we want to support in the community. Đạt should probably say something. Đạt, the community award is yours. Where are you now?
[64:26] I’m outside right now, still on the way. Everyone’s done with meetings already? Thanks so much for the time. Honestly, Tom and Thành helped me a lot during onboarding and sharing stuff back to the team in a way that could be understood and used. Anything else? No, I think that’s it. Thanks again for your time.
[65:11] The way you’ve been sharing what you read with everyone is super appreciated, Đạt. Even now, in terms of internal knowledge sharing, that’s been one of the most valuable things. Because innovation is always shifting, and we haven’t had a chance to work closely together yet. But in the bigger picture, sharing cool ideas with each other like that is really meaningful. Thanks, Đạt. Now, final award, Thành. After that we’ll wrap up.
[66:14] Developer of the Year award goes to Biên. Everyone, give a quick in-out reaction. Biên, where are you? Please share the reason behind the nomination, go ahead. Alright, hold on everyone, okay. Last year and the year before, as you all know, we had this idea posted in the group we wanted to execute based on the AMA model: mastery, autonomy, and meaning. The way we determine the winner is by observing who in the team executed that model the best over the past year.
[68:23] This is something the team really wants to roll out, especially now that AI can help with unit work, solutioning, design systems, all that stuff. It’s become even more important lately. Biên’s been one of those folks who really seems to embody the core goals of the team most clearly. Everyone really enjoyed working with Biên recently, so that’s basically the main point.
[69:18] Biên, please say a few words, then we’ll move to the final part. What do you think, based on Thành’s comments? Thanks everyone. Even if things change, that’s alright. Let’s wrap this up here, that’s it for Biên’s part.
[70:21] Later, before we all head out to wrap up the year together, we’ve got a few new things to reorient after Tết. This is basically the final weekly sync, right? Next week we’re not meeting anymore, since we’re cutting the frequency down to once every two weeks. The topics we’ve been sharing starting from keywords and ideas are for us to keep learning and exploring to develop ourselves. Since the syncs are now biweekly, the next one will be the final one in January. After Tết, we’ll pick it up again.
[71:49] After Tết, the direction of our team and the projects we’ve been building especially the ones Minh Lê’s been involved in are leaning more into innovation in those specific fields. Even the management team sees that. Those types of projects are starting to come in, and we’ve been building them. Our products are heading that way too. So after Tết, there will be a very interesting phase of startup-style building and joining the build-in-public trend, especially after many engineers were laid off. Some of them have started building on their own, launching businesses, participating in build-in-public communities, launching a token, or deploying alpha features. I’ve noticed this natural flow of four themes coming together, and it’s led our team in a direction I think will continue through mid-year—focused more on the finance sector in general.
[73:07] If we plug that framework in, it’s almost like a repeatable button. We can do consulting based on that, and at the same time apply all the engineering knowledge we’ve built up from working on regular products. Products used to just be about datasets lists, arrays. Now we’re moving toward more complex problem-solving, scaling, and building real applications. If you want to self-detect and manage your own trend in the end market, that’s also possible. It’s a really interesting direction, and probably after Tết, we’ll start revealing more during future syncs. With that direction in mind, the team’s strategy will influence personnel decisions a lot too.
[74:28] Some changes will kick in at the start of next year. With that in mind, I want to temporarily move away from the idea that our team is default-remote. Meaning, it won’t be assumed that everyone just works remotely by default anymore. After the last few syncs, I’m hoping we can reset our rhythm a bit. Some of our current projects feel a bit scattered, and we’re not quite sure how to handle that yet.
[75:15] The whole project vibe feels a bit too casual. I’ve been labeling it as retainer work just show up and coast. So I want to announce a new policy: after Tết, everyone in Saigon needs to start working at the office again. We’re removing the remote-default setup for the Saigon Hub. Instead, we’ll move to a hub-based working model.
[76:07] We have two, even three, official hubs: Saigon, Danang, and Hanoi. Everyone should find a place to sit together again, rebuild that physical connection. You’ll be expected to show up 3 days a week. Yeah, those are a bit different. Over the past stretch, working remotely has been great for the “alone zone.” Alone zone works when knowledge is stable and not changing.
[77:05] But when the market shifts, the teams that communicate the most are the ones who adapt and grow the fastest. So if you’re working remotely, there’s a high chance of falling behind. We’re even thinking of reopening some hiring, I’ll repost the requirements soon. We’ll restructure things. Remote worked great when the knowledge was stable, but now that things are moving, you need those dense information zones to evolve faster.
[77:43] That’s why things are shifting the way they are. Either you need to be extremely active online or you meet people offline. That’s the hard rule. With this policy, you’ll have one month to figure out what your setup looks like. Given the way the market is moving, Meta just laid off another batch, didn’t update the rest, dropped 3,600 people everyone’s skeptical about building new stuff. So fully remote opportunities are starting to shrink.
[78:35] We’re not asking anyone to change overnight, but this is the direction. First, everyone in Hanoi and Saigon should start sitting together again. I’ll try to arrange teams by region so you can get back into your flow.
[79:29] So that’s 3 days per week. At the moment, with our current members—Thành, for example he’ll relocate to Saigon sometime mid-year. Huy Nguyễn is already running the Saigon office. Folks who’ve been going in regularly shouldn’t have any issue. We’ll test this out first, and it’ll become the official policy after Tết. Everyone we know who’s currently based in Saigon will be required to follow it.
[80:14] That’s the main change in how we operate. The second change is: there will be no ref-sharing this year. In the past, we had a ref-sharing program, but this year there’s only the 13th-month salary. About 90 minutes ago I pushed the button, so everyone should have received it by now. It’s calculated as the average of your past 12 months’ salary. For newer folks, it’s prorated by month. But no extra sharing this year.
[81:26] The sharing program usually kicked in when revenue stayed stable or grew. In those cases, I’d take a percentage of revenue and distribute it based on team seniority. Someone with 8 years would get more than someone with 5, etc. But this year, there won’t be any of that. That’s a quick summary of the core changes in how the team’s operating. If anyone wants more info, Inno posted an article earlier have you all read it? Alright, take a look at the screen. There’s a post there. I think the way we’re running things now is going really well. Everything’s clicking together.
[82:41] Now it’s just a matter of choosing the right market and spotting opportunities that can trigger major income jumps that’s the real goal. With our current model and the way we operate, I’m really happy with how things are going. If there’s nothing else, enjoy dinner tonight with the team at either of the two meetup spots. We’ll reconnect after Tết with more detailed plans, new recruitment, and new directions especially around the finance sector. I think there’ll be a lot of breakout financial opportunities ahead.
