NHỮNGBÀI HỌC TỪ THỰC TIỄN
Cho tớibây giờ, hầu hết các công ty, tổ chức có liên quan tớiviệc phát triển phần mềm tự do nguồn mở (PMTDNM) tạiViệt Nam đều thực hiện việc phát triển, tùy biến cácPMTDNM có nguồn gốc của thế giới, dựa vào kho mã nguồncủa thế giới, mà cụ thể hơn là dựa vào các kho mãnguồn PMTDNM của một cộng đồng, do một quỹ và/hoặc(các) công ty có trách nhiệm duy trì một PMTDNM cụ thểnào đó.
Trong quátrình tùy biến và/hoặc phát triển dựa vào các kho mãnguồn được nhập vào từ bên ngoài, các công ty, tổchức phát triển các PMTDNM tại Việt Nam thường gặpphải một số khó khăn trong việc duy trì, nâng cấp vàđồng bộ kho mã nguồn của riêng mình tạo ra khi tùybiến và hoặc bổ sung thêm mới (các) chức năng choPMTDNM gốc ban đầu. Một trong những lý do cơ bản tạora những khó khăn đó nằm ở chỗ các công ty, tổ chứcphát triển đã không đóng góp các mã nguồn tùy biếncủa mình trở ngược lại về dự án gốc ban đầu, tạora những khác biệt ngày càng lớn, ngày càng xa về tínhnăng và/hoặc tiêu chuẩn của PMTDNM dẫn xuất của chínhcông ty, tổ chức mình so với PMTDNM gốc ban đầu. Tớilượt chúng, theo thời gian, sự khác biệt này tạo ranhững khó khăn cho chính các công ty, tổ chức phát triểnmà trong một số trường hợp là rất khó và/hoặc khôngcòn có khả năng để tích hợp kho mã nguồn của PMTDNMdẫn xuất của riêng công ty, tổ chức phát triển vớikho mã nguồn của PMTDNM gốc ban đầu được nữa.
Mộtvài ví dụ điển hình cho việc này như:
Khi bạn phát triển một trình điều khiển thiết bị cho nhân Linux mà không có đóng góp mã nguồn của bạn ngược trở lại cho dự án phát triển nhân Linux của thế giới, thì cứ mỗi lần có phiên bản nhân Linux mới phát hành thì bạn có thể phải viết lại hoàn toàn và/hoặc sửa lại nhiều đống mã nguồn mà bạn đã viết và đã chạy được tốt với phiên bản nhân cũ. Vì nhân Linux hiện nay cứ khoảng 70 ngày lại có một phiên bản nhân mới được phát hành, nên có thể chính lý do này làm nản lòng bạn khi liên tục phải viết lại và/hoặc sửa lại đống mã nguồn của trình điều khiển thiết bị mà bạn viết cho nhân Linux.
Khi bạn phát triển một module có tính địa phương của quốc gia bạn, ví dụ như bộ gõ tiếng Việt, mà không có đóng góp mã nguồn của module đó ngược trở lại cho cộng đồng, công ty và hoặc quỹ có trách nhiệm duy trì phát tán gốc ban đầu mà bạn và cộng đồng địa phương sử dụng hàng ngày, ví dụ như Ubuntu hay Fedora chẳng hạn. Nhiều công ty, tổ chức của Việt Nam chúng ta chắc còn chưa quên khi từng phải tích hợp module bộ gõ tiếng Việt của mình mỗi khi có phiên bản mới của các phát tán như Ubuntu, Fedora được phát hành vài năm về trước.
Khi bạn tiến hành công việc bản địa hóa cho các ứng dụng, tiện ích PMTDNM, ví dụ cụ thể như OpenOffice, LibreOffice, GNOME, KDE, Mozilla Firefox... mà không đóng góp các bản dịch đó ngược trở lại về từng dự án gốc có xuất xứ từ bên ngoài đó, thì có khả năng mỗi lần có phiên bản mới, bạn sẽ phải dịch lại từ đầu, hoặc tệ hơn nữa, là không có luôn ngôn ngữ của quốc gia bạn.
Nói rộng ra, khi bạn tiến hành phát triển bất kỳ PMTDNM nào mà không có đóng góp trở ngược lại cho cộng đồng, chắc chắn bạn sẽ gặp khó khăn lớn cho chính sản phẩm dẫn xuất mà bạn đang dựa vào PMTDNM gốc để phát triển.
GIỚITHIỆU VỀ NGƯỢC LÊN DÒNG TRÊN
Ngượclên dòng trên là một khái niệm được sử dụng để môtả qui trình đóng góp những sửa đổi mã nguồn trongnội bộ trở ngược lại cho một dự án nguồn mở, vớimục tiêu để chúng được chấp nhận và được phânphối trong các phát hành trong tương lai của dự án. Nộidung của bài này đưa ra qui trình ngược lên dòng trên,những lợi ích cho tất cả các bên có liên quan (các côngty, các dự án, hệ sinh thái nguồn mở), và nhấn mạnhtới một số thực tiễn tốt nhất để đi theo.
Ngượclên dòng trên là một khía cạnh cơ bản của qui trìnhphát triển nguồn mở. Trong nguồn mở, điều này thườngđược sử dụng để mô tả qui trình nơi mà một cánhân hoặc một công ty sửa đổi mã nguồn của một dựán nguồn mở cho phù hợp với một nhu cầu cụ thể, vàsau đó đóng góp những sửa đổi của họ trở ngượclại cho dự án.
PMTDNMđang ngày càng được tích hợp vào trong các sản phẩmthương mại, được dẫn dắt bằng giá trị kỹ thuật,khả năng tăng tốc sự phát triển, hoặc để cải thiệnthời gian đi tới thị trường. Kết quả là, nhiều côngty cũng đang tùy biến, sửa đổi PMTDNM để đáp ứngđược những yêu cầu của các khách hàng. Các tổ chứcphát triển mà còn chưa ôm lấy một cách đầy đủ sựtham gia tập thể của nguồn mở có thể duy trì nhữngnhánh nội bộ riêng rẽ của những dự án đó, vì nó cóthể là một cách dễ dàng để bắt đầu khi tiêu dùngPMTDNM.
Trongkhi các cây phát triển trong nội bộ một cách riêng rẽcó thể là bước khởi đầu cho sự phát triển của mộtsản phẩm hoặc để chứng minh khái niệm, thì sự duytrì dài hạn có thể nhanh chóng trở thành đắt giá. Điềunày đặc biệt đúng nếu PMTDNM sẽ được cập nhậtthông qua vòng đời của sản phẩm, khi mã nguồn tùy biếnsẽ cần phải được thích nghi với những thay đổitrong dự án nguồn mở dòng chính. Vì các lập trình viêntrong các dự án nguồn mở có thể nhận thức được vềnhững sửa đổi đang được thực hiện cho mã nguồnđược phát hành của họ đằng sau những cánh cửa đóng,thì sẽ không có sự đảm bảo nào rằng sự phát triểnthường lệ sẽ không phá vỡ các dẫn xuất nội bộ củamã nguồn đó.
Đểnhận thức được đầy đủ những lợi ích của việctiêu dùng PMTDNM, nhiều công ty đang chọn đi theo mộttriết lý “ngược lên dòng trên trước”. Điều này cónghĩa rằng những sửa đổi nội bộ sẽ được đánhgiá để được chấp nhận đưa vào trong cây phát triểnchính.
Bài viếtnày mô tả một qui trình điển hình cho việc ngược lêndòng trên cho mã nguồn nội bộ, trình bày những lợi íchcủa ngược lên dòng trên và đưa ra chỉ dẫn thực tếvà những thực tiễn tốt nhất.
QUITRÌNH NGƯỢC LÊN DÒNG TRÊN
Ngượclên dòng trên là qui trình đóng góp mã nguồn được pháttriển một cách độc lập hoặc nội bộ trở ngược lạicho dự án nguồn mở gốc ban đầu, với mục tiêu làmcho nó được tích hợp vào trong cây phát triển chính củadự án nguồn mở. Trong khi từng dự án nguồn mở có tậphợp các qui trình và các tiêu chí chấp nhận của riêngmình, thì việc tuân theo qui trình chung được minh họatrong Hình 1 có thể cải thiện được khả năng rằng sựđóng góp của bạn sẽ được đánh giá hoặc có thểđược chấp nhận trong một cây phát triển chính của dựán nguồn mở.
Hình 1:Qui trình điển hình cho việc xác định và ngược lêndòng trên cho mã nguồn nội bộ.
Qui trìnhđược bắt đầu trong một tổ chức phát triển bằngviệc giành được sự phê chuẩn nội bộ để đóng gópnhững sửa đổi trở ngược lại cho dự án bằng việctuân thủ các chính sách và thủ tục nguồn mở của côngty. Tiếp sau, hãy xác định những sửa đổi nội bộđang được thực hiện cho PMTDNM mà có thể được đệtrình trở ngược lại cho dự án, và xác định nhữngsửa đổi nào là những ứng viên phù hợp cho việc ngượclên dòng trên. Khi mã nguồn tương ứng đã được xácđịnh, hãy lên kế hoạch cho một chiến lược đệtrình, đặc biệt nếu mã nguồn là một đệ trình lớn,là phức tạp, hoặc có một tác động chủ chốt lên dựán. Mục tiêu là để tránh việc lấn át người duy trìcủa dự án và những người tham gia dự án với một đệtrình lớn mà là khó để hiểu, kiểm thử và/hoặc tíchhợp.
Tiếptheo, hãy đảm bảo không có những phụ thuộc vào mãnguồn riêng, nội bộ. Nếu có, thì chúng phải đượcgiải quyết trước khi có việc đệ trình mã nguồn chodự án. Hơn nữa, hãy chắc chắn rằng những sửa đổikhông tình cờ tạo ra bất kỳ rủi ro nào về an ninh hoặcphá vỡ mã nguồn khác.
Hãychuẩn bị mã nguồn để đệ trình, đảm bảo rằng nósử dụng kiểu dạng bản vá và lập trình của dự án,và hãy kiểm tra tính hợp lệ mà nó áp dụng một cáchsạch sẽ đối với cây mã nguồn của dự án. Hãy táchbạch mã nguồn trong các phần logic nhỏ nhất có thể,như với bất kỳ sự đóng góp nguồn mở nào khác, vàsau đó tuân theo qui trình đệ trình của dự án.
Sự đệtrình thường bắt đầu với một thảo luận trong danhsách thư của dự án. Hãy đề xuất các đóng góp, hỏivề những khuyến cáo, trả lời những câu hỏi, và đánhgiá khả năng được chấp nhận từ những câu trả lời.Nếu sự tích hợp là phức tạp, thì hãy giao tiếp vớingười duy trì qua danh sách thư của dự án và hỏi tưvấn về cách xử lý. Một khi mã nguồn được chấpnhận, hãy tiếp tục duy trì nó bên trong dự án, và làmviệc với những người khác để cải thiện chức năngđó.
Điềuquan trọng phải nhớ rằng mỗi dự án có thể khác nhautrong cách mà mã nguồn được đệ trình, được kiểmthử và được chấp nhận. Nếu qui trình đó là không rõràng, hãy yêu cầu trợ giúp và giám sát các danh sách thưcủa dự án đối với các công ty khác đang làm thứ yhệt, và xử lý tương tự theo.
NHỮNGLỢI ÍCH CỦA NGƯỢC LÊN DÒNG TRÊN
Mãnguồn được chấp nhận ngược lên dòng trên đưa ra vàilợi ích cho dự án nguồn mở, cho các công ty đệ trìnhmã nguồn tới các dự án dòng trên, và cho hệ sinh tháinguồn mở nói chung.
Dướiđây là một danh sách các ưu điểm của việc ngược lêndòng trên.
1. Ít mã nguồn hơn phải duy trìtrong nội bộ. Mộtkhi mã nguồn trong nội bộ trở thành một phần của câymã nguồn chính, thì nỗ lực cần thiết để duy trì mãnguồn còn lại có thể thấp đi đáng kể, vì kho mãnguồn nội bộ là nhỏ hơn. Hơn nữa, mã nguồn đã đượcngược lên dòng trên sẽ tiến hóa với dự án, làm giảmđi khối lượng các nỗ lực được yêu cầu nhằm duytrì một cây phát triển song song.
2. Nhiều người đóng góp hơn.Khimã nguồn được chấp nhận ngược lên dòng trên, thì nótrở thành một phần nhìn thấy được của dự án. Điềunày cho phép những lập trình viên khác đóng góp cho nó,đệ trình những tính năng mới, mở rộng chức năng hiệncó và kiểm thử nó.
3. Chất lượng mã nguồn tăng qua sựrà soát lại ngang hàng. Mãnguồn được đệ trình cho một dự án nguồn mở thườngnhận được sự rà soát lại ngang hàng đáng kể như mộtphần của qui trình đệ trình thông thường. Điều nàycó được trong một chu trình đóng góp ý kiến phản hồidẫn tới sự cải thiện của mã nguồn, và cuối cùng mãnguồn chất lượng cao hơn sẽ được sử dụng trong cácsản phẩm thương mại.
4. Tích hợp và kiểm thử nhanh hơn.Việcngược lên dòng trên làm đơn giản hóa và tăng tốc choqui tình tích hợp PMTDNM hoặc các cập nhật mới. Khi việcduy trì một cây phát triển riêng rẽ (Hình 2), thì chutrình tích hợp có thể bị chậm vì sự tích hợp, kiểmthử và gỡ rối các lỗi không được dự kiến trướcđòi hỏi phải duy trì mã nguồn trong nội bộ. Nếu nhữngthay đổi trong dự án ngược lên dòng trên đã đứt đoạnvới mã nguồn trong nội bộ, thì trách nhiệm của cáclập trình viên trong nội bộ phải sửa và kiểm tra bấtkỳ sự đứt đoạn nào trước khi sản phẩm đó có thểđược xuất ra ngoài. Vì mã nguồn ngược lên dòng trênđã trở nên nhìn thấy được đối với phần còn lạicủa dự án, nên khả năng của những đứt đoạn khôngđược dự kiến trước đó sẽ giảm.
Hình 2:Xem ở mức cao đối với một qui trình phát triển điểnhình: Sự thích nghi trong nội bộ của mã nguồn riêng cóthể dẫn tới các chu trình phát triển dài hơn.
Ngượclên dòng trên có thể giúp tránh được những đứt đoạnđó trong mã nguồn, vì những tính năng ngược lên dòngtrên sẽ được kiểm thử trong dự án dòng chính, và bấtkỳ vấn đề nào cũng sẽ được thấy và được sửatrước khi có một phát hành dự án. Hơn nữa, chỉ mộtlượng mã nguồn nhỏ hơn sẽ cần thiết phải đượcduy trì trong nội bộ, làm giảm lượng mã nguồn tùy biếnđược duy trì một cách tách biệt có thể làm nhẹ bớtđáng kể những nỗ lực tái tích hợp.
Hình 3:Qui trình phát triển tương tự với việc ngược lên dòngtrên để làm giảm sự thích nghi trong nội bộ, làm chocác chu trình phát triển ngắn hơn và thời gian đưa rathị trường nhanh hơn.
5. Tác động tới đường lối củadự án. Đốivới các công ty dựa vào PMTDNM để xây dựng một sảnphẩm, mã nguồn ngược lên dòng trên là một cách thứchiệu quả để đưa ra sự lãnh đạo kỹ thuật bên trongmột dự án, khi nó có thể chỉ dẫn đường lối củadự án và đảm bảo giữ gìn được sự bền vững. Sựtương tác với những người tham gia dự án ở bên ngoàicũng có thể làm tăng khả năng những người khác sẽnhận thức được về các nhu cầu của công ty, và họcó thể có khả năng hơn để giúp triển khai những tínhnăng và chức năng mới nếu họ có quan tâm tới chúng.
6. Giảm các chi phí đạt được sựtuân thủ. Sựtuân thủ giấy phép là một khía cạnh sống còn của bấtkỳ chiến lược tiêu dùng nguồn mở nào. Việc ngượclên dòng trên làm giảm lượng mã nguồn nội bộ phảiđược theo dõi một cách độc lập từ dự án nguồn mởcha.
Để cóthêm thông tin về sự tuân thủ, xin hãy tới thăm Chươngtrình Tuân thủ Mở của Quỹ Linux tại:http://www.linuxfoundation.org/programs/legal/compliance.Chương trình này đưa ra một số nguồn tàinguyên để giúp các công ty đạt được sự tuân thủmột cách có hiệu quả.
7.Giảm các rủi ro của chuỗi cung ứng. Nhữngđóng góp ngược lên dòng trên còn làm được nhiều hơnlà giảm những nỗ lực phát triển và tích hợp và cácchi phí cho người đệ trình. Chúng còn có thể là biệnpháp có hiệu quả để đảm bảo sự ổn định trong mộtchuỗi cung ứng nguồn mở của công ty.
Việckết hợp phần mềm ở bên ngoài trong một sản phẩm đòihỏi một sự tập trung thận trọng về tính ổn địnhcủa chuỗi cung ứng phần mềm. Những đóng góp ngượclên dòng trên có thể bù đắp cho những rủi ro từ đườnghướng hoặc tính bền vững của dự án, vì những đónggóp mã nguồn có thể đưa ra một ảnh hưởng tích cựctrong đường hướng của dự án. Bằng việc đưa ra chỉdẫn thông qua những đệ trình mã nguồn, một công ty cóthể đảm bảo rằng những phiên bản trong tương lai củaPMTDNM sẽ tiếp tục cung cấp được giá trị cho qui trìnhphát triển của họ.
8. Tăng cường cho dự án.Nhữngđóng góp ngược lên dòng trên giúp đưa ra sự ổn địnhcho dự án nguồn mở vì chúng là một dấu hiệu rõ ràngrằng dự án là hữu dụng và quan trọng. Sự hỗ trợmạnh mẽ từ các công ty đóng góp có xu hướng thu hútđược những người tham gia khác, làm gia tăng tiếp tụctính bền lâu của dự án.
NHỮNGTHỰC TIỄN TỐT NHẤT CỦA NGƯỢC LÊN DÒNG TRÊN
Cónhiều cách thức để đóng góp cho những thay đổi ngượclên dòng trên cho một dự án nguồn mở. Điều sau đâyđược khuyến cáo như là những điểm khởi đầu:
1.Thiết kế và triển khai mã nguồn với ngược lên dòngtrên trong đầu
Khôngphải tất cả những sửa đổi là phù hợp cho sự đónggóp trở ngược lại cho một dự án. Ví dụ, mã nguồnvới những phụ thuộc sở hữu độc quyền sẽ không thểđược giải quyết một cách tự do, mã nguồn với nhữngvấn đề về an ninh hoặc tính ổn định, hoặc mã nguồnmà không được xây dựng trong các công cụ nguồn mởtiêu chuẩn tất cả có thể sẽ là có vấn đề khi đệtrình.
Nhữngcải tiến chức năng cải thiện mã nguồn gốc ban đầuđể làm cho nó ổn định hơn, hiệu năng tốt hơn, hoặcmềm dẻo hơn có xu hướng sẽ là những ứng viên tốthơn. Chúng có thể thường được đóng góp mà không cóviệc gây rủi ro cho các nguồn của các ưu điểm cạnhtranh, và có thể sẽ có được sự cuốn hút rộng rãihơn vượt ra ngoài các lập trình viên của riêng mộtcông ty. Điều này là lý tưởng cho dự án, khi nó khôngchỉ cải thiện được tập hợp các tính năng, mà còncho người đệ trình, khi mà nó làm gia tăng khả năngnhững người khác sẽ giúp duy trì mã nguồn được đónggóp đó.
2. Đảm bảo sự đóng góp là hữudụng đối với những người khác. Nhữngngười duy trì của dự án thường nhìn vào số lượngnhững người sử dụng cho một tính năng được đónggóp. Mã nguồn mà cải thiện được chức năng của dựán đối với một số lượng rộng lớn những người sửdụng thường được ưu tiên hơn mã nguồn với khả năngáp dụng bị hạn chế.
3. Hãy luôn tham gia trong sự pháttriển ngược lên dòng trên. Việcduy trì mã nguồn ngược lên dòng trên chỉ giống nhưviệc duy trì bất kỳ sự đệ trình nào khác cho một dựán nguồn mở. Trong khi những người khác có thể đónggóp những thay đổi và những sửa lỗi, thì họ không cótrách nhiệm phải làm thế. Hãy lên kế hoạch để giữcác nhân viên đã tham gia vào sự phát triển mở, đặcbiệt trong quá trình chuyển tiếp ngược lên dòng trên.Có thể mất thời gian để xây dựng một đơn vị nhữngngười đóng góp từ bên ngoài.
4. Cung cấp tài liệu. Hãylập tài liệu cho mã nguồn một cách bao quát, và đưa ranhững trường hợp điển hình và các chứng minh kháiniệm, đặc biệt nếu tính năng mới là phức tạp. Nếumục tiêu là để tuyển mộ các lập trình viên từ bênngoài để bù đắp sau này cho các chi phí phát triểntrong nội bộ, hãy làm cho nó dễ dàng đối với họ đểhiểu được cách mà tính năng đó được sử dụng.
5. Ngược lên dòng trên vì những lýdo đúng đắn. Việcngược lên dòng trên không phải là một chiến lược từbỏ mã nguồn, trừ phi công ty đã được cam kết rồivới một cộng đồng ở bên ngoài có thiện chí để duytrì nó. Mã nguồn không được duy trì thường bị loạibỏ khỏi một dự án khi nó trở nên rõ ràng không có aicó thiện chí sửa các vấn đề.
6.Lắng nghe các ý kiến phản hồi, và hành động dựa vàođó
Khiđệ trình mã nguồn nội bộ ngược lên dòng trên, điềuquan trọng phải có trách nhiệm đối với những ý kiếnphản hồi và những câu hỏi, khi những lập trình viênvà những người duy trì khác có thể không quen thuộc vớinhững động lực tiến hành những thay đổi đó. Hãy sẵnsàng chuẩn bị và trả lời những câu hỏi, và giảithích cơ sở của tính năng đó.
Nhữngý kiến phản hồi ngay thẳng bộc trực và sự rà soátlại ngang hàng là nền tảng cho mô hình phát triển nguồnmở. Nếu một người duy trì yêu cầu những thay đổiđối với sự đệ trình để làm cho nó tương thích đượchơn với dự án cha, hãy đánh giá và triển khai ý kiếnphản hồi đó. Đi theo sự dẫn dắt của người duy trìcủa dự án có thể đòi hỏi những sửa đổi cho sự đệtrình, nhưng sẽ làm gia tăng khả năng những người kháctham gia dự án sẽ giúp duy trì mã nguồn trong tương lai.
7. Tuân theo kiểu lập trình phù hợp.Nhiềudự án có những chỉ dẫn tiêu chuẩn cho cách mà mãnguồn sẽ được định dạng và được đệ trình. Mộtsố dự án cũng có chỉ dẫn rất cụ thể về cách màmã nguồn nên được cấu trúc. Điều quan trọng phảiđảm bảo rằng những đóng góp ngược lên dòng trênkhớp được với những chỉ dẫn đó, vì sự không tôntrọng có thể dẫn tới một sự từ chối từ ngườiduy trì của dự án.
8. Tuân theo các qui trình được thiếtlập của dự án. Hầuhết các dự án nguồn mở đã chi tiết hóa những chỉdẫn cho việc đệ trình các bản vá và qui trình rà soátlại. Những qui trình này thường được thực hiện mộtcách nghiêm túc, và những đệ trình cho dự án phải tuântheo chúng sát sao. Chủ đề này được đề cập tới chitiết hơn trong một xuất bản phẩm khác của Quỹ Linux,“Hiểubiết về mô hình phát triển nguồn mở”.
Kếtluận
Bàiviết này đã trình bày khái niệm về ngược lên dòngtrên, một khía cạnh cơ bản của qui trình phát triểnnguồn mở. Việc ngược lên dòng trên là qui trình củaviệc đệ trình những sửa đổi trong nội bộ đối vớiPMTDNM ngược trở lại cho dự án để đưa vào trong câyphát triển chính. Qui trình này có thể giảm được đángkể các chi phí bằng việc giảm thiểu mã nguồn đượcduy trì trong nội bộ. Bằng việc tuân thủ các thực tiễntốt nhất và làm việc bên trong các qui trình của dựán, việc ngược lên dòng trên có thể làm cho các chi phíduy trì thấp hơn, sự phát triển các tính năng nhanh hơnvà các sản phẩm tốt hơn.
Cùngtrong loại bài này, chúng ta đã đi qua các bài: (1) Tìmhiểu mô hình phát triển phần mềm tự do nguồn mở;(2) Vòngđời tính năng và những đặc tính của mô hình pháttriển nguồn mở;kỳ sau chúng ta sẽ đề cập tới việc thiếtlập chiến lược phần mềm nguồn mở để có thể từngbước áp dụng được mô hình phát triển của nó vàotrong công việc hàng ngày của công ty và/hoặc tổ chức.
TrầnLê
Bàiđăng trên tạp chí Tin học và Đời sống số tháng05/2012, trang 64-68.
Ý kiến bạn đọc
Những tin mới hơn
Những tin cũ hơn
Blog này được chuyển đổi từ http://blog.yahoo.com/letrungnghia trên Yahoo Blog sang sử dụng NukeViet sau khi Yahoo Blog đóng cửa tại Việt Nam ngày 17/01/2013.Kể từ ngày 07/02/2013, thông tin trên Blog được cập nhật tiếp tục trở lại với sự hỗ trợ kỹ thuật và đặt chỗ hosting của nhóm phát triển...