All posts by Jonathan Lau


It was exactly one month ago that our newly-formed team was together brainstorming for a mobile web application to work on. 275 commits and 18 days later, Ideary was born.


People meet to brainstorm all the time — whether for new and innovative business ideas or little solutions to everyday problems. Brainstorming happens in the context of small school projects or even in large corporate environments. It’s ironic how our team came up with this idea as we too were brainstorming for a project to do, a problem to solve, something that would make lives easier for others.

Once the idea was conceived, work started quickly. After the initial experience with Project 1, I decided that trying to learn a completely new framework for a 3-week project was a big NO. Learning takes time, and while CS3216 is all about learning, this is just not the right time to learn a new framework. So, I chose to stick with something that I was at least familiar with — the MEAN stack.

There are three parts of this project that I would consider most challenging.

  1. Real-time. Libraries like Socket.IO makes things a whole lot easier, but implementing real-time features is still a pain. Apart from making sure the UI for all users are updated correctly when data changes, I also had to write checks to make sure users cannot listen to activities on other projects they do not belong to.
  2. Offline. If an offline mode wasn’t required for the project, I honestly would not have bothered with it. Making a real-time web-app is challenging on its on — making it work offline, too, is a whole new thing to me.
  3. Nesting of ideas. It started off as a simple idea that we wanted to have in our project. We never thought it was going to be so difficult to implement. When users create ideas in a project, we thought that grouping similar ideas together could be a good feature (something we ourselves would use). The difficult part for this was coming up with the schema and validating inputs so that the database would be consistent (for example, preventing a user from moving an idea to another project, or nesting an idea within another nested idea).

So, what have I learnt? Initially, I held that thought that CS3216 would have been much more effective in helping us come up with high-quality projects if we were to focus on just 1 or 2 projects through the term. However, having such tight deadlines for this project has somewhat given me the ability to rapidly scaffold and come up with working web-apps in a time-span much shorter than I thought I could finish.

Looking back, I’m really pretty happy with what I have achieved in the past weeks — a simple but fully-functional real-time web-app complete with a decent UI/UX.

Learning Points from Stickats

It has been awhile since the end of the first assignment and I have just found some time to write a little on some of the many things I’ve learnt over the short three weeks.

Git: Branching and Merging

I use Git quite a lot, even outside of this class. But I’ve never had the need to branch and merge and thus have never saw any value in it. All my projects never had any branches other than master. Working with 4 other developers, I quickly saw how useful branching can be, especially with different people working on different parts of the project.

This was how our commits looked. Bitbucket visualises all the branching and merging with some pretty nice graphics — and our team calls them MRT lines. Well, something I always wanted to learn.


CSS3 Animations

While working on Stickats, our group also decided that we wanted some animations to make the merchant perks page more attractive for users. As part of our plan to introduce some element of gamification into the platform, we planned on making a rocket (or Rockat) launch upward to a certain height, depending on how many Stickats the user has for the merchant. We initially attempted to do so using only JavaScript by setting the object’s position frame by frame. We later found that a CSS3 solution would be more efficient.

CSS3 Rockat



Our group also used Vagrant and Puppet to help everyone have a consistent development environment. This was after our group spent almost one week trying to prepare each others’ development environment for this project. We had a lot of problems building the application as everyone was on different OSes with different versions of software installed. For instance, we found out that the latest version of Compass Sass did not work very well with Foundation and would result in a compilation error. With Vagrant, everyone was able to work on a virtual machine with the right build tools provisioned.

Of course, there’s much more than just these three points that I learnt. But I’ll leave the rest for another time.

Square Reader & Security

When our team prepared for our presentation on Square, we did not expect that there would be so much interest in the security aspect of using Square. In order to focus on the other interesting elements of the Square Register app, our team spent only a mere 20 seconds explaining how the Square reader works. We actually wanted to highlight how Square could still be useful even if it was used without the credit card reader.

After reading through the reviews and comments posted by the rest of the class, I felt that I should share some of my thoughts on security.

