Thói quen đó xấu, là bởi vì nhiều khi … mất thời gian. Có nhiều bài chỉ mang tính ôn tập lại mấy cái chức năng của Ruby, thì mình lại bỏ ra 1 tiếng đồng hồ vò đầu bứt tai xem có cách nào ngon và ngắn hơn không.

Nhưng từ khi có thói quen đó, thấy đầu óc mình được optimized hẳn. Trước khi làm gì cũng bỏ ra vài trăm mili giây để đánh giá xem có cách nào nhanh hơn không, và nhờ đó mà nhiều khi lại tiết kiệm được thời gian. Quan trọng nhất là nó thay đổi tư duy của mình khi lập trình: đó là có nhiều cách để giải quyết 1 vấn đề, và không có cách nào là ngắn nhất cả, chỉ có cách ngắn nhất tạm thời, hoặc nói chính xác là “cách ngắn hơn”. Kể cả khi tớ tìm được cách để giải 1 bài mà chỉ dùng có 1 dòng code, tớ cũng chả thấy hài lòng: “chắc chắn còn cách cần ít chữ cái hơn”.

Tất nhiên khi lập trình thì có nhiều tiêu chí để nói code của mình đã được “tối ưu hoá” (không kể đến việc phải giải quyết được vấn đề):

- Chạy nhanh nhất.
- Ít dòng code nhất.
- Thuật giải rõ ràng và đẹp.

Gần như không có ai đạt được cả 3 tiêu chí đó 1 lúc cả. Và thường mọi người khi giải quyết vấn đề thường dựa vào tiêu chí thứ nhất và tiêu chí thứ ba nhiều hơn.

Giờ thì tớ muốn nhét thêm cái tiêu chí thứ 2 đó và phương trình của tớ:

code-tối-ưu = nhanh + đẹp + ngắn

Hồi gì học Ruby trên mạng, tớ gặp 1 bài khá đơn giản như sau:

Cho 1 dãy số từ 1 đến 100. In ra lần lượt cho từng số:
- Fizz nếu số đó chia hết cho 3
- Buzz nếu số đó chia hết cho 5
- FizzBuzz nếu số đó chia hết cho 15
- nếu không phải các trường hợp trên thì in ra chính số đang xét.

Bài này có thể gọi là “siêu dễ”. Thế nhưng mà phần lớn dân tốt nghiệp lập trình không giải được bài này (hô hô).

Cách đơn giản nhất là mà phần lớn học viên ở rubylearning.org đưa ra là như sau:

1.upto(100) do |number|
  if number % 15 == 0 then
    puts 'FizzBuzz'
  elsif number % 5 == 0 then
    puts 'Fizz'
  elsif number % 15 == 0 then
    puts 'Buzz'
  else
    puts number
  end
end

Như vậy là 11 dòng code. Có thể gọi đây là bản thô, chưa tinh xảo.

Một học viên khác (Marcos Ricardo) có vẻ đã quen với việc lập trình trong python từ trước, đưa ra lời giải khá là “pythonish” như thế này:

1.upto(100) do |number|
  message = ''
  message << "#{'Fizz' if(number % 3 == 0)}#{'Buzz' if(number % 5 == 0)}"
  puts message.empty? ? number.to_s : message
end

Như vậy là đỡ đi 1 lệnh điều kiện number % 15, vỏn vẹn 5 dòng.

Tớ thích cách này, vì trông nó rất là … nói chung là mã miếc các thứ lằng nhằng trông prồ. Với cả cách sử dụng lồng biểu thức khá là hay. Nhưng liệu mình có làm được cách nào ngắn gọn hơn và hay hơn không nhỉ?

Cùng lúc đó tớ đang học Drupal. Trong Drupal có 1 cái hệ thống xét loại menu item dựa trên thuộc tính khá là hay: sử dụng cờ (flag).

Các thuộc tính của menu item được biểu diễn dưới dạng các hằng, chứa giá trị thập phân tương ứng với các cờ nhị phân. Và mỗi loại menu đều là một tập hợp nhất định của 1 số thuộc tính nhất định. Chỉ cần cộng các cờ nhị phân của các thuộc tính này sẽ xác định được giá trị định nghĩa của mỗi loại menu item.

Áp dụng với bài toán fizzbuzz này, nếu tớ sử dụng 2 cờ là “chia hết cho 3″ và “chia hết cho 5″, thì tớ chỉ cần cộng giá trị của 2 cờ này với nhau sẽ biết được liệu số này có chia hết cho 3, cho 5, cho cả 2 hay không cho số nào cả. Lời giải của tớ cho bài này trong Ruby chỉ có 2 dòng như sau:

a = nil, 'fizz', 'buzz', 'fizzbuzz'
1.upto(100) { |a[0]| puts a[(a[0]%3 == 0 ? 1 : 0) + (a[0]%5 == 0 ? 2 : 0)] }

Dòng đầu tiên tớ định nghĩa “loại” cho các số.
Ở dòng thứ 2, trong quá trình xét từ 1 đến 100, tớ gán luôn số đang xét cho a[0]. Sau đó tớ cộng tổng của 2 cờ a[0]%3 và a[0]%5, và lôi giá trị “loại” của nó ra từ chính mảng a.

Đến lúc này bạn Marcos Ricardo lại có 1 cách nữa, chỉ mất 1 dòng

1.upto(100) {|number| puts "#{'Fizz' if(number % 3 == 0)}#{'Buzz' if(number % 5 == 0)}".empty? ? number.to_s : "#{'Fizz' if(number % 3 == 0)}#{'Buzz' if(number % 5 == 0)}" }

Ngắn thì ngắn thật. Nhưng hơi bị rối mắt. Và mặc dù cho độ ngắn của lời giải này vượt lời giải của tớ, độ “đẹp” và “nhanh” của nó thì không bằng của tớ được.

Đó là bởi vì cách này phải dùng tới 4 lệnh điều kiện, trong khi của tớ chỉ mất có 2. Và nó phạm phải nguyên tắc DRY (Don’t Repeat Yourself - đừng tự lặp lại mình). Lời giải của tớ thì không mắc phải vấn đề như vậy. Nó hoàn toàn không bị lặp lại, và hoàn toàn có thể được mở rộng để đáp ứng được những yêu cầu mới của bài toán nếu có.

Ví dụ như mở rộng thêm điều kiện cho bài toán như sau:

Cho 1 dãy số từ 1 đến 100. In ra lần lượt cho từng số:
- Fizz nếu số đó chia hết cho 3
- Blah nếu số đó chia hết cho 4
- Buzz nếu số đó chia hết cho 5
- FizzBuzz nếu số đó chia hết cho 15
- FizzBlah nếu số đó chia hết cho 12
- BlahBuzz nếu số đó chia hết cho 20
- FizzBuzzBlah nếu số đó chia hết cho 60
- nếu không phải các trường hợp trên thì in ra chính số đang xét.

