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)




Bình luận

  • TTCN (28)
dat

cong nghe zend framework

;D VIET BAI NAY XIN MOI NGUOI GIUP DO 8)
AI CO TAI LIEU HAY BAI TAP VE cong nghe zend framework XIN MAIL CHO MINH
;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D

dat

AI CO TAI LIEU HAY BAI TAP VE cong nghe zend framework XIN MAIL CHO MINH
[email protected]

Ruby On Rails

Trong bài viết trên blog của ông chủ cửa hàng CD online được trích dẫn ở trên, có ba nhận định cơ bản:
1 - Ruby is not a silver bullet.
2- There is nothing Ruby can do that PHP cannot do.
3 - Ruby cannot do anything better PHP.

Nhận định 1: "Ruby is not a silver bullet.", thì từ hồi mới có máy tính và ngôn ngữ lập trình - tức là từ những năm 40 của thế kỷ trước - cho đến nay ai mà chả biết. Có lẽ mỗi ông chủ cửa hàng CD là không biết, nên mới coi đấy là một phát kiến gì ghê gớm lắm của chính ông ta. Sự thực là bất kỳ lập trình viên nào (nếu xứng đáng được gọi là lập trình viên) cũng phải biết cách nhận định, đánh giá công cụ cho mỗi dự án. Nếu một lập trình viên chỉ biết một ngôn ngữ, ví dụ Java, và project nào cũng đem ra dùng, thì chẳng khác nào trong tay hắn có một cái búa, và hắn nghĩ rằng thế giới này toàn những cái đinh.

Về hai nhận định 2 và 3, they are very questionable.
Khi xem xét một nhận định, một đánh giá hay một so sánh, bao giờ chúng ta cũng phải xem xét nó trong một ngữ cảnh, phạm vi nhất định.

Vậy ngữ cảnh của nhận định của ông chủ cửa hàng CD online này là gì? Ông ta xây dựng một Website để mua bán CD online. Xét về tính phức tạp của application, đây không phải là một ứng dụng phức tạp, chỉ có các yêu cầu về quản lý người dùng, quản lý số lượng CD tồn kho, quản lý việc nhận đơn đặt hàng, thanh toán và gửi CD cho khách hàng. Tóm lại, các vấn đề ở đây chỉ xoay quanh việc phát triển một giao diện Web, cho phép nhập, thêm, xóa, sửa thông tin và hiển thị thông tin từ một số lượng rất hạn chế các table trong database.

Đối với những ứng dụng đơn giản, nghĩa là dùng một vài trang Web để baby-sit một vài table trong database, thì dùng PHP để phát triển sẽ nhanh hơn và đơn giản hơn là dùng Ruby hay Java. Trên web site của tôi, hệ thống Content Management System cũng là PHP, chứ không phải Ruby hay Java, mặc dù tôi làm enterprise software bằng Ruby và Java hơn 10 năm nay.

Tuy nhiên, khi phát triển những enterprise software đòi hỏi những chức năng như sau đây, thì PHP không hể đáp ứng được:

- High-volume transaction database processing, ví dụ như những ứng dụng trong production system của Boeing, Airbus, Rolls Royce, Daimler-Benz, BMW ..., và những ứng dụng tài chính, ngân hàng.

- Heavy and complex business processing: Trong enterprise software, phần xử lý dữ liệu và các quy luật kinh doanh trong sản xuất và tài chính ngân hàng là rất phức tạp, có sự tương tác giữa nhiều loại dữ liệu tổ chức theo nhiều cách khác nhau, đến từ nhiều nguồn.

- Inter-system collaboration: Trong những enterprise lớn, bao giờ cũng có nhiều chi nhánh, nhiều bộ phận, nhiều văn phòng ở những thành phố khác nhau, các nước khác nhau và các châu lục khác nhau. Thậm chí, các văn phòng còn có thể dùng các loại ứng dụng khác nhau trên nhiều hệ điều hành khác nhau, và từ nhiều kỷ nguyên máy tính khác nhau, từ thời mới có máy tính to bằng cái nhà cho đến các mini computer, multi-processor server và PC computer. Việc thống nhất một enterprise-information bus đòi hỏi khả năng tương tác cao của công cụ, hỗ trợ tốt multi-system integration và SOA.

