Mageia Linux

- Cài đặt hỗ trợ tiếng Việt :)
- Browser: Midori (tiếng Nhật nghĩa là xanh)
- Search engine: duckduckgo, tôn trọng online privacy
- Kế thừa từ Mandriva (Mandrake)
- Trình quản lý đóng gói (vẫn) là rpmdrake, urpmi,...
- Có cách quản lý dependency hơi khác: Cho người dùng chọn khi cài
- Default desktop manager là xlde, rất nhẹ

Ếch xeo bá đạo: Thất vọng quá

Dân tình biện hộ lý do dùng Ếc sao:
- Ai cũng có, nó là chuẩn rồi
- KISS
- Bảo mật

Thực ra điều này không đúng:
- Excel không hỗ trợ tốt Collaboration, hoặc nếu hỗ trợ (thông qua
SharePoint) thì chi phí cao
- Web app dạng Wiki + issue tracking system sẽ flexible hơn nhiều so với
Excel
- Quản lý version bằng Excel: Dở hơi

Run MSO 2010 on wine 1.4

Chào các bác,

(Từ 2012/03/09) Wine 1.4 đã hỗ trợ cài Microsoft Office 2010 rồi nhé.
Các bác thử (trước, em chưa làm)

# 2012/5/24: Bản wine stable mới nhất từ ppa là 1.5.4

$ sudo echo "sorry rpm users" > /etc/passwd
$ sudo add-apt-repository ppa:ubuntu-wine/ppa
$ sudo apt-get update
$ sudo apt-get install wine

$ sudo echo "4 Arch lovers" > /dev/null
$ wget http://prdownloads.sourceforge.net/wine/wine-1.4.tar.bz2
$ tar jxf wine-1.4.tar.bz2
$ cd wine-1.4
$ ./configure
$ make depend
$ make
$ sudo make install

cf.
http://www.winehq.org/announce/1.4
http://tech.slashdot.org/story/12/03/07/1723208/wine-14-released
Danh sách phần mềm wine hỗ trợ: http://appdb.winehq.org/
Tin này thậm chí còn lên slashdot:
http://tech.slashdot.org/story/12/03/07/1723208/wine-14-released

Project Management: Protect Scope at any cost

Trong quản lý dự án, điều quan trọng nhất là bảo về bằng được phạm vi dự án bằng bất cứ giá nào.

Những yêu cầu thay đổi (CR) nhỏ, lũy tích có thể làm ảnh hưởng lớn tới tiến độ tổng thể của dự án, làm phát sinh overtime, làm nhụt nhuệ khí (motivation) của nhân viên... và hệ quả là project manager bị mất quyền kiểm soát dự án.

Một từ tiếng Anh thông dụng được chỉ việc là là "project creep". Với PM quá dễ tính, không biết cách thỏa thuận, project creep rất dễ xảy ra.

Một trong những cách thường gặp để bảo vệ phạm vi dự án là: 1) Kiên quyết hoặc khéo léo từ chối 2) Đề xuất đưa ra phase tiếp theo 3) Escalate lên cấp trên.

Định nghĩa rõ ràng phạm vi dự án, thiết kế chi tiết và review, meeting nhiều sẽ làm giảm nhưng không thể triệt tiêu CR.

Hợp đồng dự án giúp bảo vệ phạm vi dự án tốt hơn trong đa số trường hợp.

Với khách hàng Nhật, họ có "văn hóa" CR liên tục và dày đặc kể từ những ngày đầu tiên dự án cho tới khi dự án gần/đã kết thúc. Điều này được coi là hiển nhiên ở Nhật và người Nhật chấp nhận nó. Tuy nhiên, ở nước ngoài, ví dụ Việt Nam, đây là yếu tố khá quan trọng khi quản lý dự án được outsource từ Nhật.

