The Beginning of the End

Only 4 days left to STEPS!

So it's the end of the project and somehow (I think) we've survived 3216. I mean we don't actually know if we've passed yet.

So what do I think of final project?

1. Time constraints.

Given only 6 weeks to build this project, that's generally not very feasible. For us, making use of API and packaging it nicely... That's basically most of the work we did. In short, 6 weeks is too short to build anything significant with 4 people. Take, for example, CVWO - this year, our team did Lions Befrienders, a massive management system, that after 3 months of work we couldn't finish. And that's 8 of us working on it, 8 fantastic programmers who work together well, full time. Yep. I suppose I came into 3216 with that mentality but honestly to be fair to the module it's quite impossible to achieve such scale.

2. Ideas are key

If you don't have ideas, don't take 3216. That's basically the problem throughout the entire mod - running out of ideas as for what to do. Some ideas are absolutely lame (sorry Bubble), some aren't workable, some just don't see real world use enough.

3. Teamwork & Structure

The more fluid structure of 3216 as compared to CVWO (sorry I keep using this as a benchmark, but in any case the same would have applied to my prev internship at a startup) means that there's no clear leadership or in some sense roles. Things were terribly fluid and internal deadlines non-existent, leading to huge amounts of inefficiency. All this coupled, of course, with our other modules. Answering to Joe (CVWO team lead) or Prof Ben was much easier than trying to figure out who to do what and by when.

Of course, this is only the end of a beginning... So we'll probably see the real stuff start to pop up soon!

Versus the lazy programmer

Was reminded of this article recently (shared a long time ago by Prof Ben and Yang Shun)
https://www.entrepreneur.com/article/240644

In particular they highlighted this quote

9. Laziness.

Larry Wall, the original author of, The Perl Programming Languages, describes three good qualities in a good programmer: laziness, impatience and hubris. Laziness may sound like a bad trait for any employee to have, but IT managers have said that if you want to find the best way to do something, ask a lazy person. Chances are, that person will have found the quickest, most efficient way to do it. A company’s programming staff can often find a way to automate processes, saving time and money.

Here I need to disagree. Yes, laziness might lead you to do more automation and less work. That's a good thing.

However there's also laziness on a different scale which is the "don't do anything" scale. How bout forget about making the computer do it, let's not do it at all? Basically where laziness may be a good indicator of a person's aptitude for code, it throws away every other metric that you have on the board, and that does not play well with anything.

PIVOT

So... Here goes final project.

We started out wanting to do Treatsure with Preston. Failed horribly because of contract issues. I think mostly the contract lost whatever credibility he had and then it just collapsed into something we couldn't do.

To be honest it's a good thing it collapsed. The scope and timeframe were rather infeasible. Glad we got shocked into our senses and pulled out.

So we moved into our next contact, doing Huntbot. This one actually hit a good running start - we had a good portion of work done - most of the backend work was completed, except we hit a snag when we went through the review with Prof Colin and he decided it was too simple. He proposed some improvements but none of them were in the realm of possibility.

We then went back for Project #3 - a marketplace for telemarketers. This one, unsurprisingly, got shot down too, by Prof Ben this time. He told us we're trying to solve a 2 sided problem in a field where we had no experience. Again, he was right. We had to drop this project too.

Thankfully he linked us up with one of his ex-TAs to do the project we're now calling PIVOT. PIVOT cos we're really sick of changing projects. Really. We're off to a very late start and we hope we can rescue this. In short, it's trying to kickstart the online tuition industry. As someone who's taught CS1010FC/S for the past 2 and a half years, this is terribly interesting... As I've hated online classes. The big question is whether we can make it a convenient and conducive environment for learning.

Features coming soon ;)

Assignment 3 - Done!

Glad that this one is over. Was quite a challenge doing something so foreign this time out.

Quick overview on my scope of assignment 3:

1. Build backend, organize database

2. Open up API for the front end to consume

3. Deploy both front and back ends

4. Handle HTTPS setup, certificates, and CORS policies

5. Handle User authentication

1. Trivial. Done plenty of times, no different doing this again

