Text

· · to read

I knew this was coming before the Mac App Store was announced. Few believed it back then. When Apple first announced its Mac App Store, more believed it. Now that Apple has set a deadline for sandboxing, some people still don’t believe it.

I believe that I should be allowed control over my computers. This is not dependent on the distinction between client and server, or between web and native. I also don’t buy the argument that it’s different when talking about so-called appliances like the iPad, which are really just crippled general-purpose computers.

One of the first things I’m going to do about it is to switch to something other than Mac OS X or Windows for desktop computing.

Text

· · to read

With the Rails 3.1 Asset Pipeline, there’s the rake assets:precompile command which precompiles assets into public/assets along with a manifest.yml file which rails uses to put the paths to the assets in its templates. Precompiling generates a few files, which can clutter commit logs if they’re committed. For this reason I might add public/assets to my .gitignore and build them on the server, rather than committing them to git and uploading them. Or, if the server had trouble compiling them, I might precompile them locally, and scp them up rather than committing them to git, because they can make a lot of noise in my git logs.

On Heroku, though, git is the only way to deploy. So if I’m having trouble having heroku precompile them, I need to commit them and push them via git. This could clutter up my commit log.

There is a way around this, though: use a branch! If I create a branch just for heroku, and just commit them to the branch, I can keep my commit logs free of changes to public/assets.

Here is a sketch of this process:

  1. Add public/assets to my .gitignore and commit it
  2. Create a heroku branch with git checkout -b heroku
  3. remove public/assets from my .gitignore and commit it. This just affects my heroku branch.
  4. Run RAILS_ENV=production rake assets:precompile there.
  5. Run git add . and git commit -m 'precompile assets' to commit the files to my heroku branch
  6. Run git push heroku heroku:master to push my heroku branch to heroku as master (heroku only uses the master branch)
  7. Run git checkout master and continue development on my master branch.

A deploy rake script could be used to automate this.

The heroku branch wouldn’t need to be pushed to github, because it doesn’t contain any information that can’t be regenerated. The only reason the history would need to be preserved is so it can be cleanly pushed to the heroku app. Fortunately, if the local repo was lost, it’s possible to pull from the heroku repository. Heroku shouldn’t be used as a place to store git repositories because the lifecycle for a heroku app is often different than that of a repository. For this purpose, though, the usefulness of the old assets commits is tied to the life of the Heroku app so it works out well.

Text
· · to read

I believe that water is the only drink for a wise man.

— Henry David Thoreau (seen in the lobby of Hotel Palomar in San Francisco last week)

Text
· · to read

To believe your own thought, to believe that what is true for you in your private heart is true for all men,—that is genius.

— Ralph Waldo Emerson

Text

· · to read

I’m developing a Rails site that uses MySQL and runs on Heroku. I’m using Xeround for the database, which has a free trial. Xeround is a database PaaS (Platform as a Service) that runs on several places, including Amazon Web Services in their U. S. East region, which is where Heroku runs. Running it in the same place where Heroku runs gives it a low latency.

To set up Xeround, sign up for an account and set up a database instance in the AWS U. S. East region. Go to the page for the database instance, and you will see the username and the database URLs.

