Giả lập Raspberry Pi trên OS X và Ubuntu

Tại sao phải giả lập Raspberry Pi?

Nếu bạn muốn chạy một đoạn code/ứng dụng trên Raspberry Pi mà không muốn lúc nào cũng phải vác kè kè một em bên cạnh thì bạn nên thử giải pháp giả lập Raspberry Pi ngay trên desktop/laptop.

Việc phát triển ứng dụng/testing với một Raspberry Pi ảo cũng có phần tiện lợi hơn khi bạn không còn phải làm tùm lum thứ như:

  • Cấp nguồn Raspberry Pi.
  • Setup wifi/ethernet, ip tĩnh/động, kết nối máy tính vào cùng mạng LAN, dò tìm IP…
  • Nếu cần tương tác trên môi trường Graphic thì bạn còn phải kết nối với màn hình…

Trong khi đó bạn chỉ cần 1 câu lệnh start Raspberry Pi ảo và 1 câu lệnh ssh vào con Raspberry Pi ảo đó là bạn đã có thể tự do vọc vạch các kiểu bạn muốn. Và hơn nữa, bạn muốn có bao nhiêu con Raspberry Pi cũng được, tùy thuộc vào laptop/desktop của bạn “chơi” được tới mức nào.

Một vài ứng dụng bạn có thể làm với con Raspberry Pi ảo:

  • Chạy thử code python
  • Build code C/C++/Golang thành file bin. Những file bin này có thể chạy tốt trên các con Raspberry Pi thật.
  • Customize image cho Raspberry Pi (tối ưu hóa, thêm xóa sửa, tạo image mẫu…). Và nếu bạn burn những image đã customize này lên những con Raspberry Pi thật thì chúng vẫn chạy tốt.

Giả lập Raspberry Pi với QEMU

Sau một thời gian mày mò tìm kiếm thì cách giả lập Raspberry Pi trên các máy ảo quen thuộc như VMware, Virtualbox, Parallels… thì mình phát hiện ra QEMU. QEMU, VMware và Virtualbox đều giống nhau ở chỗ giúp ta mô phỏng một máy tính trên một máy tính khác nhưng VMware, Virtualbox lại không thể giả lập được bộ vi xử lý ARM (CPU của Raspberry Pi). Với một cơ chế khác biệt, QEMU lại có thể hỗ trợ giả lập nhiều loại Processor: ARM, PowerPC, x86…

Nếu bạn muốn nhanh chóng giả lập Raspberry Pi mà không cần tuỳ chỉnh gì thì có thể thực hiện theo cách 1. Còn nếu bạn muốn tìm hiểu chút xíu để có thể custom một image Raspberry Pi gốc cho trình giả lập QEMU thì hãy chuyển đến cách 2.

Cách 1: Mì ăn liền

Bạn cần làm 3 việc sau:

  • Cài đặt Qemu.
  • Downoad Raspberry Pi image và Kernel.
  • Chạy lệnh.

Cài đặt QEMU

Trên MAC OSX:

Trên Ubuntu:

Download Raspbian image & Kernel

Khi download về, bạn nhớ unzip và bỏ chúng vào cùng thư mục.

Chạy giả lập Raspberry Pi

cd đến folder chứa kernel và image, và chạy lệnh sau:

Xong!

Ngay khi bạn chạy lệnh trên, một cửa số giao diện của QEMU sẽ mở tra. Chờ khoảng 1 phút để con Raspberry Pi ảo của bạn khởi động xong, bạn sẽ thấy trên màn hình thế này:

Giao diện QEMU

Trên giao diện terminal bạn dùng để start QEMU và trên cửa sổ QEMU đều cho phép bạn login vào con Raspberry Pi ảo này. Ngoài ra bạn còn một lựa chọn khác đó là ssh vào Raspberry Pi ảo với dòng lệnh sau:

Đăng nhập vào Raspberry Pi giả lập

Tài khoản login mặc định ban đầu của Raspberry Pi:

user: pi

password: raspberry

Cách 2: Vừa làm vừa vọc

Cài đặt QEMU

Trên MAC OSX:

Trên Ubuntu:

Download Raspbian image & Kernel

Lưu ý: Ở đây tôi sử dụng bản Raspbian Wheezy 2015-05-05, nếu bạn sử dụng các phiên bản khác, kết quả có thể khác bên dưới.

Bạn nhớ unzip và để chúng vào cùng thư mục.

Tạo giả lập Raspberry Pi

Đầu tiên là chạy lệnh này để config vài thứ:

Nếu tên image không phải là raspbian_latest.img thì bạn nhớ đổi tên image trong câu lệnh trên nhé.

Bạn sẽ thấy cửa sổ QEMU mở lên, nó chạy đến đoạn này:

Cửa sổ QEMU

Bạn đang login với quyền root rồi đấy. Giờ thì chúng ta cần config một xíu để QEMU “nhận mặt ổ cứng” của con Pi ảo. Bạn chạy 5 lệnh sau: 

Giải thích:

  • Lệnh 1: Chúng ta mở file /etc/ld.so.preload và thêm dấu # vào trước mỗi dòng
  • 3 lệnh tiếp theo: Kết quả của 3 lệnh này là file /etc/udev/rules.d/90-qemu.rules được tạo ra với nội dung như sau:
  • Lệnh cuối cùng: “tắt” raspberry

Giờ chúng ta sẽ khởi động QEMU lần 2. Lần này mình dùng lệnh sau, hơi khác lệnh lúc nãy chút xíu:

Và dùng lệnh:

để ssh vào Raspberry Pi hoặc tương tác trực tiếp từ cửa sổ QEMU. Nếu bạn đang thao tác trong cửa sổ QEMU, bạn có thể vào chế độ graphic bằng cách chạy lệnh sau:

Khi bạn đang ở trong con Pi ảo, bạn có thể thử kiểm tra dung lượng “ổ cứng” của “Raspberry Pi ảo” với lệnh

df -h

Nếu bạn muốn tăng dung lượng “ổ cứng” cho Raspberry Pi ảo thì:

  • Tắt con Pi ảo này
  • Chạy lệnh sau trong terminal
  • Khởi động lại con Pi ảo của bạn

Kinh nghiệm + đánh giá:

  • Đã thử thành công với  2015-02-16-raspbian-wheezy.img2015-05-05-raspbian-wheezy.img trên OS X YosemiteUbuntu 14.04. Nếu bạn sử dụng các image khác và trên phiên bản hệ điều hành khác thì có thể quá trình giả lập Raspberry Pi không thành công.
  • Kernel-qemu được compile cho CPU ARM1176, tương đương với Raspberry Pi A/B/A+/B+/zero/Computer-module.
  • QEMU không mô phỏng GPU. Nếu bạn thử dùng omxplayer, bạn sẽ thấy lỗi:

QEMU không hỗ trợ GPU

  • RAM cho con Raspberry Pi ảo được ấn định ở mức 256MB. Mình đã thử tìm cách nâng mức này lên nhưng vẫn chưa thành công.
  • Trong giao diện graphic, nhiều lúc thanh taskbar không hiển thị được, hiện chưa tìm ra cách fix lỗi này. Tuy nhiên bạn có thể click chuột phải để có thể mở chạy những ứng dụng khác.

Tham khảo

Bài viết của mình có tham khảo thông tin từ các nguồn sau:

Kiểm thử tự động ứng dụng Android bằng Calabash

Giới thiệu về Calabash

Calabash là một ứng dựng nguồn mở và miễn phí để kiểm thử tự động các ứng dụng di động. Nó là ứng dụng đa nền tảng và hỗ trợ cả iOS và Android. Calabash bao gồm những thư viện cho phép tương tác với các native app và hybrid app giống như người dùng cuối bao gồm các hành động như giả lập cử chỉ, xác định đúng sai và chụp hình màn hình…

Yêu cầu

  • JAVA JDK
  • ANDROID SDK
  • RUBY

Lưu ý: Các bước hướng dẫn bên dưới được thực hiện trên hệ điều hành Mac OS X, sẽ không khác mấy đối với các hệ điều hành Linux. Nếu bạn đang sử dụng Windows, hãy tham khảo bài viết này để cài đặt Calabash.

Chuẩn bị

Cài đặt Java JDK

Các bạn tải và cài đặt tại đây: Java JDK

Cài đặt Android SDK

Tải và cài đặt Android SDK tại Android SDK Stand alone download.

Sau khi tải về máy, giải nén hoặc cài đặt (tuỳ hệ điều hành), chúng ta phải cấu hình biến môi trường ANDROID_HOME và PATH với 2 thư mục platform-tools và tools trong thư mục của Android SDK.
Thiết lập ANDROID_HOME bằng cách gõ lệnh sau vào terminal:

/path/to/your/android/sdk/folder là đường dẫn tới folder lưu SDK của bạn, chẳng hạn như của mình sẽ là /Users/hoaiviet/Documents/android-sdk

Và thiết lập lại PATH:

Sau đó nhớ thêm 3 dòng lệnh trên vào ~/.bash_profile hoặc ~/.zshrc (nếu bạn dùng zsh). Khởi động lại terminal hoặc chạy lệnh:

Cài đặt Ruby

Để tiện quản lý các phiên bản ruby, bạn có thể sử dụng rbenv hoặc RVM.

Trong bài này, mình sẽ sử dụng rbenv trên Mac OS X. Trước hết, máy bạn phải có Homebrew, nếu chưa có thì bạn phải cài đặt trước khi cài đặt Ruby bằng cách chạy lệnh sau trong terminal (lưu ý lệnh ruby ở đây là phiên bản được cài sẵn của Mac OS X):

Tiếp theo là cài đặt Ruby (ở đây mình sử dụng phiên bản 2.2.3), các bạn hãy làm theo các bước như bên dưới:

Nếu kiểm tra ruby -v không đúng với version 2.2.3 thì các bạn hãy paste những đoạn sau vào cuối file ~/.bash_profile:

Khởi động lại terminal hoặc chạy lệnh:

Cài đặt gem calabash-android

Sau khi đã cài đặt xong Ruby thì chúng ta cần cài đặt gem Calabash cho Android bằng cách chạy lệnh:

Đăng nhập vào ứng dụng Skype bằng Calabash

Khởi tạo thư mục test

Các thứ mà bạn cần chuẩn bị là:

  • Một thiết bị chạy hệ điều hành Android hoặc chương trình giả lập thiết bị Android.
  • Tập tin APK của ứng dụng bạn muốn test.
  • Sublime Text hoặc bất kì một Text Editor nào bạn đã quen sử dụng.

Trong bài này mình sẽ dùng Skype để demo cho bạn thấy cách sử dụng Calabash.

Tạo 1 thư mục mới:

Chuyển đến thư mục vừa tạo:

Tiếp theo chúng ta sẽ để Calabash tạo các thư mục và tập tin cần thiết bằng lệnh:

Calabash sẽ yêu cầu bạn nhấn Enter để tiếp tục, hãy nhấn Enter và bạn sẽ có cấu trúc một thư mục Calabash như sau:

Cấu trúc thư mục Calabash

Ở đây, bạn cần quan tâm đến 2 thứ:

  1. Thư mục step_definitions: Sẽ chứa các tập tin ruby mà bạn sẽ định nghĩa các bước, ví dụ như nhấn nút nào, gõ những kí tự gì.
  2. Các tập tin có đuôi .feature là những tập tin mà bạn sẽ viết Scenario, Test cases của ứng dụng.

Bước tiếp theo, hãy chép tập tin APK của ứng dụng bạn muốn test vào thư mục vừa tạo, sau đó resign ứng dụng:

Nếu như khi chạy lệnh trên mà bị báo lỗi thiếu keystore thì chúng ta sẽ tạo mới bằng lệnh

Viết scenario đầu tiên

Bắt đầu chúng ta hãy mở file my_fist.feature bằng Sublime Text, chúng ta sẽ thấy như hình:

Scenario đầu tiên

Calabash hỗ trợ cú pháp của Cucumber, bạn có thể tham khảo cách viết các step trong scenario ở đây.

Quay lại với tập tin feature, chúng ta hãy định nghĩa 1 scenario đơn giản cho chức năng đăng nhập bằng Skype Name:

Xong rồi, chúng ta bắt đầu sửa file my_first.feature theo các step chúng ta đã viết ở trên:

Bước cuối cùng là chạy test. Để chạy được trên thiết bị thật thì các bạn nhớ cắm dây USB và bật USB Debugging lên nhé. Tốt nhất các bạn nên kiểm tra bằng câu lệnh:

OK bây giờ chúng ta hãy chạy thử

Hãy xem thiết bị và kết quả

Chưa định nghĩa bước nhập mật khẩu

Bước 1 và 2 chúng ta đã chạy OK nhưng tới bước 3 thì Calabash báo là chúng ta chưa định nghĩa step này. Giờ chúng ta sẽ định nghĩa nó. Bạn hãy mở tập tin calabash_steps.rb trong thư mục step_definitions và thêm hàm sau để định nghĩa step trên

Và bây giờ chúng ta chạy test lại lần nữa:

Kết quả chạy lại test

Tất cả đều passed.

Xuất báo cáo

Các bạn sẽ tự hỏi, tất cả thông báo các steps pass và fail đều hiện lên trên terminal như vậy thì lưu lại báo cáo kiểu gì phải không? Tất nhiên là Calabash có hỗ trợ lưu báo cáo dưới dạng tập tin, và cụ thể là HTML và báo cáo trông cũng rất là “cool”.

hoặc

và đây là tập tin báo cáo được xuất ra:

Báo cáo chạy test

Một số mẹo khi sử dụng Calabash

Test cụ thể một feature nào đó

Đơn giản là bạn chỉ cần dẫn tới tập tin feature đó là được

