Huyền thoại Ruby on Rails đã sụp đổ nhờ PHP

Cách đây 3 năm Ruby on Rails bắt đầu tấn công vào cộng đồng Java nhờ những lời lẽ khoa trương về sức mạnh của nó. Dereck của CDbaby đã bị xao động và quyết định viết lại website của ông ta dựa trên Rails sau khi tuyển mộ một trong các nhân vật chủ chốt của cộng đồng Rails. Hai năm sau đó Dereck đã thấm đòn: Ruby và Rails không phải là viên đạn bạc cho các ứng dụng web.

Ông ta đã tiến hành viết lại site của mình bằng PHP trong 2 tháng và giảm số dòng code từ 90 000 dòng Ruby/Rails xuống còn 12 000 dòng PHP với những bài học rút ra được từ cách tổ chức ứng dụng theo tinh thần của Rails. Những gì ông ta có được đều rất đáng kể: tốc độ, khả năng bảo trì của ứng dụng, không còn ác mộng về Rails.

Trên thực tế Dereck trở về với PHP không phải là ko có lý do. Rails đã cho ông ta bài học khá tốt về lập trình hướng đối tượng theo phong cách mới khi mà năm 2005, cộng đồng PHP chưa đủ chín cho việc đó. Năm này, tôi có bài viết đầu tiên của mình về PHP5 với các tính năng hướng đối tượng trên PCWorld nhưng 2 năm sau đó cộng đồng PHP ở VN vẫn dẫm chân tại chỗ. Nhưng cũng phải mất 2 năm tôi mới thực sự hiểu lập trình hướng đối tượng trong PHP khi đánh vật với framework của riêng mình trong 16 tháng qua. Mọi vấn đề chỉ có thể được đào xới thông qua lao động thực sự. Nhưng những điều tốt đẹp đã hẳn không thể đến sau vài năm ngắn ngủi nếu như đã không có sự chuyển biến rất lớn trong cách tư duy của cộng đồng PHP: đó là mô hình hướng đối tượng ngày càng được hoàn thiện từ bản 5.0 sang 5.1. Hiện tại chúng ta đã có bản 5.2 ổn định hơn rất nhiều. Bản 5.3 sẽ xuất hiện sau 3-4 tháng nữa với Late static binding và name space hứa hẹn sẽ hoàn thiện hơn mô hình OOP của PHP. Cùng lúc đó người dùng không cần chờ đến PHP6 để có được sự hỗ trợ Unicode buit-in trong PHP mà extension intl đã được back port sang PHP5. Và lập trình viên PHP (như tôi) đã có 2 năm để đánh vật với lập trình hướng đối tượng trong PHP5 đủ để hiểu những chi phí ẩn và lợi ích đi kèm. Nhiều người đã phải cần đến một công nghệ khác làm nền tảng (với tôi là Java) khi mà common sense trong cộng đồng PHP còn khá khiêm tốn. Mọi người cũng đã thấy sự hoàn thiện dần của Zend

Framework, SolarPHP, CakePHP, Symfony, sự ra đi của Mojavi, Phrame, Blueshoes ... và vô số các framework khác như là sự kết thúc các thử nghiệm thất bại trong việc tìm ra một mô hình phát triển đúng đắn cho PHP framework. Mặc dù tất cả các web framework đương đại đều có các điểm yếu riêng của nó khiến một ai đó trong chúng ta không hài lòng (trong đó có tôi) thì chúng ta cần thừa nhận rằng sự phát triển đó đã rút ngắn khoảng cách công nghệ giữa Ruby và PHP trên một số phương diện thuần ngôn ngữ. Dereck vốn có quan hệ thân thiết với một số key figure trong cộng đồng PHP và hiển nhiên đã nhận thức được điều này. Thế là cuộc phiêu lưu với Rails chấm dứt.

Bài học của Dereck để lại vài nhận thức:

- Thế giới PHP đã có quá nhiều thay đổi: các lập trình viên PHP nên ngừng code và nghe ngóng đi kẻo tư duy của bạn đã lạc hậu so với phần còn lại của thế giới.

- Đứng cố theo đuổi một công nghệ cho một dự án nếu như với loại dự án đó nó không work. Hãy cân nhắc nó trong tương lai. Hãy nhận thức điều đó sớm hơn nếu muốn tránh hiệu ứng hệ thống thứ 2 trong công nghệ phần mềm.

