Thứ Tư, 11 tháng 2, 2009

Communicating with code

Some people can sell their ideas with a brilliant speech or a slick powerpoint presentation.

I can't.

Maybe that's why I'm skeptical of ideas that are sold via brilliant speeches and slick powerpoints. Or maybe it's because it's too easy to overlook the messy details, or to get caught up in details that seem very important, but aren't. I also get very bored by endless debate.

We did a lot of things wrong during the 2.5 years of pre-launch Gmail development, but one thing we did very right was to always have live code. The first version of Gmail was literally written in a day. It wasn't very impressive -- all I did was take the Google Groups (Usenet search) code (my previous project) and stuff my email into it -- but it was live and people could use it (to search my mail...). From that day until launch, every new feature went live immediately, and most new ideas were implemented as soon as possible. This resulted in a lot of churn -- we re-wrote the frontend about six times and the backend three times by launch -- but it meant that we had direct experience with all of the features. A lot of features seemed like great ideas, until we tried them. Other things seemed like they would be big problems or very confusing, but once they were in we forgot all about the theoretical problems.

The great thing about this process was that I didn't need to sell anyone on my ideas. I would just write the code, release the feature, and watch the response. Usually, everyone (including me) would end up hating whatever it was (especially my ideas), but we always learned something from the experience, and we were able to quickly move on to other ideas.

The most dramatic example of this process was the creation of content targeted ads (now known as "AdSense", or maybe "AdSense for Content"). The idea of targeting our keyword based ads to arbitrary content on the web had been floating around the company for a long time -- it was "obvious". However, it was also "obviously bad". Most people believed that it would require some kind of fancy artificial intelligence to understand the content well enough to target ads, and even if we had that, nobody would click on the ads. I thought they were probably right.

However, we needed a way for Gmail to make money, and Sanjeev Singh kept talking about using relevant ads, even though it was obviously a "bad idea". I remained skeptical, but thought that it might be a fun experiment, so I connected to that ads database (I assure you, random engineers can no longer do this!), copied out all of the ads+keywords, and did a little bit of sorting and filtering with some unix shell commands. I then hacked up the "adult content" classifier that Matt Cutts and I had written for safe-search, linked that into the Gmail prototype, and then loaded the ads data into the classifier. My change to the classifier (which completely broke its original functionality, but this was a separate code branch) changed it from classifying pages as "adult", to classifying them according to which ad was most relevant. The resulting ad was then displayed in a little box on our Gmail prototype ui. The code was rather ugly and hackish, but more importantly, it only took a few hours to write!

I then released the feature on our unsuspecting userbase of about 100 Googlers, and then went home and went to sleep. The response when I returned the next day was not what I would classify as "positive". Someone may have used the word "blasphemous". I liked the ads though -- they were amusing and often relevant. An email from someone looking for their lost sunglasses got an ad for new sunglasses. The lunch menu had an ad for balsamic vinegar.

More importantly, I wasn't the only one who found the ads surprisingly relevant. Suddenly, content targeted ads switched from being a lowest-priority project (unstaffed, will not do) to being a top priority project, an extremely talented team was formed to build the project, and within maybe six months a live beta was launched. Google's content targeted ads are now a big business with billions of dollars in revenue (I think).

Of course none of the code from my prototype ever made it near the real product (thankfully), but that code did something that fancy arguments couldn't do (at least not my fancy arguments), it showed that the idea and product had real potential.

The point of this story, I think, is that you should consider spending less time talking, and more time prototyping, especially if you're not very good at talking or powerpoint. Your code can be a very persuasive argument.

The other point is that it's important to make prototyping new ideas, especially bad ideas, as fast and easy as possible. This can be especially difficult as a product grows. It was easy for me to stuff random broken features into Gmail when there were only about 100 users and they all worked for Google, but it's not so simple when there are 100 million users.

Fortunately for Gmail, they've recently found a rather clever solution that enables the thousands of Google engineers to add new ui features: Gmail Labs. This is also where Google's "20% time" comes in -- if you want innovation, it's critical that people are able to work on ideas that are unapproved and generally thought to be stupid. The real value of "20%" is not the time, but rather the "license" it gives to work on things that "aren't important". (perhaps I should do a post on "20% time" at some point...)

