I’ve been interested in simplifying lately…. using Chef (solo) to configure boxes, switching to Postgres from MySQL to get decent text search without having to run sphinx, etc. My goal recently has been to cut down the number of moving parts in my deployments to make my life a little easier. So when a client project required background processing, I re-evaluated my stock approach to see if I could simplify a bit.
Recently I had a client who wanted to deliver reports via email that contained a bunch of charts, and we decided on using Google Charts for the chart rendering. I used the googlecharts gem to create the links to Google. I encountered a problem with the charts not showing up in Gmail, even when the exact same code was working when viewing the reports at the site in the browser.
It turns out that the pipe character used to delimit data, options, etc., in Google Charts URLs didn’t play nicely with Gmail. Once they were encoded (converted to %7c), it worked like a champ. So, in my (html) email views, I have this as the src attribute to image tags:
Gchart.line(..., :format => 'url').gsub('|', '%7C')
Problem solved. :)
It’s been two-and-a-half years since the last release of the faker gem, so it’s about time for another one. :) For a long time I’ve been kicking around the idea of using the I18n gem to make it easier to support different formats (think zip codes in the US vs. postal codes in the UK) without having to change the method signatures, so I sat down today to give it a whirl. I was pleasantly surprised with how quickly I was able to get it implemented, so kudos to the folks who have done all the hard work of making that gem work as well as it does.
In fact, my love for that gem has grown over the last several months as I’ve used it on a few different projects. I had one client who wanted everything localized in his Rails app, which helped me get familiar with it (and eventually enchanted with it). One thing that I found fun to do (which may indicate I’ve crossed the line into gem abuse) is to store starter data in the locale files. For example, if you wanted to give new users a sample list of groceries when they create an account in your grocery list tracker app, you could do something like this:
Then you can create a list of groceries in the user’s native tongue.
So check out the latest faker, and find crazy stuff like that and more! :)
While working on the Rails 3 upgrade of the SaaS Rails Kit (which is available for customers, BTW), I moved most of the guts of the Kit into a plugin (engine) to make it easier to integrate into pre-existing apps. Then, as I was working on integrating the Kit into a client app, I ran into a situation where I wanted to extend one of the models provided in the plugin in the app, since this was a project-specific tweak. I mixed together a couple of suggestions that I found on there on the internets to come up with this:
That is added to config/initializers, and it simply adds a couple of scopes to the model that this project needed (but that I’m not sure other RailsKit customers would care about).
Does that look like the best approach? Or is there a better way to extend models that are defined in a plugin?
The work keeps coming in, and I need another pair of hands to get it all done. So, if you’re looking to pick up some part time dev work, and you know your way around a Rails app, apply for the gig here:http://tesly.catchthebest.com/apply/e3d3/b17a
You don’t need to be local to Seattle (though that would be a plus), but you do need to be generally available from 10-3 US/Pacific so we can chat in Campfire about projects or do the occasional screen sharing.