Seri's blog

Một số thủ thuật với Facebook

2011-04-29T16:14:00.008+07:00

Thi thoảng tôi sẽ viết thêm vào bài viết này để cập nhật các thủ thuật mới.

Tự động dùng proxy chỉ với Facebook

Mỗi người có một câu trả lời khác nhau trước bài toán Facebook bị chặn. Cá nhân tôi dùng proxy, cụ thể là Ultrasurf trên Windows và Tor trên Linux, đơn giản vì giải pháp này hầu như luôn hoạt động. Vấn đề bây giờ là lướt web qua proxy thì rõ ràng phải chậm, nên thông thường mình sẽ bật proxy khi dùng Facebook, rồi lại tắt proxy đi để truy cập các trang khác được nhanh hơn.

Cách khắc phục tình trạng này là ép browser tự động dùng proxy chỉ riêng với domain facebook.com.

Xem file PAC (proxy auto-config) ở đây với Ultrasurf và ở đây với Tor.
Download và save vào path/to/pac/file.
Với Firefox: vào Options/Advanced/Network/Settings, chọn "Automatic proxy configuration URL", ở textbox gõ file:///path/to/pac/file. Kết thúc ở đây.
Với IE/Chrome: vào Tools/Internet Options/Connections/LAN Settings, chọn "Use automatic configuration script", ở textbox Address gõ file:///path/to/pac/file.

Với cách làm này, bạn nên cho phép Ultrasurf/Tor khởi động cùng Windows/Linux.

Tùy biến CSS cho Facebook

Facebook dùng fixed-width layout (961px - một độ rộng được xem là chuẩn). Nó hiển thị khá tốt trên đa số laptop phổ biến nhưng trên màn hình hơi rộng một chút thì coi bộ hơi hẹp. Hơn nữa, font-size của Facebook là 11px, khiến cho tôi hay phải zoom out. Trước thực trạng này, một lần nữa ta hãy tùy biến Facebook.

Install plugin Stylish ở đây với Firefox và ở đây với Chrome. Cho phép browser khởi động lại nếu nó đòi.
Truy cập facebook.com, ta thấy ở góc màn hình có biểu tượng chữ S của Stylish, ấn vào đó để thấy context menu, chọn Write new style/For facebook.com. Dialog "New style" xuất hiện.
Gõ Facebook ở textbox Name. Paste y nguyên đoạn code ở đây vào textbox to nhất. Ấn Save.

Luật CSS trên sẽ đồng thời che đi phần quảng cáo của Facebook. Nếu bạn có nhu cầu xem quảng cáo, hãy xóa đoạn rule cho .ego_column .phs.

Chặn Facebook trong lúc cần tập trung

Cái này chắc nhiều người biết rồi. Leechblock cho Firefox và Chrome Nanny cho Chrome sẽ giúp chặn các trang gây nghiện kiểu như Facebook trong những khoảng thời gian ta quy định trước.

Vô hiệu hóa Facebook Photo Theater

Tính năng xem photo mới của Facebook, tên gọi Theater, có lẽ được thiết kế để về lâu về dài sẽ cho phép hiển thị ảnh với kích cỡ không bị giới hạn. Tuy nhiên giao diện hiện tại của Theater thật khiến người ta phải khó chịu.

Với Chrome: Ấn nút Install ở link này thế là xong.
Với Firefox: Trước hết cài Greasemonkey rồi install script trên.

Xem số lần một URL được chia sẻ trên Facebook

Rất đơn giản, bạn chỉ cần truy cập vào địa chỉ "http://graph.facebook.com/$url". Ví dụ, để xem số lần bài viết này được chia sẻ trên Facebook, hãy truy cập: http://graph.facebook.com/http://seritrinh.blogspot.com/2011/04/mot-so-thu-thuat-voi-facebook.html.

Cấy Inception trên thực tế

2011-04-21T09:41:00.001+07:00

Trong bộ phim Inception mới công chiếu, doanh nhân Saito thuê nhóm chuyên gia giấc mơ do Cobb cầm đầu để cấy một ý tưởng lên Fischer sao cho anh này tự lật đổ tập đoàn mà người cha quá cố của mình dày công xây dựng. Chuyên môn của Cobb và đồng nghiệp không phải là cấy ý tưởng. Họ chỉ quen với việc đưa đối tượng vào giấc mơ của một thành viên trong nhóm rồi ăn cắp thông tin ở đó. Cấy ý tưởng thường được xem là một nhiệm vụ bất khả thi ngay cả đối với các chuyên gia giấc mơ như Cobb.

Tại sao cấy ý tưởng lại khó đến thế? Trước hết ta hãy mô tả nghiệp vụ mà nhóm Cobb rất thông thạo: ăn cắp thông tin từ giấc mơ. Công nghệ bấy giờ đã cho phép con người nhảy vào giấc mơ của nhau thông qua cái gọi là "máy giấc mơ". Phim không đề cập, nhưng ta có thể hình dung mục đích của tiến bộ công nghệ này là để phục vụ các nhà tâm lý học hiểu hơn về khách hàng. Tuy nhiên cái gì cũng có mặt trái của nó. Một loạt những kẻ chuyên đánh cắp thông tin từ giấc mơ xuất hiện. Họ thường sở hữu cả kỹ năng tâm lý học và kỹ năng kiến trúc (nhằm thiết kế không gian trong giấc mơ tùy theo mục đích sử dụng). Thiết bị bạn sử dụng để suy nghĩ trong mơ có tên là "tiềm thức". Nó làm việc nhanh hơn ý thức rất nhiều nhưng bạn gần như không điều khiển được nó nếu không trải qua khổ luyện. Kết quả là trong mơ, bạn thường rất mất cảnh giác và bị chi phối bởi chuyên gia giấc mơ.

Thông thường, chuyên gia giấc mơ chỉ có ý định hỏi han bạn một vài bí mật kinh doanh nào đó. Sau khi tỉnh giấc, khả năng cao là bạn không nhớ mình đã tiết lộ những gì. Người ta phải khổ luyện để có kỹ năng nhớ được tất cả những gì mình vừa mơ sau khi tỉnh, và nhớ được tất cả những gì suy nghĩ lúc tỉnh trong khi đang mơ. Và thế là bí mật kinh doanh rơi vào tay chuyên gia mà bạn không hay biết. Chuyên gia này thường làm việc cho đối thủ cạnh tranh của bạn trên thương trường theo hợp đồng.

Lần này, Saito không định thuê chuyên gia để ăn cắp bí mật kinh doanh như thường lệ. Ông ta thuê nhóm Cobb làm một công việc phức tạp, táo bạo, phi pháp hơn nhiều: gieo vào đầu đối thủ cạnh tranh đang lớn mạnh Fischer một ý tưởng "hãy tự lật đổ tập đoàn của mình đi". Gieo Inception khó ở chỗ, ta thường quên ngay nội dung giấc mơ khi tỉnh. Inception phải có sức thuyết phục, sức ám ảnh thì mới để lại ấn tượng cho nạn nhân khi ý thức của họ quay trở lại. Nói như Eames - người muôn mặt, thành viên tôi ưa thích nhất trong nhóm Cobb - gieo Inception là một nghệ thuật tinh tế.

Tại sao nhất thiết phải cấy Inception vào tiềm thức của nạn nhân? Tại sao Saito không thuê chuyên gia tâm lý tiếp cận Fischer ngoài đời để làm một việc tương tự? Thực ra cấy Inception đã được người ta áp dụng ngoài đời từ nhiều năm trước. Phương pháp của Câu Tiễn khi xưa chính là dùng chuyên gia tâm lý dưới dạng một cô gái xinh đẹp mang tên Tây Thi để cấy vào đầu Phù Sai một Inception: Tây Thi còn quan trọng hơn cả giang sơn.

Inception này khả thi vì thời đó vua chúa không được định hình vững chắc về nhân sinh quan. Trái lại, các doanh nhân thành đạt của thời đại này đều là những người rất thông minh, được giáo dục rất kỹ về ý thức, thậm chí được trao quyền tự do nhất định. Lay chuyển ý thức của Fischer là chuyện gần như không tưởng. Gái đẹp? Hãy quan sát phản ứng của Fischer trong quán bar trước một cô gái không thể đẹp hơn do Eames giả dạng. Ngay cả trong tiềm thức Fischer cũng không có hứng thú.

Như vậy cấy Inception rất khó chính bởi lẽ hệ ý thức của người hiện đại nói chung, đặc biệt là giới doanh nhân thành đạt nói riêng, cực ký kiên cố. Một khi đã qua tuổi trưởng thành, chúng ta ít khi nào chịu thay đổi ý thức. Hệ ý thức của chúng ta không có chỗ cho ý tưởng mới. Các ý tưởng cũ thì quá chắc chắn để dịch chuyển.

Quả thật hình thức cấy Inception ta thấy nhiều nhất trên thực tế chính là khi còn nhỏ. Cha mẹ, thầy cô, người lớn tuổi, bạn cùng trang lứa liên tục gieo Inception vào ý thức của ta khi nó còn thênh thang đón nhận. Có một nhóm người hiểu rõ điều này và khai thác nó triệt để: bộ máy chính quyền. Bộ máy chính quyền luôn muốn chi phối hệ tư tưởng của thế hệ sau, nhất là về, ừm, chính trị. Điều này có lẽ không cần giải thích nhiều.

Một nhóm người khác luôn phải nghĩ nát óc để làm một việc khó hơn nhiều: cấy Inception vào người trưởng thành. Đó là giới marketing. Chuyên gia marketing đầu tiên phải biết nhiệm vụ chung chung của tập đoàn thuê mình, sau đó chuyển hóa nó thành một Inception khả thi - tức là, có sức thuyết phục, có sức ám ảnh - rồi cấy vào đầu càng nhiều người càng tốt. Như đã nói ở trên, điều này rất khó.

Bạn biết không, có một Inception mà cả bên chính trị (nhất là ở các nước tư bản) và bên kinh doanh luôn muốn gieo vào đầu toàn xã hội, qua đó xây dựng chủ nghĩa tiêu dùng. Nó là giao điểm giữa nhóm mục đich của hai bên. Inception này là: bạn chi tiêu càng nhiều, địa vị xã hội của bạn càng cao và bạn càng hạnh phúc. Họ gieo Inception này một cách khéo léo, từ khi ta còn nhỏ, hết thế hệ này đến thế hệ khác. Ngày nay, chúng ta chỉ cảm thấy thua kém bạn bè vì không sở hữu iPad, không dùng dòng di động mới nhất, không đi xe xịn ... mà không ai biết tại sao. Thậm chí không ai thắc mắc tại sao. Chúng ta đã coi đó là điều hiển nhiên.

Facebook và Google trên cuộc chiến mạng xã hội

2010-12-05T18:44:00.021+07:00

