This post describes some of my thoughts from watching the changes over the first six months.

Another “wow” moment

Business people, especially the non-IT ones, are the most excited about AI in the company — more passionate than even the IT guys and technical people.

I think it’s common sense. That is another “wow” moment since the ChatGPT days, like from zero to one.

They work 10 hours at work and spend nights and weekends on AI. They send their app at 3 am and have a lot of questions about skills and MCP when they meet me in the morning.

We expected they would love it, but never imagined they would love it this much.

Motivation is the most important thing for change.

IT’s mission is to build innovation platform and data connectors to leverage how business works with AI.

Everyone can code

Across all our Agentic AI topics, coding is the one people picked up and used most effectively.

Nearly 50 apps were built in the first month. They are not simple landing pages but real business applications.

Agentic coding (or vibe coding, as it was called) proves that software will rely more on people who deeply understand the business domain.

I see business people in my company build very complete, well-finished web applications for their job. If a scrum team built that application, I’m sure they would miss some edge cases, but that doesn’t happen when the business builds it.

Today they build their daily work applications, but maybe by the end of this year, they will sit by a developer and do almost all the prompting to AI to code their business applications — the space of software engineers.

We will not need UI review round trips, no need to showcase back and forth.

If that happens, I think software delivery time will go extremely fast.

Coding Agent eating the world

“All in one packaged” agent platforms like Claude Desktop or Kiro IDE are so strong, and stronger day by day.

Last year, we built Python agent applications to loop, handle errors and send prompts to the LLM API, but that is not needed now. By now, all we need is to talk to them.

In my company, more than 80% of our people have an AI platform account to use as a personal assistant.

There is an analyst who uses CLI agent for his research job. He built a dynamic workflow that looks elegant and is much more powerful than I expected.

Prompt engineering matters less and less. What we need now is skills — not because the agent is not smart enough, but because we have “hidden things” still in our heads, and skills are the way to guide AI to follow them.

These thoughts push us to go further with AI transformation, starting with the technology team.

First is the mindset change. Engineers are comfortable with AI coding as a tool. Now they need to treat it as an autonomous agent.

The bottleneck now is people. So the next step is to reduce the human-in-the-loop role of each engineer in their own tasks.

Mình đang làm trang web cung cấp tính năng convert các loại tài liệu có cấu trúc (doc, pdf, ….) thành markdown. Như các bạn biết, markdown là định dạng friendly and token-saving nhất với AI bây giờ.

Tính năng convert đã hoạt động chuẩn, mình muốn giao diện sinh động hơn, nên bảo Claude Code làm một thay đổi nhỏ: Khi người dùng upload file lên, thì ở phần hiển thị selected file sẽ có icon tương ứng với loại file đó.

Việc bé tẹo, và vẫn có sai, nên mình muốn kiểm tra xem vì sao Claude sai, dưới đây là quá trình Claude làm, mình hỏi và sửa cu cậu.

Quá trình

• Mình bảo Claude làm tính năng.

Tính năng bé, cu cậu chẳng cần dùng skill gì, code luôn, nửa phút sau báo lại :

• Mình run lại app, kiểm tra thì thấy icon file vẫn như cũ, không thay đổi theo loại file, tức là code mới không chạy, liền hỏi lại. Nhưng cu cậu già miệng bảo không, code đúng rồi, có thể là browser cache, bla bla, …..

• Mình cũng làm lại, thấy không được, lần này mình cứng giọng hơn. Thế là cu cậu tự chạy code, tự curl page, tự verify và tìm ra được chỗ sai.

Note ở đây là mình đã có mô tả rule ở CLAUDE.md rằng mọi thay đổi về user-facing đều cần được thực hiện e2e test, nhưng cu cậu không làm

• Lần này It works thật.

• Tuy nhiên mình muốn tìm hiểu vì sao cu cậu sai, và làm sao để không sai nữa.

Như dạy con vậy thôi, sẽ có lúc con sai, nhưng vì sao sai và bài học kinh nghiệm là gì mới là thứ quan trọng hơn.

(đoạn dưới dài hơn, mình lỡ clear session để làm tiếp rồi, nên không chụp thêm được)

• Sau đó, Claude show là cu cậu đã ghi nhớ kinh nghiệm này vào file feedback memory của project, tại thư mục ~/.claude/projects/xx-markitall/memory/

  Đấy chính là vùng nhớ “Auto memory” của Claude Code:

- [Verify served HTML for UI edits](feedback_verify_served_html.md) — curl the live route + match user's auth state before declaring UI work done; cache is a last explanation, not first

---
name: feedback-verify-served-html
description: "For UI edits, verify against the live server response (curl the route, grep for the new symbol) before declaring done — and reproduce in the user's exact auth/session state, not just any state"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 9bb9d74d-df31-4ff7-bf81-49060f76739b
---

For any UI/template change, before telling the user it's done:
.... <<rule below>>.....

• Và, gần như ngay lập tức, ở session sau đó, khi implement xong, Claude tự lôi kinh nghiệm ra từ memory và làm đúng như đã hứa, chạy app, curl thông tin để verify.

Good job!

Về cơ chế Auto Memory

Theo official doc, cơ chế Auto memory bắt đầu có từ phiên bản Claude Code v2.1.59 (cỡ tháng 2 năm nay).

Theo mình đây là cơ chế cực kỳ hữu ích, cho phép Claude tự động tích luỹ kiến thức qua nhiều session làm việc mà không cần người dùng phải chủ động làm gì.

Không phải session nào Claude cũng ghi, mà cu cậu sẽ tự lựa chọn cái gì đáng ghi nhớ và có ích cho các phiên làm việc tương lai.

~/.claude/projects/<project>/memory/
├── MEMORY.md          # Concise index, loaded into every session
├── debugging.md       # Detailed notes on debugging patterns
├── api-conventions.md # API design decisions
└── ...                # Any other topic files Claude creates

Nếu bạn lo về context loaded, thì yên tâm, khi session init, Claude chỉ load 200 dòng đầu tiên của file MEMORY.md mà thôi. Thường thì file đấy không dài dòng đến vậy, đây như một file chỉ mục, dài lắm chắc cỡ 50 dòng.

Việc gọi vùng trí nhớ này mặc định là tự động, mỗi khi Claude thấy cần, như khi fix lỗi, debug, thiết kế hệ thống phức tạp, …. Tất nhiên vẫn có cách để chủ động bảo Claude active lên, tựa như gọi skill mà không gõ slash, ví dụ: “Recalled memory on …”.

Kết lại

Bên cạnh việc build skill hay workflow để làm việc với Claude Code, mình thường dành thời gian để đọc conversation log và trao đổi với công cụ này.

Theo mình, việc hiểu cơ chế hoạt động và quen thuộc với cách LLM model trả lời là yếu tố quan trọng để mình đưa yêu cầu đủ tốt, cũng như kiểm soát được hành vi của công cụ Agentic Coding số 1 này.

Vậy nên cũng như làm việc với con người, dành thời gian quan sát và chỉ bảo, tin rằng cu cậu AI này sẽ ngày càng tốt hơn. Chẳng phải cách đây vài tuần, chính Anthropic ra bài báo về “hành vi cảm xúc” của LLM model đấy sao?

Dẫn dắt bằng việc đọc 2 blog về long-horizon coding của Cursor và Anthropic. Bài của Cursor khá sơ lược, chưa thể hiện rằng họ đã làm như thế nào. Tuy nhiên với bài của Anthropic, họ viết chi tiết về 2 việc họ làm: 1 là điều phối các Claude Code session, 2 là provide testing một cách thông minh. Việc số 1 chính là Agent Harness.

Trong 1 video của LangChain, họ đưa ra sơ đồ kiến trúc tổng quan của một Reliability Proactive Agents (OpenClaw là ông nổi tiếng nhất của hội này) gồm 3 layer: Agent, Harness, Underlying: Model, Runtime (Sandbox). Trong đó Harness điều phối workflow, gọi tool, xử lý code execution, call model, …, trong một môi trường sandbox.

Cách đây cỡ 2 tháng, Cursor ra bài về Agent Harness, OpenAI cũng có bài thì phải; song song mình đọc được một bài tổng hợp công phu trên X.

Mấy ngày trước, Anthropic ra bài blog: Harness design for long-running application development. Mình nghĩ đây là lộ trình cần đi để thực sự đạt được autonomous agentic coding, giải phóng bottleneck ở con người trong việc xây dựng phần mềm.

Mình tổng hợp ở đây một số blog, video, opensource để đọc dần, sẽ viết bài thu hoạch chi tiết sau:

• Langchain: Tách riêng 1 mục cho Langchain, đây là foundation về AI workflow, có lẽ các thư viện của Langchain sẽ được dùng nhiều cho các bài toán Harness ở các công ty còn lại.

  • Improving Deep Agents with harness engineering

  • Conceptual Overviews: Frameworks, runtimes, and harnesses

• Agentic Coding top tier:

  • Anthropic

    • Harness design for long-running application development

    • Building a C compiler with a team of parallel Claudes

  • OpenAI:

    • Unlocking the Codex harness: how we built the App Server

    • Harness engineering: leveraging Codex in an agent-first world

  • Cursor

    • Scaling long-running autonomous coding

    • Towards self-driving codebases

• Video hay ho:

  • Open Models, Open Runtime, Open Harness - Building your own AI agent with LangChain and Nvidia

  • Andrej Karpathy’s Math Proves Agent Skills Will Fail. Here’s What to Build Instead

    • Cậu này hướng dẫn 6 eps để tự build 1 Agent Harness từ đầu. Đặc biệt là hệ thống hoá 12 things need to know để build reliability agent system.

