I wanted a project to allow attachments to be added to tasks. My requirements were that: users should be able to add multiple attachments to a task up to some maximum limit; there should be validation on the size of the attachments (combined with the number limit this should ensure I don't run out of disk space too fast); and, that there should be some security on downloading a task's attachments. Paperclip seems to be the popular Rails attachment at the moment and is still under active development, so I hoped to use that. However, it does not handle multiple attachments for a model. There is a plugin PaperclipPolymorph which adds multiple attachments to Paperclip, but I just couldn't get it to meet my validation and security requirements. In the end I wrote my own solution and this article details it.
Results tagged “Rails” from Cordinc Blog
I run a couple of Rails websites (queuesaurus & past weather forecasts), both on a small 256MB virtual host at Slicehost. As such I don't have a great deal of computing resources available to support two resouce hogging apps. If you have visited either of those sites, you will know that the first page view can take seemingly ages, but that after that it speeds up. As I use Phusion Passenger to serve the apps through Apache, I investigated some of the config options and how they affected performance.
Now that I have a couple of sites up and running on the web, I thought I'd talk about how I chose my hosting providers and how it's going. For those who just want the short version: I use Slicehost and am very happy with them. Read on for more details.
When looking at potential hosts for my Rails web apps I took into consideration price, speed/memory, reliability and flexibility. I basically wanted something cheap, reliable and fast. I've been an amateur sysadmin before (and at my first dotcom job was technically a pro sysadmin), so I wasn't scared of getting into the unix command line. Thus support wasn't important. Similarly for a small project, bandwidth, email accounts and credit-card billing systems would not be used. I wanted more than a hobbyist's hosting site (even if that is exactly what I am), but not costly, professional hosting.
My first thoughts were my domain name register, GoDaddy, or the host of this blog, pair. I know a number of people have issues with GoDaddy, but I've always found them fine for buying domain names and I can just ignore their constant upselling. However, I wasn't sure about their Rails hosting and a search only found bad stories (eg. here, here and here). I've also been happy with the service Pair have provided with this blog and associated static website. I didn't find much online about their Rails hosting and decided it would in any case be best to use different providers for this blog and my Rails apps.
Next I took a look at some webpages specifically listing Rails web hosts, such as on the Rails wiki. Among the massive listing there, special mention is made of Joyent and EngineYard on a couple of occasions. Certainly, these two companies seem to be held in very high esteem in the Rails community and host many well known Rails sites. However, they are both quite expensive - aiming for the high-end market. Too expensive for my goals or really anyone without funding. They are more aspirational - it would be nice to one day need the services of such a hosting firm.
I also found a couple of lists at rubyonrailswebhost and Zen and the Art of Programming. They rate Dreamhost and Site5 highly and both hosts matched my needs: dirt cheap (under $10/month) and with decent reliability according to reviews. Before signing up I sent Antonio Cangiano at Zen and the Art of Programming (a decent Rails blog I now subscribe to) an email asking if he had any updated advice since his blog on hosting was nearly 2 years old. Antonio suggested a new name, Slicehost. Slicehost use a virtualisation system so that it appears to the hosted application that it has a whole server to itself (albeit a fairly small server). This means that someone else's app can't hog resources slowing down your app. With memory intensive Rails apps this is very useful. They also have full command line access - you basically start with a clean build and can install/configure it how you like. While any "point and click" users would find it daunting, this really appealed to me. They provide a number of useful getting started articles, including some Rails ones, so I was sold. They are more expensive than other hosts at $20/month for a 256MB, but I have been very happy with their service over the last 6 months.
I am doing some work with the Rails text_field_with_auto_complete method to provide a dropdown list of completed options as a user types, like Google Suggest. However, I needed the item displayed in the dropdown to be different to the item displayed when it is selected. I couldn't find any help online. So at first I thought I would need to override the AJAX code, but when I looked I saw text_field_with_auto_complete already had this feature built in.
After having the simple idea (see here) over the New Year holiday, I next needed to decide how to implement it. Many people would say I needed to write design/spec/use case documents first, but for this project I think best to start working and see what happens. It would be easy to draw diagrams and think about problems with nifty solutions. However, the main goal is to DELIVER. I want to get something up and running quickly, get some people to use it and then improve it. I believe the longer it takes to get something up in front of people, the more likely I never will reach that point or go further. Having people use the system (even as testers) is a form of commitment.
As a result I chose to use Ruby on Rails for development - something many people who know me may find surprising. I have never programmed in Ruby before, so I'm learning it at the same time as trying to quickly develop a new system with fuzzy requirements. What happened to avoiding development risks and not trying to do too much at once? If I did a project risk assessment like most of my previous employers this would raise some serious red flags - the project would not be allowed to go ahead. Although, no previous employer would allow my idea to go ahead anyway, they would see it as too small. So why did I make the Ruby decision?
For the last 6 years I have almost entirely developed in Java (and before that a mix of Java, C++ and other languages that will never appear on my resume). I have worked on developing a wide range of systems from the large (over 100 people for a few years) to the very small (just me for a couple of weeks), although mainly for large financial firms. However, I specifically did not want to develop in Java. I may be faster in Java, but there are a number of reasons I thought it best not use it this time. People say it can be heavier to develop, with more boilerplate code, and I can certainly understand that. There are also less decent internet hosting options for Java, nearly every hosting firm provides PHP or Ruby options, but finding a good Java host is harder. However, the main reason for me was that with Java I was liable to get bogged down in the intricacies of the language and various libraries or third party tools. With a new language I wouldn't have time to think further than the next problem I was facing and finding a solution for it - there would be fewer distractions simply because there wouldn't be time to lose focus or investigate interesting side issues.
Choosing the language was difficult. There were so many I wanted to try as I haven't properly taught myself new language since C# some years ago. I have been reading (with interest) blog posts arguing (flaming?) the pros and cons of various web development languages and frameworks. Ruby on Rails seems to have a large following and been around for a while. The basic idea has been copied so many times by other languages (Groovy on Rails, Rhino on Rails, ...) that I felt there must be something useful in there. I rejected all the derivatives because I didn't think they would be mature enough yet and didn't have a large enough community behind them. After all a framework with a backlash must have reached a certain level of maturity! The speed issue was my main concern. At work code execution speed is extremely important and has a direct affect on the bottom line (I work on financial trading systems). However, the performance requirements for my system are far less than at work. Ruby will probably be fast enough - or at least fast enough at the start to see if the idea is worth pursuing. So I decided to just give Ruby a try. If it didn't work out I could quickly move onto something else.
Anyway, I've been writing Ruby on Rails code for nearly the last two months in my spare time - probably only the equivalent of only a handful of workdays in total. Yet I am quite impressed by how much functionality I have implemented. I am probably only a couple of weeks away from being ready for alpha testing on the functionality (the website design is still a mess). So far I have to say that Ruby on Rails has been a positive experience, although I am yet to properly test its performance.
