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.

344 total views, 1 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.

592 total views, no views today

Sáu năm trước, lần đầu tiên, một người thầy nói với tôi rằng “con cần cẩn thận, đừng sống theo quán tính như người ta”. Thời điểm đó, là quá sớm để tôi hiểu hết một câu nói bình dị, tôi chỉ đơn thuần bị ấn tượng bởi từ “quán tính” – không nhiều người sử dụng nó cho cuộc sống. Những năm sau đó, khi bắt đầu đọc và thực hành, hiểu hơn trong việc hình thành những thói quen tích cực, tôi dần hiểu ra rằng quán tính tích cực và cũng đáng sợ.

Khi chúng ta tiếp cận những điều mới mẻ, quán tính là mỏ neo giữ chúng ta lại. Một người chưa bao giờ hút thuốc, quán tính sẽ giữ anh ta lại, ngăn cản anh ta có những trải nghiệm mới trong làn khói; nhưng chính quán tính đó, sẽ giúp anh ta được an toàn và không làm điều tổn hại tới sức khoẻ.

Khi chúng ta, vì vượt qua quán tính để hình thành thói quen mới, ngay lập tức chúng ta đã vô tình hình thành một quán tính khác, quán tính giống như cánh buồm no gió đẩy chúng ta đi mãi. Một người khi đã quen với việc uống cafe mỗi tối, quán tính sẽ giúp anh ta tìm ra cách thưởng thức ly cafe tuyệt nhất sau bữa ăn; nhưng chính quán tính đó, sẽ đẩy anh ta tới những cơn mất ngủ, mãi không thôi.

Một con thuyền hoàn hảo phải có mỏ neo, cánh buồm và bánh lái. Một chiếc bè thì không cần như vậy, chỉ đơn giản là đứng yên khi nước lặng, và trôi tự do theo dòng khi nước đi. Và mỗi người, có sự lựa chọn của riêng mình, là chiếc bè hay con thuyền?

Có những người cảm thấy thoải mái khi là chiếc bè, cứ xuôi theo dòng chảy, mỗi ngày, làm những gì vẫn làm, và làm những gì người khác vẫn làm. Song chắc không nhiều người muốn sống cuộc sống của chiếc bè, có chăng, đa phần chỉ sống như vậy một cách thụ động, một cách bản năng; bởi họ vẫn thấy vui khi xuôi theo dòng nước, nhưng mấy ai lường được khi nước xoáy trong một cơn mưa lũ, chiếc bè có còn vui khi nó bị quán tính đẩy tới một tốc độ kinh hoàng? Tôi tin chỉ một số ít người thích thú với tốc độ.

Con thuyền thì khác, vốn tự thân nó đã chuẩn bị cho mình những thành phần và chức năng cần thiết. Thả mỏ neo khi muốn dừng lại, thu neo để xuôi theo dòng, giăng buồm để tăng tốc, và đánh lái sang một hướng khác khi muốn. Và khi cần, nó có thể đi ngược dòng nước. Nó cho phép mình có nhiều lựa chọn. Nó lựa chọn hướng đi của riêng mình trong quán tính của dòng nước. Tôi tin, hầu hết chúng ta muốn mình là một con thuyền. Chúng ta muốn được sống chủ động.

Để nâng cấp từ chiếc bè thành con thuyền không dễ, con người cần rèn giũa những kỹ năng để hình thành lên chiếc mỏ neo, cánh buồm và bánh lái. Song đó chưa phải là tất cả. Điều quan trọng hơn là cách lái con thuyền một cách thông minh. Khi nào thì quăng neo, khi nào thì nhổ neo, khi nào giăng buồm, và khi nào thì đánh lái? Điều đó cần hơn cả sự thông minh và tinh tế; cũng như phương pháp tốt. Con người cần nhìn lại vào chính mình, để hiểu thực sự mình cần gì, và muốn gì; để thu lại chiếc mỏ neo và rồi tận dụng quán tính để tiến về phía trước. Nhưng việc hiểu mình không cần gì, và không muốn gì cũng quan trọng không kém; để quăng ra chiếc mỏ neo và dừng lại khi cần. Và để nhìn vào chính mình, không gì tốt hơn những khoảng lặng. Nếu một người cứ mãi làm những việc một cách vô thức, chỉ vì ngày hôm qua anh ta làm vậy hay chỉ vì mọi người vẫn làm vậy, quán tính cuộc đời sẽ sớm đẩy anh ta tới một tốc độ kinh hoàng. Nếu anh ta nhìn có phút nhìn lại để nhận ra quán tính sẽ đẩy mình đi đâu, tới tốc độ nào, anh ta sẽ biết mình nên căng buồm, đánh lái hay thả neo.

