On 3.2
January 30, 2012 § 2 Comments
Last Rails 3.2 post. I swear.
I mentioned ActiveRecord::Relation#pluck in a previous post because it was one I was particularly excited about. After reading through the rest of the release notes I wanted to highlight a few of the other smaller changes I thought were interesting.
ActiveRecord
ActiveRecord::Relation#uniq
Client.select('DISTINCT name')
is now written
Client.select(:name).uniq
You can also revert the uniqueness with
Client.select(:name).uniq.uniq(false)
Don’t user LOWER for case insensitive searches on MySQL
When querying against our databases there are a bunch of times we don’t care about case. In the case of searching against an email address, a case insensitive search does exactly what we want it to. When you add the :case_sensitive => true to a validates_uniqueness_of it use to wrap that part of the query in a LOWER(). This sucked because it prevents MySQL from using an index. When you put this restriction on your email column and have to do this query every time you save a record. Since MySQL does case insensitive searches, ActiveRecord doesn’t worry about adding the LOWER() around the columns. Time saved all around!
rake db:drop drops both dev and test
rake db:create creates both the development and test databases. rake db:drop now drops the both development and test databases instead of just the development database.
ActiveView
namespace form_for
When you have multiple forms on one page for the same type of objects, you can get conflicting ids form elements. Problem solved with form namespaces.
<%= form_for(@offer, :namespace => 'namespace') do |f| %> <%= f.label :version, 'Version' %>: <%= f.text_field :version %> <% end %>
The ids of the form elements have the namespace prepended with and underscore to the front of the original id.
ActiveSupport
Time Ranges
One of the things that I love most about Rails is ActiveSupport. And one of the things I love most about ActiveSupport is how it makes dealing with Time awesome and easy. They have added a few new convenience functions to help with date ranges:
Time#all_dayTime#all_weekTime#all_monthTime#all_quarterTime#all_year
You can use these with ActiveRecord queries like so:
Event.where(:created_at => Time.now.all_week) Event.where(:created_at => Time.now.all_day)
Obviously there are a lot of other additions in 3.2, these are just the few that I know that I am going to have a use for. Enjoy.
On Pluck
January 23, 2012 § Leave a comment
Rails 3.2 has been released and there are a few things in it that I am excited about. I mentioned in a previous post that a few of the things coming in 3.2 were things that I had thought about doing or had already done myself. Turns out I missed one.
ActiveRecord::Relation#pluck
This is the exact same functionality provided by my select-column gem. It allows you to get an array of column values from the database without having to instantiate an ActiveRecord object for each one. So instead of having to do this:
Post.where(:published => true).collect(&:id)
you can simply do:
Post.where(:published => true).pluck(:id)
The place I see this having a lot of nice applications is in caching. I know that I wrote my gem so that I could use it to speed up some methods that would find appropriate records and then cache the ids for quicker look ups later. I am really excited to do a find and replace of collect for pluck in some of my projects.
On Local Tunnels
January 19, 2012 § Leave a comment
PayPal can be a pain in the butt to integrate in with your website. I sit next the guy on our team tasked with doing PayPal integration. I swear I can see the wrinkles and gray hair starting in on him. One of the biggest pains you’ll run into is testing the callbacks and web hooks. If you are doing anything more than putting a little donate button on you site, you’ll be dealing with IPN callbacks to keep your database in sync with PayPal. Typically your doing your development on a local machine that isn’t exposed to the outside world so you can’t have them post directly your dev machine. Bummer. There are a number of ways one can go about dealing with, I’ll mention two that we have tried before we found the third.
Test it on Prod
Nothing ever goes wrong when you do this right? A better solution here is to set up a separate staging machine that is hooked up to the PayPal sandbox, but setting up boxes just to do some sporadic testing really sucks. What if there was a service you could just point PayPal at to and just showed you what PayPal was posting, would that be better?
Postbin.org
postbin.org is a nice little service that provides web hook endpoints. It’ll give you a url to give PayPal as a callback url. When PayPal post to this url you’ll be able to inspect the request it sends. Unfortunately you’ll then have to manually parse it and figure out a way to post that info locally on your machine. But hey, no extra machines floating around in your cloud just wasting space and money! But there still has to be a better way to do this. I really would rather all of this just go to my local dev machine. Please tell me this can be done!
localtunnel
Enter localtunnel. localtunnel is a ruby gem that does what the name implies. It hooks your local server up to the world wide web by tunneling to a subdomain of localtunnel.com. You simply install and run the gem giving it your public key and a port and BOOM. http://as2js.localtunnel.com now points to your local dev machine. The PayPal IPN’s can now trigger all that nice sync code you have written.
I am currently working on some GitHub continuous integration web hook stuff, so this tool has been invaluable. Priceless even. The only additional thing I would like to see with this gem would be a way to deploy the server side to your own machine. While localtunnel.com is fine and dandy, I’d feel better if I controlled all the stops of the data. Anyways, get you localtunnel up and you web hooks on!
On Local Subdomains
January 17, 2012 § 2 Comments
I was working on a project a while ago that required the use of custom variable subdomains. If you have ever had to develop a site that used user specified subdomains, you quickly realize that editing your local /etc/hosts file over and over again sucks. A lot. You end up setting up half a dozen subdomains on a dummy domain that points to localhost. Not an ideal setup. Thanks to Railscast I tracked down a pretty cool solution to the problem.
The basic idea is to set up a live domain to point 127.0.0.1 and let DNS take care of everything for you. Tim Pope wrote about it nearly two years ago using smackaho.st. In the Railscast Ryan Bates mentions another domain setup for this, lvh.me, which was registred by Matthew Hutchinson. smackaho.st and lvh.me do the same thing, just on different domains. And because two isn’t enough, I went and registered lvho.st and configured it to do the same thing as well. The lvho.st domain comes from local virtual host, which I took from lvh.me and the fact that I liked the thought of using a .st domain like smackaho.st so I could use ho.st. Shove the two together and you get lvho.st.
Even though I don’t work with subdomains currently, I still use lvho.st for local development. Anyways, feel free to use if you have the need.
Interesting side note, this same project is the one that inspired me to write my first ruby gem, tld-cookies. It’s a nice little gem that makes it easy to set a cookie that works across all subdomains instead of just the current one.
On Sight
January 12, 2012 § Leave a comment
Here is a great little Chrome extension for developers, Sight. It’s a syntax highlighter for source files that you find on the web. It’s very nifty when you find yourself perusing the source of some open source project you are thinking of using.
Tips: ‘L’ will toggle line numbers and ‘G’ will take you to a specific line number. There are lots of font and themes to choose from as well.
On Observer Registration
January 9, 2012 § Leave a comment
If you are using the observer pattern with your ActiveRecord models, you have to register the observers. I don’t see why this can’t be done automatically. I place all of my observers in app/observers so I can easily register all of them with a few line in my application.rb file.
# Register all the observers in the observers folder. observers = [] pattern = File.join(Rails.application.config.root, 'app', 'observers', '**', '*.rb') Dir.glob(pattern).each do |filename| observers << File.basename(filename, '.rb').to_sym end config.active_record.observers = observers
More on ActiveRecord Observers and an example application.rb.
On F.lux
January 5, 2012 § Leave a comment
F.lux is a great little tool that changes the temperature of your screen to match the room you are in, syncing with the sunrise and sunset automatically and adjusts your screen to optimal levels. It’s a subtle difference but one that my eyes are very happy about.
On Personal Configurations
January 3, 2012 § Leave a comment
In a lot of the Rails projects I work on we use yaml files to set up configuration variables, things like domain urls, facebook and paypal keys, smtp configurations and many more. A lot of these can be different across different environments. The domain we use in our development environment might look like 127.0.0.1:3000 where in production it would look like awesome.com. We use Rails’s database.yml as a template for the rest of our configuration files, so an example of our config/config.yml might look like this:
test: name: AppName host: 127.0.0.1:3000 push_endpoint: http://lvho.st:8080/app/cometd development: name: AppName host: lvho.st:3000 push_endpoint: http://lvho.st:8080/app/cometd user_dev_tweaks: false production: name: AppName host: sweetdomain.com push_endpoint: http://sweetdomain.com:8080/app/cometd
We then slurp the current environment’s settings into a global constant in config/application.rb with the following:
CONFIG = YAML.load_file("#{::Rails.root.to_s}/config/config.yml")[::Rails.env].symbolize_keys
See all of the code in the gist for easier reading.
The On Blog 