I did some research on this area, and everything discussed here are information that are publicly available. Also, as I do not have a strong background in cryptography, do read up more on your own if you are interested — and feel free to correct me if I’m wrong.

Square Reader

Conversion to Sound is NOT Encryption

Some of the class seem to have the impression that the conversion of data into sound waves is what makes Square secure. This is not actually the case. After the card data in the magnetic strip is read, a piece of hardware in the reader is responsible for encrypting this information. As to how this chip does it, or what cryptographic cipher it uses — I don’t know. In the Square app, the analogue sound waves are converted back into digital, but the content remains encrypted.

Attack Vectors

A study on the security of smartphone-based POS systems listed down some of the potential threats faced by these systems.


Unencrypted information transmitted from the app over the network could be intercepted. However, the study also found that all applications tested were protected from this via the use of TLS to encrypt data sent over the network.

Malicious Apps

Malicious software or a compromised OS could intercept data sent over the audio-jack. In other words, you could have installed a bad app that tries to listen on the microphone jack for data from the Square reader. According to the study, readers without hardware encryption are indeed susceptible to this form of attack. While the first version of Square did not offer hardware-based encryption, this is no longer the case.

Malicious Hardware

The reader device could be altered at a hardware level to entirely bypass encryption. However, in order to transmit this data back to the attacker, the smartphone used also has to be compromised.

Would You Use It?

Security and technicality aside, would use such a technology? As a customer, would you choose NOT to patronise a merchant if it processes your card payment using a smartphone or similar devices? Would you even care? Most of the time, when customers make payments in restaurants, their credit card is passed to the waiter, who then returns with a receipt for the customer to sign. If Square is used together with their receipt printer, one could argue that the customer might not even know the payment was processed by Square.

On the other hand, data on credit cards remain insecure as long as they are encoded on the magnetic stripe. Anyone with a cheap magnetic stripe card reader can read, or even duplicate the data stored on the card without much difficulty. Or even easier — the waiter taking your card could simply snap a picture of the card number together with the CVV code. This information is enough for them to use your card to make online transactions.

Would you stop using credit cards entirely?

Befriend Yourself on Facebook?


It’s less than a week to the deadline of Assignment 1, and our team has been working hard to finish what we have started. While debugging our code, we found out something interesting.

It all started out when I was testing out the API call that retrieves a user’s list of Facebook friends. That was when I realised something strange — the JSON string returned included myself as part of the friend list! I immediately thought there was a bug in our code, and was working with Xuanyi for a good half an hour before we finally found out what the real problem was.

You could be a friend of yourself on Facebook — well, not quite actually. You can, only if you’re a special test user of a Facebook app. Facebook attempts to isolate test users from the rest of the real users, so you can’t have a test user befriending and interacting with a bunch of real users. They instead allow you to manage which other test users the a particular user should be friends of.

Facebook Test Users

And you can befriend yourself.

Facebook / iPad Application Seminar

Just got back from the Facebook / iPad Application Seminar, where ten groups took turns to review ten different apps that are currently in the market. This is probably the first class where I had to sit through a series of ten presentations in a row — and yet, each one brings in fresh insights that are applicable and relevant.



The presentation on Goodreads was pretty clear and insightful, and I thought the group gave a really good introduction to what Goodreads is. My only encounter with Goodreads prior to today was brief — I actually stumbled on the little “g” logo while trying out the Amazon Kindle Paperwhite.

In short, Goodreads helps people find and share the books they love through book reviews by other users. Goodreads has a huge catalog of over 900 million books. It currently has 34 million book reviews, created by its 30 million users. With that many users, Goodreads’ most valuable asset is probably its large user-base of people who loves reading. This, in my opinion, could have been what pushed Amazon to acquire the company for $150M earlier last year.

“Powerful” Book Search