Đó có thể là trong một trận bóng, tôi cố gắng kết thúc một tình huống, để có 10 giây suy nghĩ. Đó có thể là trong một bữa tiệc vui hay một cuộc buồn, tôi biến mất giữa đám đông 5 phút, để biết rằng mình nên tiếp tục hay trở về. Đó có thể là 1 giờ không làm gì để biết mình nên làm gì. Làm gì, và không làm gì, cũng đều quan trọng như nhau. Xác định được giá trị trong cuộc sống, chính là tìm ra cách sử dụng và điều khiển quán tính một cách hợp lý. Chúng ta sẽ luôn căng buồm theo những thói quen mà chúng ta tin rằng, đó là giá trị cuộc sống; chúng ta sẽ luôn xuôi dòng với những thói quen khác; và chúng ta sẽ thả neo để giữ mình lại trước khi hình thành nên một thói quen vi phạm những giá trị này. Vì sau cùng, chạy theo những thói quen của mình một cách vô thức đã là điều tồi tệ; để quán tính đẩy chúng ta theo những thói quen chỉ vì những người khác vẫn làm như vậy, còn tồi tệ hơn.

Quán tính có thể là sức ỳ, ngăn cản chúng ta chuyển động tới những điều mới mẻ, hình thành những thói quen.

Quán tính có thể là sức động, giữ chúng ta mãi trôi theo những thói quen.

Quán tính tích cực, và cũng tiêu cực như thói quen vậy.

Hiểu được bản thân cần sự tinh tế; sử dụng quán tính hợp lý để điều chỉnh cần sự sáng suốt. Và thật đáng buồn, con người lại là sinh vật phi lý trí nhất. Bởi vậy, sẽ tốt hơn nếu con người đi cùng nhau; người ta cần một đối tác sáng suốt; người sẽ căng buồm hoặc thả neo khi cần thiết. Đàn ông, với bản tính của mình, mấy khi sáng suốt?

771 total views, no views today

Đây là vấn đề cốt lõi cần được giải quyết của việc chuyển đổi sang môi trường Agile.

Push system (hệ thống đẩy) là mô thức quản lý phổ biến hiện nay, sử dụng một quy trình được đinh nghĩa trước cùng các vai trò và mô tả công việc tương ứng. Mọi công việc được chỉ định tới một thành viên cụ thể, quy định từng mức trách nhiệm và khả năng quyết định. Trong một hệ thống phân cấp, mọi công việc đều:

  • cần phối hợp và báo cáo cho người quản lý trực tiếp;
  • thực hiện bởi người ở mức thấp hơn trong phân cấp quản lý.

Thông qua việc định nghĩa rõ ràng sự phân cấp trong mô hình tổ chức, mọi công việc đều được định nghĩa cụ thể về mục tiêu, thời điểm hoàn thành, tiến độ… giúp người quản lý thực hiện việc push công việc xuống những nhân viên như commandcontrol được những gì đang xảy ra; chất lượng công việc phụ thuộc lớn vào tài năng của những nhà quản lý. Push system dựa trên giả định rằng những nhân sự không có động lực làm việc và luôn cần được giao việc và giám sát để hoàn thành.

Cuối thế kỷ 20, Peter Drucker lần đầu nói về thời đại của những lao động tri thức, những công việc trở nên phức tạp hơn, và cần nhiều kỹ năng để hoàn thành hơn. Hệ quả là sự bất hợp lý trong việc phân chia và giao từng công việc cụ thể tới một cá nhân; mô hình làm việc nhóm với những thành viên có đầy đủ kỹ năng trở nên thắng thế. Và bước phát triển tiếp theo là nhóm tự quản.