• Opensource đáng để tìm hiểu:

  • DeepAgents from LangChain

  • DeerFlow (Deep Exploration and Efficient Research Flow) from ByteDance

  • Goose - Coding Agent from Block

  • Minions - Coding Agent from Stripe

    • Không phải opensource, tuy nhiên Stripe viết 2 bài blog rất chi tiết về cách họ xây dựng Coding Agents cho chính công ty sử dụng.

• Proactive Agents:

  • OpenClaw

  • NanoClaw

• Awesome sandboxs:

  • E2B

  • Daytona

  • Sandbox by Cloudflare workers

  • OpenSandbox from Alibaba

  • OpenShell from Nvidia

  • Symphony from OpenAI

Disclaimer: Mình làm việc văn phòng, công việc bận, trong một năm nếu đếm số ngày rời văn phòng còn nhìn thấy mặt trời thì chưa hết 1 bàn tay. Mình cũng không phải type nghiên cứu sâu về kỹ thuật chạy, luyện tập thì không try-hard, ở mức vừa phải, trang bị phụ kiện cũng vậy, ở mức vừa đủ. Do vậy, những gì mình viết là chủ yếu là kinh nghiệm; phần lý thuyết nếu có, là mình tự rút ra từ trải nghiệm.

Tuy nhiên, đấy cũng là cơ sở để mình cho là khi mình hoàn thành được cự ly này, thì những người làm văn phòng giống mình, những người ít thời gian luyện tập, không cố định được theo lộ trình rèn luyện, cũng có thể làm được.

Quá trình chuẩn bị

Theo mình, cho cự ly này, bạn cần chuẩn bị hai thứ: Lý do để chạy và nền tảng thể lực.

Lý do để chạy

Đến một độ tuổi, sức khoẻ là lý do lớn nhất.

Với lý do đó, bạn có khá nhiều lựa chọn. Chạy bộ cũng như đạp xe, bơi lội là môn thể thao buồn chán. Nếu bạn thích những môn thể thao đối kháng, bạn thích rèn luyện kỹ thuật cá nhân, sẽ có những lựa chọn tốt hơn. Còn khi đang băn khoăn chưa biết chọn gì, hãy thử chạy bộ.

Thứ nhất, là môn thể thao cá nhân, chỉ cần 1 đôi giày để bạn bắt đầu chạy. Đôi giày chạy đúng nghĩa đầu tiên mình mua ở Decathlon với giá chỉ 300 nghìn.

Thứ hai, môn này dễ tổ chức giải phong trào, từ đó dễ đăng ký, dễ có thành tích, dễ có huy chương. Mình không chạy vì thành tích, nhưng thành tích là động lực cho kỷ luật. Mà kỷ luật tập thể dục là thứ xa xỉ khi chúng ta ít thời gian.

Nền tảng thể lực

Cùng với sở thích leo núi, mình từng đạp xe các cự ly 150-180km dưới nắng hè, đã hoàn thành 2 FM road và 1 FM trail. Nhìn lại, những trải nghiệm vận động đó là nền tảng để mình hoàn thành cự ly 70km vừa rồi.

Ultra trail là chạy ở cự ly dài và dốc. VMM thì có đặc sản là rất dốc. Cự ly 70km vừa rồi có gain leo lên là 4000m. Để so sánh, cự ly 42km ở giải Cúc Phương Jungle 2023 mình đi có gain cỡ 2000m. Tức là độ dài và độ cao gần gấp đôi. Leo lên đã khó, leo xuống còn vất vả hơn, mình sẽ đề cập đến cái vất vả này ở phần sau khi mô tả trải nghiệm trong race.

Nếu không chuyên, bạn cần từ 15-20 tiếng để hoàn thành. Mình đi hết 20 giờ 30 phút, về đích lúc 23h30 đêm, còn 30 phút nữa là hết COT. Để chuẩn bị cho quá trình di chuyển bằng chân cả ngày dưới cái nắng cuối hè, leo dốc lên, leo dốc xuống, chỉ nạp năng lượng bằng gel, hoa quả, 1-2 bát cháo, bạn cần chuẩn bị nền tảng thể lực.

Cần tạo điều kiện để cơ thể làm quen với trạng thái vận động dai dẳng và quá tải, từ đó tạo thành nền tảng không chỉ ở cơ bắp, mà còn ở các cơ quan hô hấp, tim mạch và đặc biệt là hệ thần kinh. Một khi đã quen với trạng thái này, việc lặp lại cường độ vận động mạnh trong race sẽ dễ dàng được cơ thể chấp nhận và vượt qua.

Quá trình này là bắt buộc hay không, mức độ thế nào phụ thuộc ở cơ địa mỗi người. Ý tưởng của mình ở đây là càng chuẩn bị đường dài, thì việc luyện tập ở giai đoạn sát ngày race càng ít áp lực, đặc biệt với những người làm văn phòng mình.

Thử chuẩn bị bằng việc hoàn thành 2 FM trong 1 hoặc 2 năm liên tục. Đó cũng là động lực để bạn đăng ký cự ly ultra trail đấy.

Đăng ký cự ly Ultra-Trail

Mình có theo dõi một anh trên YouTube, sau khi hoàn thành cự ly 100 miles (160km), anh nói rằng “Sau giải này, không biết mình còn chạy trail nữa không, đây là bộ môn tốn tiền và thời gian”.

Quả là vậy, bạn cần tập, dù ít, dù nhiều. Bạn cần đầu tư phụ kiện, BIB, chi phí đi lại, ăn ở.

Do vậy, chưa nói đến tập thế nào, chạy ra sao, việc đầu tiên là xuống tay (tiền) đăng ký giải.

Với cá nhân mình, có 3 thứ khiến mình đăng ký giải này: Cảm hứng, đồng đội và chán chạy.

Cảm hứng

Mình có người truyền cảm hứng.

Đấy là người anh, sếp trực tiếp ở công ty. Anh là người đầu tiên chạy được 42km ở công ty, từ đấy 42km trở thành tiêu chuẩn nhập câu lạc bộ chạy. Ai chưa được 42 thì chỉ có nhức tai.

Đầu năm, anh đăng ký và rủ rê mọi người đăng ký VMM 70km. Rút kinh nghiệm lần trước để anh chạy 42 mà mình chỉ 21. Lần này mình và cả nhóm cùng đăng ký theo.

Đôi khi cảm hứng phi lý cũng là tác động tốt, nó cho ta lý do không cần thuyết phục.

Đồng đội

Ngoài một số buổi cùng anh em lên Hàm Lợn, phần lớn thời gian mình tập chạy một mình. Vào giải, cả nhóm chỉ chạy cùng nhau độ 2km, sau đó thân ai nấy lo.

Ấy vậy nhưng khi đăng ký, đấy là tinh thần tập thể, cả nhóm cùng quyết tâm.

Ở công ty mình có CLB cỡ 30 người chạy cùng nhau ở các giải. VMM vừa rồi CLB có người chạy ở khắp các cự ly, từ 21 đến 70. Cũng bởi vì đi cùng nhau, nên đăng ký giải chạy cũng là cơ hội để đi chơi cùng nhau. CLB phân công luân phiên mỗi năm một người đại diện tổ chức, rất hài hoà và bài bản. Khuyến tổ chức thành công VMM năm nay, VTM tháng 1 tới do Trung tổ chức, kỳ vọng thành công gấp 7 lần.

Nghĩ lại thì không nhớ việc cùng nhau đăng ký giải có trước hay CLB có trước, nhưng rõ ràng rằng nếu không có đồng đội rủ nhau và cùng đăng ký, riêng mình sẽ chẳng một mình đăng ký giải chạy ở xa xôi như vậy. Mà đa phần các giải Ultra thì đều ở xa Hà Nội.

Chán chạy

Vợ mình bảo “người ta nói mỗi ngày chạy 5 cây còn tốt hơn cả tháng chạy 100 cây”. Vốn không tin các nghiên cứu trên con người, nhưng câu này dù đúng hay sai cũng không nhiều ý nghĩa với mình.

Thật thà mà nói, mình nhác chạy. Ngay cả khi đã đăng ký giải, mình không tập nhiều như các giáo án đọc được trên internet. Vậy nên nếu không có động cơ đủ mạnh, mỗi ngày chạy vài km, hay thậm chí tuần nào cũng chạy, là điều không khả thi với mình. Cái mình cần là một mục tiêu.

Mục tiêu mỗi lần cần mới hơn và để đủ mạnh thì cần cao hơn. Từ 2022 đến giờ, mỗi năm mình đều đăng ký ít nhất 1 giải marathon để tạo mục tiêu khiến mình luyện tập.

Đi khám sức khoẻ, bác sĩ khuyên mỗi ngày nên tập thể dục 30 phút để giữ gìn sức khoẻ, cải thiện các chỉ số định lượng. “Cải thiện” và “sức khoẻ” là các mục tiêu định tính, còn cự ly, ngày chạy là các mục tiêu định lượng. Đạt được mục tiêu định lượng, phần định tính sẽ tự tốt lên. Minh chứng rõ ràng là việc luyện tập cho VMM 2025 làm các chỉ số in đậm, in đỏ ở kỳ khám sức khoẻ 2024 đều chuyển sang in thường, in đen ở kỳ khám 2025.

