Author: FiddlersCode

Software Engineer & Violinist

on by

6/2/2017

​This week was Rails week, and our remote cohort of 17 programmers from 5 countries working in 3 timezones spent a week making Acebook, a clone of — you guessed it — Facebook.

It was a great, if hard, week. My learning shot up exponentially. Also my ice cream consumption. Here is what I learned:

1. Red/refactor/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red is not a great cycle. Red, green, and ONLY THEN refactor. We spent a lot of time looking for bugs in our code when it turned out our partial was named incorrectly and Rails couldn’t find it.

2. 
​Polymorphic (alas, not paulamorphic, much as I love eponymous taxonomy) associations are really cool. I’m glad they’re so cool, because here was the process in which my pair and I learned about them:

Step 1:
Build a PhotoComments functionality, almost wholly copying the already-existing Comments functionality. This was not remotely DRY, but we couldn’t figure out how to get round the database issues. This took a whole day because of the aforementioned red/refactor/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red and we were super pumped to finally have it submitted for PR.

Step 2:
Our coach tells us that there has to be a dryer way and blocks our PR. His name is Dan, and he’s a great coach because he made us go and find something way better. Was I still banging my head in frustration? Yes.

Step 2.5:
Help my landlord remove the old dishwasher that’s being replaced and end up with a broken hose and water gushing out over the kitchen floor before I luckily had the presence of mind to switch off the water switch on the pipe. Not flooding the kitchen is possibly my proudest moment of the whole week, and I’m pretty proud of Rails. I did later get a bottle of prosecco as a reward for valiant behaviour, so all in all, a good week.

Step 2.75
Have standup without coffee or breakfast (see Step 2.5) and decide to throw out everything we did yesterday.

Step 2.90
Go to make coffee, forgetfully turn on the kitchen tap, and watch the water flow out everywhere. Put a tea cosy over the faucet so that doesn’t happen again.

Step 3
Google. It’s a solved problem, so look for the most obvious answer:
​

This first searched proved extremely productive (newer searches first):

Step 4
Use TDD to build a polymorphic database!

Step 5
Be foiled in your attempts to merge your PR because of merge conflicts that can’t be resolved in the ten minutes before retro.

Step 6
Spend another hour that night working on all kinds of git conflicts.

Step 7
Give up on resolving the merge and write a blog.

Still, polymorphism is really cool. And if you’re still awake, you might be wondering what it is! Basically, it’s a way of reusing code so that, for example, the code for comments could be used for both posts and photos. It defines the DB associations so that the comments are polymorphic, i.e. can exist with either a post_id or a photo_it. The Ruby on Rails Guide has a great section which we found really useful, and there are various other blogs with step-by-step instructions.

So I think that’s it for Rails week. I’m building an Instagram clone this weekend, so I’d better get off the computer. I can’t stand Instagram, so if you’re very lucky, you might get a grumpy post from me about how I wish I could use Rails to build something more interesting this weekend. Or about how I tried to build something more interesting and ended up melting my laptop.

Read about the first half of Rails week: Buttoning Up Code: a valiant team uses TDD, pairing, and XP values to defeat a bug

on by

5/31/2017

This is the story of a bug.

This bug was annoying and caused the coders a great deal of heartache and misery.

The coders were tempted to give up on solving the bug.

But they persevered, and the bug was fixed.

This is also the story of Makers Academy, encapsulated in this one small story about a bug.

On Monday 29 May 2017, my pair partner and I submitted a pull request for the front end we had built and styled using Ruby on Rails 5. We were quite proud of our design, and rightly so. It was a clean, elegant user interface, modelled shamelessly on Facebook (our whole-team project was to build “Acebook”).

Our coach asked for some changes, one of which being to fix a test that had mysteriously begun to fail (first lesson learned: run your tests again before submitting a PR), the second to restyle a button class according to Rails syntax.

The first failing test was relatively easy to fix: a stylesheet had been required twice. Turns out you don’t need to explicitly require your stylesheet as it will be automatically required as long as it’s located correctly.

Which led to the second error: ‘unable to find button “New Post”’.

This error would drive us round the bend.

We could see quite clearly on the page that there was a button; we could inspect it with the chrome devtools and see its lovely button classiness.

And yet Capybara couldn’t find it.

I Zoomed one of my teammates, and when he couldn’t find the error either, I retired in defeat for the night. When we resumed the next morning, I showed the error to my full team of four and no one could figure it out.
​

​