Pull system (hệ thống kéo) là mô thức quản lý được điều hướng bởi giá trị và kết quả; những công việc được xây dựng thành một danh sách cần hoàn thành theo một thứ tự nhất định và không được giao cho một thành viên cụ thể; những thành viên trong nhóm sẽ chủ động thực hiện pull công việc và thực hiện. Pull system được xây dựng trên giả định rằng những nhân sự luôn có động lực làm việc và không cần nhiều sự quản lý.

Hiểu được sự khác biệt giữa push systempull system là vấn đề lớn nhất với những tổ chức muốn chuyển đổi sang môi trường Agile. Điều cốt lõi nằm ở:

Cách thức định nghĩa quy trình. Trong push system, quy trình được định nghĩa trước, và thông thường được định nghĩa bởi những người không trực tiếp thực hiện công việc cụ thể, và đặt trọng tâm vào giá trị quản lý. Bộ phận quản lý quy trình định nghĩa ra cách thức thực hiện một chiến lược marketing, những bước thực hiện, tài liệu trao đổi giữa các phòng ban từ việc thiết lập chi phí đến thiết kế hình ảnh, nội dung… song chính họ lại có rất ít kiến thức về cách tạo ra một chiến lược marketing hiệu quả. Quy trình được định nghĩa chủ yếu hướng tới việc giúp những nhà quản lý có cái nhìn toàn cảnh và kiểm soát công việc thông qua chỉ định công việc tới từng cá nhân cụ thể; cho mọi dự án. Nhưng sự cứng ngắc của những quy trình được định nghĩa sẵn làm hạn chế sự sáng tạo, tạo ra rào cản làm chậm quá trình tạo ra giá trị thực sự. Push system và Agile hướng tới thực nghiệm. Thông qua việc thực hành và đo đạc hiệu quả, nhóm tự tổ chức biết cách thực hiện nào là phù hợp cho nhóm trong từng hoàn cảnh cụ thể, và hình thành quy trình riêng cho nhóm; từ đó loại bỏ rào cản và tối ưu giá trị tạo ra.

Trách nhiệm hoàn thành công việc. Điều khiến mọi người phân vân là trách nhiệm cá nhân trong pull system: nếu một công việc không được chỉ định cho một cá nhân cụ thể, điều gì khiến công việc đó được hoàn thành? Đây là một câu hỏi hợp lý; song suy nghĩ theo một cách khác, nếu mọi công việc được chỉ định theo cá nhân cùng KPI tương ứng, những cá nhân này có thể vì tập trung nỗi lực hoàn thành một phần việc cụ thể mà bỏ qua việc cộng tác trong bức tranh toàn cảnh và tạo ra giá trị lớn hơn. Một tester được giao nhiệm vụ cụ thể sẽ cố gắng tìm ra thật nhiều bug thay vì cộng tác với developer trong nhóm nhằm tìm cách hạn chế chúng. Pull system và Agile hướng trọng tâm vào xây dựng nhóm có động lực làm việc – tập trung vào con người. Nhưng đó là cách làm phù hợp với thị trường lao động tri thức ngày nay khi nhu cầu người lao động đi dần lên phía đỉnh của tháp Maslow.

Chất lượng công việc. Công việc được nâng cao khi người thực hiện hiểu được giá trị và có cái nhìn thổng thể. Push system thường chỉ tập trung vào từng công việc cụ thể và bỏ qua góc nhìn về toàn cảnh hệ thống và giá trị, mức độ quan trọng cụ thể của một thành phần công việc tạo ra giá trị chung. Pull system cung cấp góc nhìn toàn cảnh, những giá trị đóng góp của từng công việc cụ thể tạo thành giá trị chung, hỗ trợ việc ra quyết định chính xác hơn. Cách vận hành kiểu thực nghiệm của pull system cũng giúp nhóm tìm ra quy trình cho chính mình, giúp loại bỏ trở ngại, tăng năng suất và chất lượng công việc.

