Another weekend, another hackathon – DubHacks 2014

Coding has well and truly become a part of my life! I spend my weekdays coding at Axiom Zen as an intern and my weekends either reading up on new tech/languages or heading out to hackathons. How much has changed in a year. I think I used to watch Netflix on the weekends…

It’s Sunday morning and I’ve just gotten back from another student hackathon, DubHacks, which was hosted over 24 hours at the University of Washington in Seattle. It was their first time hosting the event and while there were some growing pains (having dinner at the same time the hacking starts is never a good idea), it was great to see how the movement for student hackers is progressing.

The event was a lot less diverse than Hack the North a month or so ago since DubHacks was a lot smaller, maybe around 300 hackers, and there was only a little money for travel reimbursements. Luckily Seattle is a lot closer to Vancouver than Waterloo, so it was just a 4 hour bus ride. That might seem long by European standards but definitely not in North America!

Hackers Representing

I went down with a couple of other students from UBC, most of whom I didn’t know before but we had a good old time. I decided to work on a project that I’d been thinking about for a long time but never gotten around to – an app for conducting live polling of an audience. The idea is to have students in a lecture/class or attendees at a conference/presentation answer questions in real-time, thereby keeping them engaged and providing valuable feedback for the speaker to respond to, perhaps diving into an area of identified misunderstanding that needs to be clarified.

If you’re thinking that this would be a problem well solved by something like Node.js which is great for real-time apps, you’d be right. Unfortunately, I’ve been a bit behind on the learning Node front since I’ve moved onto working on front-end dev at work, which meant picking up Angular over the last few weekends. But c’est la vie. I used Rails and jQuery instead since the hackathon was a short one and I wanted to be able to code as much as possible, rather than reading docs (inevitable as it is).

For the real-time functionality, I used Pusher which delivered the messages between server and client – a big thank you to them for providing me with a free upgraded account for the weekend! They made it super easy to integrate with my Rails server and JavaScript front-end.

One other thing to add is that I ended up flying solo for the event.

I decided to work on my own at DubHacks because I thought it’d be a kind of fun endurance challenge (I managed 33 hours without sleep!) to see how much I could build on my own – plus some of my friends couldn’t make the event. I figured it would be a nice change from collaborative coding which while vital to getting things done in the real world, necessarily involves not coding a lot of the time. Don’t get me wrong, working in a team is essential but there’s something fun about being the decision maker and executor. It can be fun to live and die by your own sword – or to put it another way, I just wanted to see what I was made off. Skills I need to continue working on would become more glaringly obvious and help me figure out what to concentrate on the next few months.

For the most part, I pulled it off. My main weakness in web development continues to be design and that’s ok – I’m an engineer after all – on the coding front, my front-end skills are still not at the same level as my back-end but it was nice to see that things are coming along. The app I made doesn’t look half bad at all. The downside was that spending so much time on the front-end and design meant a few bugs in the finally demo-ed app. Super frustrating since I fixed all of them this afternoon (after the hackathon) in an hour, but when you’re sleep-deprived it is hard to think of manual test cases and spot the stupid bugs. I also need to learn more about database design, I think that’s probably something that is hard to from a book and is mostly learned from experience in the real-world. I’m definitely going to ask my co-workers at Axiom Zen how they would have designed the database for my app and see what design decisions I can improve on in the future.

I didn’t win a prize at this event which was disappointing (who doesn’t like being competitive!) but not surprising now that I think about it. My app had small but obvious bugs that took away from the end-product, and wasn’t novel enough to warrant attention amongst the hardware hacks and distributed prime number finders at the event 🙂

Winners of hackathons, I’ve realized, tend to build projects that are technically novel – that would impress other hackers – and while they need to solve a problem, it is not essential to for the problem to be a particularly painful one or for the solution to be readily adoptable. It’s a hackathon not a product-thon if that makes sense. It has to have some value but building cool stuff for its own sake deserves a lot of respect as well. Some of the winners used a Myo, Google Glass and Oculus to control a robot and be able to see the visuals via Skype. Pretty cool.

