Welcome to my blog about learning to code at Makers Academy. If you missed the last post, you can find it here. If you’re hungry for more, here’s the next.
Mentally, this week has been hard.
The days have been great. But in the evenings I’ve been zombie-ing around the house, forgetting where I’ve been putting things, leaving pots of boiling water, generally being a moron. Thursday I went for dinner at the awesome Gunpowder and then for a drink with a few friends. I got back around 9pm, exhausted, realising just how mentally tough it is coding 6 days a week, 8 hours a day.
For some reason I couldn’t sleep that night, and barely got a z the night after. I’m not sure if I’ve been working too hard or if it was just a one-off (two-off), but Friday was tough, almost painful by the end. I feel asleep on the tube home at 6pm and woke up just in time for my stop.
I think I’m really gonna have to be strict about resting in the evenings. Guess I just don’t have the mental resources to fall back on after so much intense work.
Oystercards
This week we were recreating TFL’s Oystercard system, endowing our cards with the abilities to tap-in, tap-out, be topped-up and all sorts of other fun stuff under the hood.
My pair partners were all great this week, and the program got built at a pretty good rate. By Wednesday I’d done ~80% of the challenges and was wondering how things could be going so swimmingly.
My bliss was short-lived. The challenges were designed to lead us astray, building all of the program’s functionality into one huge class before being told to tear it down. Wednesday and Thursday were brain-melting feats of class extraction, the process of teasing smaller classes out of larger ones.
Those two days were full of desperation. Minds were being lost. The March cohort grew weary, consumed with lassitude and ennui. I saw ghosts of files I knew were there but couldn’t quite require, disappearing before me like smoke through my fingers. One girl ate her shift key.
I exaggerate, although I did lose faith in the guidance of the provided walkthroughs. This was a positive thing. I felt that by the end of the week I was thinking much more independently and learning a lot by doing things my own way and questioning everything. I now have a better grasp of the Single Responsibility Principle (SRP; the notion that each class should only do one thing) and the importance of designing a project well, using diagrams from the start to map out objects and messages. Everything comes out of a good design, and by not paying attention to it you’ll pay later on.
Above is the diagram of my Oystercard program (following many iterations). Each circle represents an object (which is an instance of a class, just as you are an instance of a human), with the arrows representing the messages sent between those objects. Roi tells us to think of our program as a petri dish of dumb organisms floating around. Before I’d thought of them as wizards doing seemingly impossible things without any visible explanation.
Miraculously, both my parter and I had finished the challenges by Friday, and we got to spend the last morning of the week refactoring our code with Roi and learning how to get our program to lookup zones for tube stations using CSV files.
It was fun jumping into something new and a great buzz when we finally got it to work. After some googling and digging around Stack Overflow we found a Ruby gem called smarter_csv which made the parsing process easier (def: getting data in a nicely formatted way). By the afternoon I was pretty happy with the way my Oystercard program was looking.
Other programming bits
This week I’ve been getting more familiar with PRY and made my first step towards becoming one of those developers who use VIM.
PRY is a REPL (read-evaluate-print loop), which in english means that it will take bits of code, evaluate them, and return the result straight away. This makes it a great resource for playing around with code and batting around ideas without the hassle of modifying a file in your text editor, saving it, running it in the command line etc.
I’m starting to realise that PRY is an invaluable tool for a developer. And if I’m gonna be using it a lot, I need a great prompt.
So I had lunch at my desk on Monday and changed my PRY prompt to a whale emoji (couldn’t find a Tapir — why that doesn’t exist is beyond me but whatever).
If you’d like to be as badass as me, create a .pryrc file in your home directory. Open it in a text editor and type in the following (with your prompt of choice in place of the 3 colons).
Pry.config.prompt = [proc { "::: " },
proc { " | " }]Thanks to coding sensei Roi for the tip, known by some as ‘The Priest of PRY’ (seriously, he’s got a robe and shit).
VIM is something I’m very keen to learn, and Roi came good on his promise to give us a workshop on Friday afternoon. It’s essentially a text editor (just like Atom), with the crucial difference that it all works from within the command line, keyboard only. It’s a geeky thing to use even for developers, but affords a much more frictionless developing environment. It’ll take a fair bit of getting used to, but I’m spurred on by the high praise its received from some very good developers (Roi included).
I learnt a valuable thing about coding workshops, which is that consist of very little work and very much setting up of laptops. In fact, thats all we had time for, but the workshop wasn’t wasted. VIM, out-of-the-box, is horrible. I think this scares a lot of people off, so it’s good to have that first step out of the way.
Here’s a couple of articles from deep inside camp VIM:
Takeaway challenge
This was a fun one. We had to create a program that could display a menu, take orders, calculate a total and (drum roll) confirm it by sending a real text to a real phone.
The word menu started to look really weird as I worked into the afternoon. Still hasn’t started to look normal again. m e n u. Hmm.
Here’s my effort:
I successfully managed to parse my menu from a CSV file created on Excel and use the Twilio API to send an order confirmation to my phone (complete with sushi emoji 🍣 ).
Unfortunately I couldn’t find a good way to stub multiple user inputs. As a result my RSpec are currently all over the place, and every time I wanted to run them I had to order 5 takeaways.
Looking forward to finding out how that’s done in tomorrow’s code review.
“Relaxation”
Great TV this week: Simon Amstell’s new series ‘Carnage’ was funny and thought-provoking. Really hit a good note on a difficult topic. It’s a fictional documentary looking back at today’s ‘carnists’ from the perspective of 2067’s world of vegans, and I kind of believe it.
Also listened to one of the code newbies podcasts. Highly recommended for anyone wanting to get a feel for how developers fit into the tech landscape, without too much intense codey jargon. Gonna try and listen to these on my daily London Underground nightmares.
Stuff I learnt:
- How to incorporate CSV files into my projects to store data
- How to send a text from my program
- An introduction to the world of API’s although there’s much more to be find out
- It’s ok to go off-piste, and you learn a lot when you do
Stuff that hasn’t clicked yet:
- How to stub user-input
- I really need to be more strict on myself with writing tests before I write my code. It wasn’t too bad with the Oystercard program, but today, after failing to find a user-input stub solution, the testing of my takeaway system is not up to scratch
- VIM! I really want to find time to delve into this in the coming week and get to the stage where I’m comfortable using it for the challenges at Makers
- I need to research how to use symlinks, but first I have to research what they actually are. But I know they’re gonna be useful. I can feel it.
TODAY’S JAM
Rediscovered this tune this week. That “twice upon a time there was a boy who died” verse is just 👌🏽 .
If you read past the tapir, chances are you read the whole thing. If you enjoyed it, please click the little heart below. It’ll help others find this and enjoy it too.