2. Mildly more challenging. Just trying to think of what should and should not be returned as JSON. Like obviously I don't return everyone's oauth tokens when someone calls /api/users... But of course we want to return a decent amount of associations (esp the commonly used ones), yet not overload the caller with information

3. Deployment for back-end was pretty carefree, as it was a familiar process. Front end was rather surprisingly easy as I reverse-engineered what I did for the front. Success here!

4. HTTPS setup: Amazingly simple thanks to Let's Encrypt's integration with Apache, the only hiccup was setting server names and calling the server name rather than by IP. Almost seamless. CORS was however a headache, as matching all the stuff between Rails and Angular on separate hosts wasn't so simple. I suggest using rack-cors, and opening up the 'OPTIONS' method (wow I really learnt something here - this isn't very widespread, but it's necessary for Angular's $http!)

5. User auth was the real pain. Devise recommends devise_token_auth. Given the credibility of Devise I kinda believed them... Only to end up not using their OAuth integration (cos it was full of problems), and right at the end, realizing that this thing has way more issues like concurrency issues, plus the fact that it's not really token-based authentication. On much-later thoughts, shouldn't have used this gem.

The nice thing about A3 was the time - really managed to write tests (which saved me a couple of times here and there), even got a little spare time to set up coverage and CI tools. Though the test coverage isn't really impressive, that little bit does help with peace of mind. Strongly encourage writing tests for 3216 and writing smaller applications - be a little less ambitious and be a little safer. Compared to A1, this was really a rather more chill project.

Code for the backend is available here: http://github.com/wishpool-3216/wishpool-backend

Server Deployment

So my highlight of this week has clearly been decided: Deploying a front-end server I know absolutely nothing about.

To give it some context:
Doing Wishpool for Assignment 3, I took up the back-end role. Building a back-end in Rails (yay Rails again), after doing deployment for Assignment 1, deploying the back-end was a piece of cake. Well, almost. I spent like some 10 hours on it back in Assignment 1 and I was mostly very confused throughout. I believe I've now found the optimal way to deploy it.

http://www.learnwithdaniel.com/2015/01/apache-puma-via-reverse-proxy/

This site saved my life. Forget Passenger and Capistrano and what not. This is the fastest way to go from nothing to deployed.

(Substitute some of the init new project stuff with git clone). Also, since in 3216 we use AWS, don't bother with the Amazon images... Just grab Ubuntu, since it's more familiar to most of us anyway.

But that's where it gets interesting. Seemingly this can be applied to any webserver - that is, our front end! Which is somehow magically served with gulp.js (don't ask me how, try asking my teammates!) Anyway we had something like an hour to deploy it before UI Reviews, so guess what - I replicated the Reverse Proxy over and tadaa! It works!

Anyway, the other cool thing I've been picking up is how to automate work with scripts. Here's some useful scripts to share:

First one: SSH script to connect to our server. Seriously why bother remembering the ip address of the server when you can just type ./ssh.sh ?

#!/bin/bash
ssh -i <path_to_file> ubuntu@<server_ip_address>

Next up - redeploy. We want to keep downtime to a minimum, so... How about a one liner like  ./redeploy.sh? Sidenote: This one is specifically for Rails, using a daemonized server and the reverse proxy pass. I've currently got one for the front end as well, but... Not 100% sure it works.

#!/bin/bash
cd <path_to_repo>
kill $(lsof -ti :<port_number_of_server>)
export GIT_MERGE_AUTOEDIT=no
source ~/.bashrc
git fetch
git merge <origin/deployment_branch>
bundle install
bundle exec rake db:migrate
bundle exec rails s -d

Reflections - Assignment 1, 2 and 3

I actually wrote this earlier in the week when I was sick, fed up and very pissed. I thought it encapsulated a lot of what most people will feel throughout the module, so instead of sanitizing the post... I decided that I shall let it go live!

Assignment 1

Thankfully over, after a lot of sleepless nights. It was a real pain towards the end and I realize now how much I hate doing UI/UX. Really a pain in Rails. Next up: To learn a front end framework I can throw on top of Rails to save my soul

Assignment 2

