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?