Meta Bates

I’ve started working this week on an example application for the next book I’m about to write and I wanted a simple way for my readers to easily run the app (it’s going to be a single HTML file with a ton of cool JavaScript going on in it). My first choice for running this app was to use the popular Ruby library, Rack. If you are unfamiliar with Rack, please check it out. It provides a simple interface for writing web applications. By writing a simple Ruby file readers can use their favorite Rack compatible web server to launch the application. Sounds simple, eh? That’s because it is.

With a simple Rack application written in a few lines of code I was able to start developing my example application. That’s when I realized I needed a good way to serve up all my CoffeeScript and Sass files. I was going to write a watchr script that did this, but I thought that was a bit heavy handed, and not very flexible, so I turned to Sprockets.

Sprockets recently gained a lot of attention because it is bundled in with Rails 3.1 to serve up an application’s assets. It’s a clever little library that will process your files using CoffeeScript, Sass, etc… and let you bundle them up in to a single asset by using a manifest. That was exactly what I wanted. After I spent the better part of an afternoon doing a bit of research and debugging here is the Rack configuration file I came up with:

require 'sprockets'
project_root = File.expand_path(File.dirname(__FILE__))
assets = Sprockets::Environment.new(project_root) do |env|
  env.logger = Logger.new(STDOUT)
end

assets.append_path(File.join(project_root, 'app', 'assets'))
assets.append_path(File.join(project_root, 'app', 'assets', 'javascripts'))
assets.append_path(File.join(project_root, 'app', 'assets', 'stylesheets'))

map "/assets" do
  run assets
end

map "/" do
  run lambda { |env|
    [
      200, 
      {
        'Content-Type'  => 'text/html', 
        'Cache-Control' => 'public, max-age=86400' 
      },
      File.open('public/index.html', File::RDONLY)
    ]
  }
end

That will serve

/assets/application.css

via Sprockets. The file itself will live in

<pwd>/app/assets/stylesheets/application.scss

The same goes for JavaScript files.

Hopefully this will save someone else a little of time when they’re trying to do the same thing. Enjoy!

I have to ask a question to my fellow Rubyists out there? Why are you still using YAML? I know why you think you like YAML. You think it’s a great way to write configuration files, but it’s really not. You know what’s a great way of writing configuration files for Ruby apps? RUBY!

I know it’s crazy, isn’t it? But why not? Why would you not want to use Ruby for configuring your applications instead of YAML?

I’m the maintainer of a pretty popular configuration tool for Ruby apps, Configatron, so I think I have a little experience in this field. I also write and maintain a lot of libraries that require configuration and I have never thought that YAML is the best way to do this.

Let’s look at an example of what a library developer has to do to load a YAML file to get configurations:

foo:
  bar

require 'yaml'
config = YAML.load(ERB.new(File.read('/path/to/config.yml')).result)

I don’t know about you, but I think that’s kind of lame. Most everybody runs their YAML files through ERB so that they can make their YAML files more ‘Ruby-ish’. Why not just use Ruby?? Here’s the same example in Ruby:

SomeLibrary.config = {:foo => :bar}

require '/path/to/config.rb'

In addition to not having to deal with all the whitespace, tabs, crazy nesting, etc… that YAML brings we get to use the full power of Ruby for our configurations! Try storing a Proc in YAML. Yeah, that’s what I thought. You can drive configurations from the database, environment variables, crazy equations, etc… the world is your oyster. All you need to do now is stop using YAML!

I’ve decided to drop YAML support in Configatron 2.9 (coming sometime this Summer) and I encourage all other library developers to do the same. It’s just not needed, or very nice for that matter. Now, if we can only get Rails to drop the database.yml file, I think we’ll be all set.

In case you’ve been living in a cave this week you’ve probably heard that Ruby on Rails is going to be including both the CoffeeScript and SASS libraries, it will also make jQuery the default JavaScript framework, replacing the Prototype framework.

I would like to start by addressing my experiences with CoffeeScript. My opinion of it is of ambivalence. I’ve used it on a project, I’ve played with and in the end I’ve come out with the opinion of “it’s ok”. It didn’t blow me away, but at the same time I can see why so many people like. It offers some really cool features that I really wish JavaScript had and you can cut down on the amount of code you have to write. On the other hand the apps I tend to write don’t tend to be that JavaScript heavy that I really needed to reach out for something like CoffeeScript.

