I just put Jammit into production in one of my Rails applications. We had... well, kind of a lot.. of assets, mostly JS and CSS, and it was getting both hard to work with and rather taxing on my servers. When one page load takes 30 requests, then it's time to get some asset management in place. We're still on Rails 3.0 (a couple of gems not available for 3.1 yet), so I went with Jammit for now.
Overall, the move was easier than I expected. However, there are a few things that tripped me up. That's what today's blog post is about: the lessons I learned implementing Jammit.
Lesson 1: LOVE
First of all, I would like to complement the Jammit guys. It's supremely easy to use, and it just plain works, once you figure out what you're looking for.
Lesson 2: Use external URLs for compiling
Many of my requests are for images, almost all of them under 10K. I embedded these images in my css files. Jammit makes this easy; you just set embed_assets to on, then make sure your images are in your CSS (i.e., background images instead of image tags in the source). Then you just type:
jammit --base-url "http://my-server"
I got tripped up, though: the base-url must be an external url or IP. If you specify localhost, the images don't embed. Solution: use an external IP.
Lesson 3: Embedded images look like requests
When I did get the images embedded, they still looked like they might be requests in my browser. Here's a screenshot (note: this is a work in progress).
Lesson 4: Don't use what you don't need
This isn't related to Jammit, but as I was doing this exercise, I noticed some assets we were importing but not using. Solution: take the opportunity to clean up a little bit!
Jammit isn't the be all end all; tragically, it has not yet cured world hunger. But if you're on Rails 3.0, it's a great tool, and my hat goes off to those who built and maintained it. Quick, easy, and with only a few quirks - thanks, guys!