Giả sử tớ thích dùng cách “thô” (cái cách mà mất những 11 dòng lúc nãy), tớ sẽ phải thêm đến 4 lệnh điều kiện nữa, và độ dài của chương trình khéo phải đến 20 dòng. Và nếu dùng cách “1 dòng” như trên thì chắc phải mất đến 14 câu điều kiện nhồi nhét vào trong 1 dòng đó. Còn nếu dùng cách của tớ? Chỉ mất 2 dòng và 3 câu điều kiện:

a = nil, 'Fizz', 'Buzz', 'FizzBuzz', 'Blah', 'FizzBlah', 'BlahBuzz', 'FizzBuzzBlah'
1.upto(100) { |a[0]| puts a[(a[0]%3 == 0 ? 1 : 0) + (a[0]%5 == 0 ? 2 : 0) + (a[0]%4 == 0 ? 4 : 0)] }

Như vậy có thể coi lời giải của tớ có độ tối ưu hơn so với các lời giải khác cho đến … 1 tuần sau đó, khi tớ khám phá ra bài viết này:
Oh, Go Ahead. Overthink FizzBuzz

Trong đó có lời giải chỉ mất 1 dòng, mà trông vẫn ngắn gọn, chỉ cần 1 lệnh điều kiện:

(1..100).map {|i| srand(1781773465) if (i%15)==1; [i, "Fizz", "Buzz", "FizzBuzz"][rand(4)]}

Hãy nhìn kĩ nhé: srand(1781773465), và tác giả nói tìm ra con số 1781773465 mất 12 tiếng. Để nói thêm về cách làm này, có lẽ cho tớ khất đến một bài viết sau, vì có lẽ nó … quá sáng tạo (đối với tớ) (tất nhiên nếu mở rộng đề bài như tớ nói ở trên thì có lẽ nó hơi bị mất công, nhưng thực sự cách làm này quá sáng tạo và không ai … dám nghĩ đến). Ta sẽ nói đến lời giải này khi tìm hiểu về Pseudorandom number generator (thuật toán mô phỏng tạo số ngẫu nhiên) trong một bài viết sắp tới của tớ nhé

OK, tớ cuốn xuống phần comment của bài viết, và bắt gặp thêm 1 lời giải 1 dòng nữa, và số kí tự còn ngắn hơn lời giải vừa rồi:

puts (1..100).map{|i|(s=(i%3==0?’Fizz’:”)+(i%5==0?’Buzz’:”))==”?i:s}

I’m speechless!! Sao cách giải đơn giản như vậy mà mình không nghĩ ra!! Và lại còn có bác ngồi mất 12 tiếng để tìm ra con số seed cho hàm random nữa chứ. =))

Và còn đây nữa:

1.upto(100){|i|puts"FizzBuzz#{i}"[i%3<1?0:i%5<1?4:8,i%15<1?8:4]}

Nhìn cách này chỉ muốn đập đầu vào tường! Những cách sáng tạo nhất và ngắn gọn nhất lại là những cách dựa trên những kiến thức cơ bản nhất.

Giờ nhìn lại miếng code 2 dòng mình viết trông thật tội. Áp dụng những cái quá phức tạp cho một bài đơn giản, trong khi có những cách cơ bản khác mà vẫn đạt được độ ngắn như thế. Tuy thế nhưng mà cũng rút ra được khá là nhiều bài học quan trọng:

1. Phải nắm vững lí thuyết và thực hành thành thạo trước khi bắt tay vào làm cái gì.

2. Phức tạp hơn chưa chắc đã là tốt hơn.

3. Nên nhìn nhận vấn đề một cách đơn giản, dựa trên những gì mình đã biết và đã học.

Nghĩ lại thì trò “code 1 dòng” này khá là bổ ích, vì nó vắt kiệt bộ não của lập trình viên và thúc đẩy sự sáng tạo, đồng thời cũng khiến cho việc lập trình trở nên thú vị hơn. Tớ tin chắc là còn có nhiều cách ngắn hơn cho bài này, nhưng có lẽ cũng nên biết điểm dừng thôi nhỉ :P. Tổng thời gian tớ dành ra cho bài toán này:

lời giải đơn giản nhất: 3 phút
tham khảo lời giải của người khác: 30 phút
lời giải 2 dòng: 5 phút
tìm kiếm bài viết liên quan: 30 phút
đọc bài viết và comments của bài “Overthink FizzBuzz”: 30 phút
viết bài blog này: 30 phút

Tổng cộng là 2 tiếng 8 phút omfg!

Nhưng mà giả sử thấy 1 cái biểu đồ to thế này mà note vào thì … bó tay (click vào).

Hồi trước hình như tớ cũng có lục lọi được 1 cái addon trong firefox tên là ClipIt, hình như cũng take note được hình ảnh. Nhưng mà tớ lại hơi đòi hỏi một chút. Tớ muốn search được cả nội dung bên trong hình ảnh đó. Ví dụ như tớ không muốn bỏ sót cái biểu đồ trên khi tớ search "Google advertising revenue".

Evernote làm được tất cả các thứ này, và còn tuyệt vời hơn. Chỉ có điều hiện giờ nó vẫn đang trong giai đoạn beta và bạn chỉ có thể đăng ký xếp hàng để được họ mời bạn dùng thử bản beta này. Tớ nhận được invitation của họ từ 2 tuần trước, và trong 2 tuần đó tớ không động tay vào google notebook 1 lần nào nữa khi cần ghi chú điều gì mới. Giờ mọi người cùng "lượn" qua 1 vòng xem nó thế nào nhé

Trước hết, Evernote hỗ trợ bạn ghi chú cả online lẫn cục bộ trên máy và đồng bộ với phiên bản online. Có nghĩa là bạn có thể chọn dùng nó cùng với web browser để ghi chú các trang web, hoặc bạn có thể download 1 bản chạy trên máy trạm để ghi chú từ bất kì ứng dụng nào. Sau này khi bạn cần tra cứu lại bạn có thể dùng search engine trên mạng hoặc bằng phần mềm của nó.

Tớ thì tớ down về máy (dùng vista) để chạy. Giao diện khá là đơn giản và thân thiện.

Bạn có thể tổ chức các ghi chú của bạn bằng các tag và các notebook. Đồng thời bạn cũng có thể dễ dàng tìm lại theo ngày tháng thông qua cột phía bên phải. Như vậy nghĩa là tớ chỉ cần 1 notebook và chả cần phải tạo mới cho mỗi ngày nữa.

Nếu bạn có tablet thì việc ghi chú còn dễ dàng hơn. Evernote có chức năng nhận dạng chữ viết trong các hình ảnh, nên bạn có thể dễ dàng tìm kiếm lại các note mà bạn ghi chép bằng tay (tất nhiên là mới chỉ nhận biết được chữ cái tiếng Anh thôi ).

