Mastering Programming

Dịch từ bài viết “Mastering Programming” của tác giả Kent Beck.

Qua nhiều năm quan sát những lập trình viên bậc thầy, tôi đã nhận thấy những mô thức chung trong quy trình làm việc của họ. Qua nhiều năm huấn luyện những lập trình viên ở mức thạo nghề, tôi đã nhận thấy sự thiếu vắng những mô thức đó. Tôi đã thấy sự khác biệt (mà) khởi đầu cho những mô thức đó, có thể tạo ra.

Đây là những cách thức mà những lập trình thu được hiệu quả tốt nhất có thể từ hơn 3 tỉ giây quý báu của họ ở trên trái đất này (ý nói là thời gian trong 1 năm – lời người dịch).
Bài luận này sẽ làm bạn sáng tỏ hơn về những điều đó. Một “công nhân thạo nghề” học cách giải quyết những vấn đề lớn hơn bằng cách cùng một lúc giải quyết nhiều vấn đề hơn. Một bậc thầy học cách giải quyết những vấn đề còn lớn hơn thế bằng cách giải quyết ít vấn đề hơn cùng một lúc. Các phần của lời khuyên này sẽ được chia nhỏ sao cho việc tích hợp những giải pháp riêng biệt sẽ là một vấn đề nhỏ hơn việc chỉ giải quyết chúng đồng thời.

