Cảm nhận về nước Nhật của gia đình Ổi

Một ngày cuối tuần, cả nhà Ổi đi chơi. Bố lái xe. Mẹ thích nhất cảm giác ngả ngốn ở ghế sau, chìm mình trong tiếng nhạc, ngắm những vạt cây lướt vun vút trên nền trời xanh qua ô cửa kính, và nghĩ ngợi vẩn vơ .... Trong khung cảnh thật yên bình, mẹ nghĩ đến những tháng ngày mình đang sống - cuộc sống ở Nhật, đến xã hội này, con người ở đây, ... rồi mẹ chợt nhận ra cái này thật ngộ: Đây chính là xã hội chủ nghĩa...  
Hihi...thực ra, bao nhiêu kiến thức lý luận triết học, xã hội học, kinh tế học về xã hội chủ nghĩa đầy cao siêu đã học trong trường ĐH mẹ Ổi quên tiệt hết rồi. Chủ nghĩa xã hội theo cách hiểu của mẹ Ổi chỉ đơn giản là một xã hội thật đẹp, như những gì mẹ đã mường tượng ra qua những bài tập đọc sách đạo đức lớp 5, nơi có những con người sống trung thực nhặt được của rơi trả người đánh mất, sống trách nhiệm như bạn Thắng trên đường đi học về thấy thanh ray đường tàu bị trật đã tìm mọi cách báo hiệu cho đoàn tàu dừng lại...nơi con người ta sống bình đẳng, yêu thương nhau, không có người nghèo khổ ... thì đây, chính là những gì mẹ nhìn thấy.
 
Tại sao nói là bình đẳng. Tất nhiên đây chỉ là khái niệm tương đối. Bình đẳng ở đây không phải là cào bằng, nhưng có thể nói xã hội Nhật bản đã xây dựng được một hệ thống phân phối của cải một cách khá đồng đều, mà người ta vẫn lao động nghiêm túc, lao động hết mình. Có lẽ không nước nào trên thế giới này có tỷ lệ dân số middle class lớn như ở Nhật. Phải khoảng 80-90% dân số Nhật có mức sống trung lưu. Nghĩa là hầu hết mọi người trong xã hội có mức sống như nhau, có chăng chỉ là một sự chênh lệch rất thấp, không có quá nhiều người rất giàu hay quá nhiều người rất nghèo. Hầu hết mọi người dù ở nông thôn hay thành thị cũng đều ăn uống như nhau, cho con đi học ở những trường học có cơ sở vật chất như nhau, dịch vụ y tế, bệnh viện...về cơ bản như nhau. Cái cột điện ở Tokyo thế nào thì cái cột điện ở một nơi nhà quê hẻo lánh nhất cũng như thế. Không có chuyện cột điện ở Tokyo bằng bê tông sắt thép, còn ở nhà quê làm bằng cột tre... Hihi ...Mọi thứ đều đã được chuẩn hoá, cứ thế mà theo. Ở Nhật dù làm nghề gì, thì thu nhập cũng thường ở một mức nhất định tương đương nhau. Mới đầu mẹ Ổi cảm thấy rất sáo rỗng khi nghe người Nhật nói: tôi muốn làm tiếp viên hàng không vì muốn mang văn hoá Nhật bản đi ra thế giới, vì muốn cống hiến cho khách hàng những phút giây thư giãn trên chặng bay dài. Tôi muốn làm y tá để xoa dịu nỗi đau đớn của người bệnh. Tôi muốn làm cảnh sát để góp phần giữ gìn xã hội trật tự, yên bình .... Nhưng giờ mới hiểu họ nói thật lòng. Đơn giản vì dù làm nghề nào ở thành phần kinh tế nào, người đi làm nhà nước, hay làm công ty, hay nông dân làm ruộng, về cơ bản thu nhập cũng tương đương nhau, nên người ta chọn nghề theo sở thích. Không có chuyện lương cao vượt bậc, làm nghề nọ, công ty nọ lương gấp 10 lần nghề kia, công ty kia. Ai thấy mình thích hợp với việc gì thì làm việc ấy. Cũng chính nhờ thế người ta có tình yêu với công việc hơn, làm việc hết mình hơn. Và ở Nhật người ta cũng đánh giá theo việc chăm chỉ cần cù nhiều hơn là năng lực. Đúng là làm theo năng lực, hưởng theo lao động. Không phải ai sinh ra cũng giỏi giang, nhưng dù là ai, dù làm việc gì cao sang hay thấp hèn, miễn anh chăm chỉ lao động, anh sẽ có thu nhập và cuộc sống tốt như của mọi người.
Tất nhiên vẫn có những người giàu, rất giàu (thường những nghề có thu nhập đặc biệt như giới nghệ sĩ, hoặc doanh nhân lớn) còn phải nói là người nghèo thì rất hiếm gặp. Ít đến mức mỗi khi nhìn thấy một người nghèo ở đây mẹ Ổi đều cảm thấy thương vô cùng. Mà nghĩ kỹ ra thì những người trông khổ sở hơn như thế nhiều mình vẫn gặp đầy rẫy trước đây mà sao không thấy thương bằng. Trong khi những người này chỉ là trông mặt họ đen đúa gió sương hơn, quần áo trên người cũ kỹ một tý mà mình thấy mủi lòng. Chắc vì ai ai ở đây cũng trắng trẻo, bóng bẩy cả mà.
1 người bạn VN thắc mắc, sao ở Nhật mình gặp nhiều người khuyết tật thế nhỉ. Bố mẹ Ổi lý giải thế này, và người bạn đó đã gật gù công nhận đúng: Vì người khuyết tật ở đây không bị lãng quên, người ta vẫn có mặt trên mọi nẻo đường của cuộc sống. Tivi có chương trình thời sự nói bằng tay cho người điếc. Chương trình trẻ em hàng sáng có phần dành riêng cho trẻ kém phát triển. Vỉa hè luôn có vạch cho người mù, hiếm có toà nhà nào, dù to dù nhỏ, lại không có lối cho người đi xe lăn...Vậy là họ ra đường nhiều, họ tham gia các hoạt động xã hội nhiều thì mình thấy nhiều thôi.
 
