Month: September 2017

Week 5

Assignment 1

Assignment 1 has come to an end and this is the final product we ended up with:

Some things I have learnt from this assignment:

  1. Various css/javascript tricks for mobile responsiveness (eg. the use of window.onresize to make Twitter Bootstrap’s ButtonGroup horizontal when overflown to next line since some component props cannot be altered by CSS alone)
  2. Redux’s mapStateToProps gets invoked for all components whenever any part of the redux state tree changes, then a shallow comparison between the new props and previous props is done to determine if component should be re-rendered (after the additional shouldComponentUpdate check)
  3. null and undefined have very significant difference when it comes to optional parameters, as null overrides the default argument in Redux reducers while undefined does not. Hence in initial hydration of the store (eg. from local storage), fields that are not set should be set to the value of undefined rather than null so that default arguments don’t get overridden.
  4. The trade-off between storing all states in Redux store vs keeping UI-specific states within local components. The former allows time travel debugging and caching if desired, while the latter is simpler to implement/modify (skip all the boilerplates to interact with the Redux store) and keeps the Redux state tree cleaner.
  5. Implementation of routers for modals and collapsible panels in order to allow Facebook sharing integration.
  6. The intricacies of presentational and container components pattern. Eg. when a stateless functional component contain containers, it might affect the reusability of that component. Hence Redux’s ubiquitous store should not be abused and sometimes it’s still better to pass down props from parent components to child components (instead of child components getting state from Redux store directly) to enhance reusability.

Assignment 3

For assignment 3,  our group realised we have a common problem of missing the train/bus stop to align as we were too focused on our phone/dozed off. Furthermore, it’s very inconvenient to check the google maps/look outside the window constantly to see if we have arrived at the intended bus stop.

To solve this problem, we wanted to create a mobile app in React Native that automatically triggers a mobile notification/alarm when we reach a destination.

The destination will be manually set by the user initially (through selecting the MRT/bus stop name) but the setting will have an option to be recurred so that users will not have to set it manually every time before a trip.

There will also be smart detection to make sure it only alerts when user is actually arriving at destination instead of leaving the destination. (eg. alerts when user arrive at Com 2 bus stop from Clementi, but not when user is at com2 bus stop but is actually leaving for Clementi)

Unfortunately, the teaching team limits assignment 3 to pure PWA  (Progressive Web App) only and disallows React Native.

A PWA is not able to retrieve user’s geolocation when the browser is closed. There was a specification to add Geofencing to service workers but it was abandoned 🙁

As a result, we have to make adjustment to the idea. The user will now have to activate the app every time before the trip instead of automated recurrence. Thankfully, Web Push API has been implemented in all major browsers. Hence, our users will be able to receive push notifications on their mobile even when the browser is closed and the phone screen is turned off.

Week 4: Application Seminar

Group presentation for the application critique has concluded and our next task is to summarize and critique on another group’s presentation. I have been assigned to critique on Group 6’s presentation on Mendeley. I will briefly highlight 3 main points presented by the team and give my own thoughts about them.

Main point 1: One app to rule them all

Mendeley is a one-stop solution to aid researchers in writing and publishing their research papers from scratch to end. The presented team did not have time to go through it in detail but I will highlight it step by step here:

  1. Ideation: Through their social platform encompassing a global research community, one will be able to easily find research partners and project ideas to work on
  2. Data searching: With their searchable library containing public research papers, one can easily to mine and find relevant data from its big data repository
  3. Data storage and organization: Researchers can store their collected data on Mendeley’s cloud storage, allowing access from anywhere, as well as version control (think Git) to allow researchers to keep access to all versions of their datasets, which is particularly useful for longitudinal studies
  4. Data processing: Mendeley allows one to conveniently annotate on the research paper and datasets, as well as linking articles to the data
  5. Data sharing: Researchers can share data among each other, increasing the availability of datasets
  6. Citation generation: Allows researchers to generate citations with just a few clicks
  7. Peer review and discussion: Researchers can review and critique each other’s research paper before it gets published
  8. Research profile: Researchers can create a research profile with a compilation of all their publications and affiliations.

In summary, Mendeley is a single platform that makes the tedious process of publishing research papers manageable and efficient.

This process draws a parallel between that of publishing a research paper and publishing a software application. In the software development lifecycle, one must go through the daunting process of collection of facts, analysis, design, development, integration, testing, deployment and evaluation.  Various tools have been created to aid in version control, continuous integration, continuous delivery and continuous deployment.

My assignment 1 team currently employs a variety of tools for this entire process, including Google docs, Github, Trello, Invisionapp, Apiary, Netlify, AWS, Travis, Selenium, SourceTree, IDEs, CLI for npm, React Developer Tools etc. Evidently, I have to manage and switch between so many apps, hindering my ability to develop efficiently.

