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!

Last night I had the pleasure of presenting to the Boston Ruby User’s Group on CoffeeScript. My talk was geared to helping Rubyists understand, and hopefully love, CoffeeScript. Along the way I tried to debunk a few myths and preconceptions as to what CoffeeScript is and isn’t. The reaction was really positive, so hopefully I did my job. Anyway, here are the slides:

http://www.slideshare.net/markykang/coffeescript-bostonrb-892011

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.

Twitter is an incredibly rich source of information. I find out about new libraries, applications, plugins, screen casts, etc… But, there’s a problem with is overwhelming amount of information… keeping track of it all. A lot of time I read Twitter when I’m on my phone. I’ll see a link to an article or website, etc… but I don’t have time to read it then, what do I do? How do I find that tweet later? Or what about that announcement or news link for a new service or application that I saw six months ago? How do I find that again?

Twitter is great but it’s ability to help you find specific tweets that are important to you is almost important. That’s why today I’m happy to announce TweetKO.com. TweetKO solves this problem by using the built ‘favorite’ functionality that Twitter offers. From ANY Twitter client you can simply mark a tweet as a favorite and TweetKO will pull it in and save it for you so you can find it later.

That’s it! It really is that simple. TweetKO is FREE and easy to use. In addition to pulling in your favorite tweets you can tell TweetKO to also pull in any tweets you wrote or retweeted, effectively backing up your Twitter history. A powerful search makes finding those tweets simple and easy. Plus you can save those search queries for later use.

Well, I hope you check out TweetKO.com and find it as useful as I do. Enjoy!

http://tweetko.com - Sign up for Free Now!

About six weeks ago I announced FluxTracker.com a unified issue, document, and error management service. The response has been amazing. People love that you can now manage all of those things in one place, without any configuration. Well, today I’m happy to announce that FluxTracker has taken the next step forward to make managing all aspects of your project easier. Introducing FluxTracker Feedback.

FluxTracker Feedback allows you to put a little feedback widget on your site that can be used to collect information from your users, such as feature requests, support requests, and general comments. This feedback is automatically added to your FluxTracker project and from there it’s up to you to decide what you want to do with it. Of course it supports FluxTracker’s Issue Connect system so you can turn that customer feedback into an actionable issue with just one click?

Now you’re probably saying to yourself, I bet it’s really difficult to implement on my site. Well, you’d be wrong! It’s as simple as just adding one line to your site:

http://www.fluxtracker.com/pages/api/feedback

The widget can be customized too. CSS, text, and even the questions can be customized (well, depending on the plan you’re on). Just check out the Feedback tab on the right side of the page to see the Feedback widget in action.

Well, as you can tell I’m very excited about this. I think it really makes FluxTracker the true center for managing your application, and I think  you’ll find that too. Enjoy!