Hệ thống hành chính của Nhật rất gọn gàng, hiệu quả. Họ không quản lý người dân bằng sổ hộ khẩu, mà theo nơi sinh sống, làm việc của người dân đó, nhưng cực kỳ chặt chẽ. Đến đâu sống chỉ cần ra wardoffice đăng ký hộ tịch ở đó. Thủ tục cũng vô cùng đơn giản và nhanh chóng. Khai 1 form, trình hộ chiếu, chờ khoảng 20 phút là xong, không dấu má chứng nhận lên xuống gì cả. Thế là mọi quyền lợi trách nhiệm của mình sau đó sẽ automatic được người ta quản lý. Ví dụ trợ cấp y tế, trợ cấp nuôi con ... nếu mình không biết, thì họ cũng sẽ gửi thư đến tận nhà nhắc nhở, không phải kiểu con khóc mẹ mới cho bú. Thậm chí, khi mình đến làm thủ tục nhận trợ cấp, họ rất vui cứ như thêm được một khách hàng bán được cái gì chứ không phải là chi tiền cho mình vậy, rồi đưa thêm một đống tờ rơi để mình tìm hiểu thêm các quyền lợi khác, nhắc nhở mình đủ thứ. Nói đến thái độ tiếp dân thì ôi, đúng là dùng từ "đầy tớ của dân" cũng không hề có gì quá đáng. Vô cùng mẫn cán, nhiệt tình. Phục vụ từ 9 giờ sáng đến 5 giờ chiều, không nghỉ trưa. (buổi trưa họ cắt đặt thay nhau làm và ăn trưa vội vàng). Hỏi han cái gì cũng được trả lời tận tình, hỏi bao nhiêu cũng thế, không bao giờ cáu gắt. Mẹ Ổi nhớ lần về VN đi làm chứng minh thư, trời nắng như đổ lửa, đến nơi thấy cái cổng im ỉm. Nhìn cái biển ở ngoài giờ tiếp dân: sáng đến 11 giờ, chiều 2:00 đến 4:00. (trời ơi, nghỉ trưa gì mà những 3 tiếng). Mà lúc mẹ Ổi đến mới có hơn 3 giờ chứ đã đến 4 giờ đâu. Thế là không nộp được. Trước đó còn bao nhiêu công chạy xin dấu đủ loại giấy tờ cũng thành công toi. Cuối cùng cái CMT của mẹ Ổi bây giờ vẫn nằm trong "danh sách những việc phải làm lần về VN sau". Không phải là nói xấu VN, mà thấy sốt ruột cho nước nhà. Vì trong khi ở Nhật công chức chỉ có 950 nghìn/110 triệu dân, còn ở VN là 11,1 triệu công chức/hơn 80 triệu dân (nhiều gấp hơn 10 lần), còn chất lượng dịch vụ hành chính lại ngược nhau đến thế?
Các dịch vụ cộng đồng khác ở Nhật cũng rất là dễ chịu. Không có chuyện bệnh viện đúng tuyến, hay cấp lương nào mới được vào Việt-Xô... Thẻ bảo hiểm áp dụng cho mọi bệnh viện, công và tư, ở bất cứ đâu trên cả nước Nhật. Chất lượng các bệnh viện, phòng khám tư ở nông thôn cũng tốt chả kém, nên người ta không phải đổ xô lên tuyến trên. Ở bệnh viện thì ai đến trước khám trước, ai đến sau khám sau theo số, cứ thế mà chờ. Vì công bằng nên có phải chờ lâu cũng không thấy khó chịu. Y tá thì tận tuỵ dịu dàng đến cảm động. Vừa tiêm vừa luôn mồm xin lỗi, an ủi. Bác sĩ cũng nhẹ nhàng. Trộm vía nếu phải nằm viện thì cũng chỉ khổ vì bệnh chứ bệnh viện bao giờ cũng có điều hoà trung tâm quanh năm 27-28 độ, bước chân qua cửa bệnh viện là chả biết ngoài kia nắng đổ lửa hay tuyết đang rơi nữa. Giường được thay ga thường xuyên, mỗi người đều có tivi, tủ lạnh, và nút bấm gọi y tá ở đầu giường. Gọi bao nhiêu cũng không lo y tá bực mình bao giờ. Cấp cứu thì nếu gọi phải chuẩn bị xong xuôi rồi hãy gọi, kẻo mình vừa dập điện thoại đã thấy ò e ò e rồi. Hihi...khổ nỗi cái này mẹ Ổi phải kinh qua rồi mà. Thống kê trên toàn nước Nhật là trung bình xe cấp cứu sẽ đến bệnh viện trong khoảng 6 phút kể từ lúc được gọi. Choáng không? Phòng khám nhi thì trang trí cho cái gì cũng rất dễ thương, bác sĩ ngọt ngào với trẻ, luôn chuẩn bị sẵn đồ chơi để dỗ trẻ. Trẻ em dưới tuổi đi học miễn phí hoàn toàn cả tiền khám lẫn tiền thuốc, dù khám ở bất cứ đâu. Khám định kỳ miễn phí 6 tháng/lần nếu dưới 2 tuổi, và 1 năm/lần từ 2 tuổi trở lên. Còn Nhà trẻ thì cô giáo nào cũng nhẹ nhàng như cánh hoa, miệng cười mắt cũng cười ... trẻ con đi học đứa nào cũng cảm nhận được tình yêu của cô dành cho mình, và đứa nào cũng rất yêu cô giáo chứ không sợ cô bao giờ.
 
