I'm reading Delivering Happiness by Tony Hsieh (CEO of Zappos). In it, Tony provides a link to a message that Jeff Bezos (Amazon CEO) had for the Zappos employees when Amazon acquired them. I found Jeff's obsession over the user to be quite inspirational:
Today I'm happy to announce that we've released an optimized version of the event details pages on Active.com. About 60% of our events will have this new format, and we're working steadily in the background to get this number to 100%.
The old version made use of tabs and had pertinent information scattered throughout the page.
The new version of the page completely does away with tabs, has all of the pertinent information needed to make a registration decision up at the top (including details on whether or not the event is almost full, and whether or not the price is going to change). We also feel that the new design is much cleaner than the old and hope you have a better experience getting the information you need when signing up for an event!
As Rob blogged in May, Trainer 2 is now using Unicorn for no-downtime deployments. This is great, however it means that our all.js and all.css files will not be generated until the first request is made after the new release - and this means the first request after a new release will incur the extra processing time required to build those files, which is less than ideal.
So what are our options?
We can just accept that that is the way it is going to work, and hope the extra time incurred is minimal. This will obviously work, but why not try to address the issue before it becomes a problem?
We can build all.js and all.css ourselves in the deployment script. This will get us what we want - the files will be built before the first request to the server is made, however it's not very flexible. We would need to update the deployment script every time we wanted to include a new file in all.js or all.css.
In the deployment script, we can simulate a request to the server, which will cause all.js and all.css to be built. This too will result in the files being built before the first user request is made to the server, and since the server that is building the files, it will generate them from the files specified in the application - no further configuration is required.
So how can we create a recipe in our Capistrano deployment file that will open a connection to the server, but we also don't want to hard code any URLs so that we don't have to update the deployment script if we need to change the URL for the application?
We can create a rake task that will open a connection and issue a get request to the root of the current application: