I will have a workshop at CodeGym at the end of this month about Design patterns. One of the biggest issue in training design patterns is the trainees don’t know how to apply them together in a single real world problem. Here is my example that will be used as the exercise for this workshop. Is it interesting enough? Try it out.

KFC. Order system

KFC is very famous fastfood brand, they have many franchises in various places that share the same hotline, menu.

When users open the menu on KFC website, they see the single menu, choose and order food by calling to the single hotline. A order center (OC) receives the order and notifies to the appropriate store by a specific criteria (now is location and can be changed in the future). A store can answer their possibility to take this order (they need to cook and deliver it on time). If a store takes this order, the process ends; otherwise, the OC will find another one.

To process a order, a store has a recipient who receives the order from OC, forwards it to the kitchen, finds the right delivery man and updates the order basing on the information from delivery man such as payment, status (accepted or declined), customer feedback… to OC. So OC has real time data of every orders but doesn’t have order’s internal note that works within the store.

When OC gets the order information from customer, they may get the extra information in some categories like food change, delivery time, special notes… If customer calls to OC to cancel the order, OC can directly cancel it by updating the order status in taken store.

Design the system by design patterns.

—————————————————————-

The solution will be updated later.

510 total views, no views today

Trong Agile Y, tôi có đề cập tới yearly master plan – phương pháp được tôi sử dụng để tạo lập kế hoạch. Tôi không phải là người theo đuổi trường phái thiết lập và bám theo những kế hoạch dài hạn, song tôi khuyến khích mọi người cần có mục tiêu và một kế hoạch phác hoạ cho một năm; và vì thế, cần có yearly master plan.

Mỗi năm, tôi thường dành từ 1/2 đến 1 ngày để tạo master plan vào ngày đầu năm (dương lịch) với các bước sau:

  1. Liệt kê những công việc muốn làm trong năm, theo độ ưu tiên. Ví dụ:
    1. Đọc 18 cuốn sách
    2. Đi du lịch 3 thành phố
    3. Viết 1 cuốn sách
    4. Viết 20 bài blog
    5. Học bơi
  2. Dự trù tài chính. Tính toán dòng tiền vào, ra hàng tháng, chi tiêu cố định, chi tiêu phát sinh, tiết kiệm… Ví dụ:
    1. Tháng 1: lương: 20 triệu, chi tiêu: 10 triệu, tiết kiệm: 10 triệu
    2. Tháng 2: lương: 20 triệu, chi tiêu: 20 triệu (hàng tháng: 10 triệu + Tết: 10 triệu), tiết kiệm: 10 triệu
    3. Tháng 3: lương: 20 triệu, chi tiêu: 15 triệu (hàng tháng: 10 triệu + mua điện thoại: 5 triệu), tiết kiệm: 15 triệu
  3. Dự trù thời gian. Tính toán thời gian cố định cho công việc, giao lưu, nghỉ ngơi… Ví dụ:
    1. Tháng 1: Bận chuẩn bị Tết, dư 15 giờ
    2. Tháng 2: Nghỉ Tết, dư 40 giờ
    3. Tháng 3: Muốn du lịch châu Âu
  4. Đánh giá 3 danh sách trên. Ba yếu tố trên chính là những yếu tố ràng buộc lẫn nhau, cho thấy được thời điểm và tính khả thi của từng mục tiêu. Ví dụ: Tháng 2 thích hợp cho việc đọc sách và viết blog, tháng 3 là không thích hợp cho mục tiêu du lịch châu Âu bởi tình hình tài chính chưa đảm bảo nhưng lại đủ cho mục tiêu học bơi hoặc du lịch trong nước;… Quay trở lại các bước 1-2-3, điều chỉnh lại mục tiêu, danh sách công việc và thời điểm cho phù hợp. Ví dụ: Điều chỉnh mục tiêu du lịch 3 thành phố xuống 1 hoặc điều chỉnh dự trù tài chính: cần tiết kiệm hơn, cần tìm kiếm nguồn thu khác…
  5. Liên tục lặp lại các bước này tới khi 3 yếu tố trên đạt sự cân bằng cần thiết và khả thi. Thông thường, một năm tôi sẽ chọn lấy 2 công việc cần thực hiện, trong đó có 1 công việc phải thực hiện: năm trước nữa là du lịch châu Âu, năm trước là Agile Y…