One other thing I’ve been reminded of at DubHacks is that there is no need to build the core tech itself, at least not at student hackathons. For example, the grand prize winning team didn’t need to build or understand the complexities of the speed reading api that they exported to multiple clients/platforms, it was enough that they got it to work and could put something in the judges’ hands and say, hey this is some cool stuff. Winning Hack the North a month ago, was like that too. We solved a problem using a complex API that neither of us understood (hey, it’s an NP complete problem!) but still created something that was cool.

Good thing the Space Needle is tall and near the bus stop – there wouldn’t have been any sightseeing otherwise!

So what next?

Well, after building a prototype of my live polling application at DubHacks, I still think the problem it tries to solve exists and is one that needs a good/better solution, and so I’m planning to continue developing my live polling app over the next few weeks. It will need to be a complete re-write since the Rails app I made is some of the least DRY (so wet?) code I’ve written in a long time – the number of random script tags and !important CSS tags would be embarrassing in the real world, but hey it’s a hackathon app!

So yeah, definitely going to use it as an excuse, if I needed one, to learn Node and to come up with something more robust. It’s annoying to have to use a technology stack you know is ill-suited to the problem because you don’t quite yet know the alternative. Inspiration to continue learning then. Always keep on learning.

Oh, and here’s the app I built (plus an hour of post-hackathon tidying up of the most obvious styling issues and bugs).

LivePoll – I’m definitely getting better at this design thing

Day 60 – Part 2 – End of the road.

Presentations are all over and I’ve officially completed the course at Makers Academy! It’s been both a long and short 12 weeks and there have been plenty of ups and downs. Today, more so than ever.

I started the day off pretty late since I’d been working on the app till just before Makers closed last night. My partner and I thought we were in a pretty good place with our app and that most of the feature related work had been completed. Unsurprisingly, and indeed, as always, a few issues cropped up when we pushed to Heroku. That meant that we ended up making bug fixes right up until the deadline, only breaking for a few rehearsal presentations.

Gem of the day: Although the ideal would have been to have memorised my presentation or at least the outline of it in time for the rehearsals, I would say straight out that having a script definitely helped me get things clearer in my mind. If you rehearse the same presentation 5 different times in 5 different ways, it isn’t really a rehearsal. You’re just practising “winging it” and that is not the same as a proper rehearsal! Also, having a script/outline doesn’t mean you have to read from it during the presentation. Think of it as a safety net or a guide to help you on your way.

Anyway, the main bug fix we had to do was with the  websockets protocol and the fact that we were using the websockets gem for local development and Pusher in the production environment (i.e. on Heroku). It seems like each returned a different format of objects, so that whilst we needed to parse the string returned from the websockets gem into JSON, we didn’t have to do the same with the object returned from Pusher. Thanks to Enrique, who spotted the error, that got fixed fairly quickly.

The graduation event itself was not as hyped/formal as I thought it would be and the audience was mostly made up of prospective students and a couple of hiring partners/recruiters. The presentations themselves went really well and I felt that the other guys in my cohort really delivered when they presented what the apps they had been working on the last two weeks. There was a classifieds site, invoice app, and a to-do list/data visualisation app. All of them looked really good and were presented solidly. Nice to see after all the effort that everyone has put in!

My partner and I presented last, and overall, I thought that the presentation went well. There were a few points where I felt that we could have related the features of the site more strongly with the technologies we used, but the proof was really in the pudding and the site delivered in terms of dynamic and visual updates.

We finished off with some questions, and then Alex presented each of us with a book from Makers Academy, which is sort of a graduation tradition now; Makers tries to give each graduate a book which will help them in their developer career.

It was mostly just mingling, drinking, eating and saying goodbye after that. I definitely wish there was time for a debrief day to go through the things we encountered during the final project (and the course) that we need to get cleared up, but c’est la vie. There’s always going to be something you don’t understand, whether you know it or not.

