Nhiều chuyện để nói...

Không biết từ khi nào tôi đã đọc được những dòng tâm sự của chính tác giả Unikey và hiện tại tôi cũng đang làm việc liên quan đến nguồn mã mở và giải pháp tích hợp mở. Tôi cũng như anh Long nhận được nhiều ý kiến thật bất công và không có nhã nhặn cho lắm, nhưng cuộc đời mà: "Cuộc đời có rất nhiều bất công nhưng cũng chính từ đó tạo nên công bằng".

Đã quá lâu rồi tôi không dùng Windows - một hệ điều hành khá phổ biến và thân thuộc với chúng ta mà thay vào đó tôi dùng Ubuntu, với tôi Ubuntu thật tuyệt vời, nó giúp tôi giải quyết các công việc thường ngày, giúp tôi phát triển chương trình mà tôi thích và đặt biệt thích hợp với những người không có đủ điều kiện để trang trải chi phí bản quyền sản phẩm như tôi. Tôi thầm cảm ơn những nhà phát triển phần mềm miễn phí và phần mềm nguồn mã mở vì chính họ đang tạo nên một thế cân bằng trên thế giới này.

Tôi cũng như công ty nơi mà tôi đang làm việc đang phát triển những dự án với chi phí cực thấp và dự án nguồn mã mở với một mục tiêu đáp ứng phần lớn nhu cầu của những người dân mà nói đúng hơn là người nông dân cơ cực đang dãi dầu mưa nắng trên cánh đồng, nơi những vùng núi đồi xa xôi, nơi mà những trẻ thơ ngày ngày đang làm việc mà quên rằng với cái tuổi của mình, các em cùng bạn bè mình đang "ê a" tập đọc, đang nắn nót viết những chữ đầu đời và đang tiếp thu những kiến thức trên toàn thế giới đang ngày càng "phẳng" đi. Nhưng chúng tôi gặp một trở ngại lớn đầu tiên trên những bước đường của mình vì những nhận thức không đúng về phần mềm nguồn mở và phần mềm miễn phí. Phần đông những người cho rằng phần mềm nguồn mở kém chất lượng, phần khác cho rằng phát triển phần mềm trên nguồn mã mở là không làm gì ngoài việc lấy "nguồn mã" và tự biên dịch ra cái của mình. Vâng, họ nói đúng phần phát triển nguồn mã mở là lấy "nguồn mã" và tự biên dịch ra cái của mình nhưng vẫn sai lầm và thiếu sót vì nhà sản xuất phải lấy "nguồi mã", "sửa đổi", "mở rộng", "tích hợp", "kiểm tra chất lượng" và "xuất bản" phần mềm của mình, với quy trình đó công của nhà sản xuất đã để vào rất nhiều và họ phải làm một việc rất quan trọng và làm cho phần mềm phải thân thiện, dễ dùng và đáp ứng nhu cầu của người dùng. Một nhận xét sai về phần mềm nguồn mở là "kém chất lượng", vì rằng phần lớn phần mềm nguồn mở có tính hướng cộng đồng và tính đáp ứng rất cao vì họ cho phép người dùng phát triển thêm những tính năng mới đáp ứng yêu cầu của mình, do đó về mặt kiến trúc phần mềm nguồn mở phải dễ dàng mở rộng, dễ dàng tích hợp và chất lượng ngày càng tốt, một ví dụ điển hình là "OpenOffice" và "Ubuntu" có mặt trong "top 100" những phần mềm máy tính được ưa chuộng nhất. Như vậy thì phần mềm mã nguồn mở và phần mềm miễn phí phải chăng là "kém chất lượng" và nhà sản xuất sản phẩm phần mềm dựa trên nguồn mã mở là "không làm gì"?

Phần mềm nguồn mã mở và phần mềm miễn phí đã tạo nên một bất công cho các nhà sản xuất sản phẩm hướng thương mại, nhưng nó đã tạo nên một sự công bằng đối với tôi, đối với những người dân các nước đang phát triển và chưa phát triển!

Một thực tế cũng khiến không ít người băn khoăn và cũng nhiều lần tự hỏi là: "Liệu chúng ta có tự hào dân tộc không nhỉ?". Tôi dám chắc với các bạn là có nhưng họ đang từ hào về quá khứ hào hùng mà thôi!, Tôi nói sai ư? Vậy xin trích cho các bạn một số thí dụ nha:

1. Ai cũng biết bóng đá là môn thể thao vua, và đội bóng chúng ta không ít lần thắng trước những đối thủ lớn, ví như hôm nay trước UAE chúng ta vẫn thắng 2-0, vâng bao nhiêu bài báo ca ngợi chiến tích hào hùng của các chàng trai nhưng đã không ít lần họ lại bị chê bai thiếu đường "tìm đất chui xuống". Vậy là tự hào sao ???
2. Ai cũng biết vụ nước tương có chất gây ung thư và ngay sau đó họ tẩy chay không dùng nước tương, nhưng ai cũng biết những món hàng từ Trung Quốc có rất nhiều chất gây ung thư mà các báo chí trong nước cũng như ngoài nước đăng tin, nhưng họ vẫn dùng đó thôi. Như vậy là tự hào sao???
3. Có rất nhiều sản phẩm việt nam xuất khẩu ra nước ngoài và có không ít người trong chúng ta không ít lần "mua nhầm" những sản phẩm đó ở nước ngoài nhưng vẫn tưởng là hàng ngoại, khi biết đều đem trả lại cho bán và cho là bị lừa. Như vậy là tự hào sao???
4. Đến cả CNTT, những công ty như FCGV(PSV), TMA gia công phần mềm cho nước ngoài, đôi khi là gia công cả sản phẩm, nhưng khi người nước ngoài bán vào việt nam, chúng ta mua và không nhận ra rằng đó chính là trí tuệ Việt. Nhưng nếu cũng sản phẩm đó công ty của người việt sản xuất ra, người nước ngoài đón nhận nó nhưng chính chúng ta đang ngày càng bài trừ nó. Như vậy là tự hào sao???

