Apr 19, 2017

Óc thán thưởng

Thán thưởng: 
- từ cũ
- từ này không có trong Vietlex 2013


Mar 22, 2017

Status/Lifecycle of a bug/issue/task

Status/Lifecycle of a bug/issue/task như sau:

*New*
 Task mới được tạo, chưa assign cho ai

*In Progress (Assigned)*
 Task đã assign, đang làm

*Resolved*
 Task đã được làm xong bởi người được assigned, tự review xong. Chờ review chéo hoặc review từ cấp trên hay confirm từ khách hàng.

*Feedback*
 Vì một lý do nào đó, task bị "trả lại" cho người tạo ra nó.
 Ví dụ: Tester X tìm ra lỗi #6868 assign cho developer Y. Y kiểm tra lại và
thấy đó không phải là lỗi do mình gây ra. Khi đó Y sẽ "feedback" lại task
#6868 cho X để X assign cho người thích hợp.

*Incomplete*
 Task thiếu thông tin, cần được làm rõ.
 Ví dụ: Tester X tìm ra lỗi #6767 assign cho developer Y. Y không thể tái
hiện được lỗi đó. Khi đó Y sẽ mask task #6767 là "Incomplete" và assign cho X để X phân tích thêm.

*Closed*
 Done. đóng task.

*Rejected*
 Task sai. đóng lại.

*Pending*
 Treo task, tạm thời chưa làm.
 Có thể đẩy lùi task sang sprint sau nhưng không đóng task.

*Reopen*
 Mở lại 1 task/issue đã đóng.
 Ví dụ: Developer Y fixed xong lỗi #7070 và Tester X đã closed lỗi đó. Tuy nhiên sau đó Tester X phát hiện lỗi này chưa được fix hẳn. Khi đó Tester X reopen lại lỗi #7070.

*Verified*
 Issue/lỗi đã được verified bởi tester X sau khi tiếp nhận báo cáo lỗi từ
phía khách hàng.

*Invalid*
 Issue/lỗi sai. Failed alert. Close.

*Wontfix*
 Không phải làm. Lý do "wontfix" có thể là: báo cáo sai, chưa cần thiết
phải làm/fix trong sprint hiện tại, tuy là lỗi nhưng có workaround nên chấp
nhận được, hoặc độ ưu tiên/cần thiết của task là thấp

*Duplicated*
 Task bị trùng lặp với một task khác. Close.

*Closed*
 Done, đóng task.

Chú ý: 
Đây là những status cơ bản của một issue/ticket/bug.

Có thể đơn giản hoá vòng đời của task với các bộ status như sau:
1. New, In Progress, Resolved, Closed (Backlog.jp default status)
2. TODO, DOING, DONE (Basic Kanban)
3. TODO, DOING, VERIFYING, DONE (thêm Verifying: Kiểm tra)


​Tham khảo: ​
1. A life cycle of a bug:

2. Design a workflow with Redmine:

--
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.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to 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.

Mar 13, 2017

Tuckman's stages of group development

Tuckman's stages of group development

Các giai đoạn phát triển team:

1. Forming: Thành lập (mới, hay thay đổi)
2. Storming: Trao đổi, tranh luận
3. Norming: Ổn định 
4. Performing: Làm ra kết quả

Tình huống: 
1. Team mới thành lập
2. Team có thành viên mới join

--
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.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to 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.

Feb 16, 2017

How to write daily reports / Viết báo cáo ngày thế nào

How to write daily report 
(dành cho IT staffs, developers)

Chú ý chung
Viết report hàng ngày, vào buổi chiều tối trước đi khi về
Viết thật ngắn
Nếu đề cập tới issue: ghi issue ID (Jira, backlog.jp...)
Nội dung daily report:
Ngày hôm nay đã làm gì?
Ngày mai sẽ làm gì
Có vấn đề gì, khó khăn gì cản trở công việc không?

Các chú ý khác
- Tập hợp report ở một nơi 
- Dễ tìm
- Dễ đọc theo từng người
- Dễ đọc cho cả nhóm
- Vừa nhìn được tổng thể 
- Dễ so sánh (tiến độ, issue) của lần viết trước và sau 

Ai đọc report?
- Thành viên dự án
- Những người liên quan đến dự án
- Sếp, sếp của sếp
- Khách hàng

