How to start learning programming?

In "Teach Yourself Programming in Ten Years" Peter Norvig revealed a recipe to be successful in programming. Here are some points:

• Get interested in programming, and do some because it is fun. Make sure that it keeps being enough fun so that you will be willing to put in ten years.
• Learn at least a half dozen programming languages...
  
• Remember that there is a "computer" in "computer science"... (or know your computer well)

I based on those points to give advices in QA style and create a list of recommended materials for a newbie who want to start learning programming (as much free materials as possible). Feel free to ask me if you need more information :)

Q: I don't know about programming. What programming language I should start with?

A: Start with a dynamic programming language (Ruby, JavaScript, Python, Perl ...) because it's easier to start and more fun than static type languages (C/C++, Java). You don't need to comply your code in-order to run program. And only with dynamic programming languages, you can interact with program via a command line tool.

Q: Which dynamic programming language should I choose?

A: For me, I prefer Ruby and JavaScript because I know them very well. I will recommend some excellent materials for learn both Ruby and JavaScript. Most of them are free.

Ruby

• why's (poignant) guide to Ruby: very funny, enjoyable but complete and insightful
  
• Humble Little Ruby Book
• The Little Book of Ruby: Learn by examples
  
• Programming Ruby (free access for 1st edition): Use as a reference book

You should learn from Ruby Object Oriented Programming (not Class Oriented :) and Meta-Programming.

JavaScript

• Excellent Video: Douglas Crockford, "The JavaScript Programming Language"
  
• Excellent Video: Douglas Crockford, "Advanced JavaScript"
• Eloquent Javascript: Small and nice for beginners. Code can run directly from links in the books (because JavaScript is the language of all web browsers)
• JavaScript Definitive Guide (free access for 2nd edition: not sure about copyright!): Use as a reference book

You should learn from JavaScript functional style and prototype-based object oriented.

Q: What next?

A: C/C++ and Erlang.

• C is today "assembly language". Most of computing systems is built in C: operation systems, database systems, core libraries for servers, desktops, mobile phones and embedded devices. I forgot to mention that, Ruby interpreters, Java virtual machine, JavaScript engines are all implemented in C/C++. So if you want to know the system well, want improve performance and utilize full power of systems. You must learn C.
  
• C++: To learn Object-Oriented Programming, Template Meta-Programming, Generic Data Structure and Algorithms in STL (Standard Template Libarary)
• Erlang: The world is concurrent. Now most of us use desktop or laptop with at least two cores. If 5 or 10 years, our machines will have 8, 16, 32, 64 or event 1028 cores. Sequential programming don't help to utilize their power. In this case, Erlang will help. You also learn about Functional Programming when using Erlang.
  

C/C++ books

• The C Programming Language
• Thinking in C++, vol 1 & vol 2: Very good and free
  
• The C++ Programming Language
  
• Effective C++: 50 Specific Ways to Improve Your Programs and Design

Erlang materials

• Programming Erlang: Software for a Concurrent World
• An Erlang course
• Concurrent Programming in Erlang (part 1 is free)

Q: Why not Java?

A: Because I don't use Java much in my programming career.

Q: What to read if I want to learn more about "science" in "computer science" that benefit programming directly?

A: I encourage you to read following excellent books:

• Concepts, Techniques, and Models of Computer Programming (can download draft version): will teach you all the concepts and paradigms of programming: stateless, statefull, concurrent, object-oriented ....
  
• Elements of Programming: Math foundation for programming
  

• Notes on Programming: same author and will be replaced by Elements of programming but easier and more enjoy to read. (more details here)
  

Above all, the most important thing is: "Before you start learning programming, make sure that you love it and it brings you a lot of fun."

English-Vietnamese Translation Service (1)

For me, dict.vn is the first step to build a web service that help Vietnamese people translating English documents FASTER and EASIER.

The original idea is presented at 05/05/2008, when I formed a group of three programmers to start the journey:
Small Team, Big Success
view presentation (tags: web service machine translation)

After several months, learning web development by working together at weekend, we released dict.vn. Here is a shameless advertisement:

