Corey Donohoe - atmos.org

My talk from POSSCON 2011

2011-03-29T00:00:00-07:00

POSSCON 2011

I posted my slides from POSSCON. The goal of the talk to let student and educators know that school alone isn't going to prepare you for real world software development. A few people came up to me after the talk and said "I don't know what school you went to, but I could program when I graduated." When I asked him if he knew how to write software when he graduated, he paused and then he smiled. I don't think Open Source or Education alone will prepare you, but I really think they help. Here are my slides.

Posscon2011

View more presentations from atmosorg

The Geek Talk Interview

2010-12-13T00:00:00-08:00

Interviewed by The Geek Talk

The folks over at The Geek Talk posted an interview with me. It’s considerably more informative than my current about page. They’ve also interviewed a bunch of other people doing awesome shit recently too. The format is pretty simple and it’s nice to find out a little more about people doing amazing things.

Joining GitHub

2010-08-30T00:00:00-07:00

Joining GitHub

Today is my first day at GitHub. I’m not gonna lie, it’s a little intimidating working alongside these amazing people:

I use GitHub daily. I love open source and have for about a decade. I love the ecosystem that exists around sharing code for both teaching and learning. I believe GitHub will continue to grow over the next few years and I’m abso-fucking-lutely delighted to be a part of something I feel so passionate about.

I’m hoping that they’ll keep me around for a while. :)

On Leaving Engine Yard

2010-07-31T00:00:00-07:00

So I quit working at Engine Yard

I talked to my boss yesterday and explained that August 13th would be my last day at Engine Yard. A whole lot of crazy shit has gone down at work over the past few months and there’s a few more amazing things they haven’t announced yet. About a year ago I packed up all my shit and moved to SF because the company was in really bad shape. Things have been shaken up recently and Engine Yard is finally back on track to becoming a great company.

As an early employee I was privy to a bunch of stock that has, for the most part, vested. So in the choice of “wait out for the last 25% of my stock” vs “moving onto something new and exciting,” I’m choosing the latter. 3.5 years is a long time to stay at any job, and I want to be a part of something new.

As we grew from fewer than 10 people to almost 90, I’ve seen a lot of organizational restructuring. I really don’t want to work in a corporate environment, and I have for the better part of a year. A corporate environment is pretty unavoidable if you’ve taken as much VC as EY has. It’s something I’ll think long and hard about if I ever find myself building a company that is going to take venture capital.

However, I’m grateful to have been a part of such crazy growth with so many amazing customers and co-workers. I’ll miss my coworkers more than anything.

The AppCloud Team

The people working on the appcloud product are the best team I’ve ever been a part of. It currently consists of these members:

They’re pretty much the shit. They’re also hiring if you’re interested.

Where I’m Going

I don’t actually have anything lined up. I know I want to work less, so I’ll prolly do some contracting for a while. I’ll be available for contract work starting mid August. Holler at me if you’re interested.

Constantly Shipping Refactorings

2010-07-28T00:00:00-07:00

Constantly Shipping Refactorings

Recently, two of my favorite hackers, Martin and Tim, have been working on a pretty big refactoring in cloud. In the past our team probably would’ve worked in a topic branch for a few weeks, followed by a painful rebase/merge, followed by a deployment we really hoped we got right. Since this refactor requires db schema changes, we’d prolly have to take the site down for at least a few minutes to do it. They didn’t want to do it this, so they approached the problem in a new way (to us). Here’s what they’re doing.

Unicorn and Zero Downtime Migrations with DataMapper

We moved to unicorn the other month and have found the 0 downtime deploys really liberating. If something is ready to go out to customers, we ship it. We have no planned day of the week or time of day that we ship. On weekdays we normally ship 5-6 times a day and no one ever notices. DB schema changes currently make things a little more difficult. When you add a new model, you create a migration for it, and you ship the model with the migration. This is where Martin and Tim tried something new. Instead of coupling the migration and the model addition, they’re doing the migrations before the model is introduced to the system.

Adding a New Model

So the other day they added a new model, let’s call it User. When they wanted to introduce the User model, they did it in two releases. In the first release they shipped a zero downtime deploy to add the users table. The first release didn’t take advantage of the user model, it was just a normal deploy with the migrations running AFTER the unicorn processes had restarted. In the second release they shipped the User model in another zero downtime deploy that actually started USING the users tabel. Adding a table is pretty trivial if you think about it, but what about removing a column?

Data Transformation/Migration

Have you ever had to rollback a deployment that had data migrations? You need to go find your latest database backup, restore that, extend the outage you took because you hadn’t planned on things going south. It’s insanely stressful and makes you look like a jackass to your co-workers. Your customers won’t like it either.

Removing a Column from a Model

Let’s say that during the refactoring they discovered some insanity in our system: tokens in two places, one on the User model and one on the associated class Customer. First deployment they tracked down all the places where the attribute, in this case ‘token’, was accessed directly and removed it.

Here’s an example of the User class before the changes:

class User
  include DataMapper::Resource

  property :id,              Serial
  property :token,           String, :required => true,
  belongs_to :customer,      Integer

  def valid_token?
    token == some_token_verification_method
  end
end

Here’s an example of the User class after the changes:

class User
  include DataMapper::Resource

  property :id,              Serial
  belongs_to :customer,      Integer

  def valid_token?
    customer.token == some_token_verification_method
  end
end

When this code deploys, the User table still has the token field. Shortly after that, they shipped another release with a migration that only removed the newly unused column. Again, 0 downtime. Guess how we do tables? The same way.

Renaming a column

Renaming a column is kinda weird because it takes 4 deploys. On the first deploy, create the new, unused column. On the second deploy, introduce code that starts using the new column and denormalizes the attributes as they’re accessed. This deploy also carries a zero downtime migration that copies the attribute over to the new column. All access to the attribute is now directed to the correct column. On the third deploy, remove all reference to the old column. Finally on the fourth deploy, nuke the old column after the deploy completes. For an example of how the new column usage works, check this snippet out.

class User
  include DataMapper::Resource

  property :id,              Serial
  property :token,           String, :required => true,
  property :tos_accepted,    Boolean, :default  => false
  property :admin,           Boolean, :default  => false
  property :administrator,   Boolean, :default  => false

  timestamps :at

  def admin
    value = attribute_get(:admin)
    value.nil? ? copy_admin : value
  end

  def admin?
    admin
  end

  def copy_admin
    unless update(:admin => adminstrator)
      raise "Could not save user: #{errors.full_messages.join(", ")}"
    end
    admin
  end
end

It’s so simple, who cares?

One thing I really love about this is the guys are constantly shipping incremental improvements. There won’t be an evening where they’re forced to work late to ship out their schema changes. You’ll never hear them cursing other developers for introducing changes that mess with their refactoring. Even though they’re focused on a very large refactoring, they’re never a few days off from having something to show. You can watch their progress as the commits flow by. They never entered the mindset that it’s ok to get lost in refactoring wonderland. Solving a problem elegantly doesn’t mean you have to go sit and think up the most beautiful solution ever. Break it down into little pieces and ship ‘em.

Tim, Martin, and I are in the process of automating these kinds of rollouts. We’re testing it right now.

Hiring

We’re also hiring right now. Send me a message on github if you’re interested in working with a top notch group of hackers.

My talk from Red Dirt Ruby Conf - Rise of Devops

2010-05-07T00:00:00-07:00

Red Dirt Rubyconf

I posted my slides from red dirt rubyconf. It's about the devops movement that's been gaining a lot of momentum in the sysadmin circle. A lot of people at the conference asked me about the source of the images in the talk, they're from blackandwtf.tumblr.com.