Test cụ thể một @tag nào đó

hoặc

Xoá dữ liệu của ứng dụng

Cách 1: Dùng tag @reset

Các bạn chỉ cần thêm đoạn code sau vào file feature/support/app_installation_hooks.rb bên trong Before

Còn tại feature, chúng ta chỉ cần thêm tag @reset vào trước Scenario:

Cách 2: Viết một step để xoá dữ liệu

Tập tin nào sử dụng step này thì trước tiên chúng ta phải require app_installation trước

rồi viết step

Lưu ý: Khi dử dụng step dạng này thì bạn nên có thêm thời gian đợi nhé

Xem ID, Class của các đối tượng

Các bạn hãy dùng uiautomatorviewer có sẵn trong thư mực tools của ANDROID SDK

uiautomatorviewer

Debugging và test các steps của bạn

Tại đây các bạn có thể nhập các hàm của mình vào để test và xem kết quả trên thiết bị.

Nếu bạn có thắc mắc hay ý kiến thì cứ thoải mái comment bên dưới nha!

5 bước cơ bản để tạo một datatable plugin cho jQuery

Bài viết này dành cho những bạn nào thích tìm hiểu các phương pháp giải quyết vấn đề với jQuery trong quá trình phát triển front-end. Qua bài viết này, bạn sẽ học được cách viết một datatable plugin cho jQuery (tìm hiểu thêm về datatable tại đây: https://www.datatables.net).

Nội dung tổng quát:

  1. Tạo 1 plugin đơn giản trong jQuery
  2. Thêm dòng mới trong table
  3. Xoá dòng trong table
  4. Tìm kiếm trong table
  5. Sắp xếp các dòng trong table

Bước 1: Tạo một plugin cho jQuery

Ở bước này ta sẽ tìm hiểu cách tạo ra 1 plugin đơn giản trong jQuery. Trước hết, chúng ta cần hiểu một chút về hoạt động của jQuery. Ví dụ:

Đây là 1 đoạn code cơ bản cho những ai đã dùng qua jQuery. Vậy hoạt động đằng sau đoạn code này là gì? Khi ta dùng dấu $ để chọn 1 DOM element (trong ví dụ là div) thì nó sẽ trả về 1 jQuery object. Object này sẽ chứa tất cả những phương thức (.css(), .click(), v.v…) và áp dụng cho những element nào phù hợp với selector (trong ví dụ là tất cả thẻ div), object này sẽ có những phương thức từ $.fn object. Giờ chúng ta cần 1 plugin datatable (mình đặt là MyDatatable) thì ta sẽ có định nghĩa sau đây:

  1. Tham số cấu hình: những tham số mặc định cho plugin sử dụng
  2. Gộp tham số: gộp những tham số
  3. Hàm xử lý: logic xử lý chính của plugin

Biến $ thường được sử dụng phổ biến trong các thư viện của javascript sẽ dễ bị xung đột với plugin này của chúng ta nên cần phải đưa đoạn code trên vào 1 scope để giải quyết vấn đề này. Ta sẽ có:

Lúc này ta hoàn toàn có thể gọi plugin MyDatatable bằng đoạn code

Giả sử ta cần cấu hình tham số mặc định và có thể thay đổi nó khi gọi plugin ta dùng cách sau đây:

Thay đoạn code

thành

Và khi ta gọi plugin này theo đoạn code:

Thì tham số mặc định sortable của plugin sẽ mang giá trị là true. Việc gộp tham số này sẽ dựa vào đoạn code

Và như vậy trong quá trình sử dụng, biến settings là 1 biến nội bộ của plugin MyDatatable cho các bạn sử dụng và có thể linh hoạt điều chỉnh dễ dàng và tường minh hơn trong code.Bạn có thể tham khảo các bước định nghĩa nâng cao hơn tại Advanced jQuery Plugin Concepts.

Bước 2: Thêm dòng mới trong table

Bước 1 vừa rồi, ta đã biết làm thế nào để định nghĩa 1 plugin cơ bản. Giờ chúng ta sẽ bắt đầu viết phương thức thêm 1 dòng mới trong table cho plugin MyDatatable. Giờ ta sẽ có file index.html và file MyDatatable.js được định nghĩa như sau:

File MyDatatable.js đã có bổ sung thêm định nghĩa các phương thức thực hiện. Ở đây mình lấy phương thức methods.load để thực hiện thêm 100 dòng vào table bằng các dùng hàm append(). Đối với những bạn sử dụng jQuery lần đầu tiên tiếp xúc với việc thêm 1 hoặc nhiều elements sẽ dùng append() để thêm code html vào bên trong element. Đây là cách không tốt vì hàm append() sẽ chuyển kiểu chuỗi thành các node DOM rồi mới thêm vào trong node cha (node cha trong ví dụ này là tbody.container). Bất lợi của việc sử dụng phương pháp này là:

  • Tốc độ sẽ càng chậm nếu số lượng node có trong chuỗi append vào càng phức tạp.
  • Thay đổi cấu trúc html trong chuỗi append càng khó khi nó càng phức tạp.
  • Sử dụng html trong file .js làm cho code không tường minh, phụ thuộc lẫn nhau giữa js và html.

Từ những bất lợi đó, mình sẽ đề xuất 1 giải pháp thao tác hoàn toàn trên DOM giúp tăng tốc độ, tách biệt code html và js để dễ dàng thay đổi, bảo trì.

Ta thay đổi 2 file trên như sau:

Ý tưởng của đoạn code thay đổi ở trên như sau:

  • Có 1 node DOM ẩn chứa đầy đủ cấu trúc của 1 dòng trong table để trong code js không cần phải tạo thêm cấu trúc này nữa.
  • Dùng hàm clone() để sao chép 1 node DOM
  • Dùng hàm find() của jQuery để tìm kiếm
  • Dùng hàm html() để thay đổi html bên trong node DOM (có thể thay đổi tương tự với các thuộc tính khác của DOM như value, attrs, props,…)
  • Dùng appendTo() để thêm node DOM vào node cha và hàm show() để hiển thị lên trình duyệt.

Với phương pháp này ta đã giải được bài toán thêm 1 node DOM phức tạp với tốc độ nhanh hơn vì bỏ qua bước chuyển đổi về node DOM như cách hàm append() hoạt động.

Bước 3: Xoá dòng trong table

Ở bước này, ta sẽ tìm hiểu được việc tương tác với 1 dòng trong table, cụ thể là thao tác xoá đi 1 dòng. Ta thay đổi đoạn code trong file MyDatatable.js như sau:

Đoạn code mới này bổ sung việc bắt sự kiện click() của mỗi dòng trong table, sự kiện này sẽ gọi 1 hàm trong plugin là hàm methods.removeRow(). Thứ tự thực hiện việc xoá này như sau:

  • Xác định dòng nào trong table đang được click
  • Lấy giá trị id của dòng
  • Lấy giá trị id để thực hiện gọi ajax với mục đích thay đổi trên server
  • Xoá dòng khỏi table bằng hàm remove() trong jQuery

Với ý tưởng tìm theo node DOM này, các bạn có thể tư duy để thiết kế được làm thể nào để thực hiện thao tác sửa trong datatable rồi nhé.

Bước 4: Thêm tính năng tìm kiếm cho table

Trong datatable thì chức năng tìm kiếm rất hữu ích nên mình sẽ giới thiệu 1 phương pháp sau đây. Ta thay đổi code như sau:

Ý tưởng của đoạn code mới như sau:

  • Thêm 1 text input vào cấu trúc của html dùng để tìm kiếm
  • Bắt sự kiện keyup của input này trong hàm init() của plugin. Ở đây chọn keyup vì ta sẽ tìm kiếm trên table mỗi khi 1 ký tự được nhập
  • Duyệt tất cả các dòng trong table
  • Duyệt các cột trong các dòng trên, nếu phù hợp thì hiển thị dòng, không phù hợp sẽ ẩn dòng. So sánh sử dụng hàm indexOf() với 2 giá trị so sánh được đưa về chữ thường (lowercase).

Như vậy ta đã có được 1 ô tìm kiếm cho tất cả các cột trong bảng. Vậy bài toán dành cho các bạn mở rộng thêm đó là làm thế nào để chúng ta có 1 ô tìm kiếm cho 1 cột trong bảng. Theo ví dụ trên ta sẽ có 1 ô tìm kiếm theo ID, 1 ô tìm kiếm theo Name và 1 ô tìm kiếm theo Score.

Bước 5: Sắp xếp các hàng trong table

Ý tưởng thực hiện như sau:

  • Thêm 1 nút bấm (button) để sắp xếp
  • Luân phiên thay đổi thuộc tính data-sort của nút bấm: 1 là tăng dần, -1 là giảm dần.
  • Sắp xếp table dựa vào cột Name, hàm sort() trong jQuery là yếu tố quyết định trong trường hợp này. Để giải mã đoạn code return nameB.localeCompare(nameA) * type. Các bạn xem thêm tại https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort. Hàm sort sẽ trả về 1 mảng là các dòng trong table đã được sắp xếp tăng hoặc giảm theo cột Name.
  • Append lại tất cả các phần tử thuộc mảng sau khi sắp xếp vào container.

Và bài toán mở rộng cho các bạn là mỗi khi bấm vào header của cột (thead) sẽ sắp xếp tăng giảm theo cột đó.

Toàn bộ code và kết quả:

Như vậy mình đã vừa chia sẻ xong cách cơ bản đề hoàn thành 1 plugin datatable cho các bạn cũng như một số lưu ý và phương pháp thao tác trên DOM trong jQuery. Hy vọng với sự sáng tạo và đam mê của mình, các bạn sẽ hoàn thiện plugin này và đóng góp thêm nhiều những plugins có ích khác nữa nhé.

Lập trình ứng dụng nhúng với thư viện EMBD của Go

Khi phát triển các ứng dụng nhúng (embedded application), tôi thường sử dụng C, C++ hoặc Python là chủ yếu. C và C++ có hiệu suất xử lý cao nhưng tốn nhiều thời gian để viết các chương trình mẫu và phát triển những ứng dụng có logic phức tạp. Đó là chưa nói đến việc phải xây dựng lại hoặc thay đổi mã nguồn khi muốn sử dụng ứng dụng trên một hệ thống phần cứng khác.

Mặt khác, Python tiện lợi để phát triển ứng dụng hơn vì nó là ngôn ngữ đa nền tảng. Nhưng Python có một khuyết điểm là hiệu suất xử lý không được tốt cho lắm. Vì vậy, tôi đã đi tìm một ngôn ngữ có thể đáp ứng được lợi thế của chúng về tốc độ và thời gian phát triển.

Gần đây, tôi phát hiện ra Go, một ngôn ngữ lập trình được phát triển tại Google vào năm 2007 bởi Robert Griesemer, Rob Pike, và Ken Thompson. Nó là ngôn ngữ kiểu tĩnh (statically typed language) với cú pháp lấy cảm hứng từ C, thêm garbage collection, type safety, những kiểu dữ liệu được định nghĩa sẵn và một thư viện chuẩn khổng lồ.

Go cung cấp cú pháp và một môi trường để xây dựng một ứng dụng nhanh và thú vị như ngôn ngữ kịch bản (scripting language). Ngoài ra, do Go là một ngôn ngữ biên dịch nên hiệu suất xử lý của nó cũng rất tốt. Nghe có vẻ thích đúng không? Nó có mọi thứ tôi cần nên tôi quyết định dùng nó để xây dựng thử một ứng dụng nhúng.

Bỏ chút thời gian tìm kiếm, tôi phát hiện thư viện EMBD. EMBD là thư viện cung cấp các lớp phần cứng trừu tượng (hardware abstraction layer) để phát triển các ứng dụng nhúng cho Go. EMBD hỗ trợ nền tảng của Raspberry PiBeagleBone Black. Hơn thế nữa, ứng dụng có thể chạy trên các nền tảng được hỗ trợ mà không cần phải thay đổi mã nguồn.

Trong bài này, bạn sẽ học được cách sử dụng EMBD với Go thông qua hai ví dụ đơn giản.

Chuẩn bị

Cài đặt Go

Bạn vào trang download của Go để tải bản cài đặt phù hợp với hệ điều hành của mình về. Nếu bạn sử dụng Windows hay Mac OS X thì phiên bản cài đặt của 2 hệ điều hành này đã cấu hình sẵn mọi thứ cho bạn. Nếu bạn sử dụng Linux thì có thể đọc hướng dẫn cài đặt Go.

Tiếp theo là thiết lập GOPATH:

  • Windows: thêm GOPATH=[đường dẫn đến workspace của bạn] vào Environment Variables.
  • Mac OS X, Linux: thêm dòng export GOPATH=[đường dẫn đến workspace của bạn] vào ~/.profile hoặc /etc/profile

Bạn có thể tham khảo thêm cách Go cấu trúc thư mục khi phát triển ứng dụng Go.

Cài đặt EMBD

Chạy lệnh sau ở terminal:

Sử dụng thư viện EMBD để xây dựng ứng dụng nhúng

Ví dụ 1 – Làm đèn led của Raspberry Pi nhấp nháy

Bước 1: Tạo tập tin embd_buildin_light.go đặt trong thư mục src với nội dung như sau:

Bước 2: Biên dịch ứng dụng cho Rasberry Pi (hệ điều hành Linux, kiến trúc arm):

Bước 3: Chép tập tin embd_buildin_light vừa được biên dịch vào Raspberry Pi

Bước 4: Chạy ứng dụng với quyền root

Bạn cần quyền root để chạy lệnh này để cho phép EMBD truy xuất đến các phần cứng của hệ thống.

Kết quả:

Bonus: Thay đổi một chút đoạn code trên sẽ cho kết quả thú vị hơn

Ví dụ 2 – Điều khiển digital input của Raspberry Pi

Bước 1: Lắp mạch điện như hình sau

Raspberry Pi with a led

Bước 2: Viết và biên dịch mã nguồn

Bước 3: Chép vào Raspberry Pi và chạy thử

EMBD còn làm được gì nữa?

Với hai ví dụ trên, bạn sẽ thấy thật dễ dàng khi sử dụng thư viện EMBD để phát triển các ứng dụng cho Raspberry Pi. Bên cạnh đó, EMBD còn hỗ trợ tương tác với:

PWM pin

Analog pin

Và nhiều linh kiện quen thuộc khác như:

  • TMP006 Thermopile sensor
  • BMP085 Barometric pressure sensor
  • BMP180 Barometric pressure sensor
  • LSM303 Accelerometer and magnetometer
  • L3GD20 Gyroscope
  • US020 Ultrasonic proximity sensor
  • BH1750FVI Luminosity sensor
  • Membrane 3×4 Matrix Keypad
  • PCA9685
  • MCP4725

Bên cạnh EMBD, bạn còn biết thư viện nào khác hỗ trợ xây dựng ứng dụng nhúng cho Go thì comment bên dưới nha.

Công việc của một Product Manager

Product Manager (Người quản lý sản phẩm – PM) là một trong những công việc khó định nghĩa nhất trong bất kỳ tổ chức nào, bởi mỗi công ty có một kiểu định nghĩa khác nhau.

Nhiều người nghĩ rằng, công việc của một PM sẽ liên quan đến những việc (lĩnh vực) sau:

  • Viết code (Kĩ thuật)
  • Tạo các mock-ups (Thiết kế)
  • Ký kết hợp đồng (Kinh doanh)
  • Lên kế hoạch PR (Truyền thông)

Nhưng thực tế, những việc trên không phải là công việc mà một PM phải làm. Đây mới là những việc mà PM phải làm:

Công việc của một product manager

Hoặc có thể mô tả đơn giản hơn:

Công việc của một product manager nói theo cách đơn giản

  • Business: Bạn là người tìm cách gia tăng tối đa giá trị của  sản phẩm.
  • Technology: Bạn không cần thiết phải là người viết code nhưng bạn phải nắm được công nghệ và kĩ thuật xây dựng nên sản phẩm của mình để có thể đưa ra các quyết định đúng đắn.
  • User Experience: Bạn là người lắng nghe và thấu hiểu trải nghiệm của người sử dụng.

Vì thế theo tôi, công việc của một PM có thể nói tóm gọn là:

Giúp đỡ đồng đội (và công ty) mang đến sản phẩm phù hợp cho người dùng.

Giúp đỡ đồng đội của bạn

1. Giúp đỡ đồng đội

Ai là đồng đội của bạn?

Đồng đội của bạn là những người làm việc trực tiếp với sản phẩm (hoặc một mặt nào đó của sản phẩm). Những người này gồm:

  • Chuyên viên thiết kế, kĩ sư, QA (Quản lý chất lượng), nhân viên marketing.
  • Những đồng nghiệp khác trong các nhóm hỗ trợ như phát triển kinh doanh, chăm sóc khách hàng, tư vấn pháp luật.

Nhiệm vụ của bạn trong nhóm là gì?

Nhiều người mô tả PM như CEO của sản phẩm.

Đây là một mô tả không đúng, nó có phần phóng đại về tầm ảnh hưởng và quyền hạn của một PM. Bạn không phải là Chủ của sản phẩm mà là Người lãnh đạo của nhóm xây dựng và phát triển sản phẩm.

Vì thế, bạn phải dành thời gian ưu tiên để giúp đỡ đồng đội của mình trong:

  • Định hướng – Đảm bảo nhóm lên kế hoạch, ra quyết định, và làm việc với nhau hiệu quả với mục đích và trọng tâm rõ ràng.
  • Giao tiếp – Bảo đảm mọi người đều hiểu chuyện gì đang diễn ra, khi nào, và tại sao, đặc biệt là khi có những thay đổi xảy ra.

Các công việc bạn phải làm:

Giữ nhịp cho nhóm (Set the cadence)

  • Xây dựng lộ trình cho nhóm từ các buổi họp brainstorm (mỗi quý một lần).
  • Kết nối lộ trình sản phẩm một cách rõ ràng và liền mạch.
  • Tổ chức các buổi họp về hoạt động của sản phẩm (định kỳ hằng tuần).
  • ACT SOLID (Hành động chắc chắn).
  • Ghi chú và chia sẻ những lưu ý trong buổi họp.

ACT SOLID (Analytics, Communications, Trust/Safety, Support, Ops, Legal, International, Design) là cụm từ thường dùng ở Twitter để chỉ các nhóm liên quan trong quá trình xây dựng sản phẩm.

Brainstorm hiệu quả

  • Mọi người cùng đề xuất các ý tưởng có thể tạo nên ảnh hưởng lớn cho sản phẩm (tất cả ý tưởng đều được hoan nghênh).
  • Hỏi đáp khi mọi người đề xuất hoặc trình bày ý tưởng.
  • Mọi người bình chọn 3 ý tưởng xuất sắc nhất.
  • Mọi người giải thích tại sao và như thế nào lại bình chọn cho ý tưởng đó.
  • Bình chọn lại một lần nữa.
  • Cuối cùng, bạn sẽ có trong tay 3 bản lộ trình tiếp theo cho sản phẩm.

Việc ghi chép các ý trong một buổi họp rất quan trọng. Hơn nữa, tổng kết và viết lại thành một bản ghi chép tốt thường tốn nhiều thời gian hơn cả cuộc họp.

Quản lý các hoạt động của sản phẩm

  • Chia sẻ các tin tức liên quan đến sản phẩm của công ty cho nhóm của bạn.
  • Dùng trực giác phán đoán khi nào nên đưa ra các tính năng mới càng sớm càng tốt.
  • Học hỏi, rút kinh nghiệm và phân tích các cập nhật, tính năng được ra mắt gần nhất.
  • Đánh dấu lộ trình khi bắt đầu phát triển tính năng mới.
  • Tìm 1-2 chủ đề quan trọng để brainstorm/thảo luận hoặc chia sẻ ở các sự kiện, meetup.

Bạn phải hợp tác với các nhóm khác để nhận phản hồi từ họ, chia sẻ với họ các kế hoạch hiện tại, và đảm bảo không có cản trở hoặc chướng ngại nào trong quá trình ra mắt sản phẩm.

Một nhóm chỉ làm việc hiệu quả nhất khi và chỉ khi mọi người đều sở hữu sản phẩm (own the product) và họ có quyền đóng góp và đề xuất ý tưởng cho sản phẩm đó. Người PM giỏi đưa ra các quyết định quan trọng từ đóng góp của các thành viên và chịu trách nhiệm điều hoà những ý kiến bất đồng, đôi khi bạn bắt buộc phải phá vỡ các ràng buộc, và tập hợp sự đồng thuận của mọi người (hoặc ít nhất đảm bảo họ cam kết làm theo kế hoạch) cho những quyết định quan trọng đó.

Ngoài ra, một nhóm hoạt động hiệu quả không có nghĩa là phải làm theo những gì mà PM cho là đúng. Đôi khi, bạn có thể có những ý tưởng tuyệt vời, nhưng điều lưu ý ở đây là không nên thành lập một nhóm chỉ biết làm việc một cách mù quáng. Thay vào đó, bạn nên xây dựng một quy trình hợp tác để cả đội có thể quyết định công việc nào là ưu tiên cần thực hiện.

PM không làm ra bất cứ thứ gì hữu hình cho một sản phẩm nhưng thành công của một sản phẩm và nhóm làm ra nó không thể thiếu đóng góp của PM.

Mục đích của công ty cũng chính là mục đích của bạn

2. Giúp đỡ công ty

Mục tiêu của công ty cũng chính là mục tiêu của bạn

Là một PM, bạn bắt buộc phải hiểu rõ mục đích và mục tiêu (goals & objectives) của công ty. Và chính xác thì bạn phải làm thế nào để đưa nhóm của mình nằm trong viễn cảnh ấy. Bạn phải lấy tầm nhìn của các founder để làm động lực cho nhóm, giúp họ nhận ra họ đang làm việc để tiến gần đến mục đích đó. Việc hoàn thành các mục tiêu đề ra cho sản phẩm sẽ thúc đẩy chiến lược toàn diện của công ty. Bạn phải khiến họ hiểu rằng họ đang phục vụ cho lợi ích công ty, họ phải hợp tác với các nhóm khác, chứ không đơn thuần là hoàn thành những gì cá nhân họ nghĩ là quan trọng.

Một trong những điều tôi luôn tìm kiếm trong những buổi phỏng vấn tuyển PM là các ứng viên nhắc đến tầm nhìn rộng lớn hơn của công ty thường xuyên như thế nào và họ làm thế nào để đặt mình vào trong viễn cảnh ấy. Cũng giống như giúp đỡ đồng đội của mình, bạn có thể có những ý tưởng tuyệt vời của riêng bạn nhưng bạn nên gắn chúng với tầm nhìn và mục đích của công ty, và đảm bảo chúng được hỗ trợ từ trên xuống dưới để trở thành hiện thực.

Ra mắt sản phẩm

3. Ra mắt sản phẩm

SHIPPING > PERFECTION

Những việc trên chỉ có giá trị khi bạn có thể giúp nhóm của mình đưa sản phẩm đến tay người sử dụng:

  • Đưa ra những điều kiện/yêu cầu rõ ràng khi nào sản phẩm vừa đủ để ra mắt thị trường.
  • Ra quyết định đánh đổi khó khăn giữa hoàn thiện sản phẩm và ra mắt nó.
  • Ưu tuyên tuyệt đối việc ra mắt sản phẩm.

Một người PM giỏi hiểu được sự cân bằng mỏng manh giữa hoàn thiện sản phẩm và đưa nó ra bên ngoài.

Sản phẩm phù hợp

4. Sản phẩm phù hợp

Tin tưởng vào bản thân nhưng vẫn phải biết lắng nghe

Việc đưa sản phẩm ra thị trường tuy quan trọng, nhưng bạn phải giúp nhóm mình đảm bảo đó là sản phẩm phù hợp cho người sử dụng. Bạn có thể giải quyết điều này từ những giải pháp sáng tạo của nhóm và cải thiện chúng từ:

  • Các phản hồi của tester và người dùng thử.
  • Những lời chỉ trích của những người không muốn sử dụng sản phẩm.
  • Góp ý của founder và ban lãnh đạo.
  • Bất kì ý tưởng nào mà bạn bắt gặp.

Kiểm tra kết quả

Một khi sản phẩm được tung ra thị trường, bạn phải đo lường được ảnh hưởng mà sản phẩm mang lại:

  • Lập mục tiêu về tầm ảnh hưởng của sản phẩm mà bạn muốn đạt được.
  • Xác định rõ các thông số mô tả sức ảnh hưởng đó.
  • Lập dữ liệu để biết được cái nào hoạt động hiệu quả và cái nào không.
  • Luôn để mắt đến những bài học bất ngờ trong quá trình phát triển sản phẩm.

Cho người sử dụng

5. Người dùng

Đảm bảo lợi ích của người sử dụng

Phần khó nhất trong xây dựng và phát triển sản phẩm là nắm rõ được trường hợp sử dụng chính. Hãy kể một câu chuyện về ai sẽ sử dụng sản phẩm này và tại sao họ phải dùng nó. Một người PM giỏi nắm rõ người dùng và đại diện cho họ trong hầu hết các buổi họp khi đưa ra các quyết định cho sản phẩm.

Để làm được việc này, bạn phải:

  • Thấu hiểu những thách thức/vấn đề của người sử dụng.
  • Thấu hiểu sản phẩm sẽ mang lại giá trị gì mà người sử dụng đang tìm kiếm.
  • Liên tục lắng nghe những phản hồi (thông qua kiểm tra cách người sử dụng dùng sản phẩm, các buổi họp, gặp gỡ trực tiếp người sử dụng, các tin nhắn trên mạng xã hội, v.v…).

Đừng quên là bạn có thể thu thập những thông tin này thông qua các bộ phận khác trong công ty.

Tổng kết

Những việc mà một PM phải làm:

  • Đưa ra những quyết định quan trọng dựa trên đóng góp của các thành viên trong nhóm.
  • Cân bằng sự bất đồng ý kiến trong nhóm và luôn giữ cho sản phẩm đi đúng tiến độ.
  • Đảm bảo sự nhất trí của các thành viên trong nhóm (dù họ không đồng ý nhưng vẫn phải cam kết làm đúng theo kế hoạch).

Những việc mà một PM không nên làm:

  • Đừng cố gắng xây dựng một thứ mà chỉ có bản thân bạn cho là đúng.
  • Đừng mong đợi nhóm của bạn sẽ làm theo mệnh lệnh một cách mù quáng.
  • Đừng bao giờ quên các đóng góp của mọi người trong quá trình phát triển sản phẩm. (Don’t forget where credit is always due.)

Công việc của bạn không bao giờ kết thúc

Một khi sản phẩm ra mắt thị trường, bạn nên chuẩn bị kế hoạch cho bước đi tiếp theo:

  • Kế hoạch cải thiện sản phẩm (hãy họp với tất cả mọi người trong nhóm).
  • Bổ sung các công đoạn kiếm tra khác.
  • Brainstorm các giải pháp dựa trên dữ liệu và phản hồi thu được.

Sản phẩm sẽ không bao giờ hoàn thiện

Không có sản phẩm tốt nhất (right product), chỉ có cách tốt nhất (right way) để trở thành một nhà quản lý sản phẩm giỏi.

Sự thật là, không có sản phẩm nào phù hợp cho tất cả mọi người, và việc phát triển sản phẩm là một quá trình liên tục và lặp đi lặp lại để làm cho sản phẩm ngày càng tốt hơn. Công việc của một Product Manager giỏi là dẫn dắt đồng đội mình tiến lên phía trước và vượt qua cuộc hành trình đó.

Tổng hợp từ bài viết Let’s talk about Product ManagementA Product Manager’s Job của tác giả Josh Elman bởi Giáp Hồng, Hải An, Kim Tuyến.

Làm quen với Appium thông qua ví dụ đơn giản!!!

Đôi nét về Appium

Appium là một công cụ mã nguồn mở được sử dụng để kiểm thử tự động (test automation) các native app, mobile web app, và hybrid app trên nền tảng iOS và Android.

Đặc biệt là Appium hỗ trợ “đa nền tảng” (cross-platform) cho phép bạn sử dụng API giống nhau để viết test cho các nền tảng khác nhau (iOS và Android). Điều này khá là tiện lợi khi bạn muốn sử dụng lại các test suites của mình.

Bên cạnh đó, Appium hỗ trợ viết test cho rất nhiều ngôn ngữ, từ Java cho đến Ruby, Python, JavaScript…

Dưới đây là bảng so sánh tổng quan giữa Appium và các công cụ kiểm thử tự động khác:

So sánh Appinium và các công cụ khác
Bảng so sánh Appium và các công cụ khác (Nguồn: testdroid)

Cài đặt Appium

Mình mặc định là các bạn đã cài các chương trình sau trong máy:

Các bạn đừng quên cấu hình ANDROID_HOME và JAVA_HOME nha.

Ở đây mình sử dụng IDE là IntelliJ IDEA để viết test bằng ngôn ngữ Java. Bạn có thể sử dụng các IDE khác như Eclipse hay NetBeans cũng được.

Cuối cùng là download bộ cài của Appium Desktop App tùy theo bạn sử dụng Mac hay Windows.

Kiểm thử tự động với Appium thông qua ví dụ đăng nhập vào Skype

1. Chạy Appium server

  • Bước 1: Mở Appium
  • Bước 2: Click Launch

Chạy Appium

2. Cài ứng dụng vào thiết bị Android và mở ứng dụng

3. Kết nối thiết bị vào máy tính

4. Vào thư mục [AndroidSDK]/tools, mở chương trình UI Automator Viewer để lấy resource-id:

uiautomatorviewer

Lấy resource-id

Chúng ta sẽ dùng resource-id để nhận biết các đối tượng như (button, textbox,….) khi code.

Lưu ý: một số trường hợp không có resource-id , các bạn có thể dùng class và index

5. Viết code với  IntelliJ IDEA:

– Mở IntelliJ IDEA.

– Tạo Maven project: Chọn File -> New -> Project -> Chọn Maven project -> Đặt tên GroupID , ArtifactID -> Project name:

Tạo dự án mới

Tạo dự án maven mới

Nhập GroupID và ArtifactID

Nhập tên project

Import thư viện

Lưu ý: đôi khi quá trình import có thể bị lỗi bạn có thể import lại bằng cách: Click phải tên project -> Maven -> Reimport

– Mở file pom.xml thêm các dependency vào:

Chúng ta sẽ được như thế này:

dependencies code

– Import tập tin apk bằng cách chép tập tin .apk  vào src/main/resouces/:

Vị trí file apk

– Tạo package mới:

Tạo new package

Nhập tên package

– Tạo một class Java mới (chúng ta sẽ code testcase trong đây):

Tạo file java

Đặt tên class

– Cấu trúc cơ bản của một test class:

  • @BeforeTest: Chúng ta viết các hàm trước khi chạy test case trong mục này (ví dụ install app, kết nối server…).
  • @Test: Viết các hàm tương ứng với các testcase trong mục này.
  • @AfterTest: Các hành động sau khi chạy hết test cases.

Dưới đây là code mình đã viết để chạy 2 testcase signin của app Skype:

– Chạy các case vừa viết bằng cách click phải class java cần chạy -> Chọn Run:

Chạy testcase

Kết quả sau khi chạy test:

Kết quả test

Rất đơn giản phải không? Còn chờ gì nữa mà không dùng thử Appium cho các ứng dụng cần kiểm thử tự động của bạn đi nào!

Làm sao để developer và tester trở thành bạn tốt của nhau?

Đôi khi developer và tester cãi nhau về lỗi của ứng dụng, và có rất nhiều nguyên do cho chuyện đó: hiểu lầm giữa hai bên, lỗi đó không phải do code, tester báo lỗi sai, v.v… Việc này gây mất đoàn kết trong nội bộ và ảnh hưởng đến công việc chung của cả nhóm. Vậy làm thế nào để giải quyết rắc rối này đây?

Trước hết, chúng ta cùng xem lại định nghĩa về công việc của cả hai:

  • Developer là những người xây dựng và phát triển ứng dụng.
  • Tester là người kiểm tra và  tìm kiếm lỗi trong ứng dụng.

Điều này cho thấy cả hai có lối tư duy khác nhau dẫn đến rất khó để họ làm việc chung với nhau. Nhưng trên thực tế thì developer cũng là tester. Họ kiểm tra code của mình để đảm bảo mọi thứ đều hoạt động, nhưng đôi khi rất khó để nhận ra sai lầm của bản thân. Vì thế mà chúng ta cần đến tester.

Có thể chia tester làm 4 cấp bậc:

  1. Developer viết đoạn code đó
  2. Một developer khác
  3. Tester chuyên kiểm tra và tìm loại
  4. Một công ty chuyên về test

Và cũng có 4 cấp độ của test:

  1. Unit testing: Còn có tên gọi khác là component test, module test. Mục đích chính là tìm kiếm lỗi trong thiết kế của phần mềm, mô hình dữ liệu, xác định các chức năng, cũng như hiệu quả hoạt động của các thành phần. Unit testing thường được thực hiện bởi các developer, có thể là người viết ra nó hoặc là một developer khác trong nhóm. Việc áp dụng unit testing vào ngay những giai đoạn đầu sẽ giúp chúng ta dễ dàng kiểm soát cũng như tìm ra lỗi của phần mềm, giảm khả năng phát sinh lỗi và giảm chi phí quá trình xây dựng sản phẩm.
  2. Integration testing: Tập trung vào test sự tương tác của các thành phần. Cách tốt nhất để thực hiện integration testing chính là chúng ta sẽ “tích hợp” những phần mà chúng ta cho rằng khi kết hợp với nhau nó sẽ gây ra lỗi. Mức độ test này thường được thực hiện bởi một nhóm chuyên về integration test hoặc là nhóm tester.
  3. System testing: Đảm bảo sản phẩm sẽ đáp ứng được yêu cầu của khách hàng khi chạy thử. Bên cạnh đó là tìm được càng nhiều lỗi trong mức có thể càng tốt. Chúng ta sẽ đưa ró ra môi trường giống như thực tế (như môi trường khi lên production) để chắc chắn xem phần mềm có chạy ổn định, đúng đặc tả hay chưa, có đáp ứng yêu cầu kinh doanh hay không. Và người chịu trách nhiệm về system testing là những đội test chuyên biệt hay đội test độc lập – những tester có hiểu biết về tất cả các lĩnh vực từ kinh doanh đến kỹ thuật hay thiết kế.
  4. Acceptance testing: Sau khi phần mềm đã được sửa hết những lỗi được phát hiện. Chúng ta chuyển sản phẩm cho khách hàng. Người sử dụng và khách hàng là người chịu trách nhiệm cho acceptance testing. Họ đảm bảo phần mềm hoạt động đúng theo những yêu cầu mà họ đã đề ra. Có những công việc liên quan đến mức độ test này như là khả năng backup/restore, bảo mật…

Tester thường cảm thấy phấn khích khi tìm được những lỗi nghiêm trọng, đặc biệt là những lỗi dẫn đến ứng dụng bị tắt đột ngột (crash). Nhưng developer thường biện hộ rằng lỗi này không phải do họ gây ra. Vậy làm thế nào để developer và tester hiểu nhau hơn?

Theo kinh nghiệm làm QA của mình:

  • Việc đầu tiên, bạn phải kiểm tra cẩn thận lại lỗi bạn vừa tìm được. Đảm bảo bạn có thể tạo ra lỗi đó một lần nữa, ghi lại các bước thực hiện để phát sinh lỗi và chụp lại màn hình.
  • Việc tiếp theo, bạn báo cáo lỗi này cho nhóm của mình, đặc biệt là developer. Công đoạn này rất quan trọng, tìm lỗi dễ hơn là báo lỗi. Bạn có thể liệt kê được nhiều lỗi, nhưng để developer có thể sửa được chúng còn phụ thuộc vào loại lỗi bạn tìm thấy và cách bạn giao tiếp với họ.

Bạn phải có kinh nghiệm trong việc testing để biết được lỗi nào là đúng – lỗi đúng là lỗi mà mọi người đều công nhận chứ không phải dựa trên suy nghĩ của bạn. Ví dụ: bạn nghĩ một ứng dụng đọc sách nên có chế độ đọc cho màn hình nằm ngang, đây không phải là lỗi mà là cách sử dụng của bạn, trên thực tế hầu hết người dùng đều đọc sách ở chế độ màn hình dọc.

Giao tiếp cũng là một việc rất quan trọng. Mục đích cuối cùng của developer và tester là tạo ra một sản phẩm tốt cho người sử dụng. Vì vậy, khi nói chuyện với developer, bạn phải truyền đạt được thông điệp đó. Mục đích của việc tìm lỗi là đưa ra các vấn đề cần được giải quyết cho developer chứ không phải là chỉ trích hay phàn nàn về chúng.

Khi báo lỗi, bạn nên dùng những câu như “mình nên thay đổi cái này” thay vì “anh/chị phải thay đổi cái này”, “cái này chưa được ổn lắm” thay vì “cái này làm sai rồi”… Bạn cũng có thể sử dụng một vài công cụ để quản lý và báo lỗi như Trello, Scrumwise… Ví dụ, khi sử dụng Trello: Card của bạn nên có tiêu đề ngắn gọn và thể hiện được nội dung chính của lỗi; bạn nên mô tả đầy đủ về lỗi này và các bước cần thực hiện để tạo ra nó, đính kèm thêm ảnh chụp hoặc ảnh động gif, làm thế sẽ khiến lỗi rõ ràng hơn; thêm các thành viên khác vào card bên cạnh bạn như developer, project manager…

Nếu bạn thực hiện được những điều này, mình nghĩ developer sẽ vui vẻ khi nhận các thông báo lỗi từ bạn.^_^

Liệu bạn có sở hữu tư duy của một người quản lý?

Julie Long là senior developer của một công ty phần mềm. Hiệu quả công việc của cô được sếp đánh giá rất cao. Cô đã rất phấn khích về cơ hội được thăng chức lên vị trí quản lý khi được yêu cầu hướng dẫn một nhóm ba bạn junior developer cho một dự án. Nhưng chưa bao lâu, cô đã chán nản và bực bội. Những việc đối với cô vô cùng dễ dàng và đơn giản lại trở nên khó khăn và tốn nhiều thời gian đối với nhóm ba bạn ấy. Khi Julie đánh giá lại code của các thành viên trong nhóm sau vài tuần làm việc, cô có suy nghĩ muốn quăng chúng vào sọt rác và tự mình viết lại toàn bộ. Cô biết rằng, kết quả làm việc của ba người bọn họ trong mấy tuần vừa qua chỉ bằng vài tiếng đồng hồ của cô.

Hình ảnh trên rất dễ bắt gặp khi một người được thăng chức từ vị trí chuyên viên/kĩ sư lên làm quản lý, hoặc được yêu cầu dẫn dắt các đồng nghiệp trước đây của mình. Dù lúc đầu mọi thứ rất thuận lợi khi bạn nhúng tay vào tất cả mọi thứ, nhưng đây không phải là hướng giải quyết lâu dài. Cách tốt nhất đối với một người quản lý như bạn là phải tập trung trở thành một người thầy, một huấn luyện viên giỏi để giúp cấp dưới của mình phát triển và trưởng thành. Vì suy cho cùng, mục đích cuối cùng của bạn là nâng cao hiệu quả làm việc của cả nhóm.

Tuy nhiên, để có được tư duy của một người quản lý là một quá trình vô cùng khó khăn đối với nhiều người, và đòi hỏi bạn phải có một sự thay đổi rất lớn trong suy nghĩ. Việc hướng dẫn và chỉ đạo người khác không giống như những công việc thường ngày trước đây của bạn, và rất khó để bạn làm quen với chúng. Bạn nên bắt đầu từ việc theo dõi sự tiến bộ của các thành viên và đừng so sánh họ với chính bản thân bạn. Nếu bạn đánh giá cẩn thận từng người, bạn sẽ sớm nhận ra tài năng của họ, và quá trình trưởng thành của họ sẽ là thước đo cho sự thành công của bạn.

Dưới đây là những điều bạn cần nhớ để đạt được tư duy của một người quản lý. Một số có vẻ rất hiển nhiên, nhưng những điều cơ bản này sẽ rất có ích khi trách nhiệm và áp lực trên đôi vai của bạn ngày càng nhiều hơn.

Tập nhìn về tương lai

Trong khi các thành viên thầm lặng hoàn thành công việc của mình, người quản lý phải biết nhìn xa trông rộng. Người quản lý giỏi dành nhiều thời gian để dự đoán những thách thức, xử lý các tình huống nhạy cảm, và xây dựng một kế hoạch kết nối các thành viên với nhau. Bạn cũng phải suy nghĩ xa hơn những chuyện sẽ phát sinh dù trong điều kiện hoàn hảo nhất và lên các kế hoạch dự phòng cho điều đó.

Muốn nhìn được một khung cảnh to lớn hơn bạn cần phải lưu ý hai việc:

  1. Bạn phải hiểu thấu đáo mục đích và mục tiêu của nhóm, lẫn của cả công ty. Việc này sẽ làm sáng tỏ môi trường  mà nhóm của bạn (hay của công ty) đang hoạt động, và nó cũng giúp bạn ước lượng được kì vọng của cấp trên.
  2. Bạn phải nắm bắt được khả năng của mỗi thành viên trong nhóm. Xác định khả năng của cả nhóm sẽ cho phép bạn lường trước mọi việc tốt hơn khi nhóm của bạn bị thiếu hoặc thừa nhân lực, đồng thời xác lập các mục tiêu phù hợp hơn.

Đặt nhiều câu hỏi hơn

Khi một thành viên gặp rắc rối, bạn có xu hướng đưa ngay cho họ phương án giải quyết (hoặc đích thân bạn giải quyết việc đấy, như Julie ở ví dụ trên chẳng hạn). Dù sao thì bạn cũng biết mình phải làm gì, và đưa ra một giải pháp nhanh chóng sẽ giúp bạn sớm quay trở lại với công việc của mình. Trừ khi bạn muốn nhóm quen việc ỷ lại vào bạn, hãy tạo cơ hội cho họ thử thách bản thân nhiều hơn.

Đặt cho họ các câu hỏi để dẫn dắt họ đến với câu trả lời cũng là một biện pháp tuyệt vời. Hãy để cho họ mô tả những rắc rối họ đang gặp, viết chúng ra (nếu được), và sau đó là phân tích mọi khía cạnh của chúng. Trong nhiều trường hợp, giải pháp sẽ xuất hiện vô cùng rõ ràng khi mọi người bàn luận với nhau. Nếu cách này không khả thi, bạn nên thử đặt các câu hỏi mang tính gợi mở để mọi người nhìn nhận vấn đề ở một khía cạnh mới hoặc phương pháp tiếp cận khác.

Tập trung vào “Cái gì” và “Khi nào”

Khi còn là một nhân viên, bạn được tưởng thưởng cho việc “Làm thế nào” để giải quyết công việc của mình. Bạn có rất nhiều sáng kiến tuyệt vời cho phép bạn làm việc hiệu quả hơn và hoàn thành chúng một cách xuất sắc. Nhưng cách phù hợp với bạn chưa chắc đã phù hợp với người khác, và hơn nữa, họ có thể nghĩ ra những ý tưởng hoặc phương pháp mới mà bạn chưa từng hình dung đến. Biện pháp tốt nhất là đặt mục tiêu để nhóm của bạn tập trung vào việc họ sẽ đưa ra kết quả gìkhi nào hoàn thành, còn việc làm như thế nào thì tùy theo cách của mỗi người.

Tuy nhiên cũng có vài trường hợp ngoại lệ, như khi ai đó nhờ bạn giúp đỡ, hoặc khi bạn thấy một thành viên đang gặp rặc rối. Vào lúc đó, bạn hãy quan sát cách họ xử lý công việc. Hãy tiếp cận tình huống với sự cởi mở, và không nên áp đặt giải pháp của bạn cho họ.

Thêm một lý do để bạn tập trung vào các kết quả mà không phải cách thực hiện là tránh quản lý quá nhiều việc nhỏ nhặt (micro-manage). Không ai thích sếp của mình lúc nào cũng ở bên cạnh nhắc nhở mình nên làm việc thế nào cả. Đó là cách đơn giản nhất để quấy rầy người khác, và nó không làm cho mọi việc suông sẻ hơn.

Tin vào trực giác của bạn

Chuyển sang một vị trí mới có thể phá vỡ cân bằng thường ngày của bạn. Bạn cố gắng học cách suy nghĩ và ứng xử mới, và nó thường mang lại cho bạn cảm giác không còn là chính mình nữa. Nhưng dù sao thì trực giác của bạn vẫn là thứ vô cùng giá trị. Nếu bạn cảm thấy một dự án đang đi chệch hướng, đừng đợi quá lâu để phản ứng. Bạn có thể học cách để trở thành một người quản lý giỏi, nhưng đừng quên trực giác của bạn đối với công việc. Làm thế nào để hoàn thành công việc và để hoàn thành nó một cách đúng đắn rất quan trọng, đặc biệt là đối với những  công việc tương tự như việc bạn đã từng làm trước đây.

Nhiều người mới được lên làm quản lý thường trì hoãn đối mặt với các thành viên đang lỡ kỳ hạn hoặc gặp rắc rối vì họ nghi ngờ trực giác của bản thân hoặc không biết phải làm thế nào để giải quyết vấn đề này cho hiệu quả. Thay vì chờ đợi tình huống trở nên tồi tệ hơn, hãy gặp mặt và trao đổi với nhân viên đó. Hãy đảm bảo là bạn nắm được cách mọi người đang làm việc, cũng như theo sát họ thường xuyên. Khi bạn cảm thấy có gì đó không đúng, hãy tin vào trực giác của mình.

Bạn cần phải nhẫn nại

Thay đổi tư duy từ việc chỉ chịu trách nhiệm cho công việc của chính bạn sang việc có một tầm nhìn rộng lớn hơn của một người quản lý cần có thời gian. Bạn đừng hi vọng học được những kĩ năng này chỉ trong một đêm. Và cũng đừng bỏ cuộc khi bạn bị loạng choạng vì cố gắng giữ cân bằng giữa công việc được giao và phát triển nhóm của mình. Hầu hết chúng ta không phải là một nhà quản lý bẩm sinh. Hãy tin rằng cách suy nghĩ của một người quản lý có thể được học và rèn dũa nhờ cọ sát với thực tế.

Khi gặp những thời điểm khó khăn hoặc cảm thấy bị quá tải bởi chức vụ mới, hãy dừng lại một chút và tự hỏi mình:

  1. Liệu bạn có xem xét các bản đánh giá về điểm mạnh và yếu của các thành viên trong nhóm một cách khách quan, hay bạn đang so sánh họ với bản thân mình?
  2. Liệu bạn có đang nhìn xa hơn, dự đoán các khả năng, thách thức trong tương lai và các kết quả cần đạt được?
  3. Bạn đang đặt câu hỏi nhiều hơn hay đưa ra câu trả lời nhiều hơn?
  4. Bạn có đặt ra mục tiêu cho thời gian hoàn thành và kết quả công việc một cách rõ ràng không, còn việc hoàn thành chúng như thế nào hãy để cho nhóm tự quyết định?
  5. Liệu bạn có đang nghi ngờ trực giác của bản thân?
  6. Liệu bạn có đang nhẫn nại để phát triển các kĩ năng quản lý không?

Dịch từ bài viết Do you have a manager’s mindset?

Biên dịch: Giáp Hồng, Hải An, Kim Tuyến

Tối ưu hiệu suất render để website “mượt” hơn

Optimizing Performance (tối ưu hóa hiệu suất) cho website là một công việc mà bất kỳ front-end developer nào cũng nên biết, mục đích là để trang web đáp ứng được 3 tiêu chí:

  1. NHẸ: Giảm kích thước trang web và các thành phần đi kèm như javascript, css, hình ảnh… nhằm đảm bảo thời gian tải xuống ngắn hơn. Chúng ta có thể dùng các bộ minify cho javascript, css…, nén các tập tin hình ảnh, font chữ, svg… ngoài ra còn có các kĩ thuật như code splitting, browser caching, HTTP caching…
  2. NHANHHiển thị nội dung trang web càng sớm càng tốt bằng cách: chia cấu trúc DOM hợp lý, hạn chế blocking CSS/JS, hạn chế chỉnh sửa DOM tree, chia các file ra thành nhiều module, tải resource bất đồng bộ, tối ưu hóa các selector của CSS và JS…
  3. MƯỢT: Sau khi nội dung trang web đã được tải về và hiển thị thì việc tiếp theo là bảo đảm các hiệu ứng animation, transition, scrolling… phải mượt, không bị lag và giật (jank).

Trong 3 tiêu chí này, có 2 tiêu chí mà front-end developer chúng ta hằng ngày đều thực hiện là nhẹ và nhanh. Bằng cách sử dụng các framework (angularjs, reactjs…) và các bộ build tool (grunt, gulp, webpack…), các resource trong project ở môi trường production lúc nào cũng được minify và đóng gói đầy đủ, gọn gàng.

Do đó, trong bài này tôi sẽ hướng dẫn cho bạn cách đáp ứng được tiêu chí thứ 3, đó là MƯỢT, thứ mà ít có framework hay công cụ nào có thể hỗ trợ bạn được.

timeline record

Trên thực tế, các web page yêu cầu độ mượt cao thường là các webpage có nhiều hiệu ứng, chuyển động, ví dụ như các trang landing page, giới thiệu sản phẩm, HTML5 game, hoặc các ứng dụng có animation chạy trên các thiết bị có cấu hình thấp. Bạn có thể xem qua một số trang sau:

Làm thế nào để web page “mượt”?

Mượt ở đây chính là “Rendering Performance”, để tối ưu hiệu suất render chúng ta phải hiểu được quá trình render của browser.

60

… là số khung hình trên một giây mà các thiết bị phổ biến hiện nay hỗ trợ (60fps). Để cho trang web mượt thì tốc độ render phải đáp ứng được con số này. Tức là trong 1 giây chúng ta phải cho ra 60 khung hình. Với mỗi khung hình, chúng ta có 1 / 60 = 16,66 mili giây. Trên thực tế, browser còn có một số tác vụ khác phải làm bên cạnh việc render, vì thế chúng ta trừ hao còn lại khoảng 16ms.

Bất cứ animation hay transition nào, muốn đảm bảo được tốc độ 60fps thì phải cũng phải đảm bảo trong vòng 16ms phải render được một khung hình, nếu không thì sẽ bị hiện tượng “frame skip”, hiệu ứng sẽ bị giật, lag.

Cần phải làm những gì trong 16ms đó?

Để cho ra được 1 khung hình, đây là các việc mà browser phải thực hiện (the pixel pipeline):

pixel pipeline

Giải thích ngắn gọn:

1. JavaScript: là hoạt động execute code của javascript.

2. Style calculation: tính toán các thuộc tính theo các quy tắc từ file CSS (hoặc thẻ <style>, thuộc tính style).

3. Layout: browser thực hiện “chia vùng” cho các element khi hiển thị trên màn hình, dựa trên các thuộc tính đã tính toán được từ bước Style.

website layout4. Paint: tô màu cho từng pixel, bao gồm việc: vẽ chữ (render font), hình ảnh, màu, vẽ các hiệu ứng CSS như border, box-shadow… Việc tô màu này được thực hiện trên nhiều “layer” cùng một lúc (phần sau sẽ giải thích rõ hơn về layer). Đây là bước chiếm nhiều thời gian nhất.

website paint5. Composite: gộp các layer đã được vẽ (ở bước Paint) và hiển thị lên màn hình theo đúng thứ tự của các layer đó.

Như vậy, chỉ với 16ms browser phải thực hiện 5 bước như trên để có thể render ra được 1 khung hình. Vậy để đảm bảo mọi thứ đều hoàn thành dưới 16ms, việc chúng ta cần làm là tối ưu từng bước. Cụ thể là:

– JavaScript:

– Dùng requestAnimationFrame.

– Dùng Web workers, Micro-task cho các tác vụ nặng.

– Profiling with Chrome DevTools.

– Style:

– Giảm độ phức tạp của selector

– Giảm số lượng element bị ảnh hưởng

– Layout:

– Hạn chế kích hoạt layout

– Sử dụng Flexbox

– Hạn chế forced synchronous layout.

– Paint:

– Paint là tác vụ xử lý lâu nhất

– Box-shadow, large image không tốt cho paint

– Tạo và quản lý layer hợp lý

– Composite:

– Sử dụng transform và opacity

– Quản lý các layer bằng Chrome DevTools

fps

Từng bước tối ưu hiệu suất render

Bước 1: Javascript

1.1. Sử dụng requestAnimationFrame để thực hiện các thay đổi trên UI.

Khi thực hiện các thay đổi trên UI bằng JavaScript, bạn sẽ muốn thực hiện nó ngay vào lúc bắt đầu của frame, lúc đó browser sẽ có được toàn bộ 16ms để thực hiện các thay đổi (JavaScript ⇒ Style ⇒ Layout ⇒ Paint ⇒ Composite). Để làm được điều này bạn cần dùng hàm requestAnimationFrame. Hàm này có chức năng “hẹn giờ” chạy vào đúng thời điểm của frame tiếp theo.

Một số đoạn code trên mạng hoặc trong các framework thường sử dụng hàm setTimeout, tuy nhiên hàm được gọi bởi setTimeout sẽ không khởi chạy lúc bắt đầu frame, dẫn đến việc không tận dụng hết được khoảng thời gian 16ms, do đó gây ra hiện tượng frame skip, gây giật, lag.

setTimeout

1.2. Chuyển các tác vụ nặng sang Web workers

Đối với các tác vụ nặng như encode/decode, xử lý dữ liệu lớn… chúng ta nên chuyển tác vụ đó sang Web Workers. Web Workers hoạt động trên một thread riêng biệt, sẽ giúp giảm tải cho UI Thread và giúp tiết kiệm được thời gian xử lý.

Tuy nhiên, Web Workers không thể tương tác với DOM tree, do đó một số tác vụ không thể chuyển qua Web Workers được. Trong trường hợp này ta có thể áp dụng phương pháp “micro-task”: chia nhỏ task ra, sau đó sử dụng </span><span class="c0 c12">requestAnimationFrame để cập nhật UI. Lúc này, nếu mỗi task nhỏ có thời gian thực thi bé hơn 16ms thì sẽ tránh được hiện tượng giật, lag như khi chạy cả task lớn.

1.3. Sử dụng Chrome DevTools để “điều tra” JavaScript execution

Chrome DevTools là công cụ cực kỳ hữu ích. Ở tab “Timeline” của Chrome DevTools, bạn có thể kiểm tra được độ mượt của web page bằng cách:

  1. Nhấn nút Record (hoặc Ctrl + R trên Windows, Command + R trên Mac)
  2. Thực hiện animation / transition trên trang web chính
  3. Nhấn nút Stop Record.

Chrome Developer Tools

Chrome DevTools sẽ hiển thị toàn bộ các thông tin liên quan đến các tác vụ JavaScript ⇒ Style ⇒ Layout ⇒ Paint ⇒ Composite. Bạn có thể kiếm tra để xem tác vụ nào chiếm nhiều thời gian nhất và gây ra frame skip.

JS Profile

Bước 2: Style calculation

Cố gắng giữ cho selector của bạn càng đơn giản càng tốt, và giảm số lượng element bị ảnh hưởng bởi selector, ví dụ:

Nên:

Không nên:

Không nên:

Nên:

Việc sử dụng các selector này cần phải cân bằng giữa việc code gọn gàng đẹp đẽ và hiệu suất. Khi sử dụng các selector phức tạp thì browser cần phải thực hiện nhiều tính toán, nhưng nếu chỉ sử dụng các selector đơn giản thì lại khiến code của chúng ta khó quản lý.

Giải pháp ở đây là chúng ta nên sử dụng một số kỹ thuật quản lý style như: BEM (Block, Element, Modifier), PostCSS. Các công cụ này sẽ giúp chúng ta vừa dễ quản lý code CSS ở môi trường dev, và cũng vừa đảm bảo hiệu suất ở môi trường production sau khi build.

Bước 3: Layout

3.1. Hạn chế kích hoạt tính toán layout

Việc thay đổi một số thuộc tính CSS của element có thể kích hoạt browser tính toán lại layout của element đó.

Khi một element bị thay đổi layout thì thường là các element khác cũng sẽ bị thay đổi theo (kích thước, vị trí…). Do đó nếu trang của bạn có nhiều element và việc kích hoạt layout diễn ra quá thường xuyên thì hoàn toàn không tốt cho performance.

Bạn có thể sử dụng Chrome DevTools để kiểm tra xem web page của bạn có bị kích hoạt layout quá nhiều hay không.

Active Layout

Ví dụ trong hình này, bạn có thể thấy sự kiện Layout chiếm tới 20.636ms, vượt qua con số 16ms và tất nhiên là sẽ dẫn đến frame skip, số lượng element cần tính toán lại layout là 1618 (rất nhiều).

Để biết được những thuộc tính nào sẽ kích hoạt Layout (và lý do vì sao), bạn có thể tra cứu ở trang http://csstriggers.com/ – công cụ do một Googler viết cho mục đích tra cứu.

3.2. Sử dụng các thuộc tính mới của CSS3

CSS3 có cung cấp một số thuộc tính mới không những giúp chúng ta canh chỉnh layout dễ hơn mà còn giúp tăng hiệu suất rất nhiều. Điển hình là Flexbox, việc sử dụng flexbox để canh chỉnh layout sẽ dễ hơn so với cách dùng float truyền thống.

Xem bài hướng dẫn tuyệt vời về Flexbox: http://css-tricks.com/snippets/css/a-guide-to-flexbox/

Về hiệu suất, dưới đây là 2 hình ảnh đo hiệu suất của việc kích hoạt layout trên 1300 elements.

Sử dụng Float:

Using Float

Sử dụng Flexbox:

Using Flexbox

Có thể thấy con số “Self Time” giảm từ ~14ms chỉ còn ~3.5ms, đó là một sự thay đổi rất đáng kể.

3.3. Hạn chế kích hoạt layout sớm

Hãy xem xét đoạn code sau: thay đổi kích thước của 3 elements

Khi một element (DOM) được ghi giá trị mới thì layout sẽ bị đánh dấu giá trị hết hiệu lực (invalidates) và sẽ được tính toán lại tại một thời điểm nào đó. Để đảm bảo performance, browser sẽ thực hiện tính toán lại layout vào thời điểm bắt đầu của frame tiếp theo.

Tuy nhiên nếu trong thời gian frame hiện tại chưa kết thúc, ta muốn lấy giá trị kích thước của element thì lúc này browser buộc phải thực hiện tính toán layout lại sớm hơn so với thông thường để có thể trả về kết quả. Hiện tượng này gọi là “forced synchronous layout” – tạm dịch “kích hoạt layout sớm”, và nó gây ra vấn đề về performance khi ta phải thực hiện nhiều tác vụ hơn trong 1 frame.

Để giải quyết, cách nhanh nhất là chúng ta sẽ “đọc trước, ghi sau”.

Hoặc sử dụng requestAnimationFrame để “hẹn giờ” cho cả 3 thao tác ghi vào frame tiếp theo:

Bằng cách này, cả 3 thao tác ghi đều sẽ được thực hiện một lần trong frame tiếp theo, tốt hơn cho hiệu suất.

Bạn sẽ thấy rõ tác dụng của việc hạn chế layout sớm trong một số trường hợp thực tế như sau “Layout thrashing”:

Như đoạn code trên, layout sẽ liên tục bị trigger và kích hoạt sớm ở trong vòng lặp (read: box.offsetWidth, và write: paragraphs[i].style.width) điều này là thảm họa cho browser

(hình: dấu chấm than vàng là báo hiệu forced synchronous layout).

forced synchronous layout

Nếu đã biết về vấn đề forced synchronous layout, đoạn code trên nên được viết lại như sau:

Nếu cảm thấy việc quản lý layout quá phức tạp, bạn có thể tham khảo sử dụng thư viện FastDOM, thư viện này giúp bạn quản lý các tác vụ read/write để đảm bảo không gây ra forced synchronous layout.

Bước 4: Paint

4.1. Dùng Chrome Developer Tools để phát hiện vấn đề performance khi paint

Bất kỳ sự thay đổi nào trên màn hình browser đều yêu cầu quá trình paint, animation, transition, lúc bôi đen đoạn text hay cả con trỏ nhấp nháy ở textbox.

Để biết được browser phải vẽ lại những phần nào trên màn hình, bạn có thể bật chức năng “Show paint rectangles” ở tab “Rendering” trong Chrome Developer Tools.

Chrome Developer Tools - options

Những vùng bị vẽ lại sẽ được tô và hiển thị màu xanh lá cây trên màn hình.

Paint Rectangles

Bạn có thể xem chi tiết hoạt động vẽ của browser bằng cách kích hoạt chế độ “Paint profiler” ở tab “Timeline” khi record.

Timeline options

Paint Profiler

Paint Profiler - Example

Ở chế độ này, bạn có thể kiểm tra quá trình vẽ của tất cả các element trong web page. Dựa vào các thông tin này bạn có thể phân tích và đưa ra hướng giải quyết phù hợp nếu quá trình paint mất quá nhiều thời gian. Một số yếu tố khiến quá trình paint diễn ra chậm:

  • Các hiệu ứng CSS phức tạp: box-shadow, gradient, curves
  • Các element chồng đè lên nhau.
  • Các hình ảnh có kích thước quá lớn

4.2. Sử dụng hợp lý các layer

Trên thực tế, quá trình vẽ diễn ra song song trên nhiều các layer khác nhau, việc phân chia các layer hợp lý sẽ giúp tiết kiệm được thời gian vẽ rất nhiều.

layers

Ví dụ trong trường hợp này, khi bạn cuộn trang thì browser phải vẽ lại layer trên cùng (text), còn layer hình bên dưới có vị trí cố định, không có gì thay đổi nên không cần phải vẽ lại nữa. Các layer này sẽ được gộp lại (ở bước cuối cùng – composite) và hiển thị lên màn hình.

Làm sao để tạo layer?

Vẽ – Paint – là tác vụ nặng nhất, chiếm nhiều thời gian nhất trong các bước, do đó bạn có thể thấy rõ được lợi ích của việc phân chia các layer làm sao cho browser ít phải vẽ lại nhất.

Một layer (compositor layer) sẽ được tạo khi bạn sử dụng thuộc tính will-change (trên Chrome, Opera, Firefox) thuộc tính này báo hiệu cho browser biết element sẽ có sự thay đổi, do đó sẽ đưa element này vào một layer mới.

Đối với các browser không hỗ trợ will-change bạn có thể sử dụng thuộc tính 3D transform để “ép buộc” tạo layer mới:

Cần lưu ý, việc tạo layer mới sẽ yêu cầu thêm bộ nhớ và tác vụ để quản lý các layer, do đó bạn không nên tạo quá nhiều layer, và chiến lược tao layer ở đây không cố định mà còn tùy thuộc vào tính chất của các animation, transition có trên website của bạn.

Không nên: (layer explosions – tạo ra quá nhiều layer không cần thiết)

Bước 5: Composite

Tại bước này, browser sẽ tiến hành gộp các compositor layer đã được vẽ (ở bước 4) và hiển thị lên màn hình.

Trường hợp lý tưởng nhất cho performance là bỏ qua 2 bước Layout và Paint, công việc của browser chỉ là thay đổi các compositor layer để tạo ra một frame.

composite

Để làm được điều đó, bạn chỉ được thay đổi các thuộc tính mà Compositor có thể xử lý độc lập (mà không cần phải kích hoạt Layout và Paint). Các thuộc tính đó là transform và opacity.

transform & opacity

Tuy nhiên trên thực tế chúng ta cần phải thay đổi nhiều thuộc tính hơn nữa để đáp ứng được yêu cầu khi animate các hiệu ứng. Do đó, giải pháp chính là phải tạo và quản lý được các layer một cách hợp lý. Để quản lý được các layer, bạn có thể sử dụng công cụ Chrome Developer Tools.

Trong tab “Timeline” đánh dấu vào mục Paint

Timeline - Paint

Tiến hành record và chọn phần Paint trên kết quả hiển thị

recording paint

Ở đây bạn sẽ thấy thẻ “Layer” trong phần thông tin của frame

layer

Từ đây bạn có thể tra cứu toàn bộ các frame mà web page đang có.

all frames

Danh sách các layer được liệt kê dưới dạng cây (layer tree), preview dạng 3D, có thông tin về kích thước, bộ nhớ, lý do layer được tạo…

Tổng kết

Như vậy là ta đã đi từng bước để có thể tối ưu hiệu suất render cho web page:

JavaScript

     – Dùng requestAnimationFrame

     – Dùng Web workers, Micro-task cho tác vụ nặng

     – Profiling with Chrome DevTools

Style

     – Giảm độ phức tạp của selector

     – Giảm số lượng element bị ảnh hưởng

Layout

     – Hạn chế kích hoạt layout

     – Sử dụng Flexbox

     – Hạn chế forced synchronous layout.

Paint

     – Paint là tác vụ xử lý lâu nhất

     – Box-shadow, large image không tốt cho paint

     – Tạo và quản lý layer hợp lý

Composite

     – Sử dụng transform và opacity

     – Quản lý các layer bằng Chrome DevTools

Sau khi đã thực hiện những bước trên, web page của bạn sẽ hoạt động mượt mà, trơn tru với 60fps. Chúc bạn thành công!

60FPS FOR THE WIN!

Chuyện ngoài lề

Ở Silicon Straits Saigon, chúng tôi có một bài test dành cho Front-end Developer, đó là implement hiệu ứng scrolling sau (ảnh động, load hơi lâu): http://bit.ly/1CCYx9y

Các bạn có thể vận dụng những kiến thức có được trong bài viết này để “thử sức” với hiệu ứng trên.

Đây là bài làm của tôi, mặc dù không được hoàn hảo nhưng có thể dùng được cho mục đích tham khảo.

Link: http://trungdq88.github.io/css-stuffs/delay-scroll/

Timeline Record:

timeline record

Layers (một phần):

layers

Các nguồn tham khảo trong bài viết:

Một số hình ảnh và code mẫu:

Các trang web có hiệu ứng đẹp:

Khóa học:

Các nguồn khác:

Silicon Straits is hiring Venture Builder

Who we are…

…at Silicon Straits Saigon, we build impactful products for businesses in South East Asia and worldwide! We have been working with many different stakeholders and have delivered over 100 projects successfully since starting our journey.

Over the years, we have been exposed to a number of unique opportunities building hard- and software products and creating significant IP which we own and which are already being used by paying customers in Vietnam and overseas. It is time for us to now double down on our efforts to not only build great products but turn those into great companies as well.

What we believe…

Successful startups need to get three things right – they need to build great PRODUCT, find and monetize on great MARKET and ultimately create great ORGANIZATION.

Whilst our core competency and culture focuses a lot around building great products, building great startups will take something slightly different which is why we need you.

We are looking for…

… a person who can combine a number of the great products coming out of our current work and build a business around each of these products.

Specifically, this means that you will:

  • help define the business value proposition and product positioning, identify target customers and prepare a business plan for each offering
  • get your hands dirty by going out and doing actual business development for these new businesses closing deals and signing up new customers
  • set up an infrastructure to support these customers through remote as well as physical support processes
  • working closely with Product team to help build the roadmap and iterate the product based on market and customers’ feedback.

Ultimately, we expect you to take our products and do whatever it takes to make them the basis for strong standalone spin-offs without having to worry about engineering quality.

This is a senior position and the successful applicant will have the opportunity to ultimately lead a separate business unit we will form around this venture building arm.

Do impress us

Interested candidates are invited to send us their updated CV to [email protected] with an explanation of why they are the right person for the job.

5 trạng thái của UI và Quy trình làm việc mới của SpaceWalker

Làm thế nào để quá trình thiết kế một sản phẩm không xảy ra quá nhiều biến cố dẫn đến phải thay đổi thiết kế ban đầu và kéo theo những thiết kế khác? Làm thế nào để developers có thể làm việc ăn ý với UI/UX designers? Làm thế nào để việc thiết kế UI và UX đạt hiệu quả với thời gian ít nhất?

Đó là những câu hỏi mà một thời SpaceWalker đã phải trăn trở để tìm ra các câu trả lời tốt nhất. Cho đến một ngày…

5 trạng thái khi thiết kế UI

Đó là một ngày đẹp trời tháng 9, bọn mình được gửi cho một bài viết rất hay về UI và UX. Nó ngay lập tức trả lời cho những câu hỏi làm thay đổi quy trình làm việc của Squad.

Bài viết chia sẻ về 5 trạng thái khi thiết kế UI (5 states of UI stack):

  • Blank State (Trạng thái trống)
  • Loading State (Trạng thái chờ)
  • Partial State (Trạng thái lưng chừng)
  • Error State (Trạng thái báo lỗi)
  • Ideal State (Trạng thái lý tưởng)

UI Stack

Trước đây khi thiết kế, bọn mình chỉ tập trung vào Trạng thái lý tưởng mà bỏ sót những trạng thái khác, làm cho các bạn developers gặp khó khăn khi viết code cho ứng dụng.

Ví dụ điển hình là trong giai đoạn chạy nước rút của một dự án, developers khi phát hiện những trường hợp còn thiếu thì họ sẽ tự thiết kế giao diện mà không hỏi qua bên thiết kế (Đây là điều xảy ra khi bạn để các lập trình viên tạo giao diện người dùng). Việc đó dẫn đến:

  • Giao diện không đồng nhất với thiết kế trước đó.
  • Xung đột giữa developers và UI designers.
  • Cảm giác khó chịu của developers và UI designers khi phải làm sửa chữa thiếu sót của bên UX.
  • Phản ánh không tốt từ khách hàng.

Tất cả việc đấy ảnh hưởng đến tinh thần và hiệu quả làm việc của cả nhóm.

Áp dụng quy trình làm việc mới

Từ những kiến thức thu được từ bài viết, SpaceWalker đã tìm cách áp dụng chúng vào công việc thực tế. Bọn mình đã xây dựng nên một quy trình làm việc mới giúp tăng hiệu quả công việc, tiết kiệm thời gian cho mọi người và dẹp tan bầu không khí căng thẳng ở giai đoạn cuối của các dự án:

  1. Khi bắt đầu thiết kế user flow, PM và UX sẽ tổ chức những buổi thảo luận có sự tham gia của tất cả thành viên từ developers, UI designers cho đến QA. Việc này giúp ích rất nhiều trong việc tìm ra các giới hạn công nghệ, thời gian phát triển và các trường hợp phát sinh trong quá trình sử dụng sản phẩm.
  2. User flow sau khi hoàn thành sẽ được gửi cho khách hàng xác nhận. Nhằm đảm bảo khách hàng hiểu rõ user flow thì PM phải xác nhận từng trường hợp với họ. User flow sau khi được xác nhận sẽ tạo thuận lợi cho rất nhiều công đoạn khác: QA xây dựng test case dễ hơn, PM nắm vững sản phẩm nhiều hơn và xác định rõ timeline hiện tại đã ổn hay chưa để còn thay đổi cho phù hợp.
  3. Khi có bản user flow cuối cùng, UI và UX sẽ ngồi lại với nhau để quy định ra những màn hình chính, phụ và những màn hình có tương tác đặc biệt. Sau đó, wireframe của màn hình chính và phụ được thiết kế và gửi cho khách hàng xem xét. Nếu có thay đổi thì chỉ cần chỉnh sửa những wireframe của màn hình chính và tương tác đặc biệt thay vì tất cả wireframe như trước đây. Quy trình mới làm cho công đoạn này giảm xuống còn 2-3 ngày thay vì 1 tuần như lúc trước.
  4. Trong quá trình vẽ wireframe, bọn mình còn làm một spreadsheet để liệt kê những màn hình nào có trong ứng dụng và những phần tử xuất hiện trên màn hình đó (nút nhấn, ô nhập…). Các màn hình chính, phụ và tương tác đặc biệt sẽ được đánh dấu khác nhau. Cấu trúc của spreadsheet sau khi áp dụng 5 trạng thái khi thiết kế UI như sau:
    • Số thứ tự.
    • Hoàn thành: giúp PM kiểm tra tiến độ quá trình thiết kế.
    • Tên màn hình: đặt tên như file thiết kế, các màn hình chính sẽ được đánh dấu nổi bật hơn.
    • Nội dung: các phần tử có trong màn hình (nút gì, câu chữ gì…).
    • Trạng thái: Empty, Loading, Partial, Error, Ideal.
    • Ghi chú: Bổ sung những lưu ý.

Kết quả

Nhờ sự khuyến khích của các sếp và sự hợp tác nhiệt tình, vui vẻ của mọi người mà các dự án áp dụng quy trình làm việc này có kết quả rất khả quan:

  • Số lượng màn hình phải thiết kế tăng gấp 5 lần để đảm bảo đầy đủ tất cả trường hợp nhưng các màn hình phụ chủ yếu là sử dụng lại các phần tử trên màn hình chính.
  • Công việc thiết kế diễn ra trơn tru hơn do đã biết rõ nội dung từng màn hình khi thiết kế.
  • PM cập nhật tiến độ cho khách hàng cũng dễ dàng và thuận tiện hơn hẳn.
  • Developers chỉ cần tập trung làm theo thiết kế có sẵn, không phải tự thiết kế các trường hợp đặc biệt nữa.

Còn bạn, nhóm của bạn đang sử dụng quy trình nào trong quá trình phát triển sản phẩm?

Bài học Quản lý Người Sao Hỏa

Giả sử một ngày nào đó, một người sao hỏa đáp xuống vườn nhà bạn. (Đừng sợ, bạn ấy rất dễ thương. Bạn ấy có màu da xanh lá, một cái đầu quá khổ, thân mình bé nhỏ, và ba con mắt to mang đầy vẻ hiếu kỳ).

Người bạn Sao Hỏa vô cùng tò mò với mọi thứ. Bạn ấy nói giọng cao chót vót và mang một chất giọng lai của người Boston, Úc và Siri. Kỳ diệu làm sao khi bạn ấy hiểu được Tiếng Việt và bạn ấy đến đây để học về Trái Đất của chúng ta cho buổi Tetra InterGalWarp Ewol trước Martian Dojimos (tạm dịch: bài thuyết trình mùa hè trước lớp của học sinh khối bốn).

Hóa ra bạn ấy đến đây là vì thế. Bạn ấy chỉ vào mọi thứ và hỏi bạn về chúng. Cái này là gì vậy? Nó làm được gì? Ai làm ra nó vậy? Nó dùng vào việc gì?

Không có gì có thể thoát khỏi những con mắt tò mò đó (dù sao thì có đến ba con lận mà). Ngọn cỏ. Chai nước mắm. Chiếc xe đạp cũ kĩ. Quyển ngôn tình sờn gáy nằm từ đời nảo đời nao trên kệ sách. Bộ phim Cô đâu 8 tuổi chiếu trên TV. Màu xanh da trời trên tường nhà bạn. Con nhền nhện. Nhân vật hóa trang. Kể cả cây kem chuối… và danh sách này còn rất dài.

Lúc đầu, bạn còn thấy dễ thương. (Haha, người bạn Sao Hỏa đáng yêu muốn biết tại sao có người lại mặc bồ đồ màu xanh, vác mai trên lưng, đeo một chiếc khăn ngay mắt và trên tay cầm côn hoặc đinh ba). Nhưng không lâu sau, chuyện này chẳng còn vui tý nào. Các câu hỏi cứ dồn dập đập vào mặt bạn. Cỏ ba lá là gì? Xe hơi là gì? Điện thoại là gì? Bạn biết tất cả câu trả lời, nhưng cứ đà này thì bạn chết mất. Trên đời này có hàng triệu thứ để hỏi. À không, cả tỷ ấy chứ.

Bạn có thể dành cả ngày lẫn đêm trả lời câu hỏi của người bạn Sao Hỏa nhưng việc đó giống như muối bỏ biển vậy.

Là một người quản lý, bạn chịu trách nhiệm cho kết quả của nhóm. Mọi chuyện đều từ bạn mà ra, nên đừng có đi lung tung đổ lỗi cho người khác nếu như có gì đó không được như mong muốn. Đây là ý nghĩa của trách nhiệm.

Nhưng mặt tối của bổn phận là khi bạn quá chú tâm vào kết quả, và bạn bắt đầu nghĩ rằng cách trực tiếp nhất để đạt kết quả mong muốn là đưa cho mọi người đáp án và nói cho họ biết cách dễ nhất-tốt nhất-nhanh nhất để giải quyết một vấn đề.

Không có gì sai khi có suy nghĩ này vì mọi người đều mong có câu trả lời. Có khi họ hỏi bạn là để tìm ra cách dễ nhất-tốt nhất-nhanh nhất vì họ biết bạn là sếp, họ tin chắc bạn biết hết mọi đáp án. Và đương nhiên bạn cũng muốn giúp họ rồi. Bạn muốn cấp dưới của mình thành công. Nếu bạn thực sự biết con đường ngắn nhất dẫn đến thành công, sao bạn lại không giúp họ tiết kiệm thời gian và công sức cơ chứ – đó là chưa kể hạn chế được những rủi ro có thể xảy ra – bằng cách trực tiếp đưa câu trả lời cho họ?

  • Cậu phải tạo mối quan hệ với công ty X bằng cách gửi cho họ một email, nhờ họ sắp xếp một buổi gặp mặt, và chúng ta sẽ thảo luận những nội dung sau…
  • Ally vừa hỏi tôi khi nào thì bản nháp được hoàn thành. Cậu có thể làm xong chúng trong một tuần được không? Chúng ta sẽ xem xét wireframes vào ngày mai.
  • Cậu nên đưa tính năng này cho 1% người sử dụng để kiểm tra trước khi chính thức ra mắt nó, và nhớ là phải lên kế hoạch cho một cuộc nghiên cứu khách hàng nữa đấy.

 Bạn vừa đọc những trường hợp điển hình nhất cách đưa cho một người hướng dẫn rõ ràng để họ làm việc theo ý bạn. Thỉnh thoảng, việc này cần thiết. Đôi khi có những tình huống khủng hoảng và rối rắm đòi hỏi phải có những hành động rõ ràng và quyết đoán. (Điều này được Ben Horowitz nhắc đến trong quyển sách của anh ta với cái tên “a company in wartime” – một công ty trong thời chiến.)

Nhưng bạn đang trong thời bình cơ mà. Bạn đang mở rộng và phát triển một lĩnh vực kinh doanh hiệu quả. Bạn xây dựng một nhóm làm việc cho mục đích thành công lâu dài. Vậy thì sao? Việc bạn đưa ra mọi câu trả lời nói lên rằng bạn đang quản lý cả những việc nhỏ nhặt (micromanage – quản lý vi mô) không cần thiết. Bạn đang bóp chết sự sáng tạo và trưởng thành. Bạn đang cản trở sự phát triển của những người khác. Và khi bạn muốn vươn tay đến tất cả mọi thứ như một siêu anh hùng, bạn đang tự đặt chân mình lên một con đường dài, đầy rẫy chông gai ở phía trước.

Nếu bạn không tìm được cách nào tốt hơn, mọi thứ sẽ không duy trì được lâu nữa đâu.

Management with Martians

Làm thế nào để người bạn Sao Hỏa có được mọi câu trả lời mà vẫn để bạn có một cuộc sống bình yên?

Thực ra thì, bạn chỉ cần ngồi xuống và giảng cho bạn ấy nghe vài bài học cơ bản về cuộc sống. Như kiến thức về động vật và thực vật, hay tự nhiên và nhân tạo khác nhau như thế nào. Và điều gì thôi thúc người Trái Đất (thuyết nhu cầu của Maslow, do sự tự thể hiện bản thân ở trên đỉnh tháp nên mới có những người thích hóa trang, ăn cơm với nước mắm hay xem phim Cô dâu 8 tuổi trên TV). Sau đó, trong tương lai, khi người bạn Sao Hỏa bé nhỏ của chúng ta chỉ tay đến con vật bốn chân nào đó, bạn chỉ cần nói “nó là con mèo, là động vật” và thế là xong.

Hoặc một biện pháp khác là… dạy cho bạn ấy đọc và dẫn bạn ấy vào một thư viện nào đó. Vài tháng trong ấy, sẽ giúp anh bạn của chúng ta sẽ có cái nhìn rõ hơn về thế giới này. (Lâu lâu xem TV một chút cũng chẳng hại gì.)

Còn không thì… đưa bạn ấy đi học. Bắt đầu từ mẫu giáo cho đến đại học. Có lẽ sẽ mất nhiều thời gian đấy, nhưng bạn đâu biết thời gian của người Sao Hỏa như thế nào đâu, có khi 1 ngày của họ bằng 1 năm của chúng ta ấy chứ.

Cách đơn giản hơn nữa là… dạy cho bạn ấy cách sử dụng Internet. Cái nào không biết thì lên Wikipedia, Quora, Stack Overflow mà tìm đáp án, hoặc sử dụng vũ khí tối thượng là Google. Trong thời gian đó, bạn có thể thoải mái dẫn bạn gái đi dạo hay xem phim.

Giả sử người Sao Hỏa sở hữu một loại công nghệ tiên tiến có thể xây dựng được một hệ thống như phim The Matrix thì quá khỏe rồi. Cứ tải thẳng kiến thức về não thế là xong. (Không chừng bạn có thể học ké chút kung fu từ hệ thống ấy đấy!)

Thực tế thì có rất nhiều biện pháp để giải quyết vấn đề của anh bạn chúng ta.

Những framework (phương pháp tư duy) hiệu quả nào thường dùng trong công tác quản lý? Có hàng tá quyển sách nói về chủ đề này. Không có quyển nào đảm bảo kết quả hoàn hảo, nhưng dùng để tham khảo cũng tốt. Chúng giúp bạn hình thành lối suy nghĩ để tiếp cận và đưa ra lời giải cho một vấn đề tốt hơn. Một framework tốt giống như một con đường ngắn nhất để tìm ra giải pháp cho một nhóm vấn đề tương tự nhau.

Tôi thích cách nghĩ công việc của một người quản lý là học hỏi, thiết kế hoặc hướng dẫn người khác các framework, mỗi framework là lối tắt để đạt được kết quả mong muốn trong một trường hợp cụ thể. Như trò chơi sưu tập những viên bi đủ màu sắc thuở bé, sưu tầm những framework khác nhau cũng rất thú vị, dù là từ sách, từ người khác, hay kinh nghiệm của bản thân.

Một số framework hữu ích tôi thường gặp (mỗi cái đều đã được sàng lọc và lặp lại khá nhiều trong công việc):

  • Đưa ra lời phê bình tích cực hoặc có những cuộc nói chuyện nghiêm túc
  • Đánh giá khi nào thì sản phẩm sẵn sàng được ra mắt
  • Thiết kế và thi hành một lộ trình thực tế
  • Thiết lập những mục tiêu cụ thể với các nhiệm vụ phải làm
  • Xây dựng sản phẩm mới khả thi
  • Quản lý một nhóm dù trong giai đoạn “chiến tranh” và “hòa bình”
  • Định nghĩa chất lượng là gì
  • Xác định nên tuyển người nào
  • Thấu hiểu kĩ năng, sức mạnh, và quỹ đạo tăng trưởng của người khác

Khi bạn phát hiện mình đang đưa ra phản hồi giống nhau lặp đi lặp lại, hay khi bạn lặp lại sai lầm nhiều lần – đó là khi bạn nên cân nhắc sử dụng một framework (gọi nó là công thức tổng quát nếu bạn muốn)

Cuối cùng, bạn biết người khác nói thế nào về người Sao Hỏa rồi đấy.

Nếu bạn đưa cho họ một câu trả lời, bạn chỉ thỏa mãn họ trong một phút. Nhưng nếu bạn đưa cho họ một cách thức để tìm ra câu trả lời, khi đó bạn đã cho họ cơ hội để đạt được Pistatort-Caliber (tạm dịch: điểm A+) cho Tetra InterGalWarp Ewol.

Ai lại không muốn anh bạn nhỏ bé dễ thương của chúng ta đạt được điều đó cơ chứ?

Dịch từ bài viết Managing with Martians của tác giả Julie Zhuo.

Biên dịch: Hải An, Giáp Hồng

Cài đặt và Sử dụng Linter cho JavaScript

1. Linter là gì? Có ăn được không?

Linter là từ chỉ chung một nhóm phần mềm có nhiệm vụ đọc code của bạn và cho bạn biết đoạn code đó có lỗi gì về cú pháp hoặc “phong cách” (code style) hay không. Một số linter cho JavaScript tiêu biểu có thể kể đến là JSLint, JSHint, và ESLint. Về bản chất thì 3 thằng này giống nhau. Trong bài viết này tôi chỉ sẽ tập trung vào ESLint.

Ta hãy cùng xem qua một ví dụ dùng ESLint. Giả sử ta có một file bad.js với nội dung:

Giả sử bạn đã cài đặt NodeJS và ESLint, chạy eslint --init để thiết lập một số tính năng cơ bản, sau đó chạy eslint bad.js để kiểm định chất lượng code ta vừa viết ở trên:

ESLint error

Có thể thấy ngay rằng ngoài việc bắt lỗi code style vô thưởng vô phạt (thiếu dấu chấm phẩy – Missing semicolon), linter còn giúp ta phát hiện được lỗi code thừa ("two" is defined but never used), thiếu từ khóa var khi khai báo biến (“one” is not defined), và lỗi chính tả khi ta muốn gọi biến one (“onee” is not defined).

Thế nhưng sức mạnh thật sự của một linter là khả năng tích hợp vào text editor:

ESLint text editor integration

Hình trên là ESLint đã được tích hợp vào vim thông qua plugin Syntastic. Ngay khi save file, ta sẽ thấy ngay code có lỗi gì và biết chính xác chúng ở hàng nào, cột nào.

Đây chỉ là ví dụ đơn giản nhất. ESLint có khả năng mở rộng (extensibility) rất cao, và hiện tại JSX lẫn ES6 đều đã được hỗ trợ rất tốt.

2. Tại sao tôi phải quan tâm?

Thứ nhất, linter cho JavaScript giúp ta tiết kiệm (rất nhiều) thời gian. Thay vì phải chạy test hoặc chạy thẳng code, ta có thể biết lỗi ngay từ lúc save file trên text editor và sửa ngay tại đó.

Thứ hai, một file linter config sẽ giúp duy trì một chuẩn chung về code style cho các lập trình sư làm việc trên cùng một dự án. Công ty Airbnb có hẳn một tài liệu quy chuẩn cho JavaScript cả ES5 lẫn ES6, và họ có tạo hẳn một package chứa ESLint config để ràng buộc (enforce) những chuẩn họ đưa ra. Thậm chí ta có thể thêm một bước “linting” vào trong build process để cấm deploy nếu linter tìm ra bất cứ lỗi nào trong code.

3. Ok ông nói bùi tai phết, giờ tôi muốn dùng phải làm sao?

Thì… google chứ làm sao :)

