Posted by Jeremy Voorhis
Thu, 10 Aug 2006 17:20:00 GMT
I have resigned from the position of Lead Architect at PLANET ARGON. While the experiences I have had there have been invaluable to me, it is time for me to explore a few specific areas of my career on my own. I am leaving behind a highly competent team and I look forward to seeing what they will accomplish as time unfolds.
In case you are wondering what’s next, I am dedicating greater portion of my time to my forthcoming book, Rails In a Nutshell, which will be published in 2007 by O’Reilly Media. I am also eager to spend even more time developing my Craft series of workshops, which begins on September 1-2. Finally, I will be available for contracting for Ruby development projects, acting as an developer, but also as a trainer and a mentor.
The common theme in all of these endeavors, giving direction to my future, is that I want to ultimately develop as a communicator; I want to connect with clients as well as fellow developers with the intent of improving our craft and sharing what we learn. Towards that end, I also intend to increase my community involvement, beginning at the Portland Ruby Brigade. See you there!
email address: jeremy at jvoorhis dot com
Posted in Rails, web development, Ruby, PLANET ARGON | 9 comments
Posted by Jeremy Voorhis
Wed, 02 Aug 2006 10:47:00 GMT
If you are excited about Ruby on Rails development and want to better understand the intersection of application design and web architecture, then I am pleased to announce that I will be hosting a workshop in September. Stay tuned for more details.
Posted in Rails, web development, Ruby | no comments
Posted by Jeremy Voorhis
Sun, 30 Jul 2006 22:22:00 GMT
This morning after refreshing my blogroll, I noticed that I had received a chain letter. Here is my response.
What was your technical background before you started learning Ruby/Rails?
My earliest flirtations with web development involved Perl and MySQL, and my first professional programming job involved PHP and Microsoft SQL Server. I later moved on to working with .NET on Windows. While Visual Studio was sometimes inescapable, I claimed the Mono platform and Emacs as my development environment whenever I could.
How long ago did you start?
I have programmed professionally since 2003. I have been a full-time professional Rails developer since March 2005.
What were the two most useful resources to you in the learning process (not counting The Agile Book or the Pickaxe Book, which we’ll assume everyone knows about)?
Regarding learning the Ruby langauge, the most helpful resources have been community-based. Ruby Quiz, the #ruby-lang channel on freenode.net, the Ruby Talk mailing list (although I mostly browse the archives), fellow bloggers, and the erratic Poingant Guide to Ruby.
Because the Ruby language has such varied influences, it also helps to understand them as well. Many folks who see Ruby for the first time comment that is looks “Perlish”. On the surface level it bears a resemblance, but my nominal experiences with languages like Scheme and Smalltalk have contributed more to my mental model of Ruby than Perl.
Tell us the story of how you came to learn Rails:
Prior to Rails, I had been experimenting with Nant, NUnit, NHibernate and different approaches to the model-view-controller architecture on .NET. Rails was a natural fit because it encompassed a familiar toolset, but in a smaller, more easily comprehended package.
Three Ruby bloggers to whom you’re passing the baton:
Posted in Rails, web development, Ruby, Languages | no comments
Posted by Jeremy Voorhis
Wed, 28 Jun 2006 03:14:00 GMT
Here’s a follow-up story about PLANET ARGON’s asset compiler project in action.
In our client’s application, an Image model is created for each image they upload and the uploaded images are saved into an asset source directory. After the images are saved, an observer launches the build system, acting on any source images whose targets are missing.
While I was speaking at Railsconf, a client of ours posted a bug to our Basecamp. For reasons I am still trying to determine, our client had uploaded four images to their application but the asset compiler task was not executed. It might take a minute to find the disconnect between my application and Rake, but our client needs those images that coincide with a press release as soon as we can deliver them.
Because asset compiler is build on top of Rake, it receives all of the benefits of Rake. I recalled that Rake supported a way to perform a dry run of a task execution (actually the option is called
--dry-run). Because each individual target file is a dependency of the top level task,
assets:build, running
rake assets:build --dry-run
tells me exactly which target files were missing. Sure enough, they coincided perfectly with the files the client reported were missing. By running
rake assets:build --dry-run | grep "** Execute"
I can ignore any file tasks which are not necessary. Within five minutes, I was able to diagnose the problem and allow my client to proceed after building the remaining target images and uploading them to the bandwidth provider, which was as simple as running
rake assets:build
The beautiful thing here is how easy asset compiler lets me manage 4000 images. The application knows when to run build tasks, and in my assets.rake file, I can concisely define 11 types of image transformations. I can run each type of transformation individually, or I can run them in one shot. Even better, since rebuilding all of the images takes considerable CPU power, I can rsync my asset source directory to a separate build server and run the build tasks there, exporting them to our web server and the bandwidth provider.
For those of you unfamiliar, the asset_compiler project is hosted at planetargon.org and there is an article on InfoQ that tells the story of its motivation and implementation. Asset compiler is free software.
UPDATE
Here is the amazingly helpful output I got from
rake assets:build --dry-run | grep "** Execute".
** Execute (dry run) assets:navigation_icon:build
** Execute (dry run) assets:bronze_navigation_icon:build
** Execute (dry run) assets:navigation_icon_no_resize:build
** Execute (dry run) assets:bronze_navigation_icon_no_resize:build
** Execute (dry run) /path/to/assets/full_size/Ronaldo9mVert1.jpg
** Execute (dry run) /path/to/assets/assets/full_size/Ronaldo9mHoriz2.jpg
** Execute (dry run) /path/to/assets/assets/full_size/Ronaldo9mVert2.jpg
** Execute (dry run) /path/to/assets/assets/full_size/Ronaldo9mHoriz1.jpg
** Execute (dry run) assets:full_size:build
<snip />
** Execute (dry run) assets:build
This is exactly the kind of clear and unambiguous feedback I like to see when investigating this kind of problem. A big thank you to Jim Weirich for his thoughtful implementation of Rake.
Posted in Rails, web development, PLANET ARGON, Architecture | no comments
Posted by Jeremy Voorhis
Tue, 25 Apr 2006 22:08:00 GMT
I am pleased to announce that I have signed on with O’Reilly Media as the author of Rails in a Nutshell. Keeping true to the In a Nutshell tradition, this book will
...drill down, expand, and, we hope, delight the reader by providing useful information the reader didn’t even expect to find.
Expect to find great coverage of Ruby on Rails in depth, as well as additional topics that are not Rails, but are vital to the Rails experience.
www.railsinanutshell.com
Posted in Ruby, web development, Rails | 2 comments
Posted by Jeremy Voorhis
Mon, 17 Apr 2006 22:43:00 GMT
i really think that all web apps degenerate to a CMS eventually.
Zed Shaw on #caboose
Posted in web development | 6 comments
Posted by Jeremy Voorhis
Mon, 17 Apr 2006 21:49:00 GMT
Or, Don’t be afraid to use the right tool
At Canada on Rails, I showed screenshots of a recent PLANET ARGON Rails development project which showcased my work with Globalize. What the slides did not explain was how we were able to process 1000s of images in an agile way.
We began by writing our own plugin, similar to FileColumn. Problem is, each image we had to manage required up to 4 variations, as well as transport the files to a bandwidth provider. In the beginning, the rules to produce these variations changed frequently. As you might guess, our models had suffered some bloat. My solution to coping with this problem was inspired by Jason Watkins’ experience in the video game industry: an asset compiler. In short, an asset compiler is a build tool that works from raw assets living in source directories and transforms them into their final state.
What I wanted was a flexible tool to regenerate – or build – all of these image variations, and I wanted it to stay out of my way. I had decided the best platform to build this tool might be Rake – a Ruby build system. I followed Jim Weirich’s RDocTask library as a template, and in a couple of days I had the asset compiler up and running. With the asset compiler in place, it was a simple matter to write an observer to fire off the right tasks. Our plugin and our image models were greatly simplified and now it simply saves or deletes a file in a source directory.
There is something desireable about heterogenous architecture. Specialist components with clear lines of responsibility become a joy to work with, and easier to maintain. Don’t force heterogenous design, but consider it as an agile approach when you suspect your application is growing into a monolith.
Posted in Rails, web development, PLANET ARGON, Architecture | no comments
Posted by Jeremy Voorhis
Fri, 14 Apr 2006 03:35:00 GMT
I just gave my presentation titled Globalizing Rails at Canada on Rails – the world’s first Ruby on Rails conference.
For those who may be interested in viewing my slides, I have made them available as a PDF at http://www.jvoorhis.com/media/globalizing-rails.pdf.
Globalize was used in a recent PLANET ARGON development project to provide internationalization services and to localize the app to 18 languages. Learn more about Globalize at globalize-rails.org.
Thanks to Nathan for organizing the conference, DHH for giving me something to talk about, and everyone who contribued to making Canada on Rails a success.
UPDATE
Ryan Davis has kindly made the conference attendee’s shared notes available here.
Posted in Travel, PLANET ARGON, Ruby, web development, Rails | 4 comments
