Prototypal Objects at Chicago Javascript

A short into to Javascript objects and prototypes.

Javascript objects are basically maps from strings to values, witha few extras, like dot indexing and prototypes. Prototypes are a way of relating objects so that one, the prototype, can provide default values for another. I find prototypes are simpler and more supple object model, though it may not be as familiar to those experience in class based systems.

Comments Off

Paths, Properties, Paint: HTML5 Canvas and the Pervasive Pixel Painting Protocol at Chicago Web Conf

Sometimes, stacking divs and fiddling with CSS just doesn’t cut it. The canvas tag gives us an escape hatch – an infamous blank rectangle. Unlike applets and Flash, canvas is orchestrated by the same javascript you already use to run your web site. Canvas is a strange beast however; while it gives us a “blank canvas” perfect for painting and blending effects, the API is largely vector based, which makes it easy to do shapes and outlines that can be smoothly transformed.

We’ll take a (brief) peek at how this bizarre combination came about, and then dive into the way canvas “thinks” – the drawing model that you’ll need to bend it to your will.

One comment so far, add another

Paths, Properties, Paint: HTML5 Canvas and the Pervasive Pixel Painting Protocol at Elgin Technology Center

Sometimes, stacking divs and fiddling with CSS just doesn’t cut it. The canvas tag gives us an escape hatch – an infamous blank rectangle. Unlike applets and Flash, canvas is orchestrated by the same javascript you already use to run your web site. Canvas is a strange beast however; while it gives us a “blank canvas” perfect for painting and blending effects, the API is largely vector based, which makes it easy to do shapes and outlines that can be smoothly transformed.

We’ll take a (brief) peek at how this bizarre combination came about, and then dive into the way canvas “thinks” – the drawing model that you’ll need to bend it to your will.

Comments Off

Android

I got an Android a few months ago for some mobile web app testing. (I then proceeded to focus my attention to wrestling dragons for said web app, which didn’t leave much time for blogging.)

I really hope they they’ve worked on user experience, because my onboarding experience was absolutely awful – it was several hours before I was able to successful type the username and password to my google account, and the phone refuses to do anything until you’ve set up a google account. I had more trouble setting up other apps and services, and in some cases ended up sending passwords to myself, because I was really just that sick of typing in the same sequences over and over on a crummy touch keyboard.

The Swype keyboard is fairly nice for normal text. Even so I don’t relish typing a mobile screen, so I mainly end up entering login information, where alternate keyboards aren’t much help.

I didn’t get the latest-greatest model (which changes weekly anyway), both because I don’t have steady income, and because I wanted to see what a typical user experience would be like. I got a T-Mobile LG Optimus-T, which comes with Android 2.2.2. I’ve since unlocked the phone, but from what I can tell, I wouldn’t be able to take much farther in the Android versions because the hardware requirements increase with each release.

It still runs my geolocation-based web app, so I can use it “in context”, which was the whole point of the exercise. It’s also able to run Disk Clock fairly well, although the app-switching use case is making me reconsider the startup animations even further. (The fact that it’s running Disk Clock at all hints at some other stuff I need to get around to publishing.)

I also realized I should probably have a case for carrying it around. I got a soft case – it seemed (quite unscientifically) that a hard case would just transmit any shock through to the phone. I assumed it would have cut-outs for the buttons, but in fact there are specially designed extrusions, with a peak to push the button an a thin area around to allow it to move.

The new device also pushed my “charging station” over the edge. I don’t know how tolerant the devices are of slightly off input-power, so I’ve kept around each power supply. I pulled out the twist-ties to keep the cables straight – a technique I’d been using the keep the computer and power iPad cables sorted out.

Comments Off

On the Inception of the Ruby Object System, at Chicago Software Craftsmanship

Class, superclass, metaclass, singleton class, eigenclass, class <<self, class Class, Class.new. We all know that Ruby is an object oriented language, and specifically it is a class based language. One of the strengths of Ruby is that it can be extremely usable without having to really understand what’s going on behind the scenes. Drift from the happy path, however, and you can find yourself wandering in a dream-world of class<<self or trying to grok the difference between ‘include’ and ‘extend’. This talk will try to explain why we have classes and metaclasses, and how it all hangs together (and a bit about the movie Inception, to keep things from getting too boring.)