Nói về an ninh ở Nhật. Chỉ có phạm tội lớn chứ không có ăn cắp vặt, cướp giật dọc đường, đánh nhau, ẩu đả cũng không thấy bao giờ, chứ đừng nói đến đánh bom với súng đạn. Nhìn vào thời sự ở Nhật cũng đủ biết là tội phạm ít, vì cả những vụ vớ vẩn như có cái ôtô ở đâu đâm vào cái cột điện ko có người chết chẳng hạn, cũng đưa lên tivi. Những vụ mà như thế mà ở nước khác thì đăng bao nhiêu cho xuể. Tội giết người thường vì những lý do tinh thần hơn là vì tiền, nên có thể là những cách giết người cực kỳ quái gở, ... còn vì tiền thường là phá máy ATM, cướp ngân hàng. Mà rất buồn cười là thủ phạm thường không phải là dân ăn cắp chuyên nghiệp, nên hành sự cực kỳ stupid và toàn bị tóm tại trận...Haha. Còn người dân trong cuộc sống hàng ngày thì nhìn chung không phải lo nghĩ gì, rất yên bình. Nhà của Nhật bao giờ cũng có một mặt hướng ra lan can, sân vườn là cửa kính rất to để hứng ánh sáng, kính sát xuống tận sàn nhà, mà không có chấn song. Mở cửa kính này ra là bước toẹt ra vườn/hành lang luôn. Hàng rào cũng thấp, chủ yếu để ngăn đất và cho đẹp chứ không phải để tránh trộm. Mẹ Ổi nhiều lúc nghĩ, mình mà là dân đạo chích, chắc mình sẽ mơ một nơi thế này để tha hồ hành nghề. Hihi... Ra đường, trên tàu điện, xe búyt, các phương tiện công cộng, thì cứ việc ngủ thoải mái ... Mà đừng nói đến ăn cắp, có khi để phơi ra đấy cũng không bị lấy. Vào nhà hàng túi để ở ghế rồi đi toilet vô tư. Nhiều khi mẹ Ổi đi siêu thị, chọn thực phẩm xong vứt xe hàng ở một góc, mải mê ngắm nghía quần áo chán chê mới tìm đến cái xe hàng để thanh toán thì mới giật mình vì thấy cái túi của mình vẫn vứt trong xe từ bao giờ. Mẹ Ổi với cái tính đãng trí đã không ít lần quên đồ, nhưng chưa bao giờ bị mất cái gì cả. Ấn tượng nhất là lần ngồi chờ ở bến xe buýt, mẹ Ổi để quên cái túi của mình trên ghế chờ. Khi phát hiện ra và quay trở lại tới nơi thì đã cả mấy tiếng sau, chiếc túi vẫn nằm ở đó, màu đỏ rất nổi bật, mà ở một bến chờ xe buýt trước cổng bệnh viện, biết bao người qua lại. Mọi thứ trong túi vẫn còn nguyên, ví tiền, giấy tờ tuỳ thân. Ôi ôi, thật là không tưởng tượng nổi. Đúng là họ đầy đủ về vật chất thì người ta sẽ sống tốt hơn, không nhòm ngó đến của cải của người khác. Nhưng mẹ Ổi cho rằng đó mới là điều kiện cần thôi. Vì thực ra người Nhật cũng rất tiết kiệm. Người ta thậm chí chờ xếp hàng cả mấy chục phút dài dằng dặc chỉ để mua xăng rẻ được vài trăm Yên. Chứ 10,000 Yên (số tiền tối thiểu thường có trong ví các bà nội trợ), thì cũng là khá to với họ. Vậy mà vẫn không bị lấy thì là vì sao. Vì họ có cả điều kiện đủ là nếp sống đẹp, lương tâm thiện ... Ở Nhật đúng là như vậy, "Lễ" là cái đã ngấm vào máu của mỗi người dân. Họ cư xử với nhau không chỉ theo luật, mà còn theo lệ, theo lễ: Không ở đâu mẹ Ổi thấy người ta nói cảm ơn và xin lỗi nhiều như trong tiếng Nhật. Từ cảm ơn và xin lỗi ở trên đầu môi. Đi đường nhỡ va chạm vào nhau thì cả hai bên đều cúi đầu xin lỗi, bất kể ai sai ai đúng. Ổi thường hay nói chuyện với các bà già gặp ở đường. Bao giờ kết thúc câu chuyện cũng là lời cảm ơn của bà cụ, dù già như vậy. Cảm ơn vì đã giành thời gian cho bà được có những phút giây với đứa trẻ đáng yêu như Ổi. Ở trường dạy lái xe, người ta không chỉ dạy luật, mà văn hoá lái xe cũng rất được chú trọng. Chả thế mà ra đường nhiều khi cứ nhường nhau mãi, rồi mẹ Ổi (dù sao vẫn là người VN), thường là người đi trước. Hihi... Người ta rất nhường nhịn nhau. Khi 2 người cùng đến xếp hàng một lúc thì thường lịch sự cúi đầu nhường nhau đứng trước, chứ không có cảnh ai nấy cố gắng nhanh chân để được đứng trước. Người Nhật rất có ý thức giữ gìn kỷ luật chung. Ví dụ đi thang cuốn có luật bất thành văn là ai đứng trên thang để nó tự cuốn đi thì đứng dẹp về bên trái, để một lối bên phải cho những người vội vàng, muốn đi nhanh thì chạy trên thang nữa. Thế là ai nấy đều tuân thủ, chả thấy ai đứng yên mà đứng bên phải cả. Họ có ý thức trách nhiệm với xã hội từ những việc nhỏ như việc đổ rác chẳng hạn. Người ta phân loại rác rất kỹ, để dễ tái chế. Chia cơ bản nhất là rác cháy được và không cháy được. Nhưng trong rác cháy được, thì nhựa, giấy báo, giấy bìa, vỏ hộp sữa tươi,.....rác không cháy được thì hộp sắt, hộp nhôm, thuỷ tinh, đồ độc hại (pin...). Mẹ Ổi thì lười, chỉ phân loại sơ sơ, ví dụ vỏ hộp sữa hay juice bằng giấy, uống hết bóp cho nhỏ lại rồi vứt vào rác cháy được, nhưng mẹ để ý thấy các bà hàng xóm, các bà ấy mở cái vỏ cho phẳng ra, rửa sạch, phơi khô, xếp cả đống vào nhau, các khay đựng thịt cá cũng vậy, loại nào vào loại ấy khay trắng vào khay trắng, đen vào đen, nhựa trong vào với nhựa trong, rồi mới vứt. Hộp bằng kim loại có nắp bằng nhựa thì vứt riêng nắp, riêng hộp (tất nhiên hộp đã được cọ rửa sạch)... họ có được cái gì ở đó đâu, chỉ là vì tuân thủ qui định chung thôi. Mà rác nào được đổ ngày nào thì đúng ngày đó mới mang đổ, không thì cứ giữ ở nhà mình. Hôi thối cũng phải chịu chứ không mang ra bãi rác vứt trước ngày qui định. Mẹ Ổi không biết ở các nước văn minh khác như Mỹ và châu Âu thế nào, chứ dân châu Âu và Mỹ hàng xóm mẹ Ổi ở đây cũng a-ma-tơ chả hơn gì dân VN cả.
Ở Nhật là thế, cái gì cũng có qui định, và ai cũng tuân thủ, nên mọi thứ đều rất qui củ. Nói thêm về sự văn minh trong văn hoá ứng xử: Người Nhật không nói to ở chỗ đông người. Không ăn ngoài đường. Đứng ngồi đi lại ý tứ. Nói năng với nhau lễ phép lịch sự, thái độ nhã nhặn. Hiếm khi cáu kỉnh. Chưa bao giờ mẹ Ổi thấy người ta cãi nhau, ... hình như họ không bao giờ cãi nhau thì phải. ??? Tất nhiên là người phải có yêu có ghét chứ nhỉ?, nhưng thậm chí cả trên phim truyền hình của Nhật cũng không thấy cảnh các mẹ tốc váy lên chửi nhau như người TQ, VN, Hàn Quốc ...bao giờ. Nói chung, người Nhật rất lành tính, sống thiện. Văn hoá ứng xử của họ nếu chưa quen thì sẽ thấy cứng nhắc, có phần khuôn sáo, không thật lòng. Nhưng quen rồi thì sẽ thấy thật là dễ chịu.
 
