Duane Johnson and Neal Harmon are a programmer at and the president of FamilyLearn, a small company using Ruby, Rails, and Amazon's S3 and EC2. They've ported their applications from PHP to Ruby on Rails, and have recently started a Public Beta of their iMemorybook tools. I've invited them to share some of their experiences in this interview.
To start things off, would you two please tell us a bit about yourselves and about FamilyLearn?
Neal: My wife Trisha and I started this website as a little family project over 4 years ago. After reading a wonderful compilation of stories my grandpa wrote, we decided to collect stories about our family to share with our unborn son, Michael. The project evolved, went online, and was shared with other families. So, we became a company with the same vision for the rest of the world, build the world's most enjoyed family library. We're building a place where families can preserve and share the stories of their lives. iMemoryBook is a powerful software for capturing stories and publishing them as a hardbound book. The best part is it's free for families to use.
Duane: I've been a web developer ever since graduating from High School. I didn't know the difference between VB Script and Javascript in those days, so when my first boss said I'd be programming in ASP, I thought, "Great!" and they gave me a company laptop to boot. Since then, I've followed most of the webdev crowd as we've moved to happier and more sensible development languages. PHP was a nice, clean language for a large set of problems. But I was lucky enough to be an early-adopter for Ruby on Rails, as I'd been secretly using Ruby for a number of years before Rails 0.5 came out.
My first job also taught me a lot about what I wanted to focus my life energy on. I had an opportunity for a short time to help engineer the operating system software for an electronic slot machine. I found out quickly that getting paid for something I couldn't give my heart to was bad for both me and my employer. A number of jobs later, I'm delighted to work for a company that believes in family and preserving relationships. FamilyLearn is a smart company with a great leader.
How did you decide on Ruby and Rails for your development platform?
Duane: From my angle, as an experienced web developer, I wanted to enjoy what I do. I got pretty tired of re-inventing the wheel in PHP, or, if you'll pardon the analogy, trying to fit a Honda engine in to a Jetta. You can find anything for PHP, but getting the whole system to work right together was a real challenge for me — one that kept me up at night and eventually led to frustration and a search for something better. When I found out about Ruby on Rails, it just had to have "Ruby" in its name and I was already hooked.
Since Neal was already hearing good things about Rails, I think he just needed the right players with availability and he was willing to see what we could do.
Neal: I choose to give Ruby on Rails a try after reading "Agile Web Development with Rails". The framework conventions seemed to make programmers happier and more productive. I saw impressive demonstrations on the development speed of the technology. Also, I liked to use nearly all the websites that I encountered which had been built with Rails. They were, for the most part, simple and straight forward.
Our company faced some rapid growth on a hodge-podge of loosely tied together PHP applications, along with some Perl, LaTeX and TeX. The database reflected numerous shifts in the business' direction and changes in programmers. Bringing on new engineers to help the iMemoryBook service grow quickly revealed the weaknesses in our mess of code and we ultimately decided to green field our new iMemoryBook application completely in Ruby on Rails. I made the decision hoping for some miraculous development times before our company outgrew the old code (we were already having some serious growing pains).
What challenges has that created for you?
Neal: Initially, Rails didn't prove as fast in development times I had hoped (part of it was that two of us on the project were getting into Rails for the first time). It was a slow start in the beginning, but the benefits of the framework and our Ruby guru's (Duane) approach began to shine as the code base grew.
Duane: Choosing Ruby on Rails meant green-fielding the first version that Neal had put so much time and effort in to. We couldn't re-use a scrap of code once we chose Ruby. But as a testament to his flexibility and personal humility, Neal was willing to take a leap of faith — we built the database structure from scratch so that it would fit cleanly with ActiveRecord's expectations of what a database should look like. When Neal would look at the new database, he'd laugh so hard and say, "You can tell I wasn't a programmer when I started this thing, can't you?" This has been a blessing in the long run, but rebuilding what was basically an already functioning system was a real frustration for everyone at first.
Another area where Rails has not been kind to us is in its speed. Our iMemoryBook system is a computationally intensive process — sometimes taking minutes to complete a task (such as converting a TeX book into PDF format), which means that a whole process can be tied up for that long. We're still trying to figure out how to get this to work on a large scale.
Neal: When I asked Paul (our other developer) about this, he said:
Ruby itself seems just as fast as the next scripting language. It's not C, but nothing but C is. ... There are a couple of problems with rails/mongrel in a production environment. Ruby/Rails encourages lazy programming. The think the philosophy is something like, "don't work for the computer, let it work for you". If you are not careful you will be dong things the ruby way and not realize that you are hitting your database multiple times on every iteration of a loop. This just won't work in real life. You still have to remember you are working with finite hardware.
Duane: For our system, Ruby hasn't been the bottleneck. By far, using LaTeX in the back-end has been our challenge. It's just so hard to get speed improvements out of that system when it isn't really meant to be creating PDFs on-the-fly for each change the user makes. Once we address that issue with some caching techniques, we'll be able to see if Ruby becomes a bottleneck
In addition to using Ruby on Rails, you guys have been using the Amazon EC2 and S3 offerings. I'd like to spend a little bit of time talking about them too. Looking back on the past couple of months (the time you've been working with Amazon) what's stood out as the good and the bad?
Neal: Except for the struggles to successfully launch a SUSE virtual machine, everything has worked well for us so far. I have seen a few slow downs in our website that are not due to our own traffic. I suspect that the grid got hit by too much traffic all together and we weren't really getting our full virtual machine resources or we didn't have access to enough bandwidth. But, I don't know...we haven't done sufficient testing to determine if Amazon is the problem.
Duane, there's a lot of movement around S3 libraries for Ruby right now. Are the Amazon libraries good enough for you, or are you looking at any of the third-party offerings?
Duane: We've wanted some better tools. While the S3 sample ruby library that Amazon provided was a good starting point, it didn't seem to take advantage of some of Ruby's idioms. In other words, I guess it didn't feel like a Ruby library to me, and so it fell in to that "itch that needs to be scratched" category. I've taken a quick look at some of the nicer offerings that are now available, but since our code seems to do well enough with the current implementation, we haven't had a need to go fix it. In the words of my coworker, Paul Jones, "on a scale from terrible to beautiful, this code is 'working'".
What tools do you find lacking?
Duane: We've wished that some of our FTP tools would support S3. I use Panic's "Transmit" application for the Mac, and I've heard rumors that they may be implementing a solution soon. It would also be nice to have a more centralized "control panel" or something for all of the common tasks on EC2. The command line is a bare-bones kind of tool that gets the job done--with a lot of reference help. I'd like to see some kind of web-based administration system for tasks like backing up / duplicating your EC2 image, starting new instances of common images, and browsing what other shared images people have created.
How is working with EC2 and S3 different than developing for a local system?
Duane: There are some pros and cons to using S3 for file storage. Some of the benefits are widely known, such as infinite, scalable storage space and very fast content delivery. We've found some disadvantages, however, that have made things a little painful, but still workable. For example, we do a lot of image resizing in our application, so we have to decide between caching on S3 for speed and getting scaled / rotated images directly from our server. We've kind of struck a balance so far where some of our "probably not going to change very often" images are stored on S3 while our "probably going to change" images are generated dynamically. Another area that has sometimes surprised us is that uploads to S3 will fail inexplicably and so our code has to take retries in to account. Other than that, we've been quite happy with the fast transfer times between the two systems. Amazon has definitely thought out how the two systems orthogonally complement one another.
Neal, what changes would you like to see in the EC2 or S3 offerings?
Neal: I would like to see pricing that scales with a business. The day will come when Amazon will be more expensive than building our own system. We will need to switch when that day arrives. I suspect, even hope, there will be a company who will solve that problem for us before we get there. It'd be great if it were Amazon.
What advice would you give to someone who's looking at the Amazon Suite?
Duane: I think it's a great solution for small developers who intend to grow quickly. While a stand-alone server will work for quite some time, it's always painful when you hit that "wall" and realize your configuration isn't going to hold up against all of the traffic. Being able to turn on another server and/or rely on the distributed storage of Amazon is a decent way to scale on a budget.
Neal: Use both. Bandwidth between S3 and EC2 is basically free. It saves us a lot in image processing.
What advice would you give to someone who's looking at migrating to Ruby on Rails?
Neal: Consider hiring one RoR developer to guide your project and hiring other developers to learn RoR while helping with the project. It's difficult to find good RoR people.
Duane: Make the switch, and don't look back! Seriously though, if you're someone who takes pride in what you do as a programmer, Ruby is a great language with a great supporting culture. There are a lot of computer-scientist types in the Ruby world that make for good examples wherever you have weaknesses. And of course, the push for "convention over configuration" on the Rails platform is generally a good thing when it comes to quickly learning how to get things done.
I've saved myself often by doing something the "Rails way" by finding out later that a convention I'd followed earlier was smarter than face value. Web development isn't a new thing anymore, and we shouldn't have to be re-thinking the whole business each time a new application is built. That's why I said good-bye to PHP two and a half years ago.
Technorati tags: Ruby Rails interviews
No comments:
Post a Comment