This one was rather chill - just the presentation and criticisms. Didn't manage to comment on as many posts as I wanted to - will explain later.

Assignment 3

We're honestly quite out of ideas and it's quite a pain trying to think of some. Group seems fine (cheers guys, if you're reading this). It's quite foreign territory to me and I hope this goes okay. Anyway we've chosen to do WishPool - more details to come!

Overall week Summary

If you haven't taken this module, are thinking about it, and somehow chance across this - here's the real cost price of this module -

1. Your health

2. Your sanity

3. Your relationships

I'm really pissed now cos my body can't keep up with all the shit that's blowing up atm. Not to mention there's still a FYP I need to do which I haven't done crap for. So. If you're not prepared to blow up everything else don't take the mod. Ran a nasty fever, headache, sore-throat and a completely messed up nose for the past 6 days.

Now if you're willing - Lessons learnt:

1. jQuery and VanillaJS will not survive doing frontend work. Really. Too much work to do simple cute stuff

2. Finally learnt about Facebook's JS SDK and signing in, passing the code to the server and exchanging that for a long-term token. Really interesting.

3. Also learnt about token-based authentication this week as I set up the RESTful API for Assignment 3. Wow, that's tough. Like either you use a library or you just cry setting the headers all the time. The headers change after every session - just wow.

How much does a UI attract readers?

It's a strange question that crossed my mind - while we go out to design pretty interfaces for our web apps, here I am on a crappy blogger template (with 0 comments on the critique!) It does make me wonder if I've been a little blind in not seeing this earlier...

But really, out of curiousity - do leave a comment to tell me what you think about this question! Does it carry the same level of importance as in a web app?

Review: Shopback

Criticizing the critic:

The presenters were extremely clear about what they set out to do, and the agenda of their presentation was clear:

The UI of ShopBack is crap.

I can't agree more. The whole dual language thing makes it not just look like a translation failure, but a cheap ripoff site where they sell you a whole bunch of fake goods (oops, sounds familiar).

They made great points about how the ads are a complete pain in the ass (sorry am I allowed to use language like that?) and how badly the T&Cs are listed. What's best is that they did also suggest improvements to it - and excellent ones at that, which should totally be given to the development team for implementation.

What really caught my attention about their presentation was how they raised the problem of having to advertise their other partners while at the same time trying to minimize the UI/UX problems by using the chrome extension. This is a great example of a real-world problem and other factors which hamper development, and that's a really great lesson to learn from them.

My gripe with this presentation is how they spent a too much time on the start showing off statistics that are totally unimpressive. Really, 7000 order, 10000 users? That's really on the lame side - why bother putting it in bold and giving it all that time? Negative example lah... I think they should have played to the strong points of ShopBack instead (though there really aren't that many). Lesson: Choose the numbers you present properly. This was 2 slides (10% of the entire presentation) of useless stuff that doesn't convince anyone to care about ShopBack at all

My thoughts on ShopBack:

Interesting idea, that cannot stand alone. It needs to be better integrated with its' partners. Currently the flow is

ShopBack -> Partner -> ShopBack (The last page you visit must be ShopBack)

Instead, to make this successful, it needs to be

Partner -> ShopBack -> Partner

