Photography: New York (2014)

Monday, 13 October, 2014 — photography

Robin and I took a vacation to New York, covering New York City for a weekend and upstate in Accord in the Catskills at the tail-end of September. It was absolutely gorgeous and I have four growing sets to show the trip:

• On the Silver Star
• New York City 2014
• Accord, NY
• Vacation Foliage 2014

Some of the images, notably some of the foliage pieces like the one above, will be for sale. Drop me a line if you’re interested in purchasing a print.

Tool Sharpening: Oct. 11, 2014

Saturday, 11 October, 2014 — development improvement

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

So, it’s been a little while since my previous entry. I’d like to thank a 10-day out-of-state and substantially offline vacation for that. I have been posting photographs from the vacation, over on Flickr.

Anyhow, before I left, during and after vacation, I have been able to do some technical self-improvement.

Environment + Process tweaks

• Added two more smart folders in Mail.app
  • One shows me all mail that I don’t have filters for that’s new within the last 48 hours
  • The other shows me items still in my inbox that are older than two weeks, which I want to serve as a sort of “drop dead” period. If I’m not getting to it by that point, I’m not likely to get to it at all. Archive and move on.
• Improved my incoming email filtering so fewer automated messages hit my inbox

Project work

There’s been little progress on account of the vacation work, however, I did start on implementing the service object for adding a pomodoro in my Pomodori project.

Skill improvements

• Learned about Control-R to search through previous commands. I’d been using history | grep <cmd> for years, like a chump
  • This works, but Control-R is more efficient a lot of the time for

Articles read

• Avdi Grimm’s “Boolean Externalities”
• “Making RSpec stop operation immediately after failing” by Jeff Kreeftmeijer
• “Faith in Eventually” by Jason Fried
• Uncle Bob Martin’s “My lawn”
• Khoi Vinh’s interview with Mike Monteiro covering Monteiro’s new book, You’re My Favorite Client
• Craig Hockenberry’s, “The Terminal”
  • This is where I picked up the Control-R tip
• “Don’t End the Week with Nothing” by Patrick McKenzie

These next two pieces are vitally important not because they relate to the technical craft of our industry, but the rather awful state our collective social craft is in within this industry. While we’re great at technically building social spaces and connections online, we’re really crappy at understanding how those same tools can be severely abused and mitigating that abuse. These two pieces are two of the saddest and troubling I’ve read. I highly encourage you to read them and reflect on them.

• “Trouble at the Koolaid Point” by Kathy Sierra / Serious Pony
• “Telling My Troll Story Because Kathy Sierra Left Twitter” by Adria Richards

Screencasts, podcasts and presentations

• Ruby Rogues Ep. 173: “ActiveRecord Crud with Eileen Uchitelle”
• Ruby Rogues Ep. 174: “RubyGems with Eric Hodel”
  • JEG II’s last episode as a regular
• Ruby Rogues Ep. 175: “Civic Hacking with William Jeffries”
• Accidental Tech Podcast Ep. 82: “The Flash Storage is Adequate”
• Accidental Tech Podcast Ep. 83: “Entering the iTouch Phase of My Life”
• Accidental Tech Podcast Ep. 84: “The Load-Bearing Finger”
• Giant Robots Smashing into Other Giant Robots Ep. 116: “A Model Jellyfish”
• Giant Robots Smashing into Other Giant Robots Ep. 117: “Designing Quality”
• Back to Work Ep. 186: “I Wish John Siracusa Were Here”
• Back to Work Ep. 187: “Peeling a Dangerous Onion”
• Back to Work Ep. 188: “The Smell of Snake Anxiety”
• Attended Magnus Hedemark’s Triangle DevOps presentation, “DevOps: Year One”
  • One piece that I really liked was thinking of organizational structure and going “SOA”
  • Now, this sounds like keeping existing development and operations silos. No. Instead, it means a team that can deliver a solution end-to-end that other teams can use. Engineering teams will have development and operational components and expertise embedded to deliver that end-to-end piece. From there, teams can iterate service offerings that meet an API independently, which cuts waste
• Reviewed slides from “Writing Fast Ruby” by Erik Michaels-Ober
  • This is a wonderfully illustrated slide deck. Seriously, go look at it.

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

• Read DevOps Weekly No. 193

Screencasts, podcasts and presentations

• Attended Jason Draper’s presentation on Ember.js at Triangle.rb
• Listened to Giant Robots Smashing Into Other Giant Robots Ep. 114: “Offer Value First”
• Listened to Giant Robots Smashing Into Other Giant Robots Ep. 115: “There’s a Spectrum Involved Here”
• Listened to Ruby Rogues Ep. 172 on Extreme Deployment
• Listened to Back to Work Ep. 185, “David Foster Wallace Morning”
  • Discussion between hosts Dan Benjamin and Merlin Mann on effective email practices led me to making the project work adjustments on my Daily Review as noted above
• Watched Ruby Tapas Ep. 010: “Finding $HOME”
• Watched Ruby Tapas Ep. 011: “Method and Message”
• Watched Ruby Tapas Ep. 012: “#fetch for Defaults”
  • There’s more on this technique in Avdi Grimm’s Confident Ruby and I absolutely love the technique as it saves me a lot of otherwise defensive programming

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

Tool Sharpening: Sept. 7, 2014

Sunday, 7 September, 2014 — development improvement

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

The time since my last entry was primarily spent reading blog posts and watching screencasts vs. writing code at home. I’m totally OK with that.

• Read up on Devise, CanCanCan and Clearance as authentication and authorization schemes
• Built an initial User model for New Project
• Read James Edward Gray II’s post, “Sleepy Programs” which will be useful for the Pomodori project I still need to finish up
  • Then I reread it later on in the week
• Watched Ruby Tapas episodes:
  • 006: Forwardable
  • 007: Constructors
  • 008: #fetch as an Assertion
  • 009: Symbol Literals
• Reviewed entries in vimtutor
• Reviewed posts on setting-up microservices
  • Breaking up Monoliths and moving to microservices
  • How Karma builds microservices
• Read entries from this week’s Ruby Weekly
• Installed pry-byebug
• Made my first use of verifying doubles with RSpec 3
  • This in particular helped me feel more comfortable just using a test double vs. the natural object out of laziness
  • The test run for just this file in a larger suite went from 6.34 seconds to 0.01234 seconds
  • This serves as a good reinforcement that when I’m unit testing, I should test message passing to objects not under test and not fully instantiate those objects with whatever they need to know about the state of the world
• Read up on changes to RSpec 3.1
• Listened to Ruby Rogues Ep. 171: “Evaluating Yourself”
  • This episode helped me validate a project I’ve been thinking about building for a little while
  • That totally means I need to wrap up the two projects I already have in-flight

Tool Sharpening: August 24, 2014

Sunday, 24 August, 2014 — development improvement

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

This week has been pretty light, so I’ll present this without much in the way of ceremony:

• I read up on using pry as a debugger for Ruby
• Started a small project to work on in order to refresh my Rails knowledge
  • Identified the project from a list of potential projects I’ve been keeping
  • Fleshed out the questions I want the product to answer
  • Instantiated a Git repository for the project
  • Sorted out dependencies
  • Built an initial schema diagram
• Rebuilt smart mailboxes for Apple Mail
  • My previous mailboxes disappeared a little while ago and rather than chase down recovering them, I set-up new ones
    • All unread
    • Unread from the last two weeks
    • Unread from the past 2 days
    • Mailing Lists
    • Recent from the last two weeks
  • In the morning, checking email, I can check what’s new from the last two days and move on with my day
  • As I have other time, I can knock down more of the backlog