There were also a couple of scholarships given out at the end. One of them was for the best blog and I won that, thanks in no small part to the lack of competition! I think I was the only one from my cohort to write a blog of my Makers Academy journey! There was also a random draw scholarship and I was gutted not to have won that since the odds were in my favour – lots of entries made etc. It was one of those things that you kind of saw coming. You know that feeling when you think something bad is going to happen and then it does? Well, I guess that’s randomness and luck for you. I would not make a good gambler.

It’s kind of silly to be feeling down about all of that since it really is all a numbers game in the end, but missing out on that latter scholarship really took the wind out of my sails on what should have been a really satisfying day. I guess the experience has reminded me that arbitrariness is never a good thing and random draws for scholarships or prizes or anything really, aren’t great marketing tools. Note to self.

Ok, enough doom and gloom. Over the last 12 weeks, I’ve developed and co-developed a number of apps which I couldn’t have/wouldn’t have known to dream about. That in itself is pretty amazing.

Where to from here? You tell me. Do you want me to continue blogging so that you can see how things turn out post-Makers Academy? What would it be helpful for me to blog about? Is there anything I’ve missed.

Let me know using the contact form and/or by filling in this poll.

Day 59 – Finishing touches and overhauls

Did you catch my mistake yesterday? Somehow I got mixed up with the day count! I’ve now changed the title of yesterday’s post and without further ado, here’s the post for Day 59 actual!

I am exhausted! With all the rush to get features implemented in time for tomorrow’s graduation/hiring day, we’ve written code which isn’t as dry as it should be, and then paid for it when making changes. Try finding the relevant event listener to change when the function is duplicated in your code! Lots of alerts and console logging occurred as a result.

That’s not to say that it was all bug fixes and unicorns (ok bug fixes aren’t really that fun). We had to do a major overhaul of the way users follow/unfollow each other. That involved creating a relationships model and rewriting the relevant methods. It took some time but doing things the right way, helped massively today. In taking the decision to actually overhaul our code, we realised we had come to a point where working with sub-par follow/unfollow code and the relevant associations and models, was going to be more of a hassle than just re-doing things. A little bit of pain to move forward. I just wish we had done, and knew to do, things the right way in the first place! At the very least, this project has taught me I need to re-visit self-referential associations (“followed users” and “user following” are the two key pieces of information needed for the relationship table, and they both refer to the same User table and model) in Rails and ActiveRecord soon.

Alex, our instructor, saw us flagging a bit(a lot) today and helped out with some of the debugging in the afternoon. JavaScript and its brackets, yeesh.

On one hand, I’m frustrated that our code base for this app is far from clean. It is not something I would be proud to show to another developer. Saying that, and without serving up excuses, I’ve got to put things in perspective. We’ve only been doing this for twelve weeks. In that time, I’ve gotten a working knowledge of HTML, CSS, JavaScript and jQuery, Ruby, Sinatra, Rails, Heroku deployment, storage on Amazon S3, AJAX, websockets, and a whole host of other ruby gems. I’ve gotten the foundation these last few weeks, now I need to cut my teeth and refine my technique by putting things into real world practice. And by practice, I mean real, live projects!

We also had a presentation run through this evening and it was stressful to say the least. What with all the bug fixes, we didn’t have any time to do any real presentation prep. I know Steve Jobs said something like you should put in an hour for every minute of a product demo, but there just aren’t enough hours in the day.

I left pretty late tonight since I stayed to fix a couple more javascript bugs in our follow/unfollow feature which uses ajax to dynamically update a user’s feed so that only the posts made by people the user is following are displayed.

Tomorrow is the end of the road as far as Makers Academy is concerned. There still styling, database seeding and presentation prep to do, but I’m confident things will work out fine.

Gem of the day: When presenting, look at the top of people’s heads rather than directly in their eyes. The former helps you engage an audience, while the former can be confrontation so and intimidating (for all parties concerned).

Day 58 – TDD and MVPs