Yet, a panacea for a process as complex as software development might never exist. Developers have a wide range of preferences and current tools in the market are well suited only for their targeted niche. Any attempt to produce a one-stop solution to software development will prove arduous even for software giants like Google.

Main point 2: Inconsistency across different platforms

As the presented team highlighted, the application is inconsistent across its supported platforms (Desktop, web and mobile), not just in terms of design but also functionalities. Eg. some functionalities are present on one platform but not another.

I wholeheartedly agreed that this inconsistency is rather undesirable. I often come across responsive mobile web apps that hide certain functionalities and I’m forced to select ‘request desktop version’ then pan and zoom around to access the desired functionalities.

While I understand that it’s a design philosophy to minimize clustering on a mobile web app, I believe that most designers underestimated the number of users who would want access to slightly more advance functionalities, and more careful design choices could have been made to allow access to them without severely compromising the app experience for the average users.

Main point 3: No automatic syncing

As mentioned by the presenter, Mendeley requires one to manually synchronize the data to the cloud.

With the proliferation of cloud apps like Dropbox and Google Drive, automatic synchronization has become a user expectation and such shortcoming would certainly frustrate and drive away users.

In the rapidly evolving world we live in today, it is important to keep up with the technology trends and design our applications with modern standards that meets the expectation of our users.


My thoughts on the Application Seminar

Computing students have a common conception that there are 10 things one can do in life:

  1. Writing code
  2. Wasting time

CS3216 is meant to be a module where one is not limited by the rigid curriculum of a typical module and is instead given a lot of freedom to learn by themselves and develop innovative apps on their own.

However, in this assignment, we were dragged away from our programming safe haven and forced to engage in mind-numbing task of making and preparing for Powerpoint presentation.

I understand that the intention behind this assignment is to provide an opportunity for us to systematically evaluate a successful application, so that we are able to learn what makes it successful and avoid its pitfalls.

Nonetheless, I believe we have already been subconsciously doing that when we use various applications in our daily lives. Therefore, the experience and knowledge gained might not match up to the time and effort invested on this assignment.

Nevertheless, to say that this assignment is a complete waste of time is neither politically correct nor fair to the assignment creator. As an optimistic opportunist, I always make the best of every experience I go through, regardless of whether it is forced upon me or that I willingly partake in it. I have certainly have picked up invaluable skills and improve my non-technical skills through this learning experience.

However, life is all about making trade-offs. In this increasingly competitive world, it is not sufficient to be learning. One must learn efficiently and effectively, utilizing every single second of the very limited time we have in this world to its maximum possible potential. Consequently, it is not easy to justify that this assignment is the worth the opportunity cost.

Week 3


Dr Damith conducted first part of the lecture, which touches on presentation skills. Unlike typical lectures of this nature (eg. those in CS2101), I find the lecture quite interesting as there were many useful pointers that are logically sound and yet commonly overlooked.

The second part of the lecture is conducted by Su Yuen, who touches on UI/UX design and brought our attention to pre-designed website templates that we can purchase to accelerate the development process.

This reminds me of a classic literature by Frederick Brooks: The Mythical Man-Month. Brooks postulate that the very nature of software precludes any invention that could have a multi-fold improvement in software development productivity, and therefore there is no silver bullet, which culminated at the famous quote:

The best way to attack the essence of building software is not to build it at all.

Like Su Yuen, Brooks also asserted that software should be purchased off the shelf whenever possible.

Yet, despite the advice from these brilliant individuals, I remain unease about using pre-designed website templates.

First, we have to spend considerable effort in searching for and evaluating a suitable template that is inline with our design style and technology stack (eg. React + Redux).

Next, we have to become familiarized with the code base and either adopt the code organization and style of the existing code base or adjust it to our liking.

As web development is a rapidly evolving field, it would be hard to find a well written code base that satisfies the requirements and employs the latest web technologies (eg. ES6). In the end, we might end up having to modify so much of the code base that we might as well have written it from scratch.

Yet, the very nature of software, in which a copy can be provided to another user at no marginal cost, compels one to believe that there are certainly scenarios in which developing on top of a purchased software can be more efficient than building it from scratch. Nonetheless, we should not rush into purchasing website templates and careful consideration has to be made with regards to the suitability of the chosen template for the task at hand.

Assignment 1 tidbit

When a component view is shared on Facebook, an URL link must be created that can be referenced back to the component view.

As some of our component views to be shared are collapsible panels and modals, it is slightly unconventional to control their state (collapsed, opened) through URL routing.

In the end, we manage to resolve it rather elegantly with React Router without compromising on performance or the Redux principle of single source of truth through  components such as Switch as well as push etc from the react-router-redux bindings.


© 2024 Course Reflection

Theme by Anders NorenUp ↑

Skip to toolbar