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.

Sep 24, 2016

Nim game

Nim game:

Counting to S (=30)

- Số người chơi: 2
- Mục đích: Người nào nói số S thắng
- Người đầu tiên bắt đầu từ số 1
- Mỗi người được nói tối thiểu một, tối đa N (=2) số trong lần nói của họ (không được skip). 
- Người nói tiếp theo phải bắt đầu từ số kế tiếp của người nói trước. 
- Ví dụ, người đầu tiên nói "1", người thứ hai có thể nói "2" hay "2, 3"
- Ngừoi nào nói số S (=30) là người chiến thắng 

Bài tập:
1. Hãy chơi game với S = 10, 20 (nhỏ)
2. Hãy chơi game với N = 2 hay 3
3. Hãy tìm chiến lược cho người đi trước (hoặc sau), luôn thắng
4. Tìm điều kiện (giữa S và N) để đảm bảo người đi trước luôn tìm được chiến lược thắng

Câu hỏi:
Những lý thuyết số học gì đằng sau bài toán này?

Cu lớp 1 nhà mình tìm được chiến lược với S = 30, N = 2

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.

Sep 20, 2016

Problems and solutions with slack


Hiện trạng sử dụng slack:
- 6 team
- Tổng số 5 - 20 channels trong mỗi sites
- Khoảng 5 - 10 thành viên trong mỗi sites/channels

Chưa hài lòng/chưa làm tốt:
- Quá nhiều team
- Quá nhiều channel
- Check vẫn bị sót thông tin

Slack làm tốt:
- PC hay mobile đều xem được
- Tốc độ xử lý nhanh
- Ai cũng xem được (nếu muốn, online), luôn và ngay
Phải chăng là mình (biết cách) chưa dùng slack hiệu quả?

Giải pháp (để cải thiện):
- Dùng shortcuts (Ctrl-1, 2, 3, 4), 
- Dùng alt+shift+(lên/xuống arrow) để move giữa các channel mà có unread message
- Giảm lượng việc, dự án, thông tin cần phải xử lý

Nguyên nhân cốt lõi:
- Nhiều việc, nhiều dự án, nhiều thông tin quá 


--
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.

Sep 11, 2016

Raw estimation for unclear requirement

Yêu cầu từ khách hàng:
Hãy estimte các task (khoảng N = 50) trong một sprint, theo giờ.

Bối cảnh:
Khách hàng yêu cầu thêm/sửa khoảng N issues.
Team chưa rõ những yêu cầu này.
Có thể dùng planning poker để estimate.
Tuy nhiên, công cụ quản lý issue của dự án là backlogtool, không hỗ trợ point estimte, nên nhóm quyết định estimate theo giờ, ghi số giờ vào backlog trong cột "số giờ dự định" cũng như "thời điểm" bắt đầu.

Quy ước về cách sử dụng số giờ: 
- 1h, 2h, 4h: Task nhỏ, yêu cầu khá rõ ràng
- 8h: Task lớn, có thể làm trong tầm 1 ngày, có thể nhiều hơn hoặc ít hơn
- 16h, 24h, 32h: Task rất lớn, team chưa hiểu yêu cầu, chưa estimate được (chính xác), cần làm rõ yêu cầu với PO, cần phân tích mức độ ảnh hưởng của issue với hệ thống/module hiện tạ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.

Aug 15, 2016

What Google recommend IT/CS students about learning?

Google gợi ý một số nội dung, khoá học cho sinh viên. 

Vài điểm nhấn:

- Google cần computer science, không phải software engineering
- Các ngôn ngữ lập trình được gợi ý chủ yếu là scripting và focus và Web technologies
- Kỹ năng tự test là quan trọng
- Có khả năng sư phạm (để hướng dẫn người khác)
- Nhiều kiến thức cao cấp được đòi hỏi: Cryptography, AI, Parallel programming, 
- Tham gia các dự án nguồn mở
- Hiểu rõ về OS (môn học khó)
- Hiểu rõ về logic (không chặc chẽ về logic, thậm chí không thông tam đoạn luận thì không thể trở nên (kỹ sư) giỏi)