Còn như cái biểu đồ tớ nói ở trên, các bước take note rất là dễ dàng

Chọn 1 phần (hoặc toàn bộ) biểu đồ sử dụng Clipper của Evernote (nút bên trái để ghi chú đoạn văn bản đang được chọn, nút bên phải để cắt hình ảnh trong khung màn hình hiện tại) .

Sau đó nếu tớ muốn thêm thắt ghi chú bằng tay của mình vào, chỉ cần nhất phím D trên bàn phím, và tha hồ phóng bút.

Chữ tớ hơi xấu nhỉ

Giờ click vào nút OK của khung Clipper, biểu đồ sẽ được đưa vào Evernote. Tiếp theo chỉ việc thêm tag là xong.

Evernote tất nhiên có thể nhận dạng được cả chữ viết, và bất cứ văn bản nào có mặt trong 1 tấm hình. Giờ nếu tớ quay trở lại cửa số Evernote và search "advertising revenue", biểu đồ này sẽ chình ình hiện ra ngay.

Còn nếu bạn muốn biết đầy đủ các tính năng tuyệt vời của Evernote, tốt nhất nên đăng ký 1 chân để dùng thử bản Beta, và xem clip này

Hạn chế duy nhất của Evernote cho đến giờ mà tớ biết, đó là không chạy được trên Linux. Tất nhiên là bạn vẫn có thể sử dụng web interface của nó, nhưng rõ ràng là chức năng không đầy đủ bằng.

Bạn cũng có thể chèn ảnh vào từ ổ cứng mà không cần phải tỉ mẩn upload nó lên trước và căn lề chỉnh lối:

Có nhiều effect và option để bạn hiệu chỉnh cho ảnh của mình trong bài viết:

Bạn cũng có thể cài thêm một vài plug-in nữa để thêm tính năng sửa bài. Ví dụ ảnh sau là được xử lý bởi plugin Polaroid:

Các tính năng sửa bài của Wordpress đều đủ cả:

Và còn nhiều tính năng hay ho nữa. Bạn có thể tìm hiểu cách cài đặt và sử dụng tại viettut.info.

Cũng phải công nhận mình chả giỏi giang gì nên mới sa chân vào những cái nhóm làm việc như thế, và cũng chả phải thằng có tinh thần teamwork lắm khi hay chê bai chỉ trích đứa khác. Tự làm mọi thứ 1 mình thì lại thấy workload quá lớn mình không kham nổi. Qua lần này rút ra một vài kinh nghiệm về làm việc nhóm.

Nếu bạn được chọn làm leader:

- Luôn nhớ rằng “you are leading people, not managing them”. Thử đặt mình vào vị trí 1 thằng developer, sẽ rất khó chịu khi bị chú leader không có trình độ chuyên môn mà cứ áp đặt những cách làm rất trâu bò và thiếu mềm dẻo cho mình. “Leader” khác “manager” ở chỗ, leader cần trình độ chuyên môn cao hơn, biết nhiều về chi tiết kĩ thuật hơn, và thực sự xét về mặt quyền lực thì ngang hàng với các thành viên khác, chỉ có thêm trách nhiệm “dẫn đầu đàn” và “điều phối hoạt động” cho toàn nhóm. Mọi quyết định là do đa số trong nhóm cùng nhau nhất trí, chứ không bị áp đặt bởi một ai cả.

- Vấn đề deadline cần được đối xử một cách tế nhị, nhất là đối với một project dính dáng đến phần mềm, ứng dụng web .v.v. Gia công phần mềm nó khác với việc “đánh cho xong bản report” hay “thắt cà vạt trong vòng 30 giây”. Bạn chỉ có thể đặt ra các mốc thời gian dự định mềm dẻo, chứ khó có thể kiểm soát được một hạn định cụ thể cho một dự án dù nhỏ hay to. Trên thực tế, việc cho ra sản phẩm chậm hơn hạn định dự kiến 3 tháng - 6 tháng là chuyện bình thường, và thậm chí đã có thể coi là “best practice”. Đó là do trong quá trình gia công, không thể lường được hết các thay đổi về mặt kĩ thuật, cũng như lỗi chương trình .v.v. Không nhận thức được điều này, và o ép các thành viên cùng nhóm khác phải hoàn thành trước deadline dĩ nhiên sẽ dẫn đến thất bại của dự án.

- Nếu được phép lựa chọn thành viên, thà chọn ít nhưng chất lượng còn hơn chọn nhiều mà thằng nào cũng làng nhàng. Tớ bị rơi vào hoàn cảnh này nhiều lần. Ghét nhất là phải học lớp nào mà thày không cho chọn nhóm, mà chỉ định nhóm cho từng thành viên. Kết quả là vào toàn nhóm ất ơ. Một nhóm có 6 đứa chẳng hạn, thì 3 đứa là “free rider” (cùng nhóm cho lấy lệ, chứ chả đóng góp gì sất!). Cuối cùng thì cả đội chán nản và một mình mình phải è cổ ra làm hết phần của bọn nó, hay nói cách khác là biến thành “servant” chứ chả phải “leader”. Hiện tại đang làm 1 cái project lèm nhèm của 1 đứa châu Phi nó lead. Do không có hiểu biết về chính lĩnh vực của cái dự án, nên nó toàn lôi bạn bè vớ vỉn vào, rồi chia 2 nhóm, 1 nhóm design (trong đó có thằng lít đờ) và 1 nhóm coder cho trang web. Trong khi mấy cha coder è cổ ra đọc documentation và “vừa xây vừa phá vừa sửa”, thì mấy ông designer thiết kế 1 cái logo mà tớ dùng paint tớ còn vẽ được đẹp hơn, rồi dựng ra 1 cái layout cho trang web mà trông như blog của mấy bạn 9x và cứ nghĩ chỉ việc thay image cho cái default theme của drupal là mọi thứ sẽ hiện ra như ý muốn. Nhưng đâu có đơn giản thế! Cuối cùng việc code cái template rồi lại sẽ phải vào tay bọn coder thôi!

- Gạch đầu dòng cuối cùng, và cũng là quan trọng nhất: Nếu không có trình độ kĩ thuật bằng bọn cùng nhóm, thì nên tập cách lắng nghe. Xét cho cùng thì nếu trình độ không bằng bọn khác thì cũng khó mà có thể đảm đương làm leader được, vì nói chả ai nghe. Nếu muốn người khác nghe mình, thì phải nghe người khác nói trước đã. Hồi trước tớ đọc trong Rich dad Poor dad, có ví dụ về ông Ford. Tớ cũng chả nhớ rõ chi tiết lắm, nhưng đại loại là có người chê Henry Ford (sáng lập ra hãng xe ô tô Ford) là giàu thì có giàu thật, nhưng trình độ văn hóa chưa quá lớp 3. Thế là Ford mới thách người kia hỏi bất cứ câu gì ông cũng trả lời được. Và khi được hỏi về lĩnh vực nào, Ford liền mời cố vấn của mình về vấn đề đó ra giải đáp đâu ra đấy. Tóm lại là, leader giỏi không hoàn toàn đòi hỏi trình độ kĩ thuật phải cao hơn người khác. Mà cái quan trọng là biết chọn người giỏi làm việc cùng mình, và biết nghe ý kiến của người ta, chứ không phải lúc nào cũng coi mình là nhất, và mọi người phải theo ý mình. Chả ai muốn bị một thằng dốt hơn mình giật dây cả.