Theo TechCrunch, Sergey Brin sẽ trực tiếp chỉ đạo nhóm phát triển mạng xã hội đương đầu với Facebook. Trọng vụ đàm phán không thành với Groupon, Google thể hiện rõ quyết tâm bám đuổi Facebook Deals, FourSquare trên thị trường quảng cáo nội địa khi sẵn sàng trả giá đến tận 6 tỉ đô-la. Cũng chỉ mới đây thôi người ta chứng kiến vụ cãi nhau như hai đứa trẻ con giữa Facebook và Google về vấn đề chia sẻ danh bạ các mối quan hệ. Ở mặt trận nhân lực, áp lực chảy máu chất xám đã ép Eric Schmidt phải muối mặt bỏ ra 3.5 triệu đô-la cho việc giữ chân một nhân viên chủ chốt trước sức cám dỗ của Mark Zuckerberg, đồng thời đưa ra tuyên bố tăng lương 10% cho mọi vị trí trong công ty. Có thể thấy cuộc đối đầu giữa hai đại gia dẫn đầu lưu lượng sử dụng Internet đang diễn ra vô cùng căng thẳng và hấp dẫn.

Google nhảy vào cuộc chơi không phải chỉ vì tham lam

Tại sao Google cứ cố chấp không chịu từ bỏ mạng xã hội? Nó đến quá muộn khi cánh cửa thị trường đã gần như hoàn toàn khép lại, không còn chỗ cho nó nữa. Sao nó không tập trung tài nguyên vào chiến lược cốt lõi là tìm kiếm, tổ chức dữ liệu?

Nguyên nhân là vì đối với Google mà nói, Facebook chẳng khác nào hình ảnh của chính nó trước Microsoft cách đây 10 năm. Khi ấy, chính niềm tin mù quáng vào sức bành trướng không giới hạn của thị trường ứng dụng desktop đã khiến gã khổng lồ phần mềm bàng quan với thị trường online trong suốt một thời gian dài. Microsoft có nhen nhúm chen chân vào online nhưng tất cả chỉ dừng lại ở những nỗ lực nửa vời không hơn không kém. Các chiêu bài nực cười của Yahoo càng giúp Bill Gates yên tâm hơn về tầm nhìn của mình. “Online chỉ là xu thế nhất thời đang được truyền thông thổi bong bóng mà thôi. Ứng dụng online quá hạn chế về tài nguyên và sẽ không bao giờ cạnh tranh nổi với desktop. Vả lại, làm dịch vụ online dù tốt đến đâu cũng khó có thể sinh lời.” Gates tự nhủ. Kết quả như chúng ta thấy, giá trị vốn hoá thị trường của Microsoft hiện giờ là 233 tỉ đô-la, so với con số gần 400 tỉ đô-la vào mùa hè năm 2001.

Để tôi kể lại bi kịch nói trên một lần nữa cho các bạn dễ hình dung. Năm 2010, bất chấp đà tăng trưởng như vũ bão của mạng xã hội nói chung, Facebook nói riêng, Google vẫn tin tưởng tuyệt đối vào máy tìm kiếm như phương tiện tối cao để đưa người sử dụng đến với World Wide Web. Một số dự án làm mạng xã hội của Google như Buzz hay Orkut chỉ gọi là cho có. Nó để dành các cá nhân xuất sắc nhất cho những chiến lược mà nó đánh giá là quan trọng hơn. Sự sa sút đến hài hước của MySpace và thái độ quay ngoắt 180 độ của người sử dụng càng củng cố niềm tin mà hai nhà sáng lập dành cho máy tìm kiếm. “Mạng xã hội chỉ là xu thế nhất thời đang được truyền thông thổi phồng lên ấy mà. Chúng sẽ liên tiếp thay thế nhau theo thói đồng bóng của giới trẻ, tựa như các trào lưu của ngành giải trí vậy. Vả lại, làm mạng xã hội dù tốt đến đâu cũng khó có thể sinh lời. Nếu anh đặt quảng cáo dựa trên các thông tin nhạy cảm mà người sử dụng cung cấp cho anh hoặc bán lại thông tin này cho doanh nghiệp thì cả người dùng lẫn nhà chức trách đều sẽ lên tiếng phản đối. À mà đừng bao giờ nghĩ đến chuyện bắt người sử dụng trả tiền cho dịch vụ mạng xã hội nhé!” Larry Page và Sergey Brin tự nhủ. Kết quả là đầu năm 2020, giá trị vốn hoá thị trường của Google sụt giảm xuống còn 90 tỉ đô-la, so với con số 183 tỉ đô-la vào mùa đông năm 2010.

Xung đột quyền lợi giữa Facebook và Google thậm chí còn mật thiết hơn thế nhiều. Trong tầm nhìn chiến lược của mình, Mark Zuckerberg đánh cược vào một pha dịch chuyển thói quen khổng lồ, ở đó người ta chỉ quan tâm đến những thông tin được khởi tạo, chia sẻ bởi nhóm người được kết nối với mình mà thôi. Tương tự như khi xưa Page và Brin tin tưởng rằng ứng dụng online sẽ thay thế phần lớn ứng dụng desktop, thì nay đối với Zuck, anh hình dung ra một ngày mạng xã hội sẽ đáp ứng hầu hết mọi nhu cầu truy cập thông tin vốn là sở trường của máy tìm kiếm.

Nếu tất cả nghe có vẻ quá to tát, ta hãy bàn đến một chuyện không thể tủn mủn hơn – cơm áo gạo tiền. Hiện cặp bài trùng Adwords/Adsense vẫn là cỗ máy in tiền chủ lực của Google. Adwords biết người tiêu dùng chuẩn bị mua gì và đặt quảng cáo dựa trên cơ sở đó. Adsense giới thiệu một mặt hàng có liên quan đến nội dung chúng ta đang quan tâm để kích thích nhu cầu mua. Tuy nhiên cả Adword lẫn Adsense đều chưa tác động đến nhân tố xã hội trong việc ra quyết định mua. Chúng ta có xu hướng muốn mua các loại hàng hóa, dịch vụ mà bạn bè đang sở hữu. Chúng ta bị chi phối bởi lời nhận xét của người quen trước khi ra quyết định mua. Đó là những biểu hiện mang tính bản năng của loài người. Ngân sách marketing của mỗi doanh nghiệp chỉ có hạn. Nếu dự định bỏ ra nhiều hơn cho truyền thông xã hội, doanh nghiệp buộc phải cắt giảm chi tiêu cho quảng cáo tìm kiếm.

Facebook đang đe dọa hoạt động kinh doanh của Google ngay tại thời điểm này. Trong tương lai, mâu thuẫn giữa chúng hứa hẹn sẽ ngày một sâu sắc hơn.

Đầu hàng không được mà đánh cũng chẳng xong

Google có nhiều lý do để chơi đến cùng trong cuộc đua mạng xã hội. Nhưng gã khổng lồ tìm kiếm tỏ ra nhỏ bé làm sao trong không ít các nỗ lực làm mạng xã hội từ trước đến giờ. Dường như cách tiếp cận của nó có gì đó không ổn.

Tôi nghĩ ở đây cá tính của hai nhà sáng lập đóng một vai trò quan trọng. Từ khi còn học đại học, Larry Page luôn ám ảnh với sự tiện ích. Quả thật mọi sản phẩm Google tung ra đều hướng đến tính tiện ích, đến mục tiêu tiết kiệm thời gian, gia tăng hiệu suất làm việc cho người dùng. Trong khi đó, giải trí, tiêu tốn thời gian, gây sao nhãng, gây nghiện gần như thuộc về bản chất của mạng xã hội – bên cạnh lợi ích kết nối và chia sẻ.

Nếu biết trước hôm nay Facebook sở hữu tới hơn 500 triệu thành viên, chắc chắn khi xưa mạng xã hội đã lọt vào trong top 3 các mối quan tâm hàng đầu của ban quản lý tối cao tại Google. Page và Brin không chờ đợi tương lai này căn bản vì họ không muốn thế. Nhưng điều gì phải đến cũng đã đến. Giờ đây Google phải làm sao để kiếm cho mình một miếng bánh trên thị trường mạng xã hội, một thị trường “khó ưa” nhưng mang tính chiến lược cho hoạt động kinh doanh của nó?

Trong slide “Mạng xã hội thực tế” của nhà nghiên cứu kinh nghiệm người dùng cho các sản phẩm xã hội tại Google, Paul Adams, ông này chỉ ra một số mâu thuẫn then chốt giữa mô hình mạng xã hội Facebook hiện đang vận hành và mô hình mạng xã hội thực tế. Chẳng hạn, mỗi cá thể thuộc mạng xã hội thực tế thường kết nối với một vài nhóm người khác nhau và khi tương tác với từng nhóm kiểu này, cá thể ấy lại mang một bộ mặt, hình ảnh tương đối khác. Trong khi đó, mỗi thành viên trên Facebook chỉ có quyền thể hiện một identity duy nhất xuyên suốt toàn bộ các kết nối, bao gồm từ gia đình, bạn thân, bạn cùng lớp, đến bạn xã hội, bạn đồng nghiệp, bạn cùng sở thích, và thậm chí cả ... girls xinh nữa.

Sau khi Adams công bố bản slide kể trên, Facebook lập tức bế quan tỏa cảng mùa hè năm 2010 để rồi tung ra Facebook Groups. Tuy nhiên Facebook Groups chưa thể gọi là giải pháp sâu sắc cho sự mâu thuẫn mà Adams đề cập. Ý tưởng của Adams rất hay nhưng không dễ để cụ thể hóa.

Câu “một nước không thể có hai vua” tỏ ra rất phù hợp để nói về mạng xã hội. Có lẽ Google chỉ muốn hất cẳng Facebook ra khỏi chiếc ghế độc quyền thôi, nhưng trớ chêu thay, bản chất của thị trường mạng xã hội là kêu gọi độc quyền. Bên cạnh đó, giải pháp tận dụng khe hở thị trường rồi tạo ra một mạng xã hội chuyên biệt kiểu như LinkedIn lại có vẻ quá khiêm tốn đối với một đại gia như Google.

Trong mọi trường hợp, thách thức lớn nhất đặt ra cho Google nằm ở lực ma sát cực lớn của dịch vụ mạng xã hội. Là người Việt Nam, chúng ta hẳn còn nhớ người dùng Yahoo! 360 trung thành đến thế nào. Họ bất chấp mọi nhược điểm của dịch vụ. Lực ma sát cho mỗi thành viên là tổng hợp các kết nối sẵn có cộng với tất cả các thông tin thành viên đó chia sẻ trong thời gian sử dụng dịch vụ.

Rõ ràng chỉ với chức năng ưu việt hơn thôi chưa đủ để bất kỳ ai đánh bật được Facebook. Khả năng cao là anh chưa kịp thu thập thành viên thì Facebook đã clone xong chức năng của anh rồi. Google cần một chiến lược ra mắt rồi lan tỏa sáng tạo và thông minh, chứ đừng bạc nhược như những gì nó đã thể hiện với Wave. Nên chăng Google bắt đầu với sơ đồ xã hội sẵn có tại Gmail và Youtube. Hoặc giả nó hãy nhanh chân nhảy vào một platform nơi lực ma sát còn thấp, như smartphone chẳng hạn.

Biết đâu Facebook sẽ không đánh mà tự thua?