Comments Off

On the Inception of the Ruby Object System, at Chicago Code Camp

Class, superclass, metaclass, singleton class, eigenclass, class <<self, class Class, Class.new. We all know that Ruby is an object oriented language, and specifically it is a class based language. One of the strengths of Ruby is that it can be extremely usable without having to really understand what’s going on behind the scenes. Drift from the happy path, however, and you can find yourself wandering in a dream-world of class<<self or trying to grok the difference between ‘include’ and ‘extend’. This talk will try to explain why we have classes and metaclasses, and how it all hangs together (and a bit about the movie Inception, to keep things from getting too boring.)

Comments Off

On the Inception of the Ruby Object System, at ChicagoRuby

Class, superclass, metaclass, singleton class, eigenclass, class <<self, class Class, Class.new. We all know that Ruby is an object oriented language, and specifically it is a class based language. One of the strengths of Ruby is that it can be extremely usable without having to really understand what’s going on behind the scenes. Drift from the happy path, however, and you can find yourself wandering in a dream-world of class<<self or trying to grok the difference between ‘include’ and ‘extend’. This talk will try to explain why we have classes and metaclasses, and how it all hangs together (and a bit about the movie Inception, to keep things from getting too boring.)

Comments Off

Debugging the Rails Asset Pipeline with Heroku Buildpacks

When I was working on a Rails 3.0.3 application trying to speed up the user experience, tools like YSlow and PageSpeed kept tell me to do things that would have been so much easier in the asset pipeline – combine, minify, and so on.

In my current 3.1.1 application, I’ve found that assets can be really slow in development mode – probably why they optimized dev mode for 3.2. One solution involved tracking down some misconfigured static asset serving in my rails engines. Another step involved turning off a lot of autoloading during asset serving.

Debugging the Asset Pipeline on Heroku

There are a number of challenges to run the asset pipline on heroku, especially when you insist on running an unconventional rails layout, and requirejs-rails to boot. The biggest challenges are that the error messages are awful, and the uniqueness of the environment, which means that local testing of the asset compile step only gets you halfway there. You also have to get the precompile step to run at all.

Get it to compile locally

I skipped this step at first. There are number of simple things which could be wrong – such as having config.assets.compile or config.serve_static_assets off. While I have no reason to run precompiled assets locally, it’s still possible to run rake assets:precompile.

Start running the rake tasks from the rails directory to make sure the basic process is working. Once that runs, run rake assets:clean and try again.

Get it to compile from the repo root directory

I ran into a lot of trouble here because the asset precompile process actually shells out to new rake instances, which start from scratch, context wise. Since I had made loading rails conditional in my base rakefile to make running other tasks faster, this didn’t work out of the box. I set up the asset tasks to depend on a task which changed the directory. Then when rake shelled out, it ran in the rails directory and picked up the standard rails rakefile.

Compile with a bogus database address

If you have set up your project to use Heroku-style DATABASE_URL by default, this is just a matter of passing the right variable.

DATABASE_URL=postgres://foo/bar rake assets:precompile

Sometimes code will connect to the database during precompile, but Heroku doesn’t have a database available at that time. I ran into this problem with ActiveAdmin I had to add a hack to prevent loading ActiveAdmin routes in routes.rb (fixed upstream)

break if ARGV.join.include?('assets:precompile')

Get asset precompilation to TRY to run on Heroku

My application was coming up as a Ruby/Rack application. This was enough to get it to run, but asset precompilation wasn’t running, which broke some pages. The odd directory structure was throwing it off, so we’ll need a few concessions to standard rails directory structure. But which ones? Reading the Heroku Ruby Buildpack source tells us that it needs two files to exist:

config/environment.rb (to show up as Rails 2+)
config/application.rb (containing Rails::Application, to also be Rails 3+)

Debug asset compilation with a custom buildpack