Viết report cho ai?
- Cho mình
- Cho tất cả những người liên quan

Tham khảo






--
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.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to 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.

Feb 15, 2017

Pair programming & Coding dojo & Agile

Tình hình:
- Team mới thành lập
- Trình độ, background, cách làm... có sự vênh.
- (Và có thể) dẫn tới mâu thuẫn âm ỉ trong team

Mục tiêu:
- Tạo sự đồng thuận trong team
- Xây dựng team agile theo hướng scrum hơn

Ý tưởng:
Team mình bỏ ra 1-2 ngày làm coding dojo (là lập trình viên chính) nhỉ?

Trong giai đoạn đầu của dự án, khi team member còn chưa thống nhất được cách làm,
có sự vênh về cả cách thiết kế, coding, xử lý vấn đề và cách nhìn vấn đề...
thì cả team ngồi lại với nhau theo cách này sẽ rất có lợi.

Chú ý:
- Chỉ có 1 keyboard và 1 màn hình
- Cả team ngồi cùng nhau
- Thay nhau code
- Người ngồi sau review giúp luôn
- Những người liên quan code phụ (nếu muốn)
- lập trình viên chính pair và code

Nếu làm pair programming thì chỉ cần Hải, Luật join là chính.
Theo cách này thì sau 1 thời gian, coder chính của dự án
sẽ như hai bình thông nhau, thống nhất được về thiết kế, coding, problem solving...

Tham khảo:
1. Pair programming
http://www.codinghorror.com/blog/2007/11/pair-programming-vs-code-reviews.html
2. Tiến thêm 1 bước nữa: Coding dojo
http://www.slideshare.net/wouterla/coding-dojo-in-5-minutes

​Nguồn ảnh: Techcrunch.​
​​

--
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.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to 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.

Feb 9, 2017

Management by objectives (MBO): Quản lý theo mục tiêu


Management by objectives (MBO): Quản lý theo mục tiêu
- Tập trung vào mục tiêu
- Dựa trên lượng tài nguyên có sẵn
- Để nhân viên hiểu rõ mục tiêu mà tổ chức, cá nhân họ cần đạt được
- Đánh giá nhân viên, tổ chức
- Các bước thực hiện
   - Đặt mục tiêu
   - Lập kế hoạch hành động
   - Theo dõi
   - Đánh giá hiệu quả

MBO cho ai?
- Nhân viên
- Sếp
- Nhóm 
- Công ty

Viết MBO thế nào?
- SMART (Specific, Measurable, Agreed/Achievable/Attainable, Realistic/Responsible/Receivablem, Time-bound)
- Rõ ràng
- Càng số hoá càng tốt  

Thời gian đánh giá MBO
- 3, 6, 12 tháng 1 lần,
- Có thể lấy các mốc review nhân viên, nhóm, phòng, công ty theo kỳ, quý, năm

MBO và KPI
- Liên quan mật thiết

MBO và BSC (Balanced Scorecard)
- Liên quan mật thiết

Cách lên MBO
- Bottom up: Từ cá nhân, tới team, phòng, ban, công ty
- Top-down: Từ chiến lược, mục tiêu công ty tới phòng, ban, team, và cuối cùng là từng cá nhân 

Giải thích

Management by objectives (MBO) is a process of defining objectives within an organization /so that management and employees agree to the objectives and understand what they need to do in the organization in order to achieve them.

The term "management by objectives" was/first popularized by Peter Drucker in his 1954/ book 'The Practice of Management'.[1]

The essence of MBO is participative goal setting, choosing course of actions and decision making. An important part of the MBO is the measurement and the comparison of the employee's actual performance with the standards set. Ideally, when employees themselves have been involved with the goal setting and choosing the course of action to be followed by them, they are more likely to fulfill their responsibilities.

According to George S. Odiorne, the system of management by objectives can be described as a process whereby the/superior and subordinate jointly identify its common goals/, define each individual's major areas of responsibility in terms of the results expected of him, and use these measures as guides for operating the unit and assessing the contribution of each of its members.[2]

Các bước thực hiện

