Các câu nói phét kinh điển

(nguồn Hoàng Đức Thịnh – Zoomban Note)

1. Internet:
Chúng tôi hoàn toàn miễn phí

2. Viễn thông:
Chúng tôi bị lỗ vốn

3. Cảnh sát:
Chúng tôi vì nhân dân phục vụ

4. Công ty tham gia thị trường chứng khoán:
Chúng tôi không làm giả các báo cáo

5. Sếp:
Tôi không bao giờ quên những cống hiến của anh

6. Nhân viên:
Mai tôi nghỉ việc, không làm nữa

7. Tài xế xe khách:
Nhà xe xuất phát đúng giờ

8. Dân buôn:
Bán lỗ vốn, đại hạ giá

9. Ngôi sao điện ảnh:
Chúng tôi chỉ làm bạn bè

10. Chính khách:
Tôi không nhận một đồng nào

11. Con gái:
Đây là lần đầu tiên

12. Con trai:
Ngoan, không đau tí nào đâu

Nhẹ nhàng, thân thiện, thông minh hơn – Anhso let’s go

(Nguồn Internet và tổng hợp)

Web 3.0
Xét về mặt công nghệ, HTML và JavaScript chưa đi xuống như dự kiến. Chúng ta vẫn sẽ khai thác, lai tạo và chờ đợi một công nghệ chuẩn, một giải pháp mới mẻ náo đó chăng? Nếu có tôi hi vọng lập trình viên sẽ không phải nên chuột của mình uỳnh uỳnh khi view website trên IE…
Bolg lúc này có thể giống như một quyển sổ gập vào, mở ra. Dịch vụ chia sẻ ảnh thì giống như là những album thực sự, mạng xã hội không ảo mà còn gắt kết nhiều hơn xã hội thực. Tìm mua hàng trên mạng không được mới nghĩ đến việc xách xe ra chợ…Sẽ không có khái niệm SecondLife mà chỉ có 1 cuộc sống thực duy nhất, nó gắn liền với mạng.