Nói nghiêm túc thì hiện tại có quá nhiều text editor và hệ điều hành trên thị trường hiện nay trong khi tôi chỉ dùng vim nên không thể liệt kê từng bước cho từng chương trình được. Tuy nhiên, nguyên tắc hoạt động của chúng nhìn chung có thể nói là giống nhau. Ta sẽ cần:

  • Cài một plugin hỗ trợ linting cho text editor. Ví dụ:
    • Syntastic cho vim
    • Flycheck cho emacs
    • SublimeLinter cho Sublime Text
  • Cài đặt để nhúng một linter cụ thể vào plugin hỗ trợ linting ở trên. Ví dụ:
  • Cài linter để plugin ở trên có thứ mà chạy

Sau đây là hướng dẫn chi tiết cách dùng ESLint với vim và dùng ké ESLint config của Airbnb để lint cả JSX trên ES6 (whoa).

Đối với những bạn sử dụng Sublime Text, có thể tham khảo cách cài đặt SublimeLinter ở bên dưới.

Cài NodeJS (duh)

Nếu bạn dùng Mac hoặc Linux, tôi khuyến khích dùng nvm để cài NodeJS phiên bản mới nhất (4.1.1 tại thời điểm viết bài).

Còn bạn nào dùng Windows thì có thể tải bản cài đặt của NodeJS tại đây.

