Tại sao phải quan tâm đến coding style?

Nicholas C. Zakas là một trong các đại tôn sư JavaScript và front end hiện nay. Anh từng làm ở một số công ty nhỏ trước khi đến Yahoo! vào năm 2006. Ở đó, anh đóng vai trò Senior Front End Engineer rồi Principal Front End Engineer. Có thể xem Nicholas như thế hệ đàn em xuất sắc của Douglas Crockford, một bậc thầy JavaScript vĩ đại khác. Cả hai đều hoạt động sôi nổi, có đóng góp rất lớn trong việc hình thành thế giới front-end sống động như ngày nay. Hiện anh đang làm ở Box.com trong vai trò Principal Architect. Ngoài ra anh cũng tham gia biên soạn đặc tả EcmaScript, viết phần mềm và sách, cuốn mới nhất của anh có tiêu đề "Understanding ECMAScript 6", đang là sách gối đầu giường của nhiều developers, trong đó có tôi.

Năm 2011, Yahoo! YUI share 1 seminar chủ đề "Scalable JavaScript Application Architecture" của Nicholas trên YouTube và đã tạo thành hiệu ứng dữ dội, hàng loạt JavaScript framework mới ra đời hoặc được kiến trúc lại, bao gồm cả Angular, Ember và Backbone. Sau đó, chính anh cũng xây dựng T3.js, một framework nhỏ gọn, dùng cho hệ thống ứng dụng ở Box.

Năm 2012, Nicholas viết "Why Coding Style Matters" trên Smashing Magazine. Bài viết nhấn mạnh tầm quan trọng của coding theo convension. Theo anh, coding style không chỉ thể hiện tính chuyên nghiệp và tăng cường khả năng debug, mà còn ẩn chứa 2 yếu tố rất nhân văn khác: sự quan tâm đến người khác và trân trọng tương lai của chính mình.

Nay tạm dịch lại, mời các bạn xem chơi :)



Tại sao coding style quan trọng?

Thời còn đi học, tôi có một ông thầy rất nghiêm khắc tên là Maxey. Ông dạy các môn phức tạp như cấu trúc dữ liệu và kiến trúc máy tính. Ông giảng hay, dễ hiểu, nhưng cũng đặc biệt khó tính. Ông không chỉ dò code xem chạy đúng không mà còn bắt lỗi trình bày code nữa.

Nếu bạn quên comment vào những chỗ cần thiết, thậm chí nếu bạn gõ sai một hai từ trong comment, ông sẽ trừ điểm. Nếu code của bạn "bẩn" - so với tiêu chuẩn của ông ấy - ông ấy cũng trừ điểm. Thông điệp rất rõ ràng: chất lượng code không chỉ nằm ở chỗ nó chạy ra sao, mà còn phụ thuộc cách bạn trình bày nó nữa. Đó là những trải nghiệm đầu tiên của tôi về coding style.


Thế tóm lại coding style là gì?

Hiểu đơn giản, coding style là nói đến việc code của bạn trông ra làm sao. Chữ "bạn" ở đây tôi muốn nhấn mạnh là chỉ chính bạn, người đang đọc bài viết này. Coding style là chuyện hết sức cá nhân và ai cũng có thói quen riêng của mình. Bạn có thể tự khám phá style của bạn bằng cách xem lại những đoạn code mà bạn đã viết trước đây khi chưa học theo bất cứ style guide nào. Mỗi người có phong cách khác nhau vì cách họ tiếp cận các môn lập trình không hề giống nhau. Nếu bạn dùng các IDEs như Visual Studio để học code, bạn sẽ viết theo đúng cách editor đó quy định. Nếu bạn dùng các trình soạn thảo thuần văn bản, cách viết của bạn có thể tiến bộ dần theo những gì bạn thấy là dễ đọc.

Bạn sẽ sớm nhận ra rằng, ở mỗi ngôn ngữ khác nhau, cách viết code của bạn cũng thay đổi theo những chiều hướng khác nhau. Bạn có thể làm với JavaScript một kiểu, làm với CSS một kiểu khác. Chẳng hạn, bạn cho rằng chuỗi trong JavaScript nên dùng nháy kép, trong khi chuỗi bên CSS bạn vẫn dùng nháy đơn. Đây không phải chuyện hiếm gặp vì chúng ta có xu hướng chuyển đổi ngữ cảnh khi nhảy từ ngôn ngữ ngày sang ngôn ngữ khác. Nó là một bài tập thú vị trong việc tự quan sát bản thân.

Coding style được hình thành từ những quyết định nhỏ trong từng ngôn ngữ bạn sử dụng:

- Khi nào cần comment và comment thế nào?
- Thụt đầu dòng bằng tabs hay spaces (và bao nhiêu spaces)
- Sử dụng white space hợp lý
- Đặt tên biến và hàm rõ ràng
- Tổ chức và gom nhóm code
- Các patterns nên dùng và nên tránh

Đấy cũng chưa phải là tất cả, vì coding style có thể rất chi tiết như Google JavaScript Style Guide hay cũng có thể tổng quát hơn như jQuery Core Style Guidelines.


Đó là chuyện cá nhân


Tính chất cá nhân của coding style là một thách thức khi làm việc nhóm. Nhiều khi để tránh phải tranh luận dài dòng, người ta cố gắng trì hoãn việc xây dựng style guides với lý do không muốn "ngăn cản sự sáng tạo và tự do biểu hiện." Một số người nghĩ rằng đưa ra style guide cho team là ép buộc tất cả các developers vào cùng khuôn khổ. Một số developers kịch liệt chống đối khi phải code theo style guide, họ tin rằng sẽ không làm được việc nếu có ai đó cứ chỉ bảo họ phải viết code như thế nào.


Tôi thấy giống với tình huống một ban nhạc mới thành lập. Mỗi thành viên đều tin rằng cách chơi của họ là tốt nhất và cố gắng chơi theo cách riêng của họ. Nhưng không thể có âm nhạc ra hồn được trừ khi các thành viên nhất trí với nhau về nhịp độ, phong cách và cử ra người dắt nhịp. Nghe các nhóm nhạc trong trường học biểu diễn thì biết. Khó có thể làm được gì nếu mọi người không vận hành theo cùng một cách thức.

Đó là lý do tại sao tôi rất khuyến khích áp dụng style guide trong các nhóm phát triển phần mềm. Nếu bạn thấy khó để mọi người nhìn vấn đề theo cùng một cách thì hãy bắt đầu từ style guide. Khi mà ai cũng trình bày code giống nhau, bạn sẽ tránh được rất nhiều rắc rối tiềm ẩn.


Thân thiện: nghĩ đến người khác


Giao tiếp là thứ quan trọng nhất khi làm việc nhóm. Để công việc trôi chảy thì phải tương tác với nhau thật tốt. Các developers giao tiếp chủ yếu qua source code. Chúng ta dùng code để nói chuyện với phần mềm cũng như với các developers khác.

Cách bạn trình bày code không quan trọng đối với máy tính, nhưng lại rất quan trọng đối với các developer khác. Code viết rõ ràng thì đọc dễ hiểu hơn. Đã bao lần bạn mở source code của người khác mà việc đầu tiên là sửa lại định dạng lại theo cách của bạn? Đó là vì cách trình bày khiến bạn không hiểu được code. Khi ai đó viết code nhìn khác lạ, mọi người sẽ ngay lập tức phải phân tích một cách trực quan trước khi có thể hiểu được code đó làm gì. Khi ai đó viết code giống bạn, bạn sẽ cảm thấy dễ chịu và hiểu được chương trình một cách nhanh chóng.


Khi bắt đầu nghĩ về code như một phương tiện giao tiếp với các developer khác, cũng là lúc bạn nhận ra rằng viết code chính là một nghệ thuật. Code nên thể hiện rõ ràng mục đích của nó. Luôn nhớ rằng code mà bạn viết ra rồi sẽ được những người khác dùng lại. Bạn không chỉ tương tác với các thành viên trong team ở thời điểm hiện tại, mà còn cả những developers sẽ gia nhập sau này.

Mới đây tôi có nhận email từ một người đang làm việc với code do tôi viết từ 10 năm trước. Tôi giật mình kinh ngạc: code của mình vẫn còn được dùng trong sản phẩm. Anh ta cảm thấy thôi thúc phải mail cho tôi để bày tỏ rằng anh rất vui khi được làm việc với code của tôi. Tôi mỉm cười. Người đồng đội tương lai này thực sự tán thưởng coding style mà tôi đã theo đuổi.


Thận trọng: nhìn xa phía trước

Trong cuộc sống, phải tự biết mình. Trong coding cũng vậy. Dẫu sao bạn sẽ không bao giờ biết mình đủ rõ để nhớ lại những gì bạn nghĩ khi viết ra mỗi dòng code. Hầu hết developers đều trải qua những lúc nhìn lại code cũ của mình mà không hiểu tại sao viết thế. Không phải do trí nhớ bạn kém, chỉ là bạn đã phải giải quyết quá nhiều chi tiết nhỏ và không thể nào ghi nhớ từng chút một.

Nhưng nếu bạn viết code dựa trên một style guide, các thông tin đó sẽ được gửi gắm vào trong bản thân mỗi đoạn code. Chỉ cần bạn biết rõ khi nào và ở đâu nên để comments, patterns nào nên/không nên sử dụng, bạn đã tạo ra ở đó một con đường mòn cho tương lai khi cần quay lại tìm kiếm ý nghĩa của code.

Không gì thú vị hơn khi mở ra một đoạn code xưa cũ mà vẫn thấy nó như vừa được viết hôm qua. Bạn sẽ bắt nhịp nhanh chóng chứ không phải mất hàng giờ nghiền ngẫm lại logic của những đoạn code ấy.

Chris Epstein từng khuyên: “Hãy ân cần với tương lai của chính bạn.”


Sáng suốt: nhận biết lỗi nhanh chóng


Một trong những lý do phải áp dụng style guide là nó khiến cho lỗi trở nên dễ thấy. Style guides giúp developers thích nghi với các patterns nào đó. Và khi bạn đã quen với những patterns ấy rồi thì chỉ cần nhìn qua code một cái, bạn sẽ phát hiện ngay ra các patterns khác lạ. Những patterns khác lạ này có thể không gây lỗi, nhưng chúng đòi hỏi phải xem xét thật kỹ để đảm bảo không có gì sai.

