Một số kinh nghiệm chuyển sang mã nguồn mở

Chuyển sang sử dụng mã nguồn mở (opensource migration) là chuyện chẳng có gì mới, "biết rồi khổ lắm...", nhưng thực tế tỉ lệ thành công ở VN là (rất) thấp. Có mấy lý do "duy ý chí" khiến việc chuyển sang nguồn mở thất bại khi còn trên ... dự án:

• Qúa chú trọng vào phần hệ điều hành: chăm chăm thay thế Windows trong vẫn khó khăn không biết lựa chọn bản Linux nào dành cho người dùng, chi phí để chuyển đổi, huấn luyện người dùng là chưa thể ước tính.
• Quá chú trọng vào phần Việt hóa: đa số các dự án Việt hóa phần mềm nguồn mở không đến được với người dùng, lý do đối tượng sử dụng máy tính phần lớn là dân (ngày càng) có trình độ quen thuộc với bản tiếng Anh, các dự án Việt hóa lại rất dở dang, không cập nhật thường xuyên, thuật ngữ không chuẩn.
• Thiếu đào tạo, huấn luyện: đây là nguyên nhân chính khiến người dùng "ngoảnh mặt" với nguồn mở, không được huấn luyện, hướng dẫn với một phần mềm mới trong khi "đồ chùa" vẫn xài được nên không không ai muốn tự đầu tư thời gian để sử dụng phần mềm mới. Nhân viên khi vào làm việc ở bất kỳ công ty nào cũng phải biết sử dụng MS Office và sẽ không có công ty nào dạy lại cả. OpenOffice thì khác, họ muốn phải được "hướng dẫn trước khi dùng", đó cũng là điều hợp lý. Đặc biệt đối với các bộ phận phi kỹ thuật như nhân sự không huấn luyện thì cầm chắc họ không thể làm được.
  
• Thiếu ủng hộ, cam kết từ cấp lãnh đạo: nghe thì tưởng dễ nhưng không đơn giản. Lãnh đạo gật đầu nhưng cứ nghĩ nguồn mở là không phải tốn tiến thế nên chi phí cho đào tạo, nghiên cứu, triển khai không được cam kết. Dù khẳng định phải chuyển sang nguồn mở, bắt buộc nhân viên sử dụng nhưng khi yêu cầu công việc lại "làm lơ" để tiếp tục sử dụng phần mềm cũ, hiệu quả rõ ràng là nửa vời.
• Thiếu thời gian: không thể nhấn nút là mọi thứ sẽ thay đổi ngay, cần phải có thời gian để phần mềm nguồn mở "thấm" vào được người dùng. Thực tế, dự án chuyển đổi khó thành công dưới một năm, chưa kể nhân viên còn phải lo hoàn thành mục tiêu công việc, các dự án khác có ưu tiên cao hơn như ISO, CMMI sẵn sàng chen ngang.

Dưới đây là một số kinh nghiệm triển khai và ứng dụng phần mềm nguồn mở trong doanh nghiệp sản xuất phần mềm, dù chưa đạt mục tiêu đề ra nhưng cũng có thể được dùng để tham khảo:

• Chuyển các phần mềm máy chủ sang nguồn mở: việc này đã được thực hiện khá tốt và rộng khắp, LAMP hiện khá phổ biến. Việc thay thế Active Directory Domain Controller khó khăn hơn khi Samba chưa theo kịp để tương thích và thay thế Windows 2003 AD hiện đã được sử dụng rộng rãi.
  
• Triển khai OpenOffice: cài đặt OpenOffice song song với MS Office để người dùng làm quen, dần sử dụng các tài liệu theo chuẩn Open Document. Thay thế được bộ MS Office đã là một thành công (và có khả năng hiện thực lớn) vì tính phổ dụng của nó trong công việc hàng ngày của doanh nghiệp cũng như giá không phải là ít. Cho đến thời điểm này vẫn chưa có phần mềm nào thay thế được MS Outlook, ứng cử viên sáng là Evolution vẫn chưa đủ ổn định để sử dụng trên Windows.
  
• Thay thế các tiện ích phổ dụng bằng phần mềm nguồn mở: thay Winzip bằng IZArc (7-zip), Lạc Việt MTD bằng Stardict, IE bằng Firefox, ...
  