Sơ sơ là thế, đã giống với xã hội chủ nghĩa chưa nhỉ? Không biết cái xã hội chủ nghĩa mà VN đang theo đuổi, với lại trong tưởng tượng của Cụ Mác với cụ Lê nin thế nào, chứ mẹ Ổi cũng chỉ mong muốn bấy nhiêu thôi.

Nguồn: NgoiLaiBenNhau

6 Tools To Be An Effective Web Developer

Over the last few years Rails has helped Ruby’s popularity explode. One of the biggest reasons for this is the time that Rails can save you. By working within a well defined framework a lot of development decisions are simplified and it is easier to be more organized. Throw in some great tools like ORM, Unit Testing, Mocking, and more and you have a powerhouse of developer efficiency and quality.

There has always been and probably always will be feuds over what is the best platform but what I want to show you is that those arguments are mostly irrelevant. Regardless of what platform you choose to develop on there are most of the same tools available in one form or another. The common components, for me anyway, that help me produce high quality code faster and is easier to maintain are a good IDE, easy to use unit testing and mocking frameworks, an ORM, a MVC framework, and a good JavaScript library.

I am a .Net developer by trade and a PHP developer sometimes by choice. I enjoy both environments for different reasons. I am going to talk about each of these components in a bit of detail and explain why I think they are important and then at the end of the article I will provide a list of each of these components for various languages (.Net, Java, PHP, Python, and Ruby). I have decided to only list free or open source tools because they are easy for someone to try out and we all like to save a few bucks.