Những công nghệ đang khởi động?
XML chẳng thể thay thế nổi HTML như người ta tưởng. Applet chết mòn khi JavaScript và Flash sinh sôi. Bất cứ dịch vụ nào, nếu phức tạp, người ta sẽ từ bỏ ngay từ lần ghé thăm đầu tiên.
Điều đó nhắc nhở giới công nghệ rằng: nhanh, nhẹ, thân thiện, đơn giản là những nhân tố để đi đến thành công. PHP được viết nhiều hơn bởi tư duy Java dù có mạnh đấy nhưng quá rắc rối và phức tạp. Với bất cứ phần mềm, hãy đừng hành là chính.
Tôi nói thì rất dễ. Bản thân tôi cũng mắc nhiều sai phạm dù trong tâm niệm mình luôn hướng đến sự đơn giản. Tư duy cần hướng đến sự đơn giản hóa. Trong công việc hằng ngày, tôi thường bắt gặp những lối tư duy quá phức tạp của các lập trình viên hay kỹ sư phần mềm. Đó là điểm yếu tạo thành bức rào cản khiến ứng dụng không thể phổ dụng. Sáng tạo quá nhiều tính năng mà người ta không bao giờ dùng sẽ làm nặng chương trình và tăng độ khó. Nghĩ đơn giản, làm giản đơn là bước đầu đưa đến thành công.
Điều đó đồng nghĩa rằng những công nghệ tương lai có thể mạnh nhưng sẽ cần gọn và dễ hiểu hơn. HTML sống được là bởi nó lỏng lẻo nhưng trong tương lai, tính lỏng lẻo đó sẽ giết chết nó. Thời đại Web 3.0 cần những xử lý, những tương tác mạnh hơn nên cần sự phát triển của HTML và Javascript hoặc một chuẩn, công nghệ, giải pháp thay thế.
Bởi ban đầu HTML chỉ được thiết kế cho việc định dạng tài liệu, sự phát triển đến thời Web 2.0 là do những chắp vá cùng scripting hỗ trợ trong trình duyệt để xử lý một phần nghiệp vụ, thao tác phía client. HTML đã có phiên bản mới để thỏa mãn những yêu cầu trong thời đại nhưng người ta cũng đang nghĩ đến giải pháp thay thế hoàn toàn HTML.
Những giải pháp này có thể chạy bên trong trình duyệt hoặc ngoài trình duyệt. Đó là những nhân tố góp phần làm thay đổi thiết kế ở mặt đồ họa của hệ điều hành tương lai dành cho thế hệ máy tính tương tác mạng. Nó phải đảm bảo được những phức tạp, tinh vi về giao diện bên cạnh sự đơn giản, nhẹ và khả năng tương tác cao hơn những gì mà HTML + JavaScript mang lại. Dĩ nhiên để có thể chạy được cả trong lẫn ngoài trình duyệt, chúng cần những bộ Runtime. Những bộ Runtime này đủ nhỏ để dễ dàng cài đặt chứ không to uỳnh như cái Reader của Acrobat.
Ngoài giao diện, thế hệ Web kế tiếp hướng đến việc xử lý tốt nguồn dữ liệu đang lớn dần từ thời Web 2.0. Ngữ nghĩa là định hướng xử lý dữ liệu cho thế hệ Web 3.0. Không phải đến thời đại này thì Sematic Web mới được định nghĩa. Đây là một mô hình đã có từ thời 1.0 nhưng phải nhờ đến 2.0 rồi sang 3.0 thì mới có đất để sinh sôi nảy nở. Phải có dữ liệu, càng nhiều, càng tốt, và chúng ta đang sở hữu một nguồn dữ liệu khổng lồ từ 1.0 do trào lưu số hóa, từ 2.0 trong trào lưu mạng dịch vụ xã hội. Tổng hợp, phân tích, xử lý nguồn tài nguyên này là định hướng dữ liệu thời 3.0. Ở 1.0, người dùng là những cá nhân chủ động tiếp cận dữ liệu, sang thời 2.0 họ trở thành những người cung cấp dữ liệu và đến thời 3.0 họ có thể trở thành chuyên gia tổng hợp, phân tích dữ liệu chuyên nghiệp. Semantic Web chính là sự thông minh của Web.
Thế hệ Web kế tiếp đón nhận sự gia nhập của các thiết bị cá nhân khác vào Web ngoài computer. Những thiết bị như máy chơi game, nghe nhạc, điện thoại hay đơn giản là giấy chứng minh điện tử, hoặc điên rồ hơn là một cặp kính thông minh cũng có thể tham gia vào Web 3.0. Sự tham gia có phong trào này sẽ làm cho môi trường Web 3.0 trở nên sinh động và có sức ảnh hưởng lớn hơn so với các thời kỳ trước đó. Trong những năm tới, thiết bị cá nhân có thể truy cập Internet và hiểu được Web sẽ là điểm nhấn tính năng trong các quảng cáo sản phẩm và nó trở thành một yêu cầu của khách hàng khi họ móc hầu bao. Kết nối không dây là cơ sở thúc đẩy trào lưu gia nhập đó giống như ADSL thúc đẩy sự phát triển các dịch vụ cung cấp nội dung ở Web 2.0.
Nền kinh tế phát triển, thế giới bị san bằng. Lượng người tham gia vào Internet sẽ chỉ có tăng chứ không hề giảm. Công nghiệp sản xuất phần mềm dịch chuyển dần sang dịch vụ phần mềm. Tương lai là dịch vụ. Do đó, những máy chủ thời 3.0 không phải là những máy dịch vụ Web đơn lẻ. Đó sẽ là một mạng máy chủ dịch vụ với môi trường điện toán lưới (Grid Computing) và xử lý song song cùng các trung tâm dữ liệu khổng lồ. SOA và Web Service sẽ trưởng thành thực thụ. Mô hình kiến trúc hướng dịch vụ trở thành xương sống trong các hệ thống phần mềm.
Web Service là trợ thủ đắc lực cho dịch vụ Web 3.0. Chúng giúp trao đổi dữ liệu giữa máy khách với máy chủ thông qua giao diện đồ họa (không nhất thiết phải nằm trong trình duyệt). Máy chủ dịch vụ sẽ đón nhận luồng dữ liệu này rồi tiến hành xử lý. Những yêu cầu xử lý có thể lên đến hàng triệu trong một đơn vị thời gian nhỏ nên dù máy chủ có mạnh đến cỡ nào cũng không thể đảm đương hết. Chúng phải được phân tải với các máy chủ dịch vụ khác trong mạng. Mô hình Grid Computing được thực tế ứng dụng nhiều hơn để tiến hóa, đáp ứng những yêu cầu thời kỳ Web 3.0.
Rất khó để biết trước tương lai ngoài những dự đoán mang nhiều cảm tính nhưng Web thế hệ kế tiếp đang nhen nhóm rồi đấy. Hãy tư duy mà sáng tạo đi thôi.