At first the error I was getting looked like a Ruby syntax error. The only sense I could make sense of it, however, was as a Javascript syntax error. Unfortunately, the reference was to a line number in a combined file, before minification destroyed the line numbers. This can be worked around by temporarily setting config.assets.compress = false in production.rb. Now I could see that javascript was choking on Coffeescript which hadn’t been translated.

But what is actually going wrong? Some information can be gotten by running rake with --trace – but we don’t control the precompile command on Heroku. However, we can.

On the latest Cedar stack, Heroku has built a much more versatile platform, that can and does run systems other than Rails and Ruby. This process is orchestrated by buildpacks, which literally run the slug compile by calling a small number of programs, which then do pretty much anything they like. The Ruby buildpack is conveniently written in Ruby.

Since the buildpack is just code, we can modify the asset call to include the --trace flag. (You could use my ruby buildpack fork, but I might make more changes at any time, and heroku appears to use it ‘live’.

Heroku’s platform has multiple buildpacks. Each includes a detect script that tries to determine if a repo is appropriate for it. I don’t know whether a custom buildback becomes exclusive, or just get’s first crack at the project. In any case, it appears that the only way to use a buildpack is to set it at instance creation time, so I created a new one for asset debugging.

heroku create --stack cedar --buildpack http://github.com/heroku/heroku-buildpack-ruby.git

Use Your Node

The problem turned out to be a missing node binary. In order to enforce it’s total isolation, Heroku gives each slug compile it’s own local, relative bin/node Since I had proven locally that the easiest way to make the forking rake behave was to cd into the rails subdirectory, it no longer had node at the correct relative path. I created a railshost/bin/node script to call the appropriate path (make sure to pass the arguments!) Heroku Support later suggested a link, though I was leery of running a link through the version control system.

Checklist

  • Check your config variables
  • Run it locally
  • Change directories as necessary
  • Add stubs to make project detect as Rails
  • Make sure you aren’t connecting to the database
  • Make sure you can use the project-relative path bin/node
  • Turn off asset compression to investigate JS errors (and don’t forget to turn it back on)
  • Use --trace to debug rake tasks
  • Use a custom buildpack to debug the process on Heroku.
Comments Off

I Spilled Queue All Over Myself

My program has a data import process, which will need to get refreshed from time to time. I started out focusing on the code. Tests ran things for a long time. I prepared fairly high level operations, and then wrapped Rakefile around them. There was still a lot of setup code, so I extracted an even higher level set of operations from the rake, so they could be just as easily driven by code. Now I just need some way to trigger those operations.

The application is hosted on Heroku at present. Heroku provides a scheduler add-on that goes up to a day (though a week would probably be sufficient for my purposes). However, Heroku wants large jobs done by worker processes, and the policy is to cut off others that run too long.

This naturally leads to the use of some sort of communication system to instruct the background workers do something. Commonly, some sort of queue is used, and Resque in particular has been getting some buzz lately. There is a free Redis add-on at Heroku, which is limited by size – not a concern for a communication structure.

Resque queues a class name and a set of parameters. Class names are handy because they are global constants, which can be looked up at the other end – if you want to get really technical, it doesn’t even have to be the same class. Resque calls a perform method on the class, passing the parameters.

This sounds pretty handy, at first blush. Just define a perform method (and which queue to put it into) and pretty much anything can become a background job, without having to inherit from some special class or anything of the sort. The problem of course, is that you can put it everywhere.

This became especially evident when I added heroku worker autoscaling to avoid having an expensive process running all day to support what will often be a few seconds of work each day. (IronWorker looks interesting, but can’t access Heroku’s shared databases yet.) The autoscaling module has be mixed into to each class which is acting as a worker. As I started out, this involved a fair bit of repetition. Now, there are of course methods to handle the repetition, but between that and sprinkling perform and queue around I was getting queue all over the application.

So, time for a new gem. The background gem has a module to wrap up the autoscaling and other common configuration. It also becomes the only piece of the application which has a direct dependency on the underlying queuing system (should Reque prove inappropriate at a later time) The background module depends on any other gems that needs in order for the background jobs to get their work done.

Comments Off

Putting Rails in it’s Place

Rails likes to own your application. It gets pride of place in the project’s root directory, setting up it’s app, config, and db. If Rails is just a delivery mechanism, why does it get the root directory?

I’ve got an application which ended up being more backend logic than CRUD. I’m starting to wonder if Rails is even an appropriate vehicle. In any case, I’ve broken out Rails-independent pieces into vendor/modules. This has worked fabulously, expect I’m getting really tired to typing vendor/modules, even with auto-complete.

Vendor is a piece of rails convention that says it’s something alien and outside the application, tacked on. In fact Rails is feeling more and more alien. Getting it out of the way was a multiple step process.

  1. Extract the core functionality into a Rails engine, hopefully flushing out some dependencies.
  2. Lift the Rails host application into vendor/modules
  3. Chop out vendor/modules so that the app is a directory full of gems.

The first step is fairly standard gem extraction – filling out a gemspec, shuffling Gemfile dependencies, adjusting some paths. There was one little hiccup with Bundler that I want to write about separately, but it comes down to making sure that the new engine requires all it’s dependencies from lib/mygem.rb. The rest is paths, paths, paths.

Autoload Paths

Once the main Rails app is at the same level as the modules, the autoload path has to change from Dir["#{config.root}/vendor/modules/**/lib/"] to Dir["#{config.root}/../**/lib/"]

Gemfile

As a precursor to the refactoring, I changed from a block form of path, to an imperative form, giving it the same effect as source. This allowed gemspecs to search the right places for my custom gems, without having to list each one in the Gemfile. Once the modules got dropped a few levels, the master Gemfile had to change from specifying a path of 'vendor/modules' to '.'.

My master Gemfile has lot more direct references than I would like, but gemspecs don’t allow for the kind of grouping that the standard Rails bundler configuration thrives on.

The rails command

The rails terminal command looks for script/rails to determine whether it’s in a rails project. Without that, you do have to type out railshost/script/rails, but from there everything is normal.

git

I found that the default .gitignore wasn’t covering some files in the moved rails directory, so I copied the file and adjusted both copies appropriately for their new positions.

Heroku

A lot of changes relate to running on Heroku, because it’s designed as a generalized hosting system and can’t know about my custom directory structure. Fortunately between Rails, Rack, and Heroku there are enough hooks to make everything work out. (Note: I’m running on the cedar stack.)

Gemfile

I already mentioned Gemfile a little, but remember that Heroku is only going to install a Gemfile at the project root.

config.ru

I knew from some previous research on running Rails in a subdirectory on Heroku that it was possible. Essentially, Heroku looks for a config.ru “rackup file”, which Rails includes by default. Heroku just needs a rackup file at the root level, pointing at the appropriate place.

Rakefile

Many tasks happen by way of the base level rake file. In particular it’s how background workers and other processes are often launched. A copy of the Rails Rakefile with appropriately adjusted paths should do the job. (Myself, I’m using a modified copy for tasks that aren’t part of the rails app.)

Procfile/Foreman

I started using Foreman a little while ago, both to identify my own worker command, and to start up a set of support processes for local development. A well configured rakefile will obviate some needs, but I had to adjust the path to the rails command for running the server, as well as some configuration paths for Postgres and Redis in my development environment.

database.yml

Under normal circumstances, Heroku can detect that you’ve got a Rails app and update the database.yml file to parse out their DATABASE_URL. Move the file from it’s standard location, however, and they just aren’t that clever. You can see what Heroku’s standard database.yml looks like by running a heroku console on a standard rails app and simply printing it out.

>> puts File.read('config/database.yml')

I ended up with dash of Sequel on top of ActiveRecord, so I had already developed a DatabaseSpecification gem to translate between schemes, which made for a less verbose database config file. I was able to copy the dynamic development configuration to the production block and carry on with little trouble.

Files to watch

  • application.rb
  • config.ru
  • database.yml
  • Gemfile
  • .gitignore
  • Procfile
  • Rakefile
  • calls to rails
Comments Off