As we put (what really should be but aren’t) the finishing touches on our final projects, I’ve been thinking about the role of test driven development (TDD) in the development of minimum viable products(MVPs). Do you code without tests to get something out there ASAP, or do you write tests, knowing that you’ll benefit in the long run? A fully tested MVP can be a great foundation for a production ready app but there’s not going to be a production app if you can’t get it finished in time for the pitch.

Before we get going, just a quick recap if you’re late to the show. TDD basically says that every piece of code you write should have an accompanying test. In fact, you shouldn’t write code without first writing a failing test. It is the failing test which provides justification for the code that you write. The process is

I) Write failing test
ii) Write code to make test pass
iii) Refactor code
iv) Repeat.

MVPs on the other hand refer to the business end of web application development and stand for minimum viable products. The idea is to just get something out there. It doesn’t have to be perfect, just the minimum needed to prove that your business idea and concept has some real substance.

Given the strict timelines we’ve been working to during this final project, we’ve had to move away from TDD to just work on getting our MVP ready for Friday’s graduation. While that does speed up the coding process at the very beginning, a lack of tests has meant a lack of focus as we write code. The consequence has been more features implemented at the expense of easier to modify/maintain code. As we seek to pivot and reimplement features, we’re starting to suffer for our lack of tests.

Gem of the day: It seems to me that straight up coding without TDD, while quick at first, soon has diminishing returns. In the same way, TDD is slow going at first but soon pays dividends.

So how do TDD and MVPs relate? Well, I think it depends on the scale and complexity of your MVP and it’s purpose. If you’re coding a fairly static website then you can probably do without TDD. Pitching for Series A funding? Or coding a rival to PayPal? Then you’re probably going to want comprehensive tests! In fact, if a security based app developer came to me for funding(if I had the money, of course) with an untested MVP, things are probably not going to go too well for them. Untested apps greatly increase the chances of a failure or error during your pitch. Recoverable if its only a school project, catastrophic if it’s for funding.

From what you can probably surmise, today involved lots of manual bug identification and fixes. It’s taken a while but at least we had more to talk about during our daily presentation run through this evening. At the end of the day, I think we made the right decision to leave TDD and work towards a more fully implemented MVP. Sure testing is important, but at least we’ve had the opportunity to demonstrate our TDD proficiency in previous apps (penny bid auction, classifieds) and at the end of the day, I’d rather get something out there which wows from a user perspective. You did TDD of a two page app? Uhh, good for you.

On a less serious note, did I mention that our cohort went out to The Rotary on City Road to get lunch together? The food was great and there was a crazy hot sauce which contained way too many habaneros. Good times. I wonder where we’ll all be a week, a month, a year from now.

Day 57 – Final push

Today was getting pretty long, or at least I thought so at 10am(!), until I got a couple of cups of coffee. That woke me right up and we got down to work on our final project after a bit of a recap of the state of the app and our to do list on GitHub.

Slowly but surely, the to do list is getting shorter and most of the features got done during the holiday or today. The menu sidebar for the app is now in place and I spent the morning fixing up the hide/show animation and created a button for that. We also got the comments overlay over each post working. Basically, when you over a post, display of the comments on that post pops up. The comments on the post are updated dynamically and we had to deal with the state of the comment display for each post on page load. That required creating a new json route and some JavaScript. Don’t tell anyone but I think I’m starting to enjoy JavaScript. OK, maybe not JavaScript on its own, only when it’s paired up with jQuery! The jQuery library makes things so much easier!

In preparation for graduation on Friday, we had a first runthrough our presentation. There’s still a lot of work to do but it’s not looking in bad shape. The main thing I picked up today was

Gem of the day: When demoing a product, mention the technologies used as you do the walkthrough of the app. Don’t leave them all to the end. It won’t be as logically relative/relevant otherwise.

We finished off the day with some styling to get the comments on each post to fit into the overlay space allocated to it.  I had to leave a little bit early so my partner stayed on to finish it up. Just one of the reasons it’s been nice to work in a pair!

Only two full working days left. Uh oh.

Day 55 – A reflection on coding