RIA (Rich Internet Application) là những dịch vụ web có khả năng hoạt động tương tự như ứng dụng desktop truyền thống. Các công nghệ hỗ trợ cho RIA, trong đó có AJAX, Silverlight, Flex, đang cạnh tranh khẳng định vị thế số một.
AJAX (JavaScript và XML không đồng bộ) là bộ công cụ cho phép tăng tốc độ ứng dụng bằng cách cắt nhỏ dữ liệu và chỉ hiển thị những gì cần thiết, thay vì tải đi tải lại toàn bộ trang web. Nó giúp cho phần mềm không phải nằm bó buộc trong ổ cứng nữa và đây cũng là công nghệ đằng sau RIA được nhắc đến nhiều nhất thời gian qua.
Còn Flex – bộ phát triển phần mềm được công ty Macromedia giới thiệu từ tháng 3/2004 – có nhiệm vụ hỗ trợ các ứng dụng RIA dựa trên nền tảng độc quyền Macromedia Flash. Tháng 4/2007, Adobe tuyên bố mã mở hóa Flex dù Flash vẫn là sản phẩm thương mại.
Trong khi đó, Microsoft vừa trình làng nền tảng xây dựng website tương tác mang tên Silverlight 2.0. Phiên bản này bổ sung khả năng phân phối hình ảnh đồ họa hoặc phát video trực tuyến với chất lượng 720p (1.280 x 720 pixel) – một bước tiến vượt trội so với Flash.
Chuyên gia tư vấn người Mỹ Scott Davis từng tin rằng AJAX sẽ thống trị thế giới bởi nó có khả năng hoạt động trên mọi trình duyệt. “Nhưng gần đây, tôi cảm thấy Flex thú vị hơn, nhất là sau khi nó trở thành công nghệ mã mở”, Davis cho hay.
Tuy nhiên, AJAX vẫn chiếm được lòng tin của những chuyên gia về kiến trúc web như Jon Ferraiolo của IBM. “Trong thế giới RIA sẽ luôn có chỗ dành cho Flash, Flex, Silverlight… nhờ những khả năng mới của chúng, nhưng AJAX là tổ hợp công nghệ kì diệu bởi nó thực hiện được gần như mọi thứ bạn muốn”, Ferraiolo nói.
Chuyên gia Jeffrey Hammond của hãng nghiên cứu Forrester (Mỹ) lại tỏ ra ưu ái Silverlight và coi đây mới là câu trả lời đúng đắn cho xu hướng web tương tác hiện nay.

Sắp kết thúc dự án

Hôm nay họp dự án, anh em chia nhau nốt những việc còn lại. Cứ mỗi khi sắp kết thúc một dự án, và thường là ngay vào những buổi họp thế này mình lại giật mình. Lại thấy mình lại mắc lại cái lỗi mà mình vẫn mắc suốt 3 năm qua. Vào thời điểm này, khi các vấn đề đã lộ mặt, các nguy hiểm tiềm ẩn đã hiện ra hoặc một vài chức năng không còn khả năng đáp ứng với sự phình to của dữ liệu hoặc chức năng bên cạnh… thì lại nhớ lại câu nói nổi tiếng của Mitch Kapor tác giả cuốn “The Software Design Mainfesto”.

One of the main resons most computer software is so abysmal is that it’s not designed at all, but merely engineered

Lý do cho việc nhìn nhận bản thân này là các phần mềm hầu như không được thiết kế một cách thực sự, mà chỉ được xây dựng có thứ tự theo một quy trình dập khuôn hoặc thậm chí được viết theo kinh nghiệm và thói quen của từng người, thành viên trong dự án. Các phần mềm sau khi được viết ra rất khó kiểm soát, tái sử dụng, mở rộng (mở rộng ở đây không bao gồm ‘Viết lại’ T_T ). Các thay đổi cần thiết trên một vài tính năng hoặc một nhóm các chức năng có nguy cơ dẫn đến thay đổi dây chuyền, phát sinh lỗi mới và mất kiểm soát đến mức lập trình viên cạn kiệt lòng kiên nhẫn mà viết lại toàn bộ mà lệnh cho chức năng này theo yêu cầu mới.

Đây biết rất rõ vấn đề và thâm chí còn có thể đọc ra về mặt lý thuyết các cách tối ưu, các thay đổi cho dự án sau…Nhưng cũng không thể phủ nhận phần mềm là một hệ thống cực kì khó thiết kế. Nếu không muốn nói phần mềm là hệ thống khó thiết kế nhất mà nhân loại tự tạo ra tính từ khi chuyển hóa từ vượn thành người cho đến nay. Giáo sư tiến sỹ Brooks trong cuốn sách của mình “No Silevr Bullet” cũng nghĩ y hết như tôi là thiết kế phần mềm còn khó hơn thiết kế một toàn nhà chọc trời. Điểm qua các vấn đề làm cho việc thiết kế một phần mềm khó như vậy.