- Internet high-volume consumer-based application, ví dụ như các ứng dụng có hàng tỷ người truy cập một ngày như e-Bay, Amazon, Akamai, Yahoo, Google ..., nhất là các ứng dụng cho phép chia sẻ, tag, search các multimedia data như video, ảnh, audio ..., thì PHP không thể làm được.

- Web Services, SOA design, RESTful development ...

Còn khá nhiều lĩnh vựa khác, ví dụ như Rich-User-Interface app, Communication protocol imlementation, Multi-threading processing ... thì ....

Còn các bạn muốn biết tại sao không thể làm được, thì làm ơn tự học hỏi, tự thử nghiệm và tìm tòi. Rất có thể là 10 năm sau các bạn mới tìm ra, nhưng như thế là còn may cho các bạn, vì có những người cả đời vẫn không tìm ra.

Ruby On Rails

Về chuyện "Ruby cannot do anything better than PHP", thì ông chủ cửa hàng CD này rõ ràng là ếch ngồi đáy giếng. Ngoại trừ những thứ Ruby làm được và PHP không làm được kể trên, thì tính ngay trong phạm vi Web-based application, Ruby có những ưu thế rõ ràng so với PHP.

- Ruby supports MVC 2, trong đó nó phân chia riêng biệt Model, View, Controller thành những component rõ ràng, khác biệt và dễ cài đặt. PHP supports only MVC 1, trong đấy PHP page vừa là model, vừa là view, vừa là controller. Nếu các bạn muốn học về sự khác biệt về MVC 1 và MVC 2 thì làm ơn đi học. Tong quá trình làm việc của tôi tại một công ty làm enterprise software tại Mỹ, tôi có đề ra thêm một mô hình nữa là mix- MVC.

- Ruby supports AJAX development: Trong Ruby, bạn có thể viết Ruby code theo phong cách OOP, kèm với RJS để tạo ra Web-based application với AJAX functionalities. Trong PHP, bạn phải dùng lẫn PHP code, HTML code, java script.

- Ruby support reuse of HTML partial views: Support này của Ruby thì cả PHP, J2EE và .NET đều không có, mặc dù cái gọi là include của PHP, J2EE và .NET cũng cho phép include một vài trình bày của HTML vào trong một file. Nhưngcác partial của Ruby cho phép cùng một partial nhưng có các data và cách hiển thị khác nhau, tùy theo cách partial đó được render như thế nào.

- Ngoài ra còn rất nhiều thứ khác như Unit Test, Code Block, Duck Typing ..., làm cho chương trình Ruby dễ bảo trì, mở rộng, và được viết một cách ngắn gọn, súc tích hơn bất kỳ một ngôn ngữ (phổ biến) nào như PHP, Java, .NET... Hiện tại chỉ có hai ngôn ngữ có thể so sánh được với Ruby về cái đẹp của cú pháp là Smalltalk và Python.

Quay trở lại vấn đề của ông chủ cửa hàng CD online. Thứ nhất, nghề của ông ta là bán CD, chứ không phải làm software.
Thứ hai, căn cứ vào những gì ông ta viết, vì dụ như 85 người viết một cái application với hàng trăm nghìn dòng PHP code rải rác lung tung, thì rõ ràng vấn đề của ông ta là system design chứ không phải là coding và programming language. Nếu như ông ta có một system design kém, thì dù có viết bằng PHP, Ruby, Java, .NET hay Python hay viết bằng ngôn ngữ giời đi nữa, thì ông ta vẫn thất bại như thường.

Và việc ông ta thất bại trong việc dịch cái chương trình của ông ta từ PHP sang Ruby và Rails là minh chứng rõ ràng nhất cho cái gọi là Bad System Design. Ông ta cho rằng ông ta thuê được một lập trình viên giỏi Ruby để làm việc đó. Ông ta là chủ một cửa hàng CD, nên khó mà biết được thế nào là giỏi đối với ông ta. Hơn nữa, một lập trình viên giỏi không có nghĩa là một software architect giỏi. Anh ta có thể hoàn toàn viết code rất tốt ở mức object, nhưng khi ghép các component của một application lại, thì vẫn có thể tạo ra một ứng dụng vứt đi.

Việc ông ta trở lại dùng PHP, thiết kế lại chương trình, chia lại chương trình thành các module tử tế, vận dụng các nguyên tắc như DRY, YAGNI ... và thành công, cũng là một minh chứng là ông ta đã có một system design kém trước đó, chứ không phải vấn đề là PHP hay Ruby.

Ruby On Rails