Xem: 


--
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.

Jul 19, 2016

What PHP full stack developers need

Thu nhập của một full stack developers 
- Khoảng 1000$+ theo giá thị trường ở thời điểm hiện tại, tháng 6 năm 2016

PHP full stack developer là gì 
- Là một senior web developers
- Làm được tất cả mọi việc, từ việc nhận yêu cầu từ khách hàng, phân tích, đề xuất, estimate, thiết kế, lập trình, sửa lỗi, test, triển khai, bảo trì

PHP full stack developers làm gì (cụ thể hơn)?
- Thiết kế đồ hoạ, sử dụng, ví dụ Photoshop, Illustrator, 
- Frontend technologies: HTML, CSS, JavaScript, PHP
- Backend technologies: PHP và các công nghệ liên quan
- Quản trị server
- Network
- Và những gì liên quan khác, cần cho công việc
- Tư thế sẵn sàng làm những việc gì cần, khó hay dễ, thú vị hay nhàm chán... để hoàn thành công việc 

Development stack gồm những công nghệ gì
- LAMP (OS: Linux (và OS khác như Windows nếu cần), Web/application server: Apache/nginx, Database: MariaDB/MySQL/PostgreSQL, PHP (với ngôn ngữ script khác: Ruby, Python...)
- Quản trị, theo dõi, vận hành hệ thống 
- UI/UX, design 

Cụ thể hơn về các công nghệ

Quản trị hệ thống:
  1. Linux, shell scripting (cơ bản)
  2. Cloud computing: Amazon, Rackspace...
  3. Background processing: Gearman, Redis
  4. Search: Elasticsearch, Sphinx, Solr
  5. Caching: Varnish, Memcached, APC / OpCache
  6. Monitoring: Nagios

Công cụ phát triển Web:
  1. Version control: Git, Mercurial, SVN
  2. Virtualization: VirtualBox, Vagrant, Docker

Back-end tech:
  1. Web servers: Apache, Nginx
  2. Programming language: PHP, NodeJS, Ruby
  3. Database: MySQL, MongoDB, Cassandra, Redis, SQL / JSON 

Design:
  1. Converting website design into front-end code
  2. UI
  3. UX
  4. Mockup tools như balsamiq
  5. Thiết kế màn hình/giao diện 

Biết thêm về mobile technologies
  1. iOS
  2. Android
  3. Hybrid: PhoneGap, Appcelerator
Các kỹ năng khác:
  1. Thiết kế, lập trình web service
  2. Phân tích, thiết kế  database
  3. Phân tích nghiệp vụ, viết tài liệu đặc tả nghiệp vụ
  4. Phân tích, viết tài liệu thiết kế cơ bản, chi tiết
  5. Test tự động
  6. Developer testing
  7. Tự động hoá (dùng shell script)


--
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.

Jul 7, 2016

Members Left Because of Technical Debt

Tình hình:
Thành viên dự án xin nghỉ và lý do là "em thấy mã nguồn bẩn quá" và "làm mãi ở dự án, gần một năm mà không học được gì"

Phân tích lý do:
Khi nhận được thông tin member xin nghỉ, quản lý/SM giả định nhiều lý do: Lương, thưởng thấp, mâu thuẫn với đồng nghiệp, lý do cá nhân, bạn bè lôi kéo.
Member xin nghỉ vì họ có lý do nào đó, mỗi tình huống xin nghỉ đều có lý do khác nhau, và trong trường hợp này "mã bẩn", "không học được gì" là hai lý do chính

Mã nguồn bẩn:
Đây là một dạng technical debt. Dự án đã phát triển trong trạng thái không kiểm soát về mã nguồn, kiến trúc. Một số biểu hiển về sự bẩn của mã nguồn:

  • Nghiệp vụ lung tung
  • Đọc code spaghetti không hiểu được, học khó hiểu
  • Với yêu cầu từ khách hàng, developer phải đi "mò" những yêu cầu ẩn
  • Dự án có nghiệp vụ phức tạp nhưng không có tài liệu về nghiệp vụ, quy trình, thiết kế 
  • Dự án sử dụng CodeIgnitor như mô hình MVC và kiến trúc không được tuân thủ tốt
  • Coding convention không được tuân thủ 
  • Không có tài liệu thiết kế database. DB không có annotation
  • Luôn xảy ra nhu cầu cần sửa đổi cấu trúc DB, tên trường trong DB do thay đổi nghiệp vụ
  • git pull request không được review (dù có cơ chế approve) tốt 
  • (HMLT) Data table đơn giản, ít chức năng, cần phải code nhiều khi có yêu cầu thay đổi từ khách hàng (như: sorting, hide/unhide trường, dữ liệu, điều chỉnh độ rộng cột, hàng, inline edit cell (giống Excel)

Không học được gì:
  • Dự án không thực sự có một người mạnh về kỹ thuật ở mức "technical lead", dẫn dắt team về định hướng kỹ thuật 
  • Kỹ thuật sử dụng trong dự án không có gì nổi trội 
  • Không được hướng dẫn
  • Không được hỗ trợ gì nhiều từ những người có kinh nghiệm hơn (họ bận việc khác)
  • Phản biện: Liệu member này thiếu sự tự giác, tự chủ, cầu tiến hay không?
  • Các framework kỹ thuật dùng trong dự án cũ kỹ 
  • Dự án/sản phẩm thiếu một vision dài hạn và mục tiêu ngắn hạn (member lo lắng cho tương lai của dự án/của bản thân mình)
​Giải pháp:
  1. Trả nợ technical debt càng sớm càng tốt
  2. Viết tài liệu cho hệ thống
  3. Viết thiết kế cho hệ thống
  4. Tổng hợp know-how, kiến thức cho hệ thống, từ developers, members trong team
  5. Tổ chức test festival để thu thập kiến thức, tìm ra một cái nhìn chung về cách hệ thống chạy, requirement, tìm lỗi hệ thống
  6. Tổ chức code review festival để chia sẻ hiểu biết về code, tìm ra bất cập về mã nguồn
  7. Tổ chức retrospective thường xuyên để tìm ra những điểm bất cập, những điểm cần/có thể improve 


--
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.

Jun 11, 2016

Backlog Management for Product Owner

Tình huống
Một dự án phát triển P bao gồm 5 developers và một scrummaster (hoặc project lead/project manager... tuỳ theo cách bạn gọi) chung sống và phát triển một phần mềm vui vẻ.

Họ sử dụng một dạng kanban để quản lý công việc của họ. 
Các lane trong kanban khá đơn giản và cơ bản, bao gồm TODO, DOING, VERIFIED (đã test) và DONE (hoàn thành).

Họ sử dụng cycle, theo cách gọi khác là sprint/iteration là 2 tuần. 
Cứ mỗi cuối 2 tuần, họ archive những công việc đã DONE, tiếp tục chuyển các công việc từ TODO sang DOING và tiếp tục công việc.
Cách sử dụng của họ có vẻ lẫn, hay áp dụng phối hợp những thói quen của các khung làm việc Scrum, Scrumban và Kanban.

Cho đến một ngày, Product Owner từ phương trời xa đến join vào dự án.
PO chưa có thói quen sử dụng phần mềm để quản lý yêu cầu.
Tuy nhiên, khi nhìn thấy công cụ kanban mà nhóm phát triển sử dụng, PO thích ngay mà muốn dùng kanban để quản lý chính công việc của anh ta, cùng đội phát triển.

Các cách tiếp cận
Một developer có kinh nghiệm khuyên rằng, khi chưa quen với backlog, kanban và các công cụ, PO có thể đưa rất cả các yêu cầu, nguyện vọng, phản hồi của anh vào TODO và nhóm sẽ sử lý dần. 

PO gật đầu và làm theo cách đó một thời gian

PO nhận ra rằng nhu cầu quản lý công việc cần làm (backlog) của PO nhiều hơn là TODO.

Sau một thời gian sử dụng cột TODO, trao đổi với nhóm phát triển hàng ngày, kéo thả task từ TODO sang DOING, VERIFY những gì mình yêu cầu, PO phát triện ra rằng workflow của anh nhiều hơn thế. Anh không chỉ cần biết những gì cần phải làm.

PO cần một backlog như thế nào?
Việc quản lý yêu cầu (backlog) thuộc về PO. 
Những ý tưởng bất chợt đếu với PO cũng cần được ghi lại.
Những công việc, feedback từ stakeholders mọi nguồn cũng cần được PO lưu lại.

Hơn thế nữa, anh cần đánh giá độ ưu tiêu của các công việc này. Cái gì cần làm trước, cái gì làm sau, cái gì quan trọng hơn... đối với từng stakeholder, với chính bản thân anh ta và chính dự án. 

Đội phát triển cũng involve, ở thời điểm thích hợp 
Sau khi có một danh sách backlog có độ ưu tiên đứng từ góc nhìn của PO, những yêu cầu này được trao đổi đội phát triển để quyết định một số điểm như: 1) tính khả thi, 2) bao giờ nhóm có thể bắt đầu 3) mất khoảng bao nhiêu giời gian và dự định hoàn thành.