Còn nếu bạn không phải (hoặc không muốn) làm leader, sau đây có lẽ là vài lời khuyên cho bạn khi phải làm việc theo nhóm:

- Biết nói “không” khi cần thiết. Nếu bạn được mời vào làm cùng một project hứa hẹn lương lậu các thứ rất hấp dẫn đến mấy, nhưng nhìn vào đội hình các team mates mà khấp khểnh, thì nên cân nhắc kĩ trước khi đồng ý. Đến lúc “sa chân vào vũng lầy” không rút ra được, thì bạn sẽ bị dằn vặt vì đã để mình phí thời gian vào nhưng thứ vô ích và vì cảm giác mình bị kẻ khác lợi dụng.

- Biết thẳng thắn đưa ra ý kiến của mình và chả phải sợ bố con thằng nào cả. Nếu bạn gặp leader giỏi, ý kiến của bạn tức khắc được trân trọng dù đúng hay sai. Còn nếu gặp leader tồi, thì lại càng phải thẳng thắn, vì càng thẳng thắn thì cơ hội bị “đá đít” ra khỏi group càng cao. Và khi bị đá đít ra rồi thì bạn rảnh tay để làm việc khác mà không lo gì về trách nhiệm đối với group cũ cả. Hơn nữa thẳng thắn là đức tính tốt, còn “nói lươn nói lẹo”, ba phải cho vừa lòng kẻ khác thì là một biểu hiện của sự hèn nhát.

- Luôn có tinh thần học hỏi người giỏi hơn, và giúp đỡ người kém hơn. Sẽ chả phải hay ho gì nếu bạn chỉ ngồi một chỗ và than trời vì group của bạn toàn thằng kém hơn mình. Tốt nhất là nên xắn tay lên và giúp đỡ họ giỏi hơn bằng mọi cách có thể. Còn nếu bạn là “chú gà con xấu xí” trong nhóm, thì cũng chả việc gì phải mất tự tin. Nếu bạn không tỏ ra kiêu kì và bảo thủ, người giỏi hơn sẽ sẵn lòng chỉ dạy cho bạn. Nếu biết tiếp thu những cái giỏi và lọc ra những cái sai thì chả mấy chốc mà bạn giỏi bằng hoặc hơn người ta.

- Đừng ôm đồm trách nhiệm, chỉ cần làm tốt phận sự của mình và giúp đỡ người khác đúng mức. Nếu công việc của bạn được giao là “code cái template”, thì cứ code cho tốt cái đã. Còn nếu các thành viên khác không chịu làm việc, thì cũng chả việc gì phải lo lắng để mà làm hết các phần việc khác cho bọn nó. Chuyện thất bại là chuyện bình thường, và chả có gì đáng xấu hổ cả khi bạn đã cố gắng hết sức cho phần việc của mình. Tớ thì tớ thường hay lo bọn cùng nhóm nó không chịu làm việc, kéo điểm của mình xuống. Nên cuối cùng toàn là tớ lo việc type cái report, làm cái powerpoint và viết sẵn cái script cho bọn kia nó đọc lúc presentation. Nhưng từ giờ nhất định chả phải coi nặng chuyện điểm chác nữa, chỉ làm phần việc của mình, thời gian còn lại để làm việc khác có ích hơn.

Còn đây là một vài lời khuyên chung cho cả leader lẫn thành viên bình thường:

- Chỉ nên nêu ý kiến khi mình thật sự có kiến thức về những cái mình định nói. Nếu ba hoa bốc phét về một vấn đề mà mình không biết chắc thì sẽ làm giảm uy tín của bản thân, sau này nói chả ai muốn nghe nữa.

- Luôn có tinh thần tích cực khi tham gia. Không nên bàn lùi hay quá bi quan về tiến độ của dự án.

- Trong đầu luôn phải tính toán cả những trường hợp xấu nhất (thất bại). Nếu bạn chưa lo xong các vấn đề nền tảng thì đừng nghĩ ngay tới việc quảng cáo cho sản phẩm khi thực sự chưa làm ra được nó. Và đừng quá nghiêm khắc khi kế hoạch của bạn thất bại, mà nên nhìn lại vấn đề một cách tích cực, đưa ra nhận xét và rút ra bài học.

- Tìm và thống nhất phong cách làm việc phù hợp nhất. Ví dụ như nếu các thành viên nhà ở xa nhau, hay không thể xếp lịch cho meeting được, thì nên tìm phương cách khác để communicate với nhau, ví dụ như sử dụng bulletin board, instant messenger .v.v. Có rất nhiều web app hỗ trợ project management miễn phí. Không phải cứ lúc nào cũng mặc vest và dắt díu nhau đi họp một cách formal là tỏ ra chuyên nghiệp. Chuyên nghiệp hay không là ở năng suất, không phải do hình thức.

- Và lời khuyên cuối cùng: tốt nhất hãy làm sao để bạn có thể hoàn thành công việc một mình, hoặc cùng lắm thì chỉ cần group nhỏ (dưới 4 người). Nếu bạn đang chuyên về flash chẳng hạn, thì hãy cố mở rộng sang web designing bằng XHTML/CSS, rồi theming in Drupal, Joomla, Wordpress .v.v. và cố master ít nhất 1 ngôn ngữ lập trình web nữa. Tất nhiên làm việc được một mình là trường hợp lí tưởng, còn không thì cùng làm với vài ba người thân cận nhất mà bạn tin tưởng được. Càng cho thêm các thành viên mà độ tin cậy chưa cao thì rủi ro của dự án lại càng lớn.

Tớ kết lại bài viết này bằng câu sau, trích trong bài phỏng vấn với Steve McConnell khi nói về software engineering, ý nghĩa thì cũng quá rõ ràng rồi nhỉ

a quarter of the projects are canceled before they’re completed and another 50 percent are completed over budget or behind schedule. And 25 percent are completed on time and on schedule, but the piece that’s always missing from those surveys is how much of the original functionality was delivered in that 25 percent that was on time and on budget.

Lesson 1: Naked Wife