• Đào tạo, huấn luyện sử dụng các phần mềm nguồn mở: cần có các khá huấn luyện ngắn cho người dùng đối với bộ OpenOffice hay Evolution.
  
• Chuyển những người không nhất thiết phải sử dụng Windows sang dùng Linux: cần phải khẳng định ngay từ đầu mục tiêu không phải là thay thế hoàn toàn Windows bằng Linux vì sẽ không thực tế. Những người không nhất thiết phải sử dụng Windows sẽ được lên danh sách để chuyển sang dùng Linux. Phiên bản Linux cho người dùng nên tương đối đơn giản, được hỗ trợ mạnh như Fedora Core hay Ubuntu.
• Đội ngũ hỗ trợ phải sẵn sàng và đi trước một bước: người dùng sẽ mất niềm tin và phương hướng nếu trục trặc với phần mềm mới không được giải quyết kịp thời.
• Thời gian triển khai: tối thiểu là một năm. Thực tế cho thấy dự án chuyển sang nguồn mở có thể kéo dài hơn hai năm mà kết quả vẫn rất khiêm tốn.
  

Sống chung với ngập!

Chống không được thì phải sống chung với ngập thôi chứ sao. Thế nên mới có cảnh chiều ngày triều cường có anh chàng áo cài măng-set, đóng thùng nhưng quần xắn tới gối, đi dép nhựa phóng xe vèo vèo. Đến công viên anh ta tấp vào, lôi đôi giày tây trong bọc ra, mang vào rồi đường hoàng ... đi dự đám cưới. Những nhà ở vùng ngập nặng thì xây kè, đắp "công sự" bao cát, làm chắn nước di động bằng sắt hoặc gỗ, rồi sắm máy bơm để bơm nước ra. Các bà buôn bán ở chợ phải sắm ủng để còn lo hàng họ sớm. Khổ là các bà nội trợ thì không có ủng nên những ngày nước ngập chồng con đành thông cảm ăn rau hay cơm bụi.

Dùng VNC cho online confrence, training nội bộ

Với các công ty đa quốc gia việc sử dụng dịch vụ online conference, training như WebEx, MeetMe, Centra không có gì xa lạ. Nhưng theo đánh giá của cá nhân, ở Việt Nam hình thức đó vẫn còn khá ... xa lạ đối với các công ty trong nước. Cứ họp là phải tập hợp lại hoặc dùng cầu truyền hình (trình diễn là chính), học từ xa là ... xem video quay sẵn. Không được "hoành tráng" như các service nói trên, nhưng chỉ với VNC + điện thoại là đã có thể triển khai được chuyện online conference, training cho nội bộ công ty.

Công ty có vài chi nhánh rải rác trong thành phố, mỗi lần có training là phải chạy về một nơi (có phòng rộng đủ cho hàng trăm người) trong khi ở mỗi nơi đều có phòng họp. Thay vì như thế có thể tổ chức training/conference theo nhóm nhỏ, các nhóm kết nối với nhau qua mạng điện thoại nội bộ cho phần thoại (conference bridge), phần hình ảnh trình bày được chia sẻ qua VNC. Cách này có mấy lợi điểm:

• Tiết kiệm được thời gian di chuyển của nhân viên
• Tiết kiệm thời gian ... đợi cho đủ người
• Thuận tiện, cá nhân có thể ngồi tại chỗ làm việc để theo dõi
• Cho phép số lượng lớn người tham gia
• Có thể thu lại được để xem offline
• Thích hợp với các loại hình training không bắt buộc, demo, conference/meeting
  

Tất nhiên cách làm này cũng có những nhược điểm:

• Không áp dụng được với training bắt buộc (có điểm danh), thi tại chỗ và workshop
• Tương tác người nghe và người trình bày thấp
• Phụ thuộc hạ tầng mạng và điện thoại
• Tốc độ hình ảnh có thể chậm khi có nhiều người kết nối (nhược điểm của VNC)
  

Thực tế cho thấy sử dụng online training để hướng dẫn sử dụng các phần mềm hoặc demo sẽ hiệu quả hơn rất nhiều so với dùng slide và projector truyền thống vì slide không thể chuyển tải hết các chi tiết hoặc quá nhỏ để theo dõi.

KeyJnote - để presentation bớt nhàm chán

