Things needs improvements

After listening to the critique to Things, I have a sudden urge to try this out but soon got disappointed by absence of an Android or web app. Therefore I turned to its iTunes descriptions and screenshots instead. What I see is a great app solving the problem of everyday task scheduling in a manageable way, and I would like to talk about them in details. On the other hand, I begin to see some big issues with the application which will be brought out later on.

First is that its user interaction and interface is sharp and responsive. From their actual screen footage, its transitions are quick and sharp; and labels and  controls are visually standing out, and therefore I think I will not get confused by the state of the app or not know what to do or how the app’s functions work. I appreciate their significant effort into user interaction, because as a task management app it serves to response to queries and commands from users. It is crucial to provide important information on time in Things. This is one, I think, that contributes to Things’ success.

Second is that its workflow is easy to understand. Things is to be used daily and needs to be handy when users just want to get things done quickly. Here I notice that its operations are minimal. On the home screen, users can choose to see tasks under different categories, sorted by their states (done vs. undone), dates and projects. Adding a to-do is as simple as tapping the plus icon, choose categories and pick due time. The scrolling calendar does not require one to tap on arrows to pick dates like in other to-do apps. Toggling the state of to-do items is handled by the box beside them, which are in short reach. There is no extra transition of screen and controls are appropriately placed at relevant places, and the path of workflow is short. Things is an app to be used everyday and its simplicity in workflow relief users from fatigue of manipulating their information. This is an important lesson to be learnt.

Third is about its integration with iOS system. Things is an app in Apple software ecosystem. It operates in Mac OS X, and three iOS devices. Integration with iOS functions was mentioned as a great feature of the app. It supports notifications, Handoff, sharing to-dos from or to other apps and Background Refresh. These makes the app seamlessly integrate into iOS workflow and develops user loyalty. It is a reasonable thing to look out for developing on iOS platform. It is not only enhancing app’s functions, but also make the app unalienable part in use of Apple devices. Therefore, Apple device users might consider installing the app every time they buy a new Mac or iOS device. This is a good way for Things to grow and sustain user base.

There is also a service provided, called Things Cloud. It is essentially a cloud storage for Things’ to-do items and it enables synchronisation across Apple devices. Things Cloud is invisible to users, which is a point that they can improved on. Since it supports pushing to Apple devices, it would be nicer to support other devices as well. Actually here is a solid use case: if one’s iPhone is out of power, and he or she needs to check out her to-do for emergency, the only option is to use others’ Apple devices or smartphones. It would be nice if there is a more cross-platform solution to this, such as a web app or Android app.

There is a Project category for to-dos, but it is still for personal use only and collaboration tasks have to be added manually. However, in order to support collaboration as suggested by the critique last night, Things Cloud needs real upgrades. The developers need to move some to-do management logic online. I would like to make a suggest for the developers to upgrade their infrastructure and support collaboration, so that they can extend to wider audience.

Other than that, I am looking forward to Things on Android very much.


ES6 Classes

Today this study is about the latest ES6 Classes. This new construct is a part of Ecmascript 2015 standard, which has great potential on reducing boilerplate and also some small misconceptions.

First we have the old style classes. Before ES6, functions are at the same time constructors. It is possible to call ordinary function as constructors (as it is possible to have functions with no presence of [[Construct]] interface), and internally there is a special routine to handle constructing calls. Normally if we want to call function as constructor, we call with an operator ‘new’.

function ClassA () {}

new ClassA();

This time in ES 6, we explicitly declare ClassA as an empty class with a constructor. With the keyword ‘class’:

class ClassA {

constructor() {}    // that is equivalent to function ClassA() {}


new ClassA();

The difference here is that ClassA now have no [[Call]] interface internally. :O. That means you cannot call ClassA as a normal function, which may enable you to use ClassA to extend existing instances. This is a point we will talk about later.

Prototype methods can be placed directly inside the class declaration. This remove even more boilerplate like ClassA.prototype.* .

class ClassA {

constructor() {}

sayHi() {console.log(‘Hi’);}


Inheritance is even more easier. Previous ES versions has to assign prototype chain manually to Object.create(). If there is a class ClassB inheriting from ClassA, we need to do the following:

function ClassB () {}  // ClassB constructor

ClassB.prototype = Object.create(ClassA.prototype);  // new instance of the prototype template

ClassB.prototype.constructor = ClassB;  // correction on constructor pointer

With ‘extends’ keyword, we simply put:

class ClassB extends ClassA {

constructor () {}


Calls to superclass constructors and methods are much easier, without use of for setting the context and explicit reference to the prototype of the superclass.

class ClassB extends ClassA {

constructor() {

super();  // necessary here in order to use ‘this’ in later part of constructor; note that this call to ClassA has context properly assigned to ‘this’ and [[Construct]] interface is used instead of [[Call]], in contrast to the old way to call super constructor:;


sayMoreHi() {

super.sayHi();  // here ‘this’ is also properly assign at the time of call



The nice part of this new syntax is that we get rid of a lot of boilerplate and call the functions with correct interface ([[Construct]] instead of [[Call]]). It abstracts the prototype mechanism to a more readable and friendly format.

New learners might find this syntax largely departs from the usual functional approach to instantiation of classes. They will not be able to see how prototype chain works under the class syntax. This is where misconceptions may come in. I would argue that this departure is necessary in learning another important internal mechanism of function application. One will have to distinguish what function can be call directly and others must be call as constructors. Examples are Document, Window, SVGElement and more.

I will foresee some difficulties in understanding patterns like factory and delegation, but these concepts do not come free in the first place even before ES6 classes are introduced. One must understand the mechanism of closure and environment- which still applies to ES6 classes- before talking about patterns. Introduction of classes should be welcomed in teaching closure, environment and eventually prototype chaining.

Thoughts about presentation

When I was listening to workshops today, I suddenly recalled the moment when my professor reminds me to think in others’ minds and engage them actively. I think this is the right time to think about effective ways to convey ideas.

Thinking in other’s minds requires skills, but there is something in common. When a speaker talks about anything, he or she needs to consider what the listeners want to take away from the conversation. A speaker can appeal to their desire for further development of ideas from a shared, common ground – which the audience have learnt before – and learning new knowledge; or he or she can frame the ideas and point to a new direction and lead the audience to new discoveries. That naturally bring excitement to the audience and the engagement takes place. This really makes the audience excited and it is good for their learning.

In that way, a speaker can understand what elements of discourse can lure the audience. I really find some parts of the demonstration intriguing because I am fond of hand-on experience, and the teaching of techniques is organised in a way that the process reproducing the said effect becomes easy. Setting a commonplace scenario (like commit conflicts, for example) and appealing to our emotion of annoyance works well when a solution is explained and the advice is given.

I believe the last time that I got nervous and lost myself in speaking during the Talent Show was an exception. Excuse me for making an excuse now. I believe I was absorbed completely in the mathematical puzzle showed by someone before, and I was then shocked when I knew the turn was mine. I know I can do better than that.

Okay, today’s three things:

  1. Singapore Chinese Chamber for Commerce and Industry is a really history-rich organisation. It is surprised to know that the Chamber, with the Indian and Malay communities, has such great influence on nation building in Singapore.
  2. USB 3.0 interferes with Wifi’s 2.5GHz channels. That is why smartphones do not use USB 3.0 for data transfer, since EM wave interference shielding is hard to implement on such small platform. Even worse, future USB standards post a interference problem again. By then it interferes with Wifi 5GHz channels. Oh boy.
  3. Yes. ‘git checkout’ is so good!


Today’s three things! The first is Quine-McCluskey!

Quine-McCluskey algorithm is a process of reducing a boolean function into a minimal min-term form. A boolean function’s input is n bits (allowed to be 0 or 1 at one time), and its output one bit (allowed to be 0, 1 or not specified). For inputs of less than four bits we can use Karnough mapping, but cases where a function’s inputs are more than four, Quine-McCluskey comes in.

The first step of this algorithm, works similar in principle to Karnough mapping, involves identifying non-reducible prime implicants. It is also trying to merge pairs of inputs giving output of 1 or not specified (which is also called min-terms) that are varied from each other by only single bit. For two min-terms that satisfy this criterion, a new “min-term” is produced from the two, only with the position of the different bits occupied by a symbol representing both 0 and 1. These new compressed “min-terms” are then again treated by the algorithm and might merge with other “min-terms”. Finally, those min-terms and the compressed ones that has never being used in compression are kept, and the rest are discarded.

Now we have a set of min-terms that has been compressed, but that might not be the minimal. We now need to proceed with the actual derivation of minimised expression. Here a prime implicant chart comes in. A prime implicant in this set of min-terms is the unique one that contains a particular original min-term. After laying out the compressed min-terms as rows and original min-terms as columns we have a table, and we can put stars in those cells to indicate that original min-term is covered by some compressed min-term. We can just pick out these prime implicants, removing the columns covered by them and repeat the process.

The worst case happens when there is no prime implicant left, but we still have original min-terms uncovered. We can use Petrick’s Method to determine the minimum cover, which will probably be explain later today/tomorrow.

And yes, this algorithm is HARD to follow, and grows exponentially in time. Unfortunately we might not be able to do better even with heuristics, since boolean function reduction is NP-complete. :O


This is today’s three things.

Quadtree is a data structure. It is a tree with each nodes having zero (leaves) or four children (internal nodes). Naturally it can be used to divide a 2D space into four quadrants recursively. In this way each internal node represents one square area, and its four children occupies the four quadrants of that area. Its operations consist of insertion, deletion and split. Split is performed when one leave is containing too many objects. It creates four children under the overloaded leave, put its objects of the four quadrants into their respective nodes.

One important use of quadtree is to check for potential particle/object collisions. Suppose there is one object out of many objects in a 2D scene that we are interested in, and we want to see what it is colliding into at a particular moment- say a bullet in a shooting game. First we arrange all the objects into a quadtree, and see one node that contains the object of interest. In that square occupied by the node, this object will only possibly collide into objects in the quadrant it resides in. If we work out the path from the root to the leave containing the object, we have a set of objects possibly colliding with it. This enables us fast detection of collision.

Will this technique be possible to apply a similar scenario, say 3D space with “Octree” (8 children per internal node)? I can imagine it being not so helpful, as we can have more complicated shape with 3D or higher dimensions. Sizes also matters. If the object of interest is huge and surrounded by small particles, quadtree or octree will not help as we always end up checking most of the particles.


Other small things:

  1. I am excited about Wayland. I am eager to see NVidia proprietary driver working with Wayland. However, while Wayland does not require Kernel mode setting (KMS), its compositors (which window manager will depend on, like kwin) need it. NVidia drivers support EGL, but not KMS. KMS is an improvement for controlling graphic card configurations, including screen resolution.
  2. Pressing Ctrl+a or Ctrl+x in Vim to increment/decrement numbers at the cursor position. Wow.

What do I hope to learn?

Okay, so CS3216 is about to begin!

My expectation of this coming journey on CS3216 is currently high! I hope I would learn and remember those things:

Technical stuffs: version controls, package/project management tools.

Engineering mind: Software engineering concepts and practices.

Business eyesight: Better grasp on the current app markets, and learn what people actually want from us, the CS people.

I don’t like this blog to die after CS3216. Although it is open one the day before CS3216, I would like to keep this blog running. To do so, I would force myself to update on three things I learn each day, no matter how small they are.

The Three Things:

  1. SMIL is going to die, but Web Animation is not ready in major browsers yet. Element.animate is the best we have for now.
  2. I read observation module of Polymer framework, and I learn that they are going to implement an reference counting “garbage collection” on observed models. I have this in my watch.js already, but I still need to look out for leakages caused by observation. WeakSets looks good to me.
  3. CUDA prefers structs of arrays instead of arrays of structs! The latter is faster by about 2 factors of the former. I need to investigate this behaviour.