Throughout the presentation, the group highlighted the fact that Goodreads’ powerful book search is one of the key features that makes it stand out from its competitors. I disagree. While their search is undoubtedly good, such features like auto-completion and searching by ISBN seem to be a pretty standard feature in many other sites now, providing results that are just as accurate as Goodreads (at least in my own experience). In fact, I would actually expect to be able to search for books by Title, Author and ISBN at any decent book review site of today. What might be more unique about Goodreads is their book discovery feature. Drawing from their large database of books its users have read and liked, I believe they provide pretty good recommendations based on the books you like.

Cluttered User Interface

The group also made a point about the user interface of Goodreads being too cluttered. A user interface that is cluttered with too many things distracts users from the content they care about. As one who appreciates clean UI designs, I would really love to see Goodreads being redesigned to have a cleaner and more responsive UI.

During their presentation, the group also showed a screenshot and pointed out that there is no clear call to action on that page. They mentioned that the sidebar had too many sections with too many actions a user could possibly take. From the sidebar alone, users could:

  1. Input the books they are currently reading
  2. View personalized book recommendations
  3. Take part in a personal reading challenge
  4. View their bookshelves
  5. Take part in featured polls
  6. See the Quote of the Day

Although these content resides on the sidebar (where auxiliary and secondary information are displayed), they are still too much and may make a new user feel lost.

User Recognition & Gamification

The group also suggested implementing a point system to encourage more active contributions to the community. Since Goodreads’ content is primarily user-generated, this is pretty important. A good way to get more people to contribute book reviews would be adopting the user reputation system implemented by StackOverflow. I really love this idea and believe that a user-reputation system could greatly increase the quantity and quality of book reviews in Goodreads. After all, people who contribute good stuff want to feel recognized and important in their community.

Since I’m not an avid reader, I wouldn’t say I’m attracted to continue using Goodreads after this review. However, I feel that the site has a lot of promise for those who enjoy reading. While exploring Goodreads, I also tried out their mobile site (which happens to be an entirely different site optimised for mobile browsing). The UI was much cleaner with less clutter, although the look and feel of the page was quite different from the desktop version. I believe that Goodreads would certainly do well with a redesign, building a more consistent and familiar interface across devices.

To sum up, there were many learning points from the seminar. Not only did I learn about what to look out for when coming up with the UI for an app, I also learnt some interesting business models and strategies some companies use in order to monetize their business.

Square Register

For the second assignment, our team had to choose a Facebook or iPad application to study and present on. We initially had a list of more than 10 different apps, but slowly narrowed it down to a final three. Most of the apps were chosen because we felt that they had interesting points that we as app developers could learn from. Our team eventually chose to study and review Square Register.


Square is not one of the typical apps that everyone with an iPad would download. Its purpose is to give small merchants the tools they need in order to scale and expand their business — tools that were once accessible only to larger and more established merchants.

As of now, Square only works in certain regions, and Singapore is unfortunately not one of them. However, I managed to get hold of a Square reader during a recent visit to Square’s headquarters in San Francisco last month. Although it is not supported in this region at the moment, the Square Register app is still fully functional, complete with sales analytics and email receipts. The only thing it cannot do is the actual processing of credit card payments.


Work has begun for our first assignment, with meetings and code-sprints lasting from the early evenings all the way through the night.

Our first few meetings this week were spent brainstorming for ideas as well as planning out the project. There were many important decisions we had to make — decisions that would greatly impact our project and how we would approach it.

Logo Brainstorming on Paper
Logo Brainstorming on Paper

Back-end Framework

As of now, our team has decided to go ahead with Django. The interesting thing about this decision is the fact that all of us has never ever done any development on any Python frameworks before. A few of the team has experience with Ruby on Rails, and others with PHP and NodeJS — but just not with Python. We came to this decision as we wanted to learn something new, and thought Django would be a good framework to learn.

Front-end Framework

Another decision we made as a team was to completely separate our front-end and back-end implementation. We made that decision to cater for future extensions, so should we decide to come up with a native app in future, we can build on the RESTful APIs that the server exposes.