Cài ESLint và đồng bọn

Bạn đã cài NodeJS mới cứng ở bước trên rồi chứ? Chưa à? Cứ thư thả cài đi, tôi chờ.

Ok, tiếp nào, mở terminal hoặc cmd lên và gõ lệnh:

Sau đó tạo file .eslintrc trong directory chứa dự án của bạn với nội dung như sau:

VIM: Cài và bắt Syntastic dùng ESLint

Cài plugin Syntastic. Nếu bạn chưa rõ cách cài plugin cho vim, vui lòng xem link Shameless Plug để biết thêm chi tiết.

Sau đó thêm dòng này vào .vimrc để chọn ESLint làm linter cho bạn:

Khởi động lại vim là xong!

Sublime Text 3: Cài tất tần tật mọi thứ

Việc đầu tiên là tải và cài đặt Sublime Text, ở đây tôi dùng Sublime Text 3.

Cài thêm Package Control cho Sublime Text 3 theo hướng dẫn ở trang chủ của họ.

Bước tiếp theo, ấn tổ hợp phím Ctrl+Shift+P để mở bảng Command Palette (hoặc có thể vào menu Tools > Command Palette) rồi gõ vào Install package xong Enter.

Sublime Text 3 Install Package

Tìm và cài package Sublime​Linter, sau đó cài tiếp SublimeLinter-contrib-eslint. Mở file *.js nào đó lên và nghịch thử thôi.

