Bài viết

Autumn Coderetreat 2017

Ngày 10/7/2017 tới đây tại Hà Nội và Đà Nẵng sẽ diễn ra một sự kiện rất đặc biệt dành riêng cho giới Lập trình viên: Autumn Coderetreat 2017.

Coderetreat là một sự kiện thực hành lập trình chuyên sâu, các hoạt động tập trung vào những nguyên tắc cơ bản của phát triển phần mềm và thiết kế. Tại sự kiện, các nhà phát triển có cơ hội tham gia vào thực hành có chủ ý (deliberate practice\deep practice), tránh xa những áp lực phải ‘hoàn thành nhiệm vụ’ trong công việc hằng ngày. Hoạt động của Coderetreat được chứng minh là có hiệu quả cao, giúp cải thiện kỹ năng. Qua việc tập trung thực hành những nguyên tắc cơ bản của Thiết kế Đơn giản (simple design) và hướng đối tượng (OOP), các nhà phát triển có thể cải thiện trình độ, năng suất trong viết mã.

Những ai muốn tham gia có thể xem thông tin chi tiết hơn tại đây: http://codegym.vn/events/autumn-coderetreat/

Xem thêm thông tin về Coderetreat và Coding Dojo:

ScrumMaster, cái tay này làm việc gì?

ScrumMaster không quản lí nhân sự, không quản lí tiến độ, cũng chẳng quản lí công việc được gán cho ai, càng không quản lí tiền bạc, hay yêu cầu. Vậy thế cái tay này làm cái gì?

Trong những lớp học tôi dạy về Scrum, phần nhiều học viên cứ nghĩ là ScrumMaster chẳng có việc gì để làm. Nên trong các ý kiến thảo luận, họ thường để một ai đó – như Product Owner, hay Developer, Tester. – kiêm nhiệm. Cực chẳng đã mới để một người làm ScrumMaster độc lập, vì sợ tốn rì-suộc (resource) hehe.

Kì thực thì có vài ScrumMaster mới nhận cái công việc này sẽ thấy ngập lụt, “ôi sao nhiều việc thế”, “thế này thì làm sao nổi” hehe..

Vậy thì hằng ngày cái vị ScrumMaster này làm những gì? Xin liệt kê ra đây vài cái bạn xem có nhiều không nhé:

1. Tổ chức các cuộc họp

Chả có mô hình làm việc nào lại có lắm kiếu họp thế: Họp kế hoạch, Họp sơ kết, Họp Cải tiến, Họp viết Yêu cầu, Họp Scrum Hằng ngày, rồi đủ các kiểu họp đột xuất khác. ..

Đó là cấu thành rất cơ bản để vận hành cơ chế Thanh tra – Thích nghi. Thực ra chúng không phải là “họp” theo nghĩa truyền thống, mà là thời gian cộng tác. Giữ cho các  cuộc họp này đầy đủ, đúng giờ và hữu ích không hề là việc dễ.

2. Chọc ngoáy liên tục (còn gọi là thanh tra quy trình)

Giữ “con mắt cú vọ” trên tất cả các phương diện của dự án, ScrumMaster sẽ phải dùng hàng tá các câu hỏi để phát lộ vấn đề, phát lộ ý tưởng, để giúp nhóm nhanh chóng đạt được mục tiêu Sprint.

Để “quan sát” ta có thể bắt đầu với:

  • Mình có nhìn thấy taskboard không?
  • Khách hàng có biết việc gì đang diễn tra trên bảng không?
  • Có gì được cập nhật từ hôm qua đến nay không?
  • Có nhìn thấy burndown\burnup không?
  • Có điểm nào bất thường trên burndown chart không?
  • ….

Để điều tra, “đào bới” thêm, ta có thể dùng các câu hỏi Socratic:

  • Tôi nhận thấy <tình huống>, chúng ta sẽ làm gì?
  • Tôi quan sát thấy <tình huống>, nó có quan trọng không?
  • Tôi thấy <cảm giác>, bạn có thấy điều đó?
  • Chúng ta sẽ cố tìm lý do của <tình trạng>?
  • Bạn nghĩ chúng ta cần làm gì?
  • Ai có ý tưởng gì về <tình trạng>?
  • Điều này có hiệu quả không?
  • Bạn đã quyết định điều gì?
  • Bạn nên làm gì [với tình huống\vấn đề này]?

