Matte Noble

CSSTree - An ultra-simple CSS parser

2011-08-20T00:00:00-04:00

I needed something to parse a bunch of CSS and gave me a manipulatable object. I tried a couple parsers and none of them worked. It wasn’t that they didn’t do everything I needed, they just flat out didn’t work at all.

So then I made CSSTree. It’s dead-simple and does next to nothing. Other than parsing CSS that is.

tree = CSSTree.parse("body { color: #000000; }")
# => #<CSSTree:0x000000>
tree.find("body").color
# => "#000000"
tree.find("body").margin = "10px" 
# => "10px"
tree.render
# => "body { color: #000000; margin: 10px; }

And that’s pretty much it. Go team!

Ruby Enumerables

2011-05-30T00:00:00-04:00

If you’re writing any type of API client library, you’ll probably need some sort of Collection class that’s iterable. It’s quite simple, but pretty powerful; most things in Ruby are.

It’s All About Each

The Ruby stdlib has this handy module named Enumerable. It basically means that if you mix it into a class which responds to each, you get all the fanciness that is select, map, all?, etc.

This sounded odd to me at first. How would implementing the method you use to iterate an object… make it iterable? It only feels weird because we’re used to each being an interface, not an implementation. It plays both roles!

An Egg Sample

class Carton
  include Enumerable

  def each
    @eggs.each { |egg| yield egg }
  end

  def drop
    @eggs = []
  end
end

Now whenever you create a Carton object with a bunch of eggs, you’ll be able to iterate over those eggs one at a time. The eggs themselves can live in an Array, Hash, whatever. The important thing is to yield them one at a time via each.

With the above code, a Carton object can now do everything any other enumerable object can, but with the added bonus of breaking all over the fucking parking lot…

Tabby - iTerm2 Environments

2011-05-12T00:00:00-04:00

If you’ve ever created a Jekyll site with, say, SASS and Coffeescript,
you know how annoying it is to set up your terminal environment every time. Open a tab, cd to your project, open a new tab, jekyll --server --auto, open yet another tab, cd to your project, sass --watch whatever.sass:whatever.css, etc.

I got tired of doing that multiple times per day, week, whatever. And so, Tabby was born.

I created Tabby for two purposes, first to solve the problem described above and second, to play around with the idea of pure Ruby configuration. There’s no crazy DSL (sorta), no YAML, no hassle; just Ruby in all it’s glory.

A Quick Tutorial

With Tabby, you set up Projects. Projects are just collections of iTerm2 tabs and what each one runs. Let’s walk through creating my blog environment. First, create the project:

$ tabby create blog

This will open up your new project in whatever you have $EDITOR set to. Tabby assumes you use ~/Dev as your project directory because, well frankly, I do. It gives you a skeleton for your project right off the bat:

class Blog < Tabby::Base
  basedir "~/Dev/blog"

  def server
    exec "rails s"
  end
end

basedir is the root of your project. Tabby takes each method in your project class and makes it a tab. The tab gets the name of the method. So above, we’d have a tab created and titled “server”. It would immediately run rails s.

Since we’re making a Jekyll blog, we can get rid of the Rails tab. We do want to have the Jekyll server running though and also SASS and Coffeescript.

class Blog < Tabby::Base
  basedir "~/Dev/blog"

  def jekyll
    exec "jekyll --server --auto"
  end

  def sass
    exec "sass --watch public/sass:public/stylesheets"
  end

  def coffee
    exec "coffee --watch -c public/coffee/ -o public/javascript/"
  end
end

So now every time you go to work on your blog, just kick it off with:

$ tabby open blog

and you’ll get:

Usage

Here’s a quick run down of the other commands, straight from the horse’s mouth:

tabby create [project]  # Creates an empty project config.
tabby edit [project]    # Opens the project config with $EDITOR.
tabby list              # List all projects.
tabby open [project]    # Starts up the environment for a project.

The Value of I Don't Know

2011-05-11T00:00:00-04:00

“I don’t know” is one of the most powerful things you can say in my opinion. I don’t mean using it when you just don’t feel like talking, I mean when you truly do not understand something.

I think people feel weak or inferior when they don’t understand something and the rest of the group does. No one wants to be left out. It’s especially bad in an industry full of very smart people, solving very challenging problems, like we have in Software Development. You’re talking with your team of ten and every one is on the same page except you; it’s frightening!

Saying I don’t know is a true sign of strength though. Admitting to a group of people that you don’t understand something takes guts. It also takes brains. Wait, it takes brains to admit your brain doesn’t know something. That doesn’t make sense. Wrong sir!

It makes perfect sense. When you admit you don’t know something to a group of people, you’re essentially making an informal pact with them to figure it out. You’re also not feeding them false information, which is always a good thing. Unless your a double-agent.