Critical thinking
Thế kỷ 21 này là thời buổi mà ai cũng vào được Internet và ai cũng mở được blog. Vì thế, khi các bạn đọc một nhận định, đánh giá, phân tích thì phải dựa trên một vài tiêu chí khách quan, và phải có khả năng tư duy logic. Ở Tây, ngay từ thế kỷ 15 người ta đã có một bộ môn gọi là critical thingking.

Còn ở Việt nam thì rất tiếc là các bạn từ 4000 năm nay đã được dạy từ tuổi đi vườn trẻ là tất cả những gì người lớn nói đều đúng, tất cả những gì cô giáo dạy đều đúng, tất cả những gì trong sách viết đều đúng, và nguy hiểm nhất là các bạn mở rộng nó ra thành tất cả những gì có trong Internet đều đúng. Nếu tất cả đều đúng hết rồi, thì còn ai đi làm nghiên cứu làm gì, làm gì có gì mới để mà phát triển nữa? Vì thế, nếu các bạn nghĩ tất cả các giá trị đã được xác định là đúng trong mọi trường hợp, mọi phạm vi mọi thời đại, cái gì hôm qua đúng thì hôm nay vẫn đúng, thì cho đến giờ, loài người chắc vẫn có đuôi, sống ở trong rừng, ở trên cây và ăn hoa quả.

Khi nghiên cứu một nhận định, bao giờ cũng phải có phân tích, đánh giá:

- Phạm vi, ngữ cảnh, hoàn cảnh mà tác giả đưa ra nhận định.

- Độ tin cậy của tác giả. Ví dụ như một ông chủ cửa hàng CD nói về software development thì độ tin cậy khó có thể cao như một software architect. Ở đây, tôi rất thận trọng, và dùng chữ "khó có thể", chứ không dùng chữ "không", vì tôi sợ rằng những con vẹt 4000 năm sẽ hiểu nhầm chữ Ví dụ, và nghĩ rằng một người có vị trí đã xác định thì luôn nói đúng hơn người không có vị trí. It is not always the case. Ví dụ như những "nhà khoa học" đã đề nghị thiêu sống Giordano Bruno. Hoặc những giáo sư tiến sĩ vật lý của châu Âu và châu Mỹ lên tiếng chửi bới một anh nhân viên thư ký quèn không bằng cấp ở một Văn phòng quản lý bằng sáng chế phát minh ở Thụy sĩ - vâng, Albert Einstein. Hoặc những người theo thuyết tương đối của Einstein chửi bới thuyết bất định của Werner Heissenberg... Tuy nhiên normally thì một ông software architect thường là nói về software development dễ tin hơn một ông chủ cửa hàng CD.

- Khi không biết thì phải thử: Như trên đã nói, nhiều khi rất khó xác định được phạm vi, ngữ cảnh hay độ tin cậy của người phát biểu nhận định, nên khi bạn không biết thì phải thử. Ngày nay, vào Internet, nếu bạn chịu khó tìm tòi thì sẽ thấy nhiều Web site với nhiều giáo sư tiến sĩ đánh giá A tốt hơn B, đồng thời cũng nhiều Web site với nhiều giáo sư tiến sĩ khác đánh giá B tốt hơn A. Và các Web site này đều sử dụng logic hình thức tốt như nhau, they are written by doctor professors, after all. Vì thế nên nếu bạn không chắc chắn, thì chỉ có mỗi cách là phải thử. Vì thế nên mới có các quy trình gọi là pilot implementation và proof-of-concept implementation khi làm software project.

- Những gì đúng trong đa số trường hợp, không có nghĩa là nó đúng trong một trường hợp cụ thể. Đa số Tất cả, các con vẹt 4000 năm thân mến của tôi ạ.

- Những gì hôm qua đúng, hôm nay chưa chắc đã đúng. Vì thế, trừ khi các bạn nhất quyết làm thợ lập trình, ai dạy gì nghe nấy, thợ cả bảo xếp gạch thì xếp gạch, bảo trộn hồ thì trộn hồ, còn không thì phải luôn luôn để ý, tìm tòi, học hỏi, thử nghiệm, khám phá.

