Author Archive

Ext JS và Bài Học Về Mã Nguồn Mở

Tháng Chín 22, 2008

<nguồn: http://www.web2vietnam.com/2008/04/29/ext-js-and-lession-of-os-license/>

Cách đây ít ngày một thư viện JavaScript/Ajax mà tôi rất thích dùng, Ext JS, đột ngột chuyển giấy phép sử dụng từ LGPL (một phiên bản của GPL cho phép sử dụng phần mềm mã mở trong các dự án thương mại) sang GPL v3 (một giấy phép mã mở chặt chẽ bắt buộc các dự án muốn dùng phần mềm mã mở cũng phải là mã mở) sau khi công bố một bản nâng cấp nhỏ. Điều này đã làm dấy lên một làn sóng phản đối, công kích trong khắp cộng đồng người dùng và phát triển.

extjs-gpl.gif

Tôi đã dùng Ext JS ngay từ khi nó chỉ là một thư viện mở rộng của YUI. Đây là một thư viện rất tốt, đặc biệt nó cung cấp những gói UI rất đẹp và dễ sử dụng — chỉ cần vài dòng code JavaScript bạn đã có thể tạo nên một giao diện chuyên nghiệp cho ứng dụng web của mình. Lúc này thư viện có tên là YUI-Ext và được phân phối dưới giấy phép BSD như YUI.

Sau đó Jack Slocum và nhóm phát triển đã đưa thư viện YUI-Ext vượt khỏi phạm vi của YUI trở thành một dự án độc lập. Khi version đầu tiên của Ext JS ra lò, giấy phép sử dụng được đổi thành kiểu “song hành” (dual license): người dùng có thể chọn LGPL (với một vài hạn chế nhỏ) hay mua giấy phép sử dụng thương mại. Có thể nói đây là một bước đi không có gì đáng chê trách để Jack và đồng sự có thể kiếm tiền cho việc phát triển của dự án. Cộng đồng phát triển mã mở vẫn rất vui lòng đóng góp và ủng hộ cho dự án, hơn 35.000 thành viên của diễn đàn Ext JS đã đóng góp vô số ý kiến, thông báo lỗi và tạo nên các thư viện mở rộng (extension) cho chính Ext JS.

Sự kiện Ext JS chuyển giấy phép sử dụng thành GPL (từ phiên bản 2.1 trở đi) đã gây sốc cho công đồng mã nguồn mở vì nhiều lý do. Không hẳn vì chúng ta sẽ phải trả tiền cho Ext. Với giấy phép thương mại hiện tại bạn chỉ cần mua một bản (cho 1 lập trình viên) là có thể triển khai không hạn chế trên nhiều máy chủ (chính xác hơn là trên số CPU không giới hạn). Những lý do chính khiển cộng đồng phát triển không hài lòng là:

  1. Vấn đề đạo đức: Ext JS khởi đầu là một dự án “ăn theo” YUI, họ nhận được nhiều quan tâm vì danh tiếng của YUI. Sau khi xác lập đựơc vị trí, họ bỏ giấy phép tự do và bắt đầu theo đuổi giấy phép chặt chẽ hơn. Là một dự án mã mở, họ nhận được rất nhiều đóng góp từ cộng đồng và đổi lại cộng đồng phát triển ngày lại càng bị thu hẹp phạm vi sử dụng.
  2. Vấn đề lòng tin: Bạn có thể tin được một công ty thay đổi giấy phép thường xuyên theo hướng càng kiếm được nhiều tiền càng tốt hay không? Điều gì sẽ xảy ra nếu một ngày đẹp trời nào đó, sau khi triển khai ứng dụng trên hàng chục máy chủ (tức là vài chục CPU), Ext JS đổi giấy phép thương mại từ “unlimited” sang “per-CPU”? Bạn sẽ phải chấp nhận trả một khoản phí “trên trời rơi xuống” hay bỏ mặc ứng dụng của mình không được nâng cấp hay vá lỗi?
  3. Vấn đề phạm vi giấy phép: Điểm khác biệt giữa LGPL và GPL là giờ đây dự án nào muốn dùng Ext JS miễn phí thì cũng phải là “nguồn mở” theo đúng giấy phép GPL v3. Có ba vấn đề gây tranh cãi là: (1) Vì Javascript được chuyển từ server qua browser người dùng, thì việc này có được coi là “phân phối” mã nguồn và do đó chịu sự rằng buộc của GPL hay không? (2) Việc nén, obfuscate các thư viện Ajax theo GPL có hợp lệ hay không khi người được phân phối (tức là người dùng ứng dụng) không xem được toàn bộ mã nguồn? (2) Theo Jack, mã server-side (Java, PHP…) của dự án cũng phải là nguồn mở mới được dùng Ext JS trong khi một số chuyên gia về giấy phép mã mở cho rằng điều đó là không đúng vì mã JavaScript không có mối liên kết tĩnh (statical link) nào với mã server (?).
  4. Vấn đề thích hợp: Vì những rắc rối nói trên mà bản thân giấy phép GPL v3 không “bao phủ” được hoàn toàn nên hầu hết các thư viện JavaScript đều chọn các giấy phép nguồn mở tự do hơn như BSD hay Apache 2. Việc Ext JS chọn GPL sẽ để lại các “lỗ hổng” có thể dẫn tới việc tranh tụng trong nhiều trường hợp hay nói cách khác chúng giống như những cái bẫy tiềm năng khiến cho việc sử dụng thư viện này theo hướng mã mở hoặc không thể thực hiện được hoặc không hiệu quả.

Nhiều người nói rằng dùng mã nguồn mở là hướng đi rẻ tiền, dễ dàng cho các công ty Việt Nam nhưng câu chuyện trên chỉ là một phần nhỏ trong rất nhiều vấn đề mà các giấy phép mã nguồn mở đặt ra. Tại Mỹ, muốn có lời khuyên đúng đắn bạn sẽ phải nhờ tới các luật sư có kinh nghiệm trong lĩnh vực này và không thực sự có nhiều luật sư như vậy (chắc chắn Jack đã không có được một luật sư tốt).

Qua vụ việc này tôi đã có được nhiều bài học (rất hữu ích cho các CIO), xin tổng kết lại dưới đây:

  1. Giấy phép sử dụng (mã mở hay thương mại) có thể bị thay đổi bất kỳ lúc nào. Mặc dù việc thay đổi giấy phép không áp dụng ngược với các phiên bản trước nhưng bạn sẽ phải đối mặt với vấn đề “trả tiền để được nâng cấp, hỗ trợ hay bỏ mặc phần mềm đó“. Vì thế nên dùng phần mềm mở do các công ty có uy tín bảo trợ vì thường họ rất ít khi thay đổi giấy phép nếu không có lý do chính đáng.
  2. Khi dùng mã nguốn mở, bạn phải đánh giá được mức độ rủi ro có thể gây ra do việc đổi giấy phép và chấp nhận mức độ rủi ro này.
  3. Không phải tất cả các giấy phép mã mở đều giống nhau. Hiểu hết các “ngõ ngách” trong đống ngôn từ của các giấy phép này là việc của các chuyên gia và dù vậy bạn vẫn có thể dính vào kiện tụng do sự diễn dịch khác nhau giữa các bên và khi ấy quyền phán quyết nằm ở tòa án.
  4. Nếu bạn định phân phối phần mềm của mình dưới giấy phép mã nguồn mở thì hãy suy nghĩ và tìm hiểu thật kỹ về phạm vi của các giấy phép này. Tất nhiên, vì là phần mềm của bạn nên bạn có quyền thay đổi giấy phép bất kỳ lúc nào cho các phiên bản mới, nhưng nếu không có lý do chính đáng cộng đồng mã mở sẽ cho rằng bạn đang lợi dụng mã mở để chuộc lợi và bạn sẽ nhanh chóng bị tẩy chay. Trong thế giới đầy cạnh tranh, bạn sẽ biến mất nhanh hơn bạn tưởng.

Ext JS và cá nhân Jack đang chịu nhiều sức ép từ phía cộng đồng. Có thể việc thay đổi giấy phép là bắt buộc nhằm kiếm tiền từ dự án để trả lương cho các lập trình viên nhưng người dùng không khỏi có cảm giác bất mãn khi đã bỏ công sức xây dựng các ứng dụng dựa vào thư viện này rồi đột nhiên nhận thấy nó sẽ không thích hợp nếu sử dụng vào các dự án thương mại hay mã đóng như dự kiến. Quan trọng hơn, việc đổ vỗ lòng tin khiến cho những người dùng nghiêm túc phải suy nghĩ lại về quyết định của mình khi đặt niềm tin lâu dài vào Ext JS.

Các bạn có thể tham khảo thêm về “vụ” Ext JS ở các bài viết dưới đây:

 

Comments:

Thai | April 30th, 2008 at 1:14 am