Let's face it, ShopBack is tiny compared to its' partners. Their current model only works if they are larger than their partners, thus making them a good landing page. (Which, as seen from the stats in the presentation, isn't true).

Week 3 - So somehow my stupidity has arrived here

So I realized I never explained NUSocial - hence the title.

NUSocial is meant to be the one-stop group management system for NUS - primarily designed for halls and CCAs, but the more I look at the functionality the more I think it can be even used for faculties, departments, even modules. Coming from Science, everyday my inbox is spammed by OCA, OSA, OCS, IT, Rubiah (whoever this really is), EUC, Math Department... You name it lah. Seriously? Who doesn't delete all this indiscriminately? I only want to receive the CFRG ones (cos they might land me jobs!)

Now imagine all this put into a feed, together with your CCA, hall, (whatever funny subscriptions you can think of) groups, combined with event-signup features. No more flooding emails, no more messages getting too long in Whatsapp, no more missing posts in FB drowned in the sheer volume of Pokemon Go screenshots.

Imagine always being able to find the information you want, and fast

Imagine managing your groups and events with peace of mind knowing people don't have to come back to bug you for info (provided you set everything up nicely lah)

We thought it'd be a good idea. Personally I think it's mildly useful, but will take a lot of onboarding to work. I guess a lot of my apprehension comes from NUS's refusal to use student projects - really, there are so many GREAT CS3216 projects out there, but look at what NUS has been doing? They're recommending using the CORS module scheduler. Like seriously guys, NUSMods exists. (I hope someone from NUS reads this and realizes what idiots they are (Am I allowed to write this?))

Basically the point is that building projects for NUS might be really cool and really useful - but end of the day the school won't support it, and we'll always have to fight to grab students ourselves. Which is kinda lame, esp. if ideas are good. In our context specifically, I think my inbox will still be flooded, even if NUSocial is an instant success with students.

I do however still see that we might possibly have a good student user-base. What's more, with the functionality we've put in, I think it's got potential to expand beyond these simple use-cases to serve modules and project groups, etc. (okay a project group probably doesn't need such a large feature set) - and I suddenly have an idea to add a file upload system. Whoops! Time to run it through the team

Anyway, reflections for this week:

Assignment 1:

Spent the week not doing so much - some review, some prep for the mid-assignment submission, and a day of trying to make our landing page look acceptable >< Unfortunately that's competing wtih all the other groups - who have really nice landing pages. Damn. We're obviously not a very artistic group, and I've been trying to look up web design principles. Haven't found any particularly good resources though.

Assignment 2:

Critiquing FastJobs - I looked mostly at the web app, various members of my team looked at Android and iOS. We're going to focus on the mobile versions in the end after looking through. I must say that the web app is terrible. Plenty of bugs, some links to functionality that doesn't work, inconsistencies and so on. It does serve a nice niche of part-time jobs but beyond that honestly I don't see what's the big deal about it. We had a really interesting discussion on Monday about what's good, bad and ugly, as well as what we can do on top of it. (But I'll leave that for the presentation right? So you won't see it here)

Week 2 - NUSocial is almost ready!

Quite glad this week - we've managed to churn out (majority) of the functionality for NUSocial. It's been quite the cool week, with the accomplishment of the week clearly being the replacement for javascript alerts (which really suck, seriously - totally remind me of spam popups). Kind of enjoy doing this kinda small little cute stuff, yet at the same time I really hate doing design work cos I'm really pretty color blind.

Hint: Fire up the console and try alert2('hello world!') (Idk why it bugs up sometimes here on blogger, but if that happens just refresh the page ><)

Week 1 - So It Begins

So,  CS3216, painful it is.

Really feels like I'm only doing one mod.

Choose to do assignment 1 in rails, something familiar, but still the enormity and the gargantuanity of it horrifies me. It's crazy yet fun, and insanely challenging. NUSocial is a rather interesting idea, yet at the same time I feel the fear that it will flop

Suppose that's the norm.

A Journey Begins

Hello!

"The reward for good work is more work"

That's a quote that's stuck with me ever since I entered NUS and took my first ever CS module in my first semester - where I figured out that the more assignments I completed, the more assignments there would be. Ironically the same tutor who gave out those assignments is also a part of the teaching staff in this course ><

But that's where the real fun in doing development is, isn't it? The more we do, the more there is to do. One module builds on top of another, as layers of abstraction grow.

So why CS3216? Because I want to do things that are meaningful. Sure, algorithms are fun and challenging, but when has solving a shortest path problem or some really cool dynamic programming trick ever made an immediate impact? (Not discounting these, cos a lot of stuff is built on these algorithms. Just that you don't quite see the impact of it at face value). I want to do stuff that helps people, that changes the mundane into the unnecessary.

What I hope to learn is the skills necessary to identify real needs in communities around me, and to address them in ways that are relevant and, what's more, intuitive. There's also, of course, the problem of rigorous testing and maintenance, which should prove a delightful challenge.

Oh and of course, I signed up expecting to have to work. A lot. That's the norm, right?