Coding is quite possibly the single most satisfying and frustrating thing which I have ever done.

Whether it’s the task of finding a missing curly brace or a finally deploying a production ready version of an app to Heroku, coding definitely has a bunch of highs and lows. Not always in equal measure, although I’m sure the two are linked – you can’t have success without failure, right? Both in terms of defining what success is (getting something working after spending hours on it) and also in equipping yourself with the skills needed to accomplish a given task (when you learn something new and worthwhile, you can bet you’re going to make mistakes).

Our instructor was away today so we just ploughed on with our apps. My partner and I are in decent shape. We’ve gotten the majority of the ajax and websockets functionality implemented and started styling the site. Users can now be followed by clicking on a comment they’ve made and which appears on a site wide comment feed. Oh, and their posts will start appearing in your “newsfeed” immediately and without a page reload too. We took a break from paired programming today and I think it was just what was needed to mix things up a bit. As good as paired programming is(see yesterday’s post), sometimes you just need to get your hands dirty and take responsibility for implementing a particular feature. It’s nice to be freed up and not have to explain things as you do them. You can still talk things through if you need to but equally, you’re free to just experiment and see what sticks/works. It’s probably the experimenting and seeing what works which provides the most learning experiences. Combined with learning from other people’s approach to a coding task and you’ve got a great learning experience combo.

I want to say something about a new technology I learned today but the truth is, today I just learned a bit more about what I was already aware of and which I needed to practice. And I’m glad that that’s the case. You know what they sat about being a jack of all trades but being a master of none.

We also had a talk from Zoe of Software who walked us through her journey from software developer to managing director. It was interesting to hear about the practicalities of the consultancy/contract industry and also about some of the issues Zoe has to contend with as MD (e.g. IPR and proprietary software development – do you develop your own things or just work for others?).

Monday’s a bank holiday but I’ll hopefully get some time to make a post in between family time and coding!

Day 54 – Slowly and not so steadily

I went home early today. I’m starting to feel pretty exhausted. Whether that’s to do with the coding or post graduation plans, I’m not sure. It’s probably some combination of the two.

I’ve always known that my learning style requires quite a lot of time to absorb information and just let it sink in. The sinking in time debt is starting to catch up with me. Saying that, I’m not too psyched at learning that Makers is closing for the bank holiday this Monday. Since they kept it open during a previous bank holiday for another cohort, I’m surprised to say the least. On the one hand, it’ll be a nice break and I originally only signed up for 10 weeks before they extended it to 12 so I’m getting two free, but on the other hand, it seems a bit of a let down. I have definitely learned the importance of maintaining habits. There’s a lot of power in coming in every weekday at the same time for x hours to learn how to code. Anyway, a break might be for the best.

Today’s teaching session covered advanced ActiveRecord. We talked about things like has_many through relationships and scoping.

Gem of the day: Scoping is similar to creating class methods for retrieving records in ActiveRecord. However, it has the benefit of easy chaining ; something not easily done with regular class method definitions.

Today we worked on our app to ensure that newly created posts were added dynamically with AJAX to a user’s main page. In addition, we started looking at self referential tables. Apart from copying a bit of Hartl’s tutorial here and there, I have a lot to learn. I guess I know what I’m reading up on come bank holiday Monday!

Day 53 – Paired Programming

OK, I admit I was sceptical about the concept of paired programming at the beginning of Makers. When you’re first starting out learning to code, you and your partner are probably pretty clueless and it’ll be hard to get the balance right between give and take. I mean, I’m probably going to think I’m right all the time if my partner and I have only been programming for a week.

Doing paired programming with some experience under your belt though is a different kettle of fish. After 5 or 6 weeks of learning to code full time, you and your partner probably have an idea of what you’re each good at – if my partner says something about CSS, I’m inclined to agree. And even though you’ll have gaps in your knowledge, you’ll probably at least know where to start looking (or what to start googling rather) and between the two of you, will be able to figure out most things (especially spotting typos).