So, how do I feel about CoffeeScript being included with Rails? Well, I’ll get to that. Let’s go over some of the most common arguments I’ve heard from people this week about why they’re anti-CoffeeScript in Rails.

“It’s an abstraction layer of JavaScript! JavaScript isn’t that bad, why can’t you just write JavaScript?”

“It’s going to be a hinderance to newbies. It’ll be too much of a learning curve!”

Let’s start with that second point first, shall we? I agree, it does represent a new element that needs to be learned when coming to Rails. But here’s the pretty nifty thing about how it’s all implemented in Rails. In order to actually use CoffeeScript in Rails you have to create your files named foo.js.coffee if, however, you just name your file foo.js then, guess what? You will have to write plain old JavaScript! Seems like newbies, and those who don’t like CoffeeScript, can just keep writing plain old JavaScript without anything stopping them at all.

Now, let’s talk about the abstraction layer argument. Yes, CoffeeScript is an abstraction on top of JavaScript, but let’s take a look at a few other parts of the Rails stack and see how they hold up against this argument.

Here’s a fairly common Rails stack:

• ActiveRecord
• Haml
• jQuery
• RSpec

What do all those things have in common? Well, they’re all abstraction layers that sit on top of something else, don’t they? Let’s look at that list again?

• ActiveRecord – SQL (Structured Query Language)
• Haml – HTML
• jQuery – JavaScript, you could just as easily hand roll those AJAX calls in pure JavaScript.
• RSpec – Test/Unit

What I’ve found funny about the particular argument is that I’ve heard it MOST from those who use things like HAML, which is a DEFINITELY an abstraction layer that sits on top of HTML. See where I’m going with this one? Good, I don’t want to belabor the point.

So, finally, where do I stand on this whole thing? Well, I view like it Test/Unit and Prototype. Those are both the current standard (although jQuery will replace Prototype in 3.1) and I don’t like or use either of them. Instead I configure Rails to use jQuery and RSpec. I don’t like Haml, but those that do simply replace ERB with Haml and they move on with their day. So my take is this, it’s there, it’s included. Use it if you like, or don’t. Is it really that big a deal? No, it really isn’t. If Rails dropped ERB and went with Haml as the default, would I bitch and moan, probably a bit, but then I’d just install the Rails-ERB gem and move on with my day, just like I do with jQuery and RSpec today.

So sit back, relax, use the libraries that you want to use, Rails let’s you do that. Oh, while you’re relaxing why not try out CoffeeScript, who knows, you might just enjoy it. Or not.

Last week I received an email from someone who used to work at a company that I used to work with. I didn’t know him, but he knew me through my work at the company, and my other exploits. He sent me an email to say that after a short time with the company he had been laid off, along with half of the development team. He wasn’t looking for pity, but rather advice.

What kind of advice was he asking for, well, he quite simply needed to know how could he become an ‘expert’ Ruby on Rails developer. First, let me say that this post won’t have anything to do with Ruby, Rails, or any other specific programming language. Everything I’ll talk about is valid in ANY language on ANY platform. With that disclaimer, let’s move on, shall we?

While at this company he got introduced to Ruby on Rails and really loved it, coming from a non-Rails background. Since being laid off he’s been trying to land another Rails gig, but everyone is looking for ‘expert’ Rails developers. So the question was, how to become an ‘expert’ developer?

I keep putting ‘expert’ in quotes because, let’s be honest here, that’s a VERY subjective term. As someone who has hired many developers in his day, I can tell you that I’v

e hired newbies to ‘experts’ and everywhere in between. Everyone has their merits and possibilities. I’ve met ‘experts’ that I wouldn’t hire to take out my trash, let alone build my business. I’ve also met people right out of college that I would hire again and again. So your mileage my vary.

So… how do you build up that ‘expert’ reputation? Let’s look at it. Below are some of things I’ve done, as well as some of the things that I look for as a hiring manager. Some are incredibly easy to do, others require work, but in the end they WILL pay off, and you’ll easily be at the head of the pack when going for that job.

Build Something

