For the past year or so I’ve been doing a lot of work with Bootstrap and recently with Gimlet, a Bootstrap theme for Rails. As part of this I’ve grown to love the awesome Font Awesome icons, so I decided to sprinkle them here on my Octopress blog. I think I like it! I love how easy it is to customize Octopress with my own flavors.
It’s been pretty quiet here for a long time, but I’ve been busy building a few businesses, one of which includes a new product I’m helping to build and launch with a couple friends. One of the things I’ve been building is a robust REST API using Grape. If you want a quick overview, check out their README on the GitHub repo. I’ve really enjoyed using Grape and figured I’d share a few little tidbits of how I’m using it so far.
Configuring URL prefix
For a long time I was just using Rails 3 to “mount” my Grape API class like this:
This worked well for a while, but then I had a need to plug in some Rack middleware (such as Rack::Cors, which I plan to
blog about soon). Long story short, I couldn’t mount it the same way anymore, but still needed to configure the base
URL for the API to point to
/api. Grape makes this really easy.
1 2 3 4 5
Quick side note, I do still mount the API in the Rails routes for the
test environment only for my automated API
integration tests. But since I already have the prefix defined in the API, I just mount it to root for these purposes.
1 2 3
Delegate to the Rails logger (if desired)
Request logging, including body
1 2 3 4 5
Global exception handling
1 2 3 4 5 6 7 8 9 10
HTTP Basic Authentication
1 2 3
1 2 3 4 5 6 7
Sending back errors with validation messages
1 2 3 4 5 6 7
General API building tips
That’s all for now. Happy coding! :)
Another quick announcement about my latest Backbone.js screencast over at backbonescreencasts.com. This time it’s another one relating to Rails, When Things Go Wrong!. In this one I cover dealing with errors, specifically validation errors from Rails as well as monitoring server availability and reacting to server downtime.
Here’s a preview:
Check out this one, as well as the special bundles available over at backbonescreencasts.com.
P.S. I have a LOT of cool stuff to blog about, which I hope to get to soon. :)
Hey there folks, just a quick announcement to let you know that my 2nd Backbone.js screencast is now available over at backbonescreencasts.com.
This new one takes a step by step look at how to create a Backbone.js application to improve the user experience in an existing Rails 3.1 application.
I really enjoy using and teaching others about Backbone.js. So I decided to launch a new site specifically for delivering screencasts on Backbone.js. The first installment is now available!
Learn how to build a complete Backbone.js application from the ground up! To watch a preview and purchase this screencast, head on over to backbonescreencasts.com.
Quick little screencast showing how much just a simple move to Ruby 1.9.3-rc1 can speed up your Rails 3.1 startup time by up to 43%!
If you like these types of screencasts, be sure to sign up for CastingCode.tv!
I’m starting to build out my first Rails application on Heroku (cedar stack), ever. Yes, I know, I’m really late to
the party. But I just ran across something that might be causing folks trouble if they’re attempting
to deploy a Rails 3.1 application to Heroku and prefer the
sass syntax over the default
(First off I want to say thanks to Benjamin Atkin for giving me the idea for this fix in this blog post about Compass and Heroku.)
As much grief as I get over it, I am still an old school Sass guy and still prefer the
instead of the default
scss that is shipped with Rails 3.1. Thankfully, this is quite easy to change
in the Rails configuration as show here.
However, when you try to deploy this Heroku, the server fails to start. This can be discovered by running
1 2 3
As pointed out in Benjamin’s post, this is 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 I took his idea and created a Sass initializer to handle the setting of this for me, only when a Sass configuration object is available.
1 2 3 4 5 6
Just found out that the initializer above won’t actually get run when you run
rails generate, which
kind of defeats the purpose. So this code must be run from
application.rb, either included directly
By doing this, it allows the Heroku
cedar stack to properly precompile the assets and successfully
start the Rails server.
One other way to “fix” this issue is to move the
sass-rails gem into the global group in your
But I think I prefer the solution above so I don’t have to pollute the global gem group with an unnecessary
gem just to satisfy Heroku deployment.
The other day as I was converting this blog over to Octopress, I recorded a short little screencast on how I was able to use Vim macros to make migrating my old blog posts a LOT easier. This was the result…
(HINT: Best watched in HD mode, full screen)
Don’t forget to sign up for CastingCode.tv to see more!
Coder Talk, the weekly conversation I started with developers that has turned into a podcast, is growing up a bit now. I’ve created a simple website and an audio RSS feed for it now. It is also listed in the iTunes podcast directory. So to keep up to date on the latest episodes, visit that site and subscribe to the podcast. We’d love to know what you think about it!
Please let us know what you think by leaving a comment below. Enjoy!
- Runtime: 1:30:30
- Download: MP3 File (86.9 MB)