Những nội dung trên cần sự trao đổi và đồng thuận giữa PO và nhóm phát triển.

Một số trường hợp dễ thấy:
  1. PO muốn, nhưng dev team không thể đáp ứng về mặt kỹ thuật, năng lực hay thời gian,
  2. PO muốn, nhưng dev team quá bận vì những tác vụ khác, do đó không làm được. 

Những yêu cầu từ phía PO được cho là "OK" khi nhóm phát triển tự tin rằng họ có thể thoả mãn yêu cầu của PO mà không cần hỏi thêm gì nhiều. 

Tới thời điểm này, việc định nghĩa yêu cầu công việc được coi là xong. 
Tiếp đó, nhóm phát triển làm việc được giao và khi họ xong, sản phẩm đầu ra được VERIFY bởi PO (là tốt nhất)

Sau khi yêu cầu được đưa vào DOING, nhóm phát triển phát triển theo quy trình mà họ đã quen thuộc. 

JIRA/Atlassian đã làm tốt việc trên, mô trình trên được JIRA mô tả và sử dụng như sau.

Chia "TODO" thành các lane,
(từ trái qua phải) 
- Not ready yet: Feedback thô đối với nhóm dev. Những task dạng này cần PO, stakeholder trao đổi rõ ràng hơn, trả lời câu hỏi: 1) Họ muốn gì? 2) Thay đổi (high level...) thế nào 
- "Not ready yet" được (tiền xử lý) sao cho thông tin đơn giản, dễ hiểu và được đưa vào "Unprioritized". Unprioritized nghĩa là, những công việc trong lane này là các việc phải làm, nhưng chưa được đô tiên và đã khá rõ ràng hơn là ý tưởng thô.
- Ready for dev team: Nhóm dev hài lòng về độ chi tiết của yêu cầu và sẵn sàng kéo sang cột DOING