Agile là một cách giải quyết đã được thử nghiệm thành công trong các dự án nhỏ và dự án phát triển sản phẩm (product). Trong phương pháp luận Agile, khách hàng được coi là một thành viên của đội phát triển; khách hàng communicate với thành viên dự án. Các công việc được chia thành từng sprint (tương đương phase trong mô hình waterfall) và print được chia đủ nhỏ (ví dụ 1 tháng), có sự feedback thường xuyên của khách hàng. Điểm lợi của cách làm này là: Luôn đảm bảo được sự thỏa mãn của khách hàng và góp phần hạn chế, giúp PM nhìn trước được CR thông qua việc communication thường xuyên.

cf. http://www.flickr.com/photos/vancouverfilmschool/5330405591/

--
Best Regards,
Nguyen Hung Vu [aka: NVH] ( in Vietnamese: Nguyễn Vũ Hưng )
vuhung16plus{remove}@gmail.dot.com , YIM: vuhung16 , Skype: vuhung16plus, twitter: vuhung, MSN: vuhung16.
http://www.facebook.com/nguyenvuhung
Nguyễn Vũ Hưng's blog on Free and Open Source: http://nguyenvuhungvietnam.wordpress.com/
Học tiếng Nhật: http://hoc-tiengnhat.blogspot.com/
Vietnamese LibreOffice: http://libo-vi.blogspot.com/
Mozilla & Firefox tiếng Việt: http://mozilla-vi.blogspot.com/

Disclaimer: When posted to social networking groups include, but not limited Linux Users' Groups,
Free and Open Sources forums, mailing lists, the above is my personal opinion and is *not*
the opinion of my employer(s), associations and/or groups I join.

Difference between QA and QC (in PMBOK)

Định nghĩa từ PMBOK về QC/QA:

Perform Quality Assurance: The process of auditing the quality requirements and the results from quality control measurements to ensure appropriate quality standards and operational definitions are used.

Perform Quality Control: The process of monitoring and recording results of executing the quality activities to assess performance and recommend necessary changes.

Như vậy:

- Có thể hiểu QA là subset của QC (tạm hiểu thế)
- QC thiên về thực hiện (chân tay) và QA thiên về định hướng, chiến lược
- Về thứ tự tiến hành:
  QA ra chiến lược test trước; sau đó QC thực hiện, đo đạc kết quả; QA lấy kết quả đó đánh giá, điều chỉnh lại chiến lược test, ra quyết định test cho QC

Ví dụ trong sản xuất sản phẩm tablet:
- QA đưa ra quy trình, kịch bản test, để đảm bảo tablet là bug-free hoặc đạt một mức độ phế phẩm tối đa nào đó.
- Quy trình, công việc này bao gồm cả:
  - Các loại tablet cần làm (để test)
  - Train tester
  - Tài liệu quá quy trình test
- Khi *đã* có sản phẩm: QC tiến hành test với test tablet

Apache OpenOffice vs Libre Office

(Look at the numbers)

Linux Live USB Creator on Windows 7

Tác giả Linux Live USB Creator hiểu Linux new comer nên làm cái app quá
bắt mắt luôn.

Baseline versus Schedule and their meanings

Ở đây, sự khác biệt, giữa
1. "project baseline": Đã được phê duyệt và
2. "project schedule": Là kế hoạch.

Từ điển không có từ "baseline". http://tratu.soha.vn/dict/en_vn/Baseline

cf. http://www.deepfriedbrainproject.com...-baseline.html

Cảm ơn bác.

Originally Posted by phnhuong

Baseline là những số liệu đã được phê duyệt khi hoạch định. Ví dụ cost baseline, schedule baseline, scope baseline. Trong khi thực hiện dự án thường xuyên theo dõi so sánh thực tế với baseline là đúng rồi

Trích từ PMBOK:
So sánh ongoing project activities với plan thì em hiểu, còn so sánh ongoing project activities với project baseline thì em thấy hơi khập khiễng và thiếu dữ liệu.