Danh sách câu hỏi loại này có thể nối dài thêm nữa, phục thuộc vào bối cảnh, sự phức tạp và khả năng thanh tra của ScrumMaster. Tuy vậy, việc này rất mất thời giờ, mất năng lượng và đòi hỏi cả cơ bắp lẫn trí tuệ.

Để điều tra nguyên nhân của vấn đề, ScrumMaster còn phải thành thạo và liên tục sử dụng 5WHYs (Hỏi 5 lần tại sao) để tìm ra cách thúc đẩy nhóm tiến lên.

3. Loại bỏ trở ngại

Nếu như phần (2) chỉ với mục đích “bới bèo ra thật nhiều bọ” (thật nhiều vấn đề của nhóm) thì cái thực sự mà ScrumMaster quan tâm là đầu tư công sức để loại bỏ các trở lực đó. Qua đó giúp nhóm hiệu suất hơn, nhanh chóng đạt được mục tiêu Sprint.

Vấn đề thì muôn hình muôn vẻ, cho nên việc này cũng muôn hình muôn vẻ. Mà có nhóm làm việc nào thực sự lại ít vấn đề? Cho nên ScrumMaster sẽ luôn chân luôn tay. Thậm chí không kiểm soát nổi vấn đề nếu không có phương pháp làm việc khoa học.

4. Tìm kiếm cải tiến

  • ProductOwner của tôi làm việc thế nào?
  • Nhóm Phát triển đang làm việc thế nào?
  • Các kỹ thuật đang được dùng thế nào?
  • Tổ chức đang làm việc ra sao?
  • Ai cần được huấn luyện về cái gì?
  • Quy trình có dư thừa cái gì không?
  • Có thể mua sắm hay làm mới công cụ gì để tăng năng suất và gia tăng không khí vui vẻ không?

Đó là vài câu hỏi thường trực. Cải tiến là thứ cần phải làm liên tục, chứ không phải đợi đến buổi họp Cải tiến Sprint mới động não. Trong khi Developer, ProductOwner bận rộn với công việc của họ, thì ScrumMaster sẽ phải âm thầm nhưng chăm chỉ nghiên cứu, phân tích và tìm ra các cải tiến để hỗ trợ nhóm.

5. Huấn luyện (Coaching) Scrum cho nhóm

Ở những nhóm mới làm việc kiểu Scrum, mọi người thường chưa nắm rõ các quy tắc (dù ít ỏi) và ràng buộc của Scrum, nên có thể mắc sai lầm. Nhiệm vụ của ScrumMaster là giúp các thành viên hiểu rõ, thực hành tốt và gặt hái thành công từ Scrum. Mà việc này thì phải theo sát, không thể lơ là.

Trong nhiều trường hợp, ScrumMaster còn phải chịu trách nhiệm tổ chức các “community of practices”, xây dựng và bảo trì kho tri thức Agile cho các thành viên của nhóm và trong phạm vi rộng hơn.

Không thể có Agile mà không có học tập. Nên việc này rất tiên quyết. À, thế nhưng bạn có biết việc học diễn ra bao lâu chưa? Bạn đã nghe con số 10.000 giờ thực hành có chủ đích liên tục chưa?

Trong cấu hình của Nhóm Scrum, có một tay có thể rất lười nhác, nhưng lại có quyền lực lớn là ProductOwner hoặc khách hàng. Tay này có khi chỉ chầu chực là phá hỏng luồng làm việc của nhóm với những bug cần fix gấp, hay những tính năng tuyệt cú mèo “anh vừa mới nghĩ ra”. Cần phải huấn luyện Scrum cho tay này để anh em phối hợp nhịp nhàng. Đấy cũng là nhiệm vụ rất mệt nhọc của Scrum Master.