So we called in the big guns: our coach.

We then spent a good half an hour exploring differences between Rails 4 and 5 syntaxes (‘form_to’ vs. ‘form_with’ anyone?), changed a lot of things around, and eventually reset the test and code to a point at which it was working. We couldn’t figure it out.

Eventually our coach said, “Sometimes you just have to say ‘that happened’.” That sure did happen. But there was one thing I couldn’t understand: why the test passed when it said ‘click_link” when the code was clearly a button, yet failed when the code said ‘click_button’.

Then our coach got the light in his eyes that said, “I now know the answer, and I am going to leave it to you guys to figure it out.”

Needless to say, I was annoyed.

​I’d been plugging away at this error for a good three hours now, with several different teammates and lots of attempted solutions, and had gotten nowhere. I was at the frustrating stage where my code worked (I thought — I could clearly see the front end doing exactly what I wanted the test to do) but I didn’t how I had broken the test, or why it was working with the reset code.

At this point part of me still wanted to implement one of the two suboptimal solutions:

  1. Commit the test that passed mysteriously and hope no one asked us to explain it
  2. Reset the code back to its ugly, plain link/unstyled state with a comprehensibly passing test.

It was also lunchtime, which may have had something to do with my frustration.

I switched pairs to get fresh input and we plugged away at the problem and then all of the sudden it came to us in a flash — in fact, the bit of Rails magic was a link, not a button, which is why ‘click_link’ worked, even though this link had managed to get attached to a button class.
​

​​

Great, so all we needed to do was to change ‘link_to’ to ‘button_to’ and be on our merry way. Simple.

Have you ever tried editing code from one unfamiliar syntax to another unfamiliar syntax while it’s lunchtime and your brain is fried from a morning of debugging?

We reconvened after lunch (in my case, a nap) and in twenty minutes had sorted out the syntax, the tests passed, and the browser looked fantastic.

The End.

​

​
The evil bug was defeated because:

  1. Curiosity and a desire to learn drove the team to find the best solution
  2. Teammates kept pushing each other forward when someone was discouraged
  3. The team shipped outstanding code, which communicated its intent clearly to the dev who will work on it tomorrow, and which can serve as a template for future code. No replication of errors on their watch!
  4. The team also shipped simple, well-refactored code: 3 lines of ‘link_to’ code became one line of ‘button_to’ which also looked better on the UI
  5. The team respected the TDD process: even when it was a giant pain in the neck to have a mysteriously failing test, we still ended up with much better code because of it
  6. The team pair programmed really effectively to solve this problem, rotating the people working on the bug so there was a good supply of fresh input mixed with the knowledge of one of the devs who wrote the code

The whole Makers Academy experience is summed up in this bug experience: pairing, TDD, XP values, and rigorous code review. I’ve never been so proud to be a MA student as I was today.

With thanks to teammates Jon, Miles and Sandy, to the rest of the remote April 2017 cohort, and to the MA staff.

Read about the second half of Rails week: Paulamorphism: tales from Rails

on by

I’ve recently rocketed my music setup into the 21st century and I thought I’d share with you the tech I’m using now!

Tablet & Stylus

Essential for reading music. I use the iPad pro 12.9″ with the Apple pencil. 
Benefits:

  • Save the trees — no more printing music
  • Easy to mark up in different colours
  • Also easy to erase — no more residual pencil marks
  • Easy to read in dim light
  • Entire music library in one lightweight tablet (yes, they are light now)

Learning curve:

  • None, really

Pedal