Anyway, the point is, don’t be afraid to admit you don’t know something. Some people may come down on you for it, but fuck them. Be honest, be sincere and acknowledge when you have something to learn. That’s how you improve, right?

Blocky RSpec Stubbing

2011-04-24T00:00:00-04:00

While working on Tabby I hit an issue when stubbing Tempfile.new. Instead of creating a Tempfile I wanted to just use a StringIO-ish (FakeFile) object so I didn’t write to the filesystem.

The Problem

Tempfile.stub(:new).and_return(FakeFile.new)

The problem is that Tabby creates a new Tempfile for every tab it needs to make, meaning it can be multiple times depending on the setup.

So one of the setups in my tests has two tabs. For the first tab, my FakeFile object was opened, written to and closed. The next tab did the same, to that same exact FakeFile instance. Since it was already closed, I got IOError: not opened for writing. Lame.

The Solution

RSpec’s and_returns takes a block, that is evaluated when the stubbed method is called. This way it’s invoked from a different context each time, giving us a brand new FakeFile each time.

Tempfile.stub(:new).and_return { FakeFile.new }

So if you have a stub that needs to return the same type of object, but a brand spank’n new instance of it each time, use a block.

Taking Care of Business

2011-04-02T00:00:00-04:00

One of the many things I love about the Ruby community is the notion that things should “just work” out of the box. I’m sure it’s in part due to Rails’ convention over configuration mentality, but I think it’s more than that.

During the day I wear skin tight, rockstar style snake skin pants. If you aren’t picking up on my odd, far-reaching metaphor, I mean I write Python code. Anyway, it may just be a lack of experience in the community but things seem infinitely more complicated to get up and running than when I’m working with Ruby. It just feels like there is more between me and the end goal.

Here’s a few of my favorite pieces of “just works” Ruby software:

Devise

rails g devise:install and rails g devise user Done. You’ve got a sign in page, a user model, migration and all the goodness. I just wrote the steps for adding authentication to an app in a single sentence. That’s incredible.

Heroku

Heroku is another great example that literally takes seconds to get up and running with. rails new blog, heroku create, git push heroku master. Done & done. Application deployed and online.

Rubygems

So you have a gem you want to make available to the world? Simple, gem build whatever.gemspec and gem push whatever-0.0.1.gem. Done. Granted, I do know this one has a Python equivalent. python setup.py register claims to get you the same, but my recent attempts have all failed with, “You are not allowed to store ‘whatever’ package information”. Okay.. so.. what now?

Tools are an important part of any developers day to day life. I think tools are partially why Ruby developers are typically quite productive. We see the value in good development tools and we spend time crafting them to “just work”.

This is only one of the many things I admire about the Ruby community, but it’s an important one. Having efficient tools helps make an efficient developer.

Test and Design Driven Development

2011-03-30T00:00:00-04:00

For quite some time the way I’ve worked was to develop the application as if the interface didn’t matter, until it was done. Write my features, tests, etc and then when you have a functioning 1.0, slap some pretty on it. It always felt wrong, it felt unfair to the application.

Outside-In Development is pretty awesome but while it ends up being great for features and application code, it didn’t seem right for mixing in some design work. I’ve altered the my general, outside-in, workflow to include some design time. Here’s how it goes..

Cucumber

Write a feature; keep it high level and based on value (you already know this though). Lets say you’re working on the Authentication portion of your application. You want to make sure when a user signs in, they are greeted with the message “Hey there!”.

RSpec, MiniTest, etc.

Write some controller and model tests to get rolling with the lower level login stuff. Let’s pretend you just did that. A user can sign in and they will in fact see “Hey there!”. That’s awesome, nice work. Except…

Gross. You could leave it like this for the time being and move on to other features if you so incline. I, however, can not do that anymore. Having a functioning app with a lame UI sounds as bad as having no app at all to me.

Design

At this point, it’s time to put a little shine on your application. If you’re not doing both design and development you could probably even “get lean” here and send a “card” downstream to a designer. Hmm, article_ideas += 1.

Anyway, now that we know we have a reliable test suite for this feature, start playing with the UI. With all the cool things available these days like SASS, Compass, Haml, etc. this step should be fast and easy, even without Photoshop.

So now you have a well tested, functional and quite attractive sign in feature. The cool thing about this approach is that it integrates really well with the normal red, green, refactor methodology. This won’t be the last sign in feature you write, most likely, so every new one is a chance to not only refactor your code, but also the design.

So if you’re a designer/developer hybrid or are tasked to doing both, try this out. It’s helped me get that abstract vision for things into a clearer light, which is always a good thing.

Forge - Python Fixture Replacement

2011-03-22T00:00:00-04:00

I found myself wanting a simple way to create objects with fake data for unit tests, in Python. I always liked factory_girl and the way it keeps things clean and coherent. However, Ruby libraries were no help to me here, directly at least, I needed a Python solution.