1. Độ phức tạp. Phần mềm là một tập hợp của rất nhiều các thành phần rời nhau. Một chiến đấu cơ F16 với giá 14,6 – 18,8 triệu USD chỉ có khoảng vài ngàn thành phần như vậy. Trong khi đó một phần mềm cỡ trung có thể có tới hàng trăm module và hàng chục ngàn dòng lệnh mà tất cả chúng phải tương thích lần nhau, tương thích với cả hệ thống. Bất cứ khi nào ta thêm 1 dòng lệnh hay đưa các điều kiện, sự kiến mới vào đều có thể phát sinh các vấn đề mà ta đã không cân nhắc trước đó. Rất hay có chuyện là thêm vào một vài dòng code ở tận đâu trong Engine rồi một ngày đẹp trời quay lại 1 chức năng lâu không dùng ở tầng UI thấy lăn ra chết rồi. T_T.
2. Tính bất quy tắc. Một chiếc xe máy thì luôn có 1 bộ khung, 2 cái bánh xe, yên xe rồi tay lái bla bla… nói chung là có thể thay đổi về hình dáng, kích thước, mầu sơn , mầu tem hay thậm chí là xe máy do Khựa sản xuất thì cũng vẫn thế như thường. Nghĩa là để sản xuất xe mày cần phải tuân thủ các nguyện tắc chung này. Đến Khựa còn phải tuần thủ thì cái này không phải bản rồi. Ấy thế mà lại không có một quy tắc nào cho việc thiết kế phần mềm cả, Tất cả đều phụ thuộc vào cách thức suy nghĩ thất thường của người thiết kế là ta đây.
3. Phần mềm có thể thay đổi và luôn thay đổi. Điều này xuất phát từ môi trường vận hành của phần mềm, mối quan hệ với các hệ thống khác theo yêu cầu khách hàng… có cả nhưng lý do hết sức ngớ ngẩn cũng có thể làm phần mềm cần thay đổi. Một ngôi nhà sau khi xây xong, hầu như sẽ không có thay đổi nào đáng kể, vì việc sửa phòng, cầu thang hay thay bệ xổm thành bệ trệt đều phải phá hủy một phần ngôi nhà. Tuy nhiên phần mềm không cho phép điều này xẩy ra, không tin thì bạn cứ đọc lại phần (1).
4. Phần mềm không nhìn thấy được, không sờ được. Nhìn một bản thiết kế của ngôi nhà chúng ta hình dung được ngôi nhà sẽ thế nào.(cao bao nhiêu, rộng bao nhiêu, bao nhiêu phòng, đi lên lầu bằng lối nào, có thể hút thuốc ở đâu mà vợ đang rủa bát không thể nhìn thấy được…vân vân và vân vân…) nhưng phần mềm thì dù các mô hình trừu tượng (abstract models) có thể giúp ích rất nhiều thì cũng rất khó khăn để hình dung ra toàn bộ phần mềm.

Với tất cả các vần đề tự vấn trên đây, hi vong lần tiếp theo triển khai dự án mình sẽ vấp ít hơn các vấn đề đã gặp phải, mà nếu vẫn gặp phải thì sẽ lại viết tiếp thêm phần 5,6,7… các lý do việc thiết kế phần mềm là cực kỳ khó. Tuy nhiên cũng nên tổng kết lại một lại điểm cần nghiêm túc và quyết tâm thay đổi trong dự án sau.

Bài học

Điều đầu tiên khi nghĩ đến việc phát triển một phần mềm, thậm chí khi ý tưởng nảy ra trong đầu. Thì ai cũng muốn đấy là một phần mềm tốt. Tuy nhiên thế nào là một phần mềm tốt? Quay về năm 29 trước công nguyên. Vitruvius - một kiến trúc sư vĩ đại người La Mã đã đặt ra một câu hỏi hết sức thú vị “Thế nào là một ngôi nhà chất lượng?”. Trong cuốn sách “Ten books on Architecture” ông đã đề ra 3 tiêu chí để đánh giá một ngôi nhà tốt và thú vị là 3 tiêu chí này đã góp phần mở ra cách thức để ngày nay chúng ta đánh giá một phần mềm tốt.

