Facebook – Mạng xã hội lớn nhất VN?

Theo thống kê từ trang http://o.pe/227, cho tới ngày 20.7.2009, lượng người dùng Facebook ở VN đã vượt qua ngưỡng 400.000. Con số này quả thật là một con số ấn tượng nếu như biết rằng nó đã tăng gấp 3 lần so với thời điểm 5.6.2009 (140,000) chỉ trong vòng  1,5 tháng.

Thống kê về độ tuổi cho thấy số người sử dụng trong độ tuổi 18 – 21 chiếm đa số (32%), từ 0-17 tuổi  chiếm 17%, 22-24 chiếm 20%, 24-29 chiếm 21%. Điều này có nghĩa là lượng người sử dụng dưới 30 tuổi chiếm tới 90%. Trong đó, lượng học sinh – sinh viên chiếm 49%, 41% còn lại (có thể) là nhân viên văn phòng. Một điểm cũng khá thú vị đó là lượng người dùng Facebook là nữ cũng chiếm nhiều hơn nam (khoảng 5%).

Vậy đâu là điểm thu hút của Facebook với người dùng VN nói riêng và thế giới nói chung? Có thể nói điểm mạnh của facebook chính là những applications, và chính điều này đã tăng cường mức độ tương tác giữa người dùng với nhau. Thông qua các game, quizz, chế độ loan tin wall… giúp mọi người dễ dàng kết nối, theo dõi, chia sẻ thông tin về nhau… rất dễ lôi cuốn nữ giới vốn phụ trách những công việc văn phòng, ít di chuyển, được tiếp xúc máy tính, internet, tán gẫu nhiều hơn nam giới! (Dễ hiểu vì sao số lượng người dùng nữ nhiều hơn nam giới).  Đó là ở góc độ người dùng cuối, còn ở góc độ hạ tầng công nghệ, việc phát triển các ứng dụng cũng khá dễ dàng trên nền tảng Cloud Computing, đó mới chính là điều quan trọng làm nên một Facebook luôn mới mẻ…

Còn riêng ở thị trường VN, sự ra đi gần như “tất yếu” của Yahoo!360 bỗng dưng trở thành một “đường chuyền” dọn sẵn cho Facebook ghi bàn vào khung thành bỏ ngõ!

Vậy liệu Facebook có trở thành mạng xã hội lớn nhất ở VN hay không?

Theo World Map of Social Networks, vào thời điểm 6.2009, mạng xã hội lớn nhất VN là Zing (www.zing.vn). Còn hiện tại (7.2009) chưa có công bố nào cho thấymạng xã hội nào chiếm vị thế độc tốn ở VN. Tuy nhiên, với những con số phát triển cực kỳ ấn tượng dựa trên  một nền tảng hệ thống mở, có thể dự đoán được Facebook sẽ sớm trở thành mạng xã hội lớn nhất VN chỉ trong vòng 6 tháng cuối năm.

Yahoo! 360 to Shut Down – cái chết của một ngôi sao!

Với cộng đồng dân cư mạng VN, đúng ra vào thời điểm này Yahoo!360 sẽ kết thúc sứ mạng “lịch sử” của mình, chấm dứt hơn 4 năm khoấy động giới trẻ VN.

“Yahoo!360 – memories” – trào lưu mới hiện nay

Ra đời vào những ngày cuối tháng 3/2005  và chính thức mở cửa với cộng đồng sử dụng Internet trên thế giới vào tháng 6, Yahoo!360 đã có những ảnh hưởng cực kỳ lớn đối với đời sống của đại bộ phận giới trẻ VN. Tuy những tính năng mà Yahoo!360 cung cấp chỉ ở mức “làng nhàng”,  “thường thường bậc trung”, song nhờ công cụ chat Yahoo Messenger “chống lưng”, Yahoo!360 dễ dàng và nhanh chóng chiếm lĩnh thị trường và trở thành  mạng xã hội hàng đầu ở VN. Thậm chí, sau đó, hàng loạt Mạng xã hội ra đời, trong nước có, ngoài nước có…, với những tính năng nổi trội hơn, song cũng không phải là kẻ đối trọng của Yahoo!360…