The Integrated Development Environment (IDE)

To me this is the prime essential. Sure you can program in Notepad and compile with the command line but it will likely take longer and it will require more discipline to stay organized. With a good IDE you have easy project management (all you files grouped together with tabbed browsing), syntax highlighting, compilation (if applicable), and auto complete.

IDE are continuously getting more and more sophisticated and plugins allow for lots more functionality like svn and git management in the IDE.

For me my favorite IDE is Visual Studio. There are some other great programs out there like NetBeans and Eclipse but for whatever reason I have become partial to Visual Studio.

Unit Testing And Mocking

These two items go hand in hand. No application is complete without proper testing. There are plenty of people on both sides of the fence when it comes to testing. I know, I was a skeptic for a along time. It just felt weird to spend time writing code to test the real code I was going to write. Finally I just decided to give it a try and it has changed the way I program. When you are focusing on how to test your code you just write cleaner code and it’s nice to have a quick way to know if the change you just made broke anything.

Object Relational Mapper

If you have ever used an ORM you know that it can save you a huge amount of time. One of the concerns I had before jumping to an ORM was performance. I wanted to know if using an ORM would make my application slower but I was asking the wrong question. I should have been asking whether or not the small performance hit was worth the huge time savings. The answer to that is a definite YES! Rarely in an application will the ORM be the source of poor performance and if it is it can be refactored to improve or you can use straight SQL if need be.

It all comes down to not worrying about performance issues before you have any. Yes it is important to keep performance in mind but using an ORM shouldn’t be anything to worry about.

MVC Framework

MVC has become very popular thanks in part to Rails and it’s revolution in the way we do Web Development. The key component to it’s popularity is that it separates the different concerns of your application into seperate pieces. This separation allows easier testing, better design, and makes your application more maintainable overall.

JavaScript Library

It seems there is a JavaScript library for just about everything these days. I remember not too long ago there were that many and JavaScript use hadn’t exploded yet. A JavaScript library is important to your productivity. The library shouldn’t compensate for poor JavaScript skills, you need a solid foundation, but should compliment a good understanding of it. The library will take care of browser compatibility issues and low level operations letting you focus on getting the job done.

