The Last Train

“No distance of place or lapse of time can lessen the friendship of those who are thoroughly persuaded of each other’s worth.” — Robert Southey

It occurred to me that once I stepped onto the train this morning it will be my last time for what will probably be quite a while. Moving to a new state at the end/beginning of a year really drives the point home. There is a definite feeling of closure and new opportunity.

That got me thinking about my journey ahead and how I ended up at this point. I’d like to thank the people around me that helped define who I am in my career path.

It pretty much started with myself and a pirated copy of Agile Web Development that led me to find others interested in Ruby programming. It was a tough time but that is when I stumbled into Ray Hightower leading a Ruby Meetup in a library meeting room. Thanks Ray, my involvement in ChicagoRuby, I feel, is what really moved my career into the fast path.

Next up is Dave Giunta, Courtney Braafhart, and Jim Hassan who believed in me enough to take a chance and give me my first full-time Ruby dev position. Thanks… I was crazy nervous trying to play it cool in my interview (with my pinstripe suit). This is also where I met Adam Walters, Chris Hallendy and Stephen Korecky. Who have become good friends and I’m always learning from each of them.

This is about where I attended an Obtiva TDD Bootcamp taught by one Dave Hoover. Dave must have been semi impressed with me cause he asked if I was interested in trying out for Obtiva shortly after that. Of course I jumped at the chance to work along side people I looked up to in the dev community. So thanks Dave Hoover, Kevin Taylor, Todd Webb and Kat Reid. That quadruple interview was intense and I know I bombed Kevin’s interview but again… thanks for believing in me.

I can say that once I started with Obtiva it was Noel Rappin, Joe Banks, and Chad Pry that really put up with me and taught me to become a half way decent dev.

Now my journey continues to Florida to join the Hashrocket family. It is my honor to be a small part of another great dev shop. So thank you, Hashrocket, for taking me on and letting me continue this crazy career path I’ve set myself on.

To all who were mentioned and those that were not… thanks for the friendship and experiences. They will not be forgotten.

Initialize those Settings

When starting a Rails project you will generally start loading in your ‘goto’ gems. You know, the ones that you are familar with and provide quick value for you and your project.

One of these for me is settingslogic. This has always been one of my first setup steps. This gem is great. It allows you to set your application settings in a YAML file and then gain access to that data in normal ruby object method calling syntax.

ex: Settings.aws.secret

Cool… now we’re on the same page. It’s a pretty simple gem to set up to boot! Just add it to your Gemfile to get started.

In my example above I was using a Settings constant. Let’s get that created. In an initializer I would create a file settings.rb.

ex: config/initializers/settings.rb

class Settings < Settingslogic
  source "#{Rails.root}/config/settings.yml"
  namespace Rails.env
end

That was easy! We’re just telling Settingslogic where to look for our config file and how to figure out different namespaces. Namespacing is key here because it allows us to have different setting entries based on environment. Now you are able to enter test keys for your payment gateway instead of the live production keys.

ex: config/settings.yml

defaults: &defaults
  use_online_storage?: false
  aws:
    access_key: longstringofchars
    secret: supersecret
    bucket: immabee-usin-settingslogic

development:
  <<: *defaults

test:
  <<: *defaults

production:
  <<: *defaults
  use_online_storage?: true

Now the fun part… lets use this bad dog. Say I want to upload some files using the fantastic Carrierwave gem. This is about how your settings would look like.

ex: config/initializers/carrierwave.rb

CarrierWave.configure do |config|
  config.fog_credentials = {
    provider: 'AWS',
    aws_access_key_id: Settings.aws.access_key,
    aws_secret_access_key: Settings.aws.secret
  }
  config.fog_directory = Settings.aws.bucket
end

Notice how I’m just gaining access to my settings via the Settings constant using what appears to be method chaining? Pretty cool, right? This is not really a new concept, I just think Settingslogic encapsulates this functionality well.

If you peek back up at our settings.yml, you should notice that the method chaining maps cleanly to the nesting of the YAML file… easy peasy.

That’s pretty much it. Now, funny thing, the reason I started writing this article was to show you some tips I found valuable. Thought I should set up the article with an overview of Settingslogic so we’re all on the same page.

If you had the above code implemented and tried to start your server or console you will most likely hit a brick wall. By chance you were following along… this may look familiar:

uninitialized constant Settings (NameError)

Gross, right? What the hell is it talking about? If you were to use the Settings constant anywhere else in your app this would probably not be a problem. This issue has to do with the order in which files are getting loaded in our app. We’re trying to use Settings before it has been evaluated.

I hit this wall a lot because a lot of times the reason I want to use this method is to cleanse my initializers of data points that shouldn’t be stored as part of my app like various api keys.

Rails loads initializers top down in alphabetical order. This should be no surprise that the ‘s’ in settings.rb is coming after the ‘c’ in carrierwave.rb. ‘That sucks!’, you say? The fix is pretty simple, you just need to think out of the box a little. Just rename your settings.rb file to _settings.rb. This now reorders its place in the alphabetical listing and allows the Settings constant to get loaded before your other initializers.