Vì một số lý do, Yahoo!360 tuyên bố chính thức đóng cửa sau nhiều lần ra… “đòn gió”. Quyết định này không quá bất ngờ với dân cư mạng, bởi suốt một năm nay, người dùng luôn phải “chịu đựng” những lỗi khó chịu từ một hệ thống quá “đát”, thiếu sự chăm sóc và quan tâm đúng nghĩa từ phía nhà cung cấp. Đại bộ phận đã “lục tục” tìm cho mình một ngôi nhà mới trên 360plus, facebook… Dù vậy, dân cư mạng VN vẫn dành một tình cảm nhất định cho Yahoo!360 cho  tới khi…

Yahoo!360 tuyên bố người dùng VN sẽ được gia hạn tới ngày 19/8 cho những nỗ lực “chuyển nhà cuối cùng”! (Yahoo! 360 gia hạn thời gian đóng cửa đến 19/8 – Dân Trí) Một thiện chí từ phía nhà cung cấp chăng?  Tuy nhiên, sau ngày 13/7 người sử dụng sẽ không cập nhật được các bài viết trên blog của mình. “Thà biến mất vào thời điểm này còn chút gì đó lưu luyến. Giờ cho thêm 1 tháng nữa cũng chả làm dc cái gì.” hay như “Tạm biệt cho đã giờ kiu gia hạn. Bó tay” – Pikachu, một blogger nhận xét.

Tuy nhiên, ngoài chuyện “dời nhà”, đây là cơ hội để bạn tham gia trào lưu “Yahoo!360 Memories”, tranh thủ chụp lại những thời khắc cuối cùng trên blog cá nhân.

…

Một cái chết tốn nhiều giấy mực!!!

Functional Point Analysis (cont) – II

Trước khi bắt đầu mình sẽ giới thiệu lại quy trình tính toán FP như sau:

1. Xác định kiểu đo lường (ước lượng cho dự án mới, nâng cấp dự án hay chỉ đánh giá một dự án đã có)
2. Xác định phạm vi của dự án.
3. Xác định số lượng Function Points thô (Unadjusted Function Points)
4. Xác định hệ số cân đối (Value Adjusted Factors).
5. Xác định số lượng Function Points cân đối (Adjusted Function Points).

Step 1: Xác định kiểu đo lường (Type of Count)

Bước đầu tiên trong phương pháp FPA đó là xác định loại dự án cần ước lượng. Do đó, việc xác định số lượng FPs có thể là việc xác định số lượng FPs của một dự án hoàn toàn mới (Development Project FP Count), số lượng FPs của việc nâng cấp một dự án (Enhancement Project FP Count) hoặc đơn giản chỉ là đánh giá lại một dự án hoàn thành (Application FP Count).

Step 2: Xác định đường biên (boundary) của ứng dụng

- Ứng dụng mà bạn đang xây dựng là ứng dụng độc lập (standalone) hay chỉ là một phần trong một gói (suite) ứng dụng. Nghĩa là nguồn cung cấp dữ liệu để ứng dụng của bạn hoạt động là “nguồn tự cung tự cấp” hay là từ một ứng dụng nào đó. Chẳng hạn như khi một trường đại học muốn gửi thông báo về kết quả của một sinh viên cho gia đình của sinh viên đó, thì nó “hệ thống quản lý điểm thi” phải lấy dữ liệu (tức là thông tin liên lạc của sinh viên đó) từ hệ thống “quản lý sinh viên”.