A man is getting into the shower just as his wife is finishing up her shower when the doorbell rings. The wife quickly wraps herself in a towel and runs downstairs. When she opens the door, there stands Bob, the next door neighbor. Before she says a word, Bob says, I will give you $800 to drop that towel. After thinking for a moment, the woman drops her towel and stands naked in front of Bob. After a few seconds, Bob hands her $800 dollars and leaves. The woman wraps back up in the towel and goes back upstairs. When she gets to the bathroom, her husband asks: Who was that? It was Bob the next door neighbor, she replies. Great! the husband says, Did he say anything about the $800 he owes me?

Moral of the story: If you share critical information pertaining to credit and risk with your shareholders in time, you may be in a position to prevent avoidable exposure.

Lesson 2

A sales rep, an administration clerk, and the manager are walking to lunch when they find an antique oil lamp. They rub it and a Genie comes out. The Genie says, I will give each of you just one wish. Me first! Me first! says the admin clerk. I want to be in the Bahamas, driving a speedboat, without a care in the world. Poof! She is gone. Me next! Me next! says the sales rep. I want to be in Hawaii,relaxing on the beach with my personal masseuse, an endless supply of Pina Coladas and the love of my life. Poof! He is gone. OK, you are up, the Genie says to the manager. The manager says: I want those two back in the office after lunch.

Moral of the story: Always let your boss have the first say.

Lesson 3

A priest offered a lift to a Nun. She got in and crossed her legs, forcing her gown to reveal a leg. The priest nearly had an accident. After controlling the car, he stealthily slid his hand up her leg. The nun said: Father, remember Psalm 129? The priest removed his hand. But, changing gears, he let his hand slide up her leg again. The nun once again said: Father, remember Psalm 129? The priest apologized Sorry sister but the flesh is weak. Arriving at the convent, the nun went on her way. On his arrival at the church, the priest rushed to look up Psalm 129. It said: Go forth and seek, further up, you will find glory.

Moral of the story: If you are not well informed in your job, you might miss a great opportunity.

Lesson 4

A crow was sitting on a tree, doing nothing all day. A rabbit asked him: Can I also sit like you and do nothing all day long? The crow answered: Sure, why not. So, the rabbit sat on the ground below the crow, and rested.
A fox jumped on the rabbit and ate it.

Moral of the story: To be sitting and doing nothing, you must be sitting very high up.

Lesson 5: Power of Charisma

A turkey was chatting with a bull I would love to be able to get to the top of that tree, sighed the turkey, but I haven’t got the energy. Well, why don’t you nibble on my droppings? replied the bull. They’re packed with nutrients. The turkey pecked at a lump of dung and found that it gave him enough strength to reach the lowest branch of the tree. The next day, after eating some more dung, he reached the second branch. Finally after a fourth night, there he was proudly perched at the top of the tree. Soon he was spotted by a farmer, who shot the turkey out of the tree.

Moral of the story: Bullshit might get you to the top, but it wont keep you there.

Lesson 6

A little bird was flying south for the winter. It was so cold the bird froze and fell to the ground into a large field. While he was lying there, a cow came by and dropped some dung on him. As the frozen bird lay there in the pile of cow dung, he began to realize how warm he was. The dung was actually thawing him out! He lay there all warm and happy, and soon began to sing for joy. A passing cat heard the bird singing and came to investigate. Following the sound, the cat discovered the bird under the pile of cow dung, and promptly dug him out and ate him.

Moral of the story:
1. Not everyone who shits on you is your enemy
2. Not everyone who gets you out of shit is your friend
3. And when you’re in deep shit, it’s best to keep your mouth shut!

Bổ ích nhất là cái bài học cuối cùng

Vào ngày 25/02/1993, Ruby được chính thức … “thụ thai” bởi Yukihiro Matsumoto (tên gọi trên mạng là Matz) nhờ tình yêu mãnh liệt giữa anh và cái máy tính. Nói đúng hơn là anh ấy bắt đầu xây dựng Ruby kể từ ngày đó, và sau 2 năm, đến năm 1995 thì Ruby mới được chính thức ra đời. Có nghĩa là nói 25/02 là ngày sinh nhật của Ruby thì cũng không chính xác, nhưng mặc kệ, dẫu sao thì cũng là 1 ngày đáng nhớ.

Vậy tại sao Matz lại chọn Ruby làm cái tên cho ngôn ngữ của mình tạo ra?

Ruby không phải một cái tên viết tắt. Đơn giản chỉ là vì Ruby chịu nhiều ảnh hưởng từ Perl, và khi hoàn tất ngôn ngữ này, anh đã đùa với một người bạn rằng nên đặt tên thế nào nghe cho nó giống một thứ đá quý nào đó (Perl lúc đầu cũng được đặt tên là Pearl - ngọc trai). Và bạn của anh đã gợi ý cái tên Ruby. Sau này Matz cũng bất ngờ khi phát hiện ra Pearl là viên đá quý tượng trưng cho những người sinh tháng 6, còn Ruby thì tượng trưng cho những người sinh tháng 7. Anh cho rằng cái tên Ruby như thế là phù hợp vì Ruby kế thừa và phát triển nhiều đặc tính từ Perl.

Một số cột mốc quan trọng trong quá trình phát triển Ruby

• 24/02/1993: Matz bắt tay vào công việc “sáng tạo” ra ngôn ngữ Ruby.
• Tháng 12/1994: Phiên bản alpha đầu tiên của ngôn ngữ được hoàn tất.
• 1997: Tài liệu hỗ trợ cho ngôn ngữ Ruby được chuyển sang tiếng Anh
• Cuối năm 1998: thành lập mailing list ruby-talk cho cộng đồng người sử dụng Ruby ngoài Nhật Bản. Cho đến trước thời điểm này, không có nhiều lập trình viên nước ngoài biết đến Ruby, trong khi Ruby đã khá thành công ở Nhật. Từ đây, cơn bão Ruby dần dần hình thành.
• 2001: JRuby ra đời, đánh dấu bước tiến mới của Ruby. JRuby là trình dịch Ruby viết bằng Java, và giúp cho việc lập trình kết hợp giữa Ruby và Java trở nên dễ dàng hơn.
• Tháng 7/2004: Ruby on Rails ra mắt cộng đồng lập trình viên ứng dụng web. Rails là một framework hỗ trợ xây dựng một cách nhanh chóng các ứng dụng web dựa trên nền tảng kiến trúc MVC (Model-View-Controller). Sau này Rails thu hút được rất nhiều sự chú ý từ các web developer nhờ tốc độ phát triển ứng dụng cũng như tính mềm dẻo của framework này, đồng thời cũng là do những đặc tính thú vị của Ruby. Từ đó trở đi, Rails trở nên phổ biến ngang ngửa với PHP, và Ruby nhờ đó cũng được càng nhiều người biết đến.
• Tháng 5/2006: JRuby hỗ trợ Rails
• 30/4/2007: IronRuby được Microsoft chính thức công bố. IronRuby là nỗ lực của các lập trình viên nhằm đưa Ruby vào .NET framework của Microsoft.
• 23/7/2007: Bản pre-alpha của IronRuby ra mắt trước công chúng
• 25/12/2007: Ruby 1.9 chính thức ra mắt với nhiều tính năng mới (hỗ trợ Unicode tốt hơn, sử dụng YARV .v.v.), tuy nhiên các phiên bản số lẻ thường là phiên bản dành cho cộng đồng phát triển và thử nghiệm. Phải chờ đến phiên bản 2.0 thì lập trình viên mới có thể sẵn sàng tận dụng các tính năng mới mẻ cho sản phẩm của mình.