Người ta đã nói quá nhiều về khả năng sinh lời của mạng xã hội nói chung, Facebook nói riêng. Cá nhân tôi nghĩ, về lâu về dài, phong cách quản lý nội bộ mới chính là yếu tố then chốt quyết định Facebook có giữ được ngai vàng trên vương quốc mạng xã hội hay không.

Mark Zuckerberg là một thiên tài. Ta không phủ nhận điều đó. Nhưng đồng thời anh cũng là một kẻ bất chấp thủ đoạn. Tháng 9 năm 2004, ba nhà sáng lập tại ConnectU kiện Zuck bỏ qua sự thống nhất không có văn bản trước đó giữa bốn người bọn họ với nhau. Theo ConnectU, Zuck đã ăn cắp ý tưởng, sử dụng mã nguồn của cả nhóm trong quá trình xây dựng một mạng xã hội cho riêng mình. Bản thân cái tên TheFacebook cùng một số ý tưởng ban đầu, Zuck cũng lấy từ Aaron Greenspan, bạn học của anh tại Harvard, nguyên Think Computer CEO. Chẳng thế mà nếu tình cờ ta bắt gặp một bài viết về Facebook trên Hacker News, khả năng cao là Greenspan sẽ xuất hiện với tài khoản thinkcomp và đưa ra một số lời lẽ cay nghiệt.

Không chỉ hung hãn, cơ hội, chàng Mark Zuckerberg trẻ tuổi đôi khi còn cư xử rất trẻ con. Anh nhiều lần bị dư luận chỉ trích vì công khai coi thường thông tin cá nhân của người sử dụng. Mới đây, Facebook vô duyên vô cớ block tài khoản của Lamebook chỉ vì trang mạng này mang một cái tên có phần động chạm. Mùa hè năm 2007, với việc lôi kéo thành công vị giám đốc tài chính của Google, ông Gideon Yu, Zuck không giấu nổi sự phấn khích trước tờ Wall Street Journal: “Thật là một điều kỳ diệu khi Yu chịu làm việc cho chúng tôi.” Ấy thế mà sau khi Yu ra đi đầu năm 2009, anh ta lại trở mặt nói rằng cái Facebook cần là một CFO với “kinh nghiệm làm việc trong công ty cổ phần công khai” kia!

Tính cách của Zuck sẽ ảnh hưởng thế nào đến văn hoá làm việc tại Facebook? Hiện Facebook đang thu hút được rất nhiều nhân tài nhờ sức hấp dẫn của cổ phiếu trước IPO cũng như khát vọng thay đổi thế giới. Tới khi Facebook ra mắt công chúng rồi, chính thức … thay đổi thế giới rồi, liệu nó còn giữ được trạng thái sôi nổi, hưng phấn như hiện nay không? Facebook có còn “move fast, break stuff” như Zuck mong muốn nữa không? Các chuyên gia về quản lý có nhiều bất đồng trong quan điểm, nhưng họ đều thống nhất rằng tiền bạc không phải là động cơ thúc đẩy tinh thần làm việc hiệu quả nhất. Mỗi doanh nghiệp đều cần một thứ tương tự như khẩu hiệu “Don’t Be Evil” của Google.

Cho đến thời điểm này, đa số chức năng trên Facebook có nguồn gốc từ sao chép hơn là sáng tạo nguyên bản. Tôi còn một lý do nữa để nghi ngờ nồng độ cách tân của Facebook. Paul Buchheit gia nhập Facebook tháng 8 năm 2009. Tháng 11 năm 2010, ông rời Facebook để đến với Y Combinator, một công ty chuyên đầu tư vào startup ở giai đoạn mới sơ khai. Phải chăng môi trường làm việc ở Facebook không đủ tính khởi nghiệp như vị cha đẻ của Gmail, nhà đồng sáng lập ra FriendFeed vẫn hằng mong đợi?

Google hay ở chỗ nó ít nhiều giữ được sự tươi mới ngay cả khi đã bành trướng đến con số hơn 20 nghìn nhân viên. Người ta thường chê trách Google quá phân tán sự tập trung nhưng theo tôi, đây mới chính là thế mạnh của gã khổng lồ tìm kiếm. Nó đảm bảo Google sẽ luôn sản sinh ra những dự án mới, thu hút nhân tài từ một diện rộng sở thích, sở trường khác nhau, tránh được sự nhàm chán, giải tỏa được sức ỳ. Lẽ dĩ nhiên, cái gì cũng có giá của nó. Cứ chốc chốc Google sẽ lại gặp phải một đối thủ nặng ký, hung hãn, tập trung vào một thị trường cụ thể như Facebook.

Dù thế nào đi nữa, cuộc chiến mạng xã hội là cơ hội để tôi và các bạn thỏa mãn trí tò mò. Chúng ta hãy cùng chờ xem thành quả của những bộ óc thông minh hàng đầu thế giới.

Đặt tên và ký tự gạch dưới

2010-12-02T16:34:00.006+07:00

Thực ra chúng ta không có quá nhiều lựa chọn trong việc đặt tên, nhất là khi cần viết thư viện cho người khác sử dụng. Ở đâu quen đó. Bạn dùng ngôn ngữ nào thì nên tuân theo chuẩn được quy định của ngôn ngữ đó để người sử dụng có cảm giác xuyên suốt và thống nhất. Dưới đây là tóm lược quy ước của các ngôn ngữ thông dụng:

Java, Haskell: PascalCaseClass.camelCaseMethod()
C#: PascalCaseClass.PascalCaseMethod()
C++: underscore_separated_class::underscore_separated_method()
Ruby, Python: PascalCaseClass::underscore_separated_method()
Lisp: lisp-loves-hyphens

Mới đầu tôi khá hài lòng với quy ước viết hoa so le của Java. Nhưng càng về sau tôi càng cảm thấy thích sử dụng ký tự gạch ngang hoặc gạch dưới hơn, ít nhất là với tư cách người đọc code. Vì lý do nào đó tôi cảm thấy khó chịu khi đọc code có quá nhiều chữ cái viết hoa. Dù sao đây cũng chỉ là sở thích cá nhân nhưng tôi biết mình không phải là người duy nhất có cảm giác này.

Vấn đề bây giờ là ký tự gạch dưới tuy dễ đọc nhưng lại khó viết. Nó đem lại cho ngón tay út của bàn tay trái một cơn ác mộng khi cứ phải với ra nhấn/nhả Shift quá nhiều lần.

Từ đây tôi nghĩ ra một giải pháp đơn giản: ta sẽ bắt editor phải cho ra ký tự gạch dưới khi gõ ký tự gạch ngang trong các bối cảnh phù hợp. Một thuật toán tôi hiện sử dụng và khá thỏa mãn: nếu ký tự ngay trước đó là chữ cái hoặc chữ số thì mình biến gạch ngang thành gạch dưới và ngược lại.

Điều này rõ ràng không khó đối với đa số editor và IDE thông dụng. Ở đây tôi chia sẻ plugin tôi viết sẵn cho 2 editor ưa thích của mình: Vim và Sublime Text.

Cập nhật: Sửa lại imap thành inoremap, sử dụng <expr> (thanks to anh Hoàng) và hỗ trợ tự động bật/tắt theo ngôn ngữ cho Vim plugin

Không gian làm việc cho lập trình viên

2010-01-29T21:51:00.005+07:00

Ở bài trước, tôi liên tục sử dụng khái niệm "trạng thái tập trung" như trọng tâm để qua đó chỉ ra những sai lầm trong việc quản lý thời gian ở các công ty công nghệ. Đây là một khái niệm đã được công nhận trong ngành tâm lý học dưới cái tên the flow state và có lẽ "trạng thái làm việc hưng phấn" sẽ là một cách dịch sát nghĩa hơn.

Bài viết Một thế giới khác mô tả góc nhìn có phần lãng mạn hoá của trạng thái làm việc hưng phấn. Nếu có dịp tôi sẽ đề cập một cách khoa học các vấn đề như cảm giác thế nào và làm sao để đạt được trạng thái làm việc hưng phấn. Nhưng ở đây, chúng ta sẽ chỉ đứng từ phía nhà quản lý cố gắng tận dụng khái niệm này nhằm khai thác nguồn lực trí óc mà LTV mang lại.

Không gian

Không gian là một bài toán về đầu tư. Ngoài lương, bạn còn trả cho LTV không gian để họ làm việc. Đôi khi gia tăng vốn đầu tư vào không gian sẽ đem lại lợi tức cao hơn. Không gian bao gồm từ máy móc thiết bị đến bàn ghế, trang trí nội thất. Việc thiết kế không gian cho LTV phải đảm bảo dễ tập trung, kích thích sáng tạo, và thân thiện cho sức khoẻ.

Thoáng, yên tĩnh, thoải mái

Một số công ty kê bàn ghế sát nhau thành hàng. Cách bài trí này rất tiện cho việc ... bắn Half Life, vừa tiết kiệm không gian mà các thành viên trong một team có thể ... soi máy cho nhau dễ dàng. Thế nhưng nó hoàn toàn không thích hợp cho lập trình. Hãy thử yêu cầu người viết sách làm việc trong môi trường như vậy xem sao.

Lập trình là một loại công việc tương đối độc lập. Những công việc độc lập đòi hỏi một môi trường độc lập. LTV cần có không gian riêng, ít nhất là để họ có thể tập trung, và quan trọng hơn là tạo cảm giác thoải mái để họ hưng phấn. Ngồi lâu trước máy tính trong cùng một tư thế rất khó chịu. Đó là chưa kể mật độ máy móc quá dầy trong không gian nhỏ hẹp có hại cho sức khoẻ.

Theo tôi, nếu bạn không thể cấp cho mỗi LTV một không gian đủ thoáng, có lẽ bạn đang thừa người so với quy mô của công ty. Nói cách khác, bạn đang đầu tư quá nhiều vào nhân lực và quá ít vào không gian.

Không gian suy nghĩ

Lập trình đòi hỏi thời gian nghĩ nhiều hơn thời gian gõ code. Đôi khi ngôi trước màn hình máy tính không phải là cách tốt nhất để suy nghĩ, nhất là khi không gian làm việc vốn đã chật hẹp. Các công ty lớn thường có hẳn một khuôn viên cho LTV đi lại suy nghĩ. Các công ty nhỏ nên sử dụng phòng seminar, bếp, hay gác thượng làm nơi cho LTV tuỳ ý sử dụng.

Đồ uống và bánh kẹo

Ở công ty Y mà tôi từng làm, đồ uống - bao gồm từ cà phê đủ loại đến trà chanh, trà xanh, trả gừng, nước lọc - và bánh kẹo đều được cung cấp miễn phí. Ngoài chức năng "thanh lọc cơ thế, giải nhiệt cuộc sống", đồ uống và bánh kẹo sẽ giữ cho đầu óc tỉnh táo, tinh thần sảng khoái, gây cảm giác thân thiện đặc biệt cho LTV. Một giải pháp ít tốn kém để xây dựng văn hoá và sự gắn kết trong công ty.

Thiết kế nội thất