Có một điểm mình rút ra được trong race 70km, đó là sự thay đổi về góc nhìn phần đường còn lại khi mục tiêu lớn dần. Lúc chạy HM, 10km sau vẫn cảm nhận là dài. Chạy FM, 21km cuối chỉ là 1 nửa, và 10k còn lại là một quãng ngắn. Khi chạy 70km qua CP4, tức là đã được 39km, nhìn bản đồ đường chạy, mình tự nói rằng “cố lên, chỉ còn hơn 30km nữa thôi”.

Luyện tập

Như đề cập ở trên, mình không phải là người kỷ luật theo phương pháp hay giáo trình, nhưng mình nghĩ, nếu không đọc hay được nghe về các bài tập, mình sẽ không đủ kiến thức để tập đúng cách.

Rất may mắn, trong nhóm của mình có một người ham thích tìm hiểu, nắm vững lý thuyết và đam mê chia sẻ, là anh Ngọc Võ.

Từ việc nghe chia sẻ, qua các buổi tập, mình thấy có 3 khía cạnh cần luyện tập: Chạy, tập bổ trợ và trải nghiệm thực tế.

Chạy

Chạy là bài tập đầu tiên. Bạn cần chạy để luyện chân, luyện lục phủ ngũ tạng và nâng cao thể trạng.

Khi đăng ký giải, mình có hỏi ChatGPT, là tập trong 6 tháng có được không. Câu trả lời là khó khả thi, vậy nên mình không nhờ nó lên lịch trình luyện tập nữa.

Điểm tích cực là mình vừa hoàn thành FM ở giải Di sản Hạ Long tháng 11/2024 nên việc luyện tập trở lại vào sau Tết khá dễ dàng, cơ thể không phải làm quen lại từ đầu.

Do thời gian eo hẹp, suốt 6 tháng trước race, mình chỉ tích luỹ 60-80km đường road/tháng. Con số này là ít hơn nhiều so với khuyến nghị, thường từ 30-50km/tuần. Thêm nữa, mình chạy rất chậm, pace cỡ 7-8, mỗi buổi chỉ chạy được 10km trong cỡ hơn 1 giờ là hết thời lượng cho phép.

Khó có công thức chạy bao nhiêu là đủ. Để chuẩn bị cho VTM 2026, nhóm mình lập hội chạy tối thiểu tăng dần từ 25-30km/tuần, mới đến tuần thứ 4 mình đã cảm thấy chán trở lại rồi, đấy là dấu hiệu không tốt. Vận động là quá trình hài hoà giữa thể chất và tinh thần. Sẽ có những ngày bạn cảm thấy chạy không biết mệt, và ngược lại.

Kinh nghiệm của mình là giữ nhịp độ chạy-nghỉ cỡ 2-3 ngày, với nhịp 5-7km / 2 ngày trong tuần, 10km / 1 ngày cuối tuần, như cái lò xo không căng, không giãn vậy, vừa co về lại kéo ra.

Tập bổ trợ

Tập chạy như trên có thể giúp bạn hoàn thành được 70km road đấy. Còn để chạy trail, bạn cần tập thêm các bài bổ trợ.

Có 2 thứ cần bổ trợ: Các vùng cơ bắp chuyên cho leo dốc và tập tim-phổi.

Làm sao để biết vùng cơ bắp nào cần tập? Đầu tiên là tìm hiểu lý thuyết bằng xem hướng dẫn trên Internet và YouTube, sau đó là luyện tập ở thực địa. Mình sẽ mô tả riêng phần thực địa ở bên dưới. Về lý thuyết, cần tăng sức mạnh cơ tứ đầu đùi; vùng cơ bắp chân, gân cơ Achilles và cổ chân.

Mình luyện cơ tứ đầu đùi bằng bài tập squat với dây kháng lực 25kg kèm bài lên xuống 1 chân (chân còn lại duỗi) học của bạn Nhơn Trọng. Mỗi sáng squad 50 cái, lên xuống 10 cái mỗi chân. Tác dụng thấy rõ sau vài tuần.

Gân cơ Achilles và cổ chân mình tập cùng dây kháng lực 30kg theo hướng dẫn của anh Ngọc Võ. Để tập bài này, bạn ngồi xuống, duỗi chân, đưa dây kháng lực qua phần trên lòng bàn chân, kéo căng dây đến cỡ đầu gối; sau đó dùng cổ chân co-duỗi bàn chân. Bài tập này giúp cổ chân vững, tăng khả năng đàn hồi của các gân vùng cổ chân. Trong race có ít nhất 3 lần mình bị lật cổ chân mà không hề hấn gì.

Mình sẽ gửi link hướng dẫn những bài tập trên ở cuối bài này.

Để tập tim-phổi, ngoài số buổi ít ỏi lên tập ở Hàm Lợn, mình chủ yếu tập bằng cách leo cầu thang. Chung cư nhà mình có 40 tầng, mình sắp xếp mỗi tuần leo 2 buổi, mỗi buổi leo 3 - 4 lượt, tức là cỡ 100 - 150 tầng leo lên. Cũng vì chạy chậm, mình ưu tiên leo cầu thang hơn chạy, cùng một lượng tiêu thụ năng lượng, thời gian giành cho leo cầu thang là ngắn hơn.

Cách leo của mình là leo liên tục 10-15 tầng, khi tim lên vùng 160-170 thì mới nghỉ một lúc rồi lại leo tiếp. Cảm nhận của mình là việc này giúp rèn khả năng hồi phục nhịp tim, nhanh chóng quay trở lại trạng thái nhịp bình thường, phản ánh sự hồi phục của hệ hô hấp.

Trong trail run, việc bạn đi xa được đến đâu phụ thuộc vào cơ thể bạn hồi phục nhanh ra sao mỗi khi leo một con dốc, vượt qua một ngọn đồi.

Trải nghiệm thực tế

Theo mình, có hai hình thức trải nghiệm thực tế bạn nên làm: Trải nghiệm địa hình và trải nghiệm thể trạng.

Trải nghiệm địa hình

Mình trải nghiệm địa hình bằng việc tập chạy và leo núi ở Hàm Lợn. Đây là địa điểm gần Hà Nội nhất để thử nghiệm chạy địa hình trail. Cỡ 1 tiếng đi xe từ Cầu Giấy đến điểm xuất phát ở Trang Thiều camping.

Chạy ở đây giúp mình quen với mặt đường đất, đường sỏi đá và đường núi. Sự đa dạng về mặt đường khiến bàn chân và cổ chân quen với việc thay đổi tư thế, chứ không giữ nguyên một nếp như chạy đường road. Luyện leo núi, nhất là những đoạn dốc đứng chính là sự chuẩn bị không thể tốt hơn cho những con dốc ở VMM.

Hồi đầu năm, khi đăng ký, trong cơn hưng phấn adrenaline, anh em trong nhóm hẹn nhau cứ 2 tuần sẽ lên Hàm Lợn 1 lần. Kết quả là 3 tháng đầu chỉ đi được ... 1 lần.

Từ tháng 5, mình cố thu xếp mỗi tháng lên tập ít nhất 1 lần. Mình thường đi cung 13km với gain ~800m, từ Trang Thiều, lên đỉnh, xuống Pitstop, về Thiên Phú Lâm rồi quay lại Trang Thiều.

Trải nghiệm thể trạng

Trải nghiệm tiếp theo cần thử là trải nghiệm thể trạng. Đó là việc đưa cơ thể vào trạng thái đốt cạn năng lượng với mục tiêu làm quen với trạng thái tâm lý và thể chất đó.

Theo mình, cơ thể chúng ta có khả năng làm quen và tương thích cực tốt. Ở lần đầu tiên tập bài leo ngược lại dốc Há Mồm lên đỉnh để về Trang Thiều, giữa cái nắng tháng 8, dữ liệu đồng hồ cho thấy mình tiêu thụ gấp rưỡi lượng kcal so với cung cũ, mình cảm thấy hoàn toàn kiệt sức, phải làm mát và nghỉ 1 tiếng sau đó mới lên xe về nhà. Đến bài tập tháng 9, hoàn thành 1 vòng, mình quay lại đỉnh 1 lần nữa rồi đi xuống, cự ly dài hơn (21 - 13), gain nhiều hơn (1000 - 800), năng lượng tiêu thụ nhiều hơn (2k8 - 2k4) nhưng cảm nhận cơ thể khoẻ, hồi phục chỉ sau vài phút nghỉ ngơi.

Bài tập tiếp theo là chạy lúc giữa buổi, từ 9h - 11h sáng hoặc 2h-4h chiều. Mình tập những bài này là do hoàn cảnh xô đẩy, có những cuối tuần chỉ thu xếp được thời gian vào giờ đó. Đến khi vào race, đứng giữa cái nắng chói chang cuối chiều ở CP5 mới thấy giá trị những buổi tập này.

Đi về mới biết dân tình gọi đấy là heat-training. Quả thật là may mắn.

Trải nghiệm trong race

Mình chia trải nghiệm hơn 20 tiếng đồng hồ từ 3h sáng đến 11 rưỡi đêm thành 3 phần: Kinh nghiệm thực tế, trải nghiệm tinh thần và vai trò của may mắn.

Một số kinh nghiệm thực tế

Dễ dàng tìm được các video chia sẻ trải nghiệm và cung đường của các cự ly VMM cả các năm trước lẫn năm 2025 nên mình chỉ liệt kê một số kinh nghiệm thực tế của bản thân qua race vừa rồi.

• Mặc dù race-plan fail ngay từ CP2, nhưng việc lên trước plan là cần thiết.