6. Chụp ảnh, quay phim, ghi ghi chép chép, dán dán dính dính

Mấy việc này không có tên, nhưng nó là những việc quan trọng không kém.

ScrumMaster có đôi mắt cú vọ để thanh tra mọi thứ, nhưng lại có một bộ nhớ của con người. Mà cái này dung lượng vừa bị giới hạn, lại có tính chất phần nhiều giống như RAM chứ không như ROM. Vậy nên phải thu thập dữ liệu, phân loại để chuẩn bị phân tích.

Không có dữ liệu thực tế, quyết định cải tiến có thể sẽ không phát huy tác dụng.

Mà mấy cái việc không tên này, cũng giống như mấy việc nội trợ ở nhà ấy; chẳng thể gọi là gì, nhưng thử mó tay vào mà xem, “đi đời” vài tiếng như chơi đấy.

7. Động viên, hỗ trợ nhóm

Bản thân công việc loại bỏ trở ngại cho nhóm đã là một lực thúc đẩy nhóm tiến lên. Tuy vậy, đôi khi ScrumMaster còn phải làm nhiều hơn nữa. Động viên, thử thách, thúc đẩy nhóm Scrum cũng là công việc quan trọng của ScrumMaster.

Hôm nay mình đã làm điều gì để khiến ai đó được “kích hoạt” không?

Hôm nay mình làm cho\tạo điều kiện cho ai làm cho nhóm vui vẻ không?

Có trò gì để khiến những chú “trâu ” kia thư giãn một chút không?

v.v.

8. Thôi , bạn thêm giúp tôi vào danh sách này nhé, còn dài lắm. Vả lại tôi có phải là ScrumMaster của các bạn đâu, nên làm sao biết được là sẽ cần phải làm những gì nữa?

Mời bạn điền tiếp!

Dương Trọng Tấn 

Nguồn : tapchilaptrinh.vn

Danh sách các Kata dành cho CodingDojo

Kata là một bài tập (bài toán, thử thách, v.v.) về lập trình đi kèm các quy tắc được lựa chọn và thiết kế để giúp các thành viên tham gia buổi Coding Dojo sử dụng để cải thiện kỹ năng\kỹ thuật cụ thể nào đó của lập trình: TDD, Pair-Programming, Unit Testing, Refactoring, v.v..

Bạn không nên chọn một bài toán bất kỳ nào đó trong lập trình để làm một Kata. Thay vào đó bạn nên chọn từ danh sách các bài đã được tổng kết ở một số trang web nổi tiếng về Coding Dojo như:

Dưới đây là những bài Kata đã được CodeGym Premium lựa chọn từ CodingDojo.org và dịch ra tiếng Việt:

  1. Kata FizzBuzz
  2. Kata RomanNumerals
  3. Kata RomanCalculator
  4. Kata Minesweeper
  5. Kata Bowling
  6. Kata PokerHands
  7. Kata YahtZee
  8. Kata DeepFirstSearch
  9. Kata WordWrap
  10. Kata Tennis
  11. Kata NumberToLCD
  12. Kata GameOfLife
  13. Kata DictionaryReplacer
  14. Kata FooBarQix
  15. Kata NumbersInWords
  16. Kata Potter

Kata GameOfLife

Giới thiệu kata :

Game Of Life là một bài toán rất thú vị của Conway, một nhà Toán học người Anh. Bài toán của ông đơn giản nhưng khi triển khai nó bạn sẽ được những kết quả thật tuyệt vời như cuộc sống đang diễn ra xung quanh ta vậy.

Mô tả bài toán :

Giả thiết thế giới chúng ta đang sống là một không gian n chiều (để đơn giản ta dùng không gian hai chiều). Ví dụ:

Game of life không gian đa chiều

Mỗi sự sống trong thế giới này là một ô (cell) nhỏ bé và chịu những quy tắc sống còn như sau:

  • Ô đang SỐNG mà xung quanh nó (kề sát) có ít hơn 2 ô hàng xóm sống thì sẽ CHẾT (Ô màu vàng)