Rise of devops

View more presentations from atmosorg.

Red dirt was a pretty damn good conference. The format was different than I'm used to and I believe it worked out quite well. It basically took 4 speakers on similar subjects, the first speaker had a 30 minute talk, the last 3 each had 15 minute talks. During the talks a moderator, @jeg2, collected questions in the IRC back channel and the presenters would answer the questions after everyone finished their talks. The location was good, the food was only second to @alohaonrails, and the vibe of the attendees was overwhelmingly positive. The only negative thing I have to say is that the talks are going to be sold instead of shared, I'm a big fan of sharing.

I really wish conferences would just stream their talks and think of the conference as an experience for the attendees, making it more than just the talks that are valuable.

My talk from Aloha On Rails

2010-03-21T00:00:00-07:00

My Aloha on Rails talk

Everything I Know About Being an Open Source Hacker I Learned From Indie Hip Hop - Corey Donohoe from Aloha on Rails on Vimeo.

SF bound and down, upcoming talks

2009-08-22T00:00:00-07:00

SF bound and down

I’m moving again. As much as I love Boulder, I’m moving to SF to be closer to Engine Yard. After years of telecommuting I find myself wanting to work with people in person more and more. Boulder is, and probably will remain, ‘home’ to me now. I don’t want to leave but joe arnold has really created an attractive environment in SF and it’s the type of development environment I feel that I’ll learn a lot from. Boulder is probably the most inspirational place I’ve ever lived. From the spiritual folks to the athletes to the artists, the community is vibrant, creative, and caring. I’m really gonna miss it. :‘(

I’m going to be speaking at three conferences over the next few months so I figured I’d mention them here.

I’m going to be speaking at the ruby hoedown in August on “how to be simply awesome.” It’s basically a run down of how halorgium and I are winning on the regular. Unfortunately I won’t be there for the full conference because I’m catching a plane to Austin later that night.

The next day in Austin I’ll be presenting at Lone Star Ruby Conf on the same topic with a slightly different title. I’m hoping my connecting flights allow this to happen because I’m pretty excited about the subject. I just gave the talk internally at EY and it needs a little work but I think I finally understand how to present the topic to people.

I’m speaking at a conference in HAWAII, aloha on rails. I’m doing a talk on open source software and independent hip hop label’s evolution over the last decade or so. I’m gonna do my best to not come off like a marketing douche bag, but I’m going to present a bunch of similarities between open source craftsmanship and successful indie rappers. You should go come! I’m hoping to get some surfing in, let me know if you’re interested!

hoptoad for rack

2009-05-15T00:00:00-07:00

Rack Hoptoad

So Tim and I were talking about how we needed hoptoad for our rack apps the other day. This rack hoptoad notifier should get you going for rack and sinatra. Raise issues on github if you run into problems. :D

If all you want to do is install the gem you can install it like this:

% sudo gem install rack_hoptoad

as time goes by : blabbing 'bout sinatra

2009-05-15T00:00:00-07:00

Sinatra 0.9

Justin Smestad invited me up to factory labs to talk about sinatra recently for one of their brown bag lunches. He recorded the talk from his laptop and I’m amazed you can see or hear me.

My slides aren’t sync’d up but they’re here.

Sinatra 0.9 – Corey Donohoe

Hancock-Client-Rails : Using Sinatra/Rack Middleware in Rails

2009-03-23T00:00:00-07:00

Hancock-Client-Rails: Works with Rails > 2.3.x

Recently I’ve been writing a bunch about sinatra as middleware and one of the things you always hear people glorifying is how rack middleware can be dropped into any framework that’s built on rack. Since I’m trying to get people to try hancock out, or atleast learn something from it, I figured I should investigate how you actually use the hancock-client sinatra app inside off rails 2.3.2.

One of the examples I’ve seen in quite a few presentations on using middleware in rack has something along the lines of:

Unfortunately, I’ve yet to get a sample like this working with sinatra middleware. For some reason sinatra always throws 404 errors instead of allowing those requests to pass through to rails. Even if I set “disable :raise_errors” in my sinatra app, it’d still throw 404s. So after a little googling I discovered a wonderful write up over at the rails on rack page. I definitely learned a lot about how rails middleware works but I still couldn’t get my sinatra app functioning properly inside of rails.

I was kind of surprised to find out that there was very little documentation on using sinatra as middleware. Sinatra is awesome for this, how could I be the first person trying to do this? It turns out that I wasn’t. :) Raggi had explained how to do this to someone in #rack on freenode a few days earlier. I looked through his gist on how he did it. I didn’t understand it all but I hadn’t tried using the metal generator that rails introduced recently. So I gave that a try and ended up with a piece of rails metal that looks like this.

This actually worked perfectly for me. All I needed to do was make a subclass of Hancock::Client::Default and set the appropriate configuration options. Next I gave myself a little helper in application.rb to check whether I was logged in or not, you’ve probably done something like this in every other app you’ve ever used.

Then there’s a simple controller that should be protected by the SSO middleware.

That’s pretty much it, hopefully this will save you some time. One thing that I’ve noticed in trying to make this work with the larger frameworks is that I really want some sort of implicit before filter. I’d really like to have the redirect to ‘/sso/login’ happen anytime an unauthenticated request comes in, I’ll try to get that working in the next release.

I’ve created an example application that I’m hoping to keep up to date as hancock grows. There are git tags that match up to a hancock release number as well. If you want to see a rails client in action you can run “rake features” inside of the hancock-client-rails application. You’ll need to be on a mac due to the safariwatir constraint but it should drive your browser and complete a full handshake against the hancock sso sandbox.

Hancock-Client : Sinatra Middleware

2009-03-22T00:00:00-07:00

Hancock-Client: Middleware

With the release of sinatra version 0.9.1, programmers have the option to write micro-apps that double as middleware in any other rack enabled application. The beauty in this is that you can write rack middleware without getting bogged down in the details of writing rack directly. Perhaps it’s your first time leveraging rack and you want to test the waters or perhaps you’re just wanting to slap a little bit of functionality onto someone else’s code; sinatra is emerging as a great way for folks to start really sinking their teeth into how rack functions.

I recently found myself waist-deep in rack. A lot of my co-workers at EY have been telling me for some time where rack made sense and where it didn’t. I didn’t really grasp it all. I understood it as a concept but there was nothing in my day to day work that made me say “Hey! I’m gonna use rack here!” At least until the other day. Jon Crosby rocked out with a great talk at MWRC and one of my friends at work had written a little sinatra app that we needed to merge into our Single Sign On(SSO) infrastructure. Tim took advantage of an existing rack openid library and made the necessary modifications to hook it in cleanly, he then went on vacation and left the gem abstraction to me. I’m really grateful for this because it really made me sit down and acquaint myself with sinatra. What I found was something pleasurable, elegant, and useful.

The hancock-client gem is an abstraction of our rack based SSO middleware in use at Engine Yard but modified to communicate with the hancock sso server. The gem provides a sinatra application that can be run as a standalone application or used as middleware in rails or merb. The application itself encompasses all of the logic required to negotiate the SSO protocol with a provider and populate session variables. You can pretty much expect that the sinatra app provided by the hancock-client gem will integrate well with a hancock provider of the same version.

So when I started trying to get the middleware going I decided on three things that were necessary for it:

you need to be able to login
you need to be able to logout
after you login you should be greeted

This makes sense for the simplest possible consumer that does something useful. The login and logout actions are mapped to /sso/login and /sso/logout respectively. Does the “after you login you should be greeted” step really make sense for middleware though? I feel like the answer is no in this situation and it’s where the beauty of rack really comes to light. Since my code shares the same rack session that my framework code will share, maybe I should leave that greeting page up to the app that’s using the middleware.

The SSO middleware handles the authentication earlier in the stack than your framework and all you need to do is rely on a set of conventions that the middleware provides to the framework layer. In the case of hancock-client it sets the :user_id session variable. Depending on your middleware ordering this happens way before your framework is hit. The basic approach for the initial release of hancock-client went something like this, “only implement login and logout but provide examples of how you might use it in your framework of choice.”

What we created was a class that inherited from Sinatra::Default called Hancock::Client::Default. This class was created with the idea that an application developer would inherit from it and implement the greeting page at “/”. So in its simplest form you can implement a hancock-client app in the following fashion:

Notice how the middleware can be extended to support requests to / in sinatra with ease and you can simply let those requests pass through in frameworks that implement them at a higher level.

Notice the usage of the configuration option sso_url. You need to set this to the url of your SSO server. If you ever need to reference this in the markup it’s available as options.sso_url.

If you’re using this as middleware in other frameworks you’ll have to make sure that you set disable :raise_errors on your Hancock::Client::Default subclass. Otherwise you’ll get 404s and that’s kind of annoying. Checkout raggi’s gist too.

Believe it or not, the standalone sinatra apps are hella useful. I love when we want to try out some new 3rd party application that offers remote authentication and we can hook the two apps up with a simple sinatra app in no time. Seriously, do not disregard sinatra as a possible solution because you think you might need big feature X in framework Y. Maybe you shouldn’t extend that monolith app that’s getting more complex by the day. Maybe some micro-apps will be just what the doctor ordered. I might be crazy or living some sheltered developer lifestyle, but it is a pleasure to write sinatra code.

If you investigate the tests in hancock-client you’ll find that there aren’t many unit tests. I think there’s 2 and one is currently pending. If you checkout the cucumber tests though you’ll find safariwatir tests that drive your browser and test against the hancock sso sandbox. All you need to do is investigate the examples/dragon directory in hancock-client and run the following command.

% rackup -p 4567 config.ru

In another terminal you should be able to run the following:

% rake features

A browser should appear, you should see that you successfully signed up for an SSO account, and that your consumer application has access to a few session variables. I chose safariwatir in this case because it allowed me to blackbox test the appserver and I chose cucumber because I was pretty sure I could copy this functionality over to merb and rails as I created examples for those frameworks. If you’re on a mac, please try to run these specs and let me know if they work for you.

One thing that I’m really hoping to handle in the next release is the ability to make the SSO before filters in rails/merb a thing of the past. I actually need to get the merb example working… If any of this interests you, you’re welcome to fork my projects on github or hook me up with patches.

Hancock : A Single Sign On Server in Sinatra

2009-03-20T00:00:00-07:00

Hancock: SSO

A while back I blogged about the flatirons openid provider and how it was inspired by something we were doing at Engine Yard. We needed a single sign on provider and chose to use OpenID as the sso protocol. Since this is heavily influenced by openid I will often use the word “provider” to describe an SSO server. I also use the word “consumer” to describe an SSO enabled application.

So we pretty much drew up a diagram of how openid works and removed the steps we felt were unnecessary(decision/acceptance steps). We then extended it by adding auto discovery of the openid url. Here’s a somewhat up to date diagram that shows off how things work. You’ll notice that the user-agent(browser) never specifies its identity url, it’s automatically provided from the SSO server.

I’m pleased to announce a new piece of software that might interest you if you need a single sign on solution for your projects. It’s called hancock and it’s available(like all good things) on github. Here’s a quick run down of what it offers you:

a rubygem that provides all the functionality you need for an sso server
an sso server as an extendable sinatra app, aka rack middleware
a required whitelist for consumer application access
configurable sreg response parameters to customize what information is exposed to clients
can hook into anything that datamapper supports as a user/consumer store.
trivial deployment as a rack application under passenger
simple user signup with email verification
application sessions don't overlap by using .domain.com style cookies

This is all implemented in about 400 lines of ruby code using the sinatra framework. With the release of Sinatra 0.9.1.1 programmers can write sinatra applications in a more modular fashion. The killer feature is that these modular applications are actually rack applications. This allows for services to be written in sinatra that can be deployed as either a standalone rack application or used as middleware in frameworks like merb or rails. Hancock is an example standalone rack application. I’ll be blogging about sinatra as middleware in the days to come.

Hancock requires that you provide atleast three things to get it going. This is normally provided in your rackup file.

database connection info, specifically the datamapper connect string
mailer info
a custom layout file

Hancock assumes that you’re going to provide the layout that gives your site its customized look and feel. The hancock gem itself provides all of the forms for authentication. If you’re going to be serving static assets like images, stylesheets, or javascript files you’ll also need to set the public attribute. Here’s what my rackup file looks like on my server.

That’s your whole app.

The Hancock gem provides a sinatra application as a class named Hancock::App. You should inherit from this class and implement a landing page at “/”. The mailer configuration functions a lot like the merb-mailer gem, if you’re having issues google around for merb-mailer help.

The Hancock gem also provides a class named Hancock::Consumer that represents a consumer application that is to be accepted by your hancock application. The :url attribute MUST match up to the return_to parameter in the openid negotiation. If you’re using the hancock-client gem then it should take care of this for you. The main thing to remember about this class is that if you ever receive the Forbidden message on your SSO provider you should double check that the host is allowed to access the provider.

Your user model is exposed as Hancock::User. Right now there is simple sign up through web forms. If you want to test the provider without setting up the full email configuration then you should run your application in development mode. When run under development mode the registration url that would normally be sent via email is embedded as a comment. I found that it made it really easy to test.

The Hancock gem doesn’t have perfect tests, but I’ll be damned if we aren’t shooting for it. You’ll find both unit and acceptance tests done in rspec, rack-test, webrat, and cucumber. Even if you’re not interested in an SSO server the tests might help clarify a few things if you’re a testing junkie.

As I mentioned earlier, the killer feature of sinatra 0.9.1.1 is that sinatra apps are modular rack applications. While hancock is a pretty cool example of the power and simplicity of sinatra; its use as middleware in other frameworks is where I expect to see sinatra shine for the foreseeable future. Even if you’re stuck on a never ending rails project with no chance of innovation in sight, go learn about rack. I think you’ll be surprised where you can start leveraging it. Besides, writing sinatra is fun.

So what good is a simple SSO server if you don’t have a super simple client library? I bet if we did it as a simple sinatra app then we could turn it into middleware. Then we could hook our rails and merb apps up. Yeah, that’d be sweet.

I’m gonna follow this up in the next few days with something covering the hancock-client gem. This gem provides a sinatra application that can be run standalone or as middleware in other apps. I’ll prolly follow that up with two short articles on “how you get your middleware running in (rails|merb).”

Considerations for Creating a Test Driven Ruby Project

2009-02-01T00:00:00-08:00

Creating a TDD Ruby Project

Where this comes from

I’d originally wanted to do something like “how our group at EY specs things” but I feel like a lot of these ideas extend beyond the merb/rspec/datamapper bubble we currently develop in. When I went through the Integrity source code a couple weeks ago I realized they were doing the same things, but with sinatra, context, and matchy. I found it really easy to understand the integrity test suite because it was setup in a wonderfully sane manner. I figured I’d share a few thoughts on it since I’d like to see more projects testing things like this. There’s nothing earth shattering here, In reality though, few projects I come across embrace developers to collaborate and enhance. If you consider these things while creating your project, I promise, you’ll be in a much better state to collaborate.