Chẳng hạn như với cấu trúc "switch" trong JavaScript. Có một lỗi khá phổ biến là cho phép thoát khỏi case để đi vào case khác, ví dụ:

switch(value) {
    case 1:
        doSomething();
    case 2:
        doSomethingElse();
        break;
    default:
        doDefaultThing();
}

Nếu value là 1 thì chương trình sẽ đi qua case thứ nhất rồi nhảy vào case thứ 2. Nghĩa là cả doSomething và doSomethingElse cùng được gọi.

Câu hỏi đặt ra ở đây là: có lỗi gì không? Rất có thể developer quên một câu lệnh "break" trong case thứ nhất, nhưng cũng có khả năng developer cố ý cho kịch bản chạy cả 2 cases nếu value bằng 1. Chưa thể khẳng định được điều gì qua đoạn code trên.

Bây giờ giả sử bạn có JavaScript style guide nói như sau:

“Tất cả các cases trong câu lệnh switch phải kết thúc bằng break, throw, return, hay một comments chỉ dẫn một fall-through”.

Với style guide như thế, chúng ta xác định đây là một lỗi trình bày, tức là có thể có lỗi logic. Nếu chủ ý bạn muốn chương trình đi qua case thứ nhất, thì nên code như sau:

switch(value) {
    case 1:
        doSomething();
        //falls through
    case 2:
        doSomethingElse();
        break;
    default:
        doDefaultThing();
}


Nếu bạn muốn thoát khỏi switch ở case đầu tiên, nó nên kết thúc bằng "break". Ngoài ra, code đầu tiên không đúng với style guide, nghĩa là bạn cần kiểm tra thật kỹ kịch bản. Với thói quen này, bug sẽ được ngăn chặn rất sớm. Cái

Style guide giúp chỉ ra những đoạn code viết bừa bãi. Chỗ lợi hại nhất của style guides là: bằng cách định nghĩa thế nào là trình bày code đúng, bạn sẽ dễ dàng hơn trong việc nhận diện code sai và do đó, cả những lỗi tiềm ẩn trước khi chúng xảy ra.


Càng tỉ mỉ càng tốt

Khi giúp khách hàng xây dựng style guide, tôi thường được hỏi những chi tiết vụn vặt có thực sự quan trọng không? Câu trả lời là đúng và không đúng. Đúng vì cách trình bày code không thực sự quan trọng với máy tính. Không đúng vì những chi tiết nhỏ ấy sẽ giúp ích rất nhiều cho các developer phải bảo trì code. Hãy nghĩ thế này: nếu trong sách có một ký tự lỗi, bạn vẫn hiểu và không mất đi hứng thú với câu chuyện. Nhưng nếu có quá nhiều lỗi, bạn sẽ nhanh chóng cảm thấy khó chịu khi cứ phải giải mã ý tứ của tác giả.

Coding style giống hệt như vậy. Các bạn đang định nghĩa cách phát âm, quy tắc ngữ pháp cho mọi người theo. Style guide của các bạn có thể khá dài và chi tiết, không sao cả. Theo kinh nghiệm của tôi, một khi các nhóm bắt đầu code theo style guides, họ có xu hướng đi vào chi tiết vì điều đó giúp họ hiểu code và tổ chức code ngăn nắp hơn.

Tôi chưa từng thấy style guide nào quá mức chi tiết, nhưng tôi đã thấy một số được làm quá sơ sài. Cho nên điều quan trọng là nhóm phát triển style guide phải phối hợp chặt chẽ, thảo luận kỹ càng xem cái gì cần nhất, để đưa ra một nền tảng tốt cho style guide. Đừng quên rằng style guide là tư liệu sống. Nó sẽ tiếp tục được nâng cấp trong quá trình làm việc tập thể mọi người ngày càng hiểu nhau hơn và nắm rõ công việc hơn.


Công cụ hỗ trợ

Đừng ngại dùng các tools bắt bạn phải tuân thủ coding style. Web developers có rất nhiều tools hỗ trợ kiểm tra coding style, từ command line chạy khi build, đến các plugins gắn vào text editors. Đây là vài công cụ bạn có thể tham khảo:

Eclipse Code Formatter
Eclipse IDE có một tool tích hợp sẵn hỗ trợ định dạng code.
JSHint
Công cụ kiểm tra chất lượng code và trình bày code JavaScript.
CSS Lint
Công cụ kiểm tra chất lượng và trình bày CSS do Nicole Sullivan và tôi xây dựng.
Checkstyle
Một công cụ kiểm tra style guidelines trong Java code, dùng được cho nhiều ngôn ngữ khác.

Bạn có thể chia sẻ trong team các files cấu hình kiểm tra style guide. Ngoài ra, làm các công cụ tích hợp vào hệ thống continuous integration của bạn cũng là ý tưởng tốt.



Kết luận

Style guides là phần quan trọng khi viết code chuyên nghiệp. Dù bạn viết JavaScript hay CSS hay ngôn ngữ nào cũng vậy, cách trình bày code là phần không thể thiếu khi đánh giá chất lượng code. Nếu team hay dự án của bạn chưa có style guide, hãy bắt đầu ngay đi. Đây là một số style guides để các bạn tham khảo:

Tất cả mọi người trong team đều nên tham gia xây dựng style guide để tránh hiểu không đúng. Vả lại, có bỏ công sức vào mới thấy trân trọng. Hãy bắt đầu bằng cách để mọi người cùng đóng góp cho sự sáng tạo chung đó.


by Nicholas C. Zakas, October 25th, 2012, Smashsing Margazine



* Một năm sau bài viết này, Nicholas quyết định viết ESLint, và cũng có chia sẻ tại đây: ESLint: The Next-Generation JavaScript Linter

Krishnamurty nói về Tự do

Dạo trước mình rất thích triết học, cũng tìm hiểu được chút ý tưởng của các cụ Aristote, Platon, Spencer, Kant… bên Tây, Khổng, Lão, Trang, Hàn… bên Tàu, lại có thói quen dẫn lời các cụ ấy coi như chân lý, mãi đến khi gặp được Krishnamurty thì mới nhận ra mọi thứ chủ thuyết trên đời đều không bằng cái tự bản thân ta thức ngộ được.

Thế giới quan của Krishnamurty có thể gọi là một dạng “triết học phi triết học” vì ông không đề xướng bất cứ học thuyết nào, chỉ lấy cái Ngã tâm linh trong Hiện tại mà đối diện với ngoại giới. Một khi loại bỏ được các giáo điều, định kiến, võ đoán… thì sẽ cảm nhận được ngoại giới bằng sự Hồn nhiên, Vô tư nhất của Trí tuệ.

Jiddu Krishnamurti


Trong video dài hơn 30 phút dưới đây sẽ có khoảng 6 phút đầu giới thiệu qua về cuộc đời Krishnamurty, tiếp đó là một số buổi nói chuyện ông đề cập đến vấn đề tự do.

Tự do, chúng ta thường hiểu là được tùy ý làm cái mình muốn, không bị ai ngăn trở, cấm đoán. Một con người tự do là một con người có thể sống bất cứ lối sống nào anh ta muốn, nói bất cứ điều gì anh ta thích. Một đất nước tự do là một đất nước không lệ thuộc thế lực nào và có đủ sức mạnh để ban phát tự do cho mỗi công dân của nó.

Nhưng trong quan điểm của Krishnamurty thì đó chỉ là lớp vỏ ngoài thô thiển của khái niệm tự do. Ông hướng đến một khái niệm mang tính tâm linh nhiều hơn, một sự tự do từ bên trong, sự tự do chân thật hình thành bởi thấu hiểu và minh triết.

Hình dung một tên cướp bị bắt giam ngồi trong tù nhớ lại thời vang bóng, khao khát gặp lại huynh đệ cũ, ngồi bên nhau chén tạc chén thù, cưỡi xe phân khối lớn chạy đua với cảnh sát… Tức là trong trí óc hắn có hai thế giới đối lập. Một nơi muốn làm gì thì làm, một nơi bị quản thúc mọi mặt. Khi hắn đặt 2 thế giới cạnh nhau và so sánh, hắn sẽ thấy rõ một bên là tù túng, bức bách, bên kia mới là khoái hoạt, vui sướng. Và do vậy, hắn bị những cảm xúc tiêu cực vây bủa, hành hạ, từ đó tạo ra nuối tiếc, đau khổ, uất hận… Nhưng nếu hắn đột nhiên thức ngộ, đột nhiên nhận ra ở trong khoảnh khắc này, ở nơi đây, nhà giam này là thế giới của hắn, nơi hắn đang thuộc về, nơi hắn tồn tại, hít thở và suy nghĩ. Hắn có thể nảy sinh những cảm nhận đặc biệt khác.

Nếu chỉ dừng ở bề ngoài khái niệm tự do thì không ai trong cõi đời này thực sự tự do. Chúng ta phụ thuộc các quan hệ xã hội, chịu các quy luật tự nhiên, suy nghĩ của chúng ta bị nô lệ bởi tầng tầng lớp lớp kiến thức, kinh nghiệm đến từ người khác. Chúng ta luôn cảm thấy các rào cản và mong muốn bứt phá để đạt đến tự do. Nhưng tất cả sẽ là vô nghĩa nếu chúng ta không tìm thấy tự do từ nội tâm của chính mình.

Mời các bạn cùng xem và suy ngẫm:


Chuyện kể về các trình duyệt web

Microsoft đã quyết định dùng tên Microsoft Edge cho Project Spartan. IE, kẻ thống trị một thời xem như đã chết. Đây là lúc chúng ta nên dành đôi phút nhìn lại lịch sử WWW và mấy cuộc đại chiến trình duyệt trong 25 năm qua. Rất nhiều điều thú vị :)

Web browsers

Sự khởi đầu của web

Web, hay World Wide Web, hay WWW, được Sir Timothy John “Tim” Berners-Lee, một nhà khoa học máy tính người Anh làm việc ở CERN, sáng tạo ra vào năm 1989. Bạn nào từng đọc “Thiên thần và Ác quỷ” của Dan Brown chắc hẳn cũng đã nghe tới CERN – Tổ chức Nghiên cứu Nguyên tử Châu Âu. Chữ viết tắt CERN là do tiếng Pháp: “Conseil Européen pour la Recherche Nucléaire”.

Theo định nghĩa hàn lâm, web là một hệ thống thông tin của những văn bản được liên kết lẫn nhau và có thể truy cập thông qua môi trường internet.


Tim Berners-Lee