"So many dictionary applications! Is it enough? Is dict.vn outstanding? What makes it different? Well, we believe in KISS (Keep It Simple, Stupid). Instead of adding as much languages as possible, we concentrate on English and Vietnamese. Our apps will be the bridge between two languages to help Vietnamese people learn, understand and play with English joyfully.

Instead of going for features races, we concentrate on information access and present it as convenient as possible. Why do you have to select dictionary types, turn on/off Vietnamese input method before you enter any word to look-up? Why you have to look though a lot of examples and idioms before you found the meanings you want to? Can you just double mouse click on the word you want to look-up instead of typing?

With dict.vn, you just type or click and get the results. No options, no noisy information, friendly and customizable user interface."


Let compare interfaces of Baamboo Tra từ and vdict.com with dict.vn, you will see the different:



No difference between baamboo and vdict




dict.vn is different

Stepanov Programming Principle

(from Note on Programming, 2006 book)

I found Stepanov 's book (he is the father of Standard Template Library) while searching for material to enhance my C++ coding skill. You can find a lot of his love for programming in his writing. Here is an extraction: "Programming is a wonderful activity that goes well beyond the range of what a single programmer can experience in a life time".

He said that "The book does not present scholarly consensus. It present my personal opinions... The book does not attempt to solve complicated problems. It will attempt to solve very simple problems which most people find trivial: minimum, maximum, linear search and swap. These problem are not however simple as they seem. I have been forced to go back and revisit my view of them many times."

He learn from his experience that we should solve simple problems carefully, and master them in order to solve complicated ones. He said "I do understand that most people have to design system somewhat more complex than maximum and minimum. But I urge them to consider the following: unless they can design a three line program well, why would they be able to design a hundred thousand line program".

So, before you coding, you should read Stepanov Programming Principle:

• The code should be partitioned into functions
• Every function should be at most 20 lines of code
• Function shouldn't depend on the global state but only on the arguments
• Every function is either general or app specific. Where general function is useful for other apps
• Every function that could be made general should be made general
• The interface to every function should be documented
• The global state should be documented by describing both semantics of individual variable and the global invariant

By appling that principle. He got a nice result:

• The code didn't contain serious bugs
• 95% of the code was in general functions !

His conclusion:

• Decomposing an app into a collection of general purpose algorithm and data structure make it robust
• General code grow with the grow of app size

His believe:

• In most desktop apps, the non-general code should be well under 1%

You can read his whole book Note on Programming, 2006 (free) he used to teach programming at Adobe. It's not about C++ and STL. It's about what his learn from his programming career.

Extend Thinking Sphinx to support SPH_SORT_EXPR mode

Thinking Sphinx is a Rails plugin that integrate SphinxSearch with Rails in an elegant way. Recently, I need to use SPH_SORT_EXPR mode of SphinxSearch in a Rails app but Thinking Sphinx don't support it. I think the reason why Thinking Sphinx don't support all SphinxSearch modes is that Pat Allan want to keep the plugin simple and easy to use so he leave advanced modes and configs out (some of them are SPH_SORT_EXPR mode, stopwords, wordforms, and exceptions configs).

Here is my code that extend ThinkingSphinx::Search class to support SPH_SORT_EXPR mode via :sort_expr option.

Feel free to tweak the code at RefactorMyCode.com

module ThinkingSphinx
class Search
 class << self
   alias_method :original_set_sort_options!, :set_sort_options!

   def set_sort_options!(client, options)
     expr = options[:sort_expr]
     if expr.nil?
       original_set_sort_options!(client, options)
     else
       client.sort_mode = :expr
       client.sort_by = expr
     end
   end
 end # class << self
end # Search
end # ThinkingSphinx

Usage: Model.search("search string", :sort_expr => "sort expression")

Find out more about my Thinking Sphinx's bug fixes and extenstions here:
http://github.com/tiendung/thinking-sphinx/wikis

Và tôi cũng yêu em

Tặng cún yêu bài hát này.
Chúc cún một tuần mới thật vui...

No complaining week

The idea belongs to my friend, Dinh Hai. He is the only man I know that can keep the smile on his face 24/7. Once time I asked him "Hai, how can you smile in every situation?". He answered "very simple, all you need is practicing". He was right. I has practiced "SMILE in every situations" for more than two month. It's a magic. I feel happy every time I smile and it help me to over come bad situations and make good situation even better :)