Game of life hai ô đang sống

  • Ô đang SỐNG mà xung quanh nó có nhiều hơn 3 ô hàng xóm sống thì sẽ CHẾT. (Ô màu vàng)

Game of life ba ô đang sống

  • Ô đang SỐNG mà xung quanh có 2 hoặc 3 ô hàng xóm sống thì tiếp tục SỐNG. (Ô màu vàng)

Game of life 2 hoăc 3 ô đang sống

  • Ô đang CHẾT mà xung quanh có đúng 3 ô hàng xóm sống thì sẽ SỐNG lại. (Ô màu vàng)

Game of life 3 ô đang sống

Bài toán này thú vị khi khởi tạo (gieo mầm) sự sống cho thế giới này. Tức là bạn đóng vai Chúa, đặt các “hạt giống” sự sống vào thế giới này và rồi … quy luật “sinh tồn” sẽ quyết định.

Bạn có thể xem một số mẫu đơn giản và phức tạp sau đây để thấy Game Of Life thú vị thế nào:

Mẫu 1: Hạt mầm sự sống (các ô màu xanh) được gieo như sau…

Game of life hạt mầm sự sống

Và rồi… https://youtu.be/bJ_Hhh5gV4w

Mẫu 2: Hạt mầm sự sống được gieo như sau…

Game of life hạt mầm sự sống được gieo

Và rồi… https://youtu.be/nlzATno5ek8

Mẫu 3: Hạt mầm sự sống (ô màu xanh và ô màu cam) được gieo như sau…

Game of life hạt mầm sự sống được gieo theo ô màu cam

Và rồi… https://youtu.be/OlIuo4If18Y

Mẫu 4: Hạt mầm sự sống (ô màu xanh và ô màu cam) được gieo như sau…

Game of life hạt mầm sự sống được gieo

Và rồi… https://youtu.be/mhswQu_VLQk

 Nguồn Kata: http://codingdojo.org/kata/GameOfLife/

Kata Bowling

Mô tả bài toán

Viết một chương trình để tính điểm của 1 ván bowling dựa trên đầu vào là 1 dãy số điểm của các lượt ném hợp lệ. Một số thứ sẽ không cần có trong chương trình:

  • Không kiểm tra tính hợp lệ của các lần ném bowling.
  • Không kiểm tra tính đúng đắn của số lượt ném (frame) và số lần ném (roll).
  • Không tính điểm sau từng lượt ném (chỉ tính tổng điểm cuối cùng sau khi ném đủ 10 lượt).

Tuỳ thuộc vào mỗi dojo khác nhau mà chương trình có thể được xây dựng hoàn thiện hoặc không, nhưng chúng tôi không xử lý ba điều trên nhằm giúp bài Kata “sáng sủa” hơn, người luyện Kata tập trung vào vấn đề chính cần giải quyết. Nếu bạn muốn viết một trò chơi bowling thật, bạn sẽ phải thực hiện các bước kiểm tra ở trên.