Lưu lý:
Backlog quản lý bằng kanban ở đây có chức năng: Thể hiện độ ưu tiên cuả công việc theo một cách nào đấy, tốt nhất là đánh số được theo chuỗi 1, 2, 3... trong đó: việc số càng nhỏ thì độ ưu tiên càng lớn. 

Nếu không thể sử dụng chuỗi số, PO có thể đánh độ ưu tiên theo thứ tự: High, Medium, Low...

Tham khảo:
The JIRA roadmap backlog has four major states:

  1. Not ready yet: Raw feedback
  2. Unprioritized: Committed to the back log, but not ready for handoff to development
  3. Ready for feature teams: The feature teams should work on the highest priority items first
  4. In design (PM and Dev): The feature story is actively being worked on



--
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.

May 30, 2016

Lần (từ cũ)


​Lần:

- trong "tôi tự học" của Nguyễn Duy Cần
- chưa có trong Vietlex 2013 anh nhỉ?
- Nghĩa là "dần dần" (theo em thế)

Ít thấy từ "lần" đứng độc lập.

--
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.

May 16, 2016

アジア撤退企業に共通する「日本式マネジメント」の時代錯誤/Những điểm chung về quan điểm quản lý sai lầm của các công ty phải từ bỏ Asia

アジア撤退企業に共通する「日本式マネジメント」の時代錯誤/Những điểm chung về quan điểm quản lý sai lầm của các công ty phải từ bỏ Asia:

1. ちょっと進出してみてダメだったら引き上げる。本気でアジア進出してほしいですね。 Quan điểm "làm thử" nửa vời khi thâm nhập (thị trường) Asia. Hãy làm thật luôn đi. 
2. 海外進出の問題点(1) 日本式を押し通しすぎる / Áp dụng cách làm kiểu Nhật quá cứng nhắc (và thất bại)
3. 海外進出の問題点(2) 現地人材のマネジメントができない / Nhiều công ty Nhật chỉ outsource cái không phải core tech/biz của họ. Họ không cần người tài ở bản địa. Chuyện người Nhật kém quản lý người bản địa giỏi: Thường thấy 
4. 日本企業がアジアで苦戦するのは「アジアNo.1」思考に原因がある / Đừng cố, vì Trung Quốc nó to lắm
5. 「皆が集まる会議」が多すぎる / Cơ chế ra quyết định chậm, nhiều ringi


--
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.

May 11, 2016

Training, mentoring and coaching: Giống, khác nhau thế nào?

Giới thiệu
Bài viết này giới thiệu ngắn gọn sự giống và khác nhau cơ bản giữa training, coaching và mentoring trong phạm vi giáo dục cho người đã đi làm, cụ thể hơn là nhân viên IT qua trải nghiệm của các nhân tôi (Vũ Hưng)

Tạm dịch và giải thích từ ngữ
Training: Là đào tạo theo cách thông thương chúng ta thường thấy. Việc dạy trong trường trường học là training
Coaching: Huấn luyện. "Huấn luyện viên" trong bóng đá được gọi là "coach"
Mentoring: Hướng dẫn

Đây là ba hình thức phát triển (cá nhân) và đều thuộc phạm trù giáo dục.

Các điểm chính 
  1. Training: Dạy học theo một chương trình đã lên kế hoạch sẵn về một kỹ năng, kỹ thuật dùng trong công việc hiện tại hay tương lai. Hiểu đơn giản, "training" là dạy, thường là bị động và một chiều.
  2. Coaching: Hướng dẫn 1-1 (hoặc 1-N) về việc phát triển kiến thức, kỹ năng, khả năng của cá nhân giúp tăng hiệu quả công việc. Điểm nhấn ở đây là huấn luyện viên làm việc/giúp đỡ 1-1 với người được hướng dẫn. 
  3. Mentoring: Người có nhiều kinh nghiêm và hiểu biết hơn hỗ trợ việc phát triển người khác. Mentoring tập trung và quan hệ giữa người truyền kiến thức và người nhận kiến thức.

Đón đọc
  1. Các hình thức coaching
  2. Các tình huống sử dụng coaching
  3. Active learning, một hình thức học mới
  4. Vì sao training không hiệu quả với công ty (mà phải dùng coaching)?
Tài liệu 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.

May 5, 2016