Rails reads its database configuration from config/database.yml. Heroku overwrites config/database.yml with a file it generates from the DATABASE_URL configuration variable. The configuration variable uses the database driver name as the network scheme (e. g. mysql://). There is more than one mysql driver for Rails; the one suggested in the Rails Guide is mysql2.

To use mysql2 as the database driver with Xeround, use the following for the DATABASE_URL configuration variable:

heroku config:add DATABASE_URL='mysql2://{{username}}:{{password}}@{{hostname}}:{{port}}/{{dbname}}'

The username, hostname, and port number can be seen on the DB Instance Manager page on Xeround. The hostname and port are under one of the three DNS Names; I picked the top one. The password is what was entered for the database password during signup. The database name is the name of the database to be added using PHPMyAdmin.

The driver also needs to be included in the Gemfile. To include it just for production, use:

group :production do
  gem 'mysql2'
end

After adding this, run bundle install, commit your changes, and push to Heroku.

The database still needs to be created. To create the database, click on one of the links under DNS Names on the DB Instance Manager. This brings up PHPMyAdmin. Enter the database password and log in. Then create the database, with the same name used for the DATABASE_URL configuration variable.

Now that the database has been created, the DATABASE_URL is set, and the Gemfile is updated and pushed, you should be able to migrate the database by running heroku run rake db:migrate.

I’m using the latest version of Rails (3.1.1) on Heroku’s cedar stack.

It will be interesting to see how well Xeround works for this project. There are other MySQL hosting options for EC2 if I need them, and migrating is fairly simple.

Text

· · to read

After setting up some Heroku addons I got used to using environment variables to specify add-on settings. I then started using them for non-addon settings, and now I’ve started using them outside of Heroku a bit too.

One area where they work well is for a Heroku-deployable open source app with OmniAuth GitHub OAuth integration. Here is an example initializer (config/initializers/omniauth.rb) from a RailsCast:

Rails.application.config.middleware.use OmniAuth::Builder do
  provider :github, 'CLIENT_KEY', 'CLIENT_SECRET'
end

I would replace CLIENT_KEY and CLIENT_SECRET with my own keys, but I can’t commit them to a public repository, or else another person could use them and I could be held responsible. Rather than leave out my client key and secret using a .gitignore and a sample config, I can use an environment variable:

Rails.application.config.middleware.use OmniAuth::Builder do
  provider :github, ENV['GITHUB_CLIENT_KEY'], ENV['GITHUB_CLIENT_SECRET']
end

With a note in the README about the environment variables used, this should be easy for developers to set this up on their own private apps.

So far I’ve been typing environment variables into the command line when running apps locally and on my VPS, but that’s about to change. I may specify them in my nginx config, which is backed up to a private git repo. I’m not sure yet. Also I’m going to dump out my Heroku environment variables and back them up too.

Repositoryomniauth
Ownerintridea
Text

· · to read

I started building a Rails 3.1 app that runs on Heroku using the Cedar stack. In this app I really want to take advantage of the Rails 3.1 Asset Pipeline. I’m using CoffeeScript, Sass, and Compass. The former two come with Rails 3.1 but I needed to add Compass myself. I used the instructions here, but used the latest version of Compass because it now works, and I added a check in the initializer to see if sass was loaded. The check in the initializer is needed because Heroku only runs with the asset gems from the Gemfile when it compiles the assets, and it only compiles the assets when a new slug is loaded. So what happened is that the Rails 3.1 initializer, sass.rb, tried setting a configuration parameter in sass when sass wasn’t loaded.

Here’s the relevant code. The asset section of my Gemfile now contains compass:

group :assets do
  gem 'sass-rails', "  ~> 3.1.0"
  gem 'coffee-rails', "~> 3.1.0"
  gem 'uglifier'
  gem 'compass'
end

…and I added config/initializers/sass.rb:

if Rails.configuration.respond_to?(:sass)
  Rails.configuration.sass.tap do |config|
    config.load_paths << "#{Gem.loaded_specs['compass'].full_gem_path}/frameworks/compass/stylesheets"
  end
end

It uses respond_to? to see if it there is a sass configuration object.

Right now I’m using Compass to set a border radius.

Text

· · to read

Here is a list of a few awesome sites offering tools for learning Rails:

PeepCode

Pricing: Starts at $12 for one screencast; Twitter: @peepcode and @topfunky

I bought my first PeepCode screencast back in 2008, before Rails and Merb merged. It’s been around for a while, but Geoffrey Grosenbach does a great job of keeping it up-to-date. There are now a number of screencasts about current topics of interest to the Ruby on Rails community, including Rails 3, Backbone.js, PostgreSQL, CoffeeScript, and John Barnette.

Railscasts

Pricing: Free weekly episodes, additional weekly episodes and revised episodes for $9/mo (RailsCasts Pro); Twitter: @railscasts

Railscasts is great for keeping up on Ruby On Rails, and because it’s free, it’s also great for recommending to people who are curious about Rails but not ready to spend money to help them learn it. Ryan Bates is great at explaining things. He covers a wide variety of topics in his screencasts and presents them in a nice format with code snippets.

Update: since I posted this Ryan Bates released Railscasts Pro, which is fantastic!

Ruby on Rails Tutorial

Pricing: $26 (book), $85 (screencasts), $95 (both); Twitter: @railstutorial

Michael Hartl is a physicist who does a number of other things (see his about page) including Web Development with Ruby On Rails. I’ve watched all of his screencasts; they’re fantastic. He builds a web application TDD-style and teaches many different concepts including MVC and how TDD can help with authorization (which is trickier than authentication IMO).

Rails Apps

Pricing: Free; Twitter: @rails_apps

I always thought that the Rails Starter App templates were cool, but they were missing something: in-depth tutorials and a comparison between the many different templates and quick-start tools. Daniel Kehoe has provided both and many more useful resources in his Rails Apps GitHub account.

Code School

Pricing: Free (one substantial free product), $45-55 (single paid products); Twitter: @codeschool

Code School is a set of tutorials designed to help developers to quickly get up to speed building web applications. Gregg Pollack and Envy Labs have been doing podcasts and screencasts for quite some time, and it’s not surprising that they still do it, because they’re very enthusiastic in front of a camera and a microphone.

Text

· · to read

I put my SyntaxHighlighter Brush Pack on WordPress.org, using the excellent git to WordPress.org Subversion instructions to preserve history.

In order to check that it works, I moved my plugin (installed as a git submodule) outside the wp-content/plugins directory, went to Add Plugin, searched for it, and instructed WordPress to automatically install it. It works! The following CoffeeScript code was highlighted using it:

launch() if ignition is on

If you use WordPress and either CoffeeScript or Clojure, I’d love for you to give it a shot!

Repositorywordpress-syntaxhighlighter-brush-pack
Ownerbenatkin
Text

· · to read

Faraday

Faraday is an high-level HTTP client library with middleware support, and support for multiple low-level HTTP client libraries. It can be used just by adding it to the Gemfile and running bundle install, just like RestClient can. Or, a different library can be added to the Gemfile and then used through one of its adapters.

Faraday Middleware

The faraday_middleware library, which was started by Wynn Netherland and has been maintained by Erik Michaels-Ober, contains a bunch of middlewares for authentication, response parsing, and convenient hash objects.

Faraday Stack

Faraday Stack is a pretty generic yet convenient API client. It encodes JSON, parses XML and JSON, follows redirects, and raises errors. In short, it works like many expect custom API clients to work, yet it can be used anywhere, just by specifying the domain. It doesn’t include authentication, which ships with many API clients, but that can be added easily by looking at the source for the stack and adding authentication from another library into it. It’s better than many custom API clients, so if an API client is the slightest bit frustrating, it may be a good idea to use faraday_stack instead.

I really like Faraday, because it lets me choose which HTTP library I’m going to use, which is different between Ruby and JRuby. I often use Faraday by itself even when a custom API client is available. I also will use it in irb (next time, pry) instead of curl at times.

Repositoryfaraday
Ownertechnoweenie
Repositoryfaraday_middleware
Ownerpengwynn
Repositoryfaraday-stack
Ownermislav
Text

· · to read

I’m working on a plugin for displaying infoboxes for URLs called Resource Infobox. The interface is a shortcode with a single url property. To include an infobox, use an expression like the following:

[resource-infobox url="https://github.com/benatkin/wordpress-resource-infobox"]

This will show an Infobox with some basic information:

Repositorywordpress-resource-infobox
Ownerbenatkin

Examples of Infoboxes include those on Wikipedia, in the upper-right corner of pages, and the old Crunchbase ones I saw on TechCrunch:

The neat thing about the ones built by this WordPress Plugin is that it renders based on some JSON rules. The current rule file has two resource types, GitHub Repositories and GitHub Users. These are not limited to GitHub, though; with the current implementation they could be written for twitter, Crunchbase, and any URL that has straightforward mapping from the HTML url to the JSON url. Here are the current rules:

{
  "github": {
    "repository": {
      "url": "https://github.com/:owner/:repo",
      "api_url": "http://github.com/api/v2/json/repos/show/:owner/:repo",
      "fields": [
        {
          "label": "Repository",
          "param": "repo",
          "url": "https://github.com/:owner/:repo/"
        },
        {
          "label": "Owner",
          "param": "owner",
          "url": "https://github.com/:owner/"
        },
        {
          "label": "Last Commit",
          "path": "repository/pushed_at",
          "type": "date",
          "format": "Y-m-d"
        },
        {
          "label": "Watchers",
          "path": "repository/watchers"
        }
      ]
    },
    "user": {
      "url": "https://github.com/:username",
      "api_url": "http://github.com/api/v2/json/user/show/:username",
      "fields": [
        {
          "label": "Username",
          "param": "username",
          "url": "https://github.com/:username/"
        },
        {
          "label": "Followers",
          "path": "user/followers_count"
        },
        {
          "label": "Respositories",
          "path": "user/public_repo_count"
        }
      ]
    }
  }
}

It’s a JSON DSL inspired by the DSL for Django’s admin interface. It has few features now, but following Django’s lead, it can have more features added to it while retaining its essence. The nice thing about using a JSON DSL rather than custom code is that it can easily be validated, and due to its declarative nature, XSS attacks and other undesired behavior can be avoided. It uses WordPress’s esc_attr and esc_url functions to render strings.

I’d love feedback on this. My goals for it include:

  • Caching (WP Total Cache greatly reduces requests to GitHub’s API on this page)
  • Adding more resource types
  • Adding more field types
  • Adding more display customization
  • Adding instructions for using code from this plugin as a base for other Infobox embedding plugins
  • Improving the resource type DSL
  • Building an editor for creating custom resource types
  • Supporting grabbing a resource type definition based on a custom header of a resource (like X-Infobox-Resource-Type)

I’d also like to make this work with more than just WordPress.