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