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, 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 05:57:00 GMT
While in Vancouver, BC for Canada on Rails, Robby and I had the pleasure of being interviewed by Geoffrey Grosenbach for the Ruby on Rails Podcast.
Tune in for me and Robby’s musings on the Rails development experience, writing and National Album Recording Month.
Posted in PLANET ARGON, Rails | 1 comment
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
Posted by Jeremy Voorhis
Tue, 11 Apr 2006 22:29:00 GMT
As I sit in my apartment, looking around at my bags that have been packed for the flight to Vancouver, BC for Canada on Rails I can’t help but feel a little bit nervous. I greatly appreciate the opportunity to speak about Globalize. My talk is designed to cover some relevant theory and standards, actually integrating Globalize with your app, and finally some practical techniques that have helped me quite a lot in PLANET ARGON development projects.
Finally, I am also pleased to announce that I will be authoring a Rails title for O’Reilly Media. More details to come, so keep an eye on the blog this coming week.
Posted in Rails, web development, Ruby, PLANET ARGON, Travel | 2 comments
Posted by Jeremy Voorhis
Tue, 03 Jan 2006 09:20:00 GMT
Four of my colleagues at PLANET ARGON and I just returned from the first PDX.rb meeting of 2006. The meeting consisted of a series of lightning talks, all of which came off (or so I’m told) very well. We had the opportunity to hear about
- Bumpr – a Rails application by Darrin Eden that uses Google maps to plot trips you record with your GPS device
- Multi – A library by Topher Cyll that provides pattern matching and multiple dispatch to Ruby, a la Haskell
- Globalize – I gave a presentation about how to use Globalize to internationalize your Rails applications
- Phil Thomson presented Ruby metaprogramming tips and tricks, and I got an irb session in my email via the PDX.rb mailing list shortly afterwards :)
Not bad for the first meeting of the year. Keep reading for more about PDX.rb and some impending news about PLANET ARGON in 2006!
Posted in PLANET ARGON, Ruby, web development, Rails, PDX.rb | 8 comments
Posted by Jeremy Voorhis
Tue, 13 Dec 2005 19:53:00 GMT
Ruby on Rails 1.0 has been released! As I am writing this, I am in the process of running gem install rails to update to the latest and greatest stable release of the framework, and intend to test and deploy my current project for PLANET ARGON on the big one-point-oh-oh, using PostgreSQL, acts_as_taggable, RMagick and last but not least, supporting 19 translations with Globalize.
Earlier today, Jason Watkins pointed me towards this PDF slideshow which showcases many of the unique features of Ruby on Rails with a special focus on aesthetics.
Congratulations and thanks to DHH, the Rails core team and everyone else who helped this come together!
Posted in PLANET ARGON, Ruby, web development, Rails | 9 comments | no trackbacks
