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

Hack the North

This time last weekend, I was on the other side of Canada in Waterloo, ON, hacking away. Maybe it has something to do with the distance traveled to get there, but it seems like a long time ago. I almost feel like I’m moving backward taking this weekend easy (and by easy, I mean getting more than 6 hours of sleep total from Friday to Sunday).

Hack the North is Canada’s largest student hackathon and this year’s inaugural event held last weekend had about 1000 students attending from countries all across the world. Generous sponsorship meant flight tickets were significantly reimbursed 80%+ of the cost, and so students from as far away as Amsterdam and Shanghai were in attendance.

There wasn’t any specific theme to the event, other than to build something cool that worked – no one said as much but I surmise that’s the aim of every hackathon. Lots of cool hardware was available to work on as well, from Myos to Pebbles and Oculus Rifts.

Getting to the event from Vancouver was an event in itself, a crazy early start, then waiting at the airport on the other side for the shuttle to Waterloo, and then the trip on the shuttle itself. Who knew that the traffic in Toronto, where everyone flies into, would be so bad.

There was a little dinner left when we arrived and then we got to hear some amazing speakers open the event. We had Chamath Palihapitiya who was formerly in charge of growth at Facebook and is now in VC, starting the fund The Social+Capital Partnership  He spoke about startups and gave realistic advice about what life in tech is like. Chamath was extremely confident and charismatic, and it’s easy to say that he is one of the best orators I’ve ever heard. Check out his talk here (the video is still not up but I’ll update this post when it is!).

The hacking started at midnight and my friend Daniel and I got to work building a travel optimization app. It uses Yelp’s API to get a list of attractions in a city and Routific’s routing optimization API to provide an efficient route to visit the attractions in a single day if one exists. A quick way for tourists to determine how much they can get the most bang for their buck on their vacation.

There were chips and soda aplenty to keep people powered through the event, and there was even a small sleeping area. Unfortunately the sleeping area wasn’t really too well organized, it was brightly lit and far too small so I guess they didn’t expect many hackers to sleep much during the event. Daniel and I ended up finding chairs in a random room on the Waterloo Campus on Saturday morning for a couple of hours of sleep.

Saturday night/Sunday morning was probably the most interesting. People were definitely starting to feel the burn by that point and this was the scene at 4am

Every team got a chance to pitch their app in 100 seconds in front of a selected group of the judges, so there was definitely something to aim for during the hackathon. It’s all a bit of a blur but I spent most of Sunday morning trying to finalize the general flow and look of the app – I am definitely not a designer.

In terms of the stack, we built our app using Angular and had a Rails back-end for interfacing with the various APIs. Neither of us had used Angular before so that definitely made the hackathon interesting to say the least. We figured if you can’t try out some new tech in a hackathon, when else can you!

One of the things we found is that Angular, a JavaScript front end framework, is very domineering. You either use it completely for the front end, or prepare for some unexpected behavior if you try to mix in some regular JavaScript in there. We definitely ended up finding ourselves in the latter position, as we moved to get things working even if that meant doing things in less than the Angular way.

Another thing I learned this weekend was about OAuth, an authentication protocol which we used to communicate with the Yelp API. Since it uses tokens and secret keys, it wasn’t possible to have just a front end, we needed a back-end as well to prevent exposing our keys. This is different from something like the Google Maps API which we used as a map and for geocoding in our app (since Yelp doesn’t always return an attraction’s latitude and longitude) where client exposed keys are OK.

By the time hacking stopped at 10am, I’d been up for more than 24 hours, with little sleep before that period(!), so I managed to get a quick nap before we pitched in front of the judges.

Our app lacked the design polish of other teams, but the judges found our app pretty interesting, as did the engineers from Yelp who we pitched to separately (main prize vs API specific prizes basically). I thought we did decently for a team of two who were using a different stack than normal and it was great to find out later that Yelp had awarded us the prize for best app to use their API at the event!

We are getting 4 leap motions between the two of us. I’ll make a post once those arrive in the mail! Definitely interested to see what can be done with the hardware. Hardware hacks are not something I’ve really explored before.

But yeah, what an experience. Daniel and I work at the same company as coop software engineers, Axiom Zen, and it was great that we got the Friday off to travel to the hackathon and that we got so much support from them. They were pretty stoked that we managed to bring home a prize as well, using an API from a company they are helping accelerate. It’s great to work somewhere which gets as excited about things like hackathons as you are.

So what next? Work is super busy, there’s always lots to do but I’m enjoying it – more on that soon. I saw some interesting apps built in Node.js at the hackathon so that’s on the agenda this weekend! I’ll post if I build anything half decent 🙂

And if you’re wondering how you can get involved in hackathons, ChallengePost is a great website to start off with. They list hackathons going on around the world, both offline and online.

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 60 – Part 1

I’m on the tube right now, heading to Makers Academy. I’m an hour (and a bit) late and sleep deprived. The presentations start at 3pm or so and that’s only five and a half hours away. Today will be interesting at the very least!

The main thing on my mind right now is where did the time go?

I think we’ve done a good job in terms of incorporating the many technologies we’ve learnt these last 12 weeks. There are lessons I’ve learned during this final project which I’m definitely going to take on board. Like the fact that tested and non tested development both have their pros and cons, and there are definitely diminishing returns with the latter after just a short time, shorter still if your app is complex (which ours kind of is).

I was joking with the guys yesterday that we’re in better shape than Facebook was in their first iteration of their site. Newsfeeds never used to update dynamically. Whether that’s because of technical performance reasons, the fact websockets didn’t really exist 8 years ago, or because it would have led to less page views (which would have been less impressive from a monetisation view since that means less ads can be displayed), I’m still going to take this as a minor victory. Maybe victory is too strong a word. How about achievement?

Not long to go till graduation now. See you on the other side.

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!