Come back to the main topic "No complaining week".

What to do?
Don't complain anybody or anything within a week.

Why?
* When you start complaining. You are accept the situation and don't want to change it.
* When you complaining, you make everybody around feel bad.
* When you complaining, everybody don't find you trusty and lovely.

What can I do instead of complaining?
Instead of spend time complaining people and things. Concentrate on CONTRIBUTION:
* What can I do to make the situation better?
* What can I help to solve the problem?
* How can I help to make everybody feel better?

How to do it?
* Every time you want to complain, try to close your mouth and start smiling and breathe deeply. You will be calm.
* Ask your friends to remind you this is "no complaining week" when they see you start complaining.

If you think it a good idea. Join us!

Không có sự lựa chọn thứ hai

(sưu tầm)

Học trò của Socrates hỏi ông bản chất đích thực của thời gian là gì. Socrates liền đưa họ đến một rừng cây, sau đó ông dặn “Các em đi theo các hàng cây, từ đầu bên này đến đầu bên kia, các em sẽ hái một trái cây mà các em cho rằng to nhất và ngon nhất. Các em không được đi vòng lại, không được lựa chọn lần thứ hai”. Các học trò của Socrates xuất phát. Họ rất cẩn thận để lựa chọn trái cây. Khi họ đến được đầu bên kia của khu rừng thì Socrates đã đứng đó chờ họ.

Socrates hỏi “Các trò đã chọn được trái cây vừa ý mình chưa?”.

“Thưa thầy, thầy cho em lựa lại lần nữa đi!”, một học trò nói. Anh ta nói tiếp “Khi mới bước vào khu rừng, em nhìn thấy một trái cây vừa to lại vừa ngon, nhưng em lại muốn tìm một trái cây khác to và ngon hơn. Khi đến đầu bên kia của khu rừng, em mới nhận ra rằng trái cây mà em nhìn thấy đầu tiên là to và ngon nhất”. Những học trò khác cũng xin Socrates cho họ lựa chọn lại lần nữa. Socrates liền lắc đầu: “Các trò của ta ơi, sẽ không có lần lựa chọn thứ hai đâu, đời người cũng giống thế”.

Lời bình:

Thượng đế không bao giờ để con người có lần lựa chọn thứ hai, đó là bản chất đích thực của đời người đồng thời cũng là bản chất đích thực của thời gian.

Cuộc đời của con người sẽ không có cơ hội bắt đầu lại từ đầu, vì thế Thượng đế rất công bằng với chúng ta. Trước khi lựa chọn phải suy nghĩ cẩn thận và thấu đáo; sau khi lựa chọn chỉ có thể nuối tiếc hoặc gắng sức mình chứ không có cơ hội quay trở lại.

Chúng ta thường nghe những lời kêu ca phàn nàn như: “Sớm biết trước là như vây..” “Lúc đó nếu làm như thế này thì hay biết mấy”.. Đừng nên hối hận, phàn nàn những lựa chọn trước kia, hãy tích cực chuẩn bị tốt cho những lần lựa chọn trong tương lai

Tại sao Tesla không thành công như Edison?

(lược dịch từ The Search)

“Nếu Edison cần tìm một cái kim trong một đống cỏ khô, ông ta sẽ bắt đầu ngay với sự cần cù của một con ong, kiểm tra từng cọng rơm một cho đến khi ông ta tìm thấy cái cần tìm ..
Tôi thấy rất tiếc khi chứng kiến chuyện đó bởi vì chỉ cần một chút lý thuyết và tính toán sẽ tiết kiệm cho Edison 90% công lao động”

– Nikola Tesla,
New York Times, 1931

Tesla là một thiên tài vĩ đại, ông phám khá và phát triển nền tảng của một loạt các phát minh đột phá, từ truyền thông không dây và tia x-quang cho tới pin mặt trời và cả hệ thống đường dây điện.