Về cơ bản, push systempull system khác nhau về hệ quy chiếu đo lường và đánh giá. Push system đo lường và đánh giá số lượng và khối lượng những công việc được hoàn thành; song cả số lượng và khối lượng công việc được hoàn thành không đại diện cho giá trị được tạo ra. Ngược lại, pull system đo lường và đánh gía dựa trên giá trị được tạo ra.

1,080 total views, no views today

Scrum of Scrums là một phương pháp mở rộng rất tự nhiên của Scrum. Thay vì mở rộng nhóm Scrum thành một nhóm lớn hơn; tổ chức duy trì nhóm Scrum vật lý như một thành phần đơn vị và tạo ra sự liên kết giữa những thành phần này thông qua một nhóm Scrum logic.

Hình minh hoạ cho thấy quy mô dự án với 243 nhân sự. Thay vì mở rộng nhóm Scrum thành 243 thành viên (scale out); những nhân sự được tổ chức thành nhiều nhóm Scrum với 9 thành viên mỗi nhóm. Mỗi nhóm Scrum A có 1 thành viên tham gia vào nhóm Scrum ở mức cao hơn để kết nối, đồng bộ, cộng tác công việc giữa các nhóm và hình thành Scrum of Scrums AScrum B; mỗi thành viên trong nhóm Scrum B có 1 thành viên tham gia vào nhóm Scrum C ở mức cao hơn để kết nối, đồng bộ, cộng tác công việc giữa các nhóm.

Những nhóm Scrum A chính là một nhóm Scrum tiêu chuẩn với những thành viên luôn làm việc cùng nhau và gắn kết với nhau; tôi gọi là nhóm Scrum vật lý.

Những nhóm Scrum B, Scrum C bao gồm những thành viên không cố định; tôi gọi là nhóm Scrum logic.

Nhóm Scrum vật lý được tổ chức là một nhóm Scrum tiêu chuẩn, tuân theo những vai trò, sự kiện, artifact được định nghĩa trong Scrum guide. Nhóm Scrum logic thì khác và cần một chút lưu ý.

Thứ nhất, nhóm Scrum logic chỉ xác định số thành viên, không xác định thành viên cụ thể. Bởi trong nhóm Scrum tiêu chuẩn, mọi thành viên trong nhóm đều biết điều gì đang xảy ra trong nhóm, những gì đang được thực hiện, những khó khăn gặp phải và tiến độ hiện tại. Do đó, bất kỳ thành viên nào trong nhóm Scrum vật lý đều có thể tham gia nhóm Scrum logic và cung cấp những thông tin như nhau. Nhóm Scrum A thường sẽ không chỉ định An hay Bình sẽ là người tham gia nhóm Scrum B; bởi bất kỳ ai cũng có thể giam gia với hiệu quả như nhau; chế độ quay vòng là một ví dụ. Ngược lại, việc này cũng giúp mọi thành viên trong nhóm có trách nhiệm trong việc quản lý chung công việc của nhóm Scrum A. Tương tự như vậy với nhóm Scrum B.

Thứ hai, nhóm Scrum logic không có nhiều lý do để thực hiện mọi vai trò, sự kiện như nhóm Scrum tiêu chuẩn. Nhóm sẽ chỉ thực hiện nhanh Sprint Planning cũng như Daily Scrum để đồng bộ công việc với nhau, cũng như tìm ra những công việc đang bị block (tắc) khiến lộ trình có thể bị thay đổi. Việc xử lý những khó khăn gặp phải nói chung vẫn là trách nhiệm của nhóm Scrum vật lý.

Để Scrum of Scrums hoạt động hiệu quả, việc giảm sự ràng buộc giữa các nhóm rất quan trọng. Scrum of Scrums không giới hạn việc cộng tác, trao đổi trực tiếp giữa những thành viên khác nhóm; song nếu việc này xảy ra với tần suất cao, hiệu suất cùng khả năng hướng tới Sprint Goal của nhóm Scrum giảm sút do có quá nhiều ràng buộc. Điều này nói thì dễ, song trong một hệ thống lớn cùng một phần cutting edge phức tạp thì không đơn giản. Khi đó vai trò của việc thiết kế cũng như phân rã chức năng trở nên quan trọng.

