1

config.assets.initialize_on_precompile = false

Once you do that, however, asset precompilation won’t trigger your Rails engine’s initialization, so even if you’ve set up your engine’s assets for precompilation as described in the Rails Engine Guide, your assets won’t actually get precompiled. Why? Because when initialize_on_precompile is disabled, only :assets initializers are run during precompliation.

The trick is to get Rails to run your engine’s initializer during asset precompilation even though it’s not actually initializing your whole application. The magic incantation for that is to pass a special :group => :assets or :group => :all option to your engine’s initializer, and make sure you configure your precompiled in that initializer.

1
2
3
4
5
6

initializer "RocketEngine asset precompile", :group => :all do |app|
  app.config.assets.precompile += %w(
    rocket.css 
    rocket.js
  )
end

Voilà!

I first got this working by specifying :group => :assets, but it turns out that :assets is only used during asset precompilation when initialize_on_precompile is explicitly disabled. So if you want your engine’s asset precompilation to work on other platforms as well as Heroku you should use :group => :all (which is special-cased to always run).

In short, it was a great conference—well worth the cost of admission and the time spent. There were two days of really great talks (and a third day of tutorial/workshop sessions that I didn’t attend) put together by developers who really want to share their knowledge.

I especially enjoyed the relatively small size of the conference, since it really brought everyone together and felt like an actual community rather than just a crowd. OSCON is a great conference, but it’s so huge that it’s hard to make a real connection there.

The speakers for the conference also included a bunch of local experts, so I got to put some faces to some names that I have seen float past on the local CocoaHeads mailing list. Janine Ohmer (@janineanne), who manages that mailing list, gave a great talk on everything to do with making an app except the coding (including such favorite developer pastimes as Marketing and Documentation). Justin Miller (@incanus77) of MapBox had a nice overview of MapKit APIs and also showed off some MapBox tools that can be useful when you need to go beyond what MapKit offers.

There were lots of other great sessions, too, and my notes from them go on for thousands of words, but here’s a short list of some of the most memorable pieces of advice I picked up:

• Not everyone will be delighted with your work, but your app is not for everyone - Daniel Steinberg (@dimsumthinking)
• You can typdef Objective-C blocks and set up blocks as properties to make
  them convenient to pass around in your APIs - Daniel Steinberg (@dimsumthinking)
• If you have some bits of data that you need to persist across a delete/restore of your app, you can put them into the keychain - Walter Tyree (@walterpt)
• MapBox has some handy tools for making maps work offline - Justin Miller (@incanus77)
• You can add your own storage implementations to Core Data and do some wild and interesting (and possibly even useful) things - Jonathan Penn (@jonathanpenn)
• XCode’s Storyboards are pretty useful and pretty awkward/painful at the same time (I’ve used them a bit, but apparently haven’t hit the pain points yet; hopefully things will get better since it seems like Apple is pushing Storyboards these days) - Collin Donnell (@collindonnell)
• NSCoding and NSValue will let you put pretty much anything into Core Data with a modicum of effort - Walter Tyree (@walterpt)
• mogenerator makes using Core Data’s model code generation tools much more convenient and practical - Walter Tyree (@walterpt)
• XCode lets you play a sound at a breakpoint, which is handy for when you need to hear when or how often something is happening without interrupting your code - Kyle Richter (@kylerichter)
• When making an iPhone app, you only have about 11 characters for the name before it starts getting cut off on the home screen - Janine Ohmer (@janineanne)
• You can use Data Detectors in iOS to clean up poorly formatted data you ingest from somewhere else and turn it into nice structured data - Colin Cornaby (@colincornaby)

One final note of awesomeness: Jean MacDonald (@macgenie) was running App Camp for Girls for the first time this summer, and brought some of girls to the conference. They added immeasurably to the roundtable discussion on Women in Tech, and I hope they got a lot out of the conference (in addition to the books that I heard the fine folks from Big Nerd Ranch gave them!).

I’ve been spending some of my free time creating a Ruby Gem for Rails apps that makes it easy to set up tables with fixed data that you want to always be present in your database: static-data. This is handy for lookup tables, predefined category lists, and other such things.

The Problem

I created some new files to add a new rails generator to static-data, I built and installed my gem, and… nothing. In researching other people’s challenges in getting their generators to work, I tried moving my generator file all over the place. I even tried adding extra code to my railtie to tell Rails where the generator file was, but that just caused rails generate to blow up entirely when it couldn’t find my generator file.

After scratching my head for more than a few minutes, I hacked up an existing gem that was showing up in rails generate, tracked down the code that attempts to require generator files (which contains a rescue clause that swallows all errors in a generator being required—bad code! no biscuit!), and eventually figured out that my generator file wasn’t even included in the installed gem files!

The Solution!

Then it dawned on me: the gemspec for my static-data gem is set up to populate the gem’s file list from git ls-files, but since I’d set that up a few weeks ago (I don’t have much free time, and it tends to come in small, infrequent chunks), I had totally forgotten that little—but very important—detail.

Once I did a git add lib/generators in my gem repository, rebuilt and reinstalled my gem, the generator was finally listed in rails generate and with a few tweaks to my template, my generator was in business.

Apparently this particular gotcha isn’t biting too many other people, since no one ever mentioned this in my search for clues on the interwebs. Nevertheless, I am writing this detail down so hopefully the next person with this issue won’t have to scratch their head for quite as long as I did.