In most cases, if you enter 0 for an IP address it will expand to 0.0.0.0. Likewise, 127.1 will expand to 127.0.0.1. Why? Magic.
But really, why do these shortcuts exist and how do they work? It can’t be as simple as adding zeros, if it was 127.1 would more logically expand to 127.1.0.0.
Sometimes an AJAX request on a page you’re developing needs to hit a server on a different domain. Web browsers’ Same-Origin Policy means (among other things) that other domains called from AJAX need to be whitelisted using the Access-Control-Allow-Origin header.
Fortunately, there’s an easier way, temporarily disable same-origin policy.
As part of the work Indra did for Stand Up To Cancer’s telethon, I need to make use of Convio/blackbaud’s Luminate Online Server APIs. Luminate Online is a widely used fundraising platform and relationship manager for non-profits.
I’ve turned that development work into open source in the form of gem providing Ruby bindings to the APIs.
I have only implemented a handful of endpoints, Luminate Online doesn’t have any kind of test mode or sandbox, any testing has to be done with live data. However, I’ve used a meta programming approach making it easy to quickly add additional endpoints.
All of the endpoints I have implemented have been used in anger.
The details are in the repo: https://github.com/spikex/luminate
Yesterday, I was involved in a fire drill around the launch of a new Rails site on a very tight time frame. The site worked fine in development/staging, but the index was taking upwards of 10 seconds to render in production.
Because it worked outside of production we leapt to the conclusion it was related to the hosting infrastructure. We checked Apache, Passenger, server load, network configuration, and so on. Nothing.
Finally, I thought to check
log/production.log, and there is was:
1 2 3
We quickly tracked it down some image processing that wasn’t being cached. It didn’t show outside of production because the image assets were different. I won’t bore you with the details.
However, I will
bore enlighten you as to my point. When debugging
a problem, start with the simple things. The Rails logs aren’t very
detailed, but they provide more than enough information to quickly
drill down to problems in your code.
If you try to build Ruby 1.8.7 with RVM you will see:
1 2 3 4 5
The work-around, is to install GCC, either with
or from Ports:
Once you have gcc you can install 1.8.7 with:
This should work with older versions of Ruby 1.9 as well.
What on earth would you want to install 1.8.7? Two words: Legacy Apps…
Previously, Strongbox, my gem for using Public Key Encryption with ActiveRecord, allowed only one key pair for encrypting all of the records for a given ActiveRecord model. I’ve had a number of requests to make it possible to dynamically choose the keys on a per record basic and version 0.6.0 adds this feature.
The values of
:key_pair can be in one of the following formats:
A string containing path to a file. This is the default interpretation of a string.
A string contanting a key in PEM format, needs to match this the regex
/^-+BEGIN .* KEY-+$/
1 2 3
A symbol naming a method to call. Can return any of the other valid key formats.
1 2 3
An instance of
OpenSSL::PKey::RSA. Must be unlocked to be used as the private key.
1 2 3 4
Using this, you can automatically create per record public keys:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Important Caveat -
Currently, Strongbox encrypts the attribute as soon as it’s assigned (this will change in version 1.0). The means that the public key must be available before the attribute is assigned, hence the use of
after_initialize to generate the key pair. Even so, this will fail if you do something like:
because the attributes are set before
after_initialize is called.
Instead, use something like:
1 2 3
Version 1.0 will allow you to control when the encryption occurs, making this less of an issue.
As always, I like building Emacs for my Mac from source. It lets me live on the cutting edge and have tigher control of the version I’m running. If building software from source isn’t your thing then skip the rest of this article and consider installing Emacs using Homebrew, MacPorts, or Fink
I’ve written about building Emacs in the past, but OS X Lion brings a few complexities to the process.
After years of running on Wordpress, today I’m relaunching my blog using Octopress. Octopress is a blogging framework build on top of Jekyll which in turn is system designed for publishing static sites from source files, be they Markdown, HAML, SASS, etc. This style fits nicely in to my everyday workflow, so my hope is it will get me writing on a regular basis.
Wordpress is great if you want a WYSIWYG blog and I still recommend to my clients. But, if you spend your days in Emacs or Vim, running rake tasks and git commits, you might want to give Octopress a try.
Pow is a zero-config Rack server that makes developing Rack apps (include Rails apps) a snap on Mac OS X.
You install Pow:
You create a symlink to your app:
You point your browser to http://myapp.dev/ and there’s you app! Awesome!
However, there is a downside: Pow doesn’t play nicely with Apache (or any server listening on port 80). Life isn’t all greenfield, if in the course of the day you need to work on PHP or CGI legacy apps Pow is not so simple. Pow creates a firewall rule that redirects port 80 to its port; to access Apache you need to either toggle the firewall rule on and off or move Apache to a different port all together. And now you’re running two web servers. There has to be a better way.
The Win And there is, make your legacy app a Rack App. Thanks to the rack-legacy gem, this is actually quite simple.
First, install the rack-legacy and rack-rewrite gems:
(To sudo or not to sudo, that’s up to you).
Next, in the top level of your legacy app create this config.ru file:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
The Details Rack::Legacy::Php runs any requested file with the extension .php. Rack::Legacy::Cgi runs any requested file that is set executable (which means you’ll need to make sure your .html files are not). Files that don’t end in .php and aren’t executable are served as static content by Rack::File.
The INDEXES array contains a list of files to check for if a directory is requested (just like Apache’s DirectoryIndex directive). You can change the order or use different names (default.htm anyone?).
The Catch rack-legacy uses the php-cgi command line program to run scripts and while PHP ships with current versions of OS X, php-cgi is not included. You’ll need to install PHP using MacPort/Homebrew/Fink/etc. That’s beyond the scope of this post but, if you’re doing this kind of development, it’s probably not beyond you.
The Caveat This is probably not a fast as running PHP using the Apache module and it’s certainly not as fast as something like FastCGI. If you are primarily developing legacy apps you probably should stick to Apache. However, if you mostly work with Rack apps and just occasionally need legacy support, this is a great way to go.
There’s plenty of documentation on how to deploy “Classic” style Sintra applications with Phusion Passenger, but it’s not immediately obviously how to deploy the new “Modular” style app (created with Sinatra::Base). Fortunately, it’s simple, the resulting class can be passed to “run” inside you “config.ru” file, something like:
1 2 3 4
Instructions you find for “Classic” Sintra apps have you setting “:env” to the ENV[‘RACK_ENV’] before running the app. As of Sintra 1.0 it’s “:environment” and it’s automatically set to ENV[‘RACK_ENV’] (or “:development” if RACK_ENV is not set). You’ll also see instructions for setting “:run” to false, this is not nessecary for “Modular” apps.