- Việc xác định đường biên của ứng dụng là rất quan trọng, nó ảnh hưởng trực tiếp lên độ phức tạp của ứng dụng, bởi vì việc phát triển một ứng dụng standalone bao giờ cũng đơn giản hơn các ứng dụng trong các “gói” ứng dụng. “Tiền của tui tui xài!”, dĩ nhiên là cảm thấy “thoải mái” hơn là sử dụng tiền của người khác vì bạn không bị phụ thuộc, và rõ ràng những thay đổi xảy ra đối với cá nhân khác không làm ảnh hưởng lớn đến “việc xài” của bạn. Nó cũng tương tự như trong một dự án, sự trì trệ tại một khâu, một giai đoạn nào đó trong chu trình phát triển sẽ ảnh hưởng lên toàn bộ chu trình. Hay như việc phát triển các phần mềm quản lý nhân viên, quản lý tiền lương riêng lẻ bao giờ cũng đơn giản hơn là việc phát triển một gói giải pháp ERP cho doanh nghiệp rồi! Dĩ nhiên ưu điểm của ERP là tài nguyên được sử dụng hiệu quả hơn song đó cũng chính là vấn đề của nó, làm thế nào để sử dụng hiệu quả nguồn tài nguyên đó!

- Giả sử chúng ta cần xây dựng một ứng dụng “đơn giản” nhằm quản lý điểm cho sinh viên, đồng thời khi có yêu cầu, ứng dụng sẽ in ra kết quả thi và gửi đến gia đình sinh viên đó. Chúng ta giả định rằng, không hề có một ràng buộc nào về một học kỳ phải học những môn học nào, đơn giản, chúng ta có một danh sách các sinh viên, danh sách các môn học và chi tiết điểm của sinh viên cho tất cả các môn học đó (không giống như thực tế lắm vì nếu có một số môn chưa học thì kết quả bằng “zero”… nhưng giả định để cho đơn giản mà).

- Như vậy về mặt CSDL ta sẽ có như sau

• SinhVien(MaSV, HoTen, MaLop)
• MonHoc(MaMH, TenMH, SoTinChi)
• KetQua(MaSV, MaMH, Diem)

- Một lưu ý là thông tin chi tiết của một SinhVien có thể truy xuất từ hệ thống quản lý SinhVien với CSDL như sau (đã lược bỏ một số thông tin)

• SinhVien(MaSV, HoTen, NgaySinh, DiaChiNha, PhuongXa, QuanHuyen, TinhThanhPho)

Như vậy bạn có thể xác định được boundary của ứng dụng của bạn như sau

Step 3a: Xác định FP thô (UFP)

Độ phức tạp của ứng dụng phụ thuộc vào hai yếu tố, đó là mức độ phức tạp của dữ liệu (data) và mức độ phức tạp của việc xử lý (transaction). Do đó, việc xác định UFP là công việc xác định số FPs của dữ liệu (Data Function Points)và số FPs của xử lý (Transaction Function Point).

Data FPs thể hiện khía cạnh dữ liệu trong các chức năng cung cấp cho khách hàng. Nó đặc trưng bởi hai yếu tố ILF (Internal Logical File) và EIF (External Interface File). Việc xác định ILF hay EIF cần được thực hiện trước khi tiến hành chuẩn hóa (normalize) dữ liệu.

- Một ILF là một nhóm các dữ liệu được lưu trữ và bảo trì trong phạm vi hệ thống (bên trong boundary). Thông thường nó là một bảng (table) trong cơ sở dữ liệu của ứng dụng.

- Một EIF cũng là một nhóm dữ liệu nhưng được lưu trữ và bảo trì bởi một ứng dụng khác (bên ngoài boundary). Dĩ nhiên, một EIF này có thể là một ILF của một ứng dụng khác. Thông thường EIF được cung cấp thông qua các services. Chẳng hạn như các services chứng khoán, bảng ngoại tệ, thời tiết…