Thời gian

  • Phân chia. Lấy một dự án lớn, cắt nó thành các phần nhỏ, và sắp xếp lại các phần sao cho phù hợp với hoàn cảnh. Tôi luôn có thể phân chia các dự án nhỏ hơn và luôn tìm thấy những cách thay đổi trật tự của các phần mà phù hợp với các nhu cầu khác nhau.
  • Một việc tại một thời điểm. Chúng ta tập trung vào tính hiệu quả đến mức chúng ta giảm số lượng số vòng phản hồi (feedback cycles) trong một nỗ lực để giảm tổng chi phí. Điều này dẫn đến những tình trạng gỡ lỗi phức tạp mà chi phí của nó có thể còn lớn hơn tổng phí về số vòng phản hồi mà chúng ta đã tránh.
  • Viết chương trình chạy được, chạy đúng, và chạy nhanh (Make it run, make it right, make it fast). (Ví dụ của một việc tại một thời điểm, phân chia công việc, và dễ dàng sửa đổi).
  • Những sửa đổi dễ dàng. Khi bạn phải đối mặt với một sự thay đổi phức tạp, đầu tiên hãy làm cho nó dễ đi (tôi cảnh báo rằng điều này có khó), sau đó thực hiện việc sửa đổi dễ (ví dụ: phân chia công việc, làm một việc tại một thời điểm, tập trung, và sự cô lập. Đây là một ví dụ của việc phân chia công việc.
  • Sự tập trung. Nếu bạn cần thay đổi một vài thành phần, đầu tiên hãy sắp xếp lại mã chương trình sao cho sự thay đổi chỉ cần xảy ra trong một thành phần.
  • Sự cô lập. Nếu bạn chỉ cần thay đổi một phần của một thành tố, hãy trích xuất thành tố đó ra để thay đổi trên toàn bộ thành tố con đó.
  • Quản lý các hệ thống cơ sở. Bắt đầu các dự án bằng việc so sánh với những hệ thống đã có. Điều này có thể chống lại thiên hướng muốn bắt đầu sửa chữa mọi thứ của chúng ta, nhưng khi bạn xem xét các hệ thống cơ sở, bạn sẽ thực sự biết liệu có đúng là bạn đang làm công việc sửa chữa những thứ hiện có không.

Học tập

  • Trước khi thực thi chương trình, dự đoán chính xác điều gì sẽ xảy ra.
  • Các giả thuyết cụ thể. Khi chương trình hoạt động không đúng, hãy minh định những gì bạn cho là sai trong chương trình trước khi thực hiện sự thay đổi. Nếu bạn có hai hay nhiều hơn các giả thuyết, hãy phân tích sự khác biệt giữa các giả thuyết đó.
  • Loại bỏ chi tiết không liên quan. Khi báo cáo một lỗi, hãy tìm những bước ngắn nhất để sinh lại lỗi đó. Khi cô lập một lỗi, hãy tìm những ví dụ (test case) ngắn nhất. Khi sử dụng một API mới, bắt đầu từ những ví dụ đơn giản nhất. “Tất cả những thứ này không thành vấn đề” là một giả thuyết quá mạnh và có khi là sai lầm.
    • Ví dụ, hãy xem một lỗi trên mobile, sinh lại nó với chương trình curl.
  • Đa quy mô. Di chuyển tự do giữa các quy mô (ví dụ khi thực thi trên dữ liệu nhỏ sang thực thi trên dữ liệu lớn — cách hiểu của người dịch). Có thể đây là một vấn đề thiết kế, không phải là vấn đề kiểm thử. Có thể vấn đề này liên quan đến con người chứ không phải là một vấn đề công nghệ [Lừa đảo, điều này luôn đúng].

Những thứ vượt trên cả logic

  • Tính đối xứng. Những thứ gần như nhau có thể phân chia chia thành những phần giống hệt nhau và những phần khác biệt rõ ràng.
  • Tính thẩm mỹ.
  • Nhịp điệu. Chờ đợi cho đến thời điểm đúng bảo toàn năng lượng và tránh sự lộn xộn.
  • Cân bằng (tradeoffs). Tất cả những quyết định là chủ đề của việc tradeoff. Quan trọng hơn là biết quyết định phụ thuộc vào cái gì hơn là biết câu trả lời bạn lựa chọn hôm nay (hoặc câu trả lời này bạn đã lựa chọn hôm qua).
  • Danh sách niềm vui (Fun list). Khi các ý tưởng không thứ tự đến, hãy ghi chép chúng và quay trở lại làm việc nhanh chóng. Xem lại danh sách khi bạn tạm dừng.
  • Chăm sóc các ý tưởng. Các ý tưởng giống như là những chú chim nhỏ dễ sợ hại. Nếu bạn doạ chúng đi, chúng sẽ dừng việc đến với bạn. Khi bạn có một ý tưởng, hãy chăm chút nó một chút. Kiểm chứng để loại bỏ chúng nhanh nhất có thể, nhưng từ dữ liệu chứ không phải là từ sự thiếu sự say mê.
  • Nguyên tắc 80/15/5. Sử dụng 80% thời gian của bạn cho những công việc nguy cơ thấp hoặc những công việc được trả lương vừa phải. Sử dụng 15% thời gian của bạn cho các việc nguy cơ cao/trả lương cao có liên quan. Sử dụng 5% thời gian của bạn cho những việc làm cho bạn thích thú, không quan tâm tới kết quả. Hãy dạy những người tiếp nối bạn làm 80% công việc của bạn. Vào thời gian ai đó sẵn sàng để đảm nhận công việc, một trong số 15% thí nghiệm của bạn (hoặc ít thường xuyên hơn, một trong số 5% thí nghiệm) sẽ cho kết quả và trở thành phần 80% của bạn. Lặp lại điều đó.

Kết luận

Dòng chảy trong trong bản phác thảo này dường như bắt đầu từ việc giảm nguy cơ bằng việc quản lý thời gian đến việc chấp nhận mạo hiểm một cách có ý thức bằng cách sử dụng toàn bộ não bộ và nhanh chóng quyết định độ ưu tiên của các ý tưởng.

Advertisements

Thiết lập môi trường làm việc cơ bản trên Mac OS X

Mình chủ yếu làm việc trên môi trường Mac OS X. Hệ điều hành hiện tài trên máy Macbook Pro của mình là El Capitan 10.11.6. Các tác vụ cơ bản là lập trình với các ngôn ngữ mã nguồn mở như Python, Perl, Ruby, R, etc, soạn thảo trên emacs, chạy các chương trình trên Terminal, soạn thảo tài liệu với LaTeX. Bài viết này sẽ tóm tắt lại các thiết lập cơ bản để làm việc trên môi trường này các yêu cầu nêu trên.

1- Thiết lập tên máy tính

sudo scutil --set HostName logos

Tham khảo: http://bit.ly/2aoUSF5

Thay đổi tên local để tránh hiện tượng emacs khởi động chậm.

sudo scutil --set HostName logos.local

2- Thiết lập con trỏ trên Terminal

Thêm dòng sau đây vào file .bashrc

PS1='[\u@\h \w]\n$ '

Thêm dòng sau vào file .bash_profile

if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

3- Thiết lập các alias cho các lệnh hay dùng

# Xoá màn hình với lệnh cls
alias cls=clear

4- Cài đặt Git

Để cài đặt Git trên máy Mac, chỉ cần gõ lệnh git trên terminal và một hộp thoại hiện lên sẽ hướng dẫn bạn cách cài đặt (http://bit.ly/1WQ50nb)

5- Cài đặt Homebrew

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Tham khảo: http://brew.sh/

6- Cài đặt môi trường làm việc Python (với anaconda)

https://www.continuum.io/downloads

Xem thêm thiết lập môi trường Python với conda tại đây

7- Đổi lại phím tắt Ctrl-Space trên Mac OS X El Capitan

Mình hay dùng phím tắt Ctrl-Space để đánh dấu khi soạn thảo với emacs nhưng trong OS X 10.11 (El Capitan), phím tắt này được dùng để thay đổi input sources. Để đổi lại bạn vào System Preferences – Keyboard – Shortcuts; vào Spotlight, bỏ chọn Show Spotlight Search, sau đó vào lại Input sources để đổi phím tắt thành command-Space.

Tham khảo: http://stackoverflow.com/questions/32932036/change-input-source-shorcut-for-mac-os-el-capitan

Chú ý khi thay chọn mục cần thay đổi, ấn phím tab sau đó ấn tổ hợp phím muốn thay đổi.

8- Remap Ctrl-a trong GNU Screen thành Ctrl-o

Mình hay dùng emacs để soạn và Ctrl-a trong emacs được dùng để di chuyển con trỏ đến đầu mỗi dòng. Trong GNU Screen, Ctrl-a được dùng như tổ hợp phím điều khiển.

Để thay đổi, thêm dòng sau vào file ~/.screenrc

espace ^oo

Tham khảo: http://www.vineetmanohar.com/2012/02/2-ways-to-change-key-binding-in-screen/

9- Cài đặt Texmaker cho Mac OS X

Mình hay sử dụng Texmaker để soạn thảo LaTeX trên Mac OS X.

Download và cài đặt Texmaker tại đây.

10- Cài đặt môi trường soạn thảo LaTeX

Xem tại đây: http://www.howtotex.com/howto/installing-latex-on-mac-os-x/

11- Dùng phím Option (Alt) như Meta key khi dùng terminal

Mục đích: Để các key-binding trong các trình soạn thảo như Emacs/Vim hoạt động chính xác. Vào Preference/Keyboard của Terminal và chọn mục “Use Option as Meta Key”. Continue reading

Tạo môi trường Python với Conda

Gần đây, mình bắt đầu sử dụng ngôn ngữ Python cho các dự án của mình. Lý do là Python đã phổ biến và ngày càng phổ biến hơn trong cộng đồng những người làm Machine Learning, NLP và là một trong những ngôn ngữ được dùng nhiều nhất trong ngày khoa học dữ liệu. Có quá nhiều các thư viện Python cho Machine Learning, NLP như scikit-learn, nltk, và đặc biệt là các thư viện Deep Learning như Theano, Chainer. Ngoài ra có rất nhiều các mã nguồn mở sử dụng ngôn ngữ Python. Nói không quá lời, ngôn ngữ Python trong cộng đồng những người làm Machine Learning, NLP cũng giống như tiếng Anh trong giao tiếp quốc tế.

Có một vấn đề khi sử dụng Python đó là các thư viện do người khác phát triển có thể sử dụng các phiên bản Python hoặc các thư viện phụ thuộc khác nhau nên có thể gặp vấn đề khi chia sẻ.

Bài viết tóm tắt lại cách tạo môi trường Python cho các dự án sử dụng Conda và Anaconda dựa trên bài blog: My Python Environment Workflow with Conda. Hiểu một cách đơn giản, Conda là một hệ thống quản lý các thư viện mã nguồn mở và môi trường làm việc, giúp chúng ta dễ dàng cài đặt các phiên bản của các thư viện khác nhau và chuyển đổi qua lại giữa chúng. Trước khi bắt đầu, hãy cài đặt Anaconda trên máy tính của bạn.

Sau đây là các bước tạo môi trường Python sử dụng Conda.

  1. Tạo thư mục của dự án, ví dụ ~/projects/python_env_example trên máy tính của bạn, sau đó chuyển vào thư mục vào tạo:
    $ mkdir ~/projects/python_env_example
    $ cd ~/projects/python_env_example
  2. Tạo một file có tên environment.yml trong thư mục hiện tại. Tên của môi trường có tên trùng với tên của thư mục làm việc. Ví dụ file environment.yml của tôi có nội dung đơn giản như sau:
    name: python_env_example
    dependencies:
    - pip
    - python=3.5
    - anaconda
    

    Trong môi trường Python của mình, tôi sử dụng Python phiên bản 3.5 và các thư viện phụ thuộc là pip và anaconda. Bạn cũng có thể tạo file môi trường bằng lệnh export như sau.

    $ conda env export > environment.yml

    Khi bạn sử dụng thư viện phụ thuộc nào trong dự án của bạn, hãy nhớ bổ sung vào file environment.yml. 

  3. Tạo môi trường conda với lệnh sau:
    $ conda env create -f environment.yml
  4. Bắt đầu sử dụng môi trường làm việc mới python_env_example bằng lệnh:
    $ source activate python_env_example

    Bạn có thể kiểm tra xem các môi trường Python đang có trên hệ thống của bạn bằng lệnh $ conda info –envs

  5. Tạo một file .env với có chứa dòng sau đây:
    source activate python_env_example

    (python_env_example là tên của môi trường Python)
    Mục đích của file này là để tự động hoá việc khởi động môi trường Python bạn đã tạo ra mỗi khi bạn chuyển vào thư mục đã tạo. Trước đó bạn cần cài đặt autoenv. Bạn có thể bỏ qua bước này và mỗi lần muốn chuyển sang môi trường Python đã tạo thì gõ lại lệnh trên. Chú ý trở lại môi trường Python gốc sau khi kết thúc phiên làm việc sử dụng lệnh sau:

    $ source deactivate
  6. Tạo Gitt repository và commit các file đã tạo ra:
    $ git init && git add environment.yml 
    $ git commit -m 'initial commit'
  7. Nếu bạn muốn đẩy repository đã tạo ra lên Github, tạo một repository trên Github và dùng lệnh sau:
    git push -u origin master

    Có thể sử dụng hub để đơn giản hoá quá trình này.

Khi bạn sử dụng thư viện phụ thuộc nào trong dự án của bạn, hãy nhớ bổ sung vào file environment.yml.

Sau khi tạo file môi trường Python environment.yml, bạn có thể dễ dàng chia sẻ với những người khác cùng làm việc trong cùng dự án với mình. Các bước để một người mới có thể bắt đầu làm việc trong dự án của bạn: (1) Sao chép (clone) repository của bạn, (2) Dùng lệnh $ conda env create -f environment.yml để sao chép môi trường Python; (3) Bắt đầu sử dụng môi trường Python với $ source activate python_env_example.

Ghi chú 1:

Bạn có thể thêm hàm sau đây vào file ~/.bashrc để gọi hàm sinh ra file lưu môi trường python trong thư mục làm việc.

## Conda-Env function
function conda-env-file {
     # Create conda environment.yml file and autoenv activation file
     # based on directory name.
     autoenvfilename='.env'
     condaenvfilename='environment.yml'
     foldername=$(basename $PWD)
     if [ ! -f $condaenvfilename ]; then
          printf "name: $foldername\ndependencies:\n- pip\n- python\n- anaconda\" > $condaenvfilename
          echo "$condaenvfilename created."
     else
          echo "$condaenvfilename already exists."
     fi
     if [ ! -f $autoenvfilename ]; then
         printf "source activate $foldername\n" > $autoenvfilename
         echo "$autoenvfilename created."
     else
         echo "$autoenvfilename already exists."
     fi
}

P/S: Trong các dự án của mình, tôi thích dùng conda để quản lý môi trường Python hơn. Bạn cũng có thể sử dụng virtualenv với pip để quản lý môi trường trong trường hợp người khác chia sẻ các “Requirement files” dùng pip. Xem thêm các tài liệu dưới đây:

  1. A non-magical introduction to Pip and Virtualenv for Python beginners
  2. Virtual Environments

16 Cuốn sách “kinh điển” mà tất cả lập trình viên đều nên đọc

1. Code Complete 2

Code Complete 2Cuốn sách Code Complete 2 của tác giả Steve McConnell đối với các nhà phát triển phần mềm thì cũng nổi tiếng như cuốn Joy of Cooking dành cho các chuyên gia đầu bếp vậy. Đọc nó nghĩa là bạn yêu thích công việc của mình, bạn có thái độ nghiêm túc về cái bạn làm, và bạn muốn làm cho nó trở nên tốt hơn. Trong Code Complete, tác giả Steve ghi chú rằng lập trình viên trung bình đọc ít hơn một cuốn sách kỹ thuật mỗi năm. Và với việc đọc cuốn sách này thì đã giúp kéo bạn ra xa khỏi 90% các đồng nghiệp của còn lại. Theo hướng tốt hơn.

Tôi thích cuốn sách này nhiều đến nỗi tên miền blog của tôi (Coding Horror) là xuất phát từ nó. Bạn nên đọc cuốn sách này đầu tiên, và là cuốn sách đầu tiên mà bạn giới thiệu đến các lập trình viên đồng nghiệp của mình.

2. The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)

The Mythical Man-MonthCó nhiều ý kiến cho rằng đây là cuốn sách “kinh điển” duy nhất trong lĩnh vực phát triển phần mềm của chúng ta. Nếu bạn vẫn chưa đọc nó, thì thật đáng hổ thẹn.

Tôi thách thức bất kỳ lập trình viên nào đọc cuốn The Mythical Man Month mà lại không tìm thấy câu chuyện về một hệ điều hành không tồn tại nữa, và nhóm người đã phát triển ra nó, rất đáng ngạc nhiên là chúng lại rất liên quan đến vấn đề của bạn ngày nay. Cuốn sách 25 năm tuổi đã minh họa sâu sắc một quan điểm rằng: máy tính có thể thay đổi, nhưng con người thì không.

Đọc cuốn sách kinh điển này chắc chắn sẽ tốt hơn rất nhiều việc bạn sử dụng thời gian để nghiền ngẫm trên hàng ngàn trang tài liệu kỹ thuật mới nhất hiện nay.

3. Don’t Make Me Think: A Common Sense Approach to Web Usability

Dont make me thinkMột cuốn sách tốt nhất về usability (tính dễ sử dụng của phần mềm) mà tôi đã từng đọc. Tác giả Steve Krug đã bao quát mọi khái niệm quan trọng về usability trong cuốn sách này, và ông làm công việc đó rất tốt. Đọc cuốn sách này thì rất vui. Nếu bạn chọn đọc chỉ một cuốn sách về usability, thì hãy lựa chọn cuốn này. Nó chứa rất nhiều thông tin tuyệt vời, và hình thức trình bày thì ngắn gọn súc tích, dễ áp dụng theo. Nó phù hợp với bất kỳ độc giả nào: dân kỹ thuật, không phải dân kỹ thuật, người dùng bình thường, lập trình viên, nhà quản lý v.v…

4. Rapid Development

Rapid DevelopmentTiêu đề đầy đủ của cuốn sách này là Rapid Development: Taming Wild Software Development Schedules, nó không chỉ dài dòng và hơi buồn cười, mà nó còn dùng sai từ một cách đáng tiếc nữa.

Rapid Development thì không nói về việc phát triển nhanh ứng dụng như cái tên của nó. Nội dung cuốn sách nói về *thực tế của thất bại*. Phần lớn các dự án phát triển phần mềm đều thất bại: chúng thường vượt quá thời hạn kế hoạch đã đặt ra, tạo ra các kết quả không đạt yêu cầu, hoặc đôi khi thậm chí nó còn không thể kết thúc được. Điều này không còn phải tranh cãi; vì đó là một thực tế đã được thống kê. Có một sự thực không mấy dễ chịu đó là team của bạn phải trở nên giỏi hơn trong việc tránh những thất bại đơn giản để có thể thành công. Trong khi nghe điều này có thể làm bạn nản lòng — vâng, nó thì rất nản lòng — nhưng bạn sẽ vẫn muốn đọc cuốn sách này.

Tại sao ư? Bởi vì một nửa thành công là không được lặp lại những sai lầm mà bạn hoặc người khác đã mắc phải. Quan điểm của cuốn sách này đó là việc phạm sai lầm là tốt. Nhưng nếu bạn đang phạm phải chính những sai lầm kinh điển trước đây, thì bạn đã thất bại ngay trước khi thậm chí bắt đầu. Và nếu bạn không biết điều đó là như thế nào thì bạn đang phạm phải một trong những sai lầm đó ngay lúc này.

Lĩnh vực của chúng ta là một trong số ít lĩnh vực thường xuyên thay đổi, vì vậy cách duy nhất là ôm lấy sự thay đổi đó và thử áp dụng những kỹ thuật phát triển “Rapid” khác biệt. Nhưng điều ngược lại thì không đúng. Chúng ta không thể cho rằng có quá nhiều thay đổi từ năm 1970, dẫn đến tất cả các bài học về phát triển phần mềm trước đây đều trở nên lỗi thời và không thích hợp khi so sánh với những công nghệ mới đang “hot” hiện nay. Điều này thì cũng đề cập đến cùng một câu chuyện: máy tính đã thay đổi; con người thì không.

Ít nhất thì cũng có một vài ý tưởng về cái gì làm việc và cái gì không trước khi bạn bắt đầu — như McConnell đã nói, “hãy đọc hướng dẫn sử dụng trên thùng sơn trước khi sơn“. Chắc chắn là vấn đề này nghe có vẻ hiển nhiên cho tới khi bạn đọc cuốn sách này và nhận ra điều đó rất hiếm khi và thực sự xảy ra trong lĩnh vực của chúng ta.

5. Peopleware : Productive Projects and Teams, 2nd Ed.

Peopleware Productive Projects and TeamsNếu bạn đã từng nhìn thấy màn trình diễn của một đội bóng toàn ngôi sao nhưng được dẫn dắt bởi một vị huấn luyện viên tồi, thì bạn sẽ đánh giá cao cuốn sách này. Không quan trọng là có bao nhiêu “siêu sao” trong nhóm của bạn, khi không ai trong số họ có thể trao đổi cùng nhau, hoặc đồng ý về bất cứ việc gì. Và không có lập trình viên nào, dù có tài năng đến mấy, có thể làm việc hiệu quả khi luôn luôn bị rào cản bởi những ngắt quãng nhỏ nhặt. Các lập trình viên không đánh giá đúng các kỹ năng về con người của họ, nhưng một điều trớ trêu thay: thành công của dự án của bạn có thể phụ thuộc rất nhiều vào điều đó. Nếu bạn có bất kỳ một khát khao chính đáng để trở thành một “Team Leader” thực thụ thay vì chỉ là cái chức danh hão, thì bạn cần phải đọc cuốn sách này.

Trong khi Peopleware chứa đầy những quan điểm hoàn toàn vững chắc và tuyệt vời, nó cũng ngụ ý về một mức độ kiểm soát nhân viên dựa trên không gian làm việc là hoàn toàn kỳ quặc tại hầu hết các công ty. Nhưng ít nhất bạn cũng sẽ biết khi nào thì môi trường làm việc của mình, hoặc team của mình đang gặp một vấn đề thực sự — và quan trọng hơn là cần phải làm gì để giải quyết nó.

6. The Design of Everyday Things

The Design of Everyday ThingsCông việc phát triển phần mềm có thể làm bạn nản lòng đến mức khó tin, bởi vì có quá nhiều thứ có thể trở nên sai sót. Có rất nhiều thứ chúng ta làm là để phòng thủ: cố gắng đoán trước điều gì sẽ trở nên sai trước khi nó xảy ra. Nó là nguyên nhân làm bạn kiệt sức về tinh thần, và thậm chí có thể biểu lộ bản thân theo một số cách khá tiêu cực. Đôi khi tôi mô tả công việc này với những người không chuyên về kỹ thuật như thể tôi đang tạo ra một cái đồng hồ với hàng ngàn chi tiết nhỏ, tất cả chúng có thể hỏng một cách ngẫu nhiên vì những kích thích nhỏ nhất.

7. About Face 3.0: The Essentials of Interaction Design

About FaceAlan Cooper, cha đẻ của ngôn ngữ Visual Basic, và là cha đỡ đầu của usability. Tôi xin nói thành thật rằng: tôi đã đọc cuốn sách này cách đây lâu lắm rồi. Tôi mua cuốn sách này khi nó được xuất bản vào khoảng năm 1995, vì vậy tôi có phiên bản “cũ” 1.0 của cuốn sách. (Nó có bị xem là usability tồi không? khi bạn không dùng những cuốn sách của mình lúc có những phiên bản mới?)

Cuốn sách này, cùng với cuốn GUI Bloopers, có khuynh hướng trở thành những cuốn sách về quy tắc sư phạm trong việc trình bày một GUI nhất quán. Nhưng đây là một trong những chỉ dẫn đầy đủ nhất mà bạn có thể ứng dụng được.

Không giống như cuốn GUI Bloopers, vì nó xuất bản thời trước khi có web, vì vậy không có sự bàn luận về cách trình bày trên web và nó có tác động đến thiết kế GUI như thế nào. Nhưng nó thì vẫn là một cuốn sách hữu ích tuyệt vời; tôi đã sử dụng chương sách nói về mô hình quản lý thông điệp lỗi (error messages) cho một dự án .NET gần đây.

8. The Inmates Are Running the Asylum : Why High Tech Products Drive Us Crazy and How To Restore The Sanity

The Inmates Are Running The AsylumĐây là cuốn sách đã giới thiệu với thế giới về khái niệm personas (con người): thay vì trước đây chúng ta cứ nghĩ người dùng là trừu tượng, khó mô tả, là một nhóm người không xác định, thì giờ đây với khái niệm personas sẽ hướng dẫn chúng ta nói chuyện về những người dùng xác định, người mà có tên, có cá tính, có nhu cầu và mục tiêu. Liệu người dùng (users) của chúng ta có muốn chức năng print preview không? Bố ai mà biết được? Nhưng nếu Gerry Manheim là kế toán trưởng, và anh ta phải in ra bảng báo cáo chi tiêu hàng tuần như là một phần công việc của mình, thì tốt hơn là bạn nên tin rằng chức năng print preview cần phải có trong phần mềm. Không có gì thần kỳ ở đây cả; luôn phải biết người dùng của bạn là ai và họ thực sự muốn làm gì — và kỹ thuật sử dụng khái niệm personas đúng là một cách rất tuyệt vời.

Cũng có một phân tích khá thú vị ở đây về việc các lập trình viên có khuynh hướng nghĩ rằng bản thân họ có khả năng tạo ra các quyết định về usability nhân danh những người dùng “bình thường”, nhưng trong thực tế thì hoàn toàn ngược lại. Các lập trình viên chính là những người dùng kỳ cục và cực đoan nhất.

Một bài học ẩn chứa phía sau cuốn sách này đó là đôi khi thiết kế của bạn có tốt như thế nào chăng nữa cũng không quan trọng: phần mềm cho máy scannerphần mềm phát triển web được sử dụng làm ví dụ trong cuốn sách này, cả hai đều thất bại trên thị trường vì những lý do rằng không có gì phải làm với tính usability của chúng cả.

Dù sao thì đây là một cuốn sách tuyệt vời khác của tác giả Cooper, và một sự tiến bộ hợp lý kể từ cuốn About Face đã đề cập phía trên. Trong cuốn About Face, tác giả Cooper coi đối tượng “Perpetual Intermediates” như là độc giả chính, còn ở đây, có một sự xác định rõ ràng hơn và vì vậy dễ phát triển hơn, đó là đối tượng personas.

9. GUI Bloopers: Don’ts and Do’s for Software Developers and Web Designers

GUI BloopersQuay trở lại những ngày tươi đẹp của Windows 95 và Apple’s System 7, đã có những quy tắc thực tế về giao diện người dùng GUI. Và đây là một cuốn sách đặc sắc trong việc thiết kế GUI, về tính nhất quán trong các menu, việc căn lề các button và các text trên các cửa sổ dialog. Bạn có thể tranh luận rằng liệu có bao nhiêu người dùng có thể thực sự hiểu về những quy tắc này, nhưng it ra thì họ cũng có thể mong chờ giao diện người dùng của ứng dụng A có cách bố trí rất giống với ứng dụng B.

Một thực tế đó là thế giới GUI cổ điển và thế giới của trình duyệt (browser) đang dần nhập lại với nhau — kết hợp lấy tất cả những ưu điểm tốt nhất của cả hai. Có những loại ứng dụng mà có giao diện giống hệt của browser.

10. Programming Pearls (2nd Edition)

Programming PearlsTôi đã hơi lưỡng lự khi liệt kê cuốn Programming Pearls vào danh sách này, bởi vì nó chứa khá nhiều kỹ thuật lập trình ở mức thấp, nhưng có đủ “pearls” (tác giả chơi chữ vì pearl có nghĩa là ngọc trai) của nghề phần mềm trong cuốn sách này để làm cho nó có giá trị đối với thời gian của bất kỳ một lập trình viên nào. Programming Pearls là cuốn sách hay tiếp theo để bạn làm việc bên cạnh như thể đang làm cùng với một lập trình viên tài năng vậy. Nó là một tập hợp của những khôn ngoan của nhiều lập trình viên “cao thủ” đã được chưng cất và cô đọng lại, nhưng khá dễ hiểu.

Tôi sẽ không nói dối bạn: phần lớn các chương trong cuốn sách này bạn có thể lờ đi. Ví dụ, tôi không thể tưởng tượng việc thực thi các thuật toán sorting, heap hoặc hash lại được viết lại trong các chương 11, 13 và 14 tương ứng, vì ngày nay đã có những thư viện tuyệt vời cho những thứ nguyên thủy cơ bản này. Chỉ cần đọc lướt qua cuốn sách, lờ đi các phần code. Chương 8, “Back of the Envelope” thì quan trọng, có thể là phương pháp ước lượng tốt nhất mà tôi đã từng được nhìn thấy. Nó cũng tiến một bước dài về phía trước để giảng giải về những câu hỏi phỏng vấn điên khùng mà các công ty thường sử dụng để làm phiền chúng ta.

11. The Pragmatic Programmer: From Journeyman to Master

The Pragmatic ProgrammerCuốn sách này khiến tôi nhớ về rất nhiều điểm trong cuốn Programming Pearls, nhưng nó thì thực sự tốt hơn, bởi vì nó ít tập trung vào code. Thay vì việc lo lắng về code, các tác giả đã đưa vào tất cả những hướng tiếp cận mà họ đã nhận thấy nó làm việc trong thế giới thực vào trong một cuốn sách này. Không phải tất cả những thứ này đều là về kỹ thuật lập trình. Ví dụ, việc hỏi bản thân rằng “Tại sao tôi lại làm điều này? Liệu làm việc này thậm chí có chút giá trị nào chăng?” thì không phải đang nghĩ ra ngoài cái hộp (thinking outside the box); nó là một điều gì đó bạn nên tổ chức vào trong các hoạt động hàng ngày để giữ cho bản thân mình — và đồng nghiệp của bạn — luôn được sảng khoái. Và chính điều đó đã làm cho Pragmatic Programmer trở thành một cuốn sách tuyệt vời.

Nếu bạn muốn biết thêm một chút về cuốn sách này, thì tôi đã tạo ra một phiên bản HTML một phần mục lục tóm tắt để tham chiếu đến các phần bên trong, nó sẽ cung cấp cho bạn một cái nhìn tổng quan về nội dung cuốn sách.

12. Designing Web Usability : The Practice of Simplicity

Designing Web UsabilityTác giả Jakob Neilsen nổi tiếng vì trang web usability của ông, và nghề nghiệp là một chuyên gia về usability từ những năm 1989 khi mà cuốn sách đầu tiên của ông được xuất bản. Cuốn sách Designing Web Usability là một khóa học đầy đủ kiến thức căn bản về web usability, nhưng nó có một chút khác biệt hơn các cuốn sách hướng GUI của tác giả Cooper ở trên.

13. The Visual Display of Quantitative Information

The Visual Display of Quantitative Information14. Visual Explanations: Images and Quantities, Evidence and Narrative

Visual Explanations15. Envisioning Information

Envisioning InformationThông tin thì rất “đẹp”. Và một giao diện người dùng GUI được thiết kế tốt cũng vậy. Bạn không cần phải sở hữu tất cả 3 cuốn sách trong sê-ri này trừ khi bạn là một người hoàn hảo, nhưng 2 cuốn đầu thì rất cần thiết.

16. Mastering Regular Expressions, Second Edition

Regular ExpressionsHệ điều hành UNIX thường nổi tiếng một cách xứng đáng vì độ phức tạp và không thể xâm nhập. Và Regular Expressions cũng nổi tiếng như vậy.

Tôi có thể trở thành một thành viên của câu lạc bộ “Keep It Simple Stupid – giữ cho nó đơn giản nhất đồ ngốc ạ”, nhưng tôi đang làm một ngoại lệ đối với regular expressions. Nếu viết tốt, thì chúng sẽ tiết kiệm cho bạn vô số thời gian trong việc thao tác bằng tay để bắt các trường hợp khác nhau, và tôi cũng hiếm gặp một dự án nào mà chúng lại không có ích ở một nơi nào đó.

Một khi bạn đã nhảy vào thế giới của regular expressions, thì bạn có thể sẽ trở nên mê mẩn với sức mạnh tuyệt vời và tiềm năng mà chúng có.

VinaCode

Bài viết được dịch từ Coding Horror

Lời bàn của Vinacode:

Khi lần đầu tiên nhìn thấy danh sách này của lập trình viên nổi tiếng Jeff Atwood, bạn biết mình nghĩ gì không ạ? Lúc đó mình nghĩ rằng đúng là chết tiệt thật, giá như mình biết được danh sách này sớm hơn. Bởi trước đó vì không ai bày cho nên đọc sách gì, nên mình đã cắm cổ đọc sách như điên. Mình thức cả đêm để download hàng trăm cuốn sách, hàng chục GB tài liệu rồi cuối cùng bỏ đó. Và cách đọc sách của mình cũng sai nữa, vớ được cuốn nào là mình đọc hùng hục từ đầu đến cuối, có khi hứng lên còn đọc luôn cả phần lời cảm ơn nữa! 🙂

Sau này mình mới biết có những cuốn kinh điển như “Code Complete 2” là sách gối đầu…

View original post 3,458 more words

Git and GitHub References

Tập hợp các references khi học/sử dụng Git & GitHub

Git

GitHub

Để trở thành một lập trình viên giỏi (Trích từ Quora) – Phần 2

Nguồn: câu trả lời của “Lionell Pack” (http://www.quora.com/What-are-the-best-kept-secrets-of-great-programmers)

There are a few pieces of advice I’d give. I’ll put a list at the end.

1. Pick some great developers in your field, and learn about the cutting-edge things they’re doing. Go to user groups when they’re presenting, read their blogs, read their books, help out on their open-source projects. Try to understand the principles they’re aiming at, and don’t just blindly follow the techniques. I’ve seen IoC DI implementations go horribly awry because the developer didn’t see the warning signs of the very things that pattern is supposed to avoid.

2. Avoid technique attachment (“Ooh, shiny!” syndrome). There’s a tendency to always try to use the newest techniques you’re learned. Event sourcing is cool, but it’s not the solution to every problem. IoC makes sense, most of the time. Using lambda expressions and closures can often make a solution clearer and simpler, but you don’t have to shoe-horn them into every single algorithm you write. There’s nothing wrong with starting a hobby or throw-away project with the intention of learning a new technique, but when you’re building code to solve a real-world problem, pick the right tool for the job.

3. Know your libraries and frameworks, and use them instead of writing your own implementations. Especially, don’t try to write your own date and time routines!

4. Pay attention to warnings, whether they’re coming from your compiler, IDE, or other tools. The people who write them understand the language deeply, and these warnings are their way of teaching you important details about the language. Don’t just change the code to avoid the warning; make sure you understand what the person who designed that warning is trying to tell you.

5. When you’re building code, constantly re-factor, and don’t get too attached to a design or block of code. This point deserves fleshing out a little, so I’m going to go into some more detail:

  • Be prepared to throw away code. Sometimes, you’ll write 20 lines, re-factor them a bit, and realize that you basically just re-implemented something offered by a framework or library you’re using, or something you’ve already written. Throw it out! DRY doesn’t just refer to your own code. It also covers DRYF (“Don’t Repeat Your Framework”) and DRYL (“Don’t Repeat Your Libraries”).
  • No matter how carefully you consider your up-front design (if you prefer exploratory coding, this is even more crucial), you are going to run into things you hadn’t thought of – and there’s a good chance your design won’t quite accommodate every single detail you encounter. Aggressively refactor your own code as you’re writing it (know your IDE, particularly the refactoring tools it provides). Move bits of code between classes. Introduce new classes. Split methods into two, or three, or more. Throw out classes which don’t make sense. Rename things the first time you read the name and think, “what does that mean again?”. Keep SRP in mind, and the moment you find yourself trying to make one class do two different things, turn it into two classes.
  • Writing software isn’t like running a race – you don’t start at the beginning, follow a pre-defined route, and end up at the finish. Think of it more as writing out post-it notes and shuffling them around on a board, sometimes making edits or throwing some notes out entirely, sometimes writing new ones, until you satisfy an on-looker (your tests!) that everything looks right.
  • (And finally, on that note… write automated tests. I don’t buy in to the principles of TDD, but I definitely buy into the practice. I usually flip it around in my head – it’s not that your code is complete once it satisfies the test; rather, your tests are complete once they demonstrate that the code functions correctly. I’ve seen too much code ‘proven’ by incorrect or incomplete tests to be happy with “write the test, write the minimum code to pass the test”.)

Here’s the promised list:
1. Follow good developers, and try to understand their ideas.
2. Pick the right tool, not your favourite tool.
3. Know your libraries and frameworks, so you don’t repeat them.
4. Pay attention to compiler/editor/etc. warnings!
5. Refactor all the time – especially new code, especially as you’re writing.

Để trở thành một lập trình viên giỏi (Trích từ Quora) – Phần 1

Nguồn: câu trả lời của “Jeff Darcy” (http://www.quora.com/What-are-the-best-kept-secrets-of-great-programmers)

OK, seriously this time.  I think there are really a few things that distinguish great programmers.

  1. Know the concepts. Solving a problem via memory or pattern recognition is much faster than solving it by reason alone. If you’ve solved a similar problem before, you’ll be able to recall that solution intuitively. Failing that, if you at least keep up with current research and projects related to your own you’ll have a much better idea where to turn for inspiration. Solving a problem “automatically” might seem like magic to others, but it’s really an application of “practice practice practice” as Miguel Paraz suggests.
  2. Know the tools. This is not an end in itself, but a way to maintain “flow” while programming. Every time you have to think about how to make your editor or version-control system or debugger do what you want, it bumps you out of your higher-level thought process. These “micro-interruptions” are small, but they add up quickly. People who learn their tools, practice using their tools, and automate things that the tools can’t do by themselves can easily be several times as productive as those who do none of those things.
  3. Manage time. Again it comes back to flow. If you want to write code, write code. If you want to review a bunch of patches, review a bunch of patches. If you want to brainstorm on new algorithms . . . you get the idea. Don’t try to do all three together, and certainly don’t interrupt yourself with email or IRC or Twitter or Quora.  😉  Get your mind set to do one thing, then do that thing for a good block of time before you switch to doing something else.
  4. Prioritize. This is the area where I constantly see people fail. Every problem worth tackling has many facets. Often, solving one part of the problem will make solving the others easier. Therefore, getting the order right really matters.  I’m afraid there’s no simple answer for how to recognize that order, but as you gain more experience within a problem domain – practice again – you’ll develop a set of heuristics that will guide you.
  5. Reuse everything. Reuse ideas. Reuse code. Every time you turn a new problem into a problem you already know how to solve – and computing is full of such opportunities – you can save time. Don’t worry if the transformed solution isn’t absolutely perfect for the current problem. You can refine later if you really need to, and most often you’ll find that you’re better off moving on to the next problem.

A lot of these really come down to efficiency.  As you move through more problems per day, you’ll gain more experience per day, which will let you move through more problems per day, and so on.  It’s a feedback loop; once you get on its good side, your effectiveness (and value) will increase drastically.