Week 13 Reflections

Time really flies. It’s week 13 already and CS3216 will be over in a week or 2. During lecture, it was re-iterated that this course trains us more on soft-skills. To be honest, I did not join to be able to talk to people nor be able to lead a startup with great ideas. I have concluded over the past few years that even though my technical skills/breadth of knowledge of the technologies out there may be inferior to many fellow students in this course, my human aspect is even worse to the extent that it is beyond saving. I came in with the aim of improving technical skills(both front and back ends) and being better than everyone else but things had to go totally the other way round. Being constantly reminded by reality that the title of “God” is unattainable makes me feel like I have wasted so much time chasing after technical superiority. After going through this course and the final project, I am not sure which direction I want to head towards anymore.

Bad things aside, I think my biggest harvest from this course is being confident enough to implement basic(not guaranteed nice-looking) UI functionalities and also realising how fast-paced working like a startup can be when trying to churn out prototypes quickly for user testing and feedback. I certainly wished my experience in this course could have been much better and I pray hard A- is still attainable even after a few hard falls…

Advertisement

Week 12 Reflections

Yet another long overdue post.

This week was not very kind for me… First, somehow during presentation of our progress report, the app somehow came across to everyone as just a chat app instead of a tool to help with travel planning. Well, at least better now than later. Following this(which costed us too much of presentation marks), we have decided to focus more on the timeline view of the itinerary items for a trip. The current version of the itinerary viewer is still far from ideal in my opinion(can’t be helped, not much time left). What I had in mind(yet to share with the group) was to be able to drag and drop items on the timeline as some form of “shopping cart” before checking out everything in the timeline under 1 payment. This seemed daunting as none of us have experience in doing something like this and thus will take a long time to perfect it.

This module has put me under too much of a stress as I now struggle to find time to catch up/start on projects for other modules or even to find time to start revision for upcoming tests(week 13). I really look forward to the end of all these. Things have turned out totally against what I wanted in the beginning.

T

Week 11 Reflections

The week started with talk by Carousell. The biggest takeaway for me was the idea of technical debt. It was a big reminder for me to not blindly hack my way through for the final project and in future projects, but to be aware of the cons of the hackish solutions used, which someone has to fix it up in the future. A small instance of such happened this week when I thought of how the back button logic I implemented some time back could turn out wrong because I took the easy way out by using “window.history.back()”, which causes the back button to bring the user out of the app if the user directly access the app via URL and not the app’s UI flow. Thankfully, it was not too hard to rework the logic from scratch.

Another such problem is binding data fetched asynchronously from server side to HTML where my angular directive has to compute derived attributes, which are to be binded to HTML, from the received data in the directive’s constructor. However, the data takes time to arrive and by the time this happens the execution flow already missed the timing. I could not find a proper way to resolve this as the simplest solution of using semaphore is just stupid for single-threaded Javascript. I found a hackish solution but it restricts whoever passing in asynchronously-fetched data to my directive to have to code in that 1 way in order for it to work properly. I guess this is ok if everyone follows this strictly. I guess this is an intentional technical debt?

Week 10 Reflections

This week’s talk was interesting for me as I am more keen on things related to Linux, server administration, deployment etc. This aspect of app development/production tends to be neglected by most app developers. Another neglected aspect, which I myself also commit, is not paying attention to security as I do not know what is the minimum must-have security features. Also, I feel that setting up even HTTPS is kind of a tedious process.

This week has been hectic, with many UI and decision changes being made. The worst was when we finally had to migrate our deployment from my AWS server(I dreaded the day when AWS begins charging me $$ when the 750 free hours depletes). The process of setting up SSH access keys already took away a few hours, only to realise that there were probably some invalid unprintable characters in the authorized keys file causing public key denied. Through these experiences, I learnt more about administering deployment of web application(at least the front end as I did not deploy the database). Well, at least the thing I enjoy more from all these is being the sysadmin of the team, tinkering with server configurations, automating deployment when Git server receives pushes etc.

On the topic of optimizing for performance, I faced the problem where concatenating minified versions of the many Bower components into a single file leads to a !MB big file. While it drastically decreases the number of HTTP requests, on a slow network, this JS file may fail to be received and will cause the whole app to malfunction. This seems to become an optimization problem involving tradeoff between download speed(due to smaller files) and latency due to number of HTTP requests sent and being waited on. Hopefully I can come up with a solution closer to STePS and production launch.

UI-wise, it was annoying to have to constantly change/improve the workflow of the same feature several times that there were not many new features added. On the other hand, I realised how convenient front end development became when there is a set of well-established CSS classes, each adding distinct CSS features to the UI component. Defining colors as variables in LESS saves so much pain of having to memorise those color codes, and also helps keep a consistent color scheme. With the aim of unified UI design, styling UI components can be as easy as looking up CSS files and choosing the right class to throw at the HTML element.

Week 9 Reflections