Ví dụ trực quan sinh động cho các con vẹt là cần thiết, nên tôi đưa ra một ví dụ. Nếu như các bạn đọc các Web site về lập trình Java, kể cả các Website của Sun, đều sẽ thấy nói là đối với String, nếu dùng s1 s2 s3 s4 thì chậm hơn là dùng StringBuffer để append. Điều này đúng với Java từ 1.4 trở về trước. Đối với Java 6, các bạn thử xem cái nào nhanh hơn. viết thử một chương trình Java nhỏ để cộng chuỗi bằng " " và "StringBuffer" , đo là biết ngay. Vì sao? Trên Internet có, Google có, MIT có giáo trình miễn phí. Các bạn vào được forum, thì cũng vào được Internet.

Nếu các bạn không có khả năng tư duy logic, không biết thế nào là critical thinking, thì tốt nhất là không nên làm nghề lập trình, mà nên làm diễn viên hài, và vở hài kịch tốt nhất có thể đóng được là "Đẽo cày trên Internet".

(Không biết các bạn trẻ ngày nay có biết truyện ngụ ngôn "Đẽo cày giữa đường" hay không nữa? Xem ra thế hệ @ ngày nay còn thua xa các cụ nông dân kể truyện ngụ ngôn, hút thuốc lào, uống chè xanh và đi cày bằng trâu ngày xưa).

Nemo Nguyen  21665

Tuy không cùng lĩnh vực (ko hiêu hết những gì phân tích) nhưng cũng cám ơn vì những phân tích của bạn (dù đúng 1 phần hay hoàn toàn), nhất là lời khuyên về cách phân tích và đánh giá 1 vấn đề.

Phần cuối bạn (hay bác) hơi mang tính chỉ trích 1 chút. Vẹt hay ko là do bản thân mỗi người mà thôi, ko dám đổ thừa là do nền giáo dục VN dạy mình thành vẹt (vì nhiều người ở nước ngoài cũng là vẹt).

Lich

Mình thấy bạn Ruby On Rails nói rất hay nhưng mình không hiểu lắm ;D . Mình lại rất thích PHP. Dạo này bị tạm dừng, toàn nhờ PHP kiếm chút tiền còm để sống nên thực sự mình rất thích PHP.

Đọc kỹ thì thấy chỗ bạn nói AJAX với cái RJS gì đấy mình thấy hơi có vấn đề. Theo mình hiểu thì về căn bản AJAX là dựa trên HTML - DOM với Javascript . Vậy RJS là cái gì mà thay thế được HTML với javascript. Theo cách bạn nói thì ngôn ngữ Ruby chắc là có một thư viện dựng sẵn bao gồm cả javascript bên trong, sau đó cứ thế dùng. Nếu đúng thế thì PHP có tỷ tỷ cái code sẵn có như thế.

Lich

Ruby support reuse of HTML partial views. Cái này có phải nói về xây dựng giao diện không. Mình thấy PHP có Smarty từ lâu rồi. Nhưng đợt này làm mấy thứ về Joomla nên thấy Smarty cũng không hay lắm vì dường như quá thừa.

Bạn thấy đấy, PHP có rất nhiều cách làm hay ho cho vấn đề giao diện. Còn ngôn ngữ bạn nói hình như vẫn chỉ có mỗi một cái thư viện code dựng sẵn đấy thôi. Chia buồn Big Grin

Lich

Mình có tật đọc ngược. Bây giờ mới thấy bạn nói về MVC1, MVC2, MVC mix ... Theo mình hiểu thì đây là một cách lập trình, mà cách lập trình thì mỗi người một kiểu, miễn sao đáp ứng được yêu cầu đặt ra, mà cụ thể ở đây là tách ba phần đối tượng hóa, giao diện hiển thị và điều khiển ra. Và theo mình thấy PHP còn hỗ trợ đến cả MVC 1000000000000000 kia, chứ đâu chỉ có MVC 2.

Theo cách bạn nói thì dường như toàn bộ ngôn ngữ Ruby nằm trọn trong cái code xây dựng sẵn kia, và bạn đang đem cách nhìn đó áp cho các ngôn ngữ khác.

Một lần nữa chia buồn với bạn :D, bạn có hơi ít thứ để tìm hiểu .

Lich

High-volume transaction database processing, Heavy and complex business processing, Inter-system collaboration, Internet high-volume consumer-based application .... những cái này thì mình không biết vì tầm của mình mới dừng lại ở mức thỉnh thoảng nhận một cái yêu cầu nhỏ về làm để kiếm ít tiền. Nhưng theo cá nhân mình thì PHP làm được hết mọi việc. Mình sẽ chứng minh phản biện bằng kiến thức về một số mã nguồn mở mà mình đã làm.

