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
Tue, 01 Aug 2006 04:02:00 GMT
resource_hacks is a plugin that extends edge Rails’ new restful routes implementation. While the current opinion of the core team is that we should only use member resources with a numeric id, resource_hacks allows Rails to support arbitrary an arbitrary member path. Allow me to illustrate:
map.resources :entries
gives us the member path /entries/1 where 1 is the value of params[:id]. With resource_hacks, you can still use a numeric id, but also declare an arbitrary member path like so:
map.resources :entries,
:member_path => '/entries/:year/:month/:day/:permalink'
This gives us the member path /entries/2006/8/1/announcing_resource_hacks rather than /entries/1.
With this routing definition, you may send an HTTP request with the PUT method to update the Entry via EntriesController#update. The same goes for DELETE. The collection found at /entries will not be affected by resource_hacks.
You can install the plugin by running
$ script/plugin install http://svn.planetargon.org/rails/plugins/resource_hacks
from your application’s base directory.
One final note: I cannot take full credit for this plugin. The basic implementation came from Andrew Grim, PLANET ARGON’s latest developer. Welcome, Andrew!
Posted in Rails | 9 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, 26 Jul 2006 02:02:00 GMT
While reading through the source of Rails::Initializer, I discovered and confirmed a solution to ordering problem documented at http://www.jvoorhis.com/articles/2006/06/30/plugins-and-the-inflector.
The individual environment files (config/environments/development.rb, et. al.) are loaded before any plugins are loaded, while the last portion of config/environment.rb is loaded after plugins are loaded.
This means that you can declare your custom inflections in those individual environment files. Just be sure that your inflections are shared across all three files. A good solution might be to create config/inflections.rb and require it in all three sites.
Posted in Rails | 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
Mon, 08 May 2006 03:43:00 GMT
In test/test_helper.rb:
class Test::Unit::TestCase
def self.fixtures_with_users *names
self.fixtures_without_users [:users, *names]
end
class << self; alias_method_chain :fixtures, :users end
end
Does anybody know another way to do this?
Posted in Rails, Testing | 3 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
