Day 38 – Recap

So I’m more than two thirds through my time at Makers Academy and today was our last pre-Rails day. We got to raise whatever questions we had on the previous weeks’ material during a group discussion/teaching session and we covered things like the security of JSON feeds and even got a very quick introduction to CoffeeScript.

The syntax of JavaScript is not the most efficient and so CoffeeScript is a compiled language which seeks to add some syntactical sugar (it makes it easier to code in basically – think less brackets and semi colons). In practice, you’ll write some code in CoffeeScript and then run it through a compiler which outputs a JavaScript version of your CoffeeScript.

There’s quite a lot of debate on the usefulness of CoffeeScript since it doesn’t allow you to access all the features of JavaScript. For example, you can’t declare the scope of variables with the same precision as in JavaScript. Nevertheless, it is syntactically a lot more attractive than JavaScript.

Personally, I’m not going to put much effort into learning CoffeeScript until I get comfortable with JavaScript. When that does happen, I’ll either think of CoffeeScript as a lifesaver or as unnecessary. Here’s an interesting article on Net Tuts about whether you should learn CoffeeScript. They interview a few developers including the creator of the language!

The cohort ahead of us are graduating this Friday so I’m definitely looking forward to seeing their final project and also seeing which recruiters and companies attend the graduation event. What typically happens is a brief talk about Makers Academy, project presentations, a short Q&A, and then some drinks and snacks. Pretty informal. If you’re thinking of attending the course or want to find out more about it in general, then I’d definitely check it out. It’s this Friday, the  2nd August 2013. Event details are here

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 35 – Pareto and Software Presentations

Pareto had  when he came up with the 80/20 (eighty twenty) rule. The Pareto rule when applied to web development basically says that 80% of the final product takes only 20% of the time. It’s the last 20% of a project when you’re refining your code and preparing it for the real world which takes up the majority of your time and money. Ain’t that the truth.

I definitely discovered today how much time the “bringing everything together” part of web development takes. There were issues with merge conflicts on git (a version control system which my partner and I used on this project) and then difficulties getting our image upload feature to work with Amazon S3 (a file storage service) and Heroku. And that’s not even mentioning the broken links and user interfaces that needed to be fixed (or created in some cases!).

In the end, we made the 2pm deadline and gave an informal presentation of our project. Our last minute fixes and tweaks to the project definitely didn’t leave enough time for a formal presentation plan which is was a shame, but I still discovered a few things which I’ll take onboard before my next software presentation.

1) Ensure the computer you’re using for the presentation is at waist height and that you’re not standing in the corner of the room

2) When presenting in a pair, ensure that you’re transitions from speaker to speaker is organised. Nothing worse than having to walk in front of a screen

3) Start high level with concept, then move onto a basic journey. Have a list of key features which you will demonstrate during the presentation.

4) Just as importantly, have a list of features which you won’t or can’t demonstrate during the presentation (and have a good reason why this is the case if you get asked)

All in all, it went decently. I definitely have things which I’d do differently if starting over again but we’ve come a long way this week. Saying that, if the site is ever going to be deployed as a live, real product, I’d probably start from scratch, using the things I’ve learned this week (e.g. if you’re using ajax, make sure you’ve thought through the user journey from page to page) to create a cleaner and more maintainable website. Making changes to the app at the moment is doable and completely possible, but it’s not as easy as I’d like it to be and I would probably be a bit embarrassed handing the code over to a seasoned professional. Live and learn. Live and learn. Baby steps.

Day 34 – with a little added style

Today we started styling our app and let me just say that it’s hard to work collaboratively on CSS when you don’t have any mockups.

Gem of the day: A brief outline of the design of a site with some typical user journeys (i.e. how a typical user might interact with the site) will enable efficient and focused back end development.

There were definitely moments today when we realised we hadn’t implemented features which we knew we’d need for a fully functional and usable app. I guess this is where agile methodology comes in – since it’s difficult to know what exactly our want the finished product to look like, it’s vital that you get something functional up and running asap so that you can iterate and improve. A little forethought at the outset of a project doesn’t hurt though.