Tôi rất thích những bức tranh ngộ nghĩnh và sáng tạo trên khắp các phòng ở công ty Z. Điều này rõ ràng đã làm không gian làm việc của tôi và đồng nghiệp trở nên sống động hơn hẳn, kích thích khả nắng sáng tạo cũng như tinh thần làm việc của chúng tôi. Nếu như quy mô công ty của bạn chưa đủ để thiết kế được những không gian kiểu như thế này thì ít nhất bạn cũng nên rót một chút sức sống vào môi trường làm việc bằng những biện pháp ít tốn kém như công ty Z nói trên.

Những tấm bảng trắng

Tôi nghe nói trong Googleplex luôn treo những tấm bảng trắng khắp nơi. Chúng hỗ trợ cho nhu cầu giao tiếp ý tưởng giữa các LTV với nhau. Các ý tưởng trong ngành lập trình thường dễ thể hiện duới dạng biểu đồ hơn là chỉ bằng lời nói.

Âm nhạc

Results show that people who listened to music of their own selection were able to perform better than those with no music who performed better than those who listened to music they disliked.

Xem thêm: StackOverflow

Trước khi bắt tay vào viết code, tôi thường suy nghĩ trong không gian yên lặng để xây dựng kiến trúc và thuật toán trong đầu. Nhưng đến khi viết code, tôi đặc biệt làm việc hưng phấn hơn nhiều nếu được nghe nhạc tự chọn (thường là death metal khi code ầm ầm hào sảng, guitar cổ điển khi cần code chậm và bình tĩnh, flamenco khi code ngẫu hứng). Tôi nghĩ các công ty nên cung cấp headphone trên mỗi PC. Điều này còn giúp cho LTV giữ tập trung nếu môi trường xung quanh đang ồn ào (nhà bên cạnh đang xây lại - chuyện thường ngày tại HN).

Trên đây tôi đã cố ý lọc ra những điểm hay bị bỏ qua nhất trong khâu thiết kế không gian ở các công ty công nghệ. Tất cả các điểm kể trên đều hướng tới mục đích giúp cho LTV có thể phát huy hết khả năng của mình.

Hãy thử phân tích môi trường làm việc tại BKIS. Với số tiền đầu tư không nhỏ, BKIS có một quang cảnh chuyên nghiệp, tiện nghi sang trọng, có nơi vui chơi giải trí, có không gian suy nghĩ (hành lang?). Thế nhưng diện tích không gian làm việc trên đầu người còn thấp, bài trí còn gò bó, chưa sáng tạo, thiếu sức sống.

Điểm đáng chú ý là tác giả bài viết tuy rất quan tâm đến quản trị doanh nghiệp nhưng lại tỏ ý hoàn toàn hài lòng với môi trường ở BKIS, và có lẽ rất nhiều nhà quản lý công nghệ khác cũng vậy. Tôi ngờ rằng các nhà quản lý công nghệ đang chưa dành sự quan tâm thoả đáng đến đặc thù của công việc lập trình.

Một thế giới khác

2010-01-22T21:35:00.002+07:00

Đúc kết từ trải nghiệm bản thân, tôi hay chia sẻ với những người bạn thân thiết của mình rằng: hãy tìm kiếm đam mê và tự thiết kế phong cách sống của mình xung quanh nó.

Mỗi lần như thế bạn tôi hay hỏi, thế nào là đam mê? Làm sao để phân biệt đam mê với một sở thích bình thường, chưa đủ để gọi là đam mê?

Hình như tôi chưa bao giờ phải băn khoăn với câu hỏi này. Hình như trong tôi có một ranh giới rõ ràng giữa cảm giác đam mê và cảm giác thinh thích. Hình như tôi biết câu trả lời nhưng nó quá mơ hồ để diễn đạt ra bằng lời.

Cho đến khi tôi bắt gặp một profile trên Facebook với phần About me như sau:

I love dreaming and reading. To me, they are both an act of denying reality and living in other worlds, one constructed by me and the other constructed by various writers. Finishing a book is similar to waking up from a dream and being in a dream in a sense is identical to reading a book.

Vân Nguyễn

Khi đọc đoạn văn trên, tôi nhận ra rằng cảm giác đam mê có thể diễn đạt được bằng lời!

Đam mê đơn giản là cảm giác bị hút vào một thế giới khác, tựa như một giấc mơ. Một thứ mà ta đam mê là thứ có thể liên tục đưa ta vào một thế giới khác.

Tôi thích nghe nhạc. Tôi nghe đủ loại nhạc. Đôi khi tôi cũng có cảm giác chìm đắm vì một bài nhạc pop nào đó sên sến sẵn tiện tâm trạng cũng đang hơi sên sến. Nhưng mỗi lần đi nghe guitar cổ điển, tiếng đàn như ru tôi vào một giấc mơ, như kéo tôi ra khỏi thực tại.

Tôi thinh thích nhạc pop nhưng không đam mê nó. Tôi đam mê nghe guitar cổ điển.

"Thinh thích" nịnh bợ với tâm trạng. Đam mê mạnh hơn thế nhiều. Đam mê có thể điều khiển tâm trạng. Đơn giản vì tâm trạng hiện tại thuộc về thế giới hiện thực, còn thế giới mà đam mê tạo ra là một thế giới hoàn toàn khác.

Thời gian làm việc cho lập trình viên

2010-01-11T15:19:00.012+07:00

Các công ty phần mềm ở VN luôn phải đối mặt với bài toán nhân lực khi mà nguồn nhân lực trong nước yếu kém cả về năng lực chuyên môn lẫn thái độ làm việc. Dưới góc độ một công ty phần mềm, đặc biệt đối với công ty tư nhân, đây là một khó khăn khách quan vượt ngoài tầm kiểm soát. Tuy nhiên điều mà họ có thể làm là tạo điều kiện làm việc tốt hơn cho LTV nhằm thu hút thêm nhân tài, đồng thời tận dụng tốt hơn nguồn lực sẵn có.

Trước hết ta cần phải hiểu một đặc thù tối quan trọng của công việc lập trình: nó đòi hỏi sự tập trung cao (đế suy luận) và cảm hứng (để sáng tạo).

Hiệu quả làm việc của LTV sẽ tăng theo cấp số nhân so với mức độ tập trung. Nguyên nhân: LTV gần như phải nạp toàn bộ kiến trúc hệ thống và các chi tiết của module mà họ đang thực thi vào bộ nhớ tạm, trong khi bộ vi xử lý liên tục làm việc song song.
Bên cạnh đó, nếu muốn tận dụng khả năng sáng tạo của LTV để có những bước đột phá công nghệ, cần trân trọng và kích thích cảm hứng, nhiệt huyết, đam mê của họ.

Lập trình gần với viết sách hơn đánh máy vi tính.

Theo tôi quan sát trực tiếp ở một số công ty, nghe ngóng từ bạn bè cũng như lượm lặt từ nhiều blog cá nhân, các công ty phần mềm ở VN chưa làm tất cả những gì có thể trong khả năng của họ để tạo điều kiện làm việc tốt nhất cho LTV, qua đó tận dụng tối đa nguồn lực trí óc mà LTV mang lại.

Sau đây tôi sẽ đi sâu vào 3 yếu tố cấu thành nên điều kiện làm việc: thời gian, không gian, con người.

Thời gian

Mọi chính sách quản lý thời gian trong một công ty phần mềm cần phải cân nhắc đến cách làm việc tối ưu cho LTV: họ làm việc theo từng khoảng thời gian dài, tuyệt đối không bị gián đoạn. Nguyên nhân: (1) LTV phải bỏ ra chi phí thời gian không nhỏ để "khởi tạo" bộ nhớ và bộ vi xử lý mỗi lần bước vào trạng thái tập trung, (2) bước vào trạng thái tập trung rất khó nhưng mất trạng thái này rất dễ, (3) trong một ngày, số lần có thể rơi vào trạng thái tập trung là hữu hạn (1-2 lần).

Đừng áp dụng giờ hành chính đối với LTV

Chính sách áp dụng giờ hành chính một cách nghiêm ngặt đối với LTV, theo tôi, là một sai lầm phổ biến nhất mà cũng dễ khắc phục nhất trong các công ty phần mềm. Dưới đây là những nhược điểm của chính sách này:

Tăc đường: Ở HN, cứ tầm 8h sáng và 5h30 chiều là đường phố đều đầy bụi và xe. Đi lại vào các khung giờ này vừa lãng phí thời gian vừa tổn hại sức khoẻ. Khi đến công ty, LTV thường khá mệt mỏi về tinh thần, điều này gây khó khăn cho việc bước vào trạng thái tập trung.
Không phù hợp với đồng hồ sinh học của mọi LTV: Mỗi người có một khoảng thời gian "ưa thích" trong ngày riêng, lúc mà họ dễ dàng rơi vào trạng thái tập trung nhất. Không phải ai cũng ưa khung giờ hành chính thông thường. Ép buộc họ phải theo khung giờ này tức là họ sẽ không thể làm việc tối ưu.
Tạo cảm giác gò bó: Quản lý chặt chẽ theo khung giờ hành chính ảnh hướng không nhỏ đến cảm hứng làm việc của LTV. Nếu không quản lý, đôi khi LTV có thể mải mê với công việc đến 8-9h tối, vì họ vốn là những người yêu công việc. Thế nhưng nếu khắt khe, họ sẽ ra về "vào đúng giờ quy định". Vấn đề ở đây là, bản thân LTV không biết khi nào trạng thái tập trung của họ sẽ kết thúc. Đặt một mốc giờ ra về cố định sẽ làm ảnh hướng đến tâm lý của họ khi đang tập trung.

Đối với công việc lập trình, việc áp dụng giờ hành chính là không cần thiết. Liệu nhà xuất bản có nên yêu cầu người viết sách phải đến văn phòng theo giờ hành chính không?

Theo tôi, một chính sách thời gian mềm mỏng cho LTV sẽ hợp lý hơn. Trước hết, nên đảm bảo cho LTV có thể làm việc tại nhà. Tuy vậy, không gian ở công ty vẫn nên đủ hấp dẫn để LTV thích đến công ty hơn ở nhà (sẽ bàn trong phần sau). Về thời gian ở công ty, cho phép LTV đến và về lúc nào tuỳ thích, có thể ngủ lại qua đêm nếu muốn.

Hãy hình dung công ty như một không gian cho phép các nhóm đến bàn luận và làm việc cùng nhau, thay vì nơi để cấp trên có thể kiểm soát hoạt động của họ.

Nếu không quản lý LTV về thời gian thì quản lý họ theo kết quả công việc, nhưng kết quả công việc lập trình rất khó đo lường. Lập trình không giống như dịch sách. Khi tôi đi dịch sách, Alphabooks trả cho tôi theo số lượng 1000 từ tiếng Anh - rất rõ ràng, đơn giản và hiệu quả. Thế nhưng sẽ thật ngớ ngẩn nếu trả cho LTV theo số LOC (lines of code).