Tất nhiên, khi thực hiện, chúng ta khó có thể bám theo yearly master plan một cách hoàn hảo do hàng trăm sự kiện xảy đến trong năm khiến chúng ta phải điều chỉnh lại kế hoạch / mục tiêu theo từng tuần. Song yearly master plan rất quan trọng, nó cho thấy những gì chúng ta có thể làm và ưu tiên cao nhất trong một năm.

233 total views, no views today

Year ago, I had a post about iterating through collection. Today my colleague’s question gave me the idea about an example of using collection right. Let’s say we have a collection like NSArray that contains multiple NSString objects, we want to print them in lines includes the line number.

Easy problem, right? Let’s see we have some solutions:

What’s a best way? I can say #2 > #3 | #1.

About #3, you can refer to my post to know why we should use iterator instead of index while going through collection. Of course they perform same with NSArray but using iterator help us more easily use another collection type later. So #1 and #2 are usually better than #3. Why is #2 better than #1? The issue is:

#1 is O(n) while #2 is O(1). We can see #1 is more readable (a bit easier to understand than #2) but #2 has better performance.

You could see #1 is worser in some way. In case of duplicated strings in lines, you may also get wrong result (index is the first found): http://stackoverflow.com/questions/3167849/indexofobject-vs-indexofobjectidenticalto 

Hôm nay đồng nghiệp hỏi câu này: Tại sao nên viết như #a thay vì #b?

Tôi mở rộng câu hỏi thành: Sắp xếp các cách viết sau theo thứ tự “tốt dần”.

Khá khó để nói #3 và #4, cách nào tốt hơn; nhưng có thể dễ dàng khẳng định #1 và #2 không tốt bằng #3, #4. Tại sao?

Nguyên tắc chung của lập trình hướng đối tượng là trừu tượng hoá và cố gắng tối đa việc trừu tượng hoá. Trừu tượng (không phải là giải pháp toàn vẹn nhưng) là một phần trong cách tư duy về Open / Closed principle. #1 rất trực quan và dễ hiểu: tạo một danh sách lưu trữ sách dưới dạng ArrayList. Nhưng những thứ cụ thể rất khó để sửa đổi và thay thế. Ví dụ, sau khi implement, chúng ta phát hiện ra đoạn code phía sau sử dụng rất nhiều thao tác thêm phần tử vào list thay vì lấy phần tử ra; do đó lưu trữ dưới dạng Stack cho hiệu suất tốt hơn; chúng ta phải sửa đổi các đoạn code phía dưới với implement cụ thể của Stack (thay cho ArrayList). Một thời gian sau, nhu cầu lấy phần tử từ list đủ nhiều để sử dụng ArrayList cho hiệu suất tốt hơn, chúng ta phải sửa lại đoạn code phía dưới với implement cụ thể của ArrayList. (Tham khảo: hiệu suất các implement của List). Khổ chưa?

Một cách thông minh hơn là sử dụng #3, khi đó, đoạn code phía dưới chỉ sử dụng những method được định nghĩa cho interface List. Khi cần thay đổi implement cụ thể thành Stack, LinkedList…, chúng ta chỉ đơn giản thay new List<Book>() bởi new Stack<Book>() hay new LinkedList<Book>(). 

Và theo cách tư duy đó, #4 tốt hơn #3? Không hẳn, nếu chúng ta đã xác định list chỉ chứa Book, việc khai báo list chứa Object khiến chúng ta có thể mất công cast những object này trong trường hợp sử dụng những method cụ thể của Book (và thường là vậy). Nên dùng #4 thường là bất lợi hơn #3 (trừ trường hợp list chữa những object khác ngoài Book).