Transaction FPs thể hiện khía cạnh xử lý của ứng dụng trong các chức năng cung cấp cho khách hàng. Nó đặc trưng bởi ba yếu tố EI (External Inputs), EO (External Outputs), External Inquiries (EQ).

- Một EI là một tiến trình căn bản (element process) trong đó dữ liệu được truyền từ bên ngoài vào bên trong của boundary. Thông thường EI là các thao tác thêm, xóa, cập nhập dữ liệu trong cơ sở dữ liệu

- Một EO là một tiến trình căn bản (element process) trong đó dữ liệu phát sinh (derived data) được truyền từ bên trong ra bên ngoài boundary. Dữ liệu phát sinh đó thường là các dữ liệu được kết hợp với nhau bằng các công thức tính toán như SUM, AVERAGE… Dĩ nhiên, các dữ liệu phát sinh này không xuất hiện trong các ILF hay IEF. Thông thường các EO là bảng báo cáo (reports), các thông báo hay dữ liệu gửi tới các ứng dụng khác.

- Một EQ là một tiến trình căn bản (element process) có hai chiều nhập dữ liệu (input) và xuất dữ liệu (output) nhằm truy xuất dữ liệu từ một hay nhiều ILF/EIF. Trong đó dữ liệu nhập (input) không làm thay đổi dữ liệu của ILF/EIF và dữ liệu xuất không chứa các dòng dữ liệu phát sinh (derived data). Thông thường, EQ là các thao tác tìm kiếm, truy vấn dữ liệu từ các ILF/EIF.

Lưu ý: Tiến trình căn bản (element process) là một xử lý đơn vị đối với người dùng (có nghĩa với họ). Ví dụ, người dùng yêu cầu chức năng thêm một sinh viên với mô tả là một sinh viên có mã số sinh viên, họ tên sinh viên… thì tiến trình căn bản chính là “thêm một sinh viên” chứ không phải là thêm một họ tên, mã số sinh viên…

Cách tính UFP

1. Xác định độ phức tạp cho các ILF và EIF: Gồm việc xác định số lượng ILF và độ phức tạp (Complexity) của mỗi ILF thông qua việc xác định số lượng RETs và DET
   • Xác định số lượng ILF.
   • Xác định độ phức tạp của mỗi ILF bằng cách tính số lượng DETs (Data Element Type) và số lượng RETs (Record Element Type). Trong đó, DETs là các cột (field) dữ liệu, còn RETs là nhóm các cột dữ liệu (có quan hệ phụ thuộc vào nhau, được cập nhập cùng nhau). Để xác định các RETs, thông thường người ta sử dụng phương pháp chuẩn hóa cơ sở dữ liệu.
   • Từ độ phức tạp tính được số FP tương ứng.

   

2. Xác định độ phức tạp cho các EI: Căn cứ vào số lượng FTR (File Types Referenced) và DET (Data Element Types) để quyết định độ phức tạp của mỗi EI.
   • Xác định các EI có trong dự án.
   • Tính FTRs và DET cho mỗi EI. Trong đó, mỗi FTR phải là một ILF hoặc một IEF mà EI đó tương tác. Còn DET là mỗi dòng dữ liệu nhập (Data Input Field), thông báo lỗi(error message), thông báo xác nhận (confirm message), buttons, mỗi nhóm radio buttons, check boxes, listbox…
     • Mỗi DATA INPUT FIELD được tính là 1 DET
     • Tất cả các ERROR MESSAGE được tính là 1 DET
     • Tất cả các CONFIRM MESSAGE được tính là 1 DET
     • Mỗi BUTTON được tính là một DET.
     • Mỗi RADIO BUTTON GROUP được tính là 1 DET
     • Mỗi CHECK BOX được tính là 1 DET
     • Mõi LISTBOX, DROP-DOWNLIST… được tính là 1 DET

     