Để truy cập và đọc những “văn bản được liên kết lẫn nhau” đó, Tim viết ra một phần mềm gọi là trình duyệt web. Thế là năm 1990, web browser đầu tiên của thế giới ra đời với cái tên là WorldWideWeb mà sau đó ít lâu được đổi thành Nexus để tránh lẫn lộn với khái niệm WWW ở trên.

Nexus - Trình duyệt web đầu tiên


Từ đó cho đến 1993 cũng xuất hiện thêm một vài trình duyệt web khác như Line Mode Browser, ViolaWWW, Erwise, MidasWWW, MacWWW, Cello, Arena, Lynx, tkWWW… nhưng không cái nào gây được nhiều dấu ấn.

Bấy giờ Marc Andreessen vẫn đang là sinh viên và làm trợ lý bán thời gian cho NCSA thuộc đại học Illinois.


Marc Andreessen

Marc Andreesen và cuộc phân tranh của bộ tộc Mosaic

Công việc ở NCSA tạo cho Marc cơ hội tiếp cận thế giới web mà rất ít người có được. Anh thấy rằng các trình duyệt web lúc ấy vừa nghèo chức năng vừa khó sử dụng. Vì thế anh quyết định viết ra một browser hỗ trợ tốt hơn, thân thiện với người dùng hơn, có giao diện đồ họa trực quan hơn.
Năm 1992, Marc chiêu mộ thêm Eric Bina – cũng là nhân viên của NCSA – để cùng anh thực hiện ý định. Cả hai bắt đầu cày ngày cày đêm. Eric sau này kể lại rằng họ thường làm việc 3 hay 4 ngày liên tục, rồi nghỉ một ngày! Sản phẩm được đặt tên là Mosaic.

Đầu năm 1993, NCSA cho download Mosaic từ máy chủ của họ. Trình duyệt này lập tức trở nên phổ biến.


NCSA Mosaic

Mosaic là trình duyệt web đầu tiên có giao diện đồ họa hoàn chỉnh, lần đầu tiên hỗ trợ các giao thức FTP, gopher… mà về sau rất quen thuộc. Một số HTML tags mới như CENTER, IMG… cũng được thêm vào. Đặc biệt, với tag IMG, lần đầu tiên các hình ảnh được hiển thị ngay trong trang web.

Một sáng tạo quan trọng khác của Mosaic là hyperlink. Trước kia các liên kết trên web có những con số tham chiếu như kiểu danh mục tham chiếu trong các tài liệu hàn lâm. Người ta phải gõ chúng để đi tới nội dung ở trang đích. Mosaic xử lý hyperlink giống như các trình duyệt ngày nay, cho phép user chỉ cần click là tới.

Vai trò của Mosaic trong lịch sử WWW quan trọng đến mức người ta có thể chia internet ra 2 thời kỳ, trước Mosaic và sau Mosaic. Nhưng khi Mosaic được vinh danh thì NCSA hầu như lãng quên công sức của Marc và cộng sự. Vì vậy mà sau đó anh rời bỏ NCSA để bước vào thung lũng Silicon.

Trong 3 ngày 25-26-27 của tháng 5, hội nghị World Wide Web lần thứ nhất được tổ chức ở Geneva, Thụy Sĩ. Cùng thời điểm, Spyglass, Inc. mua được giấy phép sử dụng mã nguồn NSCA Mosaic và cho ra đời web browser của họ lấy tên là Spyglass Mosaic. Tuy vậy, các tác giả của Spyglass chỉ dùng lại rất ít mã nguồn Mosaic.

Mùa hè năm 1994, Thomas Reardon của Microsoft khởi động dự án Internet Explorer, dựa trên source code Spyglass Mosaic. Team của Thomas có 5 hoặc 6 người. Đến 16/8/1994 thì release được phiên bản 1.0, đưa Microsoft chính thức nhập cuộc.

Internet Explorer 1.0

Ở Silicon Valley, Marc gặp lại James Henry Clark, founder của Silicon Graphics., Inc. Họ đã quen nhau từ 1 năm trước. Cả hai tính chuyện lập ra một công ty start-up hoạt động trong lĩnh vực internet. James có tiền và quan hệ rộng. Marc có nhiều kinh nghiệm chuyên môn. Vậy là giữa năm 1994, Mosaic Communications Corporation được thành lập ở Mountain View, California. Marc lôi kéo thêm một số bạn bè cũ ở NSCA về công ty mới và bắt tay vào làm một web browser khác tốt hơn Mosaic.

Họ phải xây dựng mọi thứ từ đầu vì NSCA Mosaic được phát triển bằng tiền của trường đại học, không thể dùng lại.

Vẫn với tinh thần làm việc không biết mệt mỏi, nhóm thường code với nhau 48 giờ liên tiếp. Cứ như thế, vào ngày 13/10/1994, phiên bản beta đầu tiên của Mosaic Netscape đã chính thức được release cho người dùng download.

Mosaic Netscape 0.9 on Windows XP

Sáng tạo trong Netscape vượt xa bất cứ trình duyệt nào ở thời kỳ đó. Với Netscape, lần đầu tiên web browser biết “tải xuống đến đâu hiển thị đến đó”, các cookies và frames cũng bắt đầu được sử dụng.

Song song với Netscape, nhiều trình duyệt khác cũng theo nhau xuất xưởng: IBM Web Explorer, Navipress, SlipKnot, MacWeb… Telenor, công ty viễn thông lớn nhất Na Uy thời đó cũng khởi động một dự án nghiên cứu liên quan đến trình duyệt. Nhưng những cái tên đó chỉ làm nền cho Netscape trở thành lựa chọn số một của người dùng internet.

Cũng năm 1994, Håkon Wium Lie, một đồng nghiệp của Tim Berners-Lee ở CERN lần đầu tiên đề xuất khái niệm CSS. Tháng 8, Gijsber Bert Bos tạo ra một trình duyệt tên là Argo để hỗ trợ test CSS. Tháng 10, Tim Berners-Lee rời CERN và lập ra World Wide Web Consortium (W3C).

Netscape lên ngôi

Sau vài vụ tranh chấp về từ “Mosaic” với đại học Illinois, James và Marc phải đổi tên Mosaic Communications Corporation thành Netscape Communications Corporations, và Mosaic Netscape thành Netscape Navigator.

Năm 1995, Netscape Navigator đã đánh bại NSCA Mosaic để trở thành trình duyệt được sử dụng nhiều nhất thế giới. Cũng trong năm này, Netscape 2.0 đánh dấu một bước ngoặt mới của công nghệ với sự khai sinh ra ngôn ngữ JavaScript.

Ở phía sau Netscape lại có thêm vài tân binh như: OmniWeb, WebRouser, UdiWWW… Và bên Na Uy, Opera Software ASA đã bắt tay với Telenor để phát triển trình duyệt Opera.

Ngày 22/10/1995, Microsoft công bố Internet Explorer 2.0 beta.

Từ đó đến giữa năm 1996, Netscape ở trong thời kỳ hoàng kim với 75% thị phần web browser. Bên cạnh đó, vẫn có thêm vài cái tên mới như InternetWorks, Quarterdeck Browser, InterAp, và WinTapestry lặng lẽ chào đời.

Bert Bos về hẳn W3C để hoàn thiện W3C CSS Recommendation, cũng gọi là đặc tả CSS1. Do ảnh hưởng của Bos đối với đề án, về sau, cả Bos và Håkon đều được xem như những tác giả của CSS.

Team phát triển Internet Explorer của Microsoft bấy giờ đã lên đến trăm người. Sau 3 tháng làm việc, ngày 13/8/1996, họ công bố Internet Explorer 3.0, một phiên bản được viết lại hoàn toàn mới. Đây là web browser đầu tiên hỗ trợ CSS. Ngoài ra, họ còn tích hợp thêm ActiveX controls, Java Applets… Logo hình chữ “e” màu xanh chính thức được sử dụng.

Internet Explorer 3.0

Ở Na Uy, dự án của Opera Software và Telenor đã cho kết quả là phiên bản đầu tiên của MultiTorg Opera mà về sau từ 3.0 trở đi sẽ đổi tên ngắn gọn lại thành Opera.

MultiTorg Opera

Tháng 1/1997, NSCA thông báo ngừng phát triển Mosaic. Trình duyệt lịch sử này tới đây là tạm biệt sân chơi. Còn kẻ đã hạ gục nó, đứa em cùng cha, Netscape Navigator, vẫn đang tiếp tục dẫn đầu thế giới web browser.

Năm 2003, NSCA cũng còn tổ chức kỷ niệm 10 năm ngày ra đời NSCA Mosaic. Ngày nay, các bạn vẫn có thể download NSCA Mosaic từ server FTP của trường:

ftp://ftp.ncsa.uiuc.edu/Web/Mosaic/


Đại chiến lần thứ nhất

Tháng 6/1997, Netscape Communicator 4.0 ra đời. Jim Barksdale bấy giờ là CEO của Netscape đã quyết định thay chữ “Navigator” bằng “Communicator” vì nó không còn là một trình duyệt web thuần túy nữa mà đã trở thành tổ hợp của nhiều ứng dụng như Netscape Messenger, Netscape Composer… Netscape Navigator chỉ là 1 thành phần trong đó.

Tháng 10/1997, Internet Explorer 4.0 ra mắt công chúng. Theo hồi tưởng của Eric Sink, lúc này team phát triển IE ở Microsoft đã lên đến hơn 1000 người, dưới sự dẫn dắt của Scott Isaacs.
Phiên bản IE 4.0 dùng Trident làm layout engine.

Về kiến trúc phần mềm, web browser ngày nay luôn có 2 thành phần quan trọng:

  • Layout engine giữ nhiệm vụ phân tích DOM và CSS để render ra giao diện
  • JavaScript engine thông dịch mã JavaScript trong trang web thành mã máy để chạy
Trident chính là layout engine đầu tiên.

Mãi đến cuối 1997, Opera mới release phiên bản 3.0 hỗ trợ JavaScript. Sau đó Håkon – 1 trong 2 tác giả của CSS – về làm cho Opera Software. Nhờ vậy, Opera 3.5 release mấy tháng sau đã bắt đầu hỗ trợ CSS.

Thị phần của IE đang nhích dần lên, nhưng Netscape vẫn còn giữ tới 72%, trong khi IE chỉ mới có 18%. Opera và các trình duyệt khác chia nhau 10% còn lại, đủ đứng ở vòng ngoài.