Here’s a few things that stick out in my mind:

You should have a README that tells another developer how to get up and running
You should really be testing, even if it's after the fact
Name Your Tests/Specs after what it does
Be able to toggle mocks and integration tests easily
Use GitHub
How will this commit affect Continuous Integration?

You should have a README that tells another developer how to get up and running

If some random person needs to add a feature or fix a bug in your software, they’re prolly going to have to do some setup. Maintain this README. The easier it is to get a system bootstrapped to start developing and enhancing the software the better. The old timers can send you a patch via email, the new schoolers send you pull requests. Let other people do some of the work for you. Even Dr Nic thinks it’s a good idea!

You should really be testing, even if it’s after the fact

I don’t care how fucking smart you are, software maintenance isn’t easy. I’ve seen folks argue that unit testing is fail, I’m starting to agree when it comes to the web. I’m finding that if you’re actually writing tests as you’re completing user stories you naturally exercise your models. With a code coverage tool like rcov you can really tell which portions of your models are being exercised fully. If you know your stuff then you know that rcov coverage doesn’t really mean ALL that much, but it helps. You can then use a mutator like heckle or boo hiss to cover your ass for the rest of your cases. We normally employ the mutators after we’re happy with the state of the software, it helps us prepare for handling weird errors in a more graceful manor. You don’t have to go so far as to running mutators on your code, but you should really really be testing. If you don’t have time to test code, perhaps it’s time for you to TAKE THE TIME to learn how to do it. Your co-workers and friends will thank you for it, I promise. Even if you develop software by changing code and refreshing your browser or running your script over and over, you owe it to your collaborators to let them know what portions of the code are important and what will cause major breakage if it changes. By not testing you’re saying “I really don’t care whether or not this project lives a long, happy life.”

Name Your Tests/Specs after what it does

At the first railsconf I remember srbaker talking about rspec and how much he hated the way rails generators generated test files. He told me something along the lines of “when I need to create a new spec I make it based on what it’s for.” I didn’t really understand him at the time, I was still learning how to test via the rails framework.

In the images above you can easily identify what functionality has tests. It annoys me to death when I open up spec/controllers/ and find specs named after classes. They might be empty or they might be a giant file testing all of the functionality of the class in isolation, both cases suck. I’m becoming more and more fond of just creating a spec file for a user story as I implement it. In the web space I think you should investigate webrat, you can use it with merb, sinatra, or rails. You’re basically writing acceptance tests that’s like a fake browser request with persistent sessions. Name your acceptance tests according to what they validate and you’ll be in business.

Be able to toggle mocks and integration tests easily

We recently did a bunch of stuff with braintree for some payment processing. They provide a pretty awesome test environment for you to test against. I wrote a whole bunch of specs that faked browser requests to the API server and I found their docs to be incorrect. Their examples worked but once I got down to requiring CVVs and address verification, the response hashes came back inconsistently. By really testing the requests/responses I was able to dm this really awesome ruby developer on twitter and resolve the issue in a day or two, long before we ever went live. If we’d generated mocks based on the documentation alone we would’ve gone live with a broken system. You could argue that it’s braintree’s fault and they should have correct documentation, but I’m not a big fan of finger pointing. Finger pointing doesn’t accomplish a damn thing when you just launched a site and it’s not completely functional. We’ve started shooting for something along the lines of “only mock things out if we can toggle a real integration test.” Some of our apps could really use some mocking help, but the speed hit isn’t really that big of a deal when you know it’s really running against the remote service. Of course my friend Tim has some ideas about mocks too.

Use GitHub

I use git, my homies at GitHub get it. It’s all I’ve been using since February of 2008. I really can’t say enough good things about github, it really simplifies things when collaborating on software.

How will this commit affect Continuous Integration?

You do use continuous integration, right? Continuous Integration is just a remote machine that runs your test suite every time someone pushes code. I use Integrity, some of my friends use cc.rb. Integrity works really frackin' well with github, all of my code lives there so it makes it that much more attractive. If I push some code, how will my CI task handle installing any new dependencies I introduced? Will my co-workers want to punch me in the face because half of their day was wasted tracking down some shit I committed? How well do these changes work outside of my machine? This is stuff that you really want to consider when you collaborate.

Collaboration is King

Collaboration keeps bubbling to the surface here. Perhaps I should change the title. These suggestions have little merit if you’re not interested in collaborating on software. If you’re not interested in collaborating on software though, you’re going the way of the dodo. Think of all the awesome techniques you picked up from working with other people. Think of all the projects you tried to use or hack on but couldn’t because you couldn’t get it working. It’s up to you to make your projects easy to collaborate on.

So, what’d I forget to mention?

Merb and Rails Sitting in a Tree

2008-12-23T00:00:00-08:00

Rails and Merb Merge

Who’d have thought? In case you didn’t know the two powerhouses in Ruby Frameworks are going to start working together to make the world a better place. This brings up a lot of emotions for me and gives me hope for the community.

4 years ago I spent my christmas holidays rewriting my php based weblog in rails, this new and crazy framework where you wrote less and did more. At the time I was a Solaris administrator in Georgia and the programming job landscape was primarily Java, C#, and PHP. I didn’t really want to write in those languages so I stuck to something I did enjoy, UNIX. Over that holiday season though, I really fell for the Ruby language. Not just the language but the community that surrounded rails at this time was nothing short of magical. This was my first introduction to entrepreneurs in the web space and it seemed like every new person I met in this community was just awesome at life(and hacking).

So rails took off and a lot of us got busy. A lot of us wrote software that never saw the light of day, others wrote stuff that made the world take rails seriously. I was lucky enough to be the first technical hire at Engine Yard and the growth that we’ve seen is inspirational. Not only did we target the “premium rails hosting” market and excel at meeting and exceeding our customer’s expectations but we made it clear that we love the Ruby community. We hired Evan Phoenix and Yehuda Katz to push the ruby interpreter and the merb framework respectively despite the fact that there was no immediate financial benefit.

So I’m sitting here avoiding work by writing this blog post, but I’m just so freaking excited by this merge. I’m delighted to know that our community can still surprise me, that folks can work together, and the future of ruby in the websphere is looking good.

Much respect to the merb and rails teams for making this happen. Thanks, a lot.

Merb 1.0 Controller Testing

2008-11-29T00:00:00-08:00

Merb Request Testing Evolved

This was originally going to be part of “testing flatirons” but it got kinda long and I felt it’d be most useful to community if I made it a standalone article. I’ve had the pleasure of experimenting with everything I cover in this write-up, and the state of merb’s testing environment is getting better. Since merb is at 1.0 these days this rundown should be valid for at least a few more months. I’m gonna run through what I know about how you test in merb, and in the next few days I’ll dissect flatirons. Here’s what I’ll be covering in this write up:

Request

dispatch_to
get/post/put/delete
request

Requests with Authentication

dispatch_to / http verb tests
requests w/ given blocks

RSpec Matchers FTW

have_selector
have_xpath
Roll Your Own

1.1 dispatch_to

This method allows you to unit test controllers. It also makes your co-workers cry, swear to kill you, and rewrite your code.

It seems harmless enough. dispatch_to takes 4 parameters and an optional block. The 3rd parameter is the actual params hash that the action will see. The 4th is your http environment and how you modify things like HTTP_ACCEPT to change content type. When you call this method it instantiates the Class and calls the Action with your http params, you bypass routing and have the option to stub/mock to your heart’s content. The response from dispatch_to returns an instance of the class, in this case it’s the Sessions controller. The response also has a few instance methods that might be useful to check in your testing:

#status – the http response code
#body – the document returned from the action
#headers – the http headers returned
#session– the session for the request

In my experience dispatch_to leads to really brittle tests when things start to get a little more complex. While I’m a HUGE fan of rr, I’m finding that mocks are mostly complicating my day to day work. I wanna see my code work from beginning to end, even if it means my test suite takes a little longer. The merb-core team advises against using dispatch_to. If you’re going to be using merb for the foreseeable future, do not get in the habit of using this. Seriously.

1.2 get/post/put/delete

The standard HTTP verbs are available as request helpers in your test environment too. It’s kinda like dispatch_to but it actually goes through the router. Insted of giving a Class and an Action to call, you give the same path you would request in a browser. The optional 2nd and 3rd parameters to this function are the request parameters and http environment respectively. This also has a block syntax that you’ll see later in this tutorial. Here’s what the above request looks like using the HTTP verb helpers.

The response from get / post / put / delete has the same instance methods available that dispatch_to has since they both return the actual controller that was executed.

This is cooler than dispatch_to because it goes through the router and we can make sure that our pretty “/login” url is properly configured in the router.

1.3 request

request is short and sweet. It’s a programmatic browser experience of sorts. At first glance it doesn’t seem much better than get but it actually preserves states between a series of requests. We’ll see why this kicks ass later in the tutorial. Here’s how you display the login form with the request helper.

The response from request is a struct that provides the following instance methods. In general I try not to call these instance methods, it tends to be more clean when you write matchers against the response object itself.

status – the http response code
body – the document returned from the action
headers – the http headers returned
url – the url that was requested
original_env – i think this is how stuff persists between requests. I’ve never actually called this for anything.

2.0 Testing with Authentication

2.1 merb-auth and all that jazz

So you’re supposed to be using merb-auth if you need authentication in your app. So how do you test it?

2.2 dispatch_to and HTTP verbs with Authentication

Both dispatch_to and get can take an optional block that allows you to spec and mock things on the controller. If you need to stub out authentication both helpers are easily spec’d like this.

While adding the mocks and stubs might yield some immediate results, it tends to be a maintenance nightmare. You either end up with a bunch of duplicated stuff in each spec or you end up wrapping these methods with things like employee_get/employee_put etc.

Even with this bit of abstraction it becomes a royal PITA to test real use cases. Since each spec tests the controller action in isolation you open yourself up to the possibility of having bugs in your tests that are directly related to keeping your mocks/specs synced up with your real code. “Does the signup process really work from start to finish?” “I don’t really know what that chunk of code does, but I know it returns true or false.” It becomes very easy to bypass chunks of code in certain situations without really understanding how things integrate. The request helper shines bright in this situation.

2.3 requests with given blocks

The request helper allows you to preserve the normal browser experience by making successive calls to request and preserving the user session. So here’s how you authenticate against merb-auth:

It sucks that you had to explicitly call that request to “/login” but it’s kinda nice to be able to comprehend the user experience that led up to the point where the code in question was tested. Someone logged in and then they could view their account settings.

Either Merb or RSpec provide you with this given block to setup pre conditions that the spec relies on. They’re kinda like shared_examples but if you’re using request you can build entire use cases up and attach them to describe blocks. Your session persists between requests, instant WIN! I added this to the bottom of my spec/spec_helper.rb to allow for authenticated requests.

After that your test code starts to look like this

If you’re super awesome you can pass “cookie jars” along with your requests to restore certain states. I think they’ll be really useful in situations where specs start taking forever because of the amount of setup required to get to a certain state. Thus far our specs aren’t taking a long time so I guess I’ll cross this bridge when our spec suite starts taking forever.

One other thing to keep in mind is that your HTTP_HOST environmental variable is http://example.org. So don’t be surprised if you see this popping up in your tests.

3. RSpec Matchers

Remember how both the dispatch_to and request responses have a few instance methods that are useful in testing? Notice that we didn’t explicitly call them in any of the spec examples above? It’s because we’re using the rspec matchers that merb provides. Not only should you be using the ones that merb provides, you should be writing custom ones for your app. Here’s the matchers that I use from merb on a daily basis.

3.1 HTTP Response Checks

be_successful This basically checks that response.status was 200. It was a successful request. :D
redirect This checks that response.status was 302. It’s your normal HTTP redirect code.
redirect_to This not only checks that response.status was 302 but it takes a string for the path portion of the redirection. If you need to check query parameters you’re going to have to write your own matcher. We have one in one of our apps now, redirect_to_with_params that does exactly this, we’re hoping to give it back to the merb community shortly.

Markup Validation

have_selector is what you should be using to validate HTML markup. It allows you to specify CSS 3 Selectors to identify the presence of certain markup. If you’re into that jquery thing, it’s great practice for selectors in js too. Let’s say we want to check for the presence of the ‘Hello World’ string in the following example.

In your spec you’d have something like the following:

It’s pretty straightforward, find the div with an h2 that has the dom id of ‘hello’ and contains the string ‘Hello World’. Now is a good time to review the example specs above, hopefully you can visualize the markup that those specs require now.

have_xpath is the slightly older cousin of have_selector. Instead of CSS 3 Selectors you specify an xpath that should be present in the response document. I’ve gotten in the habit of only using this for XML documents. Let’s see the Hello World example done with xpath.

3.3 Roll Your Own

Rolling your own RSpec matchers is the super pimp stuff. You can cut down on duplication in your tests by coming up with an expressive name for certain situations, their responses, and the markup that’s returned. Here’s a little matcher we wrote in flatirons that handles unauthenticated requests returned by merb-auth.

We put this matcher into our spec/spec_helper.rb file and included it into our rspec environment with the following code.

So that’s about it for the merb controller testing intro. Now that we’ve discussed the basics of testing we can get back into flatirons and talk about how things are tested in that app.

I’m sure I made some errors in here, please offer up corrections in the comments and I’ll try to work the fixes into the article soonish.

Flatirons : A Merb OpenID Provider Part 1

2008-11-24T00:00:00-08:00

Flatirons OpenID Server

What are the flatirons you say? They’re a rock formation near my house in Colorado, they look like this in the winter.

It’s also the name of the open source merb 1.0 based OpenID Provider that’s available on github. We recently started rolling out a customized OpenID Provider for all of our internal apps. Flatirons was how I familiarized myself with the OpenID spec.

The Low Down

I’m going to break this into two parts, one on the OpenID Provider and one on the way we’re testing in merb 1.0. There appears to be a lack of examples on writing specs in the merb 1.0 world and I assure you it rocks way more than it used to. This part will give you a brief overview of what’s really involved in the OpenID protocol. Part 2 will cover testing the spec that’s described here.

Paint a Perfect Picture

It’s not perfect, but it should give you an idea about the request/response life cycle for an OpenID Authentication. Keep in mind that User-Agent in these diagrams is normally a User’s browser. A Consumer is your new micro-app that doesn’t even have a concept of user passwords. The Provider is where flatirons comes into play, it’s the OpenID to Merb layer that allows you to take advantage of merb-auth’s strategies. The Auth Backend is trivial to customize, consult the merb-auth docs for more info. Check it:

Identity Discovery

Identity Discovery is the first part of the User-Agent authentication. The Consumer can request one of three options(the spec) but normally the Provider sends back a Yadis document that lets the Consumer know where to go to start talking that crypto shit with the Provider. This is normally in the form of an xrds+xml response.

