walls.corpus

By Nathan L. Walls

Tool Sharpening: Sept. 15, 2014

Monday, 15 September, 2014 — development improvement

For some background on what’s going on here, see the first tool sharpening post

For this and following editions of my tool sharpening series, I’ve set-up five different sections below. I’ll explain them briefly:

  • Environment + Process tweaks will be for anything like my tweaks to BBEdit, vim, tmux profiles, helper scripts and similar changes
  • Project work will cover personal project work I do, since my primary motivation for that work is to learn
  • Skill improvements
    • Work with code kata, koans, exercism.io or similar
    • Typing practice
    • Other deliberate skill practice work
  • Articles read will be for links of interest I come across from Twitter or mailing lists
  • Screencasts, podcasts and presentations will enumerate audio and video media that I’ve reviewed. Expect this to be Ruby Rogues and Ruby Tapas heavy.

Environment + Process tweaks

I have a Getting Things Done-style Weekly Review that just hasn’t been working for me for a little while. Many weeks, I simply look at the weekly review in OmniFocus and mark it complete. It’s important to me, abstractly. But the way I’ve structured it clearly isn’t important to me in the concrete terms of actually doing it.

To that end, I’m hoping to move some of the big scary bits out of the Weekly Review and into a work day Daily Review I have been far more consistent with. Those pieces are to:

  • Process email from the last 48 hours for further action or file it
  • Review anything I added to OmniFocus in the last day
    • I have a perspective set-up for just this purpose
  • Review anything I added to the OmniFocus Inbox so it has a context, a project and a next action

Project work

I’ve been stuck recently on my Pomodori gem project. Namely, I was getting to the point where I felt like I was working too hard to make the command line interface work with Behavior Driven Development. So, I idled on the project for a few months.

Thankfully, the work project I’ve been working on has helped me identify where I could close some of the gaps between what I want to do and how to do it intelligently, so I’ve started back on that project, hoping to get the first version wrapped up before too much longer.

  • Worked on Issue 28 of my in-progress Pomodori gem
  • Put Issue 28 on hold and began work on Issue 30. Once Issue 30 is done, I can come back to Issue 28.
  • After review, opened up a new milestone and several smaller issues and closed Issue 30

Skill improvements

Avoiding module and class namespace collisions

So, the most interesting thing I learned this past week was about the purpose and use of the :: ahead of a namespace in Ruby. At work, my team and I are working on a automation our release preparation, which covers everything from triggering software packaging to building tasks and sending notification emails. For an audit trail piece, we want to log several of the steps to our team chat. And, instead of writing everything to target a third party object directly, I wanted to wrap it in an object that was part of our application’s domain.

So far, so good.

However, I soon saw an unexpected error, along the lines of ReleaseAutomation::Flowdock::Flow not defined when what I was trying to do was instantiate Flowdock::Flow within ReleaseAutomation::Flowdock. It took a little bit to find the right search terms, but I found a Ruby Best Practices post covering modules and namespaces. In that post, I found I needed to invoke Flowdock::Flow as ::Flowdock::Flow to tell Ruby to go to the top of the namespace tree vs. trying to match Flowdock as an abbreviated namespace in my project domain.

Articles read

Screencasts, podcasts and presentations

Looking back, I’m pretty happy with what I was able to learn this week.