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.

on by

Ever wondered what sort of structures classical music has? The answer is — loads! This week I gave a presentation to my coding cohort about sonata form. If you’re curious to know what’s going on with classical forms, check out the video below! 
 
 You’ll want a Spotify account (free is fine) and if you like, you can follow along with the score as well. If you’re not comfortable reading a 4-part score, I suggest following either the first violin (top line, treble clef) or cello (bottom line, bass clef).
 ​
 Full score: hz.imslp.info/files/imglnks/usimg/2/26/IMSLP04758-Beethoven_-_String_Quartet_№4_Dover.pdf
 Spotify link:
 open.spotify.com/track/2YCrzzNg8RsF9TR7ZjdwiM
 Workshop slides
 docs.google.com/presentation/d/16Yi77R4Qn1Xxp30CSV0RRTP_QP3XsegoX9BjKUvT_fI/edit?usp=sharing
 
 
 
 Have fun and post in the comments!

Sonata Form Workshop for Makers Academy from Paula Muldoon on Vimeo.

on by

When I found out I was going to be pairing with “Captain Code”, I was curious to work with this snazzy computer program that would somehow mysteriously assist me in my programming learning. I envisioned a chirpy little bot that would come out with such pearls of wisdom as, “Ahoy there, are you sure your constant is defined, matey?”

Obligatory photo of Jack Sparrow. Entirely unrelated to Captain Code, who is much more intelligent.

Needless to say, Captain Code is a loveable pirate captain who retired from the high seas when his wooden leg was destroyed in a cricket match. He has a keen eye for detail, drinks just enough rum to be constantly jolly, and was never a very good pirate because he chatted too much to his captives, became their friends, and let them off for absurdly low ransoms. His profit margins were crap so he reinvented himself as a programming coach and joined a ukulele band.
​

Sing to the Beatles “All you need is love”

Turns out Captain Code is a polite way of saying, “You’re on your own today.”

So after 2.5 weeks of intense pair programming, today I became a lone wolf coder.

To be honest, I was really looking forward to today. I have found the pairing process rather exhausting, being in such close contact with another human being for so long. And while I’ve certainly grown better at it, and worked out when to take breaks and how to communicate to make the experience successful, I was delighted to have the chance to work untrammelled by a pair’s lunch schedule.

​
So here’s my run-down of a day of solo coding.

What went well:
1. My own schedule! I took my lunch break when I wanted it!
2. Pomodoros — I was really disciplined about 25 minutes on and 5 minutes off, and that timer really helped make my day productive.
3. Error debugging — I hit a stride today in debugging errors/fixing failing rspec tests. 
4. Code production — I finished the Single Responsibility principle, so am very happy that I’ve come this far.

What didn’t go so well:
1. I was lonely. I figured working on my own would be a walk in the park, after many years of practising violin 4–5 hours a day alone. Turns out I like talking to people, and this was the first day on the remote course I felt like I wasn’t getting enough human contact. This loneliness had a cascading effect:
2. I was grumpy because I was lonely.
3. I struggled to take breaks, because I was already grumpy so kind of figured I might as well keep on being a grump, and my grumpiness wouldn’t affect a pair. (I took 5 minutes because of my pomodoros, but really would have benefitted from longer breaks as well.)
4. Accountability. I didn’t slack off, but I really wanted to take an hour-long nap or watch TV and finish coding in the evening. This isn’t an option when you’re pairing, so the temptation never comes up. So I wasted mental energy combating this desire.
5. Not having a pair means you miss obvious things! I had to ring up my coach because of an absurdly stuck test and he spotted immediately that “Borg: 3 LS” and “Borg: 3LS” weren’t the same — a pair would have spotted it.

A borg, debatably.

I had wondered if the pair process was the best way of learning — it can be unbelievably frustrating to be at a different stage (whether higher or lower) than your partner — but after today, I can definitely say that I’d rather the frustrations and trials of pairing than doing much more solo coding.

So cheers to my cohort for being full of awesome pair partners!

on by

A sweet house in Cambridge we saw on our Easter walk.

This weekend’s coding challenge involved writing a lot of rspec tests. I got stuck pretty badly. In fact, am still stuck, hoping my coach can respond before I submit; I have shown my test to two cohort peers who couldn’t figure out what was wrong, and I do have a few more suggestions to try.

Having been stuck for about 72 hours, I feel the following:
1. Like a failure
2. Like I’ve wasted my money on the course
3. Exhausted (partly because it was Easter weekend and I had a lot of company, all of which was wonderfully fun, but which was tiring as well for this outgoing introvert)
4. Stupid
5. Worried I won’t get a job because I got stuck in rspec tests and couldn’t figure it out

To put matters in context a bit, I am used to working hard but not used to struggling — a key distinction. I graduated from university with highest honors and I had a successful career as a violinist. While at university I took hard courses but in topics that were my forte — English, music theory, Spanish, and of course violin. I steered clear of math and science because I didn’t have a very good math/science background and I was afraid of getting a grade lower than an A.

So Makers is the first time in my life that I’ve stretched myself to work outside of my comfort zone. I have to remind myself that I started violin lessons when I was eight and had many, many years of focused, individualised training that enabled me to reach the standard I have. I’ve been coding for 5 weeks. Of course all of this is new, and of course I should be struggling.

Struggling is hard. I have been realising over the past 72 hours how much of my identity is wrapped up in being right. I feel emotionally exhausted, and not just because of rspec and because I am outside of my comfort zone and struggling: because I have realised that so much of my identity throughout my life is wrapped up in being right that the thought that I might not always have the right answers to more important questions (such as personal relationships) makes me a bit sick.

I watched Brene Brown’s Ted Talk on vulnerability yesterday and the thing that really struck me was how vulnerability and the absence of certainty are so related. If you’re certain about being right (or even wrong!), you’re not vulnerable. And without that crucial, scary, uncertain component of vulnerability, deep connection with other humans (and, I’d add, with oneself) is impossible.

So here’s a baby step towards vulnerability, courtesy of rspec: I don’t know the answer and that’s ok because people will help me to find it.

Update: the story does end on a good note. My coach and cohort came through and I was able to resolve the errors and finish most of the problem.