Bonus: ESLint cho gulp

Nếu bạn là người cổ lổ sĩ như tôi và vẫn dùng gulp thay vì webpack, bạn có thể tham khảo gulp-eslint để tạo một linter task cho mình.

Rất đơn giản phải không, nếu có thắc mắc về linter thì bạn cứ comment bên dưới nha!

​Design Squad đã rebrand như thế nào?

Từ thuở hồng hoang khi công ty bắt đầu chia squad, team design bọn mình tồn tại dưới một cái tên tạm thời là Design Squad. Sau bao cuộc bể dâu thì bọn mình cảm thấy tên Design Squad không thể hiện được đầy đủ tinh thần của team như là của Tinker, Minion hay Lab squad. Thế là bọn mình quyết định bắt tay vào việc rebrand.

Ba tính chất mà bọn mình muốn brand của squad phải thể hiện được là:

Flexible – Hope – Interesting
  • Flexible – Với slogan “Be water” bọn mình luôn muốn có thể biến hoá khôn lường trong các sản phẩm mình làm ra. Dù sản phẩm đó thuộc thể loại gì, style ra sao, khó khăn như thế nào thì bọn mình vẫn có thể giải quyết và hoàn thiện mọi thứ.
  • Hope – Bọn mình mong muốn là team tiên phong trong mọi việc, là người thử nghiệm những thứ mới. Ví dụ như quy trình làm việc mới, những việc về team building, v.v… Là niềm hy vọng của mọi người về một cái gì đó mới hơn, tốt hơn.
  • Interesting – Trẻ trung, năng động, dám nghĩ dám làm và không ngại đổi mới đó chính là những điểm thú vị của bọn mình luôn luôn cuốn hút mọi người xung quanh.