Associate

This is where the magic starts. “An association between the Relying Party and the OpenID Provider establishes a shared secret between them, this is used to verify subsequent protocol messages and reduce round trips.”(the spec) The Consumer and the Provider negotiate some Diffie-Hellman keys and use these for communicating for the rest of the auth life-cycle.

Check ID Setup

Check ID Setup covers a few things, there’s a few modes that you should really investigate in the documentation if you’re curious. Suffice it to say there’s two interesting modes that are a part of the id setup, checkid_setup and immediate. Immediate is used less frequently and it’s designed for authenticating in a manner that isn’t interactive(think ajax logins). The checkid_setup mode is way more common, it involves normal http requests, redirects, and pages where you enter your username and password.

Acceptance – “Do you trust me?”

Acceptance is a form on the Provider displaying the specific information it’s going to send to the Consumer. The User-Agent specifies whether or not this information is OK to send to the Consumer. Normally users just click OK here but this is where a full fledged Provider allows you to pick one of many identities you have stored there.

Identity Result

Once the User-Agent accepts the Provider as a trusted source, an identity result is sent back to the Consumer from the Provider. The Consumer can then take this response and do whatever local bootstrapping they need to for the user. OpenID can send back more than just the identity URL, but flatirons doesn’t take advantage of these spec extensions yet.

WTF, Why do I even care?

Since this is based on merb-auth, you have all of the strategies it provides at your disposal. Flatirons defaults to the salted password setup, but you could easily hook this into whatever authentication backend that you need. If you’re considering Ruby applications and need single sign on then this is a good starting point regardless of your user store. In a trusted environment you can make this even more simple, whitelisting can simplify the request/response life-cycle by removing the Acceptance step. Depending on your user store you can mask the interaction with the actual identity URL. We’re able to mask the concept of the identity url a User-Agent uses and we just ask them for their email address. Ours users don’t even know what OpenID is, it rocks.

Where’s the Code

It’s on github of course. In the next couple of days I’ll dissect the specs that validate the expectations defined above.

Merb OpenID Consumer Application based on Merb-Auth

2008-10-30T00:00:00-07:00

Merb OpenID Consumer

We’ve been playing around with openid this week so I figured it was worth spending some time to test the latest merb 1.0 rc.

Say hello to the merb-openid-example app. It is a simple openid consumer application based on merb-auth. One of merb-auth’s built in strategies is openid , getting things going is simply a matter of enabling the appropriate authentication strategies.

This application is intended to run against merb 0.9.12(1.0rc4). Here’s a quick checklist of what was involved in getting merb-auth working with the openid strategy.

sudo gem install merb
setup the merb-auth strategy
add the openid and signup named routes
modify the user model to handle openid attributes
add the ensure_authenticated filter

To setup merb I normally uninstall every trace of merb that’s on my system. The 0.9.x branches tend to conflict if you have multiple merb versions installed. I tend to do the following(note it uninstalls ALL merb gems):

gem list merb | awk '/merb/ {print $1}' | xargs sudo gem uninstall -aI

Then I just install the merb meta package

sudo gem install merb

Setting up the merb-auth strategy requires you to familiarize yourself with the merb/merb-auth/strategies.rb file. In a newly generated merb application this file should setup a salted password base authentication scheme, we want to change it so it looks like the following:

Next we need to setup two named routes that the openid auth strategy will use in order to make the openid authentication happen. I created a separate controller(authentication.rb)

to handle these requirements. All you really need to know about the two named routes, openid and signup, is that signup should not require authentication and the openid route should.

The default user.rb that you get from merb-gen will need a few minor adjustments to work with openid. First you’ll have to add a few attributes if you intend to cache them locally, and after that you’ll need to disable the password validations that are automatically enabled by the salted password strategy(even if you disabled it). My user.rb looks like this.

Once all that’s done you should be able to just throw the before filter into your application.rb and you’ll be ready to start using merb-auth with the openid strategy.

The example application works outta the box, just run the merb command. It also has specs which show off a bug that still exists in rc4 where controllers are not honoring :only/:exclude parameters that are passed to before filters.

I’d like for this to remain a simple app that we can keep as a community example. If this gets outta date please fork it and send me a pull request on github.

Adding God to /etc/inittab on a Linux box

2008-10-19T00:00:00-07:00

God is watching

We’ve been using monit at Engine Yard on thousands of machines with a great deal of success. Sometimes it can get itself into a weird situation where it lets you down, but by far it does its job exceptionally. When I was setting up process monitoring for a merb app of my own; the logging capabilities of monit really let me down. �I had weird stuff happening because the environment was being cleared and I couldn’t track down exactly WHY my merbs kept aborting. So I gave�God a try and I really like it. I run god under init and here’s the basics for setting it up on an EY slice or any Linux box for that matter.

Setting Things Up

ensure that you’re on rubygems 1.3.0, older versions would load WAY too many things and it behaves like rubbish on most EY slices
% gem install god
% mkdir /etc/god
% echo "God.load \"/etc/god/*.god\"" > /etc/god/god.config
Add the following two lines to /etc/inittab: god:345:respawn:/usr/bin/god -c /etc/god/god.config —log-level error -D god0:06:wait:/usr/bin/god quit
% telinit q

Now all you have to do is drop god configs in /etc/god and you’re good to go. You should be able to see some meaningful log output in /var/log/syslog.

But it leaks memory!?!

Some of my coworkers are still hesitant about it because of the memory consumption and leaks they’ve seen. I kill god once a day with a cron job. :)

0 0 * * * /usr/bin/killall -9 god

Comments

p.s. Anyone have a better god config for merb processes? Here’s mine

Merb Exception Notification with HopToad

2008-10-09T00:00:00-07:00

Exceptions

One of my frustrations over the past few months has been the lack of a quality exception notifier plugin for merb. The New Bamboo Merb Exceptions gem has been around for a while now, but it has been consistently broken or tailored to versions of merb that I’m not currently running. So for the last few months we used a hacked version of new bamboo’s merb_exceptions in production, and it worked pretty well until the exception refactoring that went down in merb landed in mid-august. There’s a slightly more recent post on the Merbist about the merb_exceptions plugin being consumed into the official merb plugins repo, this is quite cool. :)

Call to Arms

Last night I saw a tweet by benburkert about hoptoad. I know Ben from the Merb/DM community and figured he had to be using hoptoad with merb. Hoptoad is an exception notifier/logger service provided by the good folks at ThoughBot. It’s kind of like a nice combination of the classic rails Exception Notifier and technoweenie/dreamer3’s exception_logger plugin. A quick search on github revealed an existing merb plugin for hoptoad. SCORE.

Problems

The downside was that this was written right when hoptoad was released, and the way that the Exceptions controller behaves changed(for the better) shortly after the initial plugin was released. So I forked the repo and it took about 30 minutes to update the code to work with the version of merb we’re running(0.9.7). I’ve sent a pull request to the author and I’m hoping he’ll consume my changes, but in the meantime you can grab it from my public fork of the plugin. I also updated the README to be a little more informative on how to get things going. UPDATE: I went ahead and made the code a proper merb plugin w/ specs and such, it’s available here.

Link to Unimplemented

2008-09-30T00:00:00-07:00

link_to_unimplemented

I ran across this post Robby Russell a while back and really liked the idea. It reminded me a little bit of an older post by Courtenay where he came up with the Tongue in Cheek Icon Set The general idea is that you’re not done with the application, there’s non-functional pieces of the UI that are at least partially exposed, and you need to make sure the client knows that these things aren’t complete.