ASP.Net
IDE: Visual Studio 2008 Express
Unit Testing: NUnit
Mocking: Rhino Mocks
ORM: NHibernate
MVC: ASP.NET MVC
JavaScript: jQuery

Java
IDE: NetBeans
Unit Testing: JUnit
Mocking: EasyMock
ORM: Hibernate
MVC: Struts
JavaScript: jQuery

PHP
IDE: PHPEclipse
Unit Testing: PHPUnit
Mocking: PHPMock
ORM: Propel
MVC: Symfony
JavaScript: jQuery

Python
IDE: PyDev
Unit Testing: PyUnit
Mocking: PythonMock
ORM: SQLObject
MVC: Django
JavaScript: jQuery

Ruby
IDE: RadRails
Unit Testing: Test::Unit
Mocking: Mocha
ORM: Sequel
MVC: Rails
JavaScript: jQuery

Resources: GeekDaily.net

Comparison of Message Passing Frameworks

Here are the message passing packages I have been looking at. Of course they are not identical. To be clear, I'm not suggesting they are indentical or even close to identical. What I am saying is that every one of these packages or subsytems could potentially be used as the basis for a message passing type of high performace distributed application in C#.

1. Open MPI:
It does not work on Windows at this time but support is being "discussed". It seems to be an open specification for message passing protocol but not message queueing.

2. AMQP:
This is specification for an open message queue protocal. It is not exactly a mesage passing.

3. RabbitMQ:
This is an open source package which is an implementation of AMQP. It works on Windows and Linux. But RabbitMQ was having timeout problems if the app wait too long between insertions of messages to the queue, which is a very undesirable behaviour.

4. Apache ActiveMQ:
This is an open source implementation of a message queue system. It runs on Windows and Linux. C# application can use ActiveMQ by calling the REST interface or by calling the NMS (similar to JMS). There were shutdown errors which causes transactions to be undone.

5. Microsoft Message Queue Server - MSMQ:
This is the standard for message queueing on Windows. It does not work on Linux. It is not free. The .Net framework of C# has a lot of built-in support for MSMQ.

6. Apache Hadoop:
This is a software platform that lets one easily write and run applicatons that process vase amout of data. Hadoop is a distributed computing platform written in Java. It incorporates features similar to those of the Google File System and MapReduce.