Tesla làm việc cho Edison, cạnh tranh với Edison suốt sự nghiệp của ông. Tuy vậy, dù Tesla có thông minh thiên tài đến cỡ nào và các phát minh của ông có thể thay đổi thế giới đến đâu đi chăng nữa ông ta chưa bao giờ có được tiếng tăm hoặc vận may xứng đáng với những nỗ lực ông đã bỏ ra.

Lý do là, suốt cuộc đời mình, Tesla luôn phải cố gắng duy trì những nghiên cứu của ông. Tesla không thể thương mại hóa những phát minh của mình. Đó là một câu chuyện buồn. Tesla là một nhà phát minh vĩ đại nhưng ông không hoàn chỉnh phát minh của mình đến độ hoàn hảo cần thiết.

Ngược lại Edison có độ kiên trì không ai bì nổi. Ông sẵn sàng chấp nhận hàng ngàn lần thử nghiệm thất bại cho tới khi làm được chiếc bóng đèn điện đầu tiên. Tương tự như Edison, nếu bạn phân tích rất nhiều những người nổi tiếng và thành công bạn sẽ đi đến một kết luận chung là:
Tính BỀN BỈ, sự tập trung nỗ lực và có một mục đích xác định là nguồn gốc dẫn tới sự thành công.

Bài học rút ra là. Có thể bạn không thông minh bằng người khác, bạn không mạnh nhất, nhanh nhất nhưng bạn có tính bền bỉ, sự tập trung và có mục đích xác định, bạn sẽ là người về đích. (Giống chuyện thỏ và rùa ghê, nếu so Edison với rùa thì có quá đáng ko nhỉ :))

How I became a web developer

A year ago I heard about Web 2.0 term. What is it? Why people talk a lot about it? Then started read more and more about it. I started with a presentation on slideshare.com.

(Can't find exact the slide but this one is also good and have more information)

Web20v54

view presentation (tags: web 2.0 yourdon blog wiki)

I was excited about beautiful and convenient web apps. Anybody can use them, just open a browser and type in an url. That all you need to start an web app (no installation, no upgrading, ....) Then I learned how to create a web apps and found Rails. At that time there was only around 5 good book about Ruby and Rails (now I think the number is 50 :). Read Pragmatic Programmer to learn how to be better programmer day after day. Then I found Getting Real, an excellent collection of advices for small team who want to build next great startups. Here are my sticky notes summarized what I learn from Web 2.0 and startups one year ago :)



And now, I'm proud to be a Web Developer at Spiragram. A small but strong Ruby on Rails shop in Singapore. We are one of the only 3 software companies in town that coding Ruby for food. We are the man behind:

hboasia.com: Brings the best of Hollywood to Asia
shouldi.com: Instant Social Advice Network
a-star.edu.sg: Singapore Agent for Science, Technology and Research

And we are rushing to finish a startup. Will be release soon :)

Got my first vote on RefactorMyCode :)

RefactorMyCode.com is a quite fun place for developers. I found it yesterday morning and can't help playing with code there. It is a huge playground for every programming language: Ruby, PHP, JavaScript, Java, C/C++, C#, VB, Python, Perl, LISP, Erlang and even Bash.

My favorite is JavaScript. It's a dynamic, functional, prototype-base OO programming language. JavaScript is the language that teach me functional programming. I use Firefox, my favorite browser, combine with Firebug plugin to code and debug.

I got first vote for this refactor. It helps to increase my rank from #96 to #23.

If you have some freetime. Let visit RefactorMyCode.com, refactor other people code or post the code you don't know how to deal with there. People will help to improve it. Fast and Fun :))

Code Monkey

Hôm trước down bài Code Monkey trên Musical Geek Friday về nghe. Thế là cả nhà gán luôn cho biệt danh mới Code Monkey :)) Chết cái tội hay ăn chuối.

Có bản video trên YouTube khá nhộn:


Còn đây là Code Kitty nhà tớ, mê ngủ và mê Whiskas. Thêm tật xấu ngủ xong không bao giờ gấp chăn ...

Image Processing & Computer Vision for Ruby

Google the title will show two libs: Camellia and HornetsEyes both of them have are built in C/C++ and have complete Ruby interface.