In Robby’s post he implemented a simple javascript function that could be called via a custom link helper.Nice and simple. Here’s the js:

And here’s the ruby to invoke it:

I’ve grown pretty fond of jquery since I spent the better part of the year working with yehuda on a merb app. When I’d whip up some js in the style above he’d sit down with me and show me how wrong I was. So when I needed to actually use something like ‘link to unimplemented’ in my app last night I went about it in a slightly different way.

It’s actually really simple. You just attach an ‘unimplemented’ class to any anchor that you don’t want folks to follow. It’s cool because you can attach the real URL to the anchor and when the time comes to use it you simply remove the class. Here’s the js.

Here’s some haml taking advantage of it.

So there it is. A simple and effective way to keep clients from wandering to the parts of your site that you really don’t want them visiting yet.

Integrity : Continuous Integration

2008-09-26T00:00:00-07:00

What's it all about?

I'm a big fan of Continuous Integration when writing software. However I've always found myself disappointed by the CI solutions that are floating around, namely Cruisecontrolrb. Managing the processes can become a nightmare once you have a few projects running under it. At work I was recently tasked with revamping our on-again/off-again cruisecontrol setup and I thought to myself "there has got to be something better." It turns out there is, it's called Integrity. Here's why I love this little piece of software.

works fine with github repos, public and private
emails me reliably so I don't have to check a web ui to know what's up
automatically works with the Post-Receive hooks github offers, including branch support
excellent test coverage, it's was at 100% last time I hacked on it
works off an sqlite3 database
keeps history of test runs
written in datamapper and sinatra
they've got lighthouse setup ( here)

Random Tidbits

The README on the integrity site is a great start, but here's a few extra things that we're using that you might be interested in.

Process Management

We're just running bin/integrity like the README says under GNU Screen. It hasn't crashed and doesn't seem to be leaking.

Private Repo Access

We're using keychain and github deploy keys to access our source code from crons and the ci process.

The Github Hooks are AWESOME

A lot of the time a simple CI setup will just 'svn up' or 'git pull' and run the latest version that it pulls down. The github hooks actually send SHA1 hashes for each commit that a person makes. If one of your co-workers bundles half a dozen commits and he broke the build in the middle, you'll be able to identify which commit caused the problem instead of reviewing each commit and possibly running them all yourself. �It's this easy:

Click Edit on your github project(example)
Enter your Post-Receive url(example)

Can it get any better?

I'd really like to see some async build process for Integrity, or perhaps some devver integration. It's a pretty solid product and it keeps improving.

iPhone pwns

2007-07-03T00:00:00-07:00

iPhone pwns

So I contained myself all day on friday and didn’t wait in line for an iphone. At about 6:45 I decided that I’d go check out the closest AT&T store to see if I could get one. I walked in and out in about 10 minutes with a 4GB model for the sane? price of 500$ US. I went home, activated the thing, waited, waited and waited some more. After about 2 hours I called support, “i can has iphone?” and they replied “you can has iphone in 6 hours!” So I waited 6 hours, only able to slide the little touchscreen over to pretend like I really needed to make that emergency call. After the 6 hours past I thought “fuck this” and went to sleep. Needless to say I refreshed my email entirely too often for a while and my iphone(which was purchased on a friday) didn’t work until Sunday morning. Two days without a phone is kinda creepy in this day and age, especially when it has all sorts of nice features you wanna fuck with. :)

All that other bullshit aside, it’s fabulous. Everyone who takes my phone from me can figure it out. I’m delighted by the intuitive UI and the integration with my mac. The keyboard took me a little bit of getting used to(I came from a blackberry), but that’s the only thing I’ve remotely struggled with. Well done apple! I don’t feel like it was a waste of money, I’m delighted with my purchase but I only wish it would’ve started working sooner.

I can has ... wolf dog?

2007-06-27T00:00:00-07:00

After getting denali around Christmas time last year, I really hadn’t planned on getting another dog for a while. Then I came back to Memphis and met a friend’s wolf hybrid. He was a big beautiful four year old dog and I found myself really wanting one. I’m terribly impulsive when it comes to things like this. If I really really want something, I usually figure out how to get it. So I scoured the local papers and found a breeder with 7 week old pups, one of which was a beautiful blue eyed little girl cub. This was a few days before Railsconf so I figured I’d read up on them some more and make my final decision when I returned. At railsconf I ended up talking a handful of people’s ears off about how beautiful and wonderful these wolf dogs were. I think everyone thought I was a little crazy when I’d describe my desire to have a wolf. I even had an Engine Yard client tell me “You look like the kinda person who would own a wolf.” I don’t really know if that’s a complement or what…

So this is my new wolf dog . She’s 7/8ths Arctic and Timber wolf and 1/8th Husky, so she’s technically a ‘high content’ wolf dog.

EVERYONE seems to have an opinion on this. If only I had a dollar for every genius who told me “you just gotta be the alpha…” Animal behavior, especially psuedo-wild animals, is actually a hell of a lot more complicated than just being ‘the alpha.’ So I’ve been reading a bunch to expose myself to possible warning signs of behavioral problems and hopefully make the years to come really easy for our pack. :)

The silly thing is that I really didn’t find the resources that were most informative until after I’d had Cindy for a week or two. If you or anyone you know is ever considering getting a wolf hybrid check out Nicole Wilde’s Living with Wolfdogs, it’s extremely informative. If I’d read that book before I got Cindy, I might not have gotten such a high content wolf dog. I am a little weary of what she’ll be like from about 10 months to 2 years, a lot of the ‘wolfy’ behavior seems to come out when they hit sexual maturity. Specifically I’m scared about a Cindy/Denali alpha bitch clash at some point, I really should have gotten a male. I also pretty much committed myself to living in houses with 6 foot tall fences for the next 10-15 years, apartments just won’t cut it. There are just all of these little things you have to keep an eye out for because, well, they’re not dogs. :(

Anyway, she’s a simply wonderful little pup. I’m doing daily clicker training with her and Denali(separately of course). She’s got three labs to play with and a big back yard. She also gets to play with Hubble and Kioko practically every day. I really doubt socialization will be an issue with her. Her flickr set will grow in time, but probably not as quickly as she’s growing. She’s 13 weeks now, and I give her another 6-8 weeks before she’s bigger than Denali. I’m definitely have a shitload of fun with the dogs right now. :)

Moving at the Speed of Life

2007-05-03T00:00:00-07:00

The last few weeks at Engine Yard have been fucking insane, seriously. I can’t remember the last time I was this stressed and tired regularly. Come to think of it, the last time I was this tired and stressed was the last time I was a systems admin. I’m learning a bunch of new things, I’m holding lots of developers hands while they get their apps out to the world, and I’m constantly amazed by my coworkers knowledge. I miss hacking terribly right now. When I do finally pull myself away from work, I’m usually trying to get as far away from the computer as possible. Despite the stress, exhaustion, and lack of programming time, life is beautiful right now. I’m extremely happy with my life right now, that’s not something I could say a year or two ago. :D

I’ve finally gotten out of Nashville for a considerably less wonderful city, Memphis. I’m going to miss so many things in that city, but getting out of the southeast is now a priority for me. I’m crashing with family(who fucking rock btw) for the next couple of months until I get everything settled for a move out west. I’m looking at Portland, the Engine Yard folks want me to look at San Francisco or Sacramento. I’m not sure where I’ll end up but I’ve got a month or two to figure it out. I’m really looking forward to Railsconf now, it’ll give me a peek at Portland and it’ll give me the opportunity to talk with some of my favorite hackers.

