Hashrocket.com / blog

Developing with small tools

posted on and written by in

Image 100x100 micah cooper

Recently I've been exploring the idea of integrating very small, specific gems and generators into my development workflow. The idea here is to have a toolset of many small, single use, non configurable libraries to add convenience and speed to my development. I think most gems start out this way and then become larger and more configurable as more people use them.

This is what I want to avoid. Not that big configurable gems don't have their place. To be honest, this works for most problems. But not always.

Imagine an adjustable wrench. With an adjustable wrench you can make it fit any size nut and it works fine most of the time. But as soon as you try to unscrew that rusty bolt on the oil pan under your car with an adjustable wrench and strip it, you'll throw that stupid wrench through the first window you can find... stupid wrench...

So, here are a few examples where I prefer something much smaller and non (or less) configurable.

Authentication

More often than not all I need for authentication is email, password, and maybe remember me. That's it. So I want a tool that does only that. If I need more, I can write it myself. Authem is a good small tool for this. It only does what I need and nothing more. It's very specific to my needs which makes the decision of whether or not to use less consequential (single responsibility). If it doesn't fit exactly, meaning I use every feature it contains, I'll use something else.

Forms

At Hashrocket, we have front end developers that write beautiful markup. They have a standard way of writing forms and there are parts of it that are the exact same for almost every form. So it seems natural to use a form builder that allows back end developers to quickly wire up a form that adheres to their standards. I know there are gems out there for writing forms. But some seem like more work than they are worth- I do not prefer learning a DSL that allows me to use one form helper that is endlessly configurable to create a <label> and a <input/>. I feel like I could have just written the two default rails helpers in the same amount of code and saved myself (and others) from learning a new DSL. Call me lazy, but I think the decision to spend a client's money learning, teaching, and implementing a new library that touches many parts of the app should be warranted. Many times it very much is. But not in this case. Not for me anyways.

All that to say I prefer to use a simple form builder called formal that saves a little bit of time when writing forms. I can add it to a form with the option builder: Formal::Builder where it applies and write a normal form where it doesn't. It saves me the work of handling form errors, and wrapping the <input /> tags in a <dd> and that's it. It will never be more than this and I don't want it to. I would rather write another small library to handle different aspects of the form than add more features to this one.

Anyways...

This is a new way of thinking for me. Usually I just choose the de facto tool for the problem, learn it and mold it to my app. But between these solutions, I feel there is a place for much smaller and more specific tools and that's what I'm working for.

Other ideas include using generators to build a very small and specific cms - Buildybuild.

Posted in Development and tagged with Ruby