Hooray, settings goodness can now be had by all!

Digging for XPath Treasure using Chrome

I was never a fan of using XPath in my cucumber step definitions… mostly because I didn’t really understand how it worked.

Recently I had the chance to work with some people that use XPath way more than I do and I extracted this nugget of info from them. (Thanks John!)

You can use $x in the Chrome javascript console. No extensions needed.

$x("//img")

I’ve seen a few questions on StackOverflow about this and all the answers related to installing a chrome extension. I thought it was definitely worth writing down.

RVM Ruby Install on Lion Got You Down?

After a fresh install of OSX Lion, RVM decided no more of my ruby friends could come over and play. So I was all like “what’s up, RVM… y u no like my ruby exchange students anymore?”

Turns out Lion made some changes to what default compiler is getting used which makes building ruby via RVM unhappy. After some searching, the fine folks over at StackOverflow are full of win again.

Here is the solution that works for me:

CC=/usr/local/bin/gcc-4.2 rvm install <ruby version>

It was recommended that the CC variable declaration could be put in your profile reducing the need to enter it every time, but I’m uncomfortable just blindly making that change. If this is the only time I need to do this, I think I’m OK with it.

We are Family

For those of you who regularly read, or at least know me, know that I work/ed for a software development shop in Chicago called Obtiva. And if you knew that then you almost certainly know that Obtiva was recently acquired by Groupon.

Obtiva has a weekly get-together back at homebase called Geekfest. This is where everyone piles into one spot for some food and, more importantly, discussion about new technology, programming principals, or anything else that we’re interested in. Yesterday marked what may be the last Geekfest in its current iteration. I’m sure it will live on in a new home but that is a discussion for a different day. It seemed the perfect time to have a retrospective of Obtiva as a whole. Many things were said… some old, some fresh and new, some enlightening, and almost all humbling.

This is where my story begins…

Out of all the things that were said, to me, they all tied to a singularity. And that to me that was family. So I’d like to share with you what I shared with others yesterday.

Something I want to carry forward into our new adventures is the idea of family. Not necessarily my own little personal family where work/life balance comes into play but the family that is Obtiva. If you are from a large family like me then you already know that there are members you are close to, some that are more distant, and some that you may not care to interact with. At times everyone of us in that room can fit into one of those categories.

There are things that we share with each other that go beyond a work relationship. We share our triumphs and failures. We’ve laughed, been stressed, and have cried together. I know you guys have had my back for many moments during my time at Obtiva and you should know that I’ve got yours. I am comfortable saying that everyone in that room is my family.

I am scared that something like that could get lost in translation with a move to a larger company. I figure that you can only scale family so much before it becomes a community of strangers and that would be a HUGE loss.

This attribute of Obtiva has set the bar for me when looking at any other company, development related or not. If/when my time with Grouptiva comes to an end, this is THE quality that will be looked for and will make or break opportunities.

My name is Matt Polito and I have a hypenated last name of obtiva

We are obtiva… we are family.

Step Into My Breadbox, A Tale of Money Lost and Knowledge Gained

Before starting with Obtiva a bit ago, I started a toy project called Breadbox. It was a project started mostly out of necessity. At the time I was freelancing and didn’t want to pay a monthly rate for invoicing software, so I did what software devs do… I built it. The project evolved slightly as it started moving toward a platform that I could sell as a service myself. I thought I really had something going because at the time there wasn’t many players in that space besides Blinksale & Freshbooks. Unfortunatly, while I was plugging away at building my very own piece of software as a service history… some new players came around. There were many but the ones closes to my work were Ballpark & Curdbee.

Curdbee, I felt, was my biggest contendor as at the time they were closest in featureset and had the same idea of free/very low priced options. Although Ballpark frustrated the crap out of me. They had design to drool over and many features I had ‘invented’ in my head. I guess there probably isn’t a lot reinvention going on in the simple invoicing space but I thought they were good ideas and Ballpark was already on their way to implementation. This was frustrating but and I wanted to give up many times but kept plugging away.

Breadbox served my purposes well and I ate my own dogfood right up until today. I’ve realized that I just don’t have the time to put into the project anymore and would like to make sure you all know there is a decent project out there to dive into.

There are many reasons i’m writing to you today. The two main reasons are as follows.

I want Breadbox to have a good home. It has been been open-sourced for a while but I don’t really advertise that. I feel there is a good codebase of clean code and also many pitfalls, but I learned A LOT along the way. I’m hoping that some developer hunting for a project to work on might take a look and give Breadbox a little love

I want to share my experience with anyone that will listen. There are so many stories of success but hardly any of failure, or at the very least, failure to launch. Even though I did not attain my goal of launching a service to make some extra cash with, I gained a wealth of knowledge that as I look back was invaluable. So on the surface it may appear a failure, for me, it was a huge success. Devs in general, but mostly the more green developer, out there need to understand that there will be sooooo many projects that you start and throw away… and that’s OK. Throw them away and then start all over again. The nice thing about code is that you can always write it again with your newly gained experience.