Bạn không thể bảo là PHP không được các tổ chức lớn dùng. Ví dụ Nasa hình như đang dùng PHP, sau khi làm một nghiên cứu về các loại công nghệ khác nhau. Mà chắc chắn Nasa bay cao hơn và chạy nhanh hơn Boeing, Airbus, Rolls Royce, Daimler-Benz, BMW...

Mình rất hay được nhờ làm những hệ thống CRM, và mình thấy trong lĩnh vực này thì PHP chiếm ưu thế tuyệt đối với SugarCRM, Vtiger .... (vài chục cái crm khác nhau) còn Ruby hình như không có cái nào. Vậy không thể nói PHP không thể phục vụ cho sản xuất kinh doanh với các quy trình quản lý phức tạp được. Trong lĩnh vực ERP thì Java hơn cũng chẳng qua là có một số nền tảng có sẵn như ofbiz ... Còn Ruby thì chưa thấy đâu.

Còn về các hệ thống phân tán và nhiều người truy cập thì thôi. PHP là bậc thầy rồi.

Nói chung mình thấy Ruby của bạn cũng được, ngoại trừ những phần mà PHP vượt trội thì Ruby cũng ngang phân với PHP ;D

Lich

Cuối cùng, mình thừa nhận là mình nói ở đây có thể hơi buồn cười vì kiến thức của mình không tốt lắm. Nhưng với kiến thức nông cạn của mình , mình cũng có thể nói Ruby On Rails là một cái thùng rỗng kêu rất to. Mình nghi ngờ 10 năm kinh nghiệm của Ruby On Rails. Mình thấy cậu có tư duy điển hình của các lập trình viên Java, và như thế khi cậu chuyển qua Ruby thì thật sự là mình thấy rất phí cho Ruby.

Huy Điên

^^

@Ruby on Rails:
Bạn thật giỏi khi comment liên tục 3 cái dài thế kia ^^. Có điều tôi không đồng tình với tất cả các quan điểm mà bạn đưa ra. Tôi sẽ không cố phản bác lại hết. Chỉ nên vắn tắc một vài điểm thôi !

Đầu tiên, bạn chẳng hiểu gì về PHP cả ! PHP là một ngôn ngữ không phải là một framework như Rails hay .NET. Việc tôi viết nó như thế nào là việc của tôi đúng không? Tôi có thể implement "MVC loại 1000" cũng chẳng sao, không ai bắt tôi phải dùng "loại 2" cả ! ĐÓ LÀ VẤN ĐỀ CỦA BẢN THÂN TÔI, DEVELOPER.

Về mặt ngôn ngữ, ừ, Ruby đẹp đấy. Có điều tôi không thể nào chịu nổi kiểu cú pháp của Ruby, Python hay Lua .. Tôi chỉ thích sự rõ ràng rành mạch của cú pháp họ C, kiểu C/C , PHP, C#, Java ... Vâng, chúng ta là lập trình viên đúng ko ? Ko phải bà nội trợ !

Tôi thấy bạn, cũng như phần lớn những người comment khác ở bài viết của Dereck trên Oreilly đều mắc phải một sai lầm nghiêm trọng đó là đánh giá quá cao tầm quan trọng của nền tảng và ngôn ngữ lập trình.
Những khái niệm mà bạn nêu ra như SOA, REST, Ajax, MVC ... hoàn toàn tách biệt với nền tảng ngôn ngữ ! Tách biệt khỏi PHP, Ruby, Rails hay Java ... Bạn sẽ thực hiện được chúng nếu bạn thật sự hiểu chúng ! Nếu muốn, tôi có thể bỏ thời gian viết một SOAP service với C ròng ! Bạn tin không ?

Cuối cùng tôi tự hỏi, bạn đã dùng "Ruby on Rails" để xây dựng ứng dụng lớn đến mức nào ?
Oh, tôi dùng một clone của Ruby on Rails là Cake để code cái weblog của mình thôi mà đã thấy khổ ko biết đường nào mà lần rồi !
Có một điểm mà tôi rất tâm đắc với Dereck: "Don't try to hide SQL from me !" ! Big Grin

Huy Điên

^^ 2

@Ruby on Rails :
oh, tôi mới đọc kỹ hơn 3 cái comment của bạn !
Tôi xin góp một câu cuối cùng: Chính bạn và mới là con vẹt thì có ! ^^