3. Xác định độ phức tạp cho các EO: Hoàn toàn tương tự như cách xác định FP cho EI.
   • Xác định các EO có trong dự án.
   • Tính FTRs và DETs cho mỗi EI để suy ra độ phức tạp và số lượng FPs tương ứng. Trong đó số lượng DET được xác định như sau:
     • Mỗi cột dữ liệu đọc được từ ILF, EIF được tính là 1 DET.
     • Mỗi dữ liệu phát sinh (derived data) được tính là 1 DET.
     • Các error message được tính là 1 DET.
     • Các Confirm message được tính là 1 DET.
     • KHÔNG TÍNH tiêu đề (heading) của cột, ngày tháng ngày lập báo cáo. Chỉ tính ngày tháng là một DET nếu nó là dữ liệu có ý nghĩa trong kinh doanh (như lập hóa đơn, ngày đăng ký…
       

       

4. Xác định độ phức tạp cho các EI: Như đã biết, mỗi EI là một tiến trình xử lý gồm hai chiều (thể hiểu như gồm EI và EO). Do đó số lượng FTRs và DETs cuối cùng là sự kết hợp giữa FTRs và DÉTs phía EI và EO. Điều này có nghĩa là nếu cả phía EI và EO cùng sử dụng một FTR thì FTR đó chỉ được tính là MỘT. Tương tự như đối với DET.

Sau khi xác định được độ phức tạp của ta sẽ tính được số lượng FP tương ứng với mỗi EI, EQ, EO.

Cuối cùng ta tính được UFP dựa vào bảng sau. Tạm thời ta chỉ quan tâm tới Total Number of Unadjusted Function Points (Trong bài viết sau sẽ trình bày cách tính Value Adjustment Factor và Total Adjusted Function Points)

Chứng khoán “câu giờ” chờ động thái mới của UBCK?

Bằng một loạt các chính sách điều chỉnh, nỗ lực từ phía UBCK nhằm “cứu” chứng khoán xem ra đang rất khả dĩ, đơn giản vì NĐT không còn cảm thấy “đau đầu” khi CK liên tục rớt sàn. Biện pháp giảm biên độ giao động, đồng thời kêu gọi các ngân hàng ngừng việc giải chấp các hợp đồng cầm cố, các REPO chứng khoán (tức là các hợp đồng mua bán chứng khoán có kỳ hạn)… đã phần nào ổn định được tâm lý đang vô cùng hoang mang của các NĐT. Tức là UBCK chưa phải viện đến chiêu thức đóng cửa TTCK.

“Màu xanh” đã trở lại, nhưng thực chất, VN-Index chỉ “nhích” lên 3-4 điểm mỗi phiên. Với “tốc độ” kiểu này còn lâu mới đạt được ngưỡng 600, đừng nói gì là cái mốc 900 vốn được nhiều người dự đoán là cái mốc lý tưởng. Rõ ràng, những NĐT không trông đợi vào cái kiểu “ổn định” như thế. CK Việt gần đây liên tục gặp những tình huống dở khóc dở cười, “lúc bán không ai mua”, “lúc mua không ai bán”. Với cảnh mua bán một chiều như thế này thì CK cần có những đợt “sóng” và với cơ chế như hiện tại thì khó lòng mà đạt được điều mong mỏi ấy. Nhưng để như vậy thì biên độ dao động phải được trở lại trạng thái 5% (HOSE) và 10% (HASTC) thay vì 1% và 2% như hiện tại. Vấn đề là bao giờ? Khi mà việc giải chấp các hợp đồng cầm cố, các REPO chứng khoán trước sau gì cũng phải được thực hiện.

Kinh nghiệm từ đợt rớt sàn “lập đáy” mới trước cho thấy, chỉ sau 3 phiên tăng trần, các NĐT lướt sóng lập tức bán tống bán tháo ngay đi các CP bởi lợi nhuận mà họ kiếm được đã ở mức 10-15% – một con số có thể làm hài lòng bất kỳ NĐT nào. Và hệ lụy là CK trở lại với “quỹ đạo rơi tự do” và liên tục phá đáy xuống dưới 500 điểm. Rất có thể lịch sử sẽ lập lại bởi lợi nhuận 3-5% cũng không quá tồi. Và sau đó…

Các chính sách hiện tại có vẻ như đang “kéo giò” nhau chỉ để chờ những động thái tích cực mới từ phía UBCK song với cá nhân của một kẻ “ngoại đạo” như tôi thì tôi vẫn mong cái biện pháp giảm biên độ dao động sẽ diễn ra trễ hơn thời điểm 27/03 hoặc trong tình thế này nó sẽ kết thúc sớm hơn việc thực hiện giải chấp của các ngân hàng (chắc chắn là vậy nhưng là bao giờ). Và liệu có khi nào, CK áp dụng biên độ dao động khác nhau cho những ngày khác nhau không nhỉ? Chẳng hạn như biên độ 5% đối với thứ 3, còn lại là 1%… Hay là giờ đang đà tăng, cứ khôi phục lại biên độ cũ, khi nào giảm lại hạ biên độ!!! Đó cũng chỉ là những biện pháp tình thế mang tính chất chắp vá cho đến khi TTCK đạt tới “trạng thái lý tưởng”. Đó chỉ là cái nhìn bi quan!

Trở lại với cái nhìn lạc quan, giá CP đã xuống tới mức “vô lý”, do đó, việc mua vào lúc này sẽ trở nên không thể “hợp lý” hơn. Kết quả là, rất có thể, đây chính là cú “hích” giúp CK trở lại đà tăng trưởng.

Và dù thế nào đi nữa, trở lại vấn đề đã đặt ra, cái biện pháp giảm biên độ dao động đến hồi sẽ phải được tháo dỡ! Khả năng sẽ là đầu tháng 4. Nhưng mong là đừng có trúng ngày 1/4 vì lúc đó không biết nên tin ai đâu đấy!

Web Standards

Hôm nay trong lớp lại nghe tới chuyện việc hiển thị web ở mỗi trình duyệt mỗi khác, IE khác, Firefox khác, Safari lại càng khác… mình lại nghĩ tới Web Standards. Cũng chẳng mới mẻ gì, khái niệm này mình cũng nghe lâu rồi, và cũng cố gắng áp dụng, à không tuân thủ mỗi khi “làm web” – dùng từ “làm” thay cho “design” bởi lẽ mình thấy những gì mình làm ra chưa thể gọi là “nghệ thuật”, mà không phải là “nghệ thuật” – sao có thể gọi là design.

Dù bạn đã từng làm công việc phát triển một ứng dụng web hay chỉ là những người mới tiếp cận công việc đầy thú vị này, thì Web Standard vẫn thật sự là một vấn đề bạn cần lưu tâm. Nó sẽ giúp bạn có được một “ấn phẩm web” có “chất lượng”, hoạt động ổn định trên hầu hết các trình duyệt web thông dụng, bạn sẽ không còn lo lắng quá nhiều về vấn đề người dùng sẽ dùng trình duyệt nào, hệ điều hành nào…. để sử dụng ứng dụng web mà bạn đã tạo ra. Thông thường thì việc phát triển các ứng dụng web “tương thích” với nhiều trình duyệt… sẽ phát sinh thêm những dòng code để phát hiện người dùng đang sử dụng trình duyệt nào và ứng với mỗi trình duyệt như thế sẽ có những xử lý khác nhau, tăng số lượng dòng code đồng nghĩa với chi phí phải trả cho nhân viên sẽ cao hơn. Tuy nhiên, do vấn đề lợi nhuận nên công việc đó thường bị xem nhẹ, thậm chí bỏ đi. Hậu quả là một phần nội dung hoặc những thao tác như ý đồ thiết kế không được thực hiện. Chính vì vậy, việc tuân thủ Web Standard sẽ góp phần giảm thiểu chi phí cho việc phát triển một cách đáng kể. Thậm chí ứng dụng web của bạn còn có khả năng phục vụ cho nhiều đối tượng người dùng, đặc biệt là dành cho cả người khiếm thị.

Vậy thực chất Web Standards là gì? Web Standards là một tập hợp các tiêu chuẩn, chuẩn mực về công nghệ, ngôn ngữ… đảm bảo cho một trang web có thể hoạt động tốt trên mọi nền tảng phần mềm hay phần cứng. Không những vậy, nó còn hạn chế được chi phí phát sinh khi tiến hành phát triển, bảo trì trang web.

Vậy tuân thủ Web Standards sẽ đem lại lợi ích gì?

• Trước mắt là vấn đề hiển thị. Mọi thứ sẽ tương đương nhau cho dù bạn dùng trình duyệt nào, hệ điều hành nào, trên PC, thiết bị PDA hay các điện thoại có chức năng duyệt web và thậm chí cả công tác in ấn nữa.
• Tiếp theo dĩ nhiên là vấn đề lợi nhuận như đã phân tích ở trên.
• Giải quyết được vấn đề cộng tác, bạn hình dung một ứng dụng web được phát triển bởi nhiều cá nhân có trình độ, tư duy, phương pháp tiếp cận khác nhau… chưa kể, công việc được chia thành nhiều công đoạn, quy trình phát triển khác nhau… do đó cần phải tạo ra những quy ước để các cá nhân có thể hợp tác “ổn thỏa” với nhau. Do đó, tốt nhất là sử dụng chuẩn
• Một điều nữa đó là nó hứa hẹn ứng dụng web sẽ được thực thi nhanh hơn (dù chưa được kiểm chứng rõ ràng). Lý do có thể là do số lượng dòng code được giảm thiểu, trình duyệt không còn phải xử lý những đoạn code lạ do các kỹ thuật hack (như hack css) gây ra.

Tuân thủ Web Standards như thế nào? Đây thực sự là một câu hỏi hay! Trước khi nói về cách thức tuân thủ Web Standards chúng ta cần biết rằng, khi nói tới “Standard” là nói tới các ngôn ngữ được sử dụng trong Web Standards. Cụ thể là

• Ngôn ngữ có cấu trúc và mang tính ngữ nghĩa (Structural and Semantic Languages): Đó chính là HTML 4.01, XHTML 1.0 và XML 1.0
• Ngôn ngữ trình bày (Presentation Languages): Đó chính là CSS level 1, 2, 2. Ngôn ngữ này giúp chúng ta có thể dễ dàng và linh động trong việc định dạng màu sắc, kích thước, vị trí… của các thành phần trong ứng dụng web của bạn.
• Mô hình đối tượng (Object Model): Đó là DOM level 1, 2, 3. Mô hình này cho phép chúng ta thao tác được với tất cả các đối tượng theo mô hình cây.
• Ngôn ngữ kịch bản (Scripting Language): Đó chính là ECMAScript được biết với cái tên thông dụng là JavaScript dù rằng gọi như thế là không đầy đủ. Loại ngôn ngữ này thường được biết đến với việc tạo ra các hiệu ứng, các xử lý hoạt động tương tác ở phía client.
• Ở một mức cao hơn, bạn nên biết đến phiên bản mở rộng của HTML và XHTML, các ngôn ngữ đánh dấu mở rộng như MathML. Tuy nhiên, tạm thời chúng ta chỉ cần quan tâm tới 4 loại ngôn ngữ ở trên là đủ.

Vậy là bạn đã đoán được ý đồ của việc tuân thủ Web Standards rồi đấy! Chỉ cần bạn sử dụng các ngôn ngữ trên cho các ứng dụng web của bạn một cách thành thục và cố gắng phát huy tối đa lợi thế mà mỗi ngôn ngữ trên đem lại. Tuy nhiên cần chú ý tới những yêu cầu đi kèm đối với việc sử dụng mỗi ngôn ngữ. Chẳng hạn như các quy định khi làm việc với XHTML đó là:

• Có thẻ mở thì phải có thẻ đóng. Ví dụ: <html>…</html>
• Đối với các loại thẻ rỗng (empty tags) như <br>, <hr>… được sử dụng dưới hình thức <br />, <hr /> hoặc có thẻ đóng </br>, </hr>..
• Các giá trị của các thuộc tính phải được bao bởi cặp dấu nháy đơn hoặc nháy kép.
• Thẻ mở trước phải được đóng sau. Tức là các thẻ có thể được lồng vào nhau nhưng không được chồng lên nhau. Ví dụ: <b><i>Hello World!</b></i> là không hợp lý. Phải là: <b><i>Hello World!</i></b>

Bạn đã phần nào thấy được sự tuyệt vời mà Web Standards đem lại, việc tuân thủ chúng có vẻ cũng đơn giản. Tuy nhiên, cũng như bất kỳ những vấn đề gì, việc tuân thủ Web Standards cũng có những mặt hạn chế và bất cập.

• Đầu tiên, bạn sẽ phải thay đổi tư duy khi phát triển ứng dụng web. Một điều thường thấy là các trang web vẫn được thiết kế theo hướng table, nghĩa là bạn sử dụng table để trình bày bố cục (layout) của trang web. Tức là phần code HTML của trang web thường có dạng <body><table width=”100%”>…</table></body>… hoặc tương tự như thế. Cách thiết kế này gọi là “table-based”. Để thay thế nó, bạn nên biết và sử dụng cách thiết kế “boxed-model” mà bạn có thể tìm thấy nó trong bất cứ tài liệu nào về CSS. Còn vấn đề tại sao ư, việc layout cho trang web của bạn theo hướng table-based sẽ khiến trang web của bạn load chậm hơn, nó làm cho trang web của bạn mất đi tính “accessible”, tức là bạn không thể lướt web bằng bàn phím hoặc trên các thiết bị PDA, điện thoại chưa kể, bạn không thể tận dụng tối đa những điều tuyệt vời mà CSS đem lại, mà trong chừng mực của bài viết này không thể trình bày kỹ càng. Một cách đơn giản, hãy sử chúng vì nó là “chuẩn”.
• Bạn phải học cách phân tách công việc trình bày và xử lý. Một cách nôm na đó là khi bạn muốn thay đổi định dạng màu sắc, kích thước của một phần tử, việc mà bạn cần làm đó là chỉnh sửa file CSS chứ không phải là chỉnh sửa các đoạn code xử lý.
• Một bất lợi nữa đó là hiện nay các trình duyệt vẫn chưa có sự “ăn ý” với nhau. Giữa chúng vẫn còn một khoảng cách nhất định. Bạn hoàn toàn có thể nhận ra điều này khi ứng dụng boxed-model trên các trình duyệt IE và đem so sánh với Firefox, Nescape, Opera, Safari… Bạn sẽ nhận thấy rằng, chính IE mới là kẻ “tội đồ”. Vì vậy hãy sử dụng song song các trình duyệt.
• Đó là chưa kể tới việc bạn phải tốn công nghiên cứu Web Standard là cái gì nữa đó! Nhưng đừng quá lo lắng, mọi thứ khi mới bắt đầu đều gặp khó khăn cả. Dần dần, bạn sẽ thấy những điều tuyệt vời mà Web Standards đem lại.

Bạn đã từng quan tâm tới chất lượng sản phẩm liệu có đáp ứng được yêu cầu của bạn như hứa hẹn của nhà sản xuất, bạn đã từng quan tâm tới ISO của một sản phẩm, của một công ty, của một tổ chức; đã từng nghe tới CMMi của một công ty phần mềm… vậy hãy quan tâm tới Web Standard.