Closing a Project: What you need to do as a Project Manager

Tình huống

Bạn là một project manager (PM) (hay Scrummaster (SM)) được điều động vào một dự án phát triển (phần mềm) thay thế PM/SM cũ. Dự án đang ở giai đoạn cuối. Theo báo cáo từ PM/SM cũ, dự án "gần xong, một chút nữa là xong" nhưng một số cái (deliverables, specs, requirements...) không thể "chốt" hay close được với khách hàng. Mục tiêu được giao từ cấp trên là close dự án này, càng sớm càng tốt, giải phóng (bớt) nhân sự, không để dự án dai dẳng, tốt công của và thời gian. Với tư cách là PM/SM, bạn nên/phải làm gì?

Dự án đang ở đâu?

Trả lời câu hỏi này để biết được hiện trạng của dự án. Một số câu hỏi cần đặt ra
  1. Dự án cần làm những gì? 
    1. Schedule/WBS (Work Breakdown Structure) ở đâu, đã làm được gì?
    2. Product backlog/sprint backlogs ở đâu, đã làm được gì?
  2. Những gì (chức năng/user story) đã hoàn thành, những gì chưa hoàn thành, những gì đang "treo" (đang được confirm). Nên trả lời riêng câu hỏi này.
  3. Dự án đang trong phase nào? (yêu cầu, thiết kế, lập trình, kiểm thử đơn vị, kiểm thử tích hợp, deploy, tạo tài liệu). Một số chức năng có thể ở phase này, hoặc ở phase khác. Cần liệt kê cụ thể.
  4. Đầu vào của dự án gồm những gì? (tài liệu yêu cầu, user stories, thiết kế, nếu có)
  5. Đầu ra của dự án gồm những gì? Đã làm được gì? Trạng thái (being confirmed, being reviewed, done...)
  6. Kế hoạch và trạng thái (schedule, burndown chart)

Vấn đề của dự án là gì?

Cần họp toàn team, lắng nghe thông tin từ tất cả những người liên quan.

Risk và issue log là hai tài liệu quan trọng nhất cần có. Với những dự án quản lý kém, hai tài liệu này thường không tồn tại hoặc quản lý kém. Đặc biệt, với dự án không chạy tốt theo khung Scrum, thường hai tài liệu này không tồn tại và cần được tạo lại.

Lưu ý rằng trong danh sách issue log không chỉ chứa các vấn đề kỹ thuật mà cần bao gồm cả danh sách các vấn đề về nhân sự, communication, yêu cầu, thiết kế, kỹ thuật, năng lực của cả nhóm.

Cận biên tích hợp của dự án

Xác định những hệ thống, chức năng có tích hợp, liên kết với dự án chúng ta tiếp quản. 

Một pattern hay thấy ở các  dự án phần mềm là, từng module đơn lẻ đã hoàn thành nhưng phần tích hợp các module đó trong phạm vi nội bộ do nhóm phát triển đảm nhận không được ý thức tới, chưa làm, hoặc làm nửa vời, không có issue log.

Một pattern khác hay thấy hơn là phân tích hợp hệ thống/phần mềm chúng ta tiếp quản với hệ thống bên ngoài làm chưa tốt. Với phần này, cần xác định các hệ thống liên quan, những người chịu trách nhiệm (đầu mối) của các dự án đó, họp và xác định trạng thái, công việc tồn đọng, issue list.

Tiếp theo phải là gì?

Sau khi đã tiến hành ba bước trên, cần refine lại danh sách công việc còn lại cần làm, tạo schedule/WBS hay masterplan cho các sprint tiếp theo. Trả lời câu hỏi: Cần khoảng bao nhiêu thời gian (và tiền) (ở mức high level) để hoàn thành nốt công việc tồn đọng. Nếu tốt hơn, nên tạo plan cho từng sprint ở mức high level.

Tiếp theo phải là gì?