Must-have to turn the pages. I use the Donner (https://www.amazon.co.uk/Donner-Bluetooth-Rechargeable-Reading-Controller/dp/B01MZICTQV)

Benefits

  • No more difficult page turns

Keyboard

I use a midi keyboard to input notes into Musescore. Great for composing quickly! Doesn’t do rhythms but the pitch saves you a lot of time. Really portable as well — took it on a transatlantic flight iwth no problem.

I use M-Audio Keystation Mini 32 II, Compact Portable 32-Key USB/MIDI Keyboard Controller with Synth-Action Velocity-Sensitive Keys (https://www.amazon.co.uk/gp/product/B00IWRJSE2/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1)

Benefits

  • Easily plugs into MacBook
  • Draws power from MacBook
  • 32 keys but has a big range as you can hit the plus or minus button to move your octave around

Modacity — Practice App

Home

I use this app every day with my practice and I think I’ve barely scratched the surface of what it can do. Shoutout to Andrew Hitz at The Entrepreneurial Musician podcast for introducing me to this!

Benefits

  • Make practice lists
  • Record yourself easily
  • Metronome/tuner
  • Tracks time spent practicing
  • Tracks practice streaks

ForScore — for reading music

I got this app several years ago for reading music, back when it was half the price. Not sure I’d buy it now as there might be cheaper alternatives, but I’m very pleased with it nonetheless.

PiaScore — IMSLP app

Great for downloading music from the wonderful free IMSLP library.

Musescore — for composing

Like Sibelius, but free. I compose on my MacBook Air but there is an iPad app as well which I haven’t tried.

on by

I’ve been writing up a lot of little Node projects recently and there’s a few npm packages I’ve come to rely on for code quality. I figured I’d write them up so others can use them. I’d also love to hear from you about the packages you consider essential for npm, so please leave a comment!

Pre-commit hook

A pre-commit hook is essential to enforce your code standards before committing. While CI tools mean you can and should run your checks on the build, it’s best practice to run before commit — vastly lessening the chances of errors making it into your repo.

I’ve used pre-commit very happily in my projects, although there are other tools as well.

Usage:
I have configured it to run my code coverage tool (see below) and eslint. I deliberately removed some of the test coverage, and tried to run git commit -m ‘pre-commit demo’.

Commit failed since my test coverage was not high enough.
Proof that the commit failed — latest commit is not the one I tried.

eslint

At first, eslint is the biggest pain in the ***. But with a little bit of configuration and patience, you’ll find that it does way more than make your code cleaner: its rules about the code itself mean you will learn so much about JavaScript, particularly if you are new to ES6. Configure it to run on your pre-commit hook to get the full benefit.

Note `unusedVar` on line 7.
We get these errors.

The first few times you use it, you’ll find it slows you down. However, the benefits become apparent pretty quickly.

You can also configure it pretty easily as needed, and even choose a popular style guide so you don’t have to spend too much time yourself. Run eslint — — init to kick off the configuration.

Recommended Resources:

AirBnB’s style guide for eslint — really interesting reading.

JSJ 336: “The Origin of ESLint” with Nicholas Zakas — great podcast

NYC — code coverage tool

Why a code coverage tool? First of all, to enforce test coverage. I have it set to 95% and I can’t make a commit if I don’t have that amount of coverage. However, it’s also super useful when refactoring tests to make sure you haven’t accidentally removed the only test covering a particular line of code.

Message from NYC.

As you can see, the messages are very helpful, particularly which lines are uncovered. I can pinpoint exactly where I need to sort out the tests. Make sure to tell it to exclude the test files so you don’t get stuck in an infinite loop of coveage errors!

Recommended Resources:

NYC npm package

Conclusion

Automate whatever you can, including your code quality tools. It’ll drive you up the wall at first but it’s worth it. If you want to see these tools in action, check out my CocoaJavaScript repo (currently a work in progress to create parameterised testing in JS/Mocha).

on by

It’s been a month since I last wrote a proper coding blog, and in that time, so much has happened! I learned JavaScript, did a project week, and now this weekend have come back to my Ruby roots as the entire cohort works as a team to use rails to build a replica of Facebook.

Regarding my initial experience of JavaScript, I can do no better than to quote Makers Academy coach Roi Driscoll:

“Javascript week is a very special time at Makers. For me it was the first time I wanted to throw things at the projector and scream ‘HERESY’. It was not my beloved Ruby, and I was not happy about it.
I felt strangely codeblind — unable to make sense of all the curly brackets, parenthesis, semicolons and the damn word ‘function’ here there and everywhere. My reaction was to fill my soul with a deep and passionate hatred of Javascript as a language, and anyone involved with it was the Devil. I was wrong.”
I did eventually learn to do cool things in JS, but what a sweet relief to be back in the land of Ruby, where there is a useful method for anything we could possibly want.

This weekend’s challenge was a delight: called Ruby Refresher, it was simply a list of about 40 puzzles we had to solve using Ruby methods. I did panic at one that asked for the square root of a number — thinking I was in JavaScript land where there are no methods — sorry, functions — and was imagining creating the method from scratch. A quick Google search reminded me of what I already knew: ‘sqrt’ is a handy Ruby method.

So I had a lovely romp in the park with my old, dear friend Ruby this weekend and now forward to making as many puns on the word rails (“keeping it rail”, “the holy gRail”) as I can possible manage.