• Mã nguồn mở được đóng góp bởi nhiều người, kết quả của sản phẩm được làm bởi nhiều người sẽ tốt hơn rất nhiều so với việc bạn phát triển một mình.
• Dễ dàng cập nhật tính năng mới dựa trên sự đóng góp mã nguồn của các nhà phát triển khác nhau.
• Giảm thời gian phát triển, giảm giá thành sản phẩm…
• và nhiều lợi ích khác nữa…

Tớ đã làm việc với PHP trong khoảng 4 năm trở lại đây, bản thân là một Freelance Developer nên không tự cho rằng mình là Master PHP bởi tớ luôn sử dụng PHP như một thành phần phát triển theo ý thích chứ không tâm niệm mình phải làm chủ được ngôn ngữ đó
Những dự án dưới đây là những thành phần phổ biến của một Website, tính thông dụng của nó như là một bắt buộc phải biết đối với Web Developer.

• Gửi eMail: Đây là tính năng phổ biến nhất của mọi Website, hàm mail(); là đủ cho hầu hết các yêu cầu khác nhau của người dùng, ngoài ra PHP còn hỗ trợ một số hàm khác nếu bạn muốn đính kèm tập tin hay gửi mail của SMTP server để có thể dễ dàng tạo một chương trình gửi eMail.
• Hỗ trợ người dùng: cho phép cá nhân hóa nội dung Website, có thể đa sở hữu, phân cấp quyền quản lý thông tin của cá nhân cũng như các nội dung khác. Tính năng chính của thành phần này hỗ trợ việc đăng nhập, truy vấn sửa đổi cơ sở dữ liệu, phiên làm việc…
• Tạo RSS, tin rút gọn Feeds: Thời điểm hiện tại Website của bạn sẽ được đánh giá là tụt hậu nếu không hỗ trợ Feed trong việc cung cấp thông tin, lấy tin bằng Feed cho phép người dùng đơn giản hóa việc theo dõi nội dung của một Website nào đó. Tớ sử dụng Magpie RSS trong phần lớn các dự án của mình.
• Xác định vị trí: xác định vị trí địa lý của người dùng đơn giản nhằm thống kê lượng người truy cập nội dung từ nước nào để có thể phục vụ tốt hơn, tính năng này không thật sự quan trọng nhưng đôi khi lại khá hiệu quả nếu bạn muốn biết người của nước nào hay vào Website mình nhất
• Lấy thông tin từ xa: truy vấn thông tin từ nhiều nguồn khác nhau, thích hợp với một cổng thông tin tổng hợp, các nội dung này được lưu vào cơ sở dữ liệu.
• Lưu tạm dữ liệu {Cache data}: giảm truy vấn tới cơ sở dữ liệu, tránh quá tải hệ thống do phần lớn các dự án cá nhân không được tối ưu về mã nguồn cũng như hiệu xuất làm việc, lưu tạm dữ liệu là một giải pháp đơn giản đề tối ưu hệ thống Website có thể hoạt động ổn định.
• Hệ thống giao diện: Dễ dàng thay đổi giao diện Website, đơn giản hóa quá trình thiết kế, giảm công sức tạo lập Website mới. Một hệ thống giao diện tốt không có nghĩa là phải đầy đủ tính năng mà chỉ cần đáp ứng được đúng nhu cầu sử dụng, tốt nhất là bạn nên tự viết sẽ hoàn hảo hơn sử dụng của người khác, theo tớ thì Hệ thống giao diện gần như là nhân {core} của một hệ thống quản lý nội dung. Tiêu biểu như Smarty của PHP
• BBcode: Tính năng thường thấy của các diễn đàn, nó đơn giản hóa việc trình bày nội dung giúp người sử dụng thông thường có thể tạo một văn bản chuyên nghiệp mà không cần biết về mã HTML, khách hàng của bạn sẽ dễ dàng sử dụng nó như một ứng dụng văn phòng mà thôi. Hãy thử StringParser_BBcode vì nó rất dễ tùy biến theo ý muốn của bạn.
• Hệ thống truy vấn cơ sở dữ liệu: Cơ sở dữ liệu là phương án tối ưu nhất để lưu trữ dữ liệu của bạn, dữ liệu của bạn có thể lưu trong một hệ CSDL lớn như Mysql hay đơn giản như là một Text file thì hệ thống truy vấn cơ sở dữ liệu sẽ hỗ trợ việc truy vấn dữ liệu, đơn giản và giản lược mã nguồn đi rất nhiều, giảm bớt công sức viết mã nguồn. Cũng như hệ thống giao diện nó là một trong những thành phần quan trọng nhất của tớ khi viết một dự án Web. Hãy thử ezSQL để giảm bớt khai báo truy vấn cho từng query của bạn.
• Môi trường nhập liệu văn bản: Về cơ bản nó là một dạng xử lý nội dung form được hỗ trợ bở Javascript và kết hợp BBCode nhằm phục vụ người dùng một cách tốt nhất có thể, mục đích của nó là cố gắng mô phỏng môi trường làm việc như các ứng dụng văn phòng. FCKEditor là một ví dụ đơn giản nhất

Mỗi người một quan điểm khác nhau nhưng ít nhiều ai cũng từng phải làm việc qua một trong những dự án trên, 10 thành phần đó không phải là toàn bộ mà chỉ là thông dụng thôi.

Related posts:

1. 10 câu thường nói của lập trình viên!
2. Sinh viên Việt trong mắt người Nga !

Ô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.

Related posts:

1. Sự thật và huyền thoại về trứng

function selfURL() {
	$s = empty($_SERVER["HTTPS"]) ? '' : ($_SERVER["HTTPS"] == "on") ? "s" : "";
	$protocol = strleft(strtolower($_SERVER["SERVER_PROTOCOL"]), "/").$s;
	$port = ($_SERVER["SERVER_PORT"] == "80″) ? "" : (":".$_SERVER["SERVER_PORT"]);
	return $protocol."://".$_SERVER['SERVER_NAME'].$port.$_SERVER['REQUEST_URI'];
	}
function strleft($s1, $s2) {
	return substr($s1, 0, strpos($s1, $s2));
	}

You can now get the full URL using the line:

print(selfURL());

Removing empty elements in a PHP array
This works like the @Trim formula in Notes/Domino

/**
* Trims an array from empty elements. *
* @param $a the array to trim.
* @return a new array with the empty elements removed. */
function array_trim($a) {
	$j = 0;
	for ($i = 0;
	$i <
	count($a);
	$i++) { if
	($a[$i] != "") { $b[$j++] = $a[$i];
	} } return $b;
}

Use it like this:

$a[0]="";
$a[1]="An entry";
$a[2]="Another one";
$a[3]="";
$b=array_trim($a);

The resulting $b array will have two entries, with the two empty ones removed.

How to figure out your server’s real name
It is sometimes necessary to figure out the real server name. There are several ways to do this, but in PHP, a simple way is this:

$IP = gethostbyname ($SERVER_NAME);
$server = gethostbyaddr($IP);
echo "<br />Server IP: $IP";
echo "<br />Server Name: $server";

If you do not want to see the IP address of your website, you can use this single line of code:

echo "Server Name: " . gethostbyaddr (gethostbyname ($SERVER_NAME));

Related posts:

1. Making AdSense work with XHTML
2. Tắt tính năng quản lý phiên bản của bài viết trên WordPress
3. Thiết kế các phản hồi bài viết tương thích với WordPress 2.7.x

Việc chuyển từ PHP4 sang PHP5 không hề đơn giản. Những sai lầm trong PHP4 đã khiến cho con đường đi đến thành trì của PHP5 chứa đầy sỏi đá và chẳng bằng phẳng.

Thứ nhất, có quá nhiều ứng dụng PHP viết theo kiểu cấu trúc khiến cho tính OO trong PHP5 không hề hấp dẫn. Viết lại chúng ư? Một công việc khổng lồ. Ai sẽ trả tiền?
Thứ hai, có nhiều ứng dụng xen lẫn cả thủ tục và đối tượng, nhưng là một thứ đối tượng dở người của PHP4. Việc chuyển sang chạy trên PHP5 sẽ tạo ra các điểm break mà phát hiện ra chúng không hề dễ dàng.
Thứ ba, dân lập trình PHP đa phần là dân tài tử. PHP đã tạo nên một hàng rào rất thấp khiến cho ai cũng có thể trở thành một lập trình viên. Không có coding convention thống nhất, API thì phi chuẩn, code mã thì thủ tục, không có tiền lệ sử dụng các design pattern, không có sự khuyến khích dùng lại mã, không khuyến khích các best practice trong lập trình, không khuyến khích test driven… Trở nên chuyên nghiệp hơn với OOP ư? Ai sẽ trả tiền?
Thứ tư, đa số các ứng dụng PHP là viết vì lý do cá nhân hoặc là mã nguồn mở viết vì vui thích hay một nhu cầu trước mắt. Điều này khác với Java, một công nghệ hướng vào thị trường doanh nghiệp, nơi mà người ta khuyến khích dùng lại mã vì… ông chủ không vui khi trả tiền 2 lần để có cùng một đoạn mã và này, các lập trình viên trẻ, hãy viết ra sao để khi các cậu đếch làm cho tôi nữa thì sẽ có người khác gánh vác công việc của cậu vì khách hàng đó còn làm việc với chúng ta dài đấy.
Thứ năm, hướng đối tượng ư? Doanh nghiệp ư? Tại sao không phải là Java mà lại là PHP5? Tôi tưởng PHP chỉ dùng để code forum, mấy trang tin nhỏ nho hay đại loại cái gì đó be bé thôi chứ? Cộng đồng PHP ư? Ôi cộng đồng là một lũ nhăng nhố, nay ở mai đi, ai dám khẳng định họ sẽ cam kết cho sự phát triển kinh doanh của tôi? Mã nguồn mở? Chúa ơi, tôi là một bậc thầy về kinh doanh mà Thượng Đế của tôi lại là lợi nhuận. Xin lỗi nhé ông ta không biết đọc mã nguồn. Hãy chỉ cho tôi ai là người có khả năng đọc nó. Chúng tôi cần tiết kiệm tiền nhưng chúng tôi cũng cần nhanh chóng và rủi ro thấp nữa. Mã nguồn mở không có nghĩa là phi rủi ro.
Thứ năm, chúa ơi, Andi và Gutman có biết đến câu Tồi hơn là tốt hơn không vậy? Xin đứng bắt tôi học thêm. Tại sao tôi phải học nấu cơm trong khi tôi đã có sẵn mì ăn liền. Lập trình PHP4 dễ như đi câu cá. Xin đừng làm cho tính lãng mạng của tôi bị ảnh hưởng với sự trừu tượng của OOP. Đẳng cấp doanh nghiệp ư? Xin đừng làm tôi mê muội bằng những ngôn ngữ mang tính dịch thuật và marketing của nhóm PHPVietnam. Tôi ngán chúng nó đến tận cổ rồi. Dù có thêm PHP5 hay PHP6 thì tôi vẫn chỉ code PHP cho cá nhân tôi và cái phần mềm của tôi vẫn be bé như thế. 10.000 hay 20.000 request 1 giây ư? Lạy chúa, băng thông của con chỉ có 3GB 1 tháng. Xin chúa rủ lòng thương.
Tóm lại, việc chuyển từ PHP4 sang PHP5 đang bị chi phối rất nhiều vào tầm cỡ cộng đồng (dân PHP không có nhiều người thông minh đâu), tính tương thích của các ứng dụng đang dùng, số ứng dụng mới có khả năng thay thế chạy được trên PHP5, tâm lý chống đối và ngại chuyển đổi, sự đón nhận PHP từ phía doanh nghiệp. Đây là những điều mà tôi đã rút ra sau khi đã lập ra PHPVietnam.
Thời gian sẽ trả lời và việc quyết định là tùy ở bạn
Thân ái
và thêm nữa của lineage

em có đọc một bài của một tiền bối với 30 năm kinh nghiệm làm về software engineering ở Carnegie Mellon University (một trong những trường dạy về Khoa học máy tính danh tiếng nhất nhì thế giới) , ông ấy nói rằng giới trẻ đừng bao giờ nên học .NET trước tiên mặc dù .NET rất là mạnh. Hãy học về Java, Perl hay Python trước để nắm được cái nền tảng về lập trình hướng đối tượng rồi sau đó học .NET sẽ nhanh hơn, hiểu rõ hơn. Ông ấy nói với cách học này ông tin chắc rằng người học sẽ tiến xa hơn rất nhiều, giỏi hơn nhiều so với những anh lười nhác chỉ biết dựa vào những công cụ có sẵn trong .NET.
Ông ấy nói Java và .NET không có khác gì nhau xét về nguyên lý vì .NET là một bản sao của Java về mặt ý tưởng + phong cách và những toan tính của Microsoft mà thôi. Microsoft bao giờ cũng là công ty có khả năng tạo ra các công cụ dễ làm việc nhất. Nhưng trong khi tạo điều kiện về mọi thứ thì user lại hòan toàn bị lệ thuộc. Họ chỉ biết kéo và thả hoặc chỉ biết ấn nút chứ đâu có biết cái gì nằm bên dưới. Rồi dần dần, cái ấn nút và kéo thả làm cho họ lười đi, họ quen với cái đó, họ không thể dứt ra được. Họ bị chi phối hòan toàn bởi M$.
Chuyển sang một ngôn ngữ mới ư ? Nhiều người chuyên về .NET (không phải tất cả) sẽ hỏi: nó có kéo thả không, nó có tiện ích như Visual Studio không…. Nghĩa là tài năng của họ đang thui chột, tính cơ động và khả năng ứng biến của họ đang giảm sút rõ rệt. Những người như thế khi công nghệ thay đổi họ dễ bị đứt quá vì khả năng học của họ giảm đi quá nhiều. Giống như con gà tre (sống bờ bụi) với con gà công nghiệp ấy mà. Dân .NET nhiều người tự biến họ thành con gà công nghiệp.
Các bác không tin ư? Cứ hỏi mấy bác chuyển từ VB 6 sang Java mà xem: luôn miệng hỏi: công cụ nào hỗ trợ kéo và thả để tạo giao diện. Ở Java không có tiền lệ đó mặc dù NetBeans có hỗ trợ kéo và thả. Chính vì thế, giới lập trình luôn coi trọng trình độ của dân Java hơn dân .NET. Do phải suy nghĩ nhiều hơn, làm việc nhiều hơn nên giới công nghệ ở Mĩ gọi dân Java là dân smart (thông minh).
Điều không may là ở giới PHP có nhiều người thiếu chuyên nghiệp, họ viết mã nhưng lại không hiểu gì về software engineering vì họ chẳng quan tâm đến điều đó. Trên các diễn đàn quốc tế, em gặp khối đứa có 12-13 tuổi code PHP ầm ầm. Hi vọng PHP5 sẽ trấn chỉnh lại hàng rào gia nhập đội ngũ PHP coder, yêu cầu họ nghĩ nhiều hơn trước khi viết, buộc họ đánh giá lại PHP và không coi PHP là ngôn ngữ mì ăn liền nữa.

No related posts.