Tiến hành dự án theo cách thông thường mà bạn, với tư cách là PM/SM nghĩ là hợp lý để hoàn thành dự án với mức độ tự tin và quyết liệt cao nhất. Luôn chú ý tới communication và risk (là hai yếu tố khá "cao cấp" với PM/SM non tay)

Kết luận

Theo kinh nghiệm cá nhân, việc xác định issue log và các hệ thống cận biên cần tích hợp tới là các điểm nóng cần làm để có thể close được dự án.


--
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.

Apr 27, 2016

Cao đẳng (từ cũ)

"cao đẳng" với nghĩa "cao cấp" chưa có trong Vietlex.

Trích từ cuốn "tôi tự học" của Nguyễn Duy Cần.


--
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.

Apr 6, 2016

Why we have bugs / Vì sao có bug?

Một câu hỏi ngây thơ nhưng không đơn giản: Vì sao chương trình phần mềm có bug, bug ở đâu ra?

Ai hỏi câu này?
Tôi nhận được câu hỏi này từ các thành viên trong dự án. Tester và developer đều hỏi câu này dù họ làm phần mềm nhiều năm?

Vì sao phải trả lời câu hỏi này?
Đây là câu hỏi có vẻ đơn giản, nhưng câu trả lời không dễ. Với người ít kinh nghiệm làm phần mềm, họ trả lời "bug là bug". Với người nhiều kinh nghiệm hơn, ẩn ý từ câu hỏi này "bug từ nguồn nào tới để chúng ta/chúng tôi biết cách phòng tránh."

Nói thêm về quy trình phần mềm
Dù chúng ta phát triển phần mềm theo quy trình nào, những khái niệm sau luôn đúng.
- Mỗi công đoạn làm phần mềm trong quy trình đều có đầu vào vào đầu ra cụ thể
- Quá trình test phát hiện ra lỗi nhiều nhất

Công đoạn (chính) nào phát hiện được bug?
- (Các loại) test, như: unit test, function test, regression test, integration test, system test, user acceptance test
- Review (nói chung): Tài liệu, mã nguồn hay các loại input/output nói chung

Đầu vào của công đoạn coding là gì?
Đây là câu hỏi quan trọng hướng tới câu trả lời "bug từ đâu ra" của lập trình viên và tester. 
Tùy vào quy trình dự án, một số đầu vào điển hình của công đoạn coding là:
- Tài liệu thiết kế (basic design, detail design)
- Requirement definition
Tùy vào dự án, quy trình, đầu vào là khác nhau

Dựa vào đâu để biết đầu ra đúng hay sai?
"Đầu ra" ở đây được hiểu đơn giản là "mã nguồn", sản phẩm một hay nhiều chức năng phần mềm.
Việc kiểm tra đầu ra đúng hay sai cần dựa trên một cái gì đó đúng. Ta có thể chọn các đầu vào của việc coding làm tài liệu "đúng".

Test thế nào nếu không có "đầu vào" của việc coding chuẩn?
- Free test (test tự do, không theo một kịch bản nhất định. Mức độ test tùy vào kinh nghiệm của người test)
- Test phá (một dạng test tự do, tìm cách làm cho chương trình chết)
Nghĩa là, cứ lần mò mà test 

Nếu không có requirements definition hay tài liệu thiết kế rõ ràng) thì test thế nào?
Trả lời: Test phá (agile testing)

Nếu khi test, tôi tìm ra một điểm mới, không biết là đúng sai thì làm thế nào?
Hãy log lại và confirm với toàn team. Đây là cơ hội để cả team review lại kiến thức của họ về hệ thống

Làm thế nào để tìm bug khi không có tài liệu:
Câu trả lời là: Agile testing

Tôi là tester, phải làm gì khi không biết thế nào là đúng/sai?
- Agile testing
- Thật chủ động
- Làm việc chặt chẽ với người hiểu code và hiểu yêu cầu nghiệp vụ



--
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.