Trước giải, mình với Trung ngồi làm race-plan cùng ChatGPT. Hai anh em lạc quan xác định đến CP2 lúc 8:00, CP3 lúc 10:00, CP4 ở 13:55 và về đích lúc 21h30, dư 2 tiếng rưỡi.

Nhưng thực tế khác xa dự kiến. Đoạn CP2 lên CP3 khó không kém CP3 lên đỉnh đồi Bò, mình tốn 2 tiếng rưỡi từ CP2-CP3, và 2 tiếng từ CP3 lên đỉnh.

Sai lầm thứ hai là bọn mình cho rằng, qua được CP4, tức qua dốc đồi Bò là coi như về đích. Thực tế hoàn toàn ngược lại, sau CP4 mình liên tục phải đuổi COT với các con dốc 400-600m gain, dưới ánh nắng chiều và với thể trạng đã kiệt sức cho 40km đầu tiên.

Tuy nhiên, giá trị của plan là để nhận ra khi nào mình bắt đầu fail so với plan ban đầu. Khi đến CP3, gặp Đức chờ ở đó, nhận thấy đã trượt so với plan tận 1 tiếng, mình chỉ dừng lại 2 phút tiếp nước, dắt lưng vài quả quýt rồi đi thật nhanh. Đoạn từ CP3 lên đỉnh đồi Bò và tiếp đó là xuống dốc, gần như mình không nghỉ suốt 9km, đến CP4 trước COT chỉ 30ph.

Nếu không định sẵn plan để phát hiện là trượt, có thể mình đã không kịp đến CP4 với mốc COT 15h00.

• Cần bổ sung dinh dưỡng từ sớm và lên danh sách từ trước những gì mình hấp thụ được.

Cự ly dài từ rạng sáng tới nửa đêm, không có bữa chính, nên bạn cần ăn theo kế hoạch cũng như ăn bất cứ khi nào qua CP có đồ ăn.

Mình có may mắn là ăn được và hấp thụ tốt. Cả quãng đường mình cắn hết 10 gói gel mang đi, ăn nho khô chị Thảo cho, ăn trứng, dưa hấu, cơm cháo ở các CP. Thậm chí lúc đến CP4 hết thức ăn, mình và tạm 2 bát cơm chan canh cũng rất ngon lành.

Qua mỗi CP, mình thường cầm đi 3-4 quả quýt. Quýt bổ sung đường, vitamin và cung cấp nước theo cách cơ thể hấp thụ được. Trước mỗi con dốc, mình ăn vài quả nho khô hoặc ngậm 1-2 miếng quýt để thêm năng lượng. Cũng có thể do yếu tố tinh thần mà thôi, miệng nhai chân khoẻ, có ăn thì leo khoẻ hẳn.

Có một số bạn không ăn được, theo mình do cơ thể bạn bị quá nhiệt. Khi đấy máu dồn về các vùng dưới da để làm mát dẫn đến thiếu máu cho hệ tiêu hoá. Vậy nên hãy tìm cách làm mát cơ thể càng nhanh càng tốt.

• Làm mát cơ thể càng nhanh càng tốt.

Kinh nghiệm những từ lần tập trên Hàm Lợn, khi rửa mặt, rửa ống tay áo, cơ thể dịu đi và sức khoẻ hồi phục gần như ngay lập tức. Trong race, mỗi lần qua suối, mình đều dừng lại rửa mặt, làm ướt 2 ống tay áo, giặt mũ đội đầu để giữ hơi mát được lâu.

Có đoạn qua CP5, mình lấy 20 nghìn mua hai chai nước đá đọng trong thùng ngâm nước giải khát, dội vào người. Dội đến đâu mát lạnh đến đấy, cơ thể như hồi phục từng phần.

• Nếu không quen uống điện giải, hãy pha nước tỉ lệ 50-50.

Khi tập mình bổ sung muối theo lịch 1 tiếng 1 lần. Race dài tận 20 tiếng, không lẽ ăn 20 viên muối, ngộ độc thì sao?

Vậy nên từ CP3, mình lấy thêm nước điện giải ở mỗi CP. Để dễ uống, mình chỉ lấy nửa bình điện giải, pha thêm nửa bình nước, uống vừa miệng hơn hẳn. Khi chạy, mình thường uống 1 ngụm nhỏ ở bình có pha điện giải và ngụm to ở bình nước.

Khi uống, mình ngậm một lúc rồi mới nuốt, để mát mồm thôi, không kỹ thuật gì ở đây cả.

• Leo dốc đều chân, dốc xuống ngắn thì chạy, đường bằng thì đi bộ nhanh cùng gậy.

Có một nguyên tắc cho chạy trail, là để về đích bạn cần liên tục up-hill, còn để về đích sớm, bạn cần biết down-hill.

Mình không biết down-hill, tập ở Hàm Lợn, mình chỉ lò dò xuống dốc. Vào giải cũng vậy, cho nên mình mất tận 2 tiếng để đi 5km dốc xuống từ đỉnh đồi Bò xuống CP4, may mắn vẫn kịp COT.

Nếu bạn cũng không chuyên như mình, cùng mục tiêu về đích, không đua top với ai thì có thể làm theo nguyên tắc của mình:

Khi leo dốc, leo bước ngắn và đều chân, hết dốc hẵng nghỉ. Việc nghỉ giữa dốc như xe mất ga giữa chừng, tốn gấp 2 lần công sức để đi tiếp. Con người còn kém cái máy ở yếu tố tinh thần, leo lại giữa dốc có khi mệt gấp 4 lần đi tiếp.

Xuống dốc ngắn, cố chạy. Chạy xuống dốc thì cực kỳ đau gối, có thể chấn thương. Tuy nhiên vẫn cần chạy khi có thể để cân bằng vận tốc cực chậm lúc leo. Không chạy thì không kịp về đích, đây là rủi ro cần chấp nhận.

Đường bằng thì hãy đi bộ nhanh cùng gậy. Đây là bài tập mình học của anh Ngọc Võ và may mắn thực hành 2 lần ở Hàm Lợn từ khi mua gậy cuối tháng 8. Giữ nhịp đi gậy ở quãng pace 10-12, đi đều bước, giữ nhịp tim ở mức 120-140. Đây là những lúc mình thấy cơ thể hồi phục, song song cũng vượt qua được kha khá anh em lững thững đi trên đường.

• Cố gắng đi theo đoàn, có người giữ nhịp

Mình may mắn được nhập với đoàn khoảng 30 người từ cuối CP5, trước khi trời tối. Có đoàn không chỉ giúp đỡ buồn chán, quan trọng hơn, đi theo đoàn giúp mình giữ nhịp độ bước chân.

Ở những quãng cuối, khi cơ thể đã thấm mệt, tâm lý buồn ngủ rất dễ khiến bước chân lệch nhịp, tai nạn và chấn thương. Đi theo đoàn, giữ đều khoảng cách chính là cách thức tự nhiên kéo mình liên tục đi về phía trước.

Có người đi cùng còn giúp mình căn được giờ về CP7, khi đồng hồ của mình hết pin phải cất để sạc, đó là 20 phút mình hoàn toàn đi theo tốc độ của mọi người.

• Trang bị, đừng tiếc trang bị.

Mình đắp nhiều thứ vào người, và ở mỗi thời điểm, mình thấy chúng đều giá trị.

Mang đủ gel, muối cho mình đủ năng lượng và muối khoáng trên cả chặng đường 20 tiếng đồng hồ. Bó calf, bó gối giữ vững vàng đôi chân chỉ luyện tập làng nhàng. Tape cố định cơ, mình ra expo nhờ dán kín cả đầu gối, cơ đùi sau và cơ lưng dưới.

Tự kỷ ám thị, nhờ những trang bị đó, cả race mình không bị đau hay chấn thương gì đáng kể.

Trải nghiệm tinh thần

Nhiều người nói về quyết tâm và cố gắng, mình nghĩ cũng đúng, nhưng diễn đạt 2 yếu tố đó thế nào. Với mình, mình thay cố gắng bằng kiên trì và thay quyết tâm bằng một tinh thần cởi mở, không nghĩ suy khi xuất phát.

Trước khi vào giải, mình có quyết tâm và tin tưởng rằng mình sẽ về đích. Tuy nhiên, càng đến ngày chạy, mình càng ít suy nghĩ về kết quả. Suy nghĩ đơn giản thì đây là một hành trình thử thách bản thân, đạt được thì nhận huy chương và không thì còn trải nghiệm.

Đến khi đứng cùng anh em đếm ngược giờ xuất phát, mình ở vào trạng thái không nghĩ gì, cởi mở hoàn toàn cho cung đường chạy đang chờ.

Có một số trải nghiệm về tinh thần mình rút ra từ những cảm nhận và quan sát trên đường chạy:

• Đầu tiên là cảm nhận mình đã đề cập ở đến, đó là góc nhìn phần đường phía trước trở nên ngắn lại khi mục tiêu lớn dần.

• Cảm giác chán nản đến với mình không phải ở chặng khó khăn nhất, mà khi đi vào nửa cuối chặng đường. Đấy là khi mình vừa vội vàng đến CP5 cách COT vài phút, chỉ lấy nước mà không kịp ăn gì, leo tiếp lên nửa dốc, đứng nhìn ánh nắng chiều và đoàn người lũ lượt đi.

  
  Có lẽ mình đã bỏ cuộc nếu không nhìn thấy một chị đeo BIB 100 lầm lũi đi qua. Chị đã đi trước mình 30km, mệt hơn, không ngủ và vẫn đi. Chị có đang nghĩ trong đầu là hãy quyết tâm và cố gắng không? Theo mình là không, chị cứ đi thôi.

  
  Mình gọi đó là sự kiên trì, một hình thái quyết tâm lặng lẽ mà bền bỉ.

• Giải VMM năm nay có vấn nạn CEOM. Riêng mình nhìn thấy hơn 15 trường hợp đi xe ôm, đủ thể loại, đi để về checkpoint, đi để cho nhanh, đi để về đích. Mình quan sát chứ không để ý, kệ người ta thôi, mỗi người mỗi lẽ.

  
  Chỉ riêng một trường hợp làm mình gợn ý nghĩ. Chị đó đi cùng đoàn 70 cả chặng đường, khi chỉ còn 3km cuối, chị lại lên xe ôm về gần pre-finish line. Sao vậy? Chị đi bộ thì vẫn kịp, sao cần đi xe. Có lẽ những km cuối với dốc bê tông quá rát và chị thì quá đau chân. Có lẽ vậy.

Và may mắn

Từ đầu bài viết này, mình nhiều lần nhắc về sự may mắn. Đây cũng là từ mình nói đầu tiên mỗi khi mọi người hỏi chuyện sau khi may mắn hoàn thành cự ly.

Sẽ là thiếu sót nếu không nhắc đến những sự may mắn này:

• Không chấn thương: Mình bị ngã 5 lần, lật cổ chân 3 lần, may mắn không chấn thương lần nào. Có lẽ do mình tập nhiều phần cổ chân nên may hơn người khác.

• Ăn được: Đây là một dạng may mắn về cơ địa, mình vốn dễ ăn. Đoạn CP6 vừa cầm bát cháo vừa chạy vẫn ăn ngon lành. Với bạn nào khó ăn hơn, có thể đọc về việc làm mát cơ thể mình đề cập ở trên.

• Gặp được một đoàn đi cùng 30km cuối: Phần này mình đã nói ở trên.

• Gặp được một anh đi 100km điều pace cho 10km trời tối từ CP6 sang CP7: Anh nói giọng Nam, đã đi 100km năm ngoái, năm nay ra đi tiếp “cho vui”. Đi cùng anh từ CP6 sang CP7 mới thấy cái out-trình của dân 100, bước chân cực đều, cực nhanh; liên tục theo dõi khoảng cách để điều chỉnh pace, xin đường vượt lên mỗi khi cần.

  
  Hơi tiếc là đoạn sau CP7 mình phải dừng lại để thay pin đèn, không đi cùng anh để bắt tay làm quen khi về đích. Cảm ơn vì may mắn được anh đi cùng một đoạn.

Kết lại

Không chỉ giải này mà với tất cả những giải chạy bộ khác, mình đăng ký chỉ với mục tiêu trải nghiệm và về đích. Đấy là mục tiêu phù hợp với thể lực, điều kiện công việc và gia đình của mình.

Nếu bạn cũng có mục tiêu giống mình, thử bắt đầu nhé, những gì bạn cần chỉ là “Lý do để chạy, cảm hứng để đăng ký giải, tâm lý thoải mái khi xuất phát và may mắn để về đích”.

Theo mình VSCode sẽ còn giữ vị trí này rất lâu nữa.

Hiện nay hai công cụ AI-Native IDE phổ biến nhất: Cursor và Windsuft, lẫn IDE mới ra đời của AWS (Kiro) đều được fork từ Code-OSS, là bản open-source của VSCode.

VSCode được Microsoft giới thiệu và phát hành miễn phí năm 2015 tại hội nghị Build 2015 cùng bản open-source. Tuy nhiên, quá trình phát triển VSCode ở Microsoft diễn ra từ trước đấy khá lâu, từ năm 2011, bởi một người mà chắc hẳn nhiều lập trình viên thế hệ 8x từng "nhìn thấy" tên của ông.

Lịch sử phát triển và open-source hoá

Giai đoạn 2011 - 2015

Người đó là Erich Gamma, một trong 4 tác giả Gang of Four với cuốn sách "Design Patterns: Elements of Reusable Object-Oriented Software" huyền thoại.

Không chỉ là tác giả học thuật, ông còn là đồng tác giả của JUnit và phụ trách cấu phần Java Development Tool trong IDE kinh điển Eclipse.

Năm 2011, Microsoft tiếp cận Erich, khi đó đang là kỹ sư cao cấp (distinguished engineer) tại IBM. Nắm bắt được sự quan tâm của Erich trong việc xây dựng một công cụ lập trình online, Microsoft mời Erich gia nhập công ty để xây dựng phiên bản web-based của Visual Studio - IDE nổi tiếng trên nền desktop của họ.

Erich sau đó đồng ý gia nhập Microsoft cùng một số đồng nghiệp ở IBM. Họ tiếp tục làm việc ở Zurich, Thuỵ Sĩ, lập nên một phòng thí nghiệm cho dự án, với tên gọi Monaco.

Năm 2013, họ phát hành phiên bản Visual Studio Online, hướng đến các lập trình viên web, với khả năng tích hợp cloud mạnh mẽ, nhằm mục đích kéo lập trình viên tới các dịch vụ cloud của Microsoft.

Hiện tại, Erich vẫn tham gia dự án VSCode, tuy ông đã lùi lại phía sau, nhường vị trí trưởng nhóm cho Kai Maetzel, người gia nhập dự án năm 2015, có vai trò quan trọng với Copilot Extension - phần mềm cũng vừa được open-source tháng 6 năm nay.

Tháng 10/2014, với nhiệm vụ xây dựng phiên bản cross-platform desktop IDE, nhóm dự án quyết định lựa chọn công nghệ Electron, khi đấy có tên Atom Shell, còn rất non trẻ nhưng đầy tiềm năng, để kết hợp với lõi Monaco Editor, tạo nên sản phẩm IDE Visual Studio Code desktop, có thể chạy trên tất cả các hệ điều hành.

Có nhiều lý do dẫn đến quyết định này, bên cạnh lý do kỹ thuật là tăng khả năng tích hợp của bản online, theo mình lý do chủ yếu đến từ chiến lược của Microsoft dưới thời Satya Nadella, người trở thành CEO của Microsoft vào tháng 2/2014.

Họ giới thiệu VSCode desktop tại sự kiện thường niên Build tháng 4/2015 và ra mắt bản public preview một tháng sau đó.

Mặc dù vẫn có phiên bản web, từ đoạn này của bài viết, từ VSCode nhắc đến bản VSCode desktop mà chủ yếu các bạn đang dùng.

Subscribe now

Giai đoạn sau 2015

VSCode đạt mốc 1 triệu lượt tải vào tháng 11/2015, mặc dù vẫn đang public preview.

Đấy cũng là thời điểm họ phát hành bản Beta và tuyên bố open-source VSCode, cùng với đó là sự ra đời của Marketplace. Đây là một phần trong chiến lược của Microsoft mà chúng ta sẽ bàn ở phần sau.

Tháng 4/2016, họ phát hành bản 1.0, phiên bản stable đầu tiên với 2 triệu lượt tải và 500.000 daily active user.

Kai nói rằng họ đã tổ chức “big party” khi đạt 1 triệu user, và một “big party” nữa khi đạt 2 triệu và từ đó thì họ xem đấy là chuyện bình thường. Cũng phải thôi, dù không công bố chính thức số lượt tải, Microsoft cho biết họ vừa đạt mức 50 triệu người dùng hàng tháng cho 2 IDE chính của họ Visual Studio và VScode. Theo tỉ lệ sử dụng của hai công cụ, phần lớn trong số 50 triệu người dùng này đang sử dụng VSCode.

Trong thông báo vào tháng 5/2025, có hơn 100 nghìn extensions được phát hành trên VSCode Marketplace, không chỉ góp phần tăng tiện ích cho người dùng, mà còn biến VSCode thành IDE cho mọi ngôn ngữ lập trình.

Vậy Erich, Kai và team đã làm thế nào để xây dựng VSCode trở thành công cụ ổn định và có khả năng mở rộng cao đến vậy?

Từ khía cạnh kỹ thuật

Dưới đây là một số thông tin mình rút ra từ nội dung bài phỏng vấn Erich và Kai năm 2024. Mọi người có thể nghe lại ở link youtube trong phần tài liệu tham khảo.

Sự ổn định đến từ mô hình Internal và Community contribution

Lựa chọn chiến lược open-source ngay từ phiên bản Beta tháng 11/2015, Code-OSS, hiện tại có hơn 2000 lập trình viên (contributor) tham gia đóng góp vào mã nguồn mở này, với hàng nghìn commit mỗi tháng.

Điểm đáng chú ý là top 25 contributors của mã nguồn này đến từ team VSCode của Erich ở Zurich. Trong đó có những thành viên làm việc rất lâu ở nhóm này, như Benjamin Pasero, người gia nhập dự án từ năm 2011, tức là đã làm cùng Erich tận 15 năm.

Giữ văn hoá như một công ty start-up với sản phẩm VSCode, họ dùng VSCode của chính họ làm IDE phát triển, cảm nhận khó khăn và nhu cầu của người dùng. Dự án cam kết sử dụng 25% thời gian để xử lý các technical-debt của sản phẩm.

Erich nói, họ giữ một phiên bản internal, tổ chức nhóm dự án gồm gần 30 lập trình viên và giữ nhịp độ phát triển, phát hành mỗi tháng một lần. Khi bản internal sẵn sàng, họ sẽ đóng góp mã nguồn vào phiên bản Code-OSS.

Điều này phản ánh chiến lược open-source đặc sắc của Microsoft: Họ cung cấp sản phẩm do họ xây dựng miễn phí, kèm với mã nguồn, với mục đích xây dựng cộng đồng.

Ở chiều ngược lại, nhiều tính năng từ cộng đồng cũng được đưa vào phần lõi (core) của VSCode.

Có một câu chuyện thú vị về extension Bracket Pair Colorization.

Câu chuyện cải tiến extension Bracket Pair Colorization

Được phát hành bởi tài khoản CoenraadS vào năm 2016 cho version 1 và bản cải tiến version 2 năm 2018, đây là extension đánh màu cho cả cặp dấu ngoặc nhọn, sử dụng cơ chế mở rộng của VSCode.

Extension này hoạt động tốt với các file nhỏ nhưng xử lý rất tệ ở các file mã nguồn dài. Trong khi các file rất dài là đặc sản của các mã nguồn web. Theo mô tả của VSCode, với một file mã nguồn Typescript có độ dài 42k dòng của chính open-source Typescript, khi thêm 1 dấu đóng ngoặc nhọn, Bracket Pair Colorization xử lý mất 10 giây để tô màu lại các cặp dấu ngoặc của file. Trong 10 giây đó, CPU bị ngốn 100% và IDE bị treo hoàn toàn đến khi màu được tô xong.

Hiện tượng này đến từ cơ chế giao tiếp giữa việc hiển thị giao diện ở UI và extension host (chúng ta sẽ tìm hiểu kỹ hơn ở phần sau), khiến cho tốc độ tìm kiếm và tô màu bị tăng đáng kể, đặc biệt ở các file dài.

Để xử lý triệt để hạn chế này, ở bản cập nhật 1.60 vào 8/2021, nhóm dự án quyết định đưa tính năng của extension này vào phần core của VSCode. Cùng với nhiều cải tiến về thuật toán duyệt cây cấu trúc (abstract syntax tree), tốc độ xử lý đã giảm từ 10 giây về mức 1 millisecond, tức là 10 nghìn lần!

Bạn có thể đọc chi tiết cải tiến kỹ thuật này ở official blog của VSCode.

Kiến trúc extension: Tách biệt và Chuẩn hoá

Khi tìm hiểu một hệ thống, công nghệ mới, để dễ ghi nhớ, mình thường kết nối (linking) giải pháp xử lý của công nghệ đó với các pattern về kiến trúc hoặc lập trình cơ bản.

Cùng dừng một chút để nhớ lại các pattern trong thiết kế hệ thống (separate of concern) và lập trình (proxy, adapter).

Câu trả lời nằm ở hai nguyên tắc: Tách biệt và Chuẩn hoá.

Trong kiến trúc ứng dụng, VSCode tách biệt 3 phần riêng rẽ ở 3 process khác nhau:

• UI Rendering: Chịu trách nhiệm hiển thị giao diện và xử lý các thao tác của người dùng. Đây là phần chúng ta thấy khi sử dụng VSCode.

• Extension Host: Là một process NodeJS runtime riêng biệt, đóng vai trò proxy giao tiếp giữa UI và các extensions.

• Language Server: Là process xử lý logic trải nghiệm riêng cho từng ngôn ngữ lập trình, như auto completion, syntax checking, ....

Kiến trúc này tách biệt tài nguyên giữa các layer, đảm bảo trải nghiệm của người dùng ở UI luôn mượt mà, tối thiểu là các thao tác cơ bản được cung cấp bởi code editor của VSCode.

Ở khía cạnh chuẩn hoá, năm 2016, Microsoft giới thiệu Language Server Protocol (LSP), là giao thức chuẩn hoá kết nối giữa Language Server và IDE.

Theo Erich, việc định nghĩa trải nghiệm lập trình của một ngôn ngữ nên đến từ hệ sinh thái tạo ra ngôn ngữ lập trình đó. Do vậy, họ cung cấp cơ chế mở rộng Language Extension, cho phép cộng đồng có thể phát triển các bản extension cho ngôn ngữ mình yêu thích, miễn là các bản extension đó tuân theo chuẩn, tức là kết nối được với VSCode qua LSP.

Sơ đồ trên mô tả cách thức kết nối giữa các Language Server với Extension Host và VSCode.

Nhắc lại chiến lược xây dựng cộng đồng của Microsoft, không chỉ cung cấp cơ chế mở rộng, chính VSCode team trực tiếp phát triển Language Extension cho hầu hết các ngôn ngữ lập trình nguồn mở phổ biến như Python, Java, ....

Chiến lược quyến rũ giới công nghệ của Microsoft

Có thể nói, Microsoft trước thời Satya Nadella là thành trì chống open-source, đối đầu trực diện với Linux và Java. Trong cuộc phỏng vấn năm 2001, CEO thời đó, Steve Ballmer từng nói Linux là nguồn gốc lây lan căn bệnh ung thư "mã nguồn mở", đe doạ phần mềm bản quyền.

Có một video nói về một ông bố là tín đồ .Net và dành tâm sức truyền đam mê đó cho con trai mình. Cậu bé lớn lên lại dành tình yêu hết mình với Java, chờ đến năm 18 tuổi để thú nhận: I use Java! Video có tiêu đề là "Java Forever And Ever", các bạn có thể xem trên Youtube. Video hài hước, tuy nhiên thể hiện rất hình tượng về xung đột giữa .Net và Java ở thời điểm hơn 15 năm về trước.

Ấy thế mà, khi Satya Nadella lên nắm quyền CEO Microsoft vào tháng 2/2014, mọi thứ thay đổi hoàn toàn, đặc biệt với thông điệp "Microsoft love Linux" được ông thể hiện ngay trong sự kiện Microsoft Cloud Briefing tháng 10 năm đó.

Vốn là lãnh đạo mảng điện toán đám mây và dịch vụ trực tuyến của Microsoft, Satya hiểu rằng khi mọi thứ ở trên cloud thì nền tảng và ngôn ngữ không còn quan trọng nữa. Mục tiêu tối thượng là tác động và mang đến cái nhìn tích cực của cộng đồng đối với Microsoft, từ đó thúc đẩy các đối tác sử dụng sản phẩm, dịch vụ của công ty.

Quay lại thời điểm tháng 10/2024, khi dự án của Erich quyết định đóng gói bản VSCode desktop có thể chạy trên mọi nền tảng. Đây là một bước đi nằm trong chiến lược cross-platform của toàn bộ Microsoft.

Cùng thời điểm đó, họ công bố thông tin gây chấn động cộng đồng công nghệ - thực hiện open-source hoá phiên bản .NET core có khả năng chạy cross-platform. Hai năm sau là ASP.NET core, bản open-source của ASP.NET, tất nhiên cũng hỗ trợ cross-platform.

Năm 2016, với uy tín và sự kết nối của Reid Hoffman, Microsoft mua lại thành công LinkedIn. Hai năm sau, họ mua lại Github trong một thương vụ gây nhiều hoài nghi từ cộng đồng mã nguồn mở.

Vượt qua các luồng ý kiến trái chiều, thậm chí là làn sóng từ bỏ Github chuyển qua Gitlab, Bitbucket, Microsoft giữ đúng cam kết để Github vận hành độc lập, tiếp tục cung cấp nhiều tiện ích miễn phí cho public repo. Đến năm 2023, Github cán mốc 100 triệu người dùng, so với con số 30 triệu vào năm 2018. Thậm chí họ đạt mốc này sớm hơn tới 2 năm so với kế hoạch ban đầu.

Subscribe now

Kết lại

Có thể từ góc nhìn tài chính sẽ có thước đo định lượng về ảnh hưởng của chiến lược xây dựng hình ảnh tốt trong mắt cộng đồng phát triển phần mềm đối với kết quả kinh doanh của Microsoft trong những năm vừa qua, kể từ khi Satya Nadella trở thành CEO của công ty.

Từ quan điểm của một người trong nghề công nghệ thông tin, mình thấy rõ sự hiện diện và ảnh hưởng tích cực của Microsoft và các sản phẩm của họ trong công việc hàng ngày, đặc biệt là với các lập trình viên.

Với việc tích hợp chặt chẽ Github - nền tảng quản lý mã nguồn lớn nhất thế giới vào VSCode - công cụ IDE phổ biến nhất, Microsoft đã đạt được mục tiêu chinh phục tình cảm và gắn kết cộng đồng phát triển phần mềm một cách tích cực vào hệ sinh thái của mình.

Ở kỷ nguyên ứng dụng AI vào phát triển phần mềm, hứa hẹn Microsoft sẽ gặt hái được nhiều thành quả từ chiến lược phân phối miễn phí mã nguồn mở trong những năm qua.

Share

Một số link tham khảo

Copilot Open Sourced! w/ Erich Gamma and Kai Maetzel

The Story of Visual Studio Code with Erich Gamma and Kai Maetzel

Bracket pair colorization 10,000x faster

Language Server Protocol

Code-OSS Github repository

Ngại nhìn mấy ngôn ngữ, framework frontend, vì lối tổ chức code phi-structure, flow rối rắm. Và chủ yếu là ngại xấu, vì không biết thế nào là đẹp.

Tuy nhiên, với sự ra đời của các công cụ AI vibe code bây giờ, chuyện có vẻ đã khác.

Từ những ngày xưa

Cách đây mấy năm, tôi có một nhóm mấy anh em rủ nhau làm side-project.

Để kiếm tiền, chúng tôi quyết định làm sản phẩm cho người dùng cuối. Ý tưởng là xây dựng một website thu thập khuyến nghị cổ phiếu từ các công ty chứng khoán, theo dõi kết quả hàng ngày, lập danh sách thống kê kết quả để chỉ ra công ty nào có khuyến nghị xịn, công ty nào dở. Dĩ nhiên, sản phẩm đó cần có giao diện.

Đến giờ tôi vẫn nhớ khoảng thời gian đó, tôi có thể ngồi tập trung cả tối để viết các đoạn mã Python thực hiện tính toán tự động đánh giá hiệu quả của hàng loạt khuyến nghị, nhưng không chịu được việc phải mày mò sửa mã màu CSS của một nút ấn.

Alan J.Perlis có câu nói nổi tiếng "A language that doesn't affect the way you think about programming is not worth knowing." Tạm dịch: "Một ngôn ngữ (lập trình) không làm thay đổi cách bạn tư duy về lập trình thì không đáng để học."

Nghĩ ngược lại, khi bạn học một ngôn ngữ lập trình mới, bạn cần thay đổi cách tư duy.

Chỉ là tôi không thích.

Đến đề bài của vợ

Vợ tôi đang học một khoá Coaching quốc tế, và nhờ tôi làm website cá nhân để bắt đầu công việc này. Chạm vào điểm "ngại", tôi lần lữa mãi, chả nhẽ bảo mình không biết làm, nhưng cứ ngại không làm.

Tuần trước vợ khoe bạn vợ được chồng làm cho cái website dạy học, nói bóng gió. Tự ái nghề nghiệp nổi lên, tôi quyết làm.

Nhân việc đang tìm hiểu và triển khai AI cho bộ phận Công nghệ ở công ty, đúng là thiên thời, địa lợi, tôi đặt mục tiêu xây dựng website này hoàn toàn bằng AI.

Vibe Coding

Là người trong nghề, tôi vốn đã sử dụng AI Assistant từ 2-3 năm trước. ChatGPT cho trợ giúp đa nhiệm, Github Copilot / Cursor cho việc hỗ trợ lập trình. Tuy nhiên, ở thời điểm hiện tại, các công cụ AI cho người làm phần mềm đã phát triển rất nhanh, cả về lượng và chất.

Thuật ngữ mới ra đời "Vibe Coding" được giới thiệu bởi **Andrej Karpathy**, đồng sáng lập OpenAI vào tháng 2 năm nay, để nói về làn sóng này.

Có người ví von rằng, sự bùng nổ của các công cụ AI trong phát triển phần mềm hiện nay có thể so sánh với sự bùng nổ của Internet những năm 1990.

Nhận định này không phải là nói quá, từ yêu cầu chỉ vài câu của vợ tôi, rất nhanh chóng, tôi có thể tìm đủ công cụ AI để làm xong website này.

Kết nối các công cụ AI

Thứ đầu tiên bạn cần biết là làm một website cần qua những công đoạn này.

Quá trình làm phần mềm đi qua 3 giai đoạn: Làm rõ yêu cầu, phát triển và triển khai.

ChatGPT tạo tài liệu yêu cầu sản phẩm

Yêu cầu bạn nhận được, dù ngắn dù dài, cần đủ để bạn hiểu. Bạn cần hiểu để diễn đạt cho AI hiểu và thực hiện các việc tiếp theo cho bạn.

Với yêu cầu sơ bộ, để Vibe Code AI code được, cần một cấu trúc tài liệu rõ ràng, theo chuẩn. Chuẩn này chính là giao thức nói chuyện giữa các công cụ AI. Ở bước làm rõ yêu cầu, chuẩn tài liệu gọi là Tài liệu Yêu cầu Sản phẩm - Product Requirement Document (PRD).

Truy cập ChatGPT, đưa một prompt yêu cầu ChatGPT xây dựng PRD từ yêu cầu sơ bộ. Nếu bạn muốn học cách viết prompt hiệu quả, hãy đọc Prompt 101 của Google.

Bạn là một product owner chuyên thiết kế và đưa ra yêu cầu làm website. Hãy viết PRD của một website với yêu cầu liệt kê bên dưới. PRD gồm tính năng và cả yêu cầu về cách trình bày, UI/UX phù hợp với chủ đề.

1. Chủ đề

2. Yêu cầu

   -- Liệt kê danh sách menu các page, chi tiết yêu cầu từng page.

3. Trình bày dạng markdown để Bolt.new hiểu.

Câu trả lời của ChatGPT là tài liệu PRD dài cỡ 1 trang A4, gồm đầy đủ các thành phần yêu cầu tính năng, yêu cầu UI/UX, yêu cầu kỹ thuật, sẵn sàng đưa vào Bolt.new

Bolt.new tạo khung website, từ 0 đến 1

Trong 3 thang bậc Vibe Coding, gồm:

• Hỏi đáp

• Code Pilot

• Prompt to app

Bolt.new là một trong số các công cụ ở level cao nhất. Nhận PRD từ prompt, Bolt sẽ phân tích, code, run chương trình và trả ra giao diện thực của web/app.

PRD của tôi gồm 7 tính năng, với lần generate đầu tiên, Bolt làm được khung mã nguồn, cài đặt sẵn bộ layout, font, style và tính năng ở Trang chủ. Từ kết quả ban đầu, tôi có thể tiếp tục prompt để Bolt phát triển thêm tính năng.

Tuy nhiên, kết quả ở những lần prompt tiếp theo chưa khiến tôi ưng ý. Bolt generate lại toàn bộ website và sửa sai những phần tôi không yêu cầu. Phân tích hiện tượng này, tôi thấy cần sử dụng công cụ Vibe Code ở level detail hơn - Code Pilot - với công cụ Cursor IDE.

Cursor IDE để phát triển thêm tính năng

Xuất phát điểm là một sản phẩm mở rộng và gắn kèm với Visual Studio Code - IDE phổ biến nhất hiện nay, Cursor IDE sớm nhận thấy nhược điểm của việc gắn kèm và quyết định tách thành một AI IDE độc lập. Chiến lược này nhanh chóng chứng minh tính đúng đắn và lại thành công bùng nổ cho Cursor.

Với mức giá 20$/tháng cho personal plan, cao gấp đôi so với Githut Copilot, với khả năng hiểu sâu mã nguồn, và tính chất chỉ-gen-thay-đổi (modified), Cursor vẫn có mức tăng ARR vượt trội.

Quay trở lại dự án website, tôi tải mã nguồn khung website từ Bolt, mở mã nguồn này trên Cursor IDE.

Để giúp Cursor hiểu về mã nguồn, tôi thực hiện 2 prompt làm quen:

<Prompt 1>: Explain this project

<Prompt 2>: Do indexing this project

Tận dụng năng lực tiếp nhận - phản hồi sâu của Cursor, tôi yêu cầu Cursor re-create lại website từ PRD:

Với đặc tính chỉ-gen-thay-đổi, Cursor giữ cấu trúc, style, giao diện trang chủ, và generate tiếp các trang còn lại theo đúng yêu cầu từ PRD.

Cursor tốt như vậy, thì cần Bolt để làm gì?

Nếu đưa PRD và yêu cầu Cursor xây dựng website từ đầu, kết quả khá tệ, giao diện "xấu" và cũ, như một người code back-end làm front-end vậy.

Dùng đúng công cụ, đúng lúc, đúng chỗ là cực kỳ quan trọng.

Bolt sinh ra với nhu cầu look&feel website/mobile-app, có lẽ đội ngũ làm Bolt đã dùng rất nhiều dữ liệu mã nguồn website để train cho Bolt AI-model. Từ đó, kết quả sinh ra từ Bolt có UI/UX rất ổn, ở mức sử dụng được.

Ngược lại, Cursor IDE sinh ra để giúp lập trình viết code tiếp trên project của họ, Cursor ưu tiên khả năng nắm context lớn, đưa ra câu trả lời sâu, hợp với project có sẵn cấu trúc.

Tích hợp Calendar từ Calendy

Đây là demo nhỏ: Prompt thay thế form Liên hệ ban đầu (ảnh trên) bằng việc nhúng Calendy widget (ảnh dưới).

replace contact form by using Calendy embedded script

Kết

Kể từ thời điểm ChatGPT ra đời cuối năm 2022, làn sóng AI - GenAI đã phát triển nhanh chóng, trong đủ các lĩnh vực, đặc biệt là các công cụ hỗ trợ phát triển phần mềm.

Đến nay, các công cụ Level 2 như Github Copilot, Cursor IDE đã tự khẳng định giá trị của mình trong công việc hàng ngày của lập trình viên. Với các công cụ Level 3 như Bolt.new, V0 by Vercel, sẽ cần một thời gian nữa để hoàn thiện, bằng việc xây dựng được các sản phẩm phức tạp hơn.

Là người dùng cuối, biết lựa chọn, sử dụng và kết hợp các công cụ AI giúp bạn vượt qua rào cản về kỹ năng, thói quen để nhờ AI xây dựng sản phẩm cho ý tưởng của mình.

Hãy bắt đầu như tôi, chỉ với 2 tiếng đồng hồ.

Gần đây mình dành thời gian tìm hiểu về bản chất của việc bất đồng ý kiến và phương pháp thể hiện sự kiến cá nhân khi bất đồng một cách hiệu quả. Bài viết này ghi lại một số điều mình rút ra được trong thời gian tìm hiểu vừa qua.

Có bất đồng ý kiến là điều tự nhiên, và cần thiết

Mỗi người mỗi góc nhìn, trước một sự việc, mỗi người sẽ ít nhiều có ý kiến riêng.