Khi đã xác định được những yếu tố cần có trong brand của squad, bọn mình bắt tay vào giai đoạn “Cà Não Tìm Tên”. Bọn mình liệt kê hết tất cả các từ có liên quan tới 3 tính chất này rồi bắt đầu “ngâm cứu”.

Slack for iOS Upload-2

Sau đó bọn mình tiến hành chốt hạ từng tên một, ghép với nhau, chơi chữ nhau, và bắt đầu vote. Mỗi bạn sẽ có quyền chọn 2 tên mà mình thích nhất. Thế là bọn mình tổng hợp lại ra được cái slide này để vote một lần nữa, lần này khác là mỗi bạn chỉ có 1 lần vote và bạn nào tâm đắc với tên nào thì được 2 phút nói lên chính kiến để thuyết phục mọi người vote tên đó với mình.

Và SpaceWalker chiến thắng với 5/10 vote. Đến giai đoạn 2, bọn mình brainstorm phát triển idea từ chữ SpaceWalker xem có những tên nào hay hơn và đúng với 3 tiêu chí tụi mình mong muốn nữa không.

Và những cái tên khác rất hay ra đời như: Space Shuffle, Space Dreamer, Into Space, Spaceroom… Nhưng cuối cùng thì vẫn cảm thấy không có cái tên nào phù hợp hơn… Như một câu nói trong phim The Martian “Everywhere I go, I’m the first.” Khi bạn là SpaceWalker, bạn là những người tiên phong.

Sau khi đã có được cái tên mà bọn mình đều cảm thấy hài lòng, giai đoạn tiếp theo cũng là giai đoạn thử thách nhất… Làm logo.

Giai đoạn đầu tiên để làm một logo đó là phác thảo nhanh. Bọn mình tổ chức một buổi phác thảo nhanh cho cả team tầm 2 tiếng đồng hồ và đây là thành quả:

Một loạt những bản phác thảo logo tuyệt tác ra đời và mỗi người chọn ra 1 hoặc 2 bản mình tâm đắc nhất để thể hiện trên máy:

Cuối cùng màn hấp dẫn đã đến, đó là việc vote xem logo nào là ứng cử viên sáng giá nhất để trở thành logo của SpaceWalker squad. Và ten ten tén, tác phẩm được vote nhiều nhất là…

QH

Logo là sự lồng ghép của hình tượng bước chân trong chữ W và hình dáng chữ S và W được inspire từ quỹ đạo của bước chân:

Tưởng chừng như đã chốt được logo thì bỗng vấn đề xảy ra khi mọi người nhận ra rằng, với màu sắc hiện tại thì logo nhìn rất dễ liên tưởng tới logo của Google Wallet. Thế là bọn mình lại xào nấu một thêm lần nữa với những option màu đẹp nhất, ý nghĩa nhất :)))

Và cuối cùng đây là logo của squad – sản phẩm của cả team cùng sống chết nhào nặn ra:

 

Bên cạnh đó logo được mọi người vote nhiều thứ 2 cũng trở thành Mascot của squad luôn (thiệt là tiện).

Mascot SpaceWalker squad
SpaceWalker – Những người tiên phong mở cõi cho Silicon Straits

Nhân tiện PR các team member trong SpaceWalker squad một tí, hí hí.

Processed with VSCOcam with hb2 preset

Cám ơn các bạn đã theo dõi!!!