Để tăng sự độc lập, những nhóm Scrum A được thiết kế là feature team, làm việc trên một sản phẩm hoặc một nhóm chức năng cụ thể. Tôi không rõ nhóm thực hiện Firebase của Google được tổ chức theo phương pháp nào, song dù chia sẻ một tầm nhìn chung về sản phẩm, Firebase Database, Firebase Testlab… vẫn có sự phân mảnh lớn trong cách cấu hình, sử dụng (console hoặc API…) bởi họ được tổ chức theo feature team. Về mặt kiến trúc bạn có thể không hài lòng bởi việc tích hợp giữa những thành phần này không thực sự tự nhiên và nhất quán; song dưới góc độ phát triển sản phẩm, việc này cho hiệu quả cao bởi Google chỉ mất 12 tháng để cho ra đời một tập lớn dịch vụ hữu ích.

Scrum of Scrums cũng vậy, đây là cách mở rộng rất tự nhiên để tổ chức việc phát triển sản phẩm với quy mô lớn theo phương pháp scale up thay vì scale out. Những phương pháp khác hầu như cũng chia sẻ chung tầm nhìn này, nhưng có sự trưởng thành cao hơn (và đương nhiên, phức tạp hơn).

295 total views, no views today

Month ago, my colleagues complained that our project was slow to build: it normally took 5 minutes, especially in branch switching it took about 10 minutes. Then I found that it doesn’t belong to only our project, it’s the common issue. And here are somethings I have done in our Android project to get its build faster.

Profiling

How long it takes to get your build done? Let’s add the –profile param to have the exact number. In Android Studio, go to Preferences -> Build, Execution, Deployment -> Compiler and set:

Let build. You could file a HTML file in [project_dir]/build/reports/profile/ generated with the detail time spent for each build task, like that:

I recommend you see the report for any optimisation we do in this article to see how good of each param.

Reasons

There are 2 common reasons of the slow build:

Repositories and dependencies

What does Android Studio do when you click on “Sync Gradle” (if build.gradle file is changed) or build a project? Gradle collect all the dependencies. The good news is Gradle uses cache, a folder to store all dependencies to stop going online. The bad news is if Gradle cannot find any specific dependency, it always goes online to scan the repositories (normally is mavenCenter or jcenter); so it’s really slow if your network isn’t good enough.

There are 2 reasons for Gradle cache cannot be used:

  • Dependency version isn’t fixed.

You could use + signal to let Gradle check for the latest version of a dependency, it always get Gradle online

 

  • Gradle version isn’t fixed.

Each Gradle organises the cache itself, no shared the dependency cache. If your team has some Gradle versions, it takes time to switch and download all the dependencies when you switch Gradle version.

Gradle isn’t optimised

Gradle provides some parameters to allow us optimise but they aren’t normally set in Android Studio.

Gradle is slow itself

Gradle is official used and supported by Android Team but it’s not a fastest build tool.

Solutions

The solutions to solves these issues are:

Setup the fixed Gradle and dependency versions

  • Use same Gradle version as your team settings. The good way is using Gradle wrapper instead of local Gradle by creating the gradlew, checkin the source code repository, go to Preferences -> Build, Execution, Deployment -> Build Tools -> Gradle

  • Specific all the dependency version

Use correct Gradle params

There are some Gradle params you could miss:

  • –offline: Force Gradle using cache
  • –configure-on-demand: Let Gradle only builds the relevant projects instead of all projects
  • –daemon: Let Gradle use in-process build and cut down the initial and warm-up state
  • –parallel: Let Gradle builds your projects in parallel if it’s possible
  • –max-workers: Going with –parallel param to let Gradle know how may threads it could use

So normally command line call could be:

Mapping to Android Studio config, they could be:

Go to Preferences -> Build, Execution, Deployment -> Compiler

Go to Preferences -> Build, Execution, Deployment -> Build Tools -> Gradle

Other settings

Other settings could help is increasing the heap size for

  • JVM

  • multiDex

Use another build tool

OK, it’s time to build your project, open the HTML report file to see how much time you saved.

