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 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 37 – APIs and Going Back to JS

We spent the morning writing more integration tests and I managed to get some practice using factory girl. Weird name, I know, but factory girl is a ruby gem (like an add on or library) which helps automate the process of creating database records for your tests. I haven’t written integration tests for a full scale web app project yet but I can already see how tools like capybara and factory girl can make the whole experience of test driven development (TDD) less painful in the short term so that you stick with it long enough to reap the dividends in the future (more maintainable and cleaner code).

The afternoon was spent looking at APIs which meant going back to JavaScript. It turned out that I already knew a bit about APIs since last week’s project involved creating json feeds for our ajax heavy site.
By the mid afternoon, I’d implemented my own version of the example that Alex used during the teaching session – a site which listed the titles of issues in a github repo.

The look at APIs reminded me that I still have a lot of foundation work to put in on JavaScript and so I’m now part way through Modern JavaScript by Larry Ullman. It’s pretty good so far, although it does mention a few methods which I can’t ever see myself using, so definitely feel free to skim those parts of the book. The main plus of the book are the examples it works through.

Gem of the day: There is no substitute for practice. Work through exercises until they become second nature and when you encounter a similar problem in real life, it’ll be a breeze

Tomorrow’s the last pre-rails day and we’re going to spend it tying up lose ends so I’d better get started drawing up a list of questions to ask!

Day 36 – Capybara. TMI

Ever have one of those days when your brain just can’t take on any new information? We revisited Capybara today and the concept of integration, or acceptance, tests. It wasn’t completely new information since we had a brief session on it last week but this was the domino that toppled all the others today!

Significant parts of the day were spent staring at a terminal trying to string a couple of lines of code today. It kind of felt like trying to cycle while thinking too much about it. By Wednesday this week, I’m pretty confident I’ll have it nailed (ish), I just need to practice and get those neural pathways going. Doing something for the first time is always difficult, more so if you’ve spent the last few weeks with familiar material. What is they say about no pain no gain?

Anyway, Capybara is a framework for writing integration tests. Whereas unit tests are about looking at a class in isolation, integration tests are about the behaviour of your web app as a whole and ensuring its constituent parts are functioning properly together. Capybara let’s you fill in forms as part of your test, or look at specific elements of HTML for expected content, and even check that submitting a sign up form creates a new user record. It’s some pretty powerful stuff.
I know test driven development is good for me but it definitely slows down development initially. I just have to remember that the time spent testing my app now as I code will yield dividends in the form of more efficient, comprehensive and maintainable code.

We start Rails at the end of this week. I’m looking forward to finally getting stuck into the dominant ruby web framework (used by Twitter and Groupon in fact), I just hope my brain can cope with the new information. Brain, don’t fail me now!

Day 25

Finally got to work on something other than battleships today! I’m really glad to leave battleships behind simply because it’s been hard to re-work any code due to the way in which the app was designed (badly if anyone’s asking but then, that’s part of the learning experience). The app was functional and I implemented a board which you could click on to select your target. The app also showed you which squares on both boards had been hit/missed etc

After the break from testing last week, we started the day off with a quick announcement that Fridays were once again Test Fridays. We had to design a web app of a simple game, or at least simpler than battleships.  We had time pressure though since we only got started at around 11a.m. and had to be done at 6pm (the deadline got extended to midnight).

It was a really good opportunity to practice the lessons I’ve learned from Battleships and also to recap the Ruby and Rspec stuff which we’ve learned over the last few weeks.

It became pretty clear early on that I’d forgotten some of the rspec material but that’s what the tests are for, right?

The hardest part of the rest was definitely the modelling – figuring out which classes should do what. It all worked out in the end though and I had a fully functional app (albeit an ugly one) by the 6pm deadline.

Or so I thought.

I’d completely forgotten about the edge case of the game where there would be no winner and it would end in a draw. I went back to the code, wrote the tests and somehow couldn’t make them pass.

Gem of the day: When using a double in rspec and specifying what boolean value it should return, use and_return(false) and not the symbol :false. Rspec and ruby will evaluate the latter as true otherwise.

An hour of struggling with Rspec later, the app was done. I’m leaving the styling to be done on the weekend.

All in all, a really satisfying day. It’s been great to see the progress I’ve made over the last few weeks. To think, I’d never used Sinatra before this Monday and instead of taking two weeks to code a game app (battleships), it took me about 7 hours.

On another note, I really need to learn about CSS selectors and inheritance. There was a moment today when I thought that elements enclosed within an element with a class, inherited that class.

Today’s a two gem day – I learned a lot!

Gem #2 of the day: When using classes in your Sinatra app file, class variables cannot be accessed by the Views. Instead, assign the class variable to an instance variable which you place in the relevant route (but before the erb file is specified)