Tình cờ chộp được KeyJnote trên #vietlug@freenode, đem về thử áp dụng ngay vào bài giảng thấy cũng bớt nhàm được tí. Muốn nhấn mạnh mục nào đó trên slide chỉ cần dùng chuột vẽ khung chữ nhật lên mục đó, phần còn lại của slide sẽ tự động mờ đi, hoặc dùng "đèn pin" để hướng sự chú ý của người nghe vào phần nào đó trên slide. Nhấn Tab sẽ liệt kê tất cả các slide để có thể nhảy đến slide bất kỳ. Đơn giản mà hiệu quả!

Visual SourceSafe to Subversion migration - part 2

Lỗi "Invalid copy source path"

Để không phải load các thư mục cũ được tạo ra trong quá khứ nhưng không còn tồn tại, dumpfile được lọc qua lệnh svndumfilter. Lỗi thường gặp khi chạy lệnh này là "Invalid copy source path" có nguồn gốc tương tự như trên. Hậu quả là "rác" từ dumpfile không thể bỏ đi được mà cũng không thể xài được.

svndumpfilter3 tương tự như svndumpfilter nhưng được viết bằng python (2.4) cho phép ignore lỗi "Invalid copy source path" để chạy tiếp. Xem như lọc được bớt "rác" không cần thiết từ dữ liệu cũ.

Lỗi "File not found"

Khi load dumpfile kết quả của vss2svn với lệnh "svnadmin load" lỗi thường gặp là: "File not found: transaction ...". Lỗi này thường gây ra do một node được tạo ra với action "change" nhưng lại không được "add" trong một revision trước đó. Hậu quả là lệnh load bị hỏng giữa chừng.

Lỗi "File not found" thì phải xử lý bằng tay, mẹo là thay action "change" thành "add" đối với node gây ra lỗi. Cách làm là tìm ra số thứ tự của dòng (line number) mô tả action cho node gây lỗi (Node-action), thay thế "change" bằng "add", tiếp tục lệnh load. Để tìm ra số thứ tự dòng của node gây lỗi có thể dùng "grep -n" hoặc "less -N", sau đó có thể pipe trực tiếp qua sed để xử lý. Ví dụ:

# cat vss2svn-dumpfilter.txt | sed -e '12345678s/change/add' | svnadmin load /var/svn/project

Hơi thủ công tí nhưng rốt cuộc cũng load được hết dumpfile, kết quả còn hạ hồi phân giải.

Visual SourceSafe to Subversion migration - part 1

Chuyển sang sử dụng OSS để giảm chi phí bản quyền, Subversion được lựa chọn là SCM chuẩn để thay thế cho Visual SourceSafe. Người dùng yêu cầu data phải được "di dời" (migrate) hoàn toàn từ VSS sang SVN, giữ được toàn bộ history. Yêu cầu hoàn toàn chính đáng nhưng lại gây đau khổ cho nhóm phụ trách "di dời".

Công cụ để migrate ngó qua ngó lại cũng chỉ có vss2svn là tốt nhất. vss2svn làm việc rất tốt với các VSS database "sạch", nguyên vẹn (không có file data nào bị hư hỏng). Nhưng với database có file data bị hỏng, quá trình load ngược vào SVN repository hầu như chắc chắn sẽ bị lỗi. Nếu lỗi xảy ra ở các revision "xa xưa" thì cơ hội để sửa được càng ... xa vời. Hiện có một VSS database 2GB với 4600 revision load được một nửa thì bị lỗi. Chẳng lẽ bó tay sao?

Mẹo xài proxy với Perl CPAN

Có những lúc cần phải cài ngay CPAN module để thử những tool viết bằng Perl. Search CPAN rồi download thì ... thủ công quá, xài shell của PAN thì proxy công ty không cho FTP nên không lấy được MIRROR list, thế là đứng ngắc. May quá, có Life with CPAN hướng dẫn cách thêm các site xài HTTP vào urllist để có thể chạy với proxy không cho FTP. Cách làm như sau:

• Vào http://www.cpan.org/SITES.html chọn một số site chạy HTTP ở đâu đó gần gần với ISP của mình
  
• Thêm site vào trong urllist của cấu hình CPAN

# perl -MCPAN -eshell
cpan> o conf urllist push http://ftp.cuhk.edu.hk/pub/packages/perl/CPAN/
cpan> o conf urllist push http://ftp.cpan.jp/
cpan> o conf commit

Giờ đây có thể install CPAN module ào ào với proxy.