Archive for Lập trình
March 26, 2008 at 4:30 pm · Filed under Lập trình, Ruby
Từ hồi tớ học Ruby, lại bị tiêm nhiễm thêm một thói quen vừa tốt vừa xấu. Đó là khi thực hành giải mấy bài toán vớ vửn đơn giản, tớ toàn bị ám ảnh phải làm sao để code của mình ít dòng, ít chữ cái nhất có thể. Dần dần CodeGolf trở thành chỗ chơi của mình lúc nào không biết.
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!
March 8, 2008 at 1:35 pm · Filed under Lập trình, Software Engineering
Một trong những cái đau đớn nhất của việc làm việc theo nhóm, đó là: phải làm cùng 1 chú leader gà con đầu óc rỗng tuếch và quan liêu.
Điều đau đớn thứ hai, đó là khi mình thẳng thắn chỉ ra chỗ sai của hắn, thì những thằng cùng nhóm khác bỏ ngoài tai và quay ra liếm đ’t thằng leader.
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.
February 25, 2008 at 8:01 pm · Filed under Lập trình, OOP, Ruby
Hic, hôm qua quên béng mất, hôm nay nhìn lại lịch thì đã là 25 mất rồi. Nói chung là các thứ mốc thời gian quan trọng tớ đều toàn bỏ lỡ cả
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.
February 22, 2008 at 4:57 pm · Filed under Linh tinh, Lập trình
Năm mới dương lịch được gần 3 tháng, tết nhất thì cũng qua lâu rồi. Thế mà hôm nay mình mới khai bút đầu xuân ở cái blog này 
Đơ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.
January 6, 2008 at 10:06 pm · Filed under Lập trình
Hôm qua rong chơi trên mạng thì tìm được trang này: http://www.tiobe.com/index.htm?tiobe_index
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