Thực tế chứng minh phần lớn các tín đồ của Ruby on Rails mới là những con vẹt thực thụ ! Chẳng biết gì ngoài cái phạm vi của Rails !
Khi đọc những bài viết của các tín đồ Rails trên mạng, tôi có nhận định như sau:

- Họ luôn bô bô cụm từ "MVC" nhưng chẳng hiểu gì về MVC ! MVC đối với họ chỉ là 3 component ! Thực sự, MVC quan trọng nhất chính là tư duy của bạn, là cách mà bạn "tưởng tượng" về 3 thành phần chính của ứng dụng, chứ không phải là 3 class, 3 component, hay 3 thư mục chứa code ... Tôi có thể viết function-based, nhưng tôi vẫn MVC được, thậm chí là MVC hơn cả Ruby on Rails ! Tin không ?

- Họ nghĩ rằng cách duy nhất để làm việc với Database là Active Record ! Oày, hãy thử làm một ứng dụng reporting bằng Active Record xem nào ! Thử dùng Active Record để query với GROUP BY xem nào ! Tôi ấy, tôi thích tự viết SQL, thích dùng Stored Procedures, thì sao nào ?

- Họ cho rằng nếu một web developer không dùng Ruby on Rails thì anh ta sucks ! Thực tế, nhiều người không dùng Ruby on Rails là vì họ không thể nào chịu nổi nó !

- Họ nghĩ rằng Ruby là ngôn ngữ đẹp nhất, huy hoàng nhất. Nhưng xin lỗi, những lập trình viên thực thụ không quan tâm đến chuyện đó !

...

Nói chung, theo tôi, bạn nên tự xem lại kiến thức của mình, để tránh lên mặt người khác như một con vẹt như thế !

Nemo Nguyen  21665

Không thấy bạn Ruby on Rail "phản pháo" lại phát nào, bạn không thích tranh luận cho mọi chuyện "rõ ràng" hay bạn "đuối lý".

Cộng đồng PHP đang mong chờ những luận điểm của bạn.

Fri3ng3R

Mấy bác này ai cũng có cái lý cả? Cãi nhau bao h mới xong! ;D

Hải Nam  30904

Twitter bỏ Ruby on Rails vì vấn đề scalability http://bit.ly/bzhKlV

comment

Mấy bài phản pháo lại comments của RoR thể hiện kiến thức kém, chỉ nói thế này thế kia mà không có luận chứng gì cả.

Chỉ cần một vấn đề "Ruby is not a silver bullet" các bạn hiểu thế nào thì thể hiện khả năng của mình đi.

Lam Ho

Bài viết hay đấy.

tunn

Tranh luận không nhất thiết phải đi đến ai đúng ai sai nhưng tranh luận là cần thiết.

mushed

Bài dịch lúc dùng tiếng Việt lúc dùng tiếng Anh loạn cào cào, thêm một số lỗi chính tả và lỗi đánh máy. Bài này giống như dịch đại để có bài đăng lên, đọc thấy gượng gượng thế nào ấy.

Linklink

"Oh, tôi dùng một clone của Ruby on Rails là Cake để code cái weblog của mình thôi mà đã thấy khổ ko biết đường nào mà lần rồi !"

hi hi, dùng dao mổ trâu để giết gà rồi dùng dao lam để đẽo cây ah, ROR tốt hay không, PHP tốt như thế nào, .net thành công ra sao thì để cộng đồng mạng đánh giá. Các ngôn ngữ lập trình, trang web, phần mềm diệt virus đều có một tổ chức đánh giá theo thang điểm, theo từng năm, có thể năm nay cái này tốt nhưng sang năm cái kia lại tốt, lúc này dùng PHP, lúc khác dùng ROR, lúc lại dùng .net, tùy điều kiện thôi, tui thấy bạn Ruby On Rails đâu có nói ngôn ngữ nào là hơn ngôn ngữ nào đâu, chủ yêu luận điểm của bạn ấy đưa ra là để phản biện lại ý kiến chê ROR của tác giả thôi mà

sangloamat

Tớ thích dùng .NET

Các bạn có tin không!!!. Hihi

Khách

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.

Ặc.em đang làm bên .Net,nghe mà buồn quá.

Panh

Lập trình viên hiện đại thì không quan trọng ngôn ngữ mà cái chính là tư duy lập trình.