During the study, I found out that there are some faster build tool than Gradle, especially Buck that is using by Facebook. On my demo, it’s super fast. But of course, it isn’t supported by Android Team and its community is very small. The idea of keeping Gradle and Buck builds in parallel is really nice to get it stable by Gradle but also fast by Buck. I will try to get back to it later.

499 total views, no views today

Today I had an accident chance to join an interesting meetup about Craftsmanship in Copenhagen when I visited my company’s office. This event was hosted by NNIT that’s a one of the biggest companies in Denmark and spoken by Mark Seemann, a professional programmer, .NET fan and also a consultant.

It’s the first time I join a meetup in Copenhagen so cannot talk much about that but generally it’s quite good today: very professional and nice place, good speaker, great content, good participants, good free foods and drinks – one reason to attract about 200 people (?) 🙂

This talk was dived into 2 parts. In the first one, about 1 hours, Mark was talking about Software Craftsmanship in his viewpoint: making the good code in humance way by activating System 2 (you could find it, System 1 and System 2 in a great book Thinking, Fast and Slow of Daniel Kahneman). It also shows that a good developers need more soft skills such as psychology, communication… in the top of the toolset. After break, he came back to demo session of how to deal with legacy code by refactoring and adding tests. This example is mostly based on the last post on his blog with some update in the model technology like Entity Framework, DataContext, ApiController… instead of ADO.NET,… but the ideas are still there. Of course, his talk was leaded by some well-known books like Refactoring: Improve the Design of Existing Code of Martin Follower, Working Effectively with Legacy Code of Michael C. Feathers, Clean Code: A Handbook of Agile Software Craftsmanship of Uncle Bob… and Code Katas.

Ok, stop taking about him, do about me 🙂

What makes me happy is these content isn’t new for me compared to the content that we have delivered in annual events of Agile Vietnam. Of course, we always learn something from any meetup but if these things are predictable and doesn’t make our brain work hard, it wouldn’t be new. By comparing the topic quality of a developed country like Denmark, I’m proud of and believe on what Agile Vietnam is delivering to community. It stays up-to-date and world-class. At least, Michael C. Feathers has never talk in Denmark but he had in Vietnam 🙂

But I also feel a bit upset. Mark said “Yes, you are too young and don’t know” after he got laughs by talking a story “There are a lot of company have reference architecture design and they might apply C# style to iOS and Android app project”. It sounds funny, of course. But it’s true: “Yes, you are too young and don’t know”. If you ask a young developers about Agile, TDD, CI… they will tell you as it is only way to build the software today. But why don’t we stop talking about it? There are still the “old” men need to know and need to change. So one of our target is the experienced developers who was tight with the old way and might use C# style for iOS project just because it appears in the reference design. But I’m disappointed that it seems experienced developers don’t want to learn more in Vietnam – there are just few old guys in ours meetups.

But where will we go without learning?

630 total views, no views today

In my opinion, iterating through a collection is very basic and simple thing because it appears in any developer’s code everyday (of course in the languages support collection).

It’s normally my simplest question to start the interview to warmup and make the candidate more confident. But I’m wrong. I’m so surprised that 90% of our candidates, who have been (senior) developers for 2-3 years, cannot give the right answer:

Let say I have a collection LinkedList<int> list. What are differences between 2 types of iterating through list:

and

Most of answer I got is “we can have the index by #1 code that we cannot have in #2 code. The performance are the same.”. But it’s incorrect, #1 is really bad code in performance wise.

The performance are the same in the index-based collection, like array or ArrayList. But #1 code is very slow in other collection like LinkedList. The reason is for getting the item at index i (by calling get(i) method), LinkedList needs to iterate from the first item with the counter set to 0, increase it in each step and stop when the counter reach to i. So while the notation of #1 code is O(N2), the notation of #2 code is O(N).

#2 code actually works as

#3 code is exactly the way #2 code works before Java introduced for each syntax.

The best solution is always use #2 code for iterating through any collection. If you are worry about the index, another code would be:

Java is just a used language here but I believe this way works in any language today. Whatever the technology you are chasing, let start from the basic things, language and data structure.

472 total views, no views today