Logrotate and Mongrel

2007-03-22T00:00:00-07:00

If you’ve been around webservers for a number of years you’ve inevitably run into logrotate at some point. You set a tiny config file up and daily, weekly or monthly your logs get rotated out, compressed and optionally moved elsewhere for archiving. It’s pretty cool when your logs get chomped out into easily identifiable chunks. You can think “I need the logs from 2 days ago” and you won’t have to go sifting through all of last week’s logs in order to get to them. Mongrel really isn’t any different than any other webserver most people have dealt with, but logrotate and mongrel seems to be lacking proper documentation around the web.

Everywhere I looked online I found stuff like this explaining how when more than one process are sharing logs files, ruby’s built in log rotation falls flat on its face. The answer to correct log rotation kept coming back to “use logrotate” but I couldn’t find an example config to save my life. So I mucked around with it for a bit. The straightforward approach, moving the log outta the way and compressing it with logrotate, doesn’t quite work because once the log file is moved out of the way the mongrels can’t write to the new empty one. This is easily solved with a postrotate task and a SIGUSR2 signal sent to mongrel. So here it is, in all its glory, a logrotate task that you can prolly copy right over to your system and not waste time scouring the web for something that’s really freakin simple. It compresses files once a day, moves them to a subdirectory of the log dir called ‘old’ and it keeps 28 days of back logs.

/home/atmos/Sites/atmos.org/shared/log/*.log {
  daily
  missingok
  compress
  sharedscripts
  olddir old
  rotate 28
  postrotate
    for i in `ls /var/atmos.org/shared/log/*.pid`; do
      kill -USR2 `cat $i`
    done
  endscript
}

Moving on ... to Engine Yard

2007-03-02T00:00:00-08:00

I’m happy to report that I’m going to start working with the good folks at Engine Yard in 2 weeks. I’ll basically be trying to lighten the load that Ezra has been bearing by himself and learning all about how they’re doing things over there.

I’m sad to report that I’ll be leaving Centerstone in two weeks. I started there just over a year ago and my life has changed so much in the last 12 months. Sooo Much. I have a lot of respect for everyone on my team at Centerstone for various reasons, and I’ll really miss all of them. I’m also giving notice 3 days before we go into user acceptance testing. I know this is really going to hurt my team, but this was far too good of an opportunity to pass up. I had a large leadership role there and am responsible for a lot of the good(and most of the bad) things in the system. I got to help train and convert a Java shop to Rails and I got to grow immensely as a developer.

Mixed feelings aside, I have a grin from ear to ear.

Phone Upgrade

2006-09-08T00:00:00-07:00

About a month ago my Blackberry 7290 quit getting reliable reception. I’d never had any problems with the phone up until then and even when I was visiting Atlanta it wouldn’t let me talk more than 45 seconds or so without dropping calls. I took it into Cingular and they tried to get me to renew my service and get a more modern blackberry. While the phone made a lot of sense while I was at GE, I really didn’t need a wallet phone anymore. So I went looking on ebay…

There were only two requirements, one of which I could deal without if I found the right phone. Mainly I wanted something that worked well with my mac via bluetooth, and the other was a keyboard for text messaging(yes the blackberry spoiled me). Most of my friends with Motorol Razrs hate them, and the other ‘popular’ phones were either more than I wanted to spend or pushing features I didn’t foresee myself using very often. I remembered my friend Roy hyping up bluephoneelite a while back, so I looked at what phones would work well with it. One of their well supported phones looked really dope, a Motorola A630. I found one on ebay, brand new, for a little more than 100$. Wow oh wow, I’m absolutely hooked on bluephoneelite. It’s so dope when I get a phone call, the caller id is displayed on-screen, and my itunes pauses when I answer it. It’ll put my machine into screensaver mode and shuts off itunes when I walk out of range. Equally cool is when it starts it back up when I walk back in range. :) They’re really really simple interactions with my computer that are just convenient. I love it.

Syncing my contacts from my Blackberry wasn’t as straight forward as I thought it’d be. Unfortunately the A630 doesn’t work with isync by default. PocketMac did a decent job of putting all of my blackberry contacts into my mac address book, isync just refused to connect to my a630. I found a great write-up on syncing the a630 with isync on macosxhints and now all is well.

nginx proxying down to your mongrels

2006-08-23T00:00:00-07:00

Ezra was going on and on about this nginx things on IRC today. Saying how it was “super light and fast webserver with really good(better than pound) proxy module.” I had an app I wanted to setup a mongrel_cluster for at work, and when he gave a pastie like this I figured I’d give it a try. It took all of 5 minutes to be up and running. It seems fine for the time being, I’ll find out tomorrow when more users start hitting it. One thing that was weird was I couldn’t start it on a high port as an unprivileged user. You CAN however start it with sudo, set the user in your config file, and it seems to setuid properly. Thanks Ezra!

My friend Kevin at work shared this link this morning, which covers a few of the cool features it offers.

Corey Donohoe - atmos.org

My talk from POSSCON 2011

POSSCON 2011

The Geek Talk Interview

Interviewed by The Geek Talk

Joining GitHub

Joining GitHub

On Leaving Engine Yard

So I quit working at Engine Yard

The AppCloud Team

Where I’m Going

Constantly Shipping Refactorings

Constantly Shipping Refactorings

Unicorn and Zero Downtime Migrations with DataMapper

Adding a New Model

Data Transformation/Migration

Removing a Column from a Model

Renaming a column

It’s so simple, who cares?

Hiring

My talk from Red Dirt Ruby Conf - Rise of Devops

Red Dirt Rubyconf

My talk from Aloha On Rails

My Aloha on Rails talk

SF bound and down, upcoming talks

SF bound and down

hoptoad for rack

Rack Hoptoad

as time goes by : blabbing 'bout sinatra

Sinatra 0.9

Hancock-Client-Rails : Using Sinatra/Rack Middleware in Rails

Hancock-Client-Rails: Works with Rails > 2.3.x

Hancock-Client : Sinatra Middleware

Hancock-Client: Middleware

Hancock : A Single Sign On Server in Sinatra

Hancock: SSO

Considerations for Creating a Test Driven Ruby Project

Creating a TDD Ruby Project

Where this comes from

You should have a README that tells another developer how to get up and running

You should really be testing, even if it’s after the fact

Name Your Tests/Specs after what it does

Be able to toggle mocks and integration tests easily

Use GitHub

How will this commit affect Continuous Integration?

Collaboration is King

Merb and Rails Sitting in a Tree

Rails and Merb Merge

Merb 1.0 Controller Testing

Merb Request Testing Evolved

Request

Requests with Authentication

RSpec Matchers FTW

1.1 dispatch_to

1.2 get/post/put/delete

1.3 request

status – the http response code

body – the document returned from the action

headers – the http headers returned

url – the url that was requested

original_env – i think this is how stuff persists between requests. I’ve never actually called this for anything.

2.0 Testing with Authentication

2.1 merb-auth and all that jazz

2.2 dispatch_to and HTTP verbs with Authentication

2.3 requests with given blocks

3. RSpec Matchers

3.1 HTTP Response Checks

Markup Validation

3.3 Roll Your Own

Flatirons : A Merb OpenID Provider Part 1

Flatirons OpenID Server

The Low Down

Paint a Perfect Picture

Identity Discovery

Associate

Check ID Setup

Acceptance – “Do you trust me?”

Identity Result

WTF, Why do I even care?

Where’s the Code