Phía trên là những ví dụ mà tôi thấy, tôi gặp, tôi cũng mong các bạn và những người Việt mình hãy xem lại thái độ và hãy tự mình xem xét rằng liệu mình có những thái độ đó không? vì rằng "con của mình thì ghét mà đem lòng yêu thương con của ai khác thì ắt hẳn con của mình sẽ hư và sẽ bị diệt", nếu đến bước này thì tôi cũng e rằng ...
Hãy hành động khi chưa quá muộn và hành động vì nước Việt thân yêu, vì bạn, vì tôi và vì cuộc sống tươi sáng của con em chúng ta. Tôi xin kết thúc bởi câu nói mà tôi thấy hài lòng nhất.

"Sống cho chân lý, cho xã hội, phục vụ trọn đời cho dân, cho người lao động cơ cực. Hãy học nữa, học mãi đó là câu trả lời cho lý tường của chúng ta".
"Cuộc sống luôn thay đổi từng giây, từng phút. Đừng sống vì quá khứ hay tương lai mà hãy sống vì chính ngày hôm nay. Đừng để một ngày mai thức dậy lại tự hỏi mình tại sao !?!"

What's new in Java 6.0 - called Mustang.

Mustang was born with somes new features:

1. Add multitasking to Java Virtual Machine, that allow one or more Java program could shared JVM.
2. Providing neư protocol call 'Socket Direct Protocol' -> Providing you with high-speed communication between Java programs.
3. Modify some features (about 500 changes) in AWT package.
4. Add new features (localization) to util and text packages.
   

Symptoms of Rotting Design.

There are four primary symptoms that tell us that our designs are rotting. They are not orthogonal, but are related to each other in ways that will become obvious. They are: rigidity, fragility, immobility, and viscosity.

• Rigidity. Rigidity is the tendency for software to be difficult to change, even in simple ways. Every change causes a cascade of subsequent changes in dependent modules. What begins as simple two day change to one module grows into a multiweek marathon of change in module after module as the engineers chase the thread of the change though the application. When software behaves this way, managers fear to allow engineers to fix non-critical problems. This reluctance derives from the fact that they don't know, with any reliability, when the engineers will be finished. If the managers turn the engineers loose on such problems, they may disappear for long periods of time. The software design begins to take on some characteristics of a roach motel - engineers check in, but they don't check out. When the manager's fears become so acute that they refuse to allow changes to software, official rigidity sets in. Thus, what starts as a design deficiency, winds up being adverse management policy.
• Fragility. Closely related to rigidity is fragility. Fragility us the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Everytime they authorize a fix, they fear that the software will break in some unexpected way. As the fragility become worse, the probability id breakage increases with time, asymptotically aproaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such soft ware causes manages and customers to suspect that the developers have lost control of their software. Distrusy reigns, and credibility is lost.
• Immobility. Immobility is the inability to reuse software from other projects or from parts of the same project. It often happens that one engineer will discover that he needs a module that is similar to one that another engineer wrote. However, it also often happens that the module in question has too much baggage that depends upon. After much work, the enginneers discover that the work and risk required to separate the desirable parts of the software from the undesirable parts are too great to tolerate. And so the software is simply rewritten instead of reused.
• Viscosity. Viscosity comes in two forms: viscosity of the design, and viscosity of the environment. When faced with a change, engineers unsually find more than one way to make the change. Some of the ways preserve the design, others do not (i.e. they are hacks). When the design preserving methods are harder to employ than the hacks, then viscosity of the design is high. It is easy to do the wrong thing, but hard to do the right thing. Viscosity of environment comes about when the development environment is slow and inefficient. For example, if compile time are very long, engineers will be tempted to make changes that don't force large recompiles, even though those changes are not optimal from a design point of view. If the source code control system requires hours to check in just a few files, then engineers will be tempted to make changes that require as few check-ins as possible, regardless of whether the design is preserved.

These four symptoms are the tell-tale signs of poor architecture. Any application that exhibits them is suffering form a design that is rotting from the inside out. But what causes that rot to take place?

Architecture and Dependencies.

• What is software architecture? The answer is multitiered. At the highest level, there are architecture patterns that define the overall shape and structure of software application. Down a level is the architecture that is specifically related to the purpose of the software application. Yet another level down resides the architecture packages, components, and classes.
• What goes wrong with software? The design of many software applications begin as a vital image in the minds of its designers. At this stage it is clean, elegant, and compelling. It has a simple beauty that makes the designers and implementers itch to see it working. Some of these applications manage to maintain this purity of design through the initial development and into the first release.
• But then something begin to happen. The software starts to rot. At first it isn't so bad. An ugly wart here, a clumsy hack there, but the beauty of the design still show through. Yet, over time as the rotting continues, the ugly festering sores and boils accumalate until they dominate the design of the application. The program becomes a festering mass of code that the developers find increasingly hard to maintain. Eventually the sheer effort required to make even the simplest of changes to the application becomes so high that the engineers and font line managers cry for redesign project.
• Such redesigns rarely succeed. Though the designers start out with good intentions, they find that they are shooting at a moving target. The old system continues to evolve and change, and the new design must keep up. The warts and ulcer accumulate in the new design before it ever makes it to its first release. On that fateful day, usually much late than planned, the morass of problems in the new design may be so bad that the designers are already crying for another redesigns.