Nếu bạn đang là PHP developer, 1 câu hỏi đặt ra là: Bạn có thể design 1 framework với MVC + DDD pattern (Domain Driven Design) hay không ? Câu trả lời là tư duy của bạn chứ không phải của PHP language.

Ngôn ngữ vẫn chỉ là ngôn ngữ, cái cách thể hiện ngôn ngữ mới là điều quan trọng.

Issol

HN có phần nhìn nhận vài vấn đề hơi thiển cậ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."

Tôi không hoàn toàn đồng tình với những lời nhận xét thiển cận thế này. Hải Nam chỉ nhìn vào một vài LTV có nền tảng yếu kém về các kiến thức nền về lập trình, chỉ sử dụng cái IDE một cách máy móc mà đánh đồng rồi hạ thấp tất cả những người còn lại. Tôi cũng thừa nhận rằng chính sự hỗ trợ quá mạnh mẽ của .NET framework mà điển hình là có rất nhiều lớp giao tiếp viết sẵn (do LTV MS viết) cùng với công cụ IDE đã tạo nên rất nhiều lập trình viên mà bạn gọi là morons. Bởi vì sao? Vì họ ko có kiến thức nền vững chắc về lập trình, chỉ học tập được các sử dụng thành thạo những thứ viết sẵn này là đáng mừng rồi, còn khả năng custom hầu như là không có. Nếu Hải Nam hay một ai khác đã giỏi về một nền tảng nào đó (PHP hay Java chẳng hạn) mà chuyển qua .NET thì tôi không nghĩ sẽ trở thành một morons!? Khi một kẻ được sinh và lớn lên trong sự chu cấp quá đầy đủ thì chúng đâu cần phải làm việc để sống (đa số thế)? Chúng chỉ biết hưởng thụ thôi đúng ko? Cần cái gì đẹp cũng có hết, mua là xong. Nhưng những cái đẹp đó ở đâu có? Do những người giỏi tạo ra đấy bạn. Đây mới là những LTV, kiến trúc sư phần mềm thật sự! Những nền tảng khác chẳng phải cũng có rất nhiều framework ra đời để đơn giản hóa quá trình phát triển ứng dụng đấy sao? Rất nhiều nữa đằng khác. Framework càng hỗ trợ nhiều, công cụ IDE càng mạnh thì lại sẽ tạo ra càng nhiều morons đấy thôi! Một hiệu ứng tất yếu của cuộc sống.

Tôi hoàn toàn đồng ý với ý kiến của bạn Panh

Issol

Sorry! Tôi sơ ý đây là bài HN dịch lại!

Rất tiếc vì khi click "Lưu" xong, tôi mới phát hiện ra đây chỉ là bài dịch lại. Sorry HN vì điều này.

newperson

Pó tay bài post này

Nói thiệt tôi cũng là LTV. Chẳng có ngôn ngữ nào hay hơn ngon ngữ nào hết.  Cái nào cũng hay hết và tuỳ bạn dùng cho trường hợp nào. Còn ASP.net phát sinh code thì có j ko tốt chứ. Giảm bớt code cho LTV.

ASP.net chỉ dc phát triển bởi Microsoft nên nó thống nhất. Không phiền toái khi thấy lỗi. Nhưng nếu có khuyết điểm thì phải đành chịu chờ phiên bản sau.

PHP , Java thì có nhìu framework  nên dân mới vào thì rối. Còn dân di làm việc thì chỉ làm quen 1 cái thôi. Gặp cái khác thì tìm hiểu lại ->đuối. Nhưng nếu có khuyết điểm thì có thể tìm cái khác thay thế .....

Trần Viễn  1

Tư duy hay bảo thủ

Cảm ơn tất cả mọi người, xin cảm ơn
Dù bài này đăng năm 2007 nhưng bây giờ tôi mới đọc, và tôi cũng không bỏ 1 chữ nào dù topic này khá dài
cuối cùng tôi có hai ý, một ý cá nhân và một ý tâm đắc

1. Đừng quá thần tượng một ngôn ngữ nào, mỗi ngôn ngữ có một thế mạnh và giải quyết TỐT một hoăc vài trường hợp cụ thể.
2. Ngôn ngữ là một như một phuơng tiện để giải quyết một bài toán,

do đó hãy nhớ "Nếu một lập trình viên chỉ biết một ngôn ngữ, ví dụ Java, và project nào cũng đem ra dùng, thì chẳng khác nào trong tay hắn có một cái búa, và hắn nghĩ rằng thế giới này toàn những cái đinh".