Mr Leong 梁先生

[The post was initially posted on MoVend Blog]

As a developer, I have to make multiple decisions everyday. When making a trade-off, there hardly is any right or wrong. Over time, the team develops core values, which act as guidelines for decision making. These guidelines then help the team members to make consistent decisions, allowing us to work effectively as a whole.

“How can I prevent, or make it difficult for a user to make a mistake?” This is one of the many questions I ask myself whenever I am designing an interface (UI and API). I use it as a guideline for making decisions. In order to achieve an objective (e.g. make a payment), the user has to perform a series of actions through interaction with the UI. When a user makes a mistake, he/she may be frustrated because the objective is not achieved. One method of circumventing this problem is to limit to only 1 possible way of performing a task. When there is only 1 possible way to perform a task, you can easily design a UI that guides user’s interaction. By reducing the possibility of making a mistake, user achieves the objective easily and fuss-free, coding then becomes easier as user action validation is simpler.

Limiting ways of performing a task is just one of the various implementation of preventing users from making mistakes. So then, how do you make it difficult for a user to make a mistake? Feel free to share your experience in the comments section.

I discovered Gravity in Google Chrome Web Store. It is a simple and elegant project management software for Agile team.

Projects

User can create up to 3 projects. At time of writing, Gravity is finalizing the paid subscription packages. User can sign up with Google / Google App account. After creating a new project, participants can be invited to join the project. Each participant can be classified in one of the following roles: Spectator, Participant, Manager.

Stories

Stories can be created and assigned to participants. Multiple stories can be grouped into user defined categories (e.g. Web, API, Mobile client). Multiple acceptance tests can be created for each story. Each acceptance test can be marked as “Passes” or “Fails”. Multiple tasks can be added to a story. It is presented as a checklist, where user can check the checkbox to mark the task as completed.

Iterations

User can define iterations. By default, each iteration last for 2 weeks. Each iteration has a cost value, which is the total cost of stories assigned to this iteration. Each story will be assigned a cost value (default 3). Stories can be either schedule in the backlog (unscheduled), or one of the iterations.

Kaban

Gravity has a Kanban feature called Task Board. It has 4 stages: To Do, In Process, To Verify, Done. Tasks within each story will appear on the Kanban board. Each task can be dragged across the Kanban board by using a mouse. I think this is a wonderful feature. Kanban is a useful tool for team to review and optimize its process.

Reports

Various information (i.e. story cost, stories burn down, task burn down) are presented in the form of charts. This feature give user a visual summary of the performance of the team.

Issue/Bug Tracker

Besides the story/task management, Gravity also comes with a simple issue tracker. Each issue has 4 attributes: title, description, category, severity.  To facilitate searching of issues, it has a filter feature where user can filter the issues by a combination of different criteria.

Opinion

Gravity is very simple to use. It uses AJAX to make user interaction smooth. It is suitable for Scrum/Kanban team. Gravity offers more features than Pivotal Tracker. If you like Pivotal Tracker and want an integrated Kanban/Issue tracker, you can consider Gravity.

Linux kernel is capable of recognizing many Android devices connected through USB. You can make the device available in userspace through udev. In order to do that, I need to write some udev rules.  I use lsusb to find the vendor ID needed to write udev rules. This is my udev rule (/etc/udev/rules.d/90-android.rules):

# Nexus One
SUBSYSTEM=="usb", SYSFS{idVendor}=="18d1", MODE="0666"
SUBSYSTEM=="usb",ATTR{idVendor}=="18d1",SYMLINK+="android_adb"
SUBSYSTEM=="usb",ATTR{idVendor}=="18d1",SYMLINK+="android_fastboot"

# HTC
SUBSYSTEM=="usb", SYSFS{idVendor}=="0bb4", MODE="0666"
SUBSYSTEM=="usb",ATTR{idVendor}=="0bb4",SYMLINK+="android_adb"
SUBSYSTEM=="usb",ATTR{idVendor}=="0bb4",SYMLINK+="android_fastboot"

2 weeks ago I conducted an Android Training Workshop for CodeAndroid Singapore meetup at Google office. I have designed a tutorial to teach newbies the basic concepts of Android development. In this tutorial, developers learn the basics of Activity, View, Intent, and HTTP request. Developers were taught to create an application called QRTalk.

QRTalk allows user to type in some text message. It uses Google Chart API to encode this message and generate a QR code image. This image is then displayed in a WebView.

URL imageURL = new URL("http://chart.apis.google.com/chart?cht=qr&chs=350x350&chl=hello+world");
Bitmap qrBitmap = BitmapFactory.decodeStream(imageURL.openStream());
imageView.setImageBitmap(qrBitmap);

This is what I have learned while developing the tutorial. With 1 line of code, I am able to make a HTTP request and turn the HTTP response into a Bitmap object instance.

Lesson learned:

1. Use more images in slides. Too much words on slides make it hard for people to absorb, and makes the presentation very dry.
2. Cannot assume audience knows what is QR code.

Links

• Source code: http://code.google.com/p/qrtalk/
• Step-by-step instruction: http://bit.ly/qrtalk
• Slides: http://bit.ly/g82fxS

This is the second day of barcamp. I have decided to talk about PHP frameworks this morning. The main purpose is to discuss when a developer should/should not use a framework, and how to choose a suitable framework.