The week started off with Cheryl from Cyan Communications giving a talk on how to talk to people(iirc). As a founder/co-founder of a startup, it is indeed important to be prepared to make yourself contactable to others at all time through namecards etc. Attending networking events like conferences lets you know about the many fellow startups in the industry and hopefully some of them may present themselves as opportunities in the future. The most important takeaway is the one that is the hardest to walk the talk: talking to the people out there, asking people who are complete strangers to you to try out your product or for their opinions of your product or the market.

Honestly, it is near impossible for me to engage in a decently-long-live conversations even with acquantainces. The only things I ever talk about are code, server administration and Linux(not that I am that good at all these though). Seriously, no layman, not even many computing students, would even know, let alone care about these things. Anything else, I know next to nothing to even talk about them.

It’s not like I have never thought of doing startup. That was when I was still serving NS. Eventually I realised it is not as simplistic as it seemed to me initially. I was simply not prepared to pitch to investors for funding, approach people to get them onboard the app etc. The killer factor for me was: no creative idea that can distinguish itself from the rest of the market. I dropped my double-degree with business after 1 semester despite high CAP because I could not stand the thought of having to win in debates against people with the gift-of-the-tongue when it comes to class participation.

Back to final project progress, progress has been slow for me in the past week as I overcomplicated the front end requirements for Facebook login in that I try to handle ALL possible cases that cause login check logic to fail, as well as eliminate latency in fetching Facebook SDK(which is impossible) that caused the app to conclude that the user is not logged in when this is not the case. Eventually, I was convinced that the login session via Facebook should not be tied to the user’s Facebook session at all. This helped simplify my case a lot, though there are still a few minor problems with sessions that need to be fixed.

Some of the basic functionalities got wired up with the back end over the weekend, which I felt was good enough a progress, though I wonder how we fare compared to other teams in terms of progress.

Week 8 Reflections

The pace of the final project has started to pick up. The past week was mainly setting up the Ionic project and working on some parts of the HTML mockup.

Being new to Ionic and Gulp, a lot of time was spent figuring out the purpose of the directory structure and setting up automated tasks that run as the code files change. With regards to directory structure, it was created by the CLI tool like this for a reason, and I only realised it after searching online for answers to why none of the bower components are rendered when app is deployed as native mobile app. Turns out it is not just the result of best practices but also where does the CLI tool look into when packaging files into APK. Gulp and automated tasks are a contention for dispute. For a web app, I love to have the final version minified and compressed to reduce latency and bandwidth consumption, but setting up such tasks in the early phase makes me viewed as doing premature optimization and software engineering purists hate that. While I know that this should be left to be done when close to release(maybe before STePs), the harsh truth is that when the time comes, everyone will be so engrossed with adding in final touches to the project or fixing last minute bugs that no one actually bothers with it. Thankfully, someone came up with a non-minified task to help the rest of us debug better during development. This allowed me to run my minifier whenever I want to test the app on my mobile as it would not affect the rest of the team’s code since the changes are not committed.

Project-wise, while some of the pages were ok with the external party, there are many more that have yet to be done as some of the pages were not what they wanted and rework needs to be done when they send us the layout. I hope these would arrive soon as getting a fully working UI up and integrating with the back end takes considerable amount of time and I do not wish to sacrifice my other modules any more.

Week 7 Reflections

This week in short: mostly a breather from CS3216 after 2 gruelling assignments.

App idea was a massive headache for us until we managed to get an external party project. Being a team of only developers, with no creative person or someone with business sense, it is just so difficult to come up with an idea that will not get shot down badly by the teaching staff nor get a low score for any component. I came in with the objective of improving implementation skills, as well as problem-solving(tech and implementation problems) in context of real-world app development. It will be great if I can ignore the human aspects totally(yea I know the real-world is not like that, too cruel).

This week’s talk by GrabTaxi served well as a reminder for some of us who aspire to start a startup in the future. For the tech part of the talk, it has been a few days since the talk so I have forgotten almost all of it XP, but the 2 main takeaways I got from the talk regarding startups were: pick a problem that you really care about, and you need luck.

Well, both points are not applicable to me anyway. First, too apathetic that I don;t have any such problem to care about. Second, fate always play adversary for me. So the conclusion is that I cannot found any successful startup.

Moving on to final project, one of the tasks given by the external party was to do Open Graph meta data scraping. It seemed easy at the start until I realised security policies made it so difficult that I have yet to find a feasible solution(How did Facebook do that?). Implementing on front-end has the CORS problem as not all web servers support CORS. Implementing on server side results in a weird workflow: client sends AJAX to server, server sends asynchronous request to the given URL. So the question is: does the promise object returned to the client get updated when the server side receives data from the source? It’s just so hard to put these into words to enter in Google search so I decided to post it here, hoping it gets answered…

Halfway Through

Assignment 3 is finally over, and so is the first half of CS3216! It sure had been a painful few weeks, thinking about the various problems faced in this assignment almost 24/7. Here’s a brief summary of my takeaways.

As the main front-end developer in the team for most of the time, I did understand more about AngularJS, some limitations the framework placed on what I wanted to achieve, as well as a few hacks to get around them. It was my first time dealing with HTML5 technologies that make Web applications look and feel like a native mobile app, let alone make it useful even when offline.

