AY 2016/17

Posted: 2016-12-02 11:22:31 +0800

If you are a student interested in taking CS3283/4 in AY 2016/17, Semestser 2, please take a look at the new site for the AY 2016/17 version of MTP.

If you took CS3283/4 in AY 2015/16 and would like to help as TA in AY 2016/17, please let Wei Tsang (ooiwt@comp.nus.edu.sg) know.

CA2 and CA3

Posted: 2016-05-08 00:44:31 +0800

Here are your CA2 and CA3 individual grades.

CA      2	3
014J	M	M			
024U	E	M			
029U	B	M			
038W	M	M
077N	E	E			
082Y	M	M			
093J	M	E	
139R	M	B
211L	B	M			
223B	E	E			
239W	M	M
304U	M	E			
329J	M	M			
384H	M	M			
398H	E	E			
409N	F	F
434H	B	B			
456Y	B	B			
493R	M	M			
493X	M	M			
521M	M	M			
527H	M	M
535R	E	M			
543J	M	M			
546J	M	M			
558N	E	E			
571W	M	M			
573J	M	E			
586J	M	E			
587M	M	M			
598X	M	M			
605U	E	E			
631N	M	M			
654L	M	M			
673A	M	M			
674M	M	M			
696W	M	M			
723U	M	M			
734N	M	M			
735R	B	M
738W	E	M			
773L	M	M			
788Y	M	E			
802X	F	P
808L	E	E			
818M	P	B			
853R	B	B
858Y	B	M
861N	M	M			
862M	M	M			
887U	M	E			
891L	M	E
906J	M	M			
960X	M	M			
972J	E	M			
995Y	E	E			


  • E: Exceed Expectation
  • M: Meet Expectation
  • B: Below Expectation
  • P: Poor
  • F: Fail

STePS Poster Template

Posted: 2016-04-07 09:45:31 +0800

I have prepared a poster template for our module for STePS. Please feel free to customize the font family, colors, etc, but keep the project ID location and sponsors logos fixed.

Towards the Finale

Posted: 2016-04-01 15:10:28 +0800

Here are the expectations for the final three weeks (Week 12, 13, and 14 (Reading Weeks)). You should not be adding more features into your project, but you should now focus on evaluating the efficiency, usability, security, and robustness of your project, as well as preparing for the final report, STePS, and final presentatation. You should also revisit your user requirements from last semester and make sure that all functional, non-functional requirements have been achieved and revisit your software achitecture from last semester and cross-check with the state of your project. If some of the requirements are not met or your architecture has changed, why?

Important Dates

  • 17 April, 23:59: (Was 15 April) Submissions of final project report and developer’s guide. Submit your project report, named teamname-proj-report.pdf, and developer’s guide, named teamname-dev-guide.pdf, into this IVLE’s workbin, replacing teamname with the name of your team in CamelCase. You only need one copy per team.
  • 20 April, 18:00: STePS. This is not graded, but is a great opportunity to check out what others have done in CS3283/4 as well as other modules, practice explaining your projects to others, answering questions about your projects, and win some prizes! Participation is entirely voluntary, but I have high hope that you will be there. You should be proud of what you have achieved (I know I am!) and show case it to other students and industry visitors.
  • 21-22 April: Final Oral Examination. Each team will have 45 minutes to present your project to a team of evaluators. The goal of the presentation is to (i) show the evaluators what your project is about, (ii) highlight changes from your requirement and architecture design last semester (what and why), (iii) explain how you achieve efficiency, security, usability, and robustness of your project (highlight interesting findings). Many of the tips from last semester still apply.
  • 22 April, 23:59 By this time, you should have a release from Github tagged as a final project release that we will use as the reference to grade. If you have other contributions that did not make it into this release (e.g., in other branches), please be sure to let me know about it.
  • 29 April, 23:59 Final peer review for the project.

Software Tools/Library

Posted: 2016-03-18 01:53:10 +0800

In this lecture, I will share with you some tools that might be useful for your project. Not all tools apply to all projects, but it should give you an idea to look for similar tools that suit the programming language or operating system you are using. This list is not exhaustive, and I don’t have first hand experience with many of them.

Message Passing Formats

Almost all teams passes information around between client and server in JSON format. JSON is human readable so it is great for debugging, but it is bloated in size since it is encoded in plain text.

To address this problem, there are several frameworks that provide binary serialization of JSON data. messagepack is one of them. If it turns out that transferring JSON data is a bottleneck for your project, you may want to consider this library.

Linting Tools

A linting tool perform static analysis on your code to check for style inconsistency, ensure good and professional coding habits, and identify potential bugs. Think of it as a computer-assisted code review.

Most of these tools allow configuration of rules – what do you want to, or do not want to, detect.

Virtual Development Environments

Vagrant is a really cool and simple way of creating a virtual development environment. It allows a developer to easily setup and teardown an environment when switching between different projects, ensures different developers on the same team work on the same environment (even if they run different OSes), and simulate deployment environment locally.

You can choose from a large catalogue of boxes, which are basically pre-configured virtual development environments (e.g., here is one with MySQL 5.5/PHP 5.4/Apache 2.2, and another one with Node.js, MongoDB, Redis, Heroku and Travis-CI).

OWASP Zed Attack Proxy (ZAP)

ZAP is a security tool that helps you find security vulnerability. DO NOT USE ZAP ON ANY WEBSITE OTHER THAN YOUR OWN !! ZAP runs as a proxy between your browser (some browser configuration needed) and your server. ZAP can launch an attack on your server to find any common vulnerability.

Network Traffic Controller

Most of you runs your client and your server on the same host, or on two hosts belonging to the same network. Such setup is convenient for development, but does not provide realistic network conditions to test your client and server. You might find that your application is fast and responsive on your laptops, only for it to crawl when you deployed it onto a cloud server.

Traffic controllers are tool that change your laptop network conditions so that it simulates a more realistic network condition (limited bandwidth, higher delay, packet losses, etc.). So that you can run your client and server under more relistic network conditions.

Mac users can download Network Link Conditioner as a developer’s tool from Apple. This tool is provided as part of the Hardware IO Tools. Note that it does not work on localhost/ Adventurous students can check out dnctl.

Linux users can use tc, which is usually bundled together. The command line arguments, however, are pretty complex.

Chrome has a built-in throttling mode but it works only for traffic from/to Chrome only.

Server load testing

ab is a web server benchmarking tool that allows developers to generate multiple requests to the server. This is a very useful tool to stress test the system, as well as to help with profiling the server.

Code Beautifier

To ensure consistent coding style, use a beaufitier, which can automatically reindent and reformat your code following a given configuration (e.g., use spaces or tab, how much to indent, etc.)

The following might be useful:

XCode and Android Studio comes with built-in indenter, but I find them less configurable than CLI tools in general.


Profiling a code involves running the code and collect usage statistics during run-time. This typically gives you the time taken to call a function (or to execute a line) plus the number of times a function/a line has been executed. Looking at the data, we might identify bottleneck within our code.

  • Django comes with pretty good profiling support. There is also silk.
  • For Ruby, see here
  • node has built-in profiler. First run node with --prof to create a profiler’s output, then run with --prof-process to produce human readable results.

XCode and Android Studio comes with built-in profiler to instrument your code.