Sau 15 năm kể từ khi được xây dựng từ những dòng code đầu tiên, Ruby đã có những bước tiến khá xa. Nhiều người vẫn phủ nhận sự thành công của ngôn ngữ này với lí do sau những 15 năm mà Ruby mới tiến tới phiên bản 1.9. Nhiều người khác thì lại trở nên dị ứng với cái tên Ruby vì sự nổi đình nổi đám của nó những năm gần đây. Dân học lập trình Việt Nam thì càng không muốn động tay vào ngôn ngữ có cái tên lạ hoắc này. Nhưng tớ tin là trong 1 thời gian ngắn nữa, Ruby sẽ là cái tên được nhắc đến rất nhiều tại Việt Nam, và sẽ ngày càng có nhiều người học Ruby hơn.

Đơn giản là vì bận quá, vướng mắc vào bao nhiêu thứ việc dù là kì nghỉ 2 tháng: bận học, bận làm và bận chơi.

Về VN nghỉ tết đợt này biết là sẽ chả tập trung vào làm được việc gì (mà thực ra là chưa bao giờ serious với cá gì cả). Năm mới thế là không ổn. Hôm trước còn bị sốt mất 1 ngày, và 3 ngày liền rồi chả học hành và làm việc gì sất, toàn ngồi xem phim, chơi game và lướt web vớ vỉn.

Có lẽ đến lúc phải serious trở lại vì tháng nữa là lại vào năm học, chả có thời gian nữa. Những mục tiêu phải hoàn tất trong vòng 1 tháng:

• Đuổi kịp lớp Ruby của bác Satish.
• Cày xong quyển Pro Drupal Development cho cái project của ông hiệu trưởng (đi đâu cũng khoe là tao làm cho ông hiệu trưởng nhưng thực ra chả chịu làm gì cả )
• Vọc dần Drupal 6, đến khi ra CCK và Views thì làm 1 cái sản phẩm gì đó cho vui

Ờ thì nói dễ hơn làm. Nhưng mà ít nhất có tí gọi là định hướng. Về Nhật không gian yên tĩnh, chắc dễ ngồi yên 1 chỗ làm các thứ một mạch hơn.

Tiện thể đang quyết tâm, thử “vạch kế hoạch” một phát cho năm sắp tới xem sao:

• Master lại XHTML/CSS
• Học Javascript tử tế từ đầu
• Tập trung vào Drupal
• Học cho xong khoá Ruby, dịch xong đống tài liệu đó sang tiếng Việt
• Động tay động chân vào Rails
• Mục tiêu là ít nhất xong 1 sản phẩm gì đó trong năm

Có vẻ hơi ôm đồm tẹo, nhưng tóm lại 3 cái quan trọng nhất phải xong trong năm là Drupal, Ruby, và Rails. Sang năm sau tính tiếp, nhưng đường hướng là trở thành một web developer.

Đã tiếp tục dịch thêm mấy chương tài liệu về Ruby. Hi vọng là đuổi kịp được lớp trong 2 tuần tới.

TIOBE là 1 công ty phần mềm (hình như thế). Họ tự lập ra chỉ số TIOBE để xếp hạng các ngôn ngữ dựa trên mức độ phổ biến. Vậy họ dựa trên tiêu chí nào để đánh giá?

Bảng xếp hạng các ngôn ngữ phổ biến nhất dựa trên chỉ số TIOBE
(Click vào để xem đầy đủ)

Tiêu chí đánh giá

Rất khó để có thể biết được chính xác đã có bao nhiêu dự án dùng ngôn ngữ A, bao nhiêu dòng mã được biết bởi ngôn ngữ B, bao nhiêu người đang sử dụng ngôn ngữ C .v.v. Vậy nên hiện giờ cách tốt nhất là xem xem ngôn ngữ nào được nhắc đến nhiều nhất trên mạng. Đó là cách làm của TIOBE.

Họ chọn các cỗ máy tìm kiếm phổ dụng nhất: Google, Google Blogs, MSN, Yahoo và cả dịch vụ chia sẻ video YouTube để xếp hạng các ngôn ngữ (bản thân các cỗ máy này cũng được chọn lọc dựa trên xếp hạng của alexa). Cách tính chỉ số như sau:

Họ sử dụng câu lệnh search +”{ngôn ngữ} programming” trên các cỗ máy tìm kiếm trên, và ghi lại số kết quả của mỗi cỗ máy. Sau đó dùng tổng số kết quả để sắp xếp các ngôn ngữ, và chọn ra 50 ngôn ngữ đứng đầu.

Tiếp theo họ tính chỉ số của từng ngôn ngữ trong 50 ngôn ngữ này bằng phép tính sau:

((hits(PL,SE1)/hits50(SE1) + … + hits(PL,SEn)/hits50(SEn))/n

Trong đó PL là ngôn ngữ lập trình đang xét. SE1, SE2 … SEn là các cỗ máy tìm kiếm (n = 5). hits(PL,SE1) là số kết quả tìm kiếm ngôn ngữ lập trình PL trên cỗ máy SE1. hits50(SE1) là tổng số kết quả của 50 ngôn ngữ đã chọn ra ở trên tìm được trên cỗ máy SE1.

Như vậy, TIOBE index (chỉ số TIOBE) đánh giá gần sát với thực tế về độ phổ biến của các ngôn ngữ trên internet.

Chỉ số này được dùng để làm gì?

Theo định nghĩa chính thức của chỉ số này, các ngôn ngữ được cho điểm A, A-, A–và B. Trong đó các ngôn ngữ điểm A là các ngôn ngữ được đánh giá là chính thống. B là không chính thống, còn A- và A–là nằm ở giữa 2 loại này. Nếu một ngôn ngữ nào giữ được chỉ số TIOBE ở khoảng 0.7% trong vòng ít nhất 3 tháng thì sẽ được điểm A. Trong hai tháng đầu có mặt trong bảng xếp hạng, ngôn ngữ đó sẽ có điểm A– và A-.

Như vậy dựa trên thang điểm đánh giá này, ta có thể đánh giá được xu hướng phát triển của các ngôn ngữ, từ đó xác định được mình nên bổ xung ngôn ngữ nào vào vốn kiến thức của mình để không trở nên lỗi thời.

Nhìn lại bảng xếp hạng, ta có thể để ý thấy vài điểm sau:

Ngôn ngữ họ C đang mất dần ưu thế

Mặc dù đang đứng thứ 2 sau Java, chỉ số của C đang tụt xuống nhanh chóng. Cách đây 7 năm C vẫn chiếm 20% số kết quả search, nhưng giờ đây đã tụt xuống còn 13%. Ta cũng có thể thấy C là một trong số ít các ngôn ngữ lập trình cấu trúc còn trụ lại trong bảng này đến giờ (Pascal đứng thứ 19 nhưng không bị giảm sút “phong độ” quá nhiều). C++ cũng đang có chỉ số giảm dần và chắc năm sau sẽ mất vị trí vào tay Python.

Các ngôn ngữ mới như Lua và Ruby đang được đón nhận nồng nhiệt

Nhìn vào biểu đồ có thể thấy các ngôn ngữ này trưởng thành nhanh như thế nào. Mặc dù đều được sáng tạo ra từ giữa thập kỉ 90, nhưng thời gian gần đây đã chứng kiến sự bùng nổ mối quan tâm về các ngôn ngữ mới này. Có thể hôm nay là lần đầu tiên bạn nghe thấy những cái tên đó, nhưng không biết năm sau bao nhiêu cái tên mới sẽ nổi lên và bao nhiêu cái tên cũ sẽ chìm vào quên lãng.

Các ngôn ngữ bạn nên bắt đầu có kế hoạch học từ hôm nay

Java – chắc chắn phải một thời gian dài nữa mới chịu nhường lại ngôi vị của mình cho ngôn ngữ khác.
Visual Basic - khả năng phát triển ứng dụng nhanh chóng trong VB là thế mạnh lớn của ngôn ngữ này. Nhiều người chỉ trích VB là sẽ làm cho coder trở nên lười nhác, nhưng thực tế VB năng suất hơn C++ nhiều đối với những ứng dụng quy mô nhỏ và không đòi hỏi tài nguyên cấu hình cao.
PHP – học lập trình Web ít nhất nên biết qua.
Ruby – Tớ cá với các bạn là năm nay bạn sẽ nghe thấy cái tên này rất nhiều. Ruby on Rails là bộ khung lập trình Web có năng lực ngang bằng với PHP (nhiều khi lại năng suất hơn).
Lua – Chắc bạn nên dành ngôn ngữ này cho 1 hoặc 2 năm nữa sau khi được cộng đồng hỗ trợ nhiều hơn. Nhưng nên làm quen dần với cái tên này

Tuy nhiên các bạn không nên dựa vào bảng xếp hạng này để quả quyết ngôn ngữ nào là hay hơn hay thông dụng hơn ngoài đời, vì những con số này chưa chắc đã chính xác. Các cỗ máy tìm kiếm thay đổi thuật toán thường xuyên, và với sự bùng nổ của Internet thì không có gì là tuyệt đối cả. Các bạn chỉ nên sử dụng chỉ số này để tham khảo xem mình nên học tiếp gì và định hướng nghề nghiệp sau này của mình ra sao

Chúc may mắn

powered by ODEO

Shock phần 1
Shock phần 2

Cho đến một hôm lôi quyển “Programming Ruby 2nd Edition” ra đọc đến phần Variable, mới biết “Everything is an object” là không hoàn toàn chính xác.

Có 1 thứ không phải là đối tượng…

Chắc bạn cũng có thể đoán ra mang máng rồi. Đó chính là Biến.
Trong Ruby, biến có cách làm việc khác với một số ngôn ngữ khác. Hãy cùng thử ví dụ này nhé:

string = 'aha'
str = string
string[2] = 'o'
puts str
puts string

Bạn thử đoán xem kết quả cho ra màn hình là thế nào? Kết quả là cả 2 biến str và string sẽ đều mang giá trị là ‘aho’.

Nhưng trong đoạn code trên ta chỉ thay đổi biến string, chứ không hề động đến biến str1. Và ta thay đổi đó xảy ra sau khi str được gán giá trị cũ của string. Nếu như biến là đối tượng, thì khi ta gán string = ‘aha’, đối tượng string sinh ra với giá trị ‘aha’. Tương tự gán str = string sẽ tạo thêm ra một đối tượng nữa có giá trị mà string đang mang. Khi thay đổi giá trị của đối tượng string, đối tượng str sẽ không bị vạ lây.

Biến không phải là đối tượng, thì biến là cái chi?

Biến là giá trị tham chiếu. Khi ta gán cho một biến một giá trị mới, một đối tượng mới sẽ được tạo ra trong bộ nhớ, và biến đó sẽ “trỏ” vào đối tượng đó. Tưởng tượng mỗi lần bạn truy vấn giá trị của biến, biến sẽ lại truy vấn giá trị của đối tượng, và trả lại cho bạn giá trị của đối tượng. Vậy có nghĩa là, biến và đối tượng không phải là một.

Còn khi bạn gán cho một biến giá trị của một biến đã có sẵn, điều gì xảy ra? Biến mới sẽ lập tức được tham chiếu vào đối tượng mà biến có sẵn kia “trỏ” tới. Tóm lại, cả 2 biến này “trỏ” tới cùng 1 giá trị giống nhau.

Khi bạn thay đổi (thay đổi thôi nhé, chứ không phải là gán cho giá trị mới) giá trị của một biến, thực chất là bạn thay đổi giá trị của đối tượng gốc. Xin xem hình minh họa sẽ rõ:

Thế nếu tôi gán cho biến string một giá trị mới, str1 có thay đổi theo không?

Cùng xem đoạn code này nhé:

string = 'aha'
str = string
string = 'oho'
puts str
puts string

Bạn sẽ thấy ngay str1 vẫn “trỏ” đến giá trị ‘aha’, trong khi string thì lại là ‘oho’. Tại sao lại có sự khác biệt này?

Đơn giản là do khi gán string = ‘oho’, ruby nhận ra là string có 1 giá trị mới hoàn toàn (chứ không phải là chỉ thay đổi 1 chữ cái như ở ví dụ trên). Do đó ruby sẽ tạo ra 1 đối tượng mới (oho) để string “trỏ” vào.

Cách sao chép biến đúng trong Ruby

Để thực sự sao chép giá trị của một biến, thay vì chỉ tham chiếu đến giá trị của biến đó, ta dùng phương thức “dup”. Câu lệnh gán sẽ phải như sau:

str = string.dup

“Not everything is an object”

Tóm lại, Ruby vẫn là một ngôn ngữ thuần túy hướng đối tượng, bởi vì “Although not everything is an object, Everything you manipulate is an object” (Mặc dù không phải cái gì cũng là đối tượng, nhưng trong Ruby tất cả các thứ bạn tác động tới đều là đối tượng).

Giáo trình của bác Satish này khá hay. Không mất thời gian giải thích lòng vòng, bác ấy đi thẳng luôn vào vấn đề và dùng nhiều code mẫu. Thế nên tớ nghĩ là những bạn mới học lập trình, hoặc mới biết đến Ruby sẽ không gặp nhiều khó khăn cho lắm.

Tuy thế dịch một tài liệu tin học từ tiếng Anh sang tiếng Việt không phải là chuyện đơn giản. Kiến thức tin học lập trình của tớ thì cũng chưa phải là sâu rộng gì, nên chắc sẽ có một số chỗ tớ dịch không chuẩn xác. Ai bắt gặp lỗi nào thì bảo cho tớ biết nhá

Tài liệu tớ dịch được post tại đây:

Tự học Ruby

Quyển đầu tiên tớ muốn nói đến là quyển “Why’s (Poignant) Guide to Ruby” của _why - một trong những thành viên kì cựu trong cộng đồng Ruby (đấy là tớ nói thế, chứ thật sự tớ chỉ đọc sách của bác này, chứ không biết gì nhiều về bác ấy).

Quyển này khá thú vị và vui nhộn. Tác giả còn vẽ cả truyện tranh chèn vào, các ví dụ không nhất thiết là phải giải thích kĩ lưỡng, nhưng mà người đọc vẫn thấy dễ hiểu. Đọc quyển này thấy khá là có hứng. Bác _why này cũng làm cả trang try ruby! Cũng nhờ trang này mà tớ thấy thích thú với ngôn ngữ Ruby mới này. Bạn nào chưa biết, hoặc mới nghe đến Ruby chứ chưa thử, thì vào try it out đi đã Đảm bảo sẽ thấy thích thú ngay. Bạn cũng có thể download bản mp3 của quyển sách này. Nhưng mà cách này thì tớ chưa thử, mà cũng chả tưởng tượng là ông ấy sẽ đọc code bằng mồm hay là thế nào nữa

Quyển thứ hai là quyển “Humble Little Ruby Book” của Jeremy McAnally. Quyển này cũng có thể download free trên mạng nốt, nhưng có thêm một lựa chọn nữa là mua bản in của quyển này (chỉ có tầm 9$, quá rẻ so với những quyển khác).

Quyển này thì tớ chưa có động đến. Nhưng đọc qua mục lục cũng đoán được style của tác giả này khá là dễ đọc và không bị nhàm chán. Chỉ có điều đọc lướt qua tớ phát hiện ra hình như nó viết cho ruby 1.8.5, trong khi bản mới nhất bây giờ là 1.8.6, và sắp tới là 1.9 đến nơi rồi. Tuy nhiên thay đổi giữa version cũ và version mới của một ngôn ngữ không thành vấn đề lắm, miễn là bạn nắm được cái core philosophy của ngôn ngữ này.

Để down quyển này bạn cần đăng ký tài khoản tại InfoQ (trang này tổng hợp tin tức và các bài viết về CNTT và lập trình khá hay!). Hoặc là bạn cũng có thể đọc nó online trên scribd.

Quyển thứ ba, không hẳn là quyển sách, mà là một khóa học free về Ruby trên mạng của bác Satish Talim. Bác này 29 năm làm trong ngành rồi. Khóa học đầu tiên bác ấy mở là vào tháng 8 năm 2005 (nếu tớ không nhầm). Sắp tới từ ngày 7/1/2008 sẽ có khóa học mới, bạn nào không ngại học bằng tiếng Anh thì nhanh tay vào đăng ký khóa học từ bây giờ. Chương trình học và giáo trình thì có cả trên trang của bác này rồi, bạn có thể tham khảo trước. Tớ thì chưa học bác này bao giờ, nên không biết là online course của bác ấy thế nào, nhưng chắc chắn là sẽ có tương tác giữa học sinh và thày giáo. Cái này hay, bởi vì sách bình thường thì chỉ tự đọc tự ngẫm thôi, còn có thày dắt theo thì sẽ đỡ bị mất thì giờ vào những vướng mắc không đâu. Bạn cũng nhớ đọc các bài viết trên blog của trang đó nhé, nhiều bài khá bổ ích.

Tớ cũng vừa đăng ký course của bác này (chờ mãi). Trước đó tớ đã xin phép bác ấy dịch giáo trình của bác sang tiếng Việt, để các bạn mới học lập trình, hoặc mới làm quen với Ruby ở Việt Nam có cơ hội tiến nhanh với Ruby hơn, mà đó cũng là một cách để tớ vừa học vừa ôn. Bác ấy đã nhận lời cho phép, và hiện tại tớ đã dịch xong phần … mục lục. Sẽ dần dần post lên blog này để mọi người theo dõi và góp ý chỉnh sửa

Ngoài việc tự học theo sách, hoặc là học theo course như trên, bạn cũng có thể tìm “gia sư” Ruby cho mình. Rất đơn giản, chỉ cần chọn lấy một bác trong list và gửi email cho người ta (bằng tiếng Anh). Mỗi người sẽ có hình thức dẫn dắt khác nhau. Nhưng học cái gì đó mà có người định hướng cho mình thì bao giờ cũng dễ dàng và đỡ tốn thời gian vô ích hơn.

Tất nhiên là để học Ruby hiệu quả thì chỉ có thế chưa đủ. Bạn còn phải subscribe một đống blog về Ruby, lướt các forum .v.v. rất nhiều nữa. Bài viết này tớ chỉ giới thiệu vài nguồn tài liệu Ruby miễn phí trên mạng để bạn có thể khởi đầu với ngôn ngữ khá thú vị và cũng đang “hot” này.

Gọi là xông nhà bởi vì đây là bài viết đầu tiên trong blog. Nhưng mà thật ra cũng chả phải là bài viết đầu tiên.

Cách đây hơn 6 tháng tôi mua domain và host này để làm một cái blog về CNTT. Nhưng sau đó mấy tuần thì … mất hứng. Thế là từ đó trở đi cái host được tận dụng làm 1 cái rapidleech server, và để lưu trữ 1 số thứ khác.

Cho đến ngày hôm qua, đang vật lộn với đống sách vở Ruby, thấy mọi thứ lằng nhằng quá. Không có một cái gì đó để theo dõi cái learning progress của mình, đâm ra là sau mấy tháng vẫn thấy mình chỉ là 1 cu n00b không viết được 1 đoạn script Ruby nào ra hồn mà không phải giở sách ra coi lại. Haizz, học hành thế là không có được…

Thế nên sáng nay thức dậy một phát (lúc 12h trưa) là ngồi vào máy vọc ngay cái Wordpress lên để nghịch. Từ giờ blog này sẽ dùng để ghi chép những gì mà mình học và khám phá ra được (not limited to Ruby or IT stuffs), rồi thì cũng là để sau này lúc nào bored mà không dám động đến game (kẻo tái nghiện) thì lôi blog ra đọc đi đọc lại cho vui.

Viết 1 bài khởi động thế, lúc khác viết tiếp sau