Bài viết được. Chỉ có một lỗi nhỏ (hay gặp) là bồ đã đánh đồng “phần mềm thương mại” (commercial software) với “phần mềm nguồn đóng” (closed source or proprietary software). Hai khái niệm đó không tương đồng với nhau. Phần mềm thương mại vẫn có thể là phần mềm nguồn mở hay tự do. Phần mềm thương mại vẫn có thể sử dụng các thành phần nguồn mở hay tự do trong mã nguồn của chúng. Phần mềm nguồn đóng thì không thể làm được chuyện đó.

Bản thân tôi cho rằng, không thể trách nhóm Ext JS. Ext JS là của họ, họ có toàn quyền quyết định sẽ sử dụng giấy phép nào.

Nếu cộng đồng không thích và nếu cộng đồng đủ mạnh, họ hoàn toàn có thể lấy phiên bản cuối cùng của Ext JS phát hành với license LGPL mà phát triển lên tiếp.

Còn nếu cộng đồng không thể làm chuyện đó, chứng tỏ rằng, phần lớn công sức phát triển Ext JS là của nhóm của Jack, nên họ xứng đáng kiếm được nhiều tiền hơn từ công sức mà họ bỏ ra.

Vả lại, chọn giấy phép GPLv3 cũng không phải là một quyết định tồi, nếu đứng trên góc nhìn của người ủng hộ phần mềm tự do, nguồn mở.

Nếu có ai đó phải trách, tôi nghĩ chính là những người sử dụng Ext JS mà không có những nghiên cứu cần thiết về rủi ro hoặc chỉ chăm chăm muốn *bốc lột* công sức của người khác mà không muốn trả tiền.

———————————————————————–

TanNg | April 30th, 2008 at 1:51 pm

@Tác giả. Bài viết hay. Open Source, Open content còn cần một chặng đường dài để điều chỉnh và phát triển. Tuy vậy, một khi triết lý đã đúng, thì dù gặp vài trục trặc, cuối cùng phong trào mở vẫn sẽ chiến thắng.

@Thái. Đồng ý với bạn về việc cộng đồng nếu không thích có thể sử dụng bản cuối cùng để phát triển lên tiếp. Tuy vây, khi nhóm Jack đã sử dụng cộng đồng để phát triển nên sản phẩm này thì họ cũng có nghĩa vụ tham khảo và tôn trọng ý kiến cộng đồng trước khi đưa ra các quyết định quan trọng ảnh hưởng tới nhiều người như thay đổi License từ GPL sang GPL3.

Bình luận ngang một chút về GPL3. Open Source thường được đánh đồng với Tự do, nhưng tự do nhất có lẽ là BSD license, GPL3 tạo ra quá nhiều ràng buộc khiến người ta phải tuân theo và tự đánh mất triết lý cốt lõi của chính mình. Tôi có cảm giác rằng, thay vì việc định vị mình là phục vụ cộng đồng, phần nào GPL3 đã tự định vị mình là anti mã đóng.

———————————————————————–

Hồng Quang | April 30th, 2008 at 11:00 pm

@Thai, @TanNg: Thanks for good comments.

@Thai: Hình như mình không đề cập gì tới những khái niệm như phần mềm thương mại (commercial software – CS), phần mềm mã đóng (closed source software – CSS). Đây là một vấn đề khá phức tạp, tuy nhiên, để chúng ta không nhầm lẫn về ngữ nghĩa, mình xin làm rõ những điểm này:

+ Phần mềm thương mại: là những phần mềm được làm ra để cho mục đích thương mại (nói nôm na là để bán lấy tiền). Nghĩa là, trong phần lớn trường hợp, bạn sẽ phải phân phối nó cho khách hàng. Thường thì phần mềm thương mại là mã đóng (closed source) và thuộc sở hữu của một cá nhân hay tổ chức (proprietary software). Một số phần mềm thương mại là mã mở, trong trường hợp này nó sẽ có ít nhất hai loại giấy phép (dual license): giấy phép thương mại và giấy phép mã mở.

+ Giấy phép mã mở chủ yếu chi phối việc bạn có được phân phối lại trong các dự án thương mại hay không. Cụ thể LGPL, BSD hay Apache cho phép điều này (với các điều kiện khác nhau một chút), ngược lại GPL thì tuyệt đối không.

+ Vì thế bạn có thể dùng phần mềm mã mở (kể cả loại giấy phép GPL như MySQL) tự do, kg phải trả phí miễn là bạn không có ý định phân phối lại nó (thí dụ, dùng MySQL trong các dự án web của công ty bạn ngay cả dự án đó lớn như FaceBook). Đây là đọan trích từ Giấy Phép Mã Mở của MySQL:

“Free use for those who never copy, modify or distribute. As long as you never distribute the MySQL Software in any way, you are free to use it for powering your application, irrespective of whether your application is under GPL license or not.”
(Source: http://www.mysql.com/about/legal/licensing/opensource-license.html)

Ngược lại, bạn phải dùng giấy phép thương mại do MySQL AB cấp. Xin xem thêm các trường hợp cụ thể bạn phải mua giấy phép ở đây:
http://www.mysql.com/about/legal/licensing/commercial-license.html

+ Khi phân phối lại các phần mềm mã mở (nếu được phép) bạn phải kèm theo giấy phép và giữ nguyên tham chiếu xuất xứ để người dùng biết được bạn đang dùng các phần mềm mã mở nào, có thể tham khảo mã ở đâu…

+ Nếu bạn mua giấy phép thương mại của một phần mềm mã mở (như của Ext JS hay của MySQL) thì nó sẽ cho phép bạn triển khai trên một số CPU nhất định và/hoặc sử dụng cho số lập trình viên nhất định. Nếu bạn phân phối lại một phần mềm có giấy phép thương mại (thường là dạng thư viện – library) thì tùy trường hợp giấy phép sẽ đòi bạn trả phí thêm cho mỗi bản phân phối (royalty fee) hay kg có rằng buộc này (royalty free). Đương nhiên bạn không cần kèm giấy phép sử dụng và tham chiếu tới các phần mềm bạn mua trong bản phân phối của mình dù nó là mã mở.

Trường hợp các thư viện JavaScript/Ajax như Ext JS khá đặc biệt. Các thư viện này được “phân phối” từ máy chủ tới browser của người dùng (ít nhất theo lập luận của Jack) nên khi nó chuyển qua giấy phép GPL thì đòi hỏi cả dự án web dùng nó phải là nguồn mở. Đây là điểm gây nhiều tranh cãi:

1. Liệu việc sử dụng một ứng dụng web có bị coi là phân phối lại phần mềm hay không?

2. Việc sử dụng một thư viện JavaScript dưới giấy phép GPL có buộc cả dự án phải là mã mở hay không (vì mối liên kết giữa JavaScript và mã server-side có thể chưa đủ mạnh để bị coi là có “liên kết tĩnh” theo định nghĩa của GPL)?

3. Có được phép nén, obfuscate một thư viện JavaScript dùng giấy phép GPL hay không?

Nếu xảy ra tranh chấp và tòa án phán quyết rằng việc sử dụng ứng dụng web không bị coi là phân phối lại phần mềm (nhất là việc phân phối lại các mã JavaScript) thì có nghĩa là chúng ta sẽ có thể dùng Ext JS trong các dự án tương tự như dùng MySQL.

Còn nhiều vấn đề xung quanh câu chuyện này, nhưng hy vọng các bạn sẽ hiểu hơn về các giấy phép mã mở và phạm vi chi phối của chúng.

Nắm bắt con tim nàng

Tháng Chín 21, 2008

Bạn có muốn biết những suy nghĩ, những tâm tư mà con gái chẳng bao giờ tiết lộ? Hãy tìm hiểu dưới đây nhé, để biết cách chinh phục nàng.

Nên

Lãng mạn

Cô gái nào cũng mong muốn nhận được một đóa hồng và có một khung cảnh “kiss” lãng mạn như phim Hollywood. Cô ấy sẽ không bao giờ quên khoảng khắc ấy và sẽ yêu bạn hơn. Vì thế, hãy lập kế hoạch làm một điều gì đó đặc biệt tại một không gian thật ý nghĩa bạn nhé.

Bảo vệ, che chở

Hãy cho cô ấy cảm thấy an toàn, yêu thương và được quan tâm khi bạn ở bên cạnh. Tuy nhiên hãy biết cách cư xử khi ghen, đừng để cô ấy ái ngại với bạn bè xung quanh. Tốt nhất là nói thẳng thắn cảm xúc của bạn cho cô ấy, nhưng nhớ rằng cô ấy cũng cần có không gian của riêng mình.

Tin tưởng

Nếu bạn yêu cô ấy và cô ấy cũng yêu bạn, thì đâu còn có lý do nào để nghi ngờ cô ấy phải không? Đôi khi cũng thật khó khi cô ấy có nhiều cậu bạn thân, thế nhưng tin tưởng nàng tuyệt đối sẽ khiến nàng tự tin và yêu bạn nhiều hơn đó.

Đọc ngôn ngữ cơ thể

Nếu cô ấy muốn cầm tay bạn, cô ấy sẽ nghịch các ngón tay, còn nếu cô ấy muốn hôn bạn, cô ấy sẽ nũng nịu đôi môi. Và nếu cô ấy không muốn bạn làm điều gì, hãy ngừng ngay mọi hành động nhé.

Hãy nói lời yêu thương

Bày tỏ cảm xúc của bạn cho cô ấy nghe. Hãy đảm bảo những lời nói ấy phải đặc biệt và bạn thực sự hiểu ý nghĩa của chúng là gì.

Chia sẻ quyền lực

Hầu hết con gái thích bạn trai mình đã lên lịch sẵn các cuộc hẹn, hoặc ít ra cũng là người chủ động. Tuy vậy, cũng rất thú vị nếu cô ấy là người lựa chọn cùng bạn. Hãy đưa ra những phương án để cô ấy lựa chọn hoặc chia sẻ ý kiến cùng nhau.

Chiều chuộng

Dù cho cô ấy bảo không cần bạn tặng quà trong dịp Giáng sinh, sinh nhật thì bạn vẫn đem cho cô ấy một thứ gì đó thật ý nghĩa và dễ thương nha. Ví dụ như một lọ nước hoa hoặc một vòng cổ hay một món đồ trang sức nào đó. Ngoài ra, những món đồ tự tay bạn làm hoặc mang dấu ấn cá nhân sẽ còn ý nghĩa hơn rất nhiều.

Không nên

Áp đặt mọi sở thích của bạn lên cô ấy

Hãy để cô ấy có quyết định tham gia hay không và đừng bắt cô ấy làm điều gì cô ấy không muốn.

Lưỡng lự gọi điện hoặc gửi email

Rất nhiều mối quan hệ phải chấm dứt vì hai bên không thường xuyên liên lạc với nhau. Thêm vào đó, việc chàng trai chủ động gọi điện và trò chuyện là điều các cô gái mong chờ.

Mang bạn bè theo mà không hỏi ý kiến

Thường thi các nàng không ngại khi đi chơi cùng nhóm bạn, nhưng nếu mang bạn bè theo mà không nói với cô ấy trước, cô ấy sẽ cảm thấy bị động và chỉ muốn có hai người bên nhau mà thôi.

E dè thể hiện cảm xúc nơi công cộng

Không phải là những cử chỉ khiêu gợi nhưng một cái nắm tay, vòng tay ôm eo cô ấy hoặc đặt một nụ hộn trên trán cũng khiến cô ấy tự hào với tình yêu bạn dành cho.

Ngọc Linh

Theo Datingtips

RainbowCrack: Công cụ để crack mã md5 hiệu quả

Tháng Chín 19, 2008

Cái tool này được biết đến từ rát lâu rồi nhưng bây giờ mới lục lại. Version hiện tại là 1.2. Phần mềm này giải mã chuỗi mã md5 ra chuỗi nguyên thuỷ của nó.

RainbowCrack sử dụng giải thuật LanManager và vì vậy phải tạo ra các Rainbow Table.

Trang chủ : http://www.antsight.com/zsl/rainbowcrack/

Nếu bạn sử dụng Windows thì bạn có thể download ở địa chỉ sau:http://www.antsight.com/zsl/rainbowcrack/rainbowcrack-1.2-win.zip

Sau khi download về, bạn giải nén ra và trước tiên bạn nên đọc file readme.txt ở ngay trong thư mục của phần mềm.

Trong thư mục bạn vừa giải nén ra có một thư mục là doc, có chứa các file hướng dẫn bạn sử dụng phần mềm này.

Đầu tiên bạn phải tạo ra các rainbow table. Việc này mất rất nhiều time. Tốt nhất là bạn lên google và search các table này. Tất nhiên là với điều kiện mạng của bạn phải tốt vì  tập các file này nếu nén lại nhỏ thì cũng phải 1.5GB.

Từ khoá chính xác là : “index of /” lm_alpha.rt

(đuôi rt có nghĩa là Rainbow Table)

Và bây giờ, bạn thử lệnh này xem:

E:\rainbowcrack>rcrack f:\table2\*.rt -h e80b5017098950fc58aad83c8c14978e

nó sẽ tìm ra là 123456 :D

Have a good time! (author:cthai83@yahoo.com)

“Lệnh help” cho một tình yêu… “sắp mất” ….. !

Tháng Chín 17, 2008

Làm thế nào để “undo” lại tình yêu của hai người sau khi “phe kia” trót “khai tử” nó trong một phút “bốc khói”? Nếu thật lòng muốn cứu chữa, không còn giải pháp nào khác ngoài việc cả hai đều phải “xắn tay áo” lên thôi!

Nếu cô ấy nói: “Anh không hiểu em, chúng ta nên dừng lại ở đây”

Thì tức là cô ấy không muốn bất – cứ – một – cuộc – tranh – luận nào nữa vào lúc này. Bởi vậy nếu bạn chọn phương án “phục kích” nàng để tiếp tục “làm rõ trắng đen” là “hạ sách” lắm đấy!

Lệnh “help” cho tình yêu của bạn lúc này là tìm một cách thật lãng mạn gửi lời xin lỗi tới cô ấy. Chẳng hạn như ôm lỳ một bó hoa hồng vàng (xin lỗi mà) và “đứng trơ” trước cổng nhà cô ấy xem nào. Chắc chắn là nàng nói chia tay phần lớn bởi vì… ”dỗi” mà thôi. Cứ tạm thời “lờ lớ lơ” lý do củ chuối khiến hai người “chiến tranh” một thời gian cái đã, thiệt đi đâu mà lo, nhỉ?

Nếu anh ấy chốt hạ: “Em chẳng còn thời gian dành cho anh nữa, có lẽ anh nên để em được tự do”

Thì tức là anh ấy đã quá “tủi thân” vì thái độ thờ ơ mà bạn đang “lạm dụng” với tình yêu của hai người. Thậm chí, khi anh ấy đề xuất chuyện chia tay thì bạn mới chột dạ, vì lâu nay “vẫn ngỡ như là…” cơ mà, hic?

“Lệnh help” khẩn cấp cho tình yêu lúc này là ngay lập tức “sửa sai” bằng hành động mang đúng “thiên chức” của – một – người – bạn – gái. Trở lại thói quen nhắn những sms tình cảm mà gần đây bạn quy kết nó là “xa xỉ”, rủ anh ấy cùng đi shopping và nhẹ nhàng ướm thử cho chàng một chiếc áo sơ mi, hoặc đơn giản là hẹn chàng đến quán café kỉ niệm và chân – thành – nhận – khiếm – khuyết với anh ấy. Nếu chuyện chia tay chỉ là “một phút tức giận” của chàng thì như thế là ok rùi đấy !

Nếu cô ấy tuyên bố: “Chúng ta chia tay nhé, em đã có người khác rồi”

Trong khi sự thật là cô nàng “ở nhà một mình” tất tần tật các tối cuối tuần, thì có nghĩa là số bạn vẫn còn… may chán. Lí do về một kẻ thứ ba chỉ là cái cớ để cô ấy “trừng phạt” bệnh ghen bóng gió của bạn. Đôi khi cách thể hiện tình yêu thái quá lại khiến cô ấy (cũng như bạn bè cô ấy) dị ứng vô cùng. Và bởi… ghét, nên cô ấy mới nóng giận mà buông ngay lời chia tay thế đấy!

“Lệnh help” duy nhất cứu nguy cho bạn lúc này là phải làm một bản “tường trình” với cô ấy về những lý do ghen tuông rất chi là “củ chuối” của bạn. Tất nhiên, vòng vo thế nào thì sau cùng vẫn phải chốt lại lý do vĩ đại nhất: do bạn quá yêu và lúc nào cũng sợ mất cô ấy mà thôi. Nhớ là sau khi cô ấy “mủi lòng” rồi thì nhất định “cam kết và giữ đúng cam kết” không ghen “vô tội vạ” nữa nhé!

 

Chăm chút cho tình yêu nhiều hơn nữa nhé!

Nếu hai người bỗng dưng “ngán nhau”

Nghe thì có vẻ “vô thưởng vô phạt” nhưng đây lại là lí do “hơi bị lớn” để dẫn đến chuyện “chia tay chia chân”. Khi một trong hai, hoặc là cả hai người không còn cảm thấy hứng thú với tình yêu của mình nữa, thì xu hướng “ngãng ra” là tất yếu. Tuy nhiên sau khi “trót” chia tay rồi, nhiều cặp mới hoảng hốt nhận ra sự thiếu vắng trong cuộc sống của mình. Không sao đâu, chỉ cần tình yêu của hai bạn vẫn còn tồn tại thì dù có “del nhầm” vẫn có thể cứu chữa được.

“Lệnh help” lần này yêu cầu cả hai phe đều phải “chấp hành tuyệt đối” để “gương vỡ lại lành”: Nhanh chóng bắn tín hiệu cho anh/cô ấy rằng bạn đang nhớ người ta không chịu được. Thêm vào đó là những thông điệp thật dí dỏm để “chữa ngượng” cho người ta, chẳng hạn như: “Anh nói chia tay là bởi đang muốn… cưa cẩm em lại từ đầu”, hoặc “Em muốn chia tay, là để “dắt mối” cho anh một cô gái đã được làm mới” đấy!

Nhớ là khi mọi chuyện đã ổn thì hai người phải nghiêm chỉnh chăm sóc cho một tình yêu đã được F5 nhé!

Một tình yêu đẹp trước hết được đo bằng độ bền của nó, đừng vì một phút nỏng nảy nhất thời mà vội vã tuyên bố “giã từ dĩ vãng” nhé! Sẽ là đáng tiếc lắm đấy, nếu như bạn không cố gắng đến cùng cho tình yêu của mình!
Theo DT

Bảng đánh giá kỹ năng

Tháng Chín 16, 2008

Đây là bản survey của forum cho các member nhằm mục đích tham khảo và kế hoạch phát triển đội ngũ HR cho forum. Các bạn tham khảo vào quote lại để trả lời nhé.

Kỹ năng
12345
Giải thích

Ngôn ngữ PHP
—–Từ mới học cho tới thuần thạo các php function string, date/time, array, I/O + upload, các php extension như mb_string

Lập trình OOP
—–Từ hiểu OOP tới viết thư viện dùng chung, n-tier coding, O/R mapping

Sử dụng PHP/MySQL
—–Mức kỹ năng có thể viết PHP và MySQL để lấy data, xử lý form/validation, SQL inject cho tới PDO, Doctrine, O/R mapping

JavaScript
—–Từ JS cơ bản, event hooker tới OOP với JS, sử dụng JS framework (prototype, jQuery, extJs, mootool,…)

Ajax
—–Kinh nghiệm AJAX từ sử dụng dựa vào Ajax framework tới Ajax pattern

Sử dụng framework
—–Từ biết sử dụng framework (cakePHP, code igniter,…) tới đánh giá được framework, tự phát triển framework

Open source/reverse engineering
—–Đánh giá kỹ năng sử dụng các opensource, viết module, plug-ins, core hack/override,… từ biết dùng tới customize template – function,…

Làm việc nhóm
—–Kỹ năng làm việc nhóm từ coding tới lead, planning, share code, review/optimize, bug tracking

Hướng dẫn: Thang điểm từ 1-5 cao dần.
1: đã có khái niệm/từng nghe tới nhưng chưa tìm hiểu sâu
2: đã tìm hiểu, thực hành nhưng chưa áp dụng thực tế
3: áp dụng thực tế, tham khảo code
4: áp dụng thuần thạo, nhiều kinh nghiệm debug, xử lý tình huống
5: có thể mở rộng, thay đổi hoặc phát triển mới
Ở mức điểm nào, bạn thay dấu – bằng số điểm tương ứng.

Kỹ năng viết mã PHP

Tháng Chín 16, 2008
Tủ sách mở Wikibooks

Bước tới: chuyển hướng, tìm kiếm

Tổng hợp về các phong cách viết mã PHP (tiếng Anh A brief on PHP Coding Styles) là một tập hợp các quy tắc mà người lập trình PHP, một khi đã lựa chọn nó, nên tuân thủ trong quá trình tạo ra chương trình nhằm mục đích tạo sự thống nhất chung giữa các đoạn mã dễ theo dõi, sử dụng lại, phát hiện lỗi, bảo trì và kế thừa chương trình. Việc tuân thủ quy ước này sẽ giúp duy trì được khả năng làm việc nhóm và khả năng kế thừa lại của người đi sau.

Tài liệu này nên được đọc và hiểu như là một tham khảo về các phong cách viết mã PHP đương đại để có thể tùy nghi lựa chọn, nghiên cứu thêm. Nó không phải là một hướng dẫn kĩ thuật để lập trình được với PHP.

Cách viết mã PHP này dùng các nguồn tham khảo chủ yếu đến từ PEAR, Chuẩn viết mã Java theo Sun và một số trang khác. Kỹ thuật này hướng dẫn phong cách lập trình PHP có thể được dùng để tham khảo trong quá trình viết mã PHP.

Mục lục

[ẩn]

[sửa] Giới thiệu

Trang này cần được wiki hóa. Xin hãy trình bày trang theo các hướng dẫn đề cập trong phần Cẩm nang về văn phong, rồi bỏ chú thích này đi.

[sửa] Tại sao cần có quy ước viết mã

Các quy ước viết mã có ý nghĩa quan trọng đối với các lập trình viên vì một số lý do:

  • 80% trong tổng số chi phí duy trì một gói phần mềm phát sinh trong giai đoạn bảo trì.
  • Hầu như không có bất cứ một phần mềm nào được bảo trì trong suốt cả thời gian tồn tại của nó bằng chính tác giả đầu tiên của nó.
  • Các quy ước viết mã nâng cao tính dễ theo dõi của phần mềm, cho phép các kĩ sư hiểu được các dòng mã mới nhanh hơn và sâu sắc hơn.
  • Một mã nguồn được đưa ra thị trường như là một sản phẩm cần phải được đảm bảo là nó được đóng góp chuẩn và gọn ghẽ như bất cứ sản phẩm nào khác.

Để các quy ước này có hiệu lực, tất cả những ai tham gia viết phần mềm đều phải tuân thủ theo các quy ước viết mã. Không trừ một ai.

[sửa] Kế thừa và đóng góp

Tài liệu này phản ánh các tiêu chuẩn viết mã trong ngôn ngữ lập trình PHP được tổng hợp từ các tài liệu về Quy ước viết mã trong PEAR, Java do Sun Microsystems và đội ngũ PHP cung cấp.

[sửa] Tên file

[sửa] Phần mở rộng của tập tin

Luôn đặt phần mở rộng của tập tin là .php. Việc đặt đuôi khác như .inc hay .class đôi khi sẽ gặp rắc rối và tập tin PHP sẽ không được thực thi.

[sửa] Cách đặt tên file

[sửa] Các tên file thường gặp trong các ứng dụng PHP

Phần này nói về các tên tập tin thường gặp và tại sao nên dùng cái nào và không nên dùng cái nào. Ví dụ: để cấu hình trong tập tin dạng .ini là không nên nếu chưa có kinh nghiệm về .htaccess. Ngoài ra còn .lng, .xsl, .xml, .tpl. Các tập tin khác như gpl.txt, README.txt

[sửa] Cách đặt tên file chứa lớp

Theo quy ước đặt tên của Mojavi framework, tất cả các tập tin chứa các lớp (bao gồm cả các thư viện của framework) đều có hậu tố là .class.php

Ví dụ: Action.class.php

[sửa] Cách tổ chức file

[sửa] Bố cục nội dung trong file

[sửa] Dữ liệu miêu tả đầu file và lớp

Tất cả các file mã nguồn nên có một khối dữ liệu miêu tả ở cấp trang ở ngày đầu file và một khối dữ liệu miêu tả ở cấp lớp nằm ngày trên phần mã cho mỗi lớp. Phần này nên viết bằng tiếng Anh. Ví dụ:

 <?php
 /* vim: set expandtab tabstop=4 shiftwidth=4 softtabstop=4: */
 /**
  * Short description for file
  *
  * Long description for file (if any)...
  *
  * PHP versions 4 and 5
  *
  * LICENSE: This source file is subject to version 3.0 of the PHP license
  * that is available through the world-wide-web at the following URI:
  * http://www.php.net/license/3_0.txt.  If you did not receive a copy of
  * the PHP License and are unable to obtain it through the web, please
  * send a note to license@php.net so we can mail you a copy immediately.
  *
  * @category   CategoryName
  * @package    PackageName
  * @author     Original Author <author@example.com>
  * @author     Another Author <another@example.com>
  * @copyright  1997-2004 The PHP Group
  * @license    http://www.php.net/license/3_0.txt  PHP License
  * @version    CVS: $Id:$
  * @link       http://pear.php.net/package/PackageName
  * @see        NetOther, Net_Sample::Net_Sample()
  * @since      File available since Release 1.2.0
  * @deprecated File deprecated in Release 2.0.0
  */
  // Place includes, constant defines and $_GLOBAL settings here.
/** * Short description for class * * Long description for class (if any)... * * @author Original Author <author@example.com> * @author Another Author <another@example.com> * @copyright 1997-2004 The PHP Group * @license http://www.php.net/license/3_0.txt PHP License * @version Release: @package_version@ * @link http://pear.php.net/package/PackageName * @see NetOther, Net_Sample::Net_Sample() * @since Class available since Release 1.2.0 * @deprecated Class deprecated in Release 2.0.0 */ class foo { } ?>

Tham khảo PEAR: http://pear.php.net/pepr/pepr-proposal-show.php?id=128 (Còn tiếp)

[sửa] Thẻ đánh dấu mã PHP

Phần này nói rõ là nên dùng <?php?> chứ không dùng cái khác. Với cách dùng này, tập tin PHP sẽ luôn được hiểu một cách chính xác.

[sửa] Cách thụt lùi dòng và chiều dài của dòng

Phần này nói về số white space áp dụng cho các hàng thụt lùi: ví dụ cho hàm con thuộc lớp, lệnh if trong một hàm thì lùi vào so với số cột bắt đầu tên hàm là bao nhiêu….

[sửa] Chú thích mã

Nên chú thích mã như thế nào. Áp dụng các thẻ meta (param) như thế nào. Áp dụng /**/ cùng với // như thế nào.

[sửa] Định dạng file

Phần này tuân thủ nguyên tắc của PEAR (có sửa đổi) theo đó:

  • Định dạng file là dạng văn bản ASCII (nên xem lại điểm này vì tiếng Việt có thẻ chứa Unicode mà)
  • Sử dụng mã hóa kí tự UTF-8
  • Được định dạng cho Unix
    • "Định dạng theo Unix" nghĩa là:
      1. Các dòng phải được kết thúc chỉ với một kí hiệu line feed (LF). Các kí hiệu bắt đầu hàng mới như vậy được được biểu diễn như là các kí hiệu hệ thập phân (10), hệ bát phân (012) và hệ thập lục phân (0A) thông thường. Không dùng các kí hiệu về đầu hàng carriage returns (CR) như các máy Macintosh hay kết hợp carriage return/line feed (CR/LF) như các máy Windows.
      2. Nên có một line feed sau thẻ PHP đóng (?>). Điều đó có nghĩa là khi con trỏ ở tận cùng của file, thì nó nên có một hàng bên dưới thẻ PHP đóng.

[sửa] Quy ước đặt tên biến, hằng, hàm, phương thức, lớp

[sửa] Khai báo

[sửa] Khai báo và khởi tạo biến

[sửa] Biến toàn cục

Nếu một gói cần định nghĩa các biến toàn cục (global) thì tên của chúng nên bắt đầu bằng một gạch đơn dưới, sau đó là tên gói và một gạch dưới khác. Ví dụ, gói PEAR dùng một biến toàn cục là $_PEAR_destructor_object_list.

[sửa] Biến thông thường

Tên biến nên là danh từ có ý nghĩa miêu tả nó chứa cái gì hay nó làm nhiệm vụ gì. Tên biến nên bắt đầu bằng chữ viết thường. Nếu biến gồm có nhiều từ thì ghép các từ đó lại: từ đầu tiên viết thường, từ thứ hai và thứ ba viết hoa chữ cái đầu tiên. Ví dụ:

  • somePrivateProperty
  • counter

Các cái tên như "foo" và "tmp" nên tránh dùng vì nó không miêu tả cái gì cả. Tên biến không nên chứa các con số. Các con số nên được miêu tả bằng các chữ cái trừ khi có lý do thiết thực để không làm như vậy. (Theo Chuẩn của ezPublish).

Ví dụ:

  • $valueOne

[sửa] Tên lớp, khai báo lớp và giao diện

Tên lớp nên là một danh từ miêu tả, xác định rõ lớp đó nó là cái gì. Tránh dùng từ viết tắt. Tên lớp nên bắt đầu bằng từ viết hoa. Khi áp dụng kĩ thuật hướng đối tượng để viết mã thì cần chú ý tên lớp cũng nên phản ảnh cây phân cấp lớp, mỗi bậc của cây phân cấp được cách nhau thông qua một dấu gạch dưới. Ví dụ:

  • Log
  • Net_Finger
  • HTML_Upload_Error

[sửa] Định nghĩa hàm và gọi hàm

[sửa] Tên gọi của hàm

Trong PHP, khái niệm hàm và phương thức thay thế được cho nhau. Chúng ta gọi khái niệm hàm cho lập trình thủ tục và dùng khái niệm phương thức khi lập trình hướng đối tượng.

Hàm và phương thức đều chỉ mặt hoạt động, thao tác, vì vậy tên chúng nên gọi tả hành động tương ứng.

Hàm và phương thức nên được đặt tên theo quy tắc "studly caps" (còn được gọi là "bumpy case" hay "camel caps"). Hàm nên lấy tên gói làm tiền tố, để tránh xung độ giữa các gói. Phần tiền tố cách phần tên hàm thực thụ qua một dấu gạch dưới. Chữ cái đầu tiên của tên (sau tiền tố) nên viết thường, và mỗi một chữ bắt đầu một từ mới sẽ viết hoa. Ví dụ:

Các thành viên lớp dạng private (nghĩa là thành viên đó được tạo ra chỉ nhằm để tiếp xúc với bên trong lớp mà chúng được khai báo mà thôi) thì được bắt đầu bằng một dấu gạch dưới. Ví dụ:

  • _sort()
  • _initTree()
  • $this->_status

Cách khai báo này được dùng trong PHP 4.x khi các từ khóa sửa đổi phạm vi truy cập chưa được định nghĩa. Nhưng ở PHP5, PEAR không còn khuyến cáo cách làm này nữa do PHP 5 đã định nghĩa 3 phạm vi truy cập là private, public, protected.

[sửa] Định nghĩa hàm

Phần định nghĩa hàm nên tuân thủ theo quy ước "một ngoặc đơn thực sự". Không nên dùng dấu cách giữa tên hàm là dấu ngoặc đơn mở. Dấu ngoặc nhọn xác định phạm vi của hàm được đặt trên các dòng riêng.

 <?php
 function fooFunction($arg1, $arg2 = )
 {
     if (condition) {
         statement;
     }
     return $val;
 }
 ?>

Các đối số có giá trị mặc định được đặt ở cuối danh sách đối số. Cố gắng trả lại một giá trị có nghĩa từ một hàm, nếu có giá trị thích hợp. Ví dụ:

 <?php
 function connect(&$dsn, $persistent = false)
 {
     if (is_array($dsn)) {
         $dsninfo = &$dsn;
     } else {
         $dsninfo = DB::parseDSN($dsn);
     }
if (!$dsninfo || !$dsninfo['phptype']) { return $this->raiseError(); }
return true; } ?>

[sửa] Lời gọi hàm, phương thức

Khi gọi hàm, không nên dùng dấu cách giữa tên hàm, ngoặc đơn mở, và tham số thứ nhất; nên dùng một dấu cách giữa dấu phẩy và tham số, và không dùng dấu cách giữa tham số cuối cùng, dấu ngoặc đơn đóng và dấu chấm phẩy. Ví dụ:

 <?php
 $var = getMessage($bar, $baz, $quux);
 ?>

Như thấy ở trên, nên để một dấu cách ở hai bên dấu bằng dùng đến gán giá trị trả lại của một hàm vào một biến. Trong trường hợp viết nhiều phép gán có liên quan thì có thể dùng thêm nhiều dấu cách để làm tăng thêm tính dễ đọc:

 <?php
 $short         = foo($bar);
 $longVariable  = foo($baz);
 ?>

Lời gọi phương thức tuân theo những quy tắc cũng tương tự như lời gọi hàm. Phương thức là thuật ngữ dùng để chỉ hàm khai báo bên trong các lớp. Chuẩn này khuyến cáo không dùng dấu cách để tách phần dấu ngoặc đơn với đối số đặt ở giữa cặp ngoặc đơn này. Sau đây là ví dụ để bạn phân biệt cách gọi nào là hợp chuẩn:

 // Khuyến cáo theo Chuẩn này
 $object->method($a);
 $array[10] = 'foo';

 // Không khuyến cáo
 $object->method($a);
 $array[ 10 ] = 'foo';

[sửa] Khai báo hằng

Các hằng nên luôn viết tất cả dưới dạng chữ hoa, dùng gạch dưới để tách các từ. Phần tên hằng làm tiền tố thì dùng tên chữ hoa của lớp hoặc gói mà chúng ta định dùng chúng trong đó. Ví dụ, các hằng dùng trong gói DB:: tất cả đều bắt đầu bằng DB_. Điều này cũng là để tránh xung đột thôi.

Xin chú ý: Các hằng true, false và null là những trường hợp đặc biệt không bị chi phối bởi quy ước viết hoa này cho nên luôn viết chúng ra dưới dạng chữ thường.

[sửa] Câu lệnh

[sửa] Câu lệnh đơn giản

<?php echo "Welcome to http://www. http://www.vnrockworld.net"; ?>

<?php $text= " http://www.vnrockworld.net"; echo "mytext is" .$text; ?>

<?php // http://www.vnrockworld.net $i=4; $z=5; if ($i>$z) echo "True; else cho "Flase"; ?>

[sửa] Lệnh tổ hợp

[sửa] Lênh return

[sửa] Lệnh điều kiện và cấu trúc điều khiển

Cấu trúc điều khiển trong PHP bao gồm có if, for, while, switch, foreach.

Các cấu trúc điều khiển nên dùng một khoảng trống giữa từ khóa điều khiển và ngoặc đơn mở, để phân biệt chúng với lời gọi hàm.

Nên dùng các ngoặc nhọn ngay cả trong các tình huống chúng chỉ được xem là các tùy chọn kĩ thuật. Các dấu ngoặc nhọn sẽ làm cho mã dễ đọc hơn và làm giảm khả năng xảy ra các lỗi logic khi viết thêm các dòng mã mới.

[sửa] Lệnh if/else

Dưới đây là cách dùng hàm if/else tuân thủ quy ước chung

 <?php
 if ((condition1) || (condition2)) {
     action1;
 } elseif ((condition3) && (condition4)) {
     action2;
 } else {
     defaultaction;
 }
 ?>

[sửa] Lệnh for

Cách dùng vòng lặp for rất đơn giản:

 <?php
 
for ( expression1; condition; expression2 )
  { 
    expresion3;
  }
 ?>

[sửa] Lệnh while

Lệnh while cho phép thực thi một đoạn mã nếu như một điều kiện nào đó được thoả mãn, và chỉ ngừng chạy khi điều kiện đó không còn đúng.

Cú pháp cho vòng lặp while:

while (condition) code to be executed;

Ví dụ:

 <?php
    $i=1;
    while($i<=5)
    {
       echo "The number is " . $i . "<br />";
       $i++;
    }
 ?>

Giải thích ví dụ:

Vòng lặp while trên sẽ được thực thi lặp đi lặp lại với mỗi giá trị biếng $i thoả mãn điều kiện (nằm trong khoảng từ 1 đén 5). Giá trị khởi đầu của biến $i là 1. Sau mỗi lần thực hiện xong đoạn mã, giá trị này tăng thêm 1 (+1) rồi tiếp tục lặp lại đoạn mã đến khi nào đạt giá trị > 5 thì dừng.

Như vậy, kết quả của đoạn mã trên sẽ như sau:

 The number is 1 
 The number is 2 
 The number is 3 
 The number is 4 
 The number is 5 

[sửa] Lệnh dowhile

Lệnh Do…while có chức năng tương tự while. Nhưng trong khi while thực thi đoạn mã khi và chỉ khi điều kiện nêu ra được thoả mãn thì Do…while sẽ thực thi đoạn mã ít nhất 1 lần – ngay cả khi điều kiện không đúng – và tiếp tục lặp lại đoạn mã nếu như điều kiện vẫn còn đúng.

Cú pháp của vòng lặp Do…while:

 do
 {
   code to be executed;
 }
   while (condition);

Ví dụ:

 <?php 
 $i=0;
 do
 {
   $i++;
   echo "The number is " . $i . "<br />";
 }
 while ($i<5);
 ?>

[sửa] Lệnh switch
 <?php
 switch (condition) {
 case 1:
     action1;
     break;
  
 case 2:
     action2;
     break;
  
 default:
     defaultaction;
     break;
 }
 ?>

[sửa] Lệnh trycatch

[sửa] Liên kết ngoài

9 từ phụ nữ hay dùng

Tháng Chín 16, 2008

(Dân trí) – Đàn ông có “vô số lúc” không hiểu đúng phụ nữ. Đó là lý do tại sao bạn nên tìm hiểu ý nghĩa của 9 từ sau đây khi chúng được thốt ra từ cái miệng xinh xắn của nàng, để tự cứu mình trước gió giông đang sầm sập tới.

1. “Tốt thôi!”

Nàng sẽ nói vậy để kết thúc cuộc cãi vã. Lúc ấy phái yếu là người nắm thế chủ động, và trong trường hợp này, sự im lặng là điều tốt nhất bạn có thể làm.

2. “5 phút nữa”

Nếu cô ấy đang chuẩn bị thay đồ và trang điểm, phải mất ít nhất nửa tiếng đồng hồ. Hãy tự biến nửa tiếng đồng hồ ấy thành 5 phút bằng cách ngồi xem TV hoặc làm việc gì đó trong nhà, thời gian sẽ trôi nhanh thôi.

3. “Không có gì”

Đây là dấu hiệu bày tỏ thiện chí trước nguy cơ xảy ra tranh cãi. Những cuộc cãi vã đang “nhen nhóm” sẽ nhanh chóng được cứu cánh với “không gì cả” của nàng.

4. “Cứ thử xem”

Đó là một lời thách thức chứ không phải là sự cho phép của các nàng đâu nhé. Vì vậy, bạn chớ có dại mà làm.

5. Thở dài đánh thượt

Một tiếng thở dài cố tình cho bạn nghe thấy sẽ nói rằng cô ấy nghĩ bạn là tên ngốc và đang băn khoăn tự hỏi tại sao lại mất thời gian ở đây tranh cãi với bạn chẳng vì lý do gì.

6. “Được lắm”

Đây là một trong những lời nguy hiểm nhất mà một người phụ nữ có thể nói ra. “Được lắm” đồng nghĩa với việc cô ấy muốn có thời gian suy nghĩ lâu hơn trước khi quyết định đưa ra phương thức gì và thời điểm nào bạn sẽ phải trả giá cho sai lầm của mình.

7. “Cảm ơn”

Khi một người phụ nữ cảm ơn bạn, đừng nên hỏi lại hoặc giả bộ tảng lờ, mà chỉ cần nói “có gì đâu”. Nếu cô ấy nói “cảm ơn anh rất nhiều” thì thực chất đây chỉ là lời châm chọc và cô ấy không hề có ý cảm ơn bạn đâu. Trong trường hợp ấy, bạn nên cẩn thận vì câu đáp “có gì đâu” của bạn lại trở thành “thế nào cũng được” đối với cô ấy. Thật quá rắc rối phải không.

8. “Sao cũng được!”

Nói ra điều này, cô ấy đang muốn chửi đánh bạn lắm đó.

9. “Để em làm”

Đây lại là một câu nói đầy nguy hiểm vì nó có bao hàm ý nghĩa: “Anh biết phải làm việc này nhưng lại lười biếng không mó tay, và nằm dài đợi tôi về làm đấy!”.

Rất nhiều lần phụ nữ nhờ các chàng làm gì đó, nhưng cuối cùng họ lai phải xử lý một mình. Và nếu bạn hỏi “em sao thế?”, hãy xem lại câu nói số 3 của nàng.

Ngọc Linh

Theo Allwomenstalk

10 nguyên tắc cơ bản của những bậc thầy PHP

Tháng Chín 16, 2008

1. Chỉ sử dụng PHP khi bạn cần đến nó – Rasmus Lerdorf
Không ai có thể sử dụng PHP thành thạo hơn chính người tạo ra nó. Vào năm 1995, Rasmus Lerdorf đã tạo ra ngôn ngữ lập trình PHP và từ đó ngôn ngữ này nhanh chóng được giới phát triển ứng dụng và làm thay đổi bộ mặt Internet. Tuy nhiên, Rasmus Lerdorf không tạo ra PHP với mục đích đó, PHP được tạo ra nhằm mục đích giải quyết các vấn đề của các nhà lập trình và phát triển ứng dụng we.

And as with many open source projects that have gone on to become popular, the motivation was never philosophical or even narcissistic. It was purely a case of needing a tool to solve real-world Web-related problems. In 1994 the options were fairly limited when it came to Web development tools

Tuy bạn có thể sử dụng PHP cho mọi thứ trên website. Lerdorf là người đầu tiên thừa nhận rằng PHP đơn thuần chỉ là một công cụ trong danh sách các các công cụ bạn sử dụng cho website của mình, và tất nhiên PHP có những hạn chế.

Use the right tool for the job. I have run across companies that have completely bought into PHP, deploying it absolutely everywhere, but it was never meant to be a general-purpose language appropriate for every problem. It is most at home as the front-end scripting language for the Web.

Sử dụng PHP cho mọi thứ trên website là việc làm không hiệu quả, nếu bạn là một nhà phát triển ứng dụng web thì nó không phải là một ngôn ngữ tốt nhất để làm việc. Đừng ngại sử dụng những ngôn ngữ lập trình khác trong dự án của bạn nếu cảm thấy nó tốt hơn cho PHP.

2. Sử dụng nhiều table cho PHP và MySQL cho những cơ sở dữ liệu lớn – Matt Mullenweg
Hầu như không có ai hỏi Matt Mullenweg là ai và tại sao anh ta lại được tôn vinh như một bật thầy của PHP bởi vì anh đã quá nổi tiếng và nhiều người biết đến.

Nếu bạn chưa rõ về Matt Mullenweg tôi có thể trích ngang cho bạn vài dòng thế này: Matt Mullenweg là người phát triển hệ thống blog khá thịnh hành hiện nay: WordPress. Sau khi hoàn thành WordPress, Matt cùng với công ty của mình đã cho ra đời website

http://www.wordpress.com

– một website có thể được liệt vào hàng tinh tú của thế giới mạng và được xây dựng trên code WordPress MU. Đây là một ứng dụng multi blog tốt nhất hiện nay. Vào thời điểm bải viết này được viết, website

http://www.wordpress.com

đang chứa khoảng 4 triệu blog con và mỗi ngày có khoảng 140.000 bài viết được đăng. Bạn có thể xem các thông số mới nhất của nó tại đây.

Vào năm 2006, Matt Mullenweg đã đưa ra những quyết định sáng suốt cho việc thiết kế cấu trúc cơ sở dữ liệu của WordPress và lý giải tại sao WordPress MU sử dụng những table riêng biệt cho mỗi blog thay vì gom chúng lại thành một khối lớn cho tất cả các blog.

We tested this approach for MU, but found it was too expensive to scale past a certain point. With monolithic structures you hit a wall based on your hardware. In MU users are divided and can be partitioned easily, for example on WordPress.com we have the users partitioned between 4096 databases, which allows you to scale very cheaply and efficiently to hundreds of thousands and even millions of users and extremely high levels of traffic.

3. Đừng bao giờ tin vào bản thân bạn và người dùng của bạn – Dave Child

Dave Child là cha đẻ của website Added Bytes (trước đây có tên là ilovejackdaniels.com) với loạt bài viết cheat sheets for many programming languages. Ông đã từng làm việc cho nhiều công ty ở Anh và thiết lập nên uy tín riêng của mình trong cộng đồng giới lập trình viên thế giới.

Dave Child mang đến cho bạn lời khuyên hữu ích trong bài viết writing secure code in PHP: đừng bao giờ tin vào người dùng của bạn (your users). Họ chỉ làm cho bạn tổn thương …

So the cardinal rule of all web development, and I can’t stress it enough, is: Never, Ever, Trust Your Users. Assume every single piece of data your site collects from a user contains malicious code. Always. That includes data you think you have checked with client-side validation, for example using JavaScript. If you can manage that, you’ll be off to a good start. If PHP security is important to you, this single point is the most important to learn.

Dave chỉ cho chúng ta thấy những ví dụ cụ thể về việc bảo mật trong phần một, phần haiphần 3 của loạt bài viết “Writing Secure PHP“.

Finally, be completely and utterly paranoid. If you assume your site will never come under attack, or face any problems of any sort, then when something eventually does go wrong, you will be in massive amounts of trouble. If, on the other hand, you assume every single visitor to your site is out to get you and you are permanently at war, you will help yourself to keep your site secure, and be prepared in case things should go wrong.

4. Đầu tư và nghiên cứu caching – Ben Balbo

Ben Balbo đã viết cho Site Point một bài viết hướng dẫn các developer và các designer.

If you have a busy and predominantly static web site–such as a blog–that’s managed through a content management system, it will likely require little alteration, yet may benefit from huge performance improvements resulting from a small investment of your time. Setting up caching for a more complex site that generates content on a per-user basis, such as a portal or shopping cart system, will prove a little more tricky and time consuming, but the benefits are still clear.

Đây là một vài kỹ thuật cache dữ liệu cho PHP

  • cached function calls
  • setting expiry headers
  • caching file downloads in IE
  • template caching
  • Cache_Lite

Và còn nhiều kỹ thuật khác Ben Balbo chưa đề cập đến.

Vì tính chất của một ngôn ngữ động, cache bị phê phán và chỉ trích vì làm mất đi tính linh hoạt của trang web do ít bị thay đổi nhưng dù sao đi nữa caching cũng là một phương án rất hữu hiệu và được ứng dụng khá rộng trong lập trình website.

5. Tăng tốc độ trang web bằng cách sử dụng một IDE Template và cắt nhỏ ảnh – Chad Kieffer
Khi Chad Kieffer không bận bịu trong các công việc thiết kế giao diện người dùng và quản trị database cho khách hàng, anh thường đưa ra rất nhiều lời khuyên sáng suốt trên blog của mình: 2 tablespoons.
Chad tin rằng sử dụng một bộ IDE như Eclipse PDT (một gói phát triển của Eclipse giành cho PHP) với sự kết hợp các kỹ thuật cắt template và chia nhỏ nó có thể giúp tăng tốc độ tải trang web.

Busy schedules, long to do lists, and deadlines make it tough for developers to get familiar with some of the advanced features their tools provide. This is a shame, because some features, like Eclipse Templates, can really reduce coding time and errors.

Ngụ ý của câu nói trên nói rằng một khi bạn thực hiện một số nhiệm vụ một cách tự động, bạn sẽ cải thiện được thời gian hoàn thành project của mình.Một ví dụ mà dễ thấy là với bạn lưu những đoạn lặp lại trên website lại thành những phần riêng biệt bạn có thể kết hợp, sử dụng lại chúng một cách nhanh chóng mà chẳng tốn thời gian viết lại chúng. Vả lại còn có thể sử dụng lại chúng trong những project khác nữa.

Bằng cách sử dụng các IDE như Eclipse và các gói PDT, bạn có thể nhận ra thời gian thực hiện dự án của bạn được rút ngắn đáng kể. Các IDE sẽ cho phép bạn thực hiện rất nhiều công việc như gộp file, debug, kiểm tra việc thiếu các dấu chấm phẩy (;), một vài IDE còn cho phép bạn thực hiện các tác vụ cao cấp hơn như upload lên hosting.

6. Khiến cho việc dùng PHP trở nên thuận tiện hơn bằng cách sử dụng Filter – Joey Sochacki

While Joey Sochacki có thể không phải là một cái tên nổi tiếng giống như Matt Mullenweg trong cộng đồng PHP, anh ấy chỉ là một nhà phát triển website một cách ngẫu nhiên và chia sẻ kinh nghiệm anh có trong thời gian làm một developer trên blog Devolio của mình.

Filtering data. We all have to do it. Most, if not all of us, despise doing it. However, unbeknown to most are PHP’s filter_* functions, that allow us to do all sorts of filtering and validation. Using PHP’s filter_* functions, we can validate and sanitize data types, URLs, e-mail addresses, IP addresses, strip bad characters, and more, all with relative ease.

Bộ lọc có thể là một thứ gì đó thật xa vời và khó hiểu. Nhưng bạn có thể ghé thăm Blog của Joey Sochacki và với sự giúp đỡ của Joey Sochacki bạn có thể học được cách cài đặt bộ lọc, tìm hiểu những thứ một bộ lọc cần, tìm hiểu nó và cải thiện để tận dụng sức mạnh của PHP.

7. Sử dụng một PHP Framework – Josh Sharp
Hiện vẫn có những cuộc tranh cãi quanh việc sử dụng framework nào giữa Zend, CakePHP, Code Igniter, hoặc những framework khác.
Josh Sharp là một lập trình viên và là một nhà phát triển website cho khách hàng. Đâu là lý do tại sao bạn nên tin Josh khi anh bảo sử dụng framework để tiết kiệm thời gian và hạn chế lỗi khi lập trình ? Josh tin điều đó vì một lẽ đơn giản : PHP rất dễ học.

But PHP’s ease of use is also its downfall. Because there are less restrictions on the structure of the code you write, it’s much easier to write bad code. But there is a solution: use a Framework

Framework có thể giúp bạn chuẩn hóa chương trình, bạn có thể tiết kiệm rất nhiều thời gian trong quá trình xử lý mã nguồn … Bạn có thể đọc thêm lợi ích của việc sử dụng framework tại blog của Josh.

8 Đừng sử dụng Framework – Rasmus Lerdorf

Trái ngược với ý kiến ở trên của Josh ở trên, Rasmus Lerdorf – cha đẻ của PHP lại cho rằng framework không phải là một lựa chọn sáng suốt. Tại sao? Bởi vì nó sẽ làm cho chương trình của bạn biên dịch chậm hơn so với viết code PHP đơn thuần. Trong bài thuyết trình của mình tại Drupalcon 2008 , Rasmus đã so sách tốc độ xử lý của một trang “Hello world !” đơn giản sử dụng framework và không sử dụng framework (slides 24-32) và chỉ ra rằng framework làm cho tốc độ xử lý web page chậm hơn code php trực tiếp.

Bạn có thể xem và nghe toàn bộ bài phát biểu của Rasmus Lerdorf tại đây.

9. Sử dụng bộ xử lý đồng bộ (Batch Processing) – Jack D. Herrington

Theo từ điển Lạc Việt Batch Processing là một chế độ thao tác của máy tính, trong đó các thao tác lệnh của chưng trình được thực hiện liên tiếp nhau mà không có sự can thiệp của người sử dụng máy tính.

Jack D. Herrington không phải là người xa lạ trong cộng đồng PHP và Developer của thế giới. Herrington khuyến khích sử dụng batch processing và cron cho việc xử lý các tác vụ dưới tầng nền hệ thống. Người sử dụng web không muốn phải ngồi đợi quá lâu trong lúc hệ thống tải trang lên. Vì vậy, những thứ không cần thiết phải hiển thị ra ngoài bạn hãy để nó chạy dưới nền ứng dụng.

Certainly, in some small cases, it’s a bit easier to fire off of a helper thread to handle small jobs. But it’s easy to see that with the use of conventional tools — cron, MySQL, standard object-oriented PHP, and Pear::DB — creating batch jobs in PHP applications is easy to do, easy to deploy, and easy to maintain.

Jack tin rằng thay vì sử dụng các tiến trình trên server, để đơn giản hơn có thể sử dụng kết hợp cron, PHP và MySQL để xử lý các ứng dụng nền.

I’ve done both, and I think cron has the advantage of the “Keep It Simple, Stupid” (KISS) principle. It keeps the background processing simple. Instead of having a multithreaded job-processing application that runs forever and, thus, can never leak memory, you have a simple batch script that cron starts. The script determines whether there’s anything to do, does it, then exits. No need to worry about memory leaks. No need to worry about a thread stalling or getting caught in an infinite loop.

10.Bật chức năng Error Reporting – David Cummings

David Cummings điều hành công ty phần mềm của mình với một CMS đặc trưng và đã đạt được rất nhiều giải thưởng. Nếu nói về một người phát triển ứng dụng PHP thành công nhất, có lẽ đó là David.

David đã viết một vài viết trên SitePoint về Hai lời khuyên cho những người muốn học PHP. Một trong hai lời khuyên là “Turn on error reporting immediately“

The single most important thing I tell people who use PHP is to turn error reporting to its maximum level. Why would I want to do this? Generally the error reporting is set at a level that will hide many little things like:

  • declaring a variable ahead of time,
  • referencing a variable that isn’t available in that segment of code, or
  • using a define that isn’t set.

Error Reporting giúp bạn tìm kiếm các lỗi lập trình trong quá trình thực hiện project dễ dàng hơn. Rất nhiều lỗi nhỏ của PHP dễ dàng được tìm thấy với mô tả lỗi giúp bạn dễ dàng khắc phục nó hơn.

Dịch bởi : babyinternet – nhanweb.com

Sáng tạo góc học tập cho bé

Tháng Chín 15, 2008

Năm học mới đã đến, bạn đã làm gì để giúp bé tăng thêm phần hứng thú trong học tập?

Một chiếc bàn xinh xắn, chiếc giá sách ngăn nắp và những vật trang trí đầy màu sắc vui nhộn sẽ giúp bé càng thêm quý mến thế giới nhỏ của mình đấy. Tinh mắt và khéo léo một chút, những khoảng trống trong nhà bạn sẽ biến thành một góc học tập đáng yêu cho bé con của mình.
Sau những cánh cửa khép kín:
Căn buồng đựng đồ nhà bạn lâu nay vẫn bỏ trống hoang phí, hãy thử dọn dẹp sạch sẽ, sơn phết màu sắc tươi sáng, biến ngăn dưới thành chiếc bàn xinh cho bé và ngăn trên thành kệ sách (chú ý độ cao cho phù hợp với bé). Sắm thêm cho bé chiếc tủ có ngăn kéo và một vài chiếc hộp đựng đồ màu sắc sặc sỡ để bé cất giữ những vật dụng cá nhân. Trên tường có thể treo thêm tấm bảng ghi chú, hộp thư hay những khung hình ngộ nghĩnh.

Những hốc tường biết nói:
Một hốc tường nhỏ sẽ là một góc học tập lý tưởng cho bé yêu của bạn. Ánh sáng là yếu tố cần được lưu ý đầu tiên. Ngoài chiếc đèn bàn, bạn nên lắp thêm đèn ở kệ sách phía trên giúp tăng cường ánh sáng. Có thể gắn thêm tấm màn để che máy vi tính và những vật dụng khác khi không sử dụng.

Lối vào rộng rãi:
Đặt một chiếc bàn ở gốc tường, chân bàn nên gắn thêm bánh xe để có thể di chuyển đến những nơi thuận tiện. Bố trí thêm chiếc bảng treo tường để bé ghi chú những gì tùy thích.

Hành lang bên ngoài phòng ngủ:
Kê chiếc bàn ngay sát tường và gắn thêm tủ phía trên để chứa đồ. Không quên cung cấp lượng ánh sáng cần thiết cho bé.

Nơi không thẳng đứng:
Tận dụng một mảng tường ngắn như ở căn gác mái hay dưới gầm cầu thang cho một chiếc bàn được đóng liền vào tường. Lắp đầy bức tường với những ngăn kệ có kích thước phù hợp với độ nghiêng. Nếu bé thích một không gian riêng, bạn có thể bố trí thêm cửa bên ngoài.

Không gian ảo:
Khách đến nhà sẽ khó mà nhận ra chiếc bàn học của bé trong căn phòng này. Một chiếc bàn nhỏ được gắn chặt với bức tường và được sơn phết những họa tiết trông giống như thế giới trò chơi của bé. Những chiếc chân bàn giả sẽ góp phần cho căn phòng thêm nét tinh nghịch.

Chung mà riêng:
Sẽ không có gì khó khăn khi thiết kế góc học tập riêng cho bọn trẻ nhà bạn, dù ở chung phòng nhưng trẻ con luôn thích có bàn học riêng của mình hơn. Hãy thử tận dụng khoảng không ở 2 đầu chiếc giường đôi để tạo cho trẻ thế giới riêng của mình. Mỗi góc học tập cũng cần được trang bị đầy đủ, vấn đề ánh sáng vẫn luôn được ưu tiên hàng đầu, chiếc bàn xếp, chiếc kệ ngay góc hay tấm bảng treo tường sẽ là lựa chọn thích hợp.

Bàn phấn ngọt ngào của bé:
Cho những bé gái thích làm duyên, hãy thử kết hợp bàn học và bàn trang điểm làm một. Đặt bàn học nối giữa 2 kệ tủ và treo thêm tấm gương ở giữa cùng với những vật dụng cần thiết, vậy là bé gái nhà bạn đã vừa có thể sử dụng để chăm chút cho mình trước khi đến trường vừa là nơi học tập lý tưởng mỗi khi tan trường về.

Theo Thụy Vũ

DiaOcOnline.vn/ BHG

Góc học tập cho trẻ

Tháng Chín 15, 2008

Năm học mới sắp đến, các bậc phụ huynh lại chuẩn bị đưa con cái đến trường, nhưng cũng không vì thế mà bỏ qua việc chăm sóc góc học tập ở nhà cho các cục cưng của mình. Chúng ta thử xem qua vài phương án thiết kế này nhé.

Màu sắc luôn là thứ khiến cho các bé thích thú. Vì thế việc trang trí góc học tập cho con của bạn cũng cần chú ý điểm này. Ngoài việc thiết kế độ cao và rộng hợp lý cho bàn ghế, bạn nên có một giá sách và đồ trang trí cho bé yêu.

Góc học tập sinh đôi đơn giản nhưng đầy cá tính

Gam màu đỏ vàng kích thích sự sáng tạo, sẽ giúp trẻ học tập hiệu quả hơn

Nếu bé gái của bạn ưa thích sự dịu dàng thì gam màu trắng – xanh là một giải pháp tốt

Và góc học tập cho những cậu bé hiếu động

Nếu các bé của bạn gần tuổi nhau, sao không tạo góc học tập chung

điều đó sẽ kiến chúng gắn kết với nhau hơn

Nếu cô bé, cậu bé của bạn có nhiều sách vở, bạn hãy phân loại chúng

bằng những chiếc giỏ xinh này. Trông thật gọn gàng và đáng yêu.

Với những đứa trẻ có thiên hướng nghệ thuật, hội hoạ, sáng tạo thì bạn

hãy để cho chúng tự do phát triển khả năng của mình.

Không gian sáng tạo cho những cậu bé thông minh, thích tìm tòi và khám phá

Một góc nhỏ đơn giản và đáng yêu cho các bé gái

Nguồn: Ngôi sao

Theo dõi

Get every new post delivered to your Inbox.