References:
1. Comparison of languages performance (http://shootout.alioth.debian.org)
2. Enterprise integration patterns (http://www.eaipatterns.com/eaipatterns.html)

Y2K38 Bug

As we all are famailiar with the millenium bug Y2K i.e. the ‘Year 2000 Software Problem’. Y2K was the major problem to the software industry in that year. Because many systems were using last two digits of the year (like 97, 98, 99 etc.) for some date and time related processing, everyone was worried about the time 12:00:00 a.m. on or after 1 January 2000 because at that time, year 2000 and year 1900 would be executed as same.

Now, after that problem, there is another software bug ahead which needs a large attention towards it. The problem is said to be executed on Tuesday, 19th January 2038 and when the time will reach at 03:14:07 a.m. Many systems would fail to work after this time. Time after this moment will be stored automatically as negetive number and these systems will show the time of year 1901 rather than year 2038. Scientists and engineers called it ‘Y2K38 bug’. The systems and the softwares, which store their system time as signed 32 bit integer, would be affected by this problem. Many 32 bit systems, like Unix systems, store and manipulate the time in 32 bit binary format, and for this reason, it is also called as ’Unix Millenium Bug’. These systems use a data type of C language ‘time_t’ to store and display the time units. The ‘time_t’ is an integer data type and it stores the number of seconds since 12:00:00 a.m, January 1, 1970. Thus, on the date 1 Jan 1970 at 12:00:00 a.m. the value of this data type (time_t) was stored as 0. On the same date, at time 12:00:01 a.m. this value was 1. Furthermore, at time 12:01:00 a.m. this value was 60 (i.e. no. of seconds). Similarly, on January 2, 1970 at 12:00:00 a.m. the value stored was 3600. Moving on to its value on 19 January, 2038 as the moment reaches to 03:14:07 a.m. , the value of ’time_t’ will be ‘2147483647′ which was the highest value of 32 bit signed binary number. And just after one second, IT world will face this huge disaster. Value to time_t will start to decrease and the time shown by the systems will be 08:45:52 p.m. Friday December 13th, 1901. The problem will be more evident from the following figure.

Resources: Year 2038 Problem : Unix Millenium Bug

Continuous integration with Hudson

Continuous integration has become common practice for teams focused on ensuring code quality throughout the software development lifecycle. In this article, Nicholas Whitehead introduces Hudson, a popular open source CI server.

Continuous integration (CI) is a set of practices intended to ease and stabilize the process of creating software builds. CI assists development teams with the following challenges:

  • Software build automation: With CI, you can launch the build process of a software artifact at the push of a button, on a predefined schedule, or in response to a specified event. If you want to build a software artifact from source, your build process is not bound to a specific IDE, computer, or person.
  • Continuous automated build verification: A CI system can be configured to constantly execute builds as new or modified source code is checked in. This means that while a team of software developers periodically checks in new or modified code, the CI system continuously verifies that the build is not being broken by the new code. This reduces the need for developers to check with each other on changes to interdependent components.
  • Continuous automated build testing: An extension of build verification, this process ensures that new or modified code does not cause a suite of predefined tests on the built artifacts to fail. In both build verification and testing, failures can trigger notifications to interested parties, indicating that a build or some tests have failed.
  • Post-build procedure automation: The build lifecycle of a software artifact may also require additional tasks that can be automated once build verification and testing are complete, such as generating documentation, packaging the software, and deploying the artifacts to a running environment or to a software repository. In this way artifacts can quickly be made available to users.

To implement a CI server you need, at minimum, an accessible source code repository (and the source code in it), a set of build scripts and procedures, and a suite of tests to execute against the built artifacts. Figure 1 outlines the basic structure of a CI system.

http://www.javaworld.com/javaworld/jw-12-2008/images/CIOverview.jpg

Figure 1. Basic structure of a CI system

The system components come into play in the following sequence:

  1. Developers check new and modified code into the source code repository.
  2. The CI server creates a dedicated workspace for each project. When a new build is requested or scheduled, the source is retrieved from the repository into this workspace, where the build is then executed.
  3. The CI server executes the build process on the newly created or refreshed workspace.
  4. Once the build completes, the CI server can optionally invoke the defined test suite on the new artifacts. If the build fails, registered individuals can be notified by email, instant messaging, or some other method.
  5. If the build is successful, the artifacts are packaged and transmitted to a deployment target (such as an application server) and/or stored as a new versioned artifact in a software repository. This repository can be part of the CI server, or could be an external repository, such as a file server or a software distribution site like Java.net or SourceForge. The source code repository and the artifact repository can be separate, and it is actually possible to use some CI servers without any formal source control system at all.
  6. CI servers usually have some sort of console where projects can be configured and debugged, and where requests can be issued for operations such as ad hoc immediate builds, report generation, or retrieval of built artifacts.

Hudson is a free and open source product hosted at Java.net It was originally written by Kohsuke Kawaguchi, a staff engineer at Sun Microsystems, who announced its release on his blog in February of 2005. Hudson has since had approximately 154 releases.

Here are some of the reasons why I like Hudson, and why I would recommend it to you, barring any unusual requirements:

  • Of all the CI products I've used, it is by far the easiest to install and configure.
  • Its Web-based user interfaces are very friendly, intuitive, and responsive, in many cases providing immediate Ajax-enabled feedback on individual configuration fields.
  • Hudson is Java-based (which is useful if you're a Java developer) but is not limited to building Java-based software.
  • Hudson is cleanly componentized and offers a well-defined and documented extensibility API in the form of Hudson plugins. This has in turn led to a large library of Hudson plugins that extend the functionality of the server; these are freely available and installable from the Hudson console.
Resources:
- Get the latest Hudson WAR file here or here.
- Download apache-tomcat-6.0.18.exe to install Tomcat on your Windows machine. Download JBoss 4.2.3.GA for a Linux environment (look for the file named jboss-4.2.3.GA.zip).
- If your Hudson server cannot connect to outside resources, you can download the plugins you need from the Hudson Website.

Update your Resume!

What you say? You like your job? Have no intention of leaving? Why would I update my resume?

Well, I too enjoy my job and the company I work for. I’m not talking about finding a new job, I’m talking about managing your career. In this day and age, individuals need to take responsibility for career management.

A good time to review your resume is once a year, around review time. I know not all companies do yearly reviews. Maybe the review you get is not as valuable as it could be. Regardless, set up your own time to review your career progress.

From now on, update it so it reflects your current experiences. Take a good look at the what you have done in the past year. How have you progressed over the last couple years?

Next, set up some goals for yourself in the next year. I like to focus on four general areas:

Technology: What technologies should I make improvements on? What new technologies are coming up? How can I better use current technologies?

Processes: Learn about new agile methods? Learn about how others are using the methods and improving them. Learn a process you may be less familiar with like configuration management techniques.

People skills: Don’t forget the soft skills. I’m not necessarily talking management here (unless that is your goal). Leadership can come from anywhere. Unless you are a “one programmer team” you work with others. Whenever you are attempting to influence someone, you are using leadership skills.

Business: We don’t work in a vacuum. What business is my company in? What areas of that business can I get a greater understanding?

Once you have a list of general topics you want to focus on, make then concrete. Pick enough that pushes you to grow in the next year, but not more then you can effectively commit to.

Next, make each goal measurable. Write down something that you can do in the next year. Write the goal such that it is obvious when you done.

Put a date with the goal. If the goal has multiple parts, put dates to the sub goals as well. For example:

Technology goal: Attain a greater understanding in .NET framework.

  • Read the book by
  • Choose an application in which to use your new skills by
  • etc…

People skills goal: Improve communication skills.

  • Choose a topic you can present on by
  • Prepare a presentation by
  • Learn foreign languages: Japanese ...
  • Present to your peers at a lunch-n-learn by
  • etc..

Next year, you can review the goals you accomplished and add them to your resume.

These goals don’t all have to be specific to the company you work for. It makes sense that they are so you can improve your career opportunities there. However, add some personal goals as well. I might want to learn a new language like Groovy or Python even though my company is a primarily a Microsoft shop or learn the.NET framework if your company is a Java shop.

You have to take charge of your career. Your company may or may not take an active role in this. Like many things in life, if you don’t manage it, it will most certainly manage you.

What It Takes To Be A Great Technical Lead

Most teams have some kind of technical lead in place. They’re often referred to as the ‘dev lead’, or the ‘lead developer’ or the ‘lead programmer’ or whatever. Some people are great fits for this role, and some simply aren’t. Below is my list of what i think makes for a great technical lead. Note: i’m not claiming that i live up to all of this, although i do try to.

  • You obviously need strong technical skills. You are responsible for the final result, so you better make sure that there is a solid technical foundation for the team to build upon. This doesn’t mean that you should build this foundation entirely yourself. Preferably, you involve your teammates into this as much as possible. You’re also responsible for fixing technical issues that your teammates can’t solve. You either fix it, or when that’s not possible you should figure out an acceptable workaround. Be sure that your teammates are fully aware of the details of the solution or the workaround.

  • You have to be able to teach your teammates. As a technical lead it is your duty to improve the skills of your teammates. No matter how good you may be, if you can’t transfer that knowledge and those skills, you’re not doing a good job as a technical lead. If there are some core principles or practices that you want them to apply to their work, you need to make sure that each and every one of them really ‘gets’ it. You need to be willing to invest the time and effort it takes to achieve that.

  • You need to trust your teammates. This isn’t always easy, especially when it’s about someone who hasn’t progressed as far or as fast as you would’ve liked him to. But it is definitely necessary. If a teammate realizes that you trust him, he will usually respond with improved output. It might not always be everything you hoped for… but either his effort, or the quality of the work will improve. Keep trusting the teammate, and eventually both will improve. Which actually happens a lot sooner than most people would think.

  • Stimulate self-organization. I know a lot of people don’t believe in self organizing teams. And to an extent, that disbelief is somewhat valid. There always has to be one or a couple of people who have some kind of leadership role (be it officially or not). Those leadership roles do not prevent self organizing teams though, in fact, i’d say they enable them. Do not simply assign tasks to your teammates all the time. Organize planning meetings where members can choose the tasks they will do. Make sure there is always some kind of balance though. You really need to prevent that person A always gets the shitty tasks or that person B always get the funnest tasks. Mix it around it a little and try to make sure that the fun/shit ratio is never out of whack.

  • Don’t keep the coolest technical tasks for yourself. If the project requires some kind of technical research to use a new library or to figure out an approach to a new problem or whatever, make sure all of the teammates get the chance to do these kind of things once in a while. It’s not always possible to do so, but when you can, it really pays off. Morale goes up, trust goes up in both directions, and everybody improves.

  • Try to prevent overtime as much as possible. If you’ve been given an impossible deadline, try to convince management that it’s simply not doable. Fight for it if you must. But realistically speaking, you can’t extend every deadline they throw at you, and sooner or later you’re gonna be in a situation where you and your teammates are going to have to put in some overtime to get everything done on time. Don’t tell your teammates they have to do it. Ask them if they want to do it. For some people, this doesn’t always make a difference but for others, it makes a huge difference. And this one is very important when you’re doing overtime: do not go home early while your teammates are still working, because it will come back to bite you in the ass eventually.

  • Remember that you are responsible for the final result. If something goes wrong, it really is your fault. Never put the blame on one of your teammates. Not within the team, and definitely not when managers are present. If a teammate screwed up and the problem made it into the production version, then that is your responsibility and your fault.

  • Give credit where credit is due. If a teammate did a great job with something, give them that credit and make sure everyone else knows about it too, especially management. Never take credit for the work of a teammate because that is simply one of the lowest possible things you could do.

  • Finally, you need to realize that your teammates are not your developers. I’ve often heard technical leads say things like “yeah, my developers…” or “my guys … “. No. They are your teammates, no matter what your role in the team is. Having a leadership role does not mean you are the boss of your teammates or that you can boss them around. If anything, it destroys morale and the results of your team will suffer tremendously from it.

Resources: Davy Brion