Dystopian Index is a Rails plugin for Tokyo Dystopia. I’m using it with small projects that don’t really need a more sophisticated indexing solution like Sphinx or Solr. There’s no daemon, so setup is less of a headache.
It uses Dystopia to build disk–based indexes. At the moment it stores one index per ActiveRecord model, but I might change this to an index per field later.
Vlad the Deployer is a well–written piece of software. It demonstrated that a realistic alternative to Capistrano is possible, with way less code. I’ve come to rely on it for a few projects and I like the design. There are times, however, when using Vlad can feel like pulling teeth.
It’s important to select the appropriate deployment technology for your project, especially if you need to take colleagues and workflow into consideration. This post outlines different approaches to deployment.
Rails deployment is dominated by technologies like Capistrano and Vlad. These deployment frameworks_ represent one approach, but there are others that are just as valid depending on the project.
Auditing your application is an important stage of deployment. Mature Rails applications have a tendency to get complicated — they typically require a host of libraries, background tasks and their own settings files. To feel confident deploying it’s important to be aware of these dependencies.
Ideally, deployment should just work. Deploying a tweak, bug fix or new feature should all be performed through a single command. However, there’s going to come a time when you or your colleagues haven’t updated an application for a few weeks or months, and deploying suddenly feels daunting. This type of document would help in that situation. It will also help you plan deployment before starting up Vlad or Cap.
Deployment should be bullet–proof, predictable and fast. You might even say it should be agile. Unfortunately, it's difficult to create an agile deployment environment. One of the reasons for this is that deployment is left as a last minute concern. It's a spectre lurking in the corners of a project manager's Gantt charts.
To make matters worse, learning and configuring deployment tools can be difficult — the documentation isn’t always great, and it’s hard to relate recipes to your particular environment. They also require a leap of faith before running with a live application.
Please accept my apologies if I’ve flooded your feed reader with articles: I owe you a beer. The reason for this is I’ve moved my blog over to a new system and new design. To make up for it I’ve lovingly curated all of my old posts by adding syntax highlighting, resizing images and fixing typos.
In fact, I’ve almost killed myself porting this blog over to Jekyll. My old blog was a simple Rails application I built based on code from Helipad. It did a sterling job, but I have so many Rails applications to maintain it added too much to my workload. Writing a blog with Jekyll is relatively simple, but deciding to make a redesign at the same time is not.
Rails boot up time really starts to drag when you’re working in a TDD or BDD style. There’s projects out there that create long running distributed processes to ease this, but it’s interesting to look at exactly why Rails might boot up slowly.
I have a project that isn’t massively complicated, but it has suffered from “just add” culture. I’ve been told to “just add” Excel support, PDF generation, and a lot more features that require complex libraries. This naturally increases the memory footprint of my application, and it also increases boot time.
I wrote a series last year called “Rapid Rails”. It was all about making your Rails app and development process faster. I’ve been analysing the performance of some mature Rails projects recently, so rapid rails is back.
If I’m tasked with improving an application’s performance, the first thing I look at is indexes. Indexes are something you’re told are important when you learn about relational databases, but the effort of domain modeling usually makes most people forget all about them. That means you’ll often come across a slow project that can be improved just by adding indexes.
I had a few glitches in the Helipad iPhone app when 3.0 rolled around. I’ve put the solution here to help those of you searching for the error message.
Helipad syncs to our web app and displays a syncing progress screen. I open this view in a new view controller like this:
I’ve always dabbled with open source (Linux got me through university), but it’s only since GitHub that I’ve released a lot of stuff: GitHub.com/alexyoung — I only had weird experiments on my site before, and I released some stuff through work too (code.helicoid.net. Nothing much drew any major attention until I publicly announced JsChat.