Trong thời đại mới, Microsoft đã tìm ra lời giải cho một vấn đề căn bản: làm thế nào để đưa các lập trình viên trẻ tuổi trở lại với Windows?
Xem phần đầu tiên của bài viết tại đây
Một gã khổng lồ chậm chạp
Trong lúc cộng đồng các lập trình viên ngày một chuyển sang ủng hộ Apple, Microsoft lại tỏ ra hoàn toàn chậm chân khi đối đầu với những mối đe dọa mới. Nhìn chung, gã khổng lồ phần mềm hỗ trợ khá tốt cộng đồng lập trình viên sử dụng công nghệ của hãng, nhưng tất cả các nhà phát triển đứng ngoài cộng đồng này lại bị đối xử khá tệ.
Ví dụ, bộ compiler (trình biên dịch) mã C và C trên Visual Studio không hỗ trợ C99, một chuẩn của C đã được ra mắt từ 17 năm về trước. Cộng đồng lập trình C nói chung đã liên tục yêu cầu Microsoft hỗ trợ C99 và gã khổng lồ này luôn luôn từ chối. Không nói ra nhưng ai cũng hiểu rằng, lý do cho sự "cứng đầu" này là bởi các nhà phát triển ứng dụng Windows không sử dụng C99.
Không hiểu vì lý do gì Microsoft không hề muốn đáp ứng nguyện vọng của các coder sử dụng Windows muốn được code C99. Sự thật rằng ứng dụng mã nguồn mở được viết bằng C99 không thể được biên dịch trên Windows cũng không khiến cho gã khổng lồ phần mềm mảy may suy nghĩ. Đơn giản, những người viết ra các đoạn code này không nằm trong nhóm người dùng Windows, và do đó đáp ứng nguyện vọng của họ không phải là ưu tiên của Microsoft.
Nhưng trải qua nhiều năm, có lẽ một vài nhà lãnh đạo của Microsoft đã nhận ra rằng họ đang không bắt kịp với thời thế. Công ty hiện đã đặt mục tiêu hỗ trợ các đặc tả mới nhất của C lên mức ưu tiên cao, nhưng C99 có lẽ sẽ mãi mãi không bao giờ trở thành một phần của Visual Studio.
Vấn đề này không chỉ diễn ra với C99 mà còn diễn ra với cả môi trường dòng lệnh shell Unix nói chung. Nhưng, một coder trẻ tuổi tốt nghiệp một trường đại học hạng "top" gần như chắc chắn sẽ sử dụng thành thục bash, make và các công cụ Linux khác. Visual Studio là một công cụ phát triển tuyệt vời, nhưng công cụ đó hoàn toàn nằm ngoài trải nghiệm làm việc với Linux thông thường.
Microsoft không phải là không biết tới vấn đề của mình. Theo một số nguồn tin nội bộ của Microsoft, công ty đã mất rất nhiều tiền để thực hiện đào tạo cho nhân viên mới, bởi trước khi gia nhập Microsoft thì các nhân viên này cũng chưa từng một lần làm quen với cung cách phát triển phần mềm trên Windows. Cho đến tận trước thời điểm Build 2016, gã khổng lồ xứ Redmond vẫn không hề có ý định giải quyết vấn đề này một cách triệt để.
Thay vào đó, chúng ta chỉ được đón nhận một vài nỗ lực nhỏ lẻ. Dĩ nhiên là các nỗ lực đó không phải là vô nghĩa: Microsoft đã đầu tư tiền bạc và nhân lực tham gia quá trình port node.js lên Windows. Người được hưởng lợi lớn nhất ở đây lại chính là cộng đồng node.js: trong quá trình port node.js lên nền tảng của mình, Microsoft đã đóng góp phương thức xử lý I/O async (đầu ra/đầu vào không đồng bộ) thực sự tuyệt vời của Windows cho node.js. Phần xử lý I/O async của Windows đã được xé nhỏ ra làm một thư viện độc lập có tên libuv, và node.js có sử dụng tới thư viện này. Tương tự, Microsoft cũng đã phát triển một bản port cho redis để chạy trực tiếp trên Windows.
Những nỗ lực này là vô giá với cộng đồng nhà phát triển nhưng lại không giúp giải quyết triệt để vấn đề rằng các lập trình viên của ngày nay vẫn chưa thực sự tin tưởng vào Microsoft. Trong khi Ryan Dahl, người đã sáng lập ra node.js, ghi nhận rằng khả năng hỗ trợ Windows là rất quan trọng và rất sẵn lòng tự thay đổi phần mềm của mình để hỗ trợ Windows, không phải bất kỳ một tên tuổi lớn nào của làng phần mềm cũng sẵn sàng làm vậy.
Apple mất lợi thế về phần cứng
Cùng lúc, lợi thế về mặt phần cứng của Apple đã bị san phẳng. Các thiết bị như HP Spectre x360 và Dell XPS 13 được cộng đồng coder yêu quý. Càng ngày, các nhà phát triển càng có nhiều lựa chọn phần cứng Windows vừa có chất lượng cao, vừa có giá dễ chịu. Hệ sinh thái Windows hiện cũng đang đa dạng hơn bao giờ hết: bạn có thể mua laptop truyền thống, laptop lai tablet như Surface Pro hoặc những thiết bị độc đáo như chiếc Surface Book có card màn hình "rời" theo đúng nghĩa. Đây đều là các lựa chọn tuyệt vời.
Nhưng chỉ phần cứng là không đủ. Windows vẫn cần phải tạo ra một trải nghiệm phát triển phần mềm thực sự hấp dẫn. Rõ ràng là Microsoft cần phải làm được điều gì đó để thu hút cộng đồng coder.
WSL chính là giải pháp để Microsoft có thể biến hệ điều hành của mình thành "ngôi nhà" của lập trình viên, như những gì công ty của CEO Satya Nadella đã tuyên bố tại Build 2016. Các công nghệ vốn không hỗ trợ Windows nay sẽ chạy trên WSL. Redis nằm trong số này: đây không phải là một phiên bản Redis đã được fork (chỉnh sửa) mà là một phiên bản Redis "thực thụ", không khác gì phiên bản trên Linux. Tương tự, trải nghiệm Ruby trên Windows cũng sẽ được cải thiện đáng kể khi chạy trên WSL.
Bạn có thể chờ đợi một cuộc "di cư" ồ ạt cho gần như tất cả các công cụ, mã nguồn mở đang đóng vai trò xương sống cho phần lớn các trang web và đám mây hiện nay. Các phần mềm này sẽ tìm thấy "ngôi nhà" mới trên Windows, một ngôi nhà giống hệt như Linux trước đây. Microsoft hiện đang hợp tác cùng Canonical, do đó chẳng sớm thì muộn các lập trình viên cũng có thể tải các phần mềm này về Windows bằng một câu lệnh apt-get đơn giản như trên Ubuntu. Và, sẽ là không có gì bất ngờ nếu như các phiên bản Linux khác cũng mang một phần trải nghiệm của mình lên WSL.
Khi WSL ngày một trưởng thành và phổ biến, rất có thể cộng đồng coder sẽ gây sức ép để buộc Microsoft phải đẩy mạnh vai trò của phần mềm này ra khỏi giới hạn của một công cụ phát triển. Chắc chắn sẽ có lúc Microsoft phải cung cấp khả năng deploy phần mềm lên WSL trên Windows Server cho các nhà phát triển. Với các nhà phát triển nhỏ, khả năng chạy các phần mềm như Redis trên Windows mà không cần có máy ảo là đặc biệt quan trọng.
Nhà vua trở lại
Nhưng kể cả ở mức độ hạn chế như hiện nay, WSL vẫn góp phần giúp cho Windows trở thành một nền tảng đặc biệt quan trọng với các nhà phát triển. Thương vụ mua lại Xamarin cùng với tuyên bố tặng miễn phí Xamarin cùng với Visual Studio và mở công cụ này thành mã nguồn mở cho phép Windows trở thành lựa chọn lý tưởng nhất để sử dụng làm môi trường phát triển rộng khắp hết mức có thể. Ngay từ bây giờ, Visual Studio đã có sẵn một bộ giả lập Android chất lượng cao cũng như toàn bộ các công cụ cần thiết để phát triển ứng dụng cho hệ điều hành của Google.
Các ứng dụng iOS vẫn chỉ có thể được build trên Mac OS X, do chỉ duy nhất công cụ của Apple có thể biên dịch mã nguồn cho iOS và máy ảo iOS chỉ chạy trên OS X. Tuy vậy, ít nhất với Visual Studio và Xamarin, các nhà phát triển có thể tập trung khâu phát triển ứng dụng iOS trên Windows và thử nghiệm ứng dụng này bằng cách kết nối tới máy Mac trong cùng mạng nội bộ. Ngay cả điều này cũng mang tới lợi thế cho các coder sử dụng Windows, bởi máy ảo iOS trên Windows không hỗ trợ cảm ứng đa điểm (do Mac chỉ hỗ trợ chuột, không hỗ trợ bàn phím). Ngược lại, rất nhiều các mẫu tablet lai và laptop chạy Windows hiện nay đã có cảm ứng đa điểm.
Quan trọng hơn, Windows ngày nay đã vượt qua Mac trên các cuộc chiến công nghệ mới. Ví dụ, người dùng Mac đang bị bỏ rơi khỏi cuộc cách mạng thực tại ảo, bởi đơn giản là Apple vẫn chưa chịu phát triển các mẫu máy tính có GPU rời mạnh mẽ. Trên lĩnh vực máy để bàn, Apple chỉ có duy nhất 2 lựa chọn là chiếc iMac không thể hỗ trợ GPU mạnh (vì là máy All-in-One) và chiếc Mac Pro đã gần như bị bỏ rơi. Ở mức giá của Mac Pro, bạn thậm chí có thể mua được nhiều cỗ máy Windows để phát triển ứng dụng VR/AR cho HoloLens, Xbox, iOS và Android.
Với Build 2016, Microsoft mới chỉ hướng tầm nhìn lên các nhà phát triển web. Nhưng Windows của ngày hôm nay và trong tương lai sẽ là nền tảng cho tất cả các lập trình viên.
NỔI BẬT TRANG CHỦ
Sự thật từ nghiên cứu khoa học: Chơi trò chơi điện tử có ảnh hưởng bất ngờ đến chỉ số IQ của trẻ em!
Trò chơi điện tử từ lâu đã là chủ đề gây tranh cãi khi nhắc đến ảnh hưởng của chúng đối với trẻ em. Trong khi nhiều ý kiến chỉ trích việc chơi game có thể gây hại cho sự phát triển trí não, thì một nghiên cứu khoa học đã mang đến cái nhìn khác biệt, cho thấy mối liên hệ tích cực giữa việc chơi game và sự gia tăng trí thông minh ở trẻ nhỏ.
Những tiểu tiết bạn có thể đã bỏ qua trong trailer The Witcher 4