One of the best ways to enable prototyping and innovation on an established product is though an API. Twitter is possibly the best example of how well this can work. There are thousands of different Twitter clients, with new ones being written every day, and I believe a majority of Twitter messages are entered though one of these third-party clients.

Public APIs enable everyone to experiment with new ideas and create new ways of using your product. This is incredibly powerful because no matter how brilliant you and your coworkers are, there are always going to be smarter people outside of your company.

At FriendFeed, we discovered that our API does more than enable great apps, it also reveals great app developers. Gary and Ben were both writing FriendFeed apps using our API before we hired them. When hiring, you don't have to guess which people are "smart and gets things done", you can simply observe it in the wild :)

In my previous post, I asked people to describe their "ideal FriendFeed". Since then, I've been thinking about ideas for my "ideal FriendFeed". Unfortunately, it's very difficult for me to know how much I like an idea based only on words or mockups -- I really need to try it out. So in the spirit of prototyping, I've used my spare time to write a simple FriendFeed interface that prototypes some of the things I've been thinking about. This interface isn't the "future of FriendFeed", it's just a collection of ideas, some that I like, and some that I don't. One thing that's kind of cool about it (from a prototyping perspective) is that it's written entirely in Javascript running in the web browser -- it's just a single web page that uses FriendFeed's JSON APIs to fetch data. This also means that it's relatively easy for other people to copy and change -- you don't even need a server!

Trích blog Paul Buchheit