I wanted something that wasn’t fixtures. First of all, I don’t think you should need a database to run unit tests. If you’re writing simple, modular code you should be able to give input and test output. So my answer to that need is Forge.

Forge is a very simple object creator loosely based on factory_girl. You define factories and then you build them. What I really like about this approach is that it makes your intent quite obvious. Testing something to with a confirmed user? confirmed_user = Forge('confirmed_user'). Simple, clean and easy to follow.

If you’re familiar with factory_girl at all, this will be nothing new for you. For those of you who aren’t, here’s a quick rundown on how to use Forge.

Defining Factories

First create a project/test/factories directory. You can either define all your factories in the __init__.py file or in separate files then import them in __init__.py.

# project/test/factories/user.py
from forge import Forge

with Forge.define('user') as f:
    f.name      = 'Matte'
    f.age       = 24
    f.confirmed = False

with Forge.define('confirmed_user') as f:
    f.name      = 'Randy'
    f.age       = 67
    f.confirmed = True

# project/test/factories/__init__.py
import user

Building Forged Objects

So now that you have a bank of factories for the different scenarios you’re testing. Time to get down to business. The API for creating factory objects mimics factory_girl’s:

import project.test.factories
from forge import Forge

user = Forge('user')
# OR
user = Forge.build('user')

Unlike factory_girl, Forge will never put your objects into the database. It doesn’t even know how.

Using Models

When you’re working with an ORM you usually want objects that are as close to what it returns from a database query. Most of the time this is just achieved by instantiating a model class with your factory data. And that is exactly what Forge does. You can configure Forge to use a specific module to retrieve models from:

Forge.configure(models='project.models')

Now, when you try to build a user factory, it will try to import project.models.User. If it exists, it will create an instance of it and apply the factory data to it. As long as your model’s constructor takes **kwargs of attributes, Forge should work just fine.

Wrap Up

Forge isn’t anything fancy, but it provides a uniform way to define and create real objects for tests. It keeps things organized, the intent clear and works out of the box. If you find yourself wanting to ditch the database in your unit tests, check it out.

A Developer's Introduction to Puppet

2011-02-08T00:00:00-05:00

Puppet is one of those things most Rubyists have probably heard of, but few know very well. I’ve recently started using it in conjunction with Vagrant and found myself wanting a consolidated explanation of it’s components. So, here it is!

Nodes

A node represents a specific type of machine. It defines how, and with what, that type of server gets provisioned. Examples nodes would be like a web server, a mail server or an LDAP server.

Modules

Puppet modules are much like Ruby modules. They’re an organization tool which DRYs up your Puppet configs. Modules contain Classes, Templates, Files, etc. The Puppet site explains it well:

Modules are reusable, sharable units of Puppet code. They can automate tasks such as setting up a database, web server, or mail server.

Classes

Classes are the actual unit you can include into nodes or even other classes. Classes support a simplified type of inheritance. Say you want to use nginx as a web server one place, but as a proxy another. You’d have a base class, nginx, then a nginx::proxy class which modifies the base to act as a proxy server.

Resources

Resources are what classes contain. They’re a single item that is part of the overall configuration of a class. Take our nginx example above, to provision nginx on a machine we need a couple things. We need to ensure the package is installed, we want to make sure the service is running and we’d like to define a custom nginx.conf. These would all be resource definitions.

Templates

Templates are any file you want to put on the machine being provisioned. This can range from a nginx.conf file to /etc/hosts. You can include dynamic data by specifying class variables in your.. you guessed it, classes! These files are just erb so any normal Ruby goes.

Just the Surface

This is a very, very basic overview of Puppet. It’s an extremely powerful platform that can really make your life easier. I didn’t cover any examples of the Puppet DSL on purpose, I want this to just be a basic primer to Puppet’s concepts.

Check out Puppet Labs’ Documentation for more information. Also, take a look into their Module Forge for preexisting modules you can use right now, with barely any work.

New Year, New Site

2011-01-18T00:00:00-05:00

As cliche as it may be, I’ve set a New Years resolution for myself; consistently update content on this blog.

I’ve wanted to resurrect this site for quite some time, but never got around to it. That is changing. I read an interesting article recently that gave me some good ideas. A blog is very much like any other project and I’m going to start treating it like one.

When I’m designing, developing, writing, whatever, something that’s going to be public or seen by others, I obsess over every small detail. I need to take a more iterative approach to everything. Things don’t have to be perfect in their first incarnation. Or any incarnation for that matter.

The Approach

I’m going to set up an issue tracker for article ideas, issues, etc. I’m also going to start carry around a pocket journal to write down ideas throughout the day.

Comments

There will be no comments on this blog directly, at least initially. If there’s enough interest in the future I’ll add them, but for the time being they aren’t needed. Until then, I’ll let sites like Rubyflow and HackerNews support those conversations for me.