Mặc dù âm Hán Việt của từ “bất đồng” có phần tiêu cực, định nghĩa trong từ điển Tiếng Việt thể hiện cho sự tự nhiên của việc này.

Bất đồng: Không cùng nhau, không đều nhau - Từ điển Tiếng Việt, Hoàng Phê, Viện ngôn ngữ học, 2003

Từ tiếng Anh, disagreement, cũng có cùng định nghĩa theo hướng neural, tự nhiên.

Disagreement: an argument or a situation in which people do not have the same opinion - Cambrigde Dictionary

Thành ngữ Việt Nam có câu “Trăm người, mười ý”, theo mình “trăm người, phải có trăm ý trở lên”. Thứ được đem ra thảo luận thường là những vấn đề không có đúng - sai rõ ràng. Độ khó của vấn đề tỉ lệ thuận với số lượng tham số ảnh hưởng. Càng nhiều người tham gia thảo luận, lựa chọn các chiều giá trị tham số, càng sinh ra nhiều ý kiến khác so với ý kiến đưa ra ban đầu.

Vậy nên, bất đồng tạo ra cái mới. Cái mới này không chỉ đến từ quan điểm khác nhau của người nghe, mà còn được sinh ra từ việc thử thách các khía cạnh mà chính người trình bày chưa nghĩ tới.

Trong bài viết How to Disagree, Paul Graham phân tích rằng:

Việc đồng ý thường ít thúc đẩy con người hơn là bất đồng. Và khi bạn đồng ý, bạn có ít điều để nói hơn. Bạn có thể mở rộng một ý mà tác giả đã đề cập, nhưng có lẽ tác giả đã khám phá hết những hàm ý thú vị nhất rồi. Khi bạn bất đồng, bạn đang bước vào một lĩnh vực mà tác giả có thể chưa khám phá.

Trong tập thể, cần cổ vũ tinh thần thể hiện ý kiến cá nhân. Lợi ích của việc này là quyết định cuối cùng được phân tích nhiều chiều, xem xét ở nhiều kịch bản, đồng thời tạo động lực cho các thành viên suy nghĩ, phản biện, từ đó tạo ra môi trường sáng tạo.

Khi đã có một môi trường tự do thể hiện ý kiến, nảy sinh hai câu hỏi cần giải quyết:

• Thể hiện bất đồng thế nào cho văn minh, tránh biến tranh luận thành tranh cãi?

• Có nhiều ý kiến, thì ra quyết định thế nào?

Kim tự tháp phân loại của Paul Graham

Paul Graham đưa ra kim tự tháp phân loại trong bài viết How to Disagree năm 2008. Bài viết này thể hiện quan sát của ông về xu hướng gia tăng sự căng thẳng, giận dữ trong các phản hồi trên internet. Ông nhận định, sự gia tăng căng thẳng này không phải là nguyên nhân dẫn đến ngày càng nhiều phản hồi bất đồng ý kiến, mà là hệ quả của cách thức thể hiện bất đồng ý kiến, đặc biệt trên môi trường online, khi người ta không nhìn thấy nhau.

Từ nhận định đó, ông thấy sự cần thiết của việc phân loại các hình thái thể hiện bất đồng ý kiến (đây là tính cách của các kỹ sư, nhà khoa học Âu - Mỹ mà mình rất ngưỡng mộ - khả năng trừu tượng hoá, mô hình hoá mọi thứ). Điều này giúp mọi người nhìn nhận ý nghĩa thực sự đằng sau lời nói của mình, hướng tới văn hoá phản hồi bất đồng văn minh hơn.

Trong kim tự tháp phân loại, Paul Graham chia các loại hình “disagreement” thành 7 loại, đánh số DH0 - DH6. Đi về phía đáy kim tự tháp là xu hướng tấn công cá nhân, chú trọng vào người nói, lời nói, thay vì nội dung. Đi về phía đỉnh là phản biện trực tiếp vào ý tưởng, chủ đề của người nói, từ đó thể hiện sự khác biệt của ý kiến bất đồng.

Một điểm thú vị trong bài viết của Paul, ông nói, việc thực hành theo 7 cấp độ này, thậm chí đạt được cấp độ DH6 - Refuting the Cental Point, không giúp người tranh luận giành chiến thắng. Việc này giúp người phản biện chú ý trọng tâm vào nội dung mình đọc, mình nghe; đồng thời người tiếp nhận phản biện tập trung vào ý kiến mình nhận được.

Càng về phía đỉnh, càng khó thực hiện, càng hiếm gặp, nhưng thành quả là sự văn minh trong thảo luận. Như Paul nói “giúp mọi người hạnh phúc hơn”.

Thực hành thể hiện bất đồng ý kiến càng có ý nghĩa trong môi trường công sở, vốn là môi trường có phân cấp bậc trên dưới. Bài viết của Amy Gallo trên Havard Business Review năm 2016 đưa ra các gợi ý tương đồng với phân tích của Paul Graham.

Văn hoá Disagree & Commit của Amazon

Mình tìm hiểu, cảm thấy phù hợp và đồng tình với văn hoá doanh nghiệp của 2 công ty công nghệ lớn là Amazon và Netflix. Để trả lời cho câu hỏi số hai ở trên: “Có nhiều ý kiến, thì ra quyết định thế nào?“, mình mượn một trong số các nguyên tắc lãnh đạo của Amazon: Disagree & Commit.

Nguyên tắc này được diễn giải ở ba ý như sau:

• Tập thể được cổ vũ tinh thần “disagree”: Văn hoá doanh nghiệp cho phép mọi thành viên đưa ra ý kiến cá nhân của mình trong các cuộc thảo luận, dù ở cấp nào. Ý kiến này có thể đúng, có thể sẽ sai, chỉ cần vì lợi ích tổ chức, sẽ được ủng hộ.

• Quyết định ở cá nhân, không thoả hiệp (no compromise): Lãnh đạo khuyến khích các thành viên đưa ý kiến và tiếp nhận các ý kiến đó. Tuy nhiên, quyết định cuối cùng nằm ở người lãnh đạo đang chủ trì thảo luận. Đây là quyền cũng là trách nhiệm của người ra quyết định. Mình rất thích văn hoá này. Công ty mình cũng lan toả và cổ suý văn hoá làm việc “Ownership” như vậy từ những ngày đầu.

• Khi đã ra quyết định, cả tập thể “commit” thực thi: Đây là quan điểm đưa lợi ích của tập thể, của doanh nghiệp lên hàng đầu. Quay lại ý đầu tiên của nguyên tắc này, ý kiến bất đồng của cá nhân đều xuất phát từ góc nhìn có lợi cho tổ chức. Vì vậy khi quyết định cuối cùng được đưa ra, các thành viên được yêu cầu thực hiện theo cùng một hướng. Dù sao đi nữa, lựa chọn chỉ là bước khởi đầu, để trả lời lựa chọn đúng hay sai, là kết quả của việc thực thi.

Có thể tóm gọn nguyên tắc trên bằng một câu khẩu hiệu mà chúng ta hay nghe: “Tôn trọng cá nhân, ưu tiên tập thể”. Thoạt nghe thì cảm thấy câu chữ, nhưng nghĩ kỹ thì cực kỳ đúng đắn.

Nếu quan tâm, bạn có thể xem video chia sẻ về nguyên tắc này của bác Andy Jassy - CEO Amazon trên Youtube.

Kết luận

Để xây dựng nền tảng trong việc thể hiện ý kiến bất đồng một cách văn minh, cần tư duy rành mạch rằng: tranh luận là đưa ý kiến cá nhân của mình đối với nội dung trình bày của người khác, không phải thuyết phục người đó chấp nhận ý kiến của mình. Việc tiếp nhận ý kiến trái chiều, sử dụng như thế nào, quyết định cuối cùng ra sao, là trách nhiệm của người trình bày, hoặc trong một số trường hợp, là của người lãnh đạo.

Đây là quan điểm đóng góp ý kiến, không phải để “giành chiến thắng”, vì chiến thắng cuối cùng là lợi ích mang lại cho tập thể tham gia cuộc thảo luận đó.

Cuối cùng, dù bạn đang có phong cách tham gia trao đổi như thế nào, có lẽ bạn đều cần tìm hiểu và thực hành bất đồng ý kiến một cách đúng đắn. Bởi trình bày bất đồng không đúng cách là bất lợi, nhưng không đưa ý kiến gì là thể hiện của việc bạn không có giá trị trong tổ chức, điều này còn có hại hơn.

Nguồn tham khảo

• Essay của Paul Graham - Việc đọc essay này tạo cảm hứng cho mình tìm hiểu sâu hơn về bất đồng ý kiến.

• Leadership Principles của Amazon - Giải thích của chính bác CEO Amazon về leadership principle: Have Backbone; Disagree and Commit.

• How to Disagree with Someone More Powerful than You của Amy Gallo - Tác giả đưa ra phương pháp luận cho việc phản biện ở văn phòng, đặc biệt với sếp, kèm theo đó là một số case-study hữu ích.

Thank you,

2025/05/03, nhân dịp dành cả Lễ chờ KRX golive - Trịnh Thế Thành

One of Grace Hopper's famous quotes is:

"The most damaging phrase in the language is: 'It's always been done that way.'"

This quote reflects her innovative spirit and her belief in challenging traditional methods to find better solutions. Hopper was known for her willingness to question conventions and push the boundaries of what was possible in computing.

https://baophapluat.vn/nguoi-phu-nu-kien-dinh-tro-thanh-me-de-cua-nganh-lap-trinh-may-tinh-post439332.html