Đây là một thực tế, một thử thách đối với nhà quản lý. Dù sao ta nên nhớ rằng, thử thách này vẫn tồn tại cho dù bạn có yêu cầu LTV đến và về theo giờ hành chính hay không! Áp dụng chính sách thời gian chặt chẽ chỉ tạo cảm giác áo cho nhà quản lý rằng LTV của họ đang làm việc cật lực, trong khi nếu bỏ hẳn đi yếu tố thời gian thì nhà quản lý sẽ chuyên tâm hơn vào việc đánh giá tiến độ và kết quả công việc. Trong trường hợp tối ưu, nhà quản lý có thể hoàn toàn tin tưởng vào LTV tự ước lượng deadline theo khối lượng công việc; khi này, trách nhiệm của nhà quản lý chỉ là hiểu rõ thế mạnh, sở thích từng người, qua đó phân phối công việc một cách phù hợp.

Đừng tổ chức meeting tuỳ tiện

Cần cân nhắc kỹ trước khi tổ chức mọi loại meeting, từ seminar thảo luận công nghệ cho đến nhóm họp cập nhật tiến độ công việc. Chi phí cho mỗi buổi meeting không đơn thuần chỉ là:

meeting_cost := meeting_duration * number_of_participants; // too naive

Quan trọng hơn là chi phí ngầm của meeting: nó can thiệp vào khoảng thời gian tập trung của LTV.

Tôi còn nhớ khi còn làm ở công ty X. Chúng tôi làm việc từ 8h. Seminar sẽ bắt đầu vào 9h. Tôi cố gắng làm một việc gì đó trong khoảng 8-9h, nhưng sau nhiều lần như vậy, tôi phát hiện ra rằng mình không thể làm được việc gì thực sự hiệu quả trong khoảng ngắn ngủi này.

Ở nhiều công ty nơi mà khái niệm "trạng thái tập trung" không được coi trọng, nhà quản lý không hề biết đến chi phí này, có lẽ bởi vì LTV của họ vốn dĩ chưa bao giờ làm việc tập trung.

Nói như vậy không có nghĩa là không nên tổ chức meeting dưới mọi hình thức. Ở đây, tôi chỉ nhấn mạnh chi phí không nhỏ của mỗi buổi meeting. Nhà quản lý nên cân nhắc và chỉ tổ chức meeting khi thực sự cần thiết. Meeting nên có sự chuẩn bị kỹ từ những người tổ chức, phải ngắn gọn về thời lượng và giá trị về chất lượng. Điều này vừa tiết kiệm tổng thiệt hại thời gian cho công ty, vừa thể hiện rõ sự trân trọng của công ty đối với thời gian của LTV.

Một yếu tố nữa cần phải cân nhắc là thời điểm tổ chức meeting. Theo tôi, nên tổ chức meeting định kỳ (để LTV có thể yên tâm tập trung mà không lo có meeting bất chợt) vào cuối ngày (để không cần yêu cầu LTV đến công ty sớm) trong một ngày làm việc cuối tuần (để tiện cập nhật tiến độ và phân phối công việc cho tuần sau), có sự tham gia của các thành viên trong nhóm (LTV nên biết những người còn lại đang làm gì để họ có cảm giác công bằng).

Nếu muốn giảm stress cho các buổi meeting định kỳ cập nhật tiến độ, có thể tổ chức theo phong cách thân mật, trong một quán cafe quen. Phương án này phù hợp với các nhóm làm việc độc lập, hiệu quả, nhà quản lý có thể tin tưởng.

Sự thật về thời gian

Để kết thúc phần này, tôi mong muốn vạch trần một sự thật về thời gian mà nhiều công ty phần mềm đã hiểu sai: không mấy ai có thể làm việc tập trung 8h/ngày, 5 ngày/tuần, 52 tuần/năm. Điều này là quá sức chịu đựng đối với một công việc quá nặng về trí óc như lập trình. Nếu bạn ép LTV làm việc như vậy, họ sẽ chống đối bằng cách này hay cách khác (bật IDE lên làm thơ, check mail vô mục đích, chat, F5 Facebook, nếu block Facebook rồi thì xem ảnh girl xinh, etc).

Trong "Lời xin lỗi của một nhà Toán học", Hardy cho rằng 4h/ngày hoàn toàn tập trung cho Toán học là đủ. Một blogger mà tôi tìm thấy trên mạng đề xuất ngày làm việc 6h, trong đó 2h cho sự lãng phí không tránh khỏi trong cơ cấu doanh nghiệp, 4h làm việc thực sự. 37signals thử nghiệm tuần làm việc 4 ngày, nghỉ từ thứ 6 đến CN.

Nói như vậy không có nghĩa là LTV chỉ cần tiếp túc với lập trình 4h/ngày. Thông thường, LTV bỏ nhiều thời gian ra để nghĩ về công việc, tìm hiểu công nghệ mới, tham gia vào các dự án nguồn mở, giao lưu với cộng đồng LTV, đọc sách trau dồi kiến thức, chơi các môn thể thao trí tuệ ... Đó đều là những hoạt động giúp họ nâng cao trình độ chuyên môn, duy trì đam mê, kích thích nguồn cảm hứng sáng tạo.

Sai lầm cuối cùng về thời gian, cũng là sai lầm không thể chấp nhận được mà tôi hy vọng không quá nhiều công ty mắc phải là:

working_time := time_in_front_of_computer; // fatal error!

Quy chụp tổng thời gian làm việc của LTV bằng số thời gian ngồi bên máy tính chẳng khác nào khuyến khích LTV làm việc mà không suy nghĩ.

Tại sao bạn chọn CNTT?

2009-12-31T22:45:00.006+07:00

Giả sử bạn đang làm trong lĩnh vực CNTT và bạn là một người thông minh. Vì bạn thông minh, bạn đã có thể lựa chọn một trong số rất nhiều lĩnh vực khác nhau để đầu tư thời gian và khả năng cao là bạn vẫn sẽ thành công ở một mức độ nhất định, nhưng tại sao bạn lại chọn CNTT?

Đó là một câu hỏi sâu sắc - nó đã kích thích tôi rút ra một số những đặc thù sau của ngành này:

1. Thoả mãn tư duy

Trí tò mò nằm trong bản năng của con người. Nếu như con gái có thiên hướng tò mò về con người, về những mối quan hệ xã hội, thì con trai thiên nhiều hơn về tự nhiên. Nếu như một bé gái thường hay đặt câu hỏi tại sao anh An thích chị Bình mà lại không thích chị Chi, thì một bé trai thường bỏ qua sự kiện này và nó quan tâm hơn đến chuyện tại sao trái đất hình tròn mà lại không phải hình vuông.

Con người có nhu cầu được suy luận, được sáng tạo xung quanh những đối tượng mà mình tò mò. Tương tự như việc con gái có nhu cầu chơi trò mèo vờn chuột với con trai để thoả mãn nhu cầu suy luận, sáng tạo về cảm xúc con người, về quan hệ xã hội, thì con trai cũng có nhu cầu chơi cờ để thoả mãn nhu cầu suy luận, sáng tạo về các đối tượng trừu tượng.

CNTT, cũng như các ngành kỹ thuật khác, đòi hỏi khả năng tư duy logic chặt chẽ, mà quan trọng hơn nữa là khả năng sáng tạo và tưởng tượng. Chính vì vậy, nó không thích hợp với đa số con gái nói riêng, cũng như những người có thiên hướng xã hội hơn là thiên hướng tự nhiên nói chung.

2. Khả năng ứng dụng cao

Đối với một người có thiên hướng tư duy trừu tượng rất cao, có sự hiếu kỳ thuần khiết hướng về tự nhiên, thì có lẽ Toán học sẽ phù hợp hơn. Thế nhưng, lợi thế của CNTT là tính ứng dụng của thành quả lao động.

Trong "Lời xin lỗi của một nhà Toán học", Hardy chia sẻ, những gì là đẹp đẽ, là tinh tuý nhất của Toán học thì không hề, hoặc có rất ít tính ứng dụng. Tôi không coi đây như một nhược điểm của bộ môn này, nó đơn giản chỉ là đặc thù. Trong CNTT, khả năng tận mắt trông thấy sản phẩm mà mình làm ra gây tác động tích cực lên đời sống của rất nhiều người là một động lực đáng kể.

3. Nuôi dưỡng tâm hồn

Những người làm kỹ thuật thường xuyên suy luận xung quanh những đối tượng trừu tượng. Điều này vô tình giúp họ dễ dàng cân bằng hơn trong cuộc sống. Con người luôn dành phần lớn thời gian và tâm trí cho những hoạt động liên quan trực tiếp đến con người, họ thực sự cần một khoảng không biệt lập với xã hội loài người để cân bằng lại.

Tôi quan sát, đa số dân kinh tế, xã hội mới gặp thì vui vẻ, hồ hởi, nhưng càng chơi càng thấy khó thân; ngược lại, dân khoa học, kỹ thuật lúc mới quen thì khó gần (như thể là họ không có khả năng giao tiếp), nhừng càng chơi càng thân, càng tin tưởng. Tôi còn nhớ ở công ty cũ, các thành viên chơi với nhau hồn nhiên như lớp cấp 3, cấp 2 của tôi vậy.

Chính vì "hồn nhiên" quá, bất lợi của dân kỹ thuật là thường không thu hút con gái - tất nhiên nếu bạn là giám đốc kỹ thuật thì lại là chuyện khác. Tuy vậy, một người làm kỹ thuật có thể xã hội hoá dễ hơn là một người quá thiên về xã hội có thể tự nhiên hoá. Hơn nữa, việc bạn không thu hút những cô gái hời hợt, ham hào nhoáng, thực dụng không hẳn đã là một bất lợi.

4. Trẻ trung, sôi nổi

So với các ngành khoa học kỹ thuật khác, CNTT là một ngành hiện còn rất trẻ. Còn xa, rất xa nữa, CNTT mới có thể đạt được độ chín tương đương với các ngành khoa học khác. Một mặt, nó có nghĩa là CNTT tồn tại rất nhiều hạn chế, nhiều sự khập khiễng, nhiều chuẩn không hợp lý, nhiều điều không hoản hảo. Mặt khác, đối với những người ham muốn khai phá, CNTT là một mảnh đất rất giàu tiềm năng. Chỉ một điểm bùng phát trong suy nghĩ của bạn cũng có thể làm thay đổi toàn ngành trên diện rộng, và qua đó tác động đến cả thế giới.

Vì còn trẻ, CNTT không có khối lượng kiến thức bị tích trữ lại quá lớn. Bạn có thể trang bị cho mình một lượng vừa đủ và bắt đầu bắt kịp với kiến thức hiện hành. Cũng vì còn trẻ, CNTT thay đổi từng ngày, nhanh đến chóng mặt, tạo cảm giác hào hứng, sôi nổi, tươi mới cho những người tham gia.

Cũng chính vì điều này, CNTT sẽ không phù hợp với những người trì trệ. Những người trì trệ sẽ nhanh chóng bị lỗi thời so với tiến độ của ngành và rất dễ để tuột mất đam mê.

Cần phải nói thêm rằng tốc độ phát triển của CNTT tuy nhanh nhưng báo chí và truyền thông đã làm cho người ta có cảm giác còn nhanh hơn rất nhiều. Những thay đổi mang tính bản lề chỉ diễn ra trong vòng từ 5-10 năm, tích luỹ từ những thay đổi nhỏ mà dân Internet gọi chung là "the next big thing". Đây cũng là một đặc thù mà những người tham gia cần có tầm nhìn để xác định đâu là hype, đâu là thực chất.