It’s probably a good setup to switch “drivers” every task or so or even every hour. I’ll admit that on a hot day like this though, I’m more than happy to let someone else drive and that’s the issue that driving times is meant to solve!

We mostly got on with implementing a live axtivirty feed for our site. Every time a user makes a post or comments on a post, the activity is updated dynamically through ajax for all users of the site.

We had two teaching sessions to break things up. The first session was on routes and we went through things like nested resources and collection and member routes.

The second session covered an array of rails related issues which we’d each asked questions about. We covered things like rake tasks and implementing pagination.

Gem of the day: You can overwrite methods generated by Rails for your models. For example, rather than using before save, you can go to the relevant model file and define a method called save, add the relevant code and then write super (to execute the rest of the Rails written code).

Time is starting to tick down towards graduation but the app seems to be getting along decently. I hope I feel the same way come next Monday!

Day 52 – A bit burned out

This week has been the second time during the course where I’ve lost my motivation to a greater or lesser degree. I’m still managing to get the features that need to be implemented implemented but I’m definitely feeling a lot of resistance.

Where did the weekend go, huh?

I did more work on the various models for our social network app. The main thing I’ve learnt this week is the power of database validations.

Gem of the day: For extra integrity, and especially when you’re modifying records directly in your database, add validations at the database level as well as at the model (rails) level.

The main use case for database level validations is when your model level validations have been implemented incorrectly. I guess on one hand, you’re essentially duplicating work (writing the same validations but in two different ways) but after Monday’s issue with duplicate records, better safe than sorry. I’m sure there are other use cases I’m not thinking of anyway.

Implementing database level validations such as for presence(i.e. the column is filled in) is pretty straightforward and all you have to do is add null: true to the relevant add_column or change_column in your migration file.

How am I going to get my mojo back? I’m not sure just yet but more sleep is definitely a good place to start!

Day 51 – The Beginning of the End

Where’s the time gone, then? Only another 9 (Makers Academy) days until graduation. We started on our final projects today and we’re all doing pretty different thing – each app emphasising different technologies.

Our app is a cross between a news aggregator and a social network (more twitter and instagram, less Facebook) so it’s definitely complex enough to keep us occupied right until the deadline. The idea is to get a more polished app than our penny bid auction to demo and present to hiring partners and future students. I’m not really too worried about the presentation elements. My thoughts right now are elsewhere like post graduation plans and well, actually building the final project.

We wanted to allow users to sign up with usernames and passwords, with emails being optional (necessary for a password reset though) so I had to struggle with that today. Turns out the issues I was having in getting Devise, the authentication gem we’re using, to work were due to strong parameters.

Gem of the day: Adding or removing fields to the authentication mechanism in devise will inevitably require dealing with strong parameters. Fail to do that and your data won’t be saved.

Strong parameters is a security measure in Rails and ensures that only specified parameters passed through a form can be saved. It prevents people from submitting random field name/value pairs and writing data, e.g. writing true into the admin column in your users table in your database. Devise doesn’t currently let you add additional strong parameters to the defaults – you have to set them all again if you want to change anything – but that’s going to change with the next version of devise. Alex, our instructor, submitted a pull request to get that changed and which was accepted. He was definitely the eight person to get help from today, then! Pretty cool.

The August cohort started today as well and it’s big! There are 20 (21?) students. That’s meant a reorganisation of desks and more tables and monitors. All of that was done last week and everything was all set when they got in this morning. I’ll admit I haven’t really gotten to know them yet since I’ve been preoccupied with the final project but tomorrow works. Noise levels have definitely quadrupled though. I think some guys were talking about counterstrike (the videogame) for at least an hour…

Oh, and we presented our penny bid auction apps today as well. Unfortunately, since our cohort was split into two and  each group worked on similar clones, there wasn’t much left to present/say for the second group (which I was in)! Still managed to mess up though.

Note to self: Before a presentation, drop, create and reseed the database. If you make changes after that, the safe thing to do is repeat that process. Or else you might end up with two identical users (which you added before fixing uniqueness validation) and cripple your app’s functionality.