Cùng với sự bùng nổ của hệ điều hành Windows, cuộc chiến giữa Netscape và IE diễn ra ngày càng kịch liệt. Vấn đề là chúng khác nhau xa. Bất chấp các chuẩn của W3C, một trang web khó lòng hiển thị tốt trên cả 2 trình duyệt. Vì thế người dùng thường gặp những thông điệp dạng: “best viewed in Netscape” hoặc “best viewed in Internet Explorer”, kèm theo link đến trang download của trình duyệt đó. Mãi đến những năm 2007-2008 tôi vẫn còn thấy nhiều trang web để như vậy.

W3C khởi xướng một cuộc chiến khác giữa các webmaster và developer để giành danh hiệu “Viewable With Any Browser”. Gắn được thông điệp đó trên trang chủ là cả một niềm vinh dự lớn lao.

Thành công của Windows biến Microsoft thành một gã khổng lồ, so với nó, Netscape Corp. chỉ là chú nhóc. Doanh thu của Netscape không đủ cho công ty tồn tại. Trong khi Microsoft sẵn sàng bỏ ra cho Apple số tiền lên đến 50 triệu USD chỉ để IE trở thành trình duyệt mặc định trong Macintosh.

Tháng 3/1998, Netscape mở mã nguồn Netscape Communicator cho cộng đồng phát triển. Ngay sau đó, Mozilla Organization được thành lập. Mozilla nguyên là code name gốc của Netscape Navigator. Các programmers chủ chốt của Mozilla Organization cũng đều được Netscape trả lương.

Tháng 8/1998, Netscape Corp. rơi vào tay America Online. Lúc này lực lượng developers của Netscape phân làm 2 nhánh, 1 thuộc về America Online, 1 hướng ra phía Mozilla và cộng đồng nguồn mở.

Bên nhánh Mozilla, các developers viết lại source code, xây dựng Gecko engine, và sau đó là Mozilla Application Suite. Nhóm developer ở AOL phát triển tiếp Netscape Communicator 5.0 nhưng bỏ dở nửa chừng để làm phiên bản khác sử dụng source code của Mozilla. Năm 2000, Netscape 6.0 được release.

Trong những ngày tháng chật vật của Netscape, Internet Explorer nhanh chóng vượt lên dẫn trước. Ngay từ 1999 thì IE đã chiếm lĩnh hơn 60% thị phần, chính thức bắt đầu một triều đại mới kéo dài hàng chục năm sau.

Năm 2000, IE đạt tới hơn 70%. Năm 2001, Microsoft release Internet Explorer 6. Đến 2002, thị phần của IE đã lên tới 96%. Netscape Communicator chỉ còn sống lay lắt.

Đại chiến trình duyệt lần thứ nhất đã kết thúc với thắng lợi hoàn toàn của IE và Microsoft.

Phượng hoàng tái sinh

Cũng như Netscape Communicator, Mozilla Application Suite bao gồm 1 bộ công cụ trình duyệt, message, email… Một số thành viên của Mozilla Organization như Dave Hyatt, Joe Hewitt và Blake Ross không nghĩ đó là chiến lược đúng đắn. Tháng 3/2003, Mozilla Organization thông báo thay đổi định hướng. Thay vì phát triển cả bộ ứng dụng trong Mozilla Suite, họ sẽ focus vào chỉ 2 sản phẩm: Firefox và Thunderbird.

Ngày 7/1/2003, Apple lần đầu công bố phiên bản beta Safari, chạy trên OS X.

Giao diện Safari 1.1.1

Ở vị trí độc tôn, suốt 5 năm từ 2001 đến tháng 10/2006, Microsoft không ra thêm phiên bản IE nào mới. Ngày nay, chúng ta thực sự không thể tưởng tượng nổi tốc độ phát triển của một sản phẩm công nghệ lại trì trệ như vậy!

Những năm tháng IE thống trị cũng là đêm trường trung cổ của WWW, cơn ác mộng của giới security. IE hỗ trợ VB script, có thể write xuống client. Virus, spyware… được mùa nảy nở rầm rộ. Thời bấy giờ, vào web trên Windows cũng như bơi thuyền trong giông bão, nếu không bị hack tài khoản thì ít ra cũng lôi về máy cả mớ virus! Chỉ có các công ty làm phần mềm Anti-virus là mặc sức ăn nên làm ra. Norton nặng nề như một cỗ đại pháo. Kaspersky hú còi inh ỏi. Rồi SpiderWeb, AVG, ClamAV, BullGoard… Tôi còn nhớ BullGoard, đỏ rực, rất mạnh mẽ. Ở Việt Nam cũng có một phần mềm biết quét virus gọi là Bkav. Dạo đó đâu đâu cũng thấy diễn đàn hacking, vừa hướng dẫn hack vừa hướng dẫn bảo mật! Hacker và các pro công nghệ thì đứng trên các hòn đảo an toàn mang tên *nix.

Nhiều chuyên gia đã buộc phải lên tiếng kêu gọi người dùng phổ thông không nên lướt web bằng IE nữa, như Bruce Schneier trong Safe Personal Computing.

Khỏi phải nói thêm về sự tệ hại của IE. Nhưng có nhiều web browser dựa trên nhân Trident của IE lại khá tốt. Như Maxthon hoặc AvantBrowser đều hỗ trợ tabs, plugins, bookmark, tùy biến giao diện… Chúng thông minh hơn IE rất nhiều.

Và những developers tốt nhất của Netcapse giờ đây tập trung vào Firefox ở Mozilla Fundation. Firefox đầu tiên có tên là Phoenix, rồi thay bằng Firebird, cuối cùng mới đổi sang Firefox như ngày nay.

Sau hàng loạt bản beta, ngày 9/10/2004, phiên bản 1.0 của Firefox đã chính thức được công bố.

Firefox 1.0

Đó cũng là ngày lịch sử WWW sang trang. Sự xuất hiện của Firefox như cơn mưa rào ngày nắng hạn. Những ai hiểu biết về máy tính một chút đều vồ lấy nó. Trên các diễn đàn người ta nhao nhao bàn tán về nó, ca tụng nó. Firefox nhẹ, đẹp, nhanh, chắc chắn. Tuyệt nhất là hệ thống plugins của nó. Tuy vậy, với đa số người dùng phổ thông, web mặc định vẫn chỉ gói gọn trong cái biểu tượng chữ E màu xanh nhạt mỏng manh yếu ớt cứ vào Windows là thấy.

Trong lúc Microsoft hứa hẹn về IE7, Mozilla Foundation, Opera Software và Apple đã bắt tay thành lập Web Hypertext Application Technology Working Group (WHATWG) nhằm phát triển XHTML và các chuẩn mới cho công nghệ web. Cũng chính WHATWG những năm sau này đã đóng vai trò quan trọng trong việc hoàn thiện đặc tả HTML5.

Tháng 6/2006, Opera Software ra mắt Opera 9. Đây không những là trình duyệt đầu tiên vượt qua Acid2 Test mà còn mang theo những tính năng độc đáo như widgets, Speed Dial, MHTML, built-in BitTorrent client… Công nghệ torrent và P2P lúc bấy giờ đang rất hot. Sau đó, Opera ngày càng hoàn thiện qua các bản 9.1, 9.2 và 9.3. Không thể phủ nhận, vào nửa cuối những năm 2000 này Opera vẫn luôn là một trình duyệt xuất sắc, thậm chí nổi bật hơn Firefox ở nhiều điểm. Số lượng fan của Opera khá lớn. Khi phiên bản Opera 9.5 được release vào tháng 10/2008, đã có tới 4.5 triệu lượt tải chỉ sau 5 ngày đầu tiên.

Ngày 18/10/2006, Microsoft release IE7, cũng bắt đầu hỗ trợ tab, zooming, tích hợp feed reader, search box… Tuy nhiên vẫn chưa pass Acid2 tests. Các chức năng trong IE7 chủ yếu vẫn là học lại từ Firefox và Opera nên hầu như không gây được ấn tượng. Microsoft tỏ ra quá chậm trong cuộc chạy đua này.

Đến 24/10/2006, Mozilla cho Firefox 2.0 xuất xưởng.

Ngày 11/6/2007, Apple ra mắt phiên bản Safari đầu tiên hỗ trợ Windows.

Ngày 15/10/2007, phiên bản chính thức của Netscape Navigator 9 được công bố. Trình duyệt này tuy dựa trên mã nguồn Firefox 2.0, nhưng có thêm khá nhiều tính năng thú vị. Ít ai ngờ đây cũng là thế hệ sau cùng của nhánh Netscape Navigator. Ngày 28/12/2007, AOL thông báo sẽ ngừng phát triển Netscape kể từ 1/2/2008, tuy nhiên sau đó lại kéo dài sang tới 1/3. Vẫn có thêm 1 bản cập nhật 9.0.0.6 vào 20/2.

Tháng 12/2007, Firefox ra phiên bản 3.0. Ở thời điểm này, Firefox đã có hơn 16% thị phần, Netscape còn khoảng 0.6%. IE vẫn giữ tới 77.4% nhưng thị phần của nó liên tục bị cắn xé. Có cảm giác chắc chắn rằng, IE không sớm thì muộn cũng sẽ bại trận trước Firefox.

Sau cái chết của Netscape vào 1/3/2008 khiến cho giới công nghệ tiếc nuối không ít, mãi đến cuối 2008, Google mới tung vào sân chơi một đấu thủ mới. Đó là ngày 11/12, phiên bản đầu tiên của Chrome trên Windows được ra mắt cộng đồng. Đi kèm với nó là phiên bản nguồn mở Chrominum cho cả Windows, Linux và Mac.

Cuối 2009, đầu 2010, Firefox 3.5 đã trở thành trình duyệt phổ biến nhất, với hơn 32% thị phần. IE phải gộp cả mấy phiên bản 6, 7 và 8 lại thì mới được khoảng 49%. Đây là giai đoạn mà trên Windows, chức năng chính của IE chỉ là dùng để tải các trình duyệt khác.

Trước đó, tháng 3/2009, Microsoft đã release IE8 nhưng không nhiều cải thiện. Phải đến tháng 3/2011, khi IE9 ra đời, Microsoft mới tạm gọi là bắt nhịp được với chuẩn web hiện đại.

Thời kỳ thống trị của IE đến đây xem như đã chấm dứt, nhường chỗ cho Firefox bước lên đỉnh vinh quang.

Chrome là số một