- Chọn công cụ đúng. Ngôn ngữ là một công cụ nhưng framework cũng là một công cụ theo nghĩa hẹp hơn hơn nhiều. Nó không phải là viên đạn bạc. Ví dụ dùng PHP để lập trình Desktop application vào thời điểm hiện tại là dở hơi. Ví dụ PHP có thể không hiệu quả như Perl trong các ứng dụng system scripting. Và nó chỉ đúng khi nó vừa tay với bạn. Tôi đố bạn trở thành chuyên gia của mọi loại ngôn ngữ nhất là khi đối với bạn, ngôn ngữ lập trình hay công nghệ chỉ là cái tivi, bật nó trong 8 tiếng xem qua ngày rồi tắt nó đi. Một chuyên gia công nghệ không thể chỉ là người thành thạo API (các bạn có các certification cho ngôn ngữ nọ kia dừng xúc động) mà bạn còn cần đến sự hiểu biết ở mức low-level mới mong xây dựng được các hệ thống high traffic kiểu như CDBaby. Đây chính là một trong các lý do khiến dự án Rails thất bại.

- Liên tục theo dõi sự phát triển của công nghệ. Dereck hiển nhiên đã thấy bứt rứt vì thành công của Digg, Facebook, Friendster, Technorati, Flickr, Wikipedia... các ứng dụng PHP khổng lồ về phương diện traffic và sự ngao ngán của những người sáng lập Twitter về sự yếu kém của Rails trong vấn đề tương tự.

- Ngôn ngữ là cái gì đó cố định: Tôi là người thừa nhận "language matters" chứ không như một số em chã khác. Cho dù quảng cáo gì về tính general purpose của 1 language thì rút cục thông qua lao động, người ta luôn thấy một ngôn ngữ đều làm tốt một số vai trò của nó tốt hơn một số ngôn ngữ khác. Đây chính là tiền đề cho DSL của Martin. Nhận thức được điều này đồng nghĩa với việc bạn chọn được công cụ đúng. Tính mềm dẻo của một ngôn ngữ thể hiện ở chỗ nó có hòa hợp được với các chuẩn công nghiệp thường gặp hay không: hỗ trợ XML/JSON/SWX, design pattern, OOP, AOP, SOAP, SOA. Cú pháp của PHP có thể xấu xí nhưng khi đi vào lập trình hướng đối tượng nó không khác gì Java về cả phương diện tổ chức lẫn cú pháp vì Java đẻ ra mô hình hướng đối tượng cho PHP. PHP là đủ mềm dẻo để lập trình viên lựa chọn mô hình lập trình cho mình. Những ai nhìn thấy tính cố định của một mô hình lập trình (ví dụ nhiều người code Java thấy PHP toàn được mix vào HTML và coi đó là cách phát triển PHP duy nhất) chỉ cho thấy là họ có hạn chế nhất định về mặt tư duy công nghệ trên các ngôn ngữ mục đích chung. Trường hợp của Dereck cho thấy ông ta đã thu nhận được kiến thức từ chuẩn công nghiệp của ngành và nhanh chóng áp dụng nó một cách thành công sau 2 tháng với PHP. Nhưng để học được kiến thức đó, ông ta cần đến 2 năm trả giá.

- Tooling: đây là một vấn đề mà Dereck đã mắc phải và phải trả giá cho nó. Không có một tool nào là viên đạn bạc. Rails là một loại cool tool dành cho một lớp các vấn đề. Nó có thể giúp giải quyết 95% vấn đề thường gặp chỉ bằng 5% nỗ lực nhưng khi miền vấn đề của ứng dụng đã vượt ra khỏi 5% đó, chúng ta sẽ phải lấp kín 95% còn lại bằng sự đau đớn. Trường hợp ASP.NET cũng như vậy. Không có gì khiến chúng ta thất vọng hơn là sự phụ thuộc vào một IDE, một thứ kiến trúc trâu chẳng ra trâu ngựa chẳng ra ngựa và một cộng đồng toàn những morons. Hiệu suất của tooling luôn đi kèm với tính độ sâu của abstraction, độ giảm của flexibility và nhiều khi nó làm cho ứng dụng dựa trên tool như là một black hole. Điều này dễ hiểu tại sao lập trình viên Rails là morons và lập trình viên ASP.NET là những morons cấp "cao" hơn.