Setting Objectives Goal-setting or objective setting is a multistage process. It starts with the examining of the current state of affaires, level of efficiency, threats, and opportunities. Then the key result areas are identified, such as product markets, improved services, lowered costs, work simplification, employee motivation, profitability innovation and social responsibility. The performance of these areas is critical for organization in the sense that failure in these areas may result in failure of the organization. And this is why they are known as "key" result areas. Peter says, objectives are important in every area where performance and results directly affect the survival and prosperity of business.

Developing Action Plans
Set objectives must be translated into action plans. It requires assignment of specific responsibilities to different departments, division, and individuals. It also requires allocation of necessary resources needed to perform the assigned responsibilities. Time dimensions are also to be decided in order that targets are reached without any unwarranted delays.

Periodic Review or Monitoring The Progress
After setting objectives and developing action plans, it is necessary to establish a proper a view to regularly keeping the activities. He progress is monitored without day path leading to the ultimate objective. It is ensured that the deviations found, if any, are thoroughly discussed and immediate corrective actions are taken to set them right on the course. Such a regular monitoring and periodic review not only provide feedback which is essential for completion of work in time. But also motivates the managers accountable for performance. Periodic review and monitoring are done at departmental level generally.

Performance appraisal
This is the last phase of MBO program that evaluates performance annually. The annual review or appraisal is comprehensive and is done at the organization level. The actual annual results are evaluated against the set objectives. Such assessment is also used for determining targets for next year, for modification in standards (goals0 if needed, and for taking corrective actions in order to avoid deviations form predetermined objectives.


--
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.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to 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.

Jan 26, 2017

Apache Voting Processes

Quy trình vote của Apache

0. Lazy vote

 Không cần mất thời gian, chỉ vote "đồng ý", "phản đối" hay "phiếu trắng"
 Lấy ý kiến, sự đồng thuận từ rất nhiều người (cả team) trong thời gian ngắn
 

1. Các tuỳ chọn vote cơ bản
 +1: Đồng ý
 -1: Phản đối
 0: Không có ý kiến (phiếu trắng)
0.x: Không/ít dùng (hơi hơi phản đối, hơi hơi đồng ý...)
 
2. Các tuỳ chọn khác 

+0: 'I don't feel strongly about it, but I'm okay with this.'
-0: 'I won't get in the way, but I'd rather we didn't do this.'
-0.5: 'I don't like this idea, but I can't find any rational justification for my feelings.'
++1: 'Wow! I like this! Let's do it!'
-0.9: 'I really don't like this, but I'm not going to stand in the way if everyone else wants to go ahead with it.'
+0.9: 'This is a cool idea and i like it, but I don't have time/the skills necessary to help out.'

3. Lợi ích
 - Tốn ít thời gian
 - Thích hợp với remote team 
 - Phù hợp với các nhóm kỹ thuật 
 
4. Quy trình vote của Apache thích hợp ở đâu?
 - Dùng lúc nào cũng được
 - Vote nhanh
 - Hay vote chậm 

5. Tham khảo 

--
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.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to 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.

Jan 20, 2017

Running a Retrospective Meeting

Overview/Giới thiệu

Cuộc họp retrospective là cuộc họp quan trọng nhất trong. Nó quyết định sự thành công và độ ổn định lâu dài của nhóm Scrum. Việc khung làm việc của Scrum không định nghĩa rõ về cuộc họp này tạo sự sáng tạo và đặc thù riêng theo từng nhóm.

Tuy vậy, việc thể hiện những giá trị cốt lõi của Scrum trong cuộc họp này – minh bạch, thích nghi và cải tiến liên tục – không phải là điều dễ làm.

KPT

KPT là một cách làm retrospective theo kiểu Nhật.
"K" = Keep là những việc tốt nên keep (duy trì) trong thời gian tiếp theo.
"P" = Problem, là những tồn tại (việc xấu) trong thời gian vừa qua cần được giải quyết.
"T" = Try, là những việc cần thử nghiệm về sau này.
KPT tương ứng với giai đoạn "C" (check) trong mô hình PDCA (Plan-Do-Check-Action)
So sánh KPT với các phương pháp chạy một cuộc họp Retrospective, ta sẽ thấy các điểm chung.

Mô hình PDCA chính là sự cải tiến liên tục. Tương tự như thế, khi Retrospective – cuộc họp cuối của một sprint – kết thúc, cũng là lúc một sprint mới bắt đầu với kế hoạch mới, hành động mới.

Starfish Model/Mô hình Sao biển

Theo cách này, bảng trắng được chia thành các múi, giống như Sao biển với các ô tương ứng
  1. start doing: Bắt đầu làm cái này
  2. stop doing: Dừng không làm cái này nữa
  3. keep doing,
  4. more of,
  5. less of


Team Radar

Không dùng. Đây là cách cho điểm từ 1 đến 10 các tiêu chí cần đánh giá. Có lẽ cách làm này phức tạp nhưng "pick brain" được team member và cách thể hiện khá nghệ thuật một cách khoa học. Cách làm Team Radar có thể xem thêm trong cuốn "Agile Retrospectives: Making Good Teams Great".

Conclusions/Kết luận

Có nhiều cách làm Retrospective. Một trong những mục đích cuối cùng của Retrospective là để nhóm nhìn lại những điểm tốt xấu đã làm trong nhịp trước, tạo tiền đề làm bàn đạp cho việc Kaizen của (những) sprint tiếp theo.

Chúng tôi lựa chọn một biến thể của KPT để thực hiện Retospective. Lý do của sự lựa chọn khá đơn giản: Nó được thực hiện từ nhiều năm nay như một thứ văn hóa ăn và máu của của Nhật.

References/Tham khảo

  1. https://proessler.wordpress.com/2011/08/31/agile-team-retrospective-activities-starfish-team-radar/
  2. http://agile-and-testing.chriss-baumann.de/2012/02/the-starfish-retrospective/
  3. https://www.thekua.com/rant/2006/03/the-retrospective-starfish/

--
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.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to 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.

Jan 6, 2017

Agile/Scrum/Kanban/Lean Learning Resources (in Vietnamese)


--
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.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to 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.

Jan 5, 2017

TiDD: No Ticket, No Commit

TiDD là gì?
Ticket-Driven Development (Phát triển hướng ticket).

Ai phát triển TiDD
Một bác Nhật xây dựng và đặt tên cách quản lý dựa trên ticket, lấy ticket làm trung tâm là TiDD. 

Khởi nguồn của TiDD
Tác giả của TiDD dùng Redmine, là task management tool để phát triển dự án phần mềm. 

"No Ticket, No Commit"
  1. Đây là nguyên tắc cơ bản của TiDD.
  2. Phải có ticket trước thì mới commit.
  3. Một commit phải tương ứng với một ticket nào đó.
  4. Ticket này là yêu cầu công việc, là lý do mà một developers commit mã nguồn của anh ta.

Vì sao cần "No Ticket, No Commit"
  1. Để biết vì sao, ta làm cái gì.
  2. Để biết DoD (Definition of Done) ra sao 
  3. Để mọi người hiểu được công việc rõ ràng hơn (không chỉ developers)

Có ticket nào không tương ứng với commit?
  1. Có, những task không liên quan đến mã nguồn như hỗ trợ khách hàng, tìm hiểu.
  2. Không. Nếu hiểu "commit" rộng hơn nghĩa "commit mã nguồn" và đối tượng của việc commit là "thay đổi một cái gì đó của hệ thống". 
  3. Hiểu rộng hơn, "cái gì đó" ở đây là "configuration" (như trong CM: Configuration Management". 

"Cấu hình" là gì?
  1. Cấu hình (Configuration) bao gồm mã nguồn, tài liệu, cấu hình hệ thống, máy chủ, server...
  2. Việc chỉnh sửa cấu hình là việc của những người liên quan đến dự án.
  3. Việc chỉnh sửa mã nguồn (một loại cấu hình) là việc chính của developers.
  4. Việc chỉnh sửa các cấu hình khác thuộc về thành viên dự án, ví dụ: Chỉnh sửa file ảnh, chỉnh sửa tài liệu hướng dẫn sử dụng, sử dụng tài liệu thiết kế hệ thống.

Quản lý cấu hình thế nào?
  1. Một cách lý tưởng, mọi thứ (cấu hình) được quản lý trong một hệ thống có hỗ trợ version (Version Control System: VCS).
  2. SCCS (Source code Control System) là công cụ quản lý mã nguồn. 

Một số biểu hiện (người/cách làm) không tuân theo TiDD
  1. Developers tự nhiên commit, không rõ lý do,
  2. Comment trong git trống không,
  3. Developers hotfix mà không hiểu vì sao ,
  4. Thay đổi của hệ thống không được theo dõi (tracking),
  5. Thông tin về quản lý hệ thống/phần mềm không thông suốt,
  6. Release Note không đủ, rõ ràng, phải làm bằng tay.

Quan điểm về TiDD
  1. Việc quản lý dự án lấy ticket làm trung tâm.
  2. Việc phân chia công việc và quản lý tiến độ dựa trên ticket.
  3. Không có ticket thì cấm commit.

Quy định trong TiDD
  1. *No Ticket, No Commit 

Một số loại tickets
  1. Bugs
  2. Yêu cầu thay đổi
  3. Phát triển chức năng mới
  4. Phân tích tính khả thi của công nghệ mới
  5. Tạo tài liệu thiết kế 
  6. Hãy release vào ngày 2017/01/01 với 30 yêu cầu có ticket ID như sau 

TiDD đem lại điều tốt lành gì?
  1. Ai, bao giờ, làm gì: đều track được từ ticket. Qua đó communication thông suốt hơn,
  2. Việc quản lý thay đổi của nội dung/yêu cầu công việc dễ dàng hơn (chỉ cần thay đổi ticket tương ứng),
  3. Release dễ hơn,
  4. Test dễ hơn (dựa trên ticket),
  5. Workflow của dự án tuân theo workflow của ticket, dễ nhìn hơn.

Cần gì để thực hiện TiDD 

  1. (Bắt buộc) Source code management system như git, subversion,
  2. (Bắt buộc) Ticket managment system như redmine, backlog, Jira...
  3. Wiki hay một hệ thống quản lý văn bản hỗ trợ versioning,
  4. Hệ thống versioning khác để quản lý CM (tài liệu...)


--
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.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to 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.

Dec 31, 2016

Học chủ động: Quá sức với người Việt không?

Học chủ động: Quá sức với người Việt không?

Phát biểu: Người học cần chủ động
Người học: Chúng tôi chưa/không biết cách tự học!
Người dạy: Chúng tôi sẽ dạy cách tự học trước khi học

Funix: Đừng dạy nữa, mà chỉ hướng dẫn thôi 
Người học: Nếu tôi biết cách tự học thì tôi cần phải bỏ tiền, đến trường không?

Cá nhân mình nghĩ: Tự học phương pháp tự học là quan trọng nhất :slight_smile: Mâu thuẫn chưa.

Quan sát người Việt với việc tự học, mình quan sát và thấy học chủ động (active learning) chỉ thích hợp với một số rất ít người Việt.

Điều đáng buồn là những người chủ động học được thì họ không cần nhiều hướng dẫn, bản thân họ "giỏi" (trong việc (tự) học) sẵn rồi.

Triết lý giáo dục này liệu có áp dụng cho 80% lượng sinh viên, người học còn lại không?

Với 80% đó liệu cách giáo dục hiệu quả lại là dạy thụ động à.

Nghe có vẻ không đúng lắm. 

--
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.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to 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.

Dec 14, 2016

Lê Thẩm Dương nhận định về nhân sự Việt

Lê Thẩm Dương nhận định về nhân sự Việt

  1. Cần cù nhưng dễ thoả mã
  2. Thông minh nhưng đối phó
  3. Khéo léo nhưng nửa vời
  4. Tụ tập nhưng không đoàn kết
  5. Xởi lởi nhưng không bền
  6. Đoàn kết chỉ khi khó khăn
  7. Đố kỵ khi thành công 

--
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.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to 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.

Dec 7, 2016

SSL and TLS: a brief comparison

SSL và TLS khác nhau thế nào?

SSL có an toàn không?
- Đủ an toàn ở mức thuật toán
- Nói "SSL bị hack" là oan cho thuật toán SSL. Implementation cho SSL bị crack bằng lỗ hổng nào đó thì đúng. 

TLS/SSL và HTTPS

History of TLS
- 1.0, 1.1, 1.2

History of SSL
- 1.x, 2.x, 3.x

TLS vs SSL
TLS 1.0 = SSL 3.1
TLS 1.1 = SSL 3.2
TLS 1.2 = SSL 3.3

RFC về TLS và SSL
Nên đọc (rất khó hiểu, dài)


--
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.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to 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.

Dec 2, 2016

Positive Thinkings for IT engineers

Tư duy tích cực cho dân IT:
  1. Đừng bàn lùi 
  2. Thay vì trình bày vấn đề, hãy đưa ra giải pháp
  3. Tạo cảm giác dễ chịu cho người nghe/xung quanh
  4. Ba xoa một đập
  5. Chê nhẹ nhàng; khen đúng. Xem cuốn "Đắc nhân tâm"
  6. Hài hước: Cuộc sống tươi đẹp hơn với những nụ cười, hãy đem nó tới cho đồng nghiệp và những người xung quanh ta
  7. Đúng mực: Đừng tỏ ra bề trên, đừng coi thường (ý kiến) người khác 
  8. "Em không làm được đâu": Chưa làm sao biết. Thử đi, thất bại cũng được. 
  9. "Em chưa làm cái đấy bao giờ": Cũng chưa làm qua cả. Thử đi. Những phát minh, phát kiến đều bắt đầu bằng ý tưởng điên rồ, sự tò mò cái mới...
  10. "Em không có thời gian làm đâu": Bạn có thời gian lướt Facebook thì cũng có thời gian thử. Thời gian làm có. Thử đi, trong một khoảng thời gian nào đó, ví dụ 2 ~ 3h, hay 2 ~ 3 ngày, nếu không ra kết quả tốt thì tổng kết và dừng sự thử nghiệp.
  11. "Không có cách khác đâu": Chắc chắn có cách khác. Cách khác có thể tốt hay không tốt hơn nhưng ít nhất là bạn dám thử, dám thất bại, có sự so sánh giữa cách này và cách kia.
  12. "Em làm mãi thế rồi, đừng thay đổi cách làm": Em làm thế đã đủ tốt chưa? Đã thử cách làm mới chưa, và kết quả ra sao? Cứ thử đi, thất bại cũng được (không bị trách đâu)
  13. "Thế này là tốt lắm rồi". Có cách nào làm tốt hơn không?
  14. "Khó quá": Đừng nói câu này. Nếu khó thì phải làm gì?

Tham khảo: 
​​

--
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.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to 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.

Nov 26, 2016

Blockchain technology

Blockchain technology:

1. Được dự đoán là một xu hướng (công nghệ: "disruptive potential of blockchain technology") của năm 2016+
2. Nhiều tổ chức (tài chính) đang nghiên cứu. Ví dụ: Deloitte, PWC
3. Nhiều dịch vụ về Blockchain đã được cung cấp

Một vài từ khoá liên quan:

- Blockchain
- Finance
- Banking
- Anti-Money Laundreing (AML)
- Know Your Customer (KYC)
- Bitcoin
- FinTech 
- Finance Services 
- P2P (peer-to-peer)

Q: Ứng dụng của blockchain là gì (ngoài lĩnh vực finance)
(payment,insurance, asset management, retail banking, capital markets, real estate)

Mình đã từng được à ơi một dự án về Blockchain.
Có vẻ như các đối tác nước ngoài chưa tin tưởng Việt Nam lắm nên chưa lấy dự án về được. 

--
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.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to 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.

Nov 5, 2016

Estimation and NoEstimation

#Estimation and #NoEstimation

"Please estimate a bug fix", asked my boss.

"Can a detective estimate, how much time he will take to solve a murder mystery"

I quit :)
#dcmtb

Oct 20, 2016

Tổng kết/Wrap-up: Agile Singapore 2016


Tóm tắt
Đây là bài tổng kết, ghi nhận về những gì tôi/Nguyễn Vũ Hưng ((board) member của Agile Vietnam), được Agile Singapore mời (free entrance ticket, tự túc đi lại lại, khách sạn) tới sự kiện Agile Singapore 2016

Đối tượng đọc
- Những người có quan tâm đến Agile
- Những người (muốn) tổ chức sự kiện (liên quan đến Agile), tầm cỡ quốc tế

Cảm nhận chung
 Đây là sự kiện lớn, nhiều diễn giả tầm cỡ thế giới, tổ chức chuyên nghiệp, chất lượng (rất cao)

Chi phí
Cá nhân: Vé máy bay 2 chiều Hà Nội - Changi + 3 đêm khách sạn (hạng thường) (100 SGD x3). Vé vào cửa (800 SGD: được Agile tặng với lý do: Ông Hưng đóng góp cho Agile Vietnam nhiều :D)

Chi phí cho diễn giả
Bao đi lại + khách sạn. Đây là chi phí rất lớn với các diễn giả lớn, đa số từ Mỹ sang

Diễn giả
- Martin Fowler là diễn giả lớn, tầm cỡ số 1 thế giới (ở một số mảng)
- Mary & Tom Poppendieck: Số một thế giới về Lean
- Các diễn giả khác: Đều là những tác giả sách nổi tiếng, hoặc là/làm Agile coaches. Một số diễn giả khác, ít tên tuổi hơn, là người local (ở Sing)

Khách sạn (Fort Canning Hotel)
- Sạch sẽ, một phòng lớn + 3 phòng làm session (cũng rất lớn)
- Thiết bị hiện đại, nhân viên khách sạn care hết
- Vị trí thuận tiện 
- Khách sạn nằm trong một công viên lớn (Fort Canning Park)

Logistics
Không nhiều (vì đã dùng hết dịch vụ của khách sạn)
Stanly Lau việc chính là đi pha cà phê 

Ăn uống
Buffet, đặt từ khách hạn.
Tea breaks (ăn nhẹ, cà phê...)
Với 800 SGD thu từ người tham gia thì các bữa ăn + tea break cũng khá tốn 

Sponsored keynote
Là keynote speech của sponsor, được nói trong lúc mọi người ăn trưa.
Suy nghĩ: Sponsor bỏ tiền ra, và họ có quyền yêu cầu lợi ích gì đó

Đối tượng tham gia
Speaker (khủng): đa số từ Mỹ
Một số local speakers ở Sing, chất lượng cao
Người tham gia đến từ nhiều nước: Mỹ, Việt Nam, Nhật, Thái, Malaysia, Ấn Độ, Singapore
Người tham gia từ Singapore có lẽ là nhiều nhất (hiển nhiên)

Về các bài nói chuyện
Về bài của Martin Fowler
 Nói hay, rất cuốn hút, xứng đánh số 1 thế giới :) 

 Design Stamina Hypothesis
 Long-term factoring
 The ecconomics of refactoring
 Comprehension refactoring
 Agile vs plan-driven 