Tuy nhiên, không ai nghĩ rằng Firefox sẽ giữ được vòng nguyệt quế dài lâu. Tân binh Chrome quá mạnh!

Chrome là một cuộc cách mạng về giao diện của trình duyệt. Nó đơn giản như Google. Các trình duyệt trước đó có quá nhiều toolbar, icons… Nào là menu bar, address bar, search box, tab bar, favorite bar, plugin bar, status bar… chiếm hết nửa màn hình. Chrome bỏ hết chỉ giữ lại tab bar và address bar, còn lại là không gian hiển thị trang web. So sánh giao diện Chrome với các trình duyệt khác tựa như nhìn một cô gái xinh đẹp thuần khiết với mấy con mẹ thành thị mặt đắp đầy son phấn và lủng lẳng các loại nữ trang!

Tốc độ vượt trội, tính năng mạnh mẽ, giao diện sáng sủa. Khỏi cần phải nói, ngay lập tức Chrome đã giành được cảm tình của người sử dụng.

Đặc biệt, nhịp độ phát triển của Chrome vượt xa mọi trình duyệt khác. Ngay cả Firefox với cộng đồng to lớn của nó cũng phải vài tháng nửa năm mới ra được một phiên bản mới, trong khi Chrome tự động update hàng ngày, mỗi tháng đều đặn upgrade lên một version.

Một năm sau ngày ra mắt, tháng 10/2009, Chrome đã chiếm được hơn 3.6% thị phần và tốc độ tăng trưởng ngày càng nhanh hơn kể từ khi có phiên bản Chrome cho Mac OS. Sang đến tháng 11/2011, thị phần của Chrome đã ngang ngửa Firefox.

Đồ thị dưới đây cho thấy sự bứt phá thần tốc của Chrome đối nghịch với quá trình tụt dốc thảm hại của IE trong vòng 6 năm từ 2008 đến 2014:
Web browser world time series since 2008 to 2014
Ngày nay, sân chơi trình duyệt không còn trăm hoa đua nở như thập niên trước. Mọi thứ đã đi vào ổn định. Chrome vững vàng ở ngôi vị trình duyệt số 1 trên thế giới, giữ khoảng 50% thị phần.

Kế tiếp là Firefox, IE và Safari, mỗi loại dao động trong khoảng 12% đến 18%. Từ tháng 5/2012, Apple đã ngừng phát triển Safari cho Windows. Nhưng thị phần của Safari không vì thế mà suy giảm, ngược lại, nhờ sự thành công của thương hiệu Apple, Safari từng bước chen lên top 4, đôi khi còn vượt qua cả Firefox.

Ở cuối top 5 trình duyệt phổ biến nhất thế giới, Opera vẫn luôn kiên trì đứng đó, mặc dù thị phần của nó chưa bao giờ đạt tới 5%.

Chrome sẽ còn thống trị thế giới trình duyệt web bao lâu nữa? Cái tên nào sẽ thay thế nó? Microsoft Edge hay Vivaldi? Có lẽ chúng ta phải chờ 5 hay 10 năm nữa mới biết được!


Links tham khảo:

Two-ways data binding với Object.observe

Các framework Javascript thường nhấn mạnh vào tính năng data binding như một ưu thế nổi bật của chúng. Nhưng thực ra bạn có thể thêm data binding vào ứng dụng Javascript của bạn một cách nhanh chóng và không có gì khó khăn cả.

Data binding về bản chất chỉ là việc đồng bộ thông tin một cách tự động giữa phần thể hiện ra ngoài trang web (DOM element, thường liên quan đến View) và phần dữ liệu được kiểm soát bên trong code Javascript (properties, thường liên quan đến Model). Vì thế, trong mô hình MVC, người ta thường hiểu data binding như là cơ chế tự cập nhật View khi Model thay đổi, và/hoặc tự cập nhật Model khi View thay đổi. Nếu sự đồng bộ diễn ra theo cả 2 chiều thì đó là two-ways binding.

Nguyên lý của data binding là theo dõi sự thay đổi của DOM và đối tượng Javascript liên quan, một khi có thay đổi ở phía bên này thì phát tín hiệu để cập nhật ở đầu kia của mối quan hệ.

Ảnh minh họa data binding, codeproject.com

Một trường hợp cụ thể

Giả sử chúng ta có 1 object:

var people = {
  firstName: "Dong",
  lastName: "Nguyen"
}

và chúng ta output thông tin này ra ngoài giao diện bằng đoạn HTML sau:

<input type="text" id="txtFirstName" value="">
<input type="text" id="txtLastName" value="">

Để hiển thị, chúng ta có script sau:

var people = {
  firstName: "Dong",
  lastName: "Nguyen"
}

var element = function(id){
  return document.getElementById(id);   
}

var $firstName = element('txtFirstName');
var $lastName = element('txtLastName');

var render = function(){
  $firstName.value = people.firstName;
  $lastName.value = people.lastName;
}

render();

Nhìn nó như thế này:

https://jsfiddle.net/ndaidong/76eadzth/1/

Ở đây nói về data binding tức là chúng ta muốn :
  • Khi user thay đổi giá trị của các input thì thuộc tính của people cũng thay đổi theo. Đây là chiều từ DOM tới Object.
  • Khi kịch bản làm cho thuộc tính của people thay đổi thì giá trị của các input cũng được thay đổi. Đây là chiều từ Object tới DOM.

Chiều thứ nhất: từ DOM tới Object

Để giải quyết việc đồng bộ từ DOM tới Object thì rất dễ vì có thể gắn event listener vào bất kỳ HTML element nào để lắng nghe. Chúng ta xử lý đoạn này trước bằng hàm domToObject như sau:

function domToObject(source, target, attribute){
  source.onchange = function(){
    var v = String(source.value);
    target[attribute] = v;
  }
}

Hàm này nhận vào 3 tham số, phần tử DOM đóng vai trò nguồn phát tín hiệu, đối tượng Javascript đóng vai trò tiếp nhận tín hiệu, và thuộc tính mà chúng ta muốn theo dõi. Bây giờ hãy thử cho kịch bản tự cập nhật các giá trị của đối tượng people khi bên ngoài input thay đổi:

 domToObject($firstName, people, 'firstName');
 domToObject($lastName, people, 'lastName');

Kết quả như thế này:

https://jsfiddle.net/ndaidong/76eadzth/15/

Các bạn thử thay đổi các giá trị trong inputs và nhấn button bên dưới để kiểm tra xem các thuộc tính của people đã được đồng bộ ra sao.

Chiều thứ 2: từ Object tới DOM

Bây giờ, chúng ta xét theo chiều ngược lại, từ Object tới DOM. Thời “xa xưa”, mọi thứ rất phức tạp. Hãy xem bài viết của Luca Ongaro cách đây 2 năm:

Easy Two-Way Data Binding in JavaScript

Nhưng bây giờ, với Object.observe, câu chuyện trở nên đơn giản hơn nhiều.

Đây là cách tôi xử lý, với một hàm objectToDom như sau:

function objectToDom(source, target, property){
  Object.observe(source, function(changes){
    changes.forEach(function(change){
      if(change.name === property){
        target.value = change.object[property];
      }
    });
  });
}

Hàm này cũng nhận vào 3 tham số, nhưng bắt đầu với source là một đối tượng Javascript, kế đó - target - là phần tử DOM móc nối với nó, và cuối cùng là property - tên thuộc tính mà chúng ta muốn nắm bắt sự thay đổi.

Kết quả như sau:

https://jsfiddle.net/ndaidong/76eadzth/16/

Trong demo, tôi để people tự thay đổi giá trị các thuộc tính firstNamelastName thành “Altonio” và “Vivaldi” sau vài giây. Các bạn có thể nhấn button để thay đổi chúng một cách ngẫu nhiên thành tên các tổng thống Mỹ ;)

Và đây là vấn đề chính: trong hàm objectToDom, tôi sử dụng Object.observe để theo dõi các biến đổi trên đối tượng Javascript.

Syntax của Object.observe như sau:

Object.observe(ob, callback);

Khi 1 hay một số thuộc tính của ob thay đổi, hàm callback sẽ được gọi cùng với tham số là một mảng chứa các thuộc tính đã thay đổi. Trên website của Mozilla có giải thích rất rõ về Object.observe.

Các ví dụ trong bài dùng để minh họa cách áp dụng data binding theo từng chiều ở mức độ cơ bản. Khi đưa vào thực tế, các bạn có thể cần bổ sung thêm các phương thức khác để testing, validating…

Now, hãy thử ghép chúng lại…

Đồng bộ 2 chiều

Dưới đây tôi sẽ xử lý cả 2 chiều cùng lúc bằng cách định nghĩa 1 đối tượng DataBinder như sau:

var DataBinder = (function(){

  var domToObject = function(source, target, attribute){
    source.onchange = function(){
      var v = String(source.value);
      target[attribute] = v;
    }
  }

  var objectToDom = function(source, target, property){
    Object.observe(source, function(changes){
      changes.forEach(function(change){
        if(change.name === property){
          target.value = change.object[property];
        }
      });
    });
  }

  var isElement = function(v){
    if(!!v && typeof v === 'object'){
      var ots = Object.prototype.toString;
      if(ots.call(v).indexOf('HTML') !== -1 && ots.call(v).indexOf('Element') !== -1){
        return true;
      }
    }
    return false;
  }     

  var start = function(source, target, attr){
    if(isElement(source)){
      domToObject(source, target, attr);
      objectToDom(target, source, attr);
    }
    else{
      objectToDom(source, target, attr);
      domToObject(target, source, attr);
    }
  }

  return {
    domToObject: domToObject,
    objectToDom: objectToDom,
    start: start
  }
})();

Như các bạn thấy, DataBinder có 3 public methods: domToObject, objectToDomstart dùng để tự động bind theo 2 chiều. Nhờ đó tôi chỉ việc gọi:

DataBinder.start(people, $firstName, 'firstName');
DataBinder.start(people, $lastName, 'lastName');

Hoặc có thể đảo thứ tự 2 tham số đầu tiên:

DataBinder.start($firstName, people, 'firstName');
DataBinder.start($lastName, people, 'lastName');

Dù thế nào, kết quả thu được vẫn như sau:

https://jsfiddle.net/ndaidong/76eadzth/17/

Cần nhắc lại, DataBinder như trên vẫn thiếu một vài thứ như exception handling, validation… Trong bài này, tôi chỉ muốn share concept của Object.observe và việc áp dụng nó trong two-ways data binding mà thôi.