Kết luận

Nhiều người coi công việc chỉ là một công cụ để đạt được những mục tiêu khác trong cuộc sống. Quan điểm này đánh giá quá thấp tầm quan trọng của công việc. Nên nhớ rằng bạn bỏ ra phần lớn thời gian trong ngày với nó - sẽ tốt hơn nếu bạn chọn một công việc mà mình thực sự yêu thích.

Việc lựa chọn chuyên môn không hề đơn giản. Nó giống như lựa chọn người yêu vậy. Bạn phải sử dụng cả lí trí lẫn trái tim. Nếu không có cảm xúc thì không thể yêu, có cảm xúc mà không phù hợp thì không thể lâu dài. Và cũng giống như tình yêu, tìm được nó đã khó rồi, giữ được nó lại càng khó hơn. Hiện nay, công việc trung bình của dân công nghệ có vẻ như tương đối nhàm chán, đòi hỏi bạn phải nỗ lực một cách có ý thức để duy trì ngọn lửa nhiệt tình - điều mà tôi mong muốn được viết tiếp trong bài sau.

Nghệ thuật code

2009-12-14T17:27:00.002+07:00

Một phản hồi mà tôi nhận được từ Những hạn chế của Java cho rằng lập trình viên Java không mấy quan tâm đến những hạn chế đó khi mà họ hoàn toàn có thể đạt được cùng một mục tiêu bằng cách này hay cách khác.

Nhận định trên không sai nếu ta coi mọi sản phẩm lập trình như những hộp kín. Toàn bộ giá trị của mọi sản phẩm lập trình sẽ nằm ở những tính năng mà chúng bộc lộ. Số source code bên trong có thể được lờ đi.

Tuy nhiên, gần như mọi sản phẩm lập trình sẽ đến lúc cần phải được nâng cấp, gần như mọi source code sẽ đến lúc cần phải được sửa đổi và dùng lại. Xu hướng open source càng nhấn mạnh rằng một khi code được viết ra, sẽ có người đọc để học hỏi, đóng góp. Trách nhiệm của lập trình viên khi này không chỉ nằm ở việc đảm bảo code thực thi được mục tiêu mà còn ở việc viết code sao cho trong sáng, hàm súc, thông minh.

Tính nghệ thuật của công việc lập trình không chỉ nằm ở vẻ đẹp của sản phẩm mà còn được chứa đựng ngay trong source code. Bản thân source code thể hiện tư duy của kiến trúc sư và của người viết code. Trong đa số các sản phẩm được đánh giá cao nhất từ trước đến giờ, hai người này là một.

Nếu một bức tranh là một sản phẩm nghệ thuật thì tính nghệ thuật của nó không chỉ nằm ở ý đồ của họa sỹ mà còn ở từng đường nét mà anh ta vẽ ra. Nếu một bản nhạc là một sản phẩm nghệ thuật thì tính nghệ thuật của nó không chỉ ở thông điệp của nhạc sỹ mà còn được hàm chứa ngay trong từng tiếng đàn mà người chơi chau chuốt, nâng niu.

Giới nhà văn thường phân tích yếu tố nghệ thuật trong cách dùng câu từ của một tác phẩm văn học bên cạnh giá trị nhân văn của toàn bộ tác phẩm. Tương tự như vậy, một codebase không chỉ ẩn chứa vẻ đẹp nghệ thuật qua kiến trúc vĩ mô mà còn qua từng chi tiết nhỏ - từng module, từng function, từng dòng code.

Người chơi guitar phải mất trung bình 10 năm lao động nghệ thuật để có được tiếng đàn âm vang, tròn trịa, sâu lắng. Người viết code cũng phải mất từng ấy thời gian để viết code một cách trong sáng, hàm súc, thông minh.

Nếu bạn vẫn coi viết code là một công việc thuần tuý chân tay, bạn không nhận thấy sự khác nhau giữa code viết bởi một lập trình viên trung bình và code viết bởi Linus Torvalds chẳng hạn, thì rất có thể bạn chưa đủ độ chín để hiểu được sự khác nhau ấy. Điều này tương tự với việc người mới học đàn thường không nhận thấy sự khác nhau giữa tiếng đàn của thầy dạy đàn và của John Williams.

Cảm thụ vẻ đẹp nghệ thuật phụ thuộc vào năng lực chuyên môn. Cảm xúc thu được khi hưởng thụ nghệ thuật bị giới hạn bởi nhận thức về bộ môn nghệ thuật đó.

Điều này cũng có nghĩa là bài viết này bị giới hạn bởi trình độ của tôi trong thời điểm hiện tại. Cái mà tôi hiểu về nghệ thuật hẳn sẽ thay đổi sau 10 năm nữa. Đến lúc đó, tôi sẽ có dịp nhìn lại xem mình nhận thức thế nào về nghệ thuật cách đây 10 năm.

Cách đây 2,5 năm khi tôi có dịp làm việc với một người bạn là VietNT, tôi mới biết thế nào là code đẹp. Cùng một mục tiêu, nhưng code của VietNT trong sáng, hoa mỹ hơn của tôi rất nhiều. Tôi vẫn coi VietNT là người có ảnh hưởng sâu sắc nhất tới tôi cho đến thời điểm này trong lĩnh vực lập trình.

Vào lúc đó, với trình độ hạn chế của mình, tôi tạm hiểu code đẹp là code sáng sủa (chia đoạn đúng chỗ, ngắt câu đúng chỗ), dùng từ chính xác (đặt tên biến, tên hàm, tên class), đủ ý (không viết thừa, không viết thiếu), tối ưu (nhận thức về tài nguyên, về tốc độ thực thi).

Khi mới học đàn, tất cả các thầy dạy đàn tận tâm đều sẽ khuyên bạn nên chơi thật chậm và lắng nghe từng tiếng đàn của mình. Bạn cũng sẽ không được phép chơi tác phẩm cho đến khi thành thục những bài tập đơn giản nhất. Tương tự, nếu nghiêm túc với nghệ thuật code, có lẽ ta nên bắt đầu với những bài toán đơn giản nhất. Code thật chậm và để ý đến từng dòng code.

Cái khó của lập trình viên là không mấy ai khuyến khích họ "code chậm", "code đẹp". Lập trình là một ngành đã được thương mại hoá. Thông thường, bạn sẽ lắp vào một khâu trong quy trình làm sảm phầm đã được công nghiệp hoá. Người ta dùng từ "thợ code" để chỉ lập trình viên thời nay là vì thế.

Ở Việt Nam, trình độ trung bình của lập trình viên không cao. Bạn không cần phải quá giỏi so với thế giới để trở thành senior programmer hay giám đốc kỹ thuật. Bạn sẽ được giao những bài toán hết sức phức tạp mà bạn vẫn có thể xoay sở thực thi theo cách này hay cách khác.

Bạn có thể chỉ cân tập đàn 6 tháng để chơi được một tác phẩm khó, nhưng sẽ cần đến 10 năm để chơi nó như một người nghệ sỹ thực thụ.

Không phải tất cả mọi người đều hiểu hết giá trị nghệ thuật mà một người nghệ sỹ tạo ra. Code đẹp để làm gì trong khi sếp không quan tâm, end users thì lại càng không? Đó là một câu hỏi thông mình và hợp lý. Câu trả lời tuỳ thuộc vào mức độ đam mê của chính bạn đối với bộ môn nghệ thuật code.

Đọc thêm: Refactoring, Beautiful Code, Code Complete. Như tất cả các cuốn sách công nghệ khác, chúng đều dài dòng hơn mức cần thiết. Bản thân tôi cũng chưa đọc hết nhưng chỉ cần lướt qua cũng có thể giúp truyền cảm hứng cho bạn về việc viết code đẹp.

Những hạn chế của Java

2009-11-20T21:09:00.027+07:00

Mặc dù chưa thực sự gây một tác động nào đáng kể đối với vị trí độc quyền của C/C++ trong các ứng dụng đòi hỏi performance cao, lập trình games và lập trình hệ thống, nhưng dưới tầm ảnh hưởng của các tập đoàn lớn như Sun, Oracle, IBM, Java đã tìm được cho nó một sân chơi riêng: embedded devices và server-side programming.

Tuy nhiên, đến khi các ngôn ngữ linh động hơn, thích hợp hơn cho sân chơi này xuất hiện - như Python, Ruby, Scala - và ASP.NET ngày một trở nên chín chắn hơn, thì những điểm yếu của Java bắt đầu được bộc lộ. Những tín đồ Java lâu năm giờ đây quay lưng lại và chỉ trích nó, như Bruce Tale viết trong cuốn Beyond Java, và dư luận bắt đầu xôn xao xung quanh những tiên đoán về cái chết của Java.

Có lẽ phương châm bảo thủ, coi trọng an toàn hơn tốc độ, khống chế quyền tự do của lập trình viên nhằm đảm bảo độ tin cậy cho code, và việc Java chạy trên một VM đã khiến nó không thể cạnh tranh được với C/C++ trên vương quốc của hai ngôn ngữ này. Thế nhưng đâu là nguyên nhân khiến cho Java tự đánh mất thị phần vào tay các giải pháp mới nổi?

Chúng ta hãy cùng điểm qua một số hạn chế trong thiết kế của ngôn ngữ Java và thư viện chuẩn của nó:

1. Thiếu language support cho collections

Ta có mảng động các số nguyên a. Ta cần nhân đôi mỗi phần tử của nó. Dưới đây là cách làm chuẩn trong Java, đã áp dụng autoboxing của Java 5 và double brace initialization (thanks to anh Buu Nguyen):

ArrayList a = new ArrayList() {{
    add(1);
    add(2);
    add(3);
}};

for (int i = 0; i != a.size(); ++i)
{
    a.set(i, a.get(i) * 2);
}

Câu trả lời của Java cho thấy một số vấn đề:

Java không support collection initializer (như D, C# 3.0, Ruby, Python, Scala).
Không support automatic type inference (như D, C++0x, C# 3.0).
Không support operator overloading (như D, C++, C#, Ruby, Python, Scala).
Không cho phép vòng foreach hiệu chỉnh các phần tử của collection (như D, C++0x).

Các thao tác liên quan đến collections (như ArrayList, TreeMap, HashMap) diễn ra thường xuyên đến nỗi C# 3.0 đã giới thiệu LINQ để thu hút lập trình viên. Việc Java không đối xử đặc biệt với collections ở mức language là một nguyên nhân khiến cho code viết trên Java tỏ ra xấu xí và thô kệch hơn so với các ngôn ngữ mới.

Java 7 sẽ hỗ trợ type inference.

2. Thư viện chuẩn "không iterable"

Java 5 giới thiệu vòng foreach với mục đích rút gọn những đoạn code duyệt qua một đối tượng có thể duyệt được (iterable). Tuy nhiên, thư viện chuẩn thì hình như không được tái thiết kế để trở nên thân thiện hơn với cải tiến mới này, đơn cử như StringTokenizer:

StringTokenizer tokenizer = new StringTokenizer("this sucks");
while (tokenizer.hasMoreTokens())
{
    String token = tokenizer.nextToken();
    // Do something with token here
}

Trong khi lập trình viên kỳ vọng sẽ được áp dụng foreach như sau:

for (String token : new StringTokenizer("this sucks"))
{
    // Do something with token here
}

Nguyên nhân là vì StringTokenizer implements Enumeration mà không implement Iterable, trong khi foreach chỉ làm việc với Iterable.

Rất nhiều class trong thư viện chuẩn không implement Iterable mặc dù điều này là hợp lý, chẳng hạn:

Java API for XML Processing: tại sao getChildNodes() không return một Iterable<Node> có implement RandomAccess mà lại return NodeList?
Java Database Connectivity: tại sao ResultSet không implement Iterable?

Điều này thể hiện sự không nhất quán trong thư viện chuẩn của Java (và hiển nhiên là các thư viện thuộc bên thứ ba). So với Java Collection Framework, C++ STL được thiết kế chặt chẽ hơn rất nhiều.

3. Không hỗ trợ mixin hoặc đa kế thừa

Ta có interface Speakable. Class DefaultSpeakable cung cấp default implementation cho Speakable. Class SuperDog extends class Dog và implement Speakable. Ta muốn SuperDog sử dụng lại default implementation từ DefaultSpeakable, có thể override một số methods theo ý mình. Hiển nhiên Java không cho phép SuperDog kế thừa DefaultSpeakable vì SuperDog đã kế thừa Dog mất rồi. Khi này ta không có sự lựa chọn nào khác ngoài implement lại Speakable từ đầu.

Tình huống trên xảy ra khá thường xuyên. Lấy thư viện chuẩn làm ví dụ. Mỗi khi implement Iterator, ta buộc phải implement hasNext(), next(), remove(). Giả sử Java cho phép một trong hai biện pháp - mixin hoặc đa kế thừa - thì hẳn sẽ có một class DefaultIterator nào đó cung cấp sẵn remove() (throw new UnsupportedOperationException()) và hasNext() (return next() == null). Trong phần lớn trường hợp, người sử dụng sẽ chỉ phải tự viết lấy next().

Hạn chế này làm các interface trong Java luôn cố gắng giảm bớt số lượng methods một cách không tự nhiên. Thử so sánh Java Iterator với Ruby Enumerable (Ruby là một ngôn ngữ hỗ trợ mixin).

Như vậy có hai hậu quả chính khi Java quyết định loại bỏ đa kế thừa mà lại không cho phép interface có implementation (mixin):

Người sử dụng không thể dùng default implementation nếu class của anh ta đã kế thừa một class khác. Anh ta chỉ còn cách copy-paste từ default implementation.
Người viết thư viện không thể thoải mái cung cấp thêm tính năng vào trong interface. Điều này làm thiết kế của anh ta đôi khi trở nên gượng ép.

4. Không chấp nhận khái niệm function

Java chỉ có khái niệm method. Method thuộc về class. Đây là lý do tại sao HelloWorld trong Java tương đối dài hơn bình thường một cách không cần thiết:

public class HelloWorld
{
    public static void main(String[] args)
    {
        System.out.println("It takes some time but hey, hello!");
    }
}

Nhưng Java có static method. Liệu có thể coi static method như function chính quy, và class mà static method thuộc về có thể coi như namespace cho function? Không hẳn, ít nhất là so với các ngôn ngữ mà function (hay callable objects) được coi trọng (D, C, C++, Ruby, Python, Scala và hàng loạt các functional languages khác - C# có delegate):

Không thể trừu tượng hoá một function call. Cũng tức là:
Static methods trong Java không thể dùng làm argument cho các methods khác.

Java tìm cách trốn tránh hai hạn chế trên bằng cách khuyến khích sử dụng interface kết hợp với anonymous inner class. Chẳng hạn ta cần viết một method lọc ra các phần tử thoả mãn một điều kiện nhất định trong Java. Bởi lẽ không thể trừu tượng hoá "điều kiện nhất định" thành một con trỏ hàm đơn giản nên lập trình viên Java chỉ còn cách sử dụng interface Predicate<T> với một method bên trong là isSatisfied(T elem), và như vậy signature cho method ban đầu trở thành:

Iterable filter(Iterable source, Predicate condition);

Và thông thường thì người sử dụng sẽ create một anonymous inner class implement Predicate<T> mỗi khi gọi method này. Giải pháp thiếu trực quan và làm code trở nên thô kệch này xuất hiện khắp mọi nơi trong thư viện chuẩn, có lẽ bởi vì function là một khái niệm không thể thiếu trong lập trình.

Trong bài viết nổi tiếng The Kingdom of nouns, Steve Yegge tranh luận rằng sự ép buộc phải thiết kế theo danh từ (object/classes) mà không tồn tại khái niệm động từ (function) của Java là một sai lầm lớn.

Java 7 dự định sẽ giới thiệu closure để khắc phục một phần. Nhưng có vẻ như đề xuất này đã bị loại bỏ.

Cùng nhiều hạn chế khác ...

Sau đây là một số nhược điểm nữa mà các tác giả khác đã đi sâu, tôi đồng ý và không cảm thấy cần thiết phải viết lại ở đây:

Checked exception: Java cho rằng một số exception nhất định bắt buộc phải được catch. Thêm một nguyên nhân khiến cho code trở nên dài dòng.
Type erasure: Java 5 implement generic programming bằng type erasure - nói đơn giản ArrayList<Person> sẽ trở thành ArrayList<Object> lúc runtime.
Không thể viết generic code vừa làm việc được với array vừa làm việc được với Java Collection Framework (C++/D khắc phục bằng iterator). Ví dụ.
Destructor trong Java (Object.finalize()) không chắc chắn sẽ được gọi trước khi process kết thúc. Điều này loại bỏ hoàn toàn khả năng áp dụng RAII vào trong thiết kế - nói đơn giản, nếu bạn đã open một FileStream thì phải explicitly close() nó.
Không có khái niệm property trong class: mỗi property tương ứng với một cặp get/set. Điều này làm code trở nên thô kệch cho cả người viết thư viện và người sử dụng. Xem thêm C# Property.

Kết luận

Trong những năm vừa qua, Java đã làm nền tảng cho rất nhiều thư viện và framework - trên thực tế, quá nhiều và chúng đều quá cồng kềnh. Nguyên nhân một phần do lỗi của người viết thư viện (lạm dụng XML và overdesign là hai bất cập hàng đầu), nhưng không thể phủ nhận những hạn chế trong ngôn ngữ Java và sự định hướng sai lệch của thư viện chuẩn cũng đã gây ảnh hưởng không nhỏ.

Với việc Java 7 từ chối hầu hết các đề xuất nhằm khắc phục những nhược điểm sâu sắc nhất thuộc về ngôn ngữ thì tương lai của Java lại càng trở nên đáng lo ngại hơn bao giờ hết. Cho đến nay, uy tín của Java trong giới hackers (hardcore programmers), startups, researchers đã giảm hẳn - nó vốn chưa bao giờ được họ coi trọng. Khi những bộ phận này thay đổi sở thích, các công ty lớn và các trường đại học rất có thể sẽ từ từ chuyển mình theo.

Lựa chọn editor cho lập trình viên

2009-07-29T18:04:00.003+07:00

Để đơn giản hóa ngôn từ, trong bài viết này tôi sẽ sử dụng thuật ngữ editor để ám chỉ cả trình soạn thảo đơn giản (như Notepad) lẫn môi trường phát triển tích hợp IDE (như Visual Studio).

Trong giới lập trình viên, có một số chủ đề nhất định mà mỗi lần xuất hiện trên các diễn đàn hay blogs, chúng sẽ có xu hướng kích hoạt một cuộc tranh luận sôi nổi: Ruby hay Python, Java hay PHP, GNOME hay KDE, vim hay emacs ...

Những chủ đề so sánh công nghệ kiểu này có chung một đặc điểm: chúng mang tính cá nhân. Việc lựa chọn Ruby hay Python, Gnome hay KDE đều phụ thuộc phần lớn vào sở thích của lập trình viên - khó có thể nói công nghệ nào tốt hơn một cách hoàn toàn khách quan. So sánh Vim với Emacs chẳng khác nào so sánh Metallica với Megadeth.

Nói là vậy chứ tôi không thể hiểu nổi tại sao người ta có thể so Megadeth với Metallica :P

Nếu coi việc lựa chọn editor như một vấn đề mang tính cá nhân thì tiêu chí lựa chọn quan trọng nhất là nó phải mang lại cho bạn cảm giác thoải mái và sự hiệu quả. Có những siêu cao thủ chỉ dùng Notepad để lập trình. Lại có những siêu sao khác phải cần đến những IDE rất cồng kềnh như IntelliJ IDEA. Họ đều có lý, nhưng những sự lựa chọn của họ sẽ không giúp bạn xác định được đâu mới là môi trường thích hợp nhất cho riêng mình. Cách duy nhất là hiểu mình muốn gì và thử qua những lựa chọn phổ biến.

IDE hay text editor?

Với số lượng lựa chọn không nhỏ, điều đầu tiên cần xác định là liệu bạn muốn một IDE hay một editor đơn giản. Không cần phải nhắc lại IDE mạnh đến thế nào với những tính năng như auto-completion, refactoring, auto-error-detection, code generation, GUI building ...

Tuy nhiên để thực thi những tính năng này, IDE thường parse toàn bộ code base và liên tục re-parse khi ta edit một file trong code base. Việc làm này đòi hỏi CPU, ngốn RAM, và cả HDD space khi IDE có thói quen save lại công việc của nó sau khi kết thúc. Đối với một project nhỏ, những thủ tục này thường không đem lại cảm giác khó chịu cho lập trình viên, nhất là với phần cứng mạnh. Nhưng khi project lớn dần và trở nên lệ thuộc vào nhiều thư viện cũng như projects khác nhau, hoạt động của IDE luôn tỏ ra ì ạch và gây ra stress cho người sử dụng.

Đối với project nhỏ, ta không cần dùng đến IDE vì việc quản lý và sửa đổi đều nằm trong tầm quyển soát. Đối với project quá lớn, IDE lại không thể xử lý với tốc độ chấp nhận được. Đây là luận điểm chính của tôi giải thích tại sao tôi không mấy khi sử dụng IDE, trừ ở công ty cũ khi tôi dùng Visual Studio + Visual Assist X + cool color schemes để code C++.

Hơn nữa, tôi đề xuất không nên dùng IDE nếu bạn chưa quen với toolset của một ngôn ngữ mới. Có nhiều lập trình viên bị lệ thuộc vào IDE đến nỗi không thể compile một project java bằng javac và không biết tự viết ant build script. Theo tôi, bạn chỉ nên dùng IDE sau khi đã hiểu cơ bản nó đã giúp bạn thực hiện những thao tác gì.

Tuy nhiên, việc bạn có thích dùng IDE hay không vẫn là một vấn đề mang tính cá nhân. Là một người sử dụng Arch Linux, tôi đã quen với những tool nhỏ gọn và không cảm thấy thoải mái đối với IDEs, nhưng tôi có thể hình dung một designer quen dùng các sản phẩm của Adobe khi chuyển qua lập trình sẽ không lấy gì làm khó chịu với giao diện tích hợp quen thuộc của các IDE như Eclipse, NetBeans, IntelliJ IDEA, cũng như sự ì ạch thường trực của chúng. Đó là sở thích và cá tính của mỗi người, nó không trực tiếp thể hiện khả năng. Quan trọng là bạn làm việc hiệu quả với môi trường mình lựa chọn.

Có khi nào editor hiệu quả hơn IDE?

Ngay cả khi đã hoàn toàn thỏa mãn với một IDE nào đó và không hề phàn nàn về tốc độ của nó, lập trình viên vẫn nên tìm kiếm và lựa chọn một editor chuyên dụng. Editor này sẽ được sử dụng để edit các file text config đơn giản, để code các ngôn ngữ chưa được IDE hỗ trợ, hoặc để thao tác sửa đổi nhanh mà không muốn tốn thời gian mở và đóng IDE.

Tôi quan sát rất nhiều lập trình viên tìm đến Notepad khi cần làm những công việc trên. Trên thực tế, có lẽ họ sẽ hiệu quả hơn với một editor mạnh hơn Notepad trong khi vẫn nhanh nhẹn và nhỏ gọn gần bằng công cụ soạn thảo không thể đơn giản hơn này.

Cá nhân tôi dùng Vim trong mọi trường hợp, từ những đoạn script nhỏ lẻ viết xong xóa đi cho đến những project lớn hơn. Đôi khi cần code trên Windows, trong quá khứ tôi vẫn thường dùng SciTE hoặc Visual Studio, nhưng tôi đang chuyển sang giải pháp Textadept hoặc Geany.

Các công cụ mà tôi lựa chọn có một số điểm chung: nhanh, nhỏ gọn, hỗ trợ auto-indent, hỗ trợ syntax highlight, hỗ trợ thay đổi color scheme (vì tôi không thể làm việc lâu với nền trắng), hỗ trợ code snippets, và nên có khả năng tùy biến thông qua một scripting language.

Tuy Vim rất mạnh nhưng có thể hiểu được tại sao số người ghét nó không ít hơn số fan hâm mộ của nó là mấy. Dù rất thích Vim, tôi vẫn phải thừa nhận việc nó sử dụng một scripting language tự chế - gọi là Vim script - đã gây khó khăn cho người sử dụng trong việc tùy biến. Họ buộc phải học thêm một ngôn ngữ mới. Đó là chưa kể phong cách edit bằng mode của Vim rất mất thời gian để làm quen.

Có lẽ thừa kế bài học của Vim, một số editor mới ra đời đã sử dụng một ngôn ngữ script phổ biến nào đó như giao diện lập trình tùy biến. JEdit sử dụng một ngôn ngữ tựa Java. Textadept dùng Lua.

Trước khi làm quen với Vim, tôi không tin rằng có chuyện editor hiệu quả hơn IDE. Nhưng thực tế đã chứng minh tôi không những hiệu quả hơn mà còn thoải mái tinh thần hơn khi làm việc trên Vim + Shell, so với Visual Studio + Visual Assist X, hay NetBeans, hay Eclipse. Và như tôi đã nói, dù sao bạn cũng nên đầu tư tìm hiểu editor vì có những thao tác nhất định mà IDE tỏ ra không phù hợp.

Nếu bạn là một fan của Notepad++ hay UltraEdit thì cũng được thôi, nhưng hãy dành thời gian tìm hiểu các editor khác trước khi đưa ra kết luận cuối cùng.

Thay lời kết

Có thể coi editor là công cụ gần gũi nhất với lập trình viên. Nếu bạn vẫn luôn dùng một tool nhất định mà chưa từng bỏ thời gian để thử qua các IDEs và power editors khác thì đây chính là lúc nên làm việc đó. Sự đầu tư vào editor ảnh hưởng trực tiếp đến hiệu quả công việc của bạn. Một editor không phù hợp có thể làm gia tăng khả năng stress, gây đau đầu, và làm giảm tinh thần làm việc. Thỉnh thoảng thay đổi editor cũng có thể sẽ đem lại cho bạn cảm giác mới lạ và hấp dẫn hơn khi lập trình.

Tại sao nên học Haskell?

2009-07-24T16:07:00.017+07:00

Dù bạn là một system programmer làm việc chủ yếu với C/C++, một web programmer C#/ASP.NET hay PHP, một "enterprise programmer" (dân Java thích dùng những từ hổ báo kiểu thế này) với giải pháp Struts/Hibernate/Spring hay GWT, một client-side developer với CSS/Javascript/JQuery ... tôi cũng dám khẳng định, bạn sẽ nhận thấy giá trị của việc tìm hiểu Haskell là lớn hơn thời gian và công sức bỏ ra cho nó.

Coders chúng ta luôn biết tự search tài liệu và tự tìm tòi. Tuy vậy, tôi viết bài viết này với hy vọng tiết kiệm thời gian cho bạn bằng cách chọn lọc và đề xuất phương pháp tối ưu nhất thông qua kinh nghiệm của bản thân. Cho dù trình Haskell của tôi còn thấp vì thời gian tiếp cận không lâu, nhưng cũng chính vì thế mà tôi còn nhớ khá rõ quá trình tìm hiểu của mình, qua đó dễ dàng chia sẻ với các bạn.

Có quá nhiều công nghệ trong ngành của chúng ta đến nỗi không một ai đủ khả năng tìm hiểu hết. Do đó, để bắt kịp với tiến độ của ngành, chúng ta buộc phải biết cách lướt qua và chọn lọc: lướt qua để có cái nhìn tổng quát về bức tranh toàn cảnh, chọn lọc để xác định mảnh nào trong bức tranh đó mình cần phải đầu tư thời gian.

Hệ thống tiêu chuẩn chọn lọc của những người khác nhau là khác nhau. Đối với một coder tự do như tôi, tôi chọn lọc bằng cách dự đoán về khả năng mà một công nghệ có thể thay đổi cách tư duy của mình. Tuy nhiên trong quá trình tiếp cận Haskell, tôi nhận định, ngôn ngữ này sẽ tỏ ra hữu ích cho đa số coders chúng ta vì những nguyên nhân sau:

Haskell là purely functional programming language

Khi một ngôn ngữ hay một công nghệ nào đó đưa ra một phương pháp lập trình hoàn toàn mới, khả năng cao là nó đáng để tìm hiểu. Gần 20 năm trước, C++ đáng để tìm hiểu so với C bởi lẽ C++ đã chỉ ra thế nào là OOP. 20 năm sau, C++ vẫn đáng để tìm hiểu so với Java khi lúc này C++ lại chỉ ra thể nào là static polymorphism (C++ template) thay vì dynamic polymorphism (Java Generic) ;)

Một ngôn ngữ cũng sẽ trở nên quan trọng nếu nó làm tiền đề cho việc phát minh ra những design patterns mới. Xét theo tiêu chí này, Java cũng đã từng là một ngôn ngữ quan trọng khi có khá nhiều design patterns bắt nguồn từ nó, đơn cử như dependency injection của Martin Fowler.

Gần đây, xu hướng áp dụng các kỹ thuật functional programming (FP) đang tái xuất hiện trong giới lập trình, mà tiêu biểu là sự ra đời của Scala. Scala có thể xem như một sự kết hợp giữa Java và các kỹ thuật lập trình được ưu chuộng nhất hiện nay, trong đó bao gồm những phát kiến mới của các ngôn ngữ động như Python và Ruby, cũng như rất nhiều ý tưởng khác lấy từ FP.

Đối với tôi, Scala không hẳn là một ngôn ngữ được chọn lọc - nó quá cồng kềnh và chưa đủ sâu sắc, không khác là mấy so với các web frameworks của Java hiện nay. Thế nhưng sự ra đời của nó đã cho thấy FP đang trở lại và chiếm ưu thế trong xu hướng phát triển của ngành lập trình. Và mặc dù một tập hợp nhỏ các kỹ thuật FP đã được tích hợp trong không ít các ngôn ngữ khác nhau như Python, Ruby, Scala, nhưng sẽ tập trung hơn nếu ta tiếp cận với FP thông qua 1 ngôn ngữ thuần FP - Haskell là 1 ngôn ngữ như thế.

Haskell có syntax đẹp nhất

Ta định nghĩa hàm sum để tính tổng các phần tử trong 1 list như sau trong Haskell:

sum [] = 0
sum (x:xs) = x + sum xs

Tôi thích sử dụng những ví dụ đơn giản như thế này để đánh giá độ súc tích và độ sáng sủa trong cú pháp của một ngôn ngữ mới. Tuy Common Lisp hay Scheme đều là FP, nhưng cá nhân tôi thực sự có cảm tình với syntax của Haskell. Theo tôi, đó là một hệ thống syntax được thiết kế rất khoa học để cân bằng giữa độ dễ hiểu, độ ngắn gọn, và khả năng mở rộng trong ứng dụng lớn.

Haskell đang trở thành xu thế

Việc có ngày càng nhiều người sử dụng Haskell có nghĩa là nó sẽ còn phát triển để thỏa mãn nhu cầu của số đông và compiler của nó sẽ sinh code ngày một tốt hơn để đáp ứng những đòi hỏi về performance trong các ứng dụng thực tế.

Nhớ lại điều gì đã xảy ra với Ruby, cho dù bản thân ngôn ngữ Ruby có hay ho đến đâu nhưng nếu không có sự tồn tại của Rail thì rất có khả năng nó sẽ mãi mãi chỉ là một "toy language" - một ngôn ngữ đồ chơi chỉ dùng để giải trí và không được áp dụng trong công nghiệp.

Cho đến nay, Haskell đã vượt qua ngưỡng cửa "toy language" và đã được sử dụng để implement những ứng dụng nghiêm túc nhất, từ web applications cho đến operating systems.

Tốc độ lớn mạnh của Haskell là rất đáng kinh ngạc và điều đáng chú ý là nó không hề được marketing rầm rộ như Java khi xưa. Còn nhớ cách đây 5-10 năm, đã có ngày càng nhiều người sử dụng Java vì sự xuất hiện của hàng loạt các vị trí tuyển dụng Java programmers (Sun -> các công ty liên kết với Sun -> rồi lan tỏa dần), sau đó là việc áp dụng Java như một bộ môn trong giảng dạy, cùng với hàng loạt tools mới có vẻ cool viết trên và viết cho Java (Eclipse, NetBeans, IDEA), cũng như rất nhiều các kênh tin tức và blogs giải thích tại sao họ lại yêu Java đến thế. Đối với Haskell, người ta tìm hiểu và sử dụng đơn giản chỉ vì họ yêu thích nó.

Tôi có một châm ngôn: mỗi khi chán lập trình, hãy học một ngôn ngữ mới. Trong bài tiếp theo, tôi sẽ tiếp tục chia sẻ với các bạn quá trình tìm hiểu ngôn ngữ vô cùng mới mẻ và thú vị này :)