Quy tắc tính điểm ngắn gọn của bowling như sau:

  • Mỗi ván bowling có 10 lượt ném (10 frame).
  • Mỗi frame, người chơi có hai lần ném (roll) để làm đổ hết 10 pin.
  • Nếu sau hai lần ném (trong 1 frame) mà người chơi không ném đổ được hết 10 pin, điểm số cho frame đó là tổng số pin đã bị ném đổ.
  • Nếu sau hai lần ném (của 1 frame), người chơi ném đổ hết 10 pin, frame này được gọi là “spare” và điểm cho 1 frame spare được tính bằng 10 cộng thêm số pin mà bạn ném đổ ở lần ném tiếp theo (Ví dụ ở frame thứ 1 bạn đạt spare, frame thứ hai bạn ném lần 1 đổ 3 pin, lần 2 đổ 5 pin, điểm số của frame 1 (spare) sẽ là (10 + 3), và tổng điểm của frame 1 và frame 2 sẽ là: (10+3) + (3+5).
  • Nếu sau lần ném đầu tiên (của 1 frame), người chơi làm đổ hết 10 pin, frame đó được gọi là “strike”, điểm số của của frame strike được tính bằng 10 cộng thêm số pin mà người chơi ném đổ ở 2 lần ném tiếp theo (Ví dụ ở frame thứ 1 bạn đạt strike, frame thứ hai bạn ném lần 1 đổ 3 pin, lần 2 đổ 5 pin, điểm số của frame 1( strike) sẽ là (10 + 3 + 5) , và tổng điểm của frame 1 và frame 2 sẽ là: (10 + 3 + 5) + (3 + 5).
  • Lượt ném thứ 10 thì hơi khác hơn 1 chút. Nếu bạn đạt strike hoặc spare ở lượt ném thứ 10 thì bạn sẽ được ném thêm (bạn được ném tối đa 3 lần trong lượt ném thứ 10). Ví dụ nếu ngay lần ném đầu tiên của frame thứ 10 bạn đạt strike thì bạn sẽ được ném tiếp hai lần, nếu bạn đạt spare thì bạn sẽ được ném thêm 1 lần nữa. ( Tối đa điểm bạn có thể có trong frame 10 là (10+10+10) khi 3 lần némcủa frame này đều dành được strike).
  • Bạn có thể xem thêm về luật trò bowling tại: www.topendsports.com/sport/tenpin/scoring.htm

Gợi ý

Trò bowling thú vị là nhờ strike và spare. Khi chúng ta giành được một frame strike hoặc spare, chúng ta không thể biết điểm của frame đó ngay mà phải chờ 1 hoặc 2 lần ném (một nửa hoặc cả 1 frame) để biết được điểm thưởng thêm là bao nhiêu.

Một số test case mẫu

(Dấu “X” là strike, “/” là spare và “-” là miss: Không ném đổ pin nào).

  • “XXXXXXXXXXXX” (12 lần ném với 12 strike) = 10+10+10 + 10+10+10 + 10+10+10 + 10+10+10 + 10+10+10 + 10+10+10 + 10+10+10 + 10+10+10 + 10+10+10 + 10+10+10 = 300 (điểm)
  • “9-9-9-9-9-9-9-9-9-9-” (20 lần ném với 10 cặp: 9 và miss) = 9 + 9 + 9 + 9 + 9 + 9 + 9 + 9 + 9 + 9 = 90 (điểm)
  • “5/5/5/5/5/5/5/5/5/5/5” (21 lần ném với 10 cặp: 5 rồi spare, lần ném cuối ném đổ 5 pin) = 10+5 + 10+5 + 10+5 + 10+5 + 10+5 + 10+5 + 10+5 + 10+5 + 10+5 + 10+5 = 150 (điểm)

Nguồn Kata: http://codingdojo.org/kata/Bowling/

Kata RomanCalculator

Giới thiệu kata

CodersDojoSweden, tổ chức ở Linköping, đã tìm kiếm một bài Kata mới đủ đơn giản dành cho người mới bắt đầu. Và Thomas Nilsson đã đưa ra bài toán Cộng số La Mã.

Mô tả bài toán

Là một kế toán, tôi muốn cộng các số La Mã tự động bởi vì làm việc đó bằng tay quá tẻ nhạt.” Cho các chữ số La Mã cơ sở ( I – 1, V – 5, X – 10, L – 50, C – 100, D – 500, M – 1000), tạo ra hai số La Mã và tính tổng của chúng. Ở Rome thời đó không có số Thập phân hay số nguyên, chúng ta cần làm việc đó với chuỗi kí tự.

Ví dụ: “XIV” + “LX” = “LXXIV”.

Dưới đây là nguyên tắc viết số La Mã:

  • Các chữ số được nối vào nhau thành số lớn hơn (VD: “XX” + “II” = “XXII”)
  • Nếu chữ số nhỏ hơn đứng trước chữ số lớn hơn, lấy chữ số lớn trừ số nhỏ (VD: “IV” là 4, “CM” là 900)
  • Với các chữ số La Mã là I, X, C bạn không thể có nhiều hơn 3 kí tự liên tiếp (VD: Không dùng “IIII” để biểu diễn số 4 mà dùng “IV”)
  • Với các chữ số La Mã là V, L, D bạn không thể có nhiều hơn 1 khi biểu diễn một số (VD: 1000 không biểu diễn là “DD” mà dùng “M” để biểu diễn)

Gợi ý

Nhóm chuỗi và nối chuỗi là chìa khóa để giải quyết bài Kata này. Nhưng hãy nhớ quy tắc về trường hợp số nhỏ hơn đứng trước số lớn hơn ở trên.(Nếu chữ số nhỏ hơn đứng trước chữ số lớn hơn, lấy chữ số lớn trừ số nhỏ, VD: “IV” là 4, “CM” là 900).

Gợi ý các ca kiểm thử (test case)

10 ca kiểm thử đầu tiên tương đối dễ tìm. Tôi không đưa ra chúng ở đây bởi vì tôi thấy rằng bài Kata này là một trong số những bài Kata rất tốt để thực hành việc tìm các ca kiểm thử.

Nguồn Kata: http://codingdojo.org/kata/RomanCalculator/

Kata RomanNumerals

Tôi không tham dự XP2001 của Kent Beck, nhưng tôi tin chắc rằng Kata này đã xuất hiện ở đó. Đây là [video về việc Karl Scotland đã biểu diễn Kata này trên Excel tại Agile2008] và đây là [video cho thấy JonJagger thực hiện bài Kata này trên Ruby sử dụng Cyber-Dojo.org]

Cấp độ của Kata: Dễ

Mô tả bài toán

Người La Mã rất thông minh. Họ đã xâm chiếm và cai trị hầu hết Châu Âu trong suốt hàng trăm năm. Họ phát minh ra những con đường bê tông thẳng, thậm chí là cả những bộ bikini. Tuy nhiên, có một điều đó là họ đã không khám phá ra con số không. Điều này khiến việc ghi chép và đánh dấu những phát kiến trong lịch sử của họ gặp nhiều khó khăn, nhưng hệ thống số của họ vẫn được sử dụng cho đến ngày nay. Ví dụ, đài BBC thường sử dụng dụng số La Mã để ghi ngày tháng cho những chương trình của họ.

Người La Mã dùng 7 chữ cái I, V, X, L, C, D, M (lưu ý những kí tự này được tạo bởi nhiều đường thẳng do đó dễ dàng khắc lên những tấm bảng đá) để biểu diễn các số (I – 1, V – 5, X – 10, L – 50, C – 100, D – 500, M – 1000).

Kata này yêu cầu bạn viết 1 chức năng chuyển đổi 1 số thông thường (hệ Thập phân) sang 1 số La Mã. VD:

  • 1 –>        I
  • 10 –>        X
  • 7 –>        VII
  • v.

Xem mô tả chi tiết của bài tập này ở [website tham khảo hữu ích], tại đây đã triển khai Kata này với JavaScript.

Bạn không cần thiết phải chuyển đổi những số lớn hơn 3000 (bản thân người La Mã cũng không có xu hướng đếm những số cao hơn số này).

Lưu ý rằng bạn không thể sử dụng “IM” để biểu diễn cho số 999.

Theo Wikipedia: Số La Mã hiện đại được viết theo quy tắc biểu diễn từng số riêng biệt bắt đầu từ bên trái và bỏ qua những số 0. Để thấy điều này trong thực tế, hãy xem xét cách biểu diễn số 1990. Số La Mã của 1990 (= 1000 + 900 + 90) sẽ được biểu diễn như sau: 1000 = M, 900 = CM, 90 = XC; kết quả là MCMXC. 2008 sẽ được viết là 2000 = MM, 8 = VIII ; 2008 = MMVIII.

Phần 2: Viết một hàm để chuyển ngược lại, số La Mã về số Thập phân.

Nguồn Kata: http://codingdojo.org/kata/RomanNumerals/