Lời kết

Object.observe được mô tả trong ES7, hiện nay mới chỉ có trình duyệt Chrome hỗ trợ (33+). Nhưng polyfills của Jeremy Darling hoặc MaxArt2501 viết sẽ giúp bạn đem nó vào các trình duyệt khác. Chỉ việc load script từ CDN của Polyfills.io như cách tôi load vào JSFiddle.

Mong rằng qua những gì tôi đề cập trên đây, các fan mới của Javascript có thể hiểu được bản chất vấn đề data binding và có khả năng ứng dụng Object.observe vào thực tiễn.

Cảm ơn các bạn đã theo dõi bài viết này.

Những skills mới cho web developer 2015



Thế giới web năm 2015 sẽ có nhiều thay đổi mang tính cách mạng, dưới đây tôi điểm qua một số nét chính. Bên cạnh mỗi cái tên sẽ là chỉ số đánh giá mức độ cần kíp của skill đó - theo quan điểm cá nhân thôi :)


1. Web Components: 10/10


Web Components là một trong những thuật ngữ quan trọng nhất hiện nay. Nó bao gồm 4 khái niệm chính yếu: Custom Elements, HTML Imports, HTML TemplatesShadow DOM.

Với Web Components, khả năng của HTML và trình duyệt sẽ được mở rộng ra vô hạn. Đó là một thế giới web hoàn toàn mới, tràn đầy sức mạnh sáng tạo. Theo đó, web developers sẽ phải thay đổi quan niệm về cấu trúc hồ sơ DOM truyền thống, cấu trúc trang web, cũng như cấu trúc files/folders của hệ thống web. Có thể cách làm cũ ( viết trang HTML, nhúng các files CSS và JS vào) sẽ trở nên không còn hợp lý nữa. Thay vào đó, người ta cần tách ra nhiều components và phối hợp chúng lại thành trang web. Giống như cách chúng ta chia 1 mặt bằng ra nhiều mảnh cho nhiều nhà thầu đến xây dựng vậy. Quy trình làm web vì thế tất yếu cũng sẽ thay đổi theo. Mỗi component là 1 tổ hợp hoàn chỉnh của HTML, CSS và JavaScript được đóng gói trong 1 scope riêng biệt, có thể tương tác lẫn nhau nhưng không ảnh hưởng lẫn nhau. Hiện nay, nếu bạn nhúng cả jQuery 2.1 và jQuery 1.2 vào cùng trang web, sẽ chỉ có 1 thư viện chạy, và thế nào cũng có lỗi xuất hiện đâu đó. Nhưng với Web Components, bạn có thể dùng nhiều version của cùng library/framwork trên cùng trang web. No problem.

Trong tưởng tượng của tôi, tương lai có thể sẽ ra đời 1 dạng Web Components Market nơi các developers làm và bán components như là người ta đang bán Widgets và jQuery Plugins hiện nay vậy.

Angular 2 sẽ tận dụng khả năng của Web Components để xử lý lại một số vấn đề chưa tốt trong Angular 1.x như databinding, templating… Đặc biệt Tranclusion trong Angular 1 sẽ bị loại bỏ, thay vào đó Angular 2 sử dụng Shadow DOM.

Hiện có nhiều cách tiếp cận Web Components, như Polymer của Google, X-tags của Mozilla, và Bosonic. Hy vọng rằng tất cả rồi sẽ hợp lại trong 1 ecosystem thay vì cứ phân tán như vậy.

Theo đánh giá của tôi, Web Components là kiến thức bắt buộc phải có đối với front-end developer hiện nay.

2. ES6: 9/10


Đặc tả ECMA-262 biến JavaScript mà chúng ta đang dùng trở thành một thứ gì đó hoàn toàn mới lạ. Có lẽ không nhiều hơn 10% javascripter trên thế giới hiện nay đủ khả năng chơi với nó. Nhưng tôi tin rằng cho đến cuối năm, con số đó sẽ tăng lên hơn 50%. Hiện đã thấy nhiều framework cho Node.js và browser được viết trên đặc tả ES6, như WaigoJS, AureliaIO.js đã hỗ trợ ES6 ngay từ khi ra mắt.

Các chức năng nổi bật trong ES6 gồm arrow function, subclassable built-ins, và collections (Maps, Sets…) Những chức năng khác như classes, modules, module loaders, promises, proxies… thì những developers xông xáo chắc cũng đã làm quen trên Node.js hoặc thông qua các polyfills rồi. Bên cạnh đó, ES6 cũng thêm vào không ít methods cho các đối tượng dựng sẵn.

Angular 2 sẽ dùng ES6 Modules thay cho Angular Modules ở v1. Nếu bạn muốn tiếp tục theo đuổi Angular, bạn sẽ cần phải nghiên cứu sâu hơn về ES6.

3. TypeScript: 6/10


Lâu nay JavaScript vẫn bị các lập trình viên khó tính xem là ngôn ngữ không mạnh, và nguyên nhân chính là do nó thiếu những ràng buộc chặt chẽ về kiểu (type). TypeScript là JavaScript được mở rộng thêm khả năng định kiểu, modules, classes, interfaces, namespaces… vô cùng phức tạp chẳng kém gì các ngôn ngữ hệ thống. Tôi chưa thực sự dùng cái này nhưng nhìn code khá đẹp mắt, ở mức sơ đẳng thì cũng giống như khai báo schema trong Mongoose thôi!

Thoạt tiên tôi có ý nghĩ rằng những thứ này có thể làm hỏng tính đơn giản, linh hoạt của JavaScript. Nhưng nhìn sang PHP, phải chăng nó cũng đang đi cùng một hướng. Cả PHP và JavaScript đều bắt đầu như những ngôn ngữ scripting thuần túy, dần hoàn thiện theo thời gian để trở thành những ngôn ngữ lập trình chặt chẽ, powerful. Đặc biệt là khi JavaScript ngày nay không chỉ quanh quẩn trên browsers mà đã tràn lên cả servers và handset devices. Nó cần phải mạnh mẽ hơn, chắc chắn hơn để có thể làm chủ các vùng đất nhạy cảm đó.

TypeScript là 1 đóng góp đáng giá của Microsoft cho thế giới web. Các tác giả của Angular đã tạo ra AtScript cho Angular 2 nhưng sau cùng vẫn phải loại bỏ để dùng TypeScript. Tuy nhiên bạn không cần quá đặt nặng TypeScript lúc này. Nó chỉ đơn giản là syntax, dùng nhiều sẽ quen.

4. SystemJS: 10/10


Trong vài năm trở lại đây, module pattern trở thành khái niệm phổ biến nhất trong kiến trúc nền tảng JavaScript. Từ module pattern mới nảy sinh ra 2 khái niệm khác là AMD (Asynchronous Module Definition) và DI (Dependencies Injection). Đã có nhiều giải pháp cho vấn đề AMD như CommonJS, RequireJS, curl.js… Nhưng có vẻ đã đến lúc kết thúc cuộc đua, và tôi đoán rằngSystemJS sẽ thay thế tất cả, vì nó đi cùng ES6; làm việc với mọi compiler; tương thích mọi phương thức module loading cũ; hỗ trợ map, path, bundles… Thậm chí nó có thể thay thế cả lệnh require quen thuộc trên Node.js server.

AMD là khái niệm mà web developer phải nắm vững từ ít nhất 1 năm trước, bằng không bạn sẽ chỉ mơ hồ đứng sau các framworks mà không hiểu tại sao nó phải viết như thế, cái gì khiến nó phải tổ chức như thế… Nếu bây giờ bạn vẫn chưa vận dụng AMD được một cách tự nhiên thì phải lập tức khắc phục hạn chế này.

5. jspm: 10/10


Không phải bower, browserify… mà là jspm sẽ chấm dứt thời kỳ cát cứ phân tranh của các package management tools trên browsers. Tôi tin chắc điều đó vì jspm được thiết kế cho SystemJS, hỗ trợ mọi định dạng module từ RequireJS, CommonJS đến ES Harmony. Nếu các bạn để ý rằng bower chỉ làm 1 việc duy nhất là chạy lệnh ngầm tải repositories từ GitHub về thư mục bower_components ở local, thì jspm làm việc với cả GitHub và NPM, cho khả năng xử lý trùng lặp, version index, và tìm kiếm tốt hơn rất nhiều.

Tuy ít được biết đến như bower, nhưng jspm với sự tương thích SystemJS/ES6 chắc chắn sẽ trở thành giải pháp hoàn chỉnh cho vấn đề quản lý packages và dependencies trên front-end.

Trên đây là những kiến thức dành cho front-end developers mà tôi tin rằng sẽ vô cùng hot vào nửa cuối năm 2015. Sẽ rất tuyệt nếu các bạn để mắt đến chúng và thử trải nghiệm ngay từ bây giờ.



Links tham khảo:

6 bí quyết dứt điểm công việc




Mọi người luôn thắc mắc về khả năng dứt điểm công việc của tôi. Ở trường phổ thông, lên đại học, khi đi làm hay trong những hoạt động tôi đã tham gia suốt nhiều năm, tôi vẫn thường được hỏi cùng một câu đó: "Chị lấy đâu ra thời gian?"

Nhưng tự xét thì tôi cũng chẳng có kỹ xảo gì đặc biệt. Giống như nhiều người khác, tôi cũng dây dưa lần lữa khi không muốn làm điều gì đó, và tôi thường chỉ làm đến mức tối thiếu yêu cầu của công việc, nhưng đó có vẻ vẫn là kỳ tích đối với một số người.

Vì thế tôi đã thử lục lọi trong tâm trí và nêu ra đây vài ý tưởng để giúp bạn nếu bạn đang cảm thấy ngập đầu công việc.


1. Có danh sách công việc cho mỗi ngày


Hằng đêm, trước khi đi ngủ, hãy lập danh sách những công việc quan trọng nhất cho ngày hôm sau.

Danh sách nên ngắn gọn khoảng 3 đến 4 mục để tránh gây áp lực.

Tôi vốn không phải là tín đồ công nghệ nên chỉ dùng 1 cái bảng trong nhà bếp để ghi những gì phải làm. Xong việc nào thì đánh dấu hoàn tất việc đó, như vậy tôi có thể trông thấy những gì đã làm được trong ngày.


2. Dành thời gian thực hiện và bám sát kế hoạch.