Về bài của Mary Poppendieck (#1)
 Khá hay. Ảnh trong slide của Mary *đều* là do Tom chụp.

Về bài của Mary Poppendieck (#2)
 Khá hay. Ảnh trong slide của Mary *đều* là do Tom chụp.

Về đội tình nguyện viên 
 10+ người
 Việc không nhiều
 Tổ chức tốt, chuyên nghiệp,
 Tự giác, tự lập 

Quay phim/chụp ảnh
 Quay phim full mọi session. Có lẽ là thuê ngoài. Khá nhẹ nhàng. Thiết bị tốt
 Mọi speakers đều có lazer points, có máy ghi âm gắn ở áo 
 Các phòng sự kiện đều có loa ấm, đủ nghe cả phòng (đẳng cấp)

Tiếng Anh
 Singlish: Đủ nghe, hơi khó nghe 
 Tiếng Anh của speakers: 1) Từ Mỹ: Khá dễ nghe 2) Từ các nước khác như Đức: Cũng khá dễ nghe 

Việt Nam cần gì để tổ chức một sự kiện như thế không?
Vì sao không nhỉ? Chúng ta hoàn toàn làm được
Stanly nói Agile 2016 là Agile Conference cuối cùng (mấy lần "cuối cùng" rồi)
Việt Nam có thể host tiếp nhỉ? 

Xu hướng năm 2016
- Con người 
- Infra outsourcing 

Các điểm khác:
- Nhiều sponsor
- Nhiều booths
- Hoạt động kiểu "Agile"
- Thẩm mĩ
- Tặng sách
- Wefie contest
- Tag chung #agilesg16
- Nhiều mẫu áo, nhiều mầu, nhiều size
- Mũ phớt: Đẹp 
- Sách của Jutta Eckstein (Retrospectives for Organizational Change) https://www.flickr.com/photos/vuhung/30131530726/in/album-72157675046803715/

Thông tin về Agile Singapore 2016


--
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.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to 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.