Our main page displays a listing of the most recent add. Specifically, the title description and price of the ad. The problem we encountered was that we only wanted to display a snippet of the description of our ad and our json feed didn’t accommodate that. Would we have to add a new field to our database which stored a snippet of the description? Or should we create the snippets using JavaScript?

Turns out that there’s a way to use methods in DataMapper which can add a pseudo field to a json feed. Who knew? And that’s the value of having an experienced teacher on hand to point you in the right direction!

The number of frustrating, give-up-for-the-day-moments I’ve avoided because of the teachers/guides at Makers Academy has been pretty high and that’s a great thing!

There’s still more styling to be done tonight and I’m going to try and get the app on heroku so that’s it from me until after tomorrow’s project presentation to the intake ahead of us.

Day 33 – Things are starting to take shape

More work on our project today and I’ve realised that quite a real elements of web development can get repetitive. So far on the course, we’ve been doing all our web development using Sinatra which is pretty basic (in what it does for you, not in its capability) and requires you to understand what you’re doing and write nearly all of the associated code yourself.

It’s been a great tool for learning how everything works. I’ve experimented a bit with Ruby on Rails, another web development framework, which does a LOT of things for you, and I’m glad we’ve started with Sinatra. When I used rails, I knew nothing beyond the command I was copying from a tutorial. What it did or why was a mystery to me and I think leaning on a web dev framework too hard makes it difficult, even impossible, to innovate or use the framework for a novel application. And that’s simply because you have no idea how to do anything besides the all-in-one commands (e.g. rails generate).

Saying that, I’m definitely going to appreciate it when Rails does handle some of the repetitive tasks like creating forms, because it then frees you up to concentrate on other aspects of your app.

I still have a lot to learn about Sinatra (and everything in general) so I’m trying not to run before I can walk. One thing I’d love to cover more with Sinatra and JavaScript is open connections, i.e. maintaining a connection with the server, which is what you need to create a chat application and which is used by Facebook to update your news feed when one of your friends has made a new post.

Gem of the day: When using Git, the command “git stash” let’s you save the state of your working directory without requiring a commit, thus allowing you to check out other branches or commits without losing your “flow”. When you’re ready, just type “git stash apply” to load the working directory state which you saved.

Programming Wish List

Over the last few weeks, I’ve been checking out job ads to see what I’ve got to aim for in terms of technical skills to land a job with one of the tech giants (Facebook, Google, etc). And…there’s a lot to learn.

I’m not too discouraged (although maybe I should feel more overwhelmed!) because at the end of the day I went into Makers Academy as a way of taking the first step towards a career in software engineering. And once you’ve learned one programming language, you’ve not so much learned a bunch of syntax but a new way of thinking and approaching problems, and it’s this latter skill which is so transferrable when it comes to picking up new languages.

So to that end, I came up with a list of things I need/want to learn over the next year (I’m definitely not going to try and fit it into the next six weeks of the course even if I have picked up a lot of JavaScript in a week!).

In no particular order, the list is:

1) A low level language like C or Java
2) SQL
3) NoSQL
4) A mobile programming language like Objective C (for Apple’s iOS) or the Android Software Development Kit (based on Java)
5) More JavaScript and jQuery
6) Python and an associated framework like Django

Day 32 – Searching with DataMapper

I can’t believe it’s only the second day of our project. I feel like it’s been a week at least with all the work that has gone into it already. Quite a bit of the work is repetitive; there isn’t much to creating routes and adding forms for CRUD (creating, reading, updating, destroying/deleting) records. However, I could just be doing it wrong!. It’s still pretty cool to see what we’ve done so far though. Today, my partner and I started integrating the JavaScript and Sinatra we’d done.

You can now see a list of the ten most recent ads and when the user scrolls to the bottom, the next 10 ads are retrieved and rendered without the need to refresh/click anywhere. Ahh, the power of JavaScript.

One new thing which we looked at today was using DataMapper (our object relational mapper which turns database records into objects which ruby can use) for searches.

It turns out DataMapper isn’t great for searches and the best it can do is make an SQL “like” query. This searches the specified fields for matching data. A query which looks for the word “fly” in song titles might look like

Song.all(:title.like => “%fly%”)