Do đó, sử dụng #3 (khai báo interface và khởi tạo bằng class (đương nhiên)) thường là cách viết nên được “quen tay”.

Thật ra #3 còn nên viết theo 1 cách khác tốt hơn như sau. Tại sao nhỉ?

585 total views, no views today

Following my post about How programmer gets his wife happy, here is a simpler version for who is using Mac with Message app.

Forget all Twilio setup, you just need to create the cronjob. Replace the content and your wife’s number.

1. Create a file sweet_sms_to_darling.sh, put the command above.

2. Get it executable, and run at 18:30 every day.

Add this line, correct your file path, 18, 30 is the hour and minute triggers this bash script.

3. Save this file and add to cronjob. That’s all.

Life is easy if you are a programmer.

790 total views, no views today

Don’t wanna get your wife angry just because of let her wait so long for a dinner? This program is for you. It’s a guide to build the simple application that automatically sends SMS to your wife at a specific time if you need to stay longer at the office.

Get Twilio account

Register an account at: https://www.twilio.com, the service lets you send the SMS via REST API. During trial period, you could get 10$ – enough free messages; then you get charged with low fare later (~0.01 – 0.05$ for each SMS).

Setup Twilio

  1. Buy a number at: https://www.twilio.com/console/phone-numbers/incoming. It costs 1$, Twilio uses this number to send SMS. Call it SENDER.
  2. Verify your wife’s phone number (with country code like +84 988 999 888) at: https://www.twilio.com/console/phone-numbers/verified (to make sure you don’t spam anyone). Call it RECEIVER.
  3. Create API key at: https://www.twilio.com/console/dev-tools/api-keys. You can get API key and secret key here. Call them KSID and KSECRET.
  4. Go to https://www.twilio.com/console and get your account SID. Call it ASID. 

Now replace this command with your information above, replace + in the phone number with %2B.

Then run.

Got it? We are almost done.

Setup a cronjob

You can send SMS to your wife by only 1 command; now get it automated.

1. Create a file sweet_sms_to_darling.sh, put the command above.

2. Get it executable, and run at 18:30 every day.

Add this line, correct your file path, 18, 30 is the hour and minute triggers this bash script.

3. Save this file and add to cronjob. That’s all.

OK, now when your computer is up on 18:30, it automatically send the SMS to your wife.

Don’t worry about she get angry. Now work. 

Please don’t put this job on server – it’s always up 😉

It’s general idea of building the application, you could do it in others platform like Windows with BAT file and scheduled task. Another simpler and specific version for Mac is coming soon 😉

734 total views, no views today

Following the topic in my short post eXtreme Programming is Dead, I had a talk at the monthly meetup of Agile Vietnam, Feb 2017, to explain more about my opinion.

Half of time, I focused on describing what exact eXtreme Programming (XP) is. Today most of development teams are applying some XP practices but they just do it with forgetting what are behind the scene: values and principles. It’s time to recall to how to do it right.

Then I explain more about my idea, why XP is dead. It’s dead in some ways: teams just follow the practices without knowledge of values and principles, the practices is more and more becoming standards of software development instead of extreme, original XP makes the confusion of applying it at enterprise.

You can find the slide here – it just is the outline, I will try to explain more in longer post later.

326 total views, no views today

Tại sao ở Việt Nam, những tư tưởng và thực hành XP không được coi trọng? Theo tôi quan sát, có ba lý do chính.

Một là, ngành CNTT của Việt Nam chủ yếu vẫn đang tiếp cận theo hướng top-down; những vấn đề về công nghệ, phương pháp luận, thực hành vẫn chủ yếu được định hình bởi các quản lý cấp cao, cấp trung. Và XP thường không bao giờ nằm trong danh sách lựa chọn của những nhà quản lý dự án hay quản lý tổ chức thuần tuý, bởi XP không phải là phương pháp luận về “quản lý”.

