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 ><)