Camellia 2.7.0 gem installation fail on Leopard. Then I compiled Camellia 2.7.0 from source code and install camellia-2.5.10 gem follow the guide here. Luckily, they can work together.

HornetsEyes require a lot of libs in order to build (Qt4, Boost, ImageMagick...). I failed to install Boost then I stopped.

When compared example code, I found Camellia is more friendly and easy to use. Let see
Camellia examples and one HornetsEyes example. HornetsEyes follows Class Oriented style (often found in C++/Java) in Ruby cloth.

I voted for Camellia: Smaller and Easier to use

Ruby in the dark ages

Here I found a funny note:
"Brian has been programming with Ruby since BR (before-Rails), which means practically since the dark ages. He has worked with several companies doing web development with Rails. In December 2006 he began contributing to Rubinius, launching the effort to write executable specs for Ruby. He is now employed by Engine Yard to work full-time on Rubinius."

Have you practice Ruby in since the dark ages?

Rubinius is an awesome and unique project. I will create a posting about it :)

How to work better

I will put "10 SMILE" to the first place. It always work even in case other methods fail :)

Lập trình viên giỏi và đầu bếp giỏi

(Dịch từ http://amix.dk/blog/viewEntry/19328)

Một người đầu bếp giỏi dùng những nguyên liệu cơ bản nhất để tạo ra một món ăn ngon. Một người đầu bếp tồi cho dù có được những nguyên liệu tốt nhất vẫn tạo ra món ăn tồi. Cũng có những đầu bếp tạo ra những món ăn quá cầu kỳ (ví dụ như dùng quá nhiều nguyên liệu) hoặc có đầu bếp không chú ý tới vệ sinh và không trình bày món ăn sao cho đẹp mắt nhưng lại rất giỏi về việc phối hợp các nguyên liệu và gia vị.

Một vài mô tả về đầu bếp giỏi:
* Thức ăn của họ rất ngon
* Họ có thể làm đương đầu tốt với deadline và stress
* Thức ăn của họ được trình bày đẹp
* Món ăn đơn giản mà vẫn ngon

Khi xem chương trình nấu ăn trên truyền hình, bạn sẽ thấy có sự giống nhau giữa đầu bếp và lập trình viên. Lập trình viên dùng những nguyên liệu cơ bản (ngôn ngữ, công cụ, thư viện) và tạo ra chương trình. Sau đây là một vài ví dụ về sự tương đồng:
* Món ăn rất ngon nhưng trình bày kém => Chương trình chạy tốt nhưng việc thực thi rất tệ
* Nguyên liệu làm nên món ăn không tốt => Ngôn ngữ / thư viện làm nên chương trình dở tệ
* Người đầu bếp sử dụng 20 nguyên liệu cho một món ăn mà lẽ ra chỉ cần 4 nguyên liệu => Lập trình viên viết một phần chương trình mà nhẽ ra có thể dùng thư viện
* Người đầu bếp bỏ quá nhiều thời gian vào việc trình bày món ăn và quá ít thời gian vào việc nấu ăn => Lập trình viên bỏ quá nhiều thời gian vào việc làm cho code dễ nhìn và quá ít thời gian vào việc thực thi tính năng

Sự tương đồng này có thể nhận thấy ở một số phần mềm nổi tiếng:
* Facebook: Dùng những nguyên liệu cơ bản nhất (PHP+MySQL) và scale ứng dụng để phục vụ hàng triệu người dùng. Họ là những đầu bếp tài năng nhưng nguyên liệu của họ dở tệ.
* Universal feed parser: Tạo bởi Mark Pilgrim (nhân viên của Google). Phần mềm rất tốt này chỉ có 1 file với khoảng 3000 dòng lệnh. Đây là một ví dụ của một đầu bếp tài năng nhưng có những thói quen không tốt và trình bày không đẹp
* Django: Code, tài liệu và trình bày đều đẹp và đáng yêu

Để trở nên giỏi hơn nữa, bạn nên học tập theo cách những lập trình viên hàng đầu làm việc:
* Họ thực thi những chương trình đơn giản nhất có thể và không thể đơn giản hơn được nữa
* Họ sử dụng idioms (của ngôn ngữ lập trình) một cách thành thạo
* Họ viết code có tính nhất quán cao (ví dụ như cách đặt tên biến và hàm)
* Họ tổ chức chương trình rất tốt (không nhét tất cả vào một file)
* Họ bổ xung comments khi cần thiết
* Họ kết thúc công việc đúng hạn
* Họ tạo ra những chương trình mà các thành phần có sự dính kết và cao nhưng ít phụ thuộc vào nhau

Refactoring

What is refactoring?

"Refactoring is the art of safely improving the design of existing code. The purpose of refactoring is to make software easier to understand and modify".

(Refactoring, Martin Fowler, 1999)

"Rewriting, reworking and rearchitecting code is collectively know as refactoring. Refactoring your code (moving functions around and updating early decisions) is really an exercise of PAIN MANAGEMENT. Changing source code around can be pretty painful. Let face it! "

(The Pragmatic Programmer, Dave and Thomas, 1999)

Refactor early, refactor often

• At it's heart, refactoring is redesign.
• "Don't live with Broken windows".
• Don't live with bad design, wrong decision, poor code ...

(The Pragmatic Programmer, Dave and Thomas, 1999)

Why we need to do refactoring?

Increasing code value

• A significant fraction of our valuation is the state of our code base
• A low quality code base is a liability
• Microview: coding convention
• Macroview: program architecture
• Both microview and macroview are equal important

(YUI Theater — Douglas Crockford: “Quality” )

Paying off code and design bills

"If programmers got paid to remove code from software instead of writing new code, software would be a whole better place".

(Nicholas Negroponte, MIT, OLPC project)

Software development is like gardening, we need to take care of it everyday

"Rather than building construction, software is more like GARDENING. It's more organic than concrete. We constantly monitor the health of the garden and make adjustments as needed. Business people are comfortable with the metaphor of building construction but we're not building skyscrapers - we aren't constrained by the boundaries of physics and the real world. The gardening metaphor is much closer to the realities of software development".

(The Pragmatic Programmer, Dave and Thomas, 1999)

Refactor to make code more maintainable

maintaining code takes 80% of the time, writing new code only takes 20%. (YUI Theater — Nicholas Zakas: “Maintainable JavaScript”)

All Programming is Maintenance Programming

"we spend a large part of our time in maintenance mode, reorganizing and reexpressing the knowledge in our systems.Most people assume that maintenance begins when an application is released, that maintenance means fixing bugs and enhancing features. We think these people are wrong. Programmers are constantly in maintenance mode. Our understanding changes day by day. New requirements arrive as we're designing or coding. Perhaps the environment changes. Whatever the reason, maintenance is not a discrete activity, but a routine part of the entire development process."

(The Pragmatic Programmer, Dave and Thomas, 1999)

When should we refactor?

• Duplication (not DRY)
• Non-orthogonal Design
• Outdated knowledge
• Bad performance

(The Pragmatic Programmer, Dave and Thomas, 1999)

"When you have to add a feature to a program and the code is not structured in a convenient way to add the feature, first refactor the program, then add the feature"

(Refactoring, Martin Fowler, 1999)

Three strikes and you refactor

• The first time you do something, just do it
• The second time you wince at duplication, but you do the duplicate thing anyway
• The third time you do something similar, you refactor

(John Tobler's "Three Strikes" Refactoring Rule, see page 20 )

When should we stop refactoring?

Refactor to "good enough" software

• know when to stop
• we can't write perfect software

(The Pragmatic Programmer, Dave and Thomas, 1999)

Refactor to "maintainable code"

Maintainable code is:

• Understandable
• Intuitive (seem to be in a right place)
• Extendable
• Debuggable

(YUI Theater — Nicholas Zakas: “Maintainable JavaScript”)

How should we refactor?

"before start refactoring, check that you have a solid suite of tests. These tests must be self-checking. Change the program in small steps. If we make a mistake, it's easy to find th bug".

Refactoring cycle

• choose the worst smell
• select a refactoring that will address the smell
• apply the refactoring

(Refactoring, Martin Fowler, 1999)

Note: smell means "bad code", "select a refactoring" and "apply the refactoring" mean select and apply a refactoring method described in Martin Fowler's Refactoring book (extract method, move method, replace conditional with polymorphisms, .. for example).

The rhythm of refactoring

• test, small change,
• test, small change,
• test, small change,
• ......

(Refactoring, Martin Fowler, 1999)

What is bad smell?

I just list the most common ones

• Dupplication
• Long method
• Large class
• Long parameter list
• Devergent change
• .....

(Refactoring, Martin Fowler, 1999) Note: you can read refactoring book to find the approriate refactoring method for each bad smell. Read this nice lecture CMSC 433: Refactoring Still want to see more? Visit this link

Đứng lên coders :)

Lập trình viên ngồi quá nhiều. 8 đến 10 tiếng ở cơ quan, về nhà lại ngồi máy tính tiếp 2-3 tiếng. Một ngày có 24 tiếng mà ngồi đã mất nửa thời gian. Ha ha ha ....

Thế là tớ quyết định sẽ đứng và lập trình tại nhà. Lý do: ngồi nhiều hỏng cột sống, sau nay già khổ lắm :) May quá cái bàn làm việc có thanh ngang bên trên để máy in và các đồ lặt vặt. Tớ bỏ máy in xuống, dọn dẹp sạch sẽ. Sau đó mang em màn hình ra giường, hì hục lấy tốt vít lột hết chân tay rồi cột em cao lên như trong hình.