1. Tính tiện nghi. Xây nhà đương nhiên là để ở, Các món hàng được mua khi khách hàng cảm thấy nó thật sự hữu dụng cho mình. Phần mềm đơn thuần cũng chỉ là một món hàng. Nó phải đáp ứng được các nhu cầu của người sử dụng, các chức năng được thực hiện đầy đủ và tất nhiên là phải thực hiện tốt. Khách hàng sẽ không vui vẻ gì khi phần mềm nghe nhạc anh ta mua chỉ chơi được file *.wma trong khi khi đặt hàng anh được chào hàng là nó có thể chơi được các file *.mp3. Nhưng thậm chí anh ta cũng không vui vẻ gì khi phần mềm này chới được cả *.mp3, nhúng nhạc vào blog, gắn Tag cho file nhạc… bla bla nhưng nhạc nghe chán chết. Tính năng nhúng lằng nhằng khó hiểu, và việc gắn tag thì cực khổ đến mức anh ta không thẻm sử dụng nó lần thứ 2 sau nổ lực bất thành lần đầu tiên.
2. Tính ổn định. Khách hàng mua mọt ngôi nhà vườn theo đúng ý ông ta, các phòng bố trí rất hợp lý, mầu sơn phòng cúng rất vừa ý và phù hợp với chức năng sủ dụng. Ông ta cực kỳ hài lòng cho đến tận 2 tháng sau. Khi mà tường có dấu hiệ bị nứt, bộ bàn ăn được khuyến cáo là không nên đặt vật gì lên có trọng lượng lớn hơn một tách trà…Chắc chắn ông ta không còn cười nổi nữa mà đến ngay chỗ mua nhà mà chửi bới loạn lên. Phàn mềm có các tính năng đáp ứng nhu cầu của khách hàng, nhưng đáp ứng tốt tới mức nào. Phần mềm có khả năng chạy nhanh, ổn định hay không. Nó có tự phát sinh lỗi trong quá trính phát triển tự nhiên của mình không? Đây là tính chất đảm bảo chất lượng phần mềm.
3. Tính mỹ quan. Một ngôi nhà kiên cố và bền vững chưa chắc đã làm hài lòng người sủ dụng. Ngôi nhà tốt cần làm hài lòng người ở và cho họ cảm giác vui thích khi được sống trong 1 ngôi nhà như vậy. Người sử dụng sẽ cảm thấy thoải mái với phần mềm có giao diện và cách bày bố chức năng đơn giản dễ hiểu hơn là 1 phần mền rối rắm và có giao diện không bắt mắt. Vì vậy giao diện cũng rất quan trọng nó đánh giá sức hút của phần mềm đối với khách hàng.

Cả 3 điều trên đếu rất quan trọng nhưng cái khó là tìm cách cân bằng nó vì trong bản thân chúng đã tồn tại các mâu thuận và tính triệt tiêu lẫn nhau. Thêm  vào đó 3 tính chất trên cũng cần thay đổi hàm lượng theo loại hình của từng phần mềm.

Sau khi đã lựa chọn và phân bổ hảm lượng của 3 tính chất trên cung không nên chỉ nong vội bắt tay ngồi code ngay. Đây là lúc cần lên kế hoạch và ghi nhớ đây là giai đoạn của việc “Thiết kế phần mềm“. Làm đến đâu nghĩ đến đó là lại đạp phải vết xe đổ của mình và thương là sẽ chỉ làm ta thu được một đống mà nguồn rối rắm hay có chăng cũng chỉ là một hệ thống nhỏ với một vài chức năng cần thiết, nhưng không thể bảo trì hay tái sử dụng.

Đôi khi do nóng lòng, sức ép về thời gian hay chỉ là sự thú hút của công nghệ mới rất dễ khiến ta làm việc chủ quan và mang tính tự phát. Nhưng nếu bình tĩnh xem xét và áp dụng các tiến trình thiết kế phần mềm vào bài toán của mình. Ta có thể tìm ra nhiều hướng đi, cách giải quyết và đôi khi đấy là nhưng lời giải tối ưu mà trước đó ta đã không để ý hoặc bỏ qua. Điều quan trọng hơn là ta có thể theo dõi và kiểm soát được chuyện gì đang xẩy ra. Thiết kế cũng đồng nghĩa với việc giúp ta có nhiều thời gian và tiền bạc hơn. Thử tưởng tượng thằng cha làm sảm phẩm yêu cầu ta thay đổi 1 vài chức năng hay cải thiện chức năng đó. Nêu không có các bản thiết kế ta lại phải nghiên cứu lại toàn bộ code, chúng ta sẽ tiêu tốn rất thiều thời gian và tiền bạc để đạt được điều này (trong điều kiện tốt nhất là chúng ta thực hiện được yêu cầu này mà không tự tạo ra xung đột và làm phá vỡ hệ thống ở các điểm khác).

Thiết kế trước khi bắt đầu những dòng code đầu tiên là cực kỳ quan trọng