------------------------------------------------------------------------------
Resume by TuanNM : có những ý tưởng dường như rất với vẩn, nhưng khi implemented lại rất tuyệt vời, ngược lại, cũng có những idea rất tuyệt vời cho đến khi bạn chạy thử nó. Hãy cố gắng implement your idea as soon as possible, đối với các innovation app, đừng quá câu nệ thiết kế ..., việc viết lại code là chuyện hết sức bình thường. Chính tôi đã phạm sai lầm này :(.

Thứ Tư, 4 tháng 2, 2009

Phương pháp học tập hiệu quả

Trong article này, tôi sẽ trình bày về những kinh nghiệm của mình trong việc tiếp cận một vấn đề cho hiệu quả, nhanh chóng nhất.

1. Xác định rõ ràng mình tìm hiểu vấn đề này để làm ji ?

Tuy cùng tìm hiểu một vấn đề, nhưng mỗi người có thể có những mục đích khác nhau, ví dụ :

- Tìm hiểu chỉ để biết rằng nó là ji, nó có tính năng abc ko ?

- Tìm hiểu để biết.

- Tìm hiểu để ứng dụng cho công việc.

- Tìm hiểu để trở thành một chuyên gia trong vấn đề đó.

- ...etc

Với mỗi loại mục đích sẽ có những phương pháp tiếp cận vấn đề khác nhau, và bạn phải ghi nhớ, đừng bao giờ quên mình tìm hiểu vấn đề đó để làm ji, nó sẽ giúp bạn loại bớt dc rất nhiều phần ko cần thiết.

Tuy nhiên, những gì tôi trình bày trong article này chủ yếu với mục đích tìm hiểu để ứng dụng, phát triển và để trở thành một cao thủ trong vấn đề đó.

2. Cố gắng tiếp cận Top-Down sớm nhất có thể.

Để tìm hiểu một vấn đề, chúng ta có 2 hướng tiếp cận Top-Down và Bottom-up, để dễ hình dung bạn có thể liên tưởng đến việc một cuốn sách, bạn tìm hiểu một vấn đề cũng tương đương việc bạn lĩnh hội dc nội dung, tư tưởng mà cuốn sách đó truyền đạt. Vậy thì cách tiếp cận Top-Down là bạn xem mục lục cuốn sách, lựa chọn phần nào đọc trước, phần nào đọc sau, phần nào đọc kỹ, phần nào đọc lướt, và phần nào ko cần đọc, bạn dừng đọc khi bạn đã hiểu đủ những gì cuốn sách đó muốn truyền đạt. Còn cách đọc Bottom-up là cách đọc từng trang, từng trang, tuần tự, sau đó bạn phải xâu chuỗi các thông tin lại với nhau để hiểu được những gì cuốn sách muốn truyền đạt. Ko khó khăn để thấy Top-down đem lại hiệu quả cao hơn rất nhiều, ko chỉ hiệu quả về mặt thời gian đọc, với Top-down bạn sẽ nhanh chóng xâu chuỗi các thông tin, hiểu dc bản chất vấn đề ngay cả khi chưa hiểu đủ vấn đề mà cuốn sách đó trình bày, thêm nữa bạn định vị dc mình đang ở đâu trong quá trình tìm hiểu nội dung cuốn sách.

Tuy nhiên, thực tế ko phải khi nào bạn cũng có ngay một cái “Mục lục” để tiếp cận Top-down, nhất là với những vấn đề hết sức mới mẻ với bạn, vậy thì việc đầu tiên là bạn hãy tìm cho mình một cái “Mục lục” sớm nhất có thể, và chi tiết cái mục lục đó dần dần.

Một cách tổng quát, bạn có thể tiếp cận vấn đề theo qui trình sau :

a. Việc đầu tiên khi tìm hiểu một vấn đề, bạn hãy bắt đầu từ những cái Top, những cái chung nhất. Nhìn chung, những câu hỏi chung nhất bạn cần phải trả lời khi bắt đầu tìm hiểu một vấn đề mới :

  • Định nghĩa của vấn đề ?
  • Nó ra đời phục vụ mục đích ji ?

Và có thể có thêm một số câu hỏi khác tùy thuộc vào mỗi trường hợp cụ thể. Bạn phải tự xác định, chẳng hạn “Nó dựa trên nền tảng ji ?”, “So sánh nó với xyz như thế nào ? (trong đó xyz là thứ có nhiều cái tương đồng về mục đích sử dụng với vấn đề đang tìm hiểu)”.

Có một số phương pháp giúp bạn có thể trả lời nhanh chóng vấn đề trên :

  • Search google với meta key “define”, ex : “define:SOA” (ko có dấu cách) => định nghĩa của SOA, trong đó SOA là tên của vấn đề đang tìm hiểu.
  • Tìm trang của Wikipedia nói về vấn đề đó, có thể search bằng google và wiki. Wikipedia là một trong những nguồn tốt nhất để nhanh chóng nắm dc overview của vấn đề.
  • Đọc FAQ (Frequently Asked Question) trên trang chủ của vấn đề mình đang tìm hiểu => là một sưu tập các câu hỏi cơ bản nhất, hay dc quan tâm nhất của user tới vấn đề đó.
  • Tìm trong Help của vấn đề trên tại chính trang chủ của nó.
  • ...etc

Chú ý, mục đích của bạn bây giờ tạm thời là trả lời các câu hỏi chung nhất mà bạn đã liệt kê ra, vậy thì bạn hãy làm thế nào để trả lời nó sớm nhất, xong là chuyển sang giai đoạn khác, tránh đọc sâu vào 1 tài liệu mất thời gian.

b. Hãy tập cách tìm kiếm, tìm các tài liệu cơ bản nhất, phù hợp với trình độ của bạn nhất để đọc. Trên thực tế, có rất rất nhiều các tài liệu khác nhau cùng diễn giải về một vấn đề. Trong hầu hết các trường hợp, cách làm khôn ngoan là hãy dành một khoảng thời gian nhất định để tìm kiếm hàng loạt các tài liệu, sau đó lướt qua từng tài liệu để đánh giá tài liệu nào phù hợp với trình độ mình nhất, trình bày dễ hiểu nhất, sắp xếp thứ tự ưu tiên từng tài liệu để đọc, và biết loại bỏ đi những tài liệu ko tốt, và cuối cùng là đọc các tài liệu theo thứ tự ưu tiên đó. Đó cũng chính là tiếp cận Top-Down, tránh việc cứ tìm thấy tài liệu nào là chúi mũi vào đọc hiểu luôn mà ko cố gắng tìm tiếp các tài liệu khác.

Cách tìm kiếm tài liệu cơ bản như sau :

  • Tìm kiếm tại help trên trang chủ của chính vấn đề đó.
  • Tìm kiếm trên các bài key của một số forum NỔI BẬT về vấn đề này. Thường các forum focus vào một vấn đề sẽ có những bài dạng basic tutorial, và trong đó họ cũng cung cấp nhiều references.
  • Đừng quên các tài liệu video, multimedia, slide => dễ hiểu, tính xúc tích cao. Với các loại tài liệu này có thể dùng slideshare để tìm slide, youtube để tìm video.
  • Bên cạnh Google, Torrent cũng là một nguồn tìm tài liệu rất tốt, nhiều trường hợp còn tốt hơn cả Google, đặc biệt với các tài liệu dạng video, hoặc các ebook ko free.
  • Nên biết rằng Google ko phải là SearchEngine tốt nhất cho mọi truy vấn, với mỗi loại tìm kiếm, có thể có những SE khác tốt hơn, bạn nên biết qua mấy ưu điểm của SE khác, như Delicious chẳng hạn. Cũng như vậy, để tìm kiếm ảnh, google image cũng ko phải là tốt nhất.
  • Tìm kiếm dựa trên các references của một tài liệu đã có, đặc biết đối với các bài báo khoa học, từ có rất nhiều references tới các tài liệu liên quan.

c. Sử dụng Mindjet(*) nhằm “lên mục lục”, bạn nên sử dụng một công cụ hỗ trợ để lên mục lục, xâu chuỗi các ý thu thập dc. Theo kiến thức và kinh nghiệm của mình, tôi cho là dùng Mindmap là lựa chọn tốt nhất, và Mindjet là tool hỗ trợ Mindmap tốt nhất thế giới hiện nay. Mindjet hỗ trợ cực kỳ hiệu quả ko chỉ việc lên mục lục, nhờ việc sắp xếp các thông tin theo cách tiếp cận thông tin của não người (Mindmap – bản đồ tư duy), nó giúp ta nhớ tốt hơn, dễ dàng tổng hợp các thông tin, và tìm ra bản chất vấn đề. Với kinh nghiệm sử dụng Mindjet khá lâu, nó cũng là một tool hỗ trợ ko thể thiếu trong công việc, tôi tin là với sự hỗ trợ của Mindjet, hiệu quả của việc tìm hiểu một vấn đề có thể lên ít nhất 200%.

3. Bắt đầu từ cái cơ bản, không ngừng cố gắng hiểu bản chất vấn đề sớm nhất

Khi tiếp cận một vấn đề, hãy đi từ cái cơ bản đến cái phức tạp, không ngừng cố gắng hiểu được bản chất vấn đề càng sớm càng tốt. Thực tế là ko cần thiết phải đọc hết cả cuốn sách bạn mới hiểu được bản chất của vấn đề cuốn sách đề cập, và ngược lại, ko phải khi nào bạn đã đọc hết cuốn sách rồi tức là bạn đã hiểu được bản chất những gì cuốn sách muốn nói.

Khi bạn đã hiểu được bản chất vấn đề, thì bạn đã đạt được một milestone quan trọng trong quá trình tìm hiểu vấn đề đó, khi đó bạn có thể suy đoán, suy diễn chi tiết hơn về vấn đế, có thể đánh giá phần nào là quan trọng cần tìm hiểu kỹ, phần nào là ko quan trọng có thể bỏ qua.

Tìm đọc các so sánh của vấn đề với những vấn đề khác có nhiều tương đồng về mục đích sử dụng để nhanh chóng hiểu dc bản chất vấn đề. Ngoài ra, bạn phải ko ngừng review, xâu chuỗi các thông tin trong quá trình, tạo ra một sự logic, nhằm tìm ra dc bản chất vấn đề.

4. Dành một thời gian đủ dài và tập trung cho MỘT vấn đề.

Nhiều nghiên cứu chứng minh là hãy dành một thời gian đủ dài và tập trung cho MỘT vấn đề sẽ đạt hiệu quả hơn khá nhiều là mỗi ngày dành 1 ít thời gian, đó là xét trên việc lượng kiến thức tiếp thu / tổng thời gian dùng để học. Tuy nhiên, điều này hoàn toàn khác với kiểu trước khi thi, thức đêm 2 hôm để học bài thì sẽ đạt hiệu quả hơn là học suốt quá trình học, học theo kiểu thuộc mà ko hiểu sẽ rất nhanh quên.

5. Không ngừng thực hành, kiểm thử nếu có thể

Học cần đi đôi với thực hành, thực hành luôn là một trong những cách tốt nhất để tìm hiểu một vấn đề, thực hành sẽ giúp bạn hiểu nhanh hơn, nhớ lâu hơn, và kết quả của những bài thực hành cũng giúp bạn hiểu bản chất nhanh hơn, hóa giải những ji bạn ko chắc chắn. Thực hành đặc biệt quan trọng nếu mục đích tìm hiểu của bạn là sử dụng được cái bạn đang tìm hiểu.

6. Ghi lại những đặc điểm key, những kinh nghiệm thú vị

Hãy tìm cách ghi lại ra đâu đó những đặc điểm key, những trick, những điểm mà mình thấy thú vị, những thông tin cần thiết nhưng khó nhớ ... về vấn đề mình đang tìm hiểu. Nó cần thiết cho việc ghi nhớ, xâu chuỗi các thông tin để tìm ra bản chất vấn đề, nếu như sau này có quên do bẵng đi một thời gian ko sử dụng thì các thông tin được ghi lại này sẽ giúp bạn nhớ lại nó cực nhanh. Việc ghi lại cũng cần đảm bảo tính tra cứu một cách khoa học, ví dụ blog cũng là một lựa chọn tốt. Đừng đánh giá thấp việc ghi lại, cũng đừng nghĩ rằng nó mất thời gian. Tôi đã từng nhiều lần tìm hiểu cách make run một chương trình java từ Console, đây là một thao tác ít dùng, khó nhớ, nhưng lại cần thiết. Việc note lại rất đơn giản, và nhanh chóng vậy mà tôi đã ko làm, kết quả cứ mỗi lần cần make-run một chương trình java lại search google, rồi thử cho đến một ngày tôi quyết định note “how to make run a java program” lại.

7. Liên tục cập nhật kiến thức

Một lĩnh vực cần tìm hiểu luôn luôn có rất nhiều thứ để biết, hơn nữa chúng luôn vận động => ko bao giờ bạn có thể biết tất cả về một vấn đ => nếu bạn ngừng cập nhật bạn sẽ nhanh chóng lỗi thời, và nếu bạn lỗi thời, bạn ko phải là một chuyên gia trong lĩnh vực đó.

Cách thức giữ cho mình update trong một lĩnh vực tốt nhất và hiệu quả nhất là hãy THAM GIA CỘNG ĐỒNG CÙNG CHUYÊN MÔN.

Khi bạn chưa thực sự tham gia vào cộng đồng cùng chuyên môn, bạn mãi mãi là ếch ngồi đáy giếng, khi bạn chưa thể xác định rank của mình trong cộng đồng chuyên môn, thì bạn đừng nói với người khác rằng tôi rất giỏi về vấn đề abc gì đó.

Việc tham gia cộng đồng chuyên môn có hai mức độ :

a. Thụ động : bạn liên tục cập nhật thông tin từ cộng đồng, hoặc các nguồn tin về chuyên môn, tuy nhiên bạn chỉ đóng vai trò đọc tin, và nắm bắt các thông tin, chứ ko đóng góp thêm vào các nguồn thông tin, tương tác với cộng đồng cùng chuyên môn là tương tác 1 chiều.

b. Chủ động : bạn ko chỉ đọc tin, mà bạn con tham gia tương tác trong cộng đồng chuyên môn, bổ sung thêm thông tin vào cộng đồng.

Đừng đợi đến khi nắm hết cơ bản rồi mới tham gia cộng đồng, bạn có thể làm thao tác đó ngay khi bắt đầu tìm hiểu vấn đề, và luôn duy trì update, chẳng hạn như :

  • Subscrire maillist để nhận tin, và có thể hỏi lúc nào cần thiết. Thường thì chúng ta sợ spam, nhưng Ymail và Gmail đều có filter, biết sử dụng chúng thì chúng ta sẽ ko ngại đăng kí maillist nữa. Thường trên trang chủ của vấn đề đó sẽ có maillist, tuy nhiên cũng có thêm một cách khác để tìm mail group của lĩnh vực liên quan, đó là sử dụng Google Group, để tìm các Gmail Group.

  • Sign up account forum. Cũng nên đánh giá qua xem forum đó có tốt ko, qua tần số bài viết mới, thời gian feedback có nhanh ko, rank alexa của forum ...etc. Nói chung là chúng ta nên tham gia forum tốt nhất về lĩnh vực đó, tham gia nhiều forum cùng loại hơi mất thời gian.

  • Tìm một số blog chuyên môn, lấy RSS của nó add vào Netvibes của bạn, hoặc iGoogle, hoặc Google Reader,... Việc sử dụng các công cụ đọc RSS sẽ tiết kiệm rất rất nhiều thời gian. Bạn có thể tìm blog dựa vào một số search engine chuyên search blog, ex : Google Blog, Technorati...

  • Lấy RSS của một số trang magazine chuyên môn, cho vào trình đọc RSS của bạn.

  • Tìm một số expert trong lĩnh vực đó, và follow họ nếu có thể (nhất là nếu họ dùng Twitter).

  • Tham gia group của một số mạng xã hội như, Facebook, Linkedin. Tuy nhiên, dường như tôi thấy các group này thiên về tương tác giữa các thành viên hơn là tập trung vào chuyên môn, tuy nhiên bạn có thể biết đến thêm những expert khác trong cùng lĩnh vực quan tâm.
  • Sẵn sàng hỏi khi cần thiết, bạn sẽ tiết kiệm dc khá nhiều thời gian, tuy nhiên, đừng nên hỏi những câu hỏi cơ bản quá, nhiều người đã hỏi rồi => khó chịu. Bởi vậy nên search qua trước, bằng Google, hoặc search trên forum đó, trong trường hợp forum đó ko hỗ trợ tính năng search, bạn có thể sử dụng metakey site của google, ex : site:muare.com máy chiếu => dùng để tìm “máy chiếu” trong forum muare.com. Ngoài ra hỏi trên Twitter cũng là một cách, nếu bạn bè của bạn cũng cùng nghiên cứu vấn đề này.

  • ...etc

8. Luôn ghi nhớ “lúc nào cũng có thể tìm được cách làm tốt hơn”

Luôn tồn tại những công cụ hỗ trợ học tập mà ta chưa biết tới, hãy luôn tự hỏi “có cách nào có thể làm tốt hơn hay ko ?”. Ngay cả với Mindmap, bạn muốn sử dụng hiệu quả Mindmap cũng ko phải dễ. Ngoài ra, khi nghiên cứu về trí nhớ, người ta có thể thống kê dc một số mẹo nhằm nhớ nhanh, nhớ lâu, hiểu nhanh hơn, chẳng hạn như :

  • Học kiều nhồi nhét sẽ ko đạt hiệu quả về mặt nhớ lâu.
  • HIỂU bản chất vấn đề thì sẽ nhớ lâu hơn.
  • Hãy tổ chức, cấu trúc hóa các thông tin tìm hiểu dc (Mindmap là công cụ khá lí tưởng).
  • Hãy liên kết, so sánh vấn đề ta đang tìm hiểu đến những kiến thức mà ta đã biết.
  • Hãy Visualize vấn đề của bạn lên => Mindmap là một trong những lựa chọn.
  • Dạy ai đó vấn đề này, hoặc viết review về nó => rất tốt cho việc xâu chuỗi các vấn đề để hiểu bản chất, phát hiện ra các lỗ hổng kiến thức.

… và rất nhiều nữa, những phương pháp mà tôi và bạn đều chưa biết tới.

* Mindjet : là công cụ dùng để vẽ Mindmap, nó ko free, tuy nhiên có thể sử dụng các lựa chọn free khác như Xmind, FreeMind. Theo tôi, Xmind tốt hơn Freemind.

Thứ Ba, 3 tháng 2, 2009

Các module, thủ tục có thể sử dụng trong nhiều dự án khác của GTID

Những module có thể tái sử dụng với những dự án khác nhau. Đây là nơi tổng hợp những module có tính tái sử dụng cao, có thể sử dụng trong nhiều dự án, chúng ta sẽ cập nhật theo thời gian, để các team khác biết, tránh thực hiện code lại những ji đã code và test rồi.
- Module phục vụ suggestion C# phía server và JS phía client(giống kiểu các SearchEngine trả về các gợi ý realtime khi ta đánh query), trả về danh sách string tương ứng với một đoạn string đầu vào. Module này đã dc viết khá tối ưu, với độ phức tạp hằng số, hoàn toàn có thể thích ứng với cả danh sách hàng triệu string mà ko vấn đề gì.

- Những thao tác phổ biến trên Array, List viết trên C#, viết dưới dạng template, có tính tái sử dụng cao, các dự án dùng C# khác sẽ ko phải code lại những hàm này :

  • Tìm kiếm nhị phân trên Array, List đã sắp xếp tăng dần rồi.
  • Hàm chèn một phần tử vào một danh sách đã sắp xếp mà vẫn bảo toàn tính sắp xếp của nó.
  • Hàm xác định vị trí để insert 1 phần tử vào một danh sách tăng dần.
  • ...

- Module xác định nước truy cập của user bằng C#, dùng khi ta muốn biết một user truy cập website của mình thuộc nước nào.

- Module quản lí tree, và forest với relation database, sử dụng giải thuật MPTT viết bằng C#, support các hầu hết thao tác cơ bản trên tree hay forest như tìm các tổ tiên, con cháu của 1 hoặc 1 nhóm node, thay đổi parent, xóa đi một node ... Giải thuật MPTT cho phép quản lí tree/forest có kích thước lớn với cơ sở dữ liệu quan hệ.

- Module counter, bộ đếm số người truy nhập trang web => có module sẵn rồi, ko phải code chức năng này.

- Module nhận feedback của người dùng, đã có sẵn, tích hợp với tool bugtracking, ko cần code module này trong mọi dự án bất kể ngôn ngữ hay platform, trừ khi chúng ta ko có trách nhiệm nhận feedback của user đối với dự án đó.

(tiếp tục cập nhật theo thời gian).

Chủ Nhật, 1 tháng 2, 2009

Sử dụng Netvibes để nâng cao hiệu quả công việc

Netvibes cũng là một dịch vụ Web2.0 rất phổ biến, luôn nằm trong danh sách những ứng dụng Web2.0 xuất sắc của năm trong 2-3 năm trở lại đây. Từ khi sử dụng nó, thật sự nó cải thiện hiệu quả đọc tin của mình lên rất rất nhiều, cũng là một dịch vụ 2.0 ko thể thiếu đối với mình. Netvibes là trang web đầu tiên được mở ra khi tôi bật trình duyệt, và nó cũng chỉ được đóng lại khi tôi tắt Firefox, thời gian Netvibes được mở chiếm > 95% thời gian tôi sử dụng laptop.
Netvibes sẽ thay đổi cách bạn lướt web, gia tăng hiệu quả đọc tin tức của bạn lên 10-30 lần, tiết kiệm rất nhiều thời gian hàng ngày bạn sử dụng để lướt web. Ngoài ra, Netvibes cũng là công cụ số một giúp bạn thường xuyên giữ mình update, giúp bạn có một tầm nhìn tốt hơn trong lĩnh vực bạn quan tâm.
Dưới đây là video hướng dẫn sử dụng Netvibes (các video đều có tiếng nhé).
1. Cách thức "lướt web" với Netvibes.


2. Cách để add một site quan tâm vào Netvibes với điều kiện trang đó hỗ trợ RSS, nói chung hiện ngay phần lớn các trang web thông dụng đều hỗ trợ RSS, bạn làm theo video hướng dẫn sau.


3. Bình thường thì để tạo một trang Netvibes cho riêng mình, bạn phải mất khoảng 3h đồng hồ, tuy nhiên mình đã share trang của mình tại http://netvibes.com/conquerorvn, bạn có thể làm theo hướng dẫn trong video để có một trang Netvibes của riêng mình trong vòng 40phút.


Chúc các bạn thành công.
Go Together In Development.