Còn một vấn đề nữa là làm sao để bàn phím và chuột đủ tầm cao khi đứng. Thử nghiệm 1: bỏ em case lên bàn, fail thảm thiết. Em case to quá, nặng quá, chắn hết chỗ, lại còn kêu phì phì nữa. Rồi mỗi lần nhét đĩa ra đĩa vô cũng bất tiện. Nhìn ngang ngó dọc phát hiện ra em loa Yamaha. Em này bị thằng cu tí (con mèo nhà tớ) cào cho tan nát cái màn chắn loa nên trông có vẻ đồng nát nhưng mà chất lượng ngon lắm đấy. Ông anh rể quý lắm mới để lại cho cơ mà :))

Em loa nằm ngang, để em bàn phím và em chuột trèo lên, thế là vừa tầm cao. Năm ngoái về thăm nhà, gạ mua được em bàn phím HHK của một anh đi Nhật về, ai dùng máy mình cũng cằn nhằn sao mà khó dùng thế, lại bé tí nữa chứ, ứ thích. Vậy mà bây h mới phát huy tác dụng đấy. Cái loa xinh xắn là thế mà cũng để vừa cả bàn phím và chuột. Ha ha ha ...

Đứng và dùng máy tính cũng có cái thú riêng của nó, thấy tự do và tập trung hơn. Tự do đung đưa và nhịp chân theo nhạc, tự do đi lại (không cần chuyển trạng thái từ ngồi sang đứng nữa). Tập trung hơn vì khi đứng phải thẳng lưng, mắt nhìn thẳng và chỉ tập trung vào màn hình. Khi ngồi có lúc nghẹo bên này, nghẹo bên kia, có lúc gác chân lên bàn nữa .. nói chung là ngả ngớn làm giảm sự tập trung. Ngoài ra đứng giúp tránh việc dùng máy tính quá lâu. Ối giời ơi, đứng được một tiếng là em chân em cẳng đã khóc không còn ra tiếng nữa. Phải giải lao 15, 20 phút cho hai em hồi sức.

Còn một tác dụng phụ nữa là tối ngủ rất ngon ... vì mệt. Ha ha ha ...

Brainstorming Guideline

From "Brainstorming Define & Guideline" in "The Myths of Innovation (2007 Oreilly)" book:

We have 3 things: FACTS, IDEAS, and SOLUTIONS

• Fact Finding: collecting data, information and research about "what is need to be done?"
• Idea Finding: the exploration of possibilities - free from as many constraints as possible and using ignoring facts as needed to find for ideas.
• Solution Finding: the development of promising ideas into solutions that can be applied to the world

Brainstorming Rules

• Produce as many ideas as possible (as many as you can, quantity over quality)
• Produce ideas as wild as possible (think different, don't follow convention)
• Build upon each other's ideas
• Avoid passing judgment