I felt quite fortunate to be in my current team. The app, TL;DR, though is a simple app with few features(at least in my opinion) as it is meant to be a convenience app for reading articles on the go, has its benefits to me as a developer. The uniform UI layout for the feeds page means I can just reuse the same HTML template for all the different categories, adding a little extra logic in the controller to differentiate between the pages. This frees up more time for us to deal with annoying CSS bugs(more like CSS properties of the UI components we used from Angular Material that we did not want), as well as thinking about the tougher problems of offline functionalities, synchronisation etc.

In terms of app reviews, to be honest, most of the comments/bugs we received were already known to me when I was developing the UI(and testing concurrently). It’s just that either I decided to leave them till after the app review as I knew I could not fix them in time or that I considered them low priority compared to getting more features up.

Of all the front-end work I did, the work that I was most satisfied with myself was the background job queue.  I felt it’s the closest thing to OS-level related stuff(I’m not very good at OS though) and I like to implement things that are PERFECTLY REUSABLE.

One of the few things which I felt was a pity was not doing splash screen for Android devices. I managed to get it to work on several types of iOS devices that are still on iOS 8. iOS 9 destroys our splash screen milestone on iOS. Why did iOS 9 have to come at this time!? Thereafter I got lazy since there are too many different devices running Android, each with different screen dimensions. Another thing is the inability to postpone initializing of Facebook SDK till the app gets Internet connectivity. Most of the times I get “err: NETWORK CHANGED” when the app tries to do so. Not very sure what causes this.

This post has gotten a bit too technical on the implementation side. Looking forward, I worry about the final project as we have yet to come up with a good app idea for the upcoming project proposal, even after squeezing our brains dry(creativity and human aspects are my worst stats). We have also tried emailing external parties but they usually take a few days to reply, which does not help the situation.

I really wish to say this: time for a proper mid-semester break from CS3216.

Week 6 Reflections

This is a few days overdue as it was another busy week, with most of the time unconsciously spent into implementing part of the offline functionality milestone(turns out to need more enhancements after adding in bookmark feature recently), which is one of the many new things to me. The week ended up with CS3230 midterms, which I was forced to revise only 1 day before the test due to this assignment.

This week, I learnt about how application cache and web storage works after investing hours to read, understand, and briefly plan out the implementation. This introduced another tough problem to solve: when and how much data to store in the web storage while online? Considerations involve implementation complexity, initial loading time, and storage space requirements. After considering the trade-offs, I decided to go for “cache only what you have viewed”, using less space, potentially less initial loading time and simpler implementation. Though this means you cannot view pages not viewed before while offline, what are the chances of viewing something you do not view even when online?

With most of the UI for this assignment built by myself, I feel that my UI implementation skills have improved quite a bit as I reused the same things from assignment 1 again(this time mainly Angular Material, borrowing a few classes from MaterializeCSS to make up for the shortfall of some stylings), I still found customizing/fixing CSS a time-waster. With the schedule so tight, I could not bother myself with improving my understanding of how CSS works nor increase my breadth of knowledge of CSS properties. Thankfully, someone in the team is good with hacking CSS.

Another problem faced during development is the application cache. Because I test very small incremental changes to y HTML and JS files, I do not edit anything in my manifest file. So unless I clear cache to force a re-fetch, my testing devices were stuck with older versions of the files, giving me a mistaken impression that the new fixes do not work. The question becomes: how early should we incorporate application caching? For amateurs like myself, leaving it till the last minute is definitely a suicidal attempt but doing it too early when files are frequently changing wastes a lot of time clearing cache. What is a good way to ensure that the caching is working when released to production but not disrupting too much in the development?

Looking back, I have learnt or at least thought about quite a few interesting problems this week. For the final project, I see myself doing more of solving data management related problems, both on front and back ends, since there are already team members who are better than me on both fronts and I am more into the non-visual aspects of any application.

Week 5 Reflections

Assignment 3 has started and I am back to being a front-end developer again, except that now in the early stages of the project, I have to be the only front-end developer until the back-end is more or less completed. Despite the stress, I think it is yet another opportunity to hone my implementation skills(not design sense though).

One frustrating experience I had this week is burning a few days Googling and hacking away to fix UI bugs. It turns out that some of Materialize’s/Angular Material’s UI components don’t work well with some Angular’s directives such as ng-repeat due to scope issues or that they don’t support ids that are not hard-coded. This has led me to debate with a friend about coding for use versus coding for reuse(I personally bring coding for reuse to the extreme). My conclusion is that in this module, whatever works… No one cares how you do it, be it hard-coded values, messy code etc.

For the upcoming app review, I wonder how much is enough. This is because, it has been a hectic week, with ICPC Singapore regionals preliminary round today and barely having any time to practice for it ever since the semester started.

For final project, although I have a near-complete team, we lack ideas and the external party we contacted has yet to get back to us. To be honest, I suck at coming up with ideas(I have low exposure to society and the world so…) that I cannot be bothered to do so anymore. Hopefully things will turn for the better so I can focus only on the technical aspects of execution.