Plasticx Blog

distribute scripts as gist micro-gems

January 20, 2013

It's really easy to distribute scripts, not just gems, as gist micro-gems. Since rubygems and bundler can handle complicated dependencies the scripts you distribute can be more advanced than just ten or twenty lines.

I wrote a script to generate an OAuth key and secret for the Tumblr API and I made it available as a micro-gem. It is encapsulated in gist 4577106 To generate your key and secret is as simple as the following:

mkdir /some/working/dir
cd /some/working/dir

wget \
https://gist.github.com/raw/4577106/6bc9befedcd5238ce9f2ee562cace666dece460c/Gemfile

bundle install
bundle exec generate-token

One bit of useful flare is the ability to set the bindir in the gemspec of the microgem to dot "." - the current working directory. This allows bundle exec generate-token to work correctly since github gists don't allow files to be in sub-directories, and the default bindir in rubygems is 'bin/'.

Seattle.rb IRB presentation

January 08, 2013

I gave a lightening talk about IRB (Interactive Ruby Shell) at Seattle.rb on 01/08/2013.

Here is my speaker deck: https://speakerdeck.com/monde/seattle-dot-rb-irb-presentation

Here my notes and example irbrc's: http://bit.ly/seattle-rb-irb

The irbtools gem is really massive in all of the features it curates together. As mentioned in the deck, I prefer a more simple setup of:

integrated vim to edit/paste code via the interactive editor gem
load/save command history (require 'irb/ext/save-history')
tab completion on object methods (require 'irb/completion')

Seattle.rb Refactoring & BDD presentation

January 02, 2013

I made a presentation on Refactoring & BDD at Seattle.rb back on 10/09/2012. I put my slides and notes from the presentation up on Speaker Deck.

Seattle.rb - Refactoring & BDD Presentation

Some quick takeaways ...

Problem Domain

The less your problem is understood, the more complicated your solution is likely to be. This is one of the reasons why we refactor code - we increase our understanding of the problem domain and increase our abilities to apply solutions to the domain as time goes by.

Simple Refactoring Guidelines

Modify code in small steps
Write tests for code that is affected
Write human readable code

Refactoring Pro-Tips

Refactoring Favors Behavior Rather Than Logic
Writing code that can be unit tested changes your writing style
If a method can’t be unit tested it must be refactored
Factor out interaction with frameworks from code that is tested

Outside-In Development

Let your tests drive your implementation. I started coding my CapGun web thumb service using Cucumber to drive Outside-In/BDD development.

Dog Food

Dog-food an app while you are developing it as quickly as possible. CapGun was web thumbing URLs from my Twitter feed and posting the results to a Tumblr account before the service was released to the public.

Attribute this quote to me, please

Outside-In / BDD is really just “poor man’s pair programming” (R) - Mike Mondragon

report Resque exceptions to Honeybadger

August 06, 2012

Two of my heros, Ben Curtis and Starr Horne are building their own application exception reporting service for Rails, and presumably other application frameworks like Sinatra. The service's name is Honeybadger. I've been running one of my hobby applications in the Honeybadger for a time. My application uses Resque as its work queue and I like to record exceptions into Honeybadger when they occur.

The Honeybadger gem configures directly into Rails' request/response loop. Therefore, all one has to do is initialize the application correctly with an account authorization code to the service, then view and controller exceptions are automatically recorded. However, if logging exceptions outside of that loop is required, the gist listed below is one way to achieve this goal for a Resque job queue.

maintaining my copy of obtvse

August 06, 2012

I'm maintaining my own copy of the obtvse blog application. I set my copy up initially as a duplicate repository from obtvse's git repository. These commands were used to duplicate the repo.

git clone --bare https://github.com/NateW/obtvse.git
git push --mirror git@example.com:monde/whatever.git

Now, I can hack on my copy all I want and keep it in a private repository. I've added my favorite capistrano set up and have appended other gems to the Gemfile such as rubyracer to compile assets during deployment. When obtvse gets some code changes that I would like pull into my copy I will do so having NateW's repository as a remote in my local repository such as the following example.

git remote add natew https://github.com/NateW/obtvse.git
git checkout master
git fetch natew
git merge natew/master

switched my blog to obtvse from typo

August 06, 2012

I switched this blog to the obtvse blog rails app. It fit how I would like to blog, as well as what I prefer in terms of an application and devops for said application.

My criteria for selecting obtvse where these:

dynamic as opposed to static rendering
simple application, light weight
basic templating system

I had been running on Typo, but it became over featured for my needs. I endured as fdv refactored and modernized its code base, but it became a burden to maintain my copy with code changes. Typo has a great community, and I support their efforts, but it no longer fit my blogging desires.

I considered a static blog generator like Octopress, but it didn't fit my itch for performing devops on a small Rails application.

When I first joined the Rails community in 2006 I wrote blog posts all the time about what I was learning. Overtime, I became more proficient in my skills and I didn't have time to blog about what I was doing. Every now and again I would think to myself "this would be good for a blog post" but not articulate the idea any further into written code.

I'm looking forward to becoming an active blogger again because obtvse fosters quick and easy publishing of posts since its templating is done in markup. It's also adept at allowing one to work on any number of blog posts at a given time. For instance, only spend ten or fifteen minutes a day working on multiple posts, until each is ready to be published. I'll no longer have an excuse to not start a blog post when an idea comes to mind and then work on the post a later when time is available.