Hãy tự cam kết và thực hiện kế hoạch một cách nghiêm túc. Ghi đầu việc vào nhật ký, lịch, hay bảng viết. Một khi đã ghi ra thì phải làm cho được. Giới hạn mỗi đầu việc trong một khoảng thời gian nếu cần. Các đầu việc của tôi thường mất khoảng 20 đến 30 phút, đảm bảo rằng chúng đều là những việc khả thi.

Tôi viết phần lớn bài này trong vòng 20 phút. Tất nhiên là phải mất thêm nhiều thời gian hơn để hoàn chỉnh, nhưng trong 20 phút làm việc tập trung, căng thẳng tôi đã có thể viết ra hầu hết ý tưởng trong một dàn bài. Bạn sẽ cảm thấy ngạc nhiên vì số lượng công việc có thể làm dứt điểm khi dành trọn vẹn tâm tư để thực hiện chúng trong khoảng thời gian ấn định sẵn, không bị gián đoạn.

Điều này dẫn tôi đến ý tưởng kế tiếp...


3. Tránh xa mọi sự phiền nhiễu


Tắt điện thoại. Ngắt mạng (dân IT đừng nghe tác giả điểm này! - DN). Dán thông báo "Không phận sự miễn vào" lên trước cửa. Hãy đảm bảo không ai quấy rầy bạn.

Rất dễ để "ngó qua" Facebook hoặc mấy thứ vớ vẩn khác rồi mất hàng giờ tán dóc và xem xét chúng. Đừng để bị chúng lôi cuốn!


4. Đừng trì hoãn. Hãy tự hỏi: "tại sao?"


Cuối năm, tôi dự tính đăng ký một chương trình tiếp thị liên kết. Việc này rất đơn giản, chỉ mất vài phút là xong.

Nhưng thật trớ trêu, cũng chính vì sự dễ dàng đó mà tôi đâm ra bê trễ. "Chỉ mất có 5 phút thôi mà, để mai làm cũng được!" - tôi cứ nghĩ bụng vậy, hết ngày này sang ngày khác.

Cuối cùng tôi phải tự hỏi tại sao chỉ có cái việc đơn giản thế mà mãi không xong? Phải chăng tôi sợ thừa tiền, hay là cảm giác áy náy khi nhận tiền mà chẳng bỏ công?

Rất nhanh chóng, ngay khi tự hỏi như vậy tôi đã đồng thời hành động. Tài khoản được tạo chỉ trong chưa đầy 5 phút.


5. Tách việc lớn ra thành các việc nhỏ


Bên cạnh danh sách công việc hàng ngày, tôi cũng bắt đầu lập danh sách công việc cho mỗi tháng. Một trong các việc tôi phải làm trong tháng Một là mở gian hàng. Đó là việc tôi chưa từng làm trước đây và khiến tôi lo lắng. Rất lo lắng.

Thế rồi bất chấp sợ hãi, tôi lao đầu vào công việc và đi tong luôn tuần đầu tiên của tháng để bận rộn lên kế hoạch cho khóa học 4 tuần. Cũng tốt, tháng Một đã đến rồi đi trong khi gian hàng vẫn chưa có.

Thay vì xấu hổ cho nhiệm vụ bất thành, tôi kiểm tra lại trong danh sách đầu việc để xem mình đã diễn đạt nó ra sao. Trông nó như thế này:

- Workshop

Chính là vậy. Đối với công việc phức tạp này, lẽ ra tôi nên chia nhỏ ra nhiều bước để rồi hoàn thành từng bước. Trong trường hợp trên, đó là phải liên hệ với một người bạn đã từng nói rằng chị ấy biết người quan tâm đến gian hàng, và rồi xem thử nên đặt nó ở đâu.

Bây giờ nhiệm vụ tháng Hai của tôi ghi là: "Bố trí một ngày." Nghe ra đã bớt nguy hiểm hơn nhiều!

Chia nhỏ các task lớn khiến cho công việc dễ quản lý hơn và cũng dễ làm hơn.


6. Tưởng thưởng


Tôi cũng chỉ mới hiểu ra tầm quan trọng của việc tự mình tưởng thưởng cho mình sau mỗi công việc hoàn tất. Hơn một năm trước, tôi dự một khóa học trong đó người ta dạy cách tự thưởng mỗi tuần. Tôi chưa từng làm vậy. Tôi cứ lập kế hoạch ra rồi quên lãng rồi lại kết luận rằng việc đó không đáng.

Gần đây, tôi lại theo một khóa học viết trực tuyến, ở đó vào cuối khóa chúng tôi cũng được nghe nói thêm về sự tự tưởng thưởng. Lần này, tôi mua cho mình một cây đàn piano.

Phần thưởng không cần phải lớn hoặc đắt giá. Nó có thể là một chút thư giãn bên ly trà, hay một chuyến nghỉ mát, nhưng quan trọng hơn cả là nó cho bạn một sự xác nhận rằng bạn đã hoàn tất công việc, nó cũng khích lệ bạn tiếp tục phấn đấu khi mọi thứ trở nên khó khăn hơn.


Trên tất cả, hãy nhớ rằng đó không phải là một cuộc đua. Hãy làm những gì bạn có thể làm trong ngày và cho phép mình được xả hơi.

Sau mỗi phần việc hoàn tất và được ghi dấu, bạn sẽ càng đến gần mục tiêu của bạn.


------------------------------------------

Louise Watson là chủ nhân của blog http://www.louisemwatson.com/ nơi  chị thường đăng tải những bài viết thú vị về phong cách sống. Ngoài ra  chị cũng viết bài cho nhiều trang tin khác ở Mỹ. Người ta thường biết đến Louise qua 2 tựa sách "Stop making your life a misery" và "Shy altitude".



Tạo môi trường dev thông minh bằng virtual machine

Setup environment trên máy tính để dev là công việc bắt buộc phải làm ngay khi bước vào triển khai dự án. Websites và webapps ngày nay thường được build dưới hình thức của những tổ hợp công nghệ, kết nối nhiều nguồn tài nguyên lại với nhau, khiến cho vấn đề setup environment và đồng bộ hóa các environments giữa máy chủ production và máy chủ dev, cũng như giữa các máy dev với nhau trở nên khó khăn hơn.

Có rất nhiều tổ hợp công nghệ, chẳng hạn MEAN stack là tổ hợp MongoDB, ExpressJS, AngularJS và Node.js - chúng đi với nhau và bạn phải hiểu cả 4 thứ để kiểm soát được chúng. Hay như tổ hợp LAMP kinh điển (Linux – Apache – MySQL – Perl/PHP) dù đã trải qua hàng chục năm nhưng vẫn được sử dụng mỗi ngày. Với xu hướng cloud computing hiện nay,  mọi việc không dừng ở đó. Nhiều công nghệ mới cũ được tổ hợp lại với nhau theo những cách thức vô cùng phức tạp, khó mà nắm bắt. Bằng cách kết hợp một số trong những cái tên dưới đây, người ta có thể tạo ra vô vàn kiến trúc:

  • Cloud computing: Amazon, Azure, Rackspace...
  • OS platform: RedHad, Ubuntu Server, CentOS...
  • Web server: Apache, nginx, Tornado, Node.js...
  • Database: MariaDB, MongoDB, CouchDB, Neo4j…
  • Mail server: Dovecot, Axigen, deepOfix...
  • Background processing: Gearman, RabbitMQ, Beanstalkd...
  • PubSub: Redis, Parse...
  • Search engine: Elasticsearch, Sphinx, Solr...
  • Caching: Varnish, Memcached, APC / OpCache....
  • Monitoring: Nagios, SolarWinds, OpManager...

Một hệ thống web có thể bao gồm nhiều thành phần, phân tán ra nhiều đám mây, chạy trên nhiều OS, sử dụng nhiều loại databases,  web servers và áp dụng nhiều kiểu caching. Developers lần đầu tiếp cận một tổ hợp công nghệ có thể phải mất hàng tuần để setup environment mà chưa chắc đã thành công.


May mắn thay, chúng ta có thể giải quyết tất cả những điều đó bằng một concept: "virtualization".

Đã đến lúc nói tạm biệt với localhost!

Mở file cấu hình database connection trong dự án mới nhất của bạn, nếu có chữ "localhost" đâu đó thì hãy cẩn thận: có thể bạn vẫn chưa sẵn sàng cho sân chơi cloud computing, clustering và cross-platform. Nó cũng giống như một web developer sau 3 năm làm việc với PHP/MySQL mà vẫn dùng XAMP vậy. Nó có nghĩa là bạn đang chạy tất cả các services trên cùng một máy. Nó có nghĩa là ứng dụng của bạn đang vận hành trên một hệ sinh thái không giống chút nào với thực tế ngoài kia.

Không có 2 hệ thống hoàn toàn giống nhau. Developer phải có khả năng thiết kế environment đặc thù cho từng hệ thống, và phải tìm cách tách biệt các dịch vụ khác nhau ra các servers khác nhau. Đó là khu biệt hóa chức năng để tối ưu hóa performance. Ít nhất cũng nên để ứng dụng web ở máy chủ dịch vụ web, còn database ở trên server chuyên về lưu trữ. Tại vì:

- Nếu server chỉ cung cấp một service duy nhất, bạn có thể yên tâm áp dụng cấu hình tốt nhất cho riêng service đó.
- Dễ dàng thực thi các thao tác backup, replicate... trên máy chủ database, cũng như  scaling máy chủ ứng dụng web.

Cấu hình database connection nên có những IP addresses thay vì  chỉ "localhost" hay "127.0.0.1".

Để làm điều đó thì bạn không nên install mọi thứ đồ nghề lên PC một cách trực tiếp, mà hãy tạo ra các máy ảo và cài đặt tools trên máy ảo.

Virtualize it! Hãy ảo hóa môi trường dev của bạn!

SSH to virtual web server.png
Figure 1 : Kết nối vào máy ảo bằng Terminal

Điều này giúp bạn:

  • giữ cho máy tính luôn sạch sẽ: vì mọi thứ chỉ hoạt động trong sandbox. Tắt máy ảo là xong. Đặc biệt nếu là máy tính riêng, chắc hẳn bạn không muốn tốn resource để giữ nginx và mongodb chạy trong khi đang xem YouTube.
  • dễ dàng thay đổi môi trường dev: bạn có thể dev 1 dự án đang chạy CentOS và 1 dự án khác dùng Windows Server mà không cần rời xa giao diện Mac OS và các software quen thuộc.
  • thao tác với máy ảo ở local cũng giống như với các máy ảo trên AWS, Azure, WebFaction... Bạn sẽ không phải lúng túng khi được quăng cho 1 cái EC2 instance mới. Xem các hình Figure 1 và Figure 2, hệ thống server trên EC2 được tái hiện trong hệ thống server ảo tại local.
  • có thể tạo ra hệ thống nhiều server với cấu hình và limit như trong thực tế. Ví dụ website của bạn dùng 3 con EC2 trong đó có 1 con m3.xLarge và 2 con  m3.medium, bạn có thể tạo ra 3 máy ảo và set RAM, storage… y như vậy để test performance và khả năng đáp ứng.
  • và đây là điều quan trọng nhất: bạn có thể clone máy ảo ra cho nhiều người khác cùng sử dụng. Mọi thứ đều consistent, không chút nào khác biệt.

Có nhiều công cụ giúp bạn tạo máy ảo, như VMware, VirtualBox, OpenVZ, Xen... ở đây chủ yếu nhắc đến VirtualBox, vì công cụ này chạy được trên cả Windows, Mac và Linux. Về cách cài đặt và sử dụng VirtualBox, các bạn có thể tham khảo chi tiết tại link dưới:


AWS EC2 instances.png
Figure 2 : Các instances trên AWS EC2


Nhưng trước hết hãy ghi nhớ một số khái niệm cần thiết khi làm việc với các công cụ ảo hóa.

Các concepts trong visualizing

  • PM (physical machine) : máy tính vật lý của bạn
  • VM (virtual machine) : máy ảo được tạo ra bên trong PMs, cô lập với môi trường của PMs
  • Host (host OS) : là hệ điều hành gốc trên PM.
  • Guest (guest OS) : hệ điều hành chạy trong VM.
  • Guest Additions : phần mở rộng chức năng cho guest giống như drivers trên host.
  • Shared folders : các thư mục dùng chung giữa host và guest. Đây là khái niệm đặc biệt quan trọng, nhờ nó, bạn có thể lưu trữ, chỉnh sửa source code bằng IDE quen thuộc trên host OS, và run chúng trên guest OS. Chỉ có thể dùng Shared folders sau khi đã cài đặt Guest Additions cho VM.

Sau đây, tôi đề cập một số bước nên làm khi ảo hóa môi trường dev.


Những điều nên làm với visualizing

1, Tạo sẵn một bộ core

Cài đặt một server lên máy ảo hoàn toàn giống như cài đặt trên máy vật lý. Bạn vẫn mất chừng đó thời gian để điền các thông tin và chờ đợi quá trình sao chép hệ điều hành lên hard disk hoàn tất. Vì vậy, bạn nên setup các bộ core trước. Đó là các máy ảo cài đặt sẵn Ubuntu Server, RedHad, CentOS... và chỉ có duy nhất hệ điều hành, không chứa gì khác.

Bạn có thể chạy các lệnh update và upgrade lên version mới nhất, rồi install thêm 2 thứ: gitopenssh-server. Git là công cụ phải có để quản lý source code. OpenSSH-Server cho phép bạn login vào máy ảo này qua ssh. Dùng ssh trên cửa sổ terminal riêng tiện hơn là thao tác qua giao diện QEMU mặc định của máy ảo.

Kế đó, bạn dùng chức năng export của VirtualBox để xuất ra các file nén OVA.  Từ các files nén này, bạn có thể import trở lại VirtualBox để tạo ra các máy ảo mới.

Tới đây, bạn đã có những server "ready-to-use". Chúng có thể bao gồm Ubuntu-core, RedHad-core, CentOS-core... Từ các bản standard này, bạn có thể phát triển theo nhiều nhánh: máy chủ dữ liệu, máy chủ web, file server, etc.

2, Tạo ra các máy ảo chuyên dụng

Giả sử bạn đi theo dòng Ubuntu, trước hết, bạn cần đem phiên bản Ubuntu-core import vào VirtualBox, đặt tên máy ảo mới là WebServer rồi login vào. Ở trong máy ảo WebServer này, bạn cài đặt nginx cho lắng nghe cổng 80, cài thêm Apache cho lắng nghe cổng 8080, cài Node.js, PhantomJS, và các đồ nghề cần thiết cho máy chủ web. Sau khi hoàn tất mọi thứ, đừng vội sử dụng mà hãy export ra một file OVA để tiện dùng lại sau này.

Tương tự, cũng dùng Ubuntu-core để tạo ra 1 máy ảo khác gọi là DbServer chẳng hạn. Login vào máy này và install MongoDB, MariaDB... sau đó, cũng export ra một file OVA trước khi sử dụng.

Tới đây, bạn đã có 3 files: Ubuntu-core.ova, WebServer.ova, và DbServer.ova. Thậm chí bạn có thể build sẵn những máy ảo chuyên biệt hơn, chẳng hạn MongoDB.ova, Neo4j.ova, nginx.ova, ApacheTomcat.ova, etc. Không có giới hạn nào cho khả năng sáng tạo của bạn. Mục tiêu duy nhất là làm cho việc setup môi trường trở nên nhanh chóng và hoàn hảo.

OVA files.png
Figure 3 : My .OVA files

Bất kể ở thời điểm nào bạn cũng có thể dùng lại chúng để tạo ra máy chủ cần thiết trong vài phút. Nếu một team khác cũng cần dùng Neo4j, bạn chỉ việc share file Neo4j.ova để họ tự tạo ra máy ảo sẵn có Neo4j.  Không cần phải làm gì thêm nữa! Một team khác cần máy chủ chạy Node.js 0.10.35, có Redis để chạy PubSub. OK. Bạn chỉ việc import WebServer.ova, tạo máy ảo mới, login vào, thêm 1 phút để install redis-server. Xong export ra thành NodeRedis.ova đưa cho họ sử dụng. Chưa bao giờ công việc trở nên dễ dàng hơn thế! Giả như họ cài đặt linh tinh làm server lỗi cũng không sao, cứ remove VM đó đi và import lại NodeRedis.ova trên  một VM mới là được.


4. Dùng static IP

Các máy ảo nên được cấu hình sử dụng static IP để tránh phải điều chỉnh file hosts nhiều lần. Để biết IP hiện tại của máy ảo, bạn login vào guest và gõ lệnh ifconfig.

Thiết lập static IP bằng cách chỉnh sửa file /etc/network/interfaces. Ví dụ sau dùng nano:

~ $ sudo nano /etc/network/interfaces

Đây là một file mẫu chuẩn (thay X bằng 1 số bất kỳ, chú ý conflict):

/////////////////////////////////////////////////////////////////////
GNU nano 2.2.6         File: /etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.1.5
gateway 192.168.1.1
netmask 255.255.255.0
broadcast 192.168.1.255
# Using wifi
# wpa-ssid
WIFI_NAME
# wpa-psk PASSWORK_WIFI_HERE
# Set DNS
# dns-nameservers 8.8.8.8 8.8.4.4
/////////////////////////////////////////////////////////////////////

Sau khi khởi động lại VM, bạn có thể connect đến guest OS này bằng SSH từ trên host OS:

~ $ ssh root@192.168.1.x


Tham khảo thêm cơ chế networking của VirtualBox:



5. Mouting và Symlink

Để chạy source code của 1 website trên máy ảo, bạn nên mount thư mục chia sẻ vào một nơi cố định, chẳng hạn: /var/www/shared

Nếu mounting thành công, bạn có thể thấy các thư mục web xuất hiện trong location này.

Sau đó, bạn sẽ cấu hình server point tới đây như khi làm trên máy thực.

Bạn cần để cho server script chạy trong guest OS có thể sửa đổi files/folders ở host OS (nằm dưới shared folder). Lệnh sau giúp mounting chính xác trên VM chạy Linux:

~ $ sudo mount -t vboxsf -o uid=1000,gid=1000 SHARED_FOLDER /MOUNT_PATH


Một vấn đề thường gặp khác là symlink. VirtualBox không cho phép dùng symlink trong guest. Nếu bạn thực sự cần dùng symlink, hãy tham khảo:


Một số module Node.js tự động thiết lập symlink khi install. Điều này có thể gây ra lỗi. Tuy nhiên Node.js cung cấp tùy chọn -no-bind-links để ngăn chặn việc tạo symlinks:

~ $ sudo npm install --no-bind-links


Tham khảo:



6. Máy vật lý cũng nên có cấu trúc phù hợp

Một khi đã áp dụng hệ thống máy ảo cho môi trường dev, vai trò của máy thực sẽ ít quan trọng hơn. Bạn có thể làm việc trên Windows, Linux hay Mac OS X tùy ý. Dù sao máy tính cho developer nên là multi boot chứa ít nhất 1 Windows và 1 Linux, có phân vùng chung giữa các OS này.

Nhiều máy hiện nay vẫn áp dụng cách chia phân vùng ổ cứng truyền thống, thời Windows XP. Tôi nhớ là dạo đó người ta hay chia ổ cứng thành 4 phần :

  • C: System chứa file hệ thống
  • D: Data chứa dữ liệu công việc
  • E: Entertainment chứa phim ảnh, game, nhạc…

Developer phần mềm thì không nên làm như vậy. Theo kinh nghiệm của tôi, với 1 ổ cứng bất kỳ, chúng ta nên phân chia như sau:

  • Partition 1 (30% dung lượng): Windows OS, 7 hay 8 tùy cấu hình máy
  • Partition 2 (30% dung lượng): Linux, Ubuntu hoặc Linux Mint
  • Partition 3 (38% dung lượng): Storage, FAT32, chứa dữ liệu mà cả Windows và Linux có thể truy cập. Các files OVAs, source code, libraries/packages… hãy để  ở đây.
  • 2% dung lượng còn lại dùng cho hệ thống, như swap, EFI, etc.

Tôi không rõ Norton Ghost có thể tạo ra các bản ghost multi boot như: Win7-Mint, Win8-Ubuntu, Win8-Mint-Solaris, etc… hay không. Nếu được vậy thì quá tốt!


Kết luận

Trên đây là những định hướng trong việc áp dụng công nghệ máy ảo để tạo ra môi trường dev thông minh, linh hoạt, nhằm cải thiện hiệu suất công việc và nâng cao năng lực thiết kế, kiểm soát, vận hành hệ thống máy tính, máy chủ. Mức độ áp dụng vào thực tiễn như thế nào đòi hỏi sự mạnh dạn thay đổi nhận thức cũng như thói quen ở mỗi developer và những người quản lý.