The percentage sign prefix and suffix indicate that text can come before and after the word.

The main issue is how to sort the results of the query by relevance. I don’t think “like” is going to cut it and the issue is going to require more though. What happens if the search query is for a phrase? Should records which match just a word of the query be returned, and if so, how can we return results where the whole phrase occurs?

Search is difficult. And we haven’t even begun talking about indexing. Rather than making a full text search of your entire Song table every time someone makes a search – which is resource intensive or “expensive” – you want a way for multiple searches to make use of some common information, and index, which might contain the frequency of commonly searched phrases for each record.

Gem of the day: So I’m starting to realise that the getting something functional part of web dev isn’t hard. It’s the optimisation part which is the killer. There’s building things which are usable by a hundred people and then there’s building things which are usable by a hundred thousand people.

Maybe I should feel afraid that I don’t know anything about the latter but to be honest, working on scaling and optimisation is a good problem to have. It means lots of people are using something which you created!

Day 31 – Mid Course Project

As I was writing the title for this post, it hit me. I’m just about half way through the course at Makers Academy.

I don’t feel like the time has passed quickly at all, which is a good thing. It means that I’ve been engaged and that I’ve not just been idling while time passes me by. I can definitely say that I have way more knowledge than when I began the course and today, my cohort got started on building something of our very own!

Each pair came up with a couple of ideas for the week long project over the weekend and had a quick chat with Alex, our guide/teacher, to check that we’d gotten the difficulty for the project right.

We’re building something like a souped up version of Craigslist/Gumtree which uses ajax to allow infinite scrolling ads (a la the Facebook news feed). It’s definitely not going to be easy and today we worked on getting the tables and database set up. We then divided up some of the initial Sinatra routing and JavaScript work.

Gem of the day: Separate out your database definition and setup from your application file. If you’re using DataMapper, have auto_migrate! and auto_upgrade! as tasks in your Rakefile.

If none of that made sense to you, don’t worry about it. I learned all of that (and more) in the last six weeks and there’s no time like the present to get started learning to code.

If you’ve written a couple of programs and are new web dev, a good place to start is this series of Sinatra tutorials from nettuts.

Day 30 – Heroku

Wow. Today was…unproductive. I think a lack of sleep the night before and lots of new information contributed to the brain fog I was fighting through today.

We started the day off with a briefing about next week’s task. It’s to work in pairs on a project of our choice! Very exciting! I’m definitely keen to get something that looks good on my portfolio and next week will be the perfect chance.

Our homework this weekend is to come up with two potential ideas for projects we want to do and write a brief spec for each of them. I’ve got lots of ideas so it’s just a matter of picking the right one.

It needs to be simple enough that we can execute it well but complex enough for it to push us to learn new things at the same time and also so we can demonstrate how far we’ve come over the last few weeks.

Most of the morning was spent thinking about ideas for apps even though we were meant to be getting on with our tennis apps! I paid for it later in the afternoon – the post lunch lull is always a killer when you’re trying to write some JavaScript.

The day was also made pretty slow by the fact I decided to spend time really pinning down some concepts which iahdnt completely grasped – I have a checklist of things that I need to revisit which I add to during the week and it was nice to be able to cross some of them off.

When you’re learning something new it’s hard to know when to start and you can find yourself spending hours to figure something out which is either staring you in the face or which is pretty irrelevant. I went down a couple of those dead ends and alleyways today but rather than spending day or weeks, I had Alex, my cohort’s teacher, available to help me over the  bumps in the road and save me precious time.

Difficult lessons are great because you remember whatever you learned but eventually there comes a point of diminishing returns, especially if you can’t figure out then solution in the end. I definitely had that when I was learning how to program on my own.

The afternoon and evening (in my case) was spent trying to deploy my tennis app to Heroki, an online hosting provider.

My app had been configured with sqlite as the database, and that cause all sorts of problems whenbibtried to upload the app to Heroku. I had to use postgresql instead and that meant figuring out how to change my program so that would work. Hours later, and with the help of a couple of guys, I managed to get my app up and running. 

I can’t say with much confidence that I could repeat the feat of uploading an app to heroku today, but that’s what tomorrow’s for.