- Khi bạn lập một dự án hoàn chỉnh để kiếm tiền, bạn chọn một hệ thống, một cộng đồng chứ không phải là một framework, một ngôn ngữ. Dereck sai lầm vì chọn Rails thay vì chọn một hệ thống trong khi cái phục vụ người dùng là hệ thống chứ không phải là Rails. Dereck bị quyến rũ bởi API trong khi ông ta không tính toán kĩ API đó sẽ đem lại user experience như thế nào và chi phí của nó là bao nhiêu. Khi Rails phù hợp với một hệ thống không work theo nhu cầu của ông ta thì dự án thất bại. Dereck sai lầm vì chọn một cộng đồng quá nhỏ, mọi thứ đều rất mới và khi cộng sự của ông ta ra đi, di sản để lại là không thể gánh được. Quay trở lại cộng đồng PHP, ông ta sẽ đối mặt với một thách mức mới: dân cư PHP đông đến mức nếu ông ta để lộ mã nguồn thì tôi tin rằng ngay ngày mai sẽ có CDBaby đánh số từ 1 đến 1000 xuất hiện. Kinh nghiệm triển khai các hệ thống lớn với PHP đã được đăng tải trên web công cộng dày đặc đến mức có lẽ cần lập riêng một nhà xuất bản để in lại. Dereck rời bỏ một cộng đồng đã quá chín muồi và đang nâng cấp level để đến một cộng đồng còn quá trẻ nhưng không đóng bảo hiểm tai nạn. Thế có buồn không?

Dù sao xin chúc mừng đứa con xa quê trở lại.

(Theo pcdinh - phpvietnam/O'reilly)

Driver Xerox Phaser 3110 for Windows 7, Windows 8.1, Windows 10

Xerox Phaser 3110 for Windows 7 (32 bit), Windows 8.1 (32 bit), Windows 10 (32 bit)

Download: https://www.dropbox.com/s/sdt0vv6qyqri869/Phaser3110.zip?dl=0

Xerox Phaser 3110 for Windows 7 (64 bit), Windows 8.1 (64 bit), Windows 10 (64 bit)

Download: https://www.dropbox.com/s/gwcs22mqfgsubi9/XeroxPhaser3110-win64bit.zip?dl=0

64bit driver is ported from Samsung ML-1200 driver (a other brand of Xerox 3110) so before install it you must disable driver signature verification (https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=How+to+Disable+Driver+Signature+Verification+on+64-Bit)

Go to Device Manager, right click on Printer and choice Update Driver Software..., browser to folder contain driver (after unzip) to install it.

-------------------------
Xerox Phaser 3110 là dòng Printer khá là cỗ lỗ, thông dụng và bền cực kỳ :-s

Hướng dẫn In sách (booklet)

Thông thường để in 1 quyển sách, k phải dạng booklet bằng giấy A4 thì cứ mỗi tờ A4 chúng ta in dc 2 trang giấy (in 2 mặt). Nhưng với in booklet thì mỗi tờ A4 chúng ta in dc 4 trang (in 2 mặt) - khổ A5. Nhiều tờ như thế gấp lại bấm kim thì thành 1 quyển sách. Các chương trình sọan thảo văn bản, in ấn thông thường thì không hỗ trợ tính năng in booklet này. Đòi hỏi chúng ta phải tạo booklet từ 1 file PDF rồi dùng file này để in thành booklet.

Với một số chương trình xem PDF hoặc các chương k cao cấp sẽ có hỗ trợ in booklet nhưng k có những tùy chọn cao hơn như multiple booklet thì nếu PDF có quá nhiều trang sau khi in xong chúng ta k thể nào bấm kim để cố định như 1 quyển sách được. Có nhiều chương trình hỗ trợ tùy chọn Multiple Booklet. Như trên Windows có BookletCreator, trên Linux có PdfBooklet. PdfBooklet có thể chạy được trên cả Windows.

Qua quá trình dùng thử mình thấy PdfBooklet nhiều tùy chọn và dễ dùng, lại miễn phí.

Tạo sách đơn (Singble Booklet). Kiểu sách này chỉ áp dụng khi sách chúng ta không có quá nhiều trang. Nếu sách chúng ta phải in 100 trang 2 mặt thì sau khi in xong, chúng ta sẽ gập 100 trang ấy lại và bấm kim ở giữa. Nếu 100 trang thì không thể bấm kim được vì nó quá dày. Nếu chúng ta dùng kim bấm số 10 thông thường hay dùng thì chỉ 10 trang giấy gập lại là vừa để bấm.

Đối với sách có quá nhiều trang và chúng ta chỉ có kim bấm số 10 thì chúng ta phải tạo ra nhiều booklet, mỗi booklet dưới 10 trang giấy thì tùy chọn Multiple Booklet sẽ làm điều ấy. Mục Leafs in a booklet quy định số trang giấy cho mỗi booklet.

Sau khi bấm Go, tại thư mục PDF sẽ có thêm tập tin PDF mới. Bạn dùng tập tin này in ra. In 2 mặt giấy. Nếu máy in không hỗ trợ in 2 mặt (phải đảo giấy) thì chúng ta in trang lẽ (odd) trước rồi xoay giấy theo chiều dọc 180 độ và in trang chẳng (even).

Bài viết 1

Test 1