When you are looking for a job people want to see what it is you’ve actually built. If you haven’t built anything, then how are you an expert? Build a lot of different things and put them up on the web for perspective employers to find and play around with. Use these are a playground for trying out all those cool new technologies you keep hearing about. Want to give NoSQL a try? Great, build an app that uses it. Need to improve your testing chops? Write an application and write all the tests you can possibly think of!

Get a GitHub Account

I can’t tell you how important GitHub has become when trying to make a name for yourself. It seems like unless you’re on GitHub, you’re nobody. While that might not be true, it certainly hurts more than it helps to not have an account. You know those apps you’ve just been building and playing around with? Post them on GitHub! Then put your profile page link on your resume. Yep, you read that right. Give those looking at your resume a link to your code. Let them see how good a developer you actually are. Show them you know how to code all the things you’ve got on your resume. Listing a language, platform, or tool on resume is one thing, but actually showing your perspective employer is another! They’ll love it.

While you’re on GitHub, why not contribute to an open source project that’s up there. There are plenty of them, and they’re ALL looking for people to help out with their projects. Simply fork the projects, make some improvements, and then give those changes back to the projects owner. This looks great on a resume and really helps to show that you are interested and active in the community. Again, employers love this! Plus, you’ll be starting to build a name for yourself, and building a network, and a network is INCREDIBLY important when looking for work.

Blog and Write

I should probably heed my own advice here and blog more often, but do as I say, not as I do. With that said I wrote a book, which looks AMAZING on a resume, but might be a bit out of reach for most people, so I recommend blogging instead. Why should you blog? Well, it shows that you have good communications skills, again very important to most employers. It can also show that you have a deep understanding of whatever it is you blog about.

What should you write about? If you’re stuck on a topic, might I make a recommendation or two. First, when you’re building those applications I mentioned early if you run into a bug or something else that got you a bit stuck, blog about it! Others could really benefit from your experience. Explain the problem and how you went about solving it. Another great thing to write about is your favorite libraries or plugins. Pick a different one each week and dissect it. Write about how it works, what it does, etc… This is a great exercise in both writing and learning about how things work. Very valuable.

Network

I mentioned earlier that a good network is INCREDIBLY important when looking for work, and I wasn’t lying. It’s the most important thing. A good network will constantly be feeding you new opportunities, or putting you in touch with those who can. So how do you develop that network? A few ways, I mentioned contributing to open source earlier, that’s a great way. Another great way is through conferences, hackfests, rumbles, and whatever other local (and non-local) events are being held in your development community of choice. Attend these events, participate, introduce yourself, speak, buy drinks, whatever! Just get out there and NETWORK!!

Conclusion

The gentleman who emailed me said that he was reading a lot of books in hopes of becoming an ‘expert’. While I’m not going to tell you not to read books (you should!!), I will tell you that there is no substitute for doing. All of things I’ve talked about above are ALL about doing. Reading is not doing, it’s reading. It’s passive and will not get you further in your career. There’s no place on a resume for the books you’ve read. Take what you’ve read and put it into action, then you’ll be on your way to becoming an ‘expert’ developer.

In August I announced CoverMe a code coverage tool for Ruby 1.9. Well, today I announce that it has hit it’s first release candidate! I’ve very excited by the fact it’s getting close to an ‘official’ release.

The response to CoverMe has been great and through feedback from the community I’ve made a lot of improvements and fixed a lot of issues.

While quite a few things have changed under the hood, not much has changed in how you use CoverMe.

Installation

The following are instructions for how you would configure CoverMe for a Rails 3 project, adjust to your local environment accordingly.

In  your Gemfile add the following:

gem 'cover_me', '>= 1.0.0.rc1', :group => :test

Then run:

$ bundle install

After CoverMe is installed place the following line at the VERY TOP of your ‘test_helper.rb’ or ‘spec_helper.rb’ file (for Cucumber put it at the top of the ‘env.rb’ file):

require 'cover_me'

I can’t emphasize enough how important it is that the require statement is at the VERY top of that file!

Finally (and optionally) run:

$ rails g cover_me:install

This will simply install a Rake task that will wrap both Test::Unit and RSpec tasks with CoverMe and will launch the results at the end of the test suites. I would recommend it. It’s kinda the whole point.

That’s it!

Enjoy the release candidate, and of course, please let me know if you find any issues with it. Issues can be reported on here.