Hai là, tên. eXtreme Programming chết bởi cái tên. Kent Beck có lẽ nên chọn một cái tên khác, có thể là vô nghĩa thì tốt hơn. XP cho thấy sự coi trọng hoá programming một cách cực đoan. Và thực sự, điều đó là đúng. Gốc rễ của mọi sản phẩm phần mềm là lập trình. Song nếu như vậy, ngành công nghiệp phần mềm sẽ là quá chật hẹp; và những nhà tư vấn cần phải làm phức tạp nó lên, để mở ra nhiều vị trí khác, nhiều công việc khác. Tư tưởng này được đẩy tới những nhà quản lý, và họ thành ra không coi trọng vấn đề lập trình; họ hiểu rằng để làm ra sản phẩm phần mềm phức tạp, thì tổ chức phải cần những phương pháp phức tạp; và nhiều công việc, nhiều quản lý chính là cách hiện thực hoá điều đó. Có lẽ eXtreme Managing sẽ được lòng hơn là eXtreme Programming.

Và thế là, ba, thị trường XP ngày càng yếu. Những nhà tư vấn, đào tạo không hào hứng với việc đào tạo XP. XP là những gì hand-on rất cụ thể, tốn kém hơn, nhưng nhu cầu ít hơn, là mảnh đất khô cằn của thị trường tư vấn, đào tạo; trong khi những phương pháp quản lý tiếp tục lên ngôi trên một mảnh đất màu mỡ hơn. Và do ít được đào tạo, XP ít được biết đến và ít được thực hành; nên dữ liệu cũng ít, nên càng khó chứng minh được sức mạnh một cách rõ ràng.

Vậy là XP chết.

Đó là tình hình ở Việt Nam. Trên thế giới? XP cũng đã chết. Ít nhất là cái tên.

Ở Việt Nam, các tổ chức không coi trọng XP, họ coi trọng những phương pháp luận về quản lý dự án và quản lý tổ chức mới. Họ mải miết với việc xây dựng môi trường làm việc thân thiện, vui vẻ. Nhưng vui vẻ sao được khi chất lượng sản phẩm không cao? Vui vẻ sao được khi các lập trình viên phải fix bug trên production? Phải căng thẳng khi merge code và lo lắng rằng việc deploy không thành công? Phải để tester chờ tới đêm mới có một bản build?

Trên thế giới, trừ một số người “học hành tử tế”, bây giờ cũng ít ai nhắc tới XP. Nhưng thực tế lại trái ngược hoàn toàn. TDD, pair programming, code refactoring… là những khái niệm và thực hành rất căn bản, ai cũng có thể làm. Continuous Integration (với Jenkins, TeamCity…) xuất hiện ở mọi dự án, đến nỗi người ta không nhớ rằng đó là practices của XP, trừ những người nghiên cứu chi tiết. Và XP chết vì nó đã trở thành bình thường, trở thành “chuẩn” kỹ năng của mọi lập trình viên, không còn là eXtreme nữa. XP là extreme của những năm 2000. Sau gần 20 năm ra đời, XP giờ đây là chuẩn theo nghĩa phổ thông. Hãy thử tìm xem có IDE nào tử tế không hỗ trợ unit test và TDD? Hãy thử tìm xem có framework nào tử tế không có test?

Trong khi thị trường thế giới cạnh tranh gay gắt về những công cụ hỗ trợ tư tưởng, thực hành XP, thì ở Việt Nam, chúng ta vẫn chưa dùng nhiều. XP chết, ở hai nơi, theo hai cách khác nhau.

Tiêu đề rất kêu này của Hiệp Lê. Nhưng nội dung thì cả Hiệp và Hiển đều có chung ý tưởng và hoàn toàn đồng tình.

751 total views, no views today