Because of the nature of our project, we wanted a single-page webapp. Hence we chose to use AngularJS as our front-end framework.

UI Framework

We had three options — no UI framework (style everything from ground-up), Bootstrap or Foundation. We thought that having a base to start off with was a good idea, especially since we wanted to build a mobile-first responsive webapp. Both Bootstrap and Foundation provides a grid to work with, and both has all the basic components styled. While Bootstrap is good because it does a large part of the design for you, the trade-off is the loss in customisability. I realised that however much you try to customise a site built with Bootstrap, the “Bootstrap look” somehow remains with your product at the end. As such, we decided to go with Foundation for the UI framework.

My role in the team (as of now) leans more towards front-end development. As such, I haven’t really worked on any python code yet. However, working on the front-end, I have already started facing several problems.


One problem I faced was nesting views in template files. After reading through lots of documentation, I realised that AngularJS does not actually support nested views out-of-the-box. However, they had a new project (ui-router) what would do just that. After reading some documentations (and lots of Stack Overflow answers), and many more hours of trying, I finally got nested views working properly!

Another challenge surfaced when some of my project-mates tried to clone the repo and build the project but failed. We found out that Compass Sass was producing different results probably because we had different versions of Compass installed. As of now, we’re still in the midst of figuring out why this may be the case, and our Stack Overflow question has been quiet with no responses.

CS3216: The Beginning

The first I heard of this class was through a mass invitational email sent out to all students in SoC. After reading the opening line, I was immediately drawn to find out more.

Have a great app idea and wished there was a course in NUS that would help you make it a reality?

Nop, it wasn’t that I had a million-dollar idea that I hoped would turn into a successful start-up over the course of 3 months — I just thought it’d be pretty fun to spend a term learning more about stuff that I love.

Before I get to the “What-I-hope-to-learn-in-CS3216” part, and since this is the first post, I thought I should start off with a short self-introduction. I’m a second year undergraduate taking the Information Systems course in the School of Computing (though numerous profs and seniors have been poking me to switch from IS to CS). My journey with programming started off about ten years back when I taught myself some basic HTML & JavaScript. In my high-school days, my interest in the Web led me to learn some PHP & MySQL. I recently also picked up Node.JS from the summer project I was working on for Orbital.

What I Hope To Learn In CS3216

There are many things I would like to learn about software development, be it in this class, or outside the class in my own free time.

Technical Skills

While I’m not completely new to web development, the list of things I would want to learn never seems to end. Apart from learning how to make use of the Facebook APIs to build something useful (which is the first part of the class), I also hope to learn about other tools that help simplify development. I’ve seen countless open-sourced projects do things like unit-testing and use services like Travis CI to build and run tests on their apps. I hope to learn what these tools are used for and how they can simplify the development, build and deployment process.

UI / UX + Design

Over the years, I have picked up bits and pieces about what a good user experience should be like. However, that being said, I’m still not that good a designer myself. Given that there will be twice-weekly UI/UX reviews on all our programming assignments, I hope to learn from the TAs as well as my project teammates.

Working Well With a Team

Most of the technical projects I have worked on had no more than two people writing code. I hope to learn how to work effectively with a team that is slightly larger and more diverse. When it comes to code collaboration, nothing can be more useful than a version control system like Git. While I have used Git for some of my projects, I’ve never needed to work in a setting where branching and merging becomes incredibly useful.


Perseverance, in two different sense. First, perseverance to continue working on a project all the way through completion. Too many times, I started personal projects that I abandon midway when I become more interested in a different thing. I hope to end off the term having a project of my own that is useful to other people. In another sense, I also hope to be able to survive this class that I’ve heard so much about. Seniors have shared about how crazy the workload can get, and even Prof Colin himself warns that the course is consistently “known to be very brutal”.

I’ll end this first post with an apology for not being able to attend the first CS3216 class. As I’m currently in San Francisco taking summer classes at UC Berkeley, I have no choice but to miss a week of class.