Recently in Rails Category

This is an autotest plugin to provide rails support. It provides basic rails support and extra plugins for migrations and fixtures.

Changes:

4.1.0 / 2009-06-03

• 1 major enhancement

  • Birthday! well... split from ZenTest

• http://rubyforge.org/projects/zentest

ZenTest provides 4 different tools: zentest, unit_diff, autotest, and multiruby.

ZenTest scans your target and unit-test code and writes your missing code based on simple naming rules, enabling XP at a much quicker pace. ZenTest only works with Ruby and Test::Unit. Nobody uses this tool anymore but it is the package namesake, so it stays.

unit_diff is a command-line filter to diff expected results from actual results and allow you to quickly see exactly what is wrong.

autotest is a continous testing facility meant to be used during development. As soon as you save a file, autotest will run the corresponding dependent tests.

multiruby runs anything you want on multiple versions of ruby. Great for compatibility checking! Use multiruby_setup to manage your installed versions.

Changes:

4.1.0 / 2009-06-03

• 1 major enhancement:

  • Removed all plugins I don't want to maintain anymore. (gem inst autotest-rails)

• 4 minor enhancements:

  • Added #blur to focus.rb to nuke all other test classes
  • Clear RUBYOPT before installs (balatero)
  • Removed test/unit include in zentest so we can focus on miniunit
  • sort versions for builds. (Jens Wille)

• 6 bug fixes:

  • Fixed a stupid bug when running on some versions of bash >= 3.2.x and using '&>' in a system call. (Jens Wille)
  • Fixed inconsistent test commands in autotest. (jbarnette)
  • Fixed unit_diff's usage generation when installed as gem. (borior)
  • Fixed zentest to deal with unnamed classes. (Bill Dortch)
  • Removed buggy/unused -l support in unit_diff. (borior)
  • make twice to make it more resilient to makefile parallel bugs

• http://www.zenspider.com/ZSS/Products/ZenTest/

• http://rubyforge.org/projects/zentest/
• ryand-ruby@zenspider.com

There seems to be some confusion and/or panic about ParseTree that I'd like to clear up:

Because of changes to internals in 1.9, ParseTree simply can not work. I asked for hooks/options to allow us to get to the information but they never arrived.

Specifically if you're using ParseTree to access the AST of a live method/block/proc, you're SOL. If you're just using ParseTree to do static analysis, then you can switch to ruby_parser in about a minute of work and you're good to go.

Here is the plan for my projects:

• RubyToC-1.0.0.5 = switching to ruby_parser
• flog-2.1.0 = switching to ruby_parser
• heckle-1.4.2 = dead, unless we can think of something soon.
• ruby2ruby-1.2.2 = dropping block/proc support.
• ruby_parser-2.0.2 = no clue why it has a dependency still, no worries here.
• ZenHacks-1.0.1 = dropping block/proc support -- not that I support this.

I don't know the status of most of the projects dependent on PT or how they're going to deal with this issue. If you use one of these projects directly or indirectly and that project relies on PT for live method/block/proc, then you're probably going to be stuck on 1.8 for a while:

• SuperCaller-1.0.0 = unsupported - can drop live method support
• ambition-0.5.4
• argible-0.1.1
• integrity-0.1.9.3
• merb-action-args-1.0.11
• nitpick-1.0.2
• protocol-0.8.1
• red-4.1.7
• reek-1.0.0 = probably doesn't need live analysis
• roodi-1.3.5
• ruby_diff-0.2
• rubyjs-0.8.0
• sake-1.0.15
• thorero-action-args-0.9.4

There are probably other projects out there dependent on PT that I don't know about. All I've listed here are rubyforge gems that depend on PT in their gemspec.

You can check your gems using this:

gem list | egrep "(ambition|argible|integrity|merb-action-args|nitpick|protocol|red|reek|roodi|ruby_diff|rubyjs|sake|thorero-action-args)"

Here is the clean and easy way to do multiple environments in vlad. Here is my deploy.rb:

set :application, "proj"
set :repository,  "https://subversion/proj/trunk"

task :beta do
  set :domain,    "localhost"
  set :deploy_to, "/tmp/proj_beta"
end

task :dev do
  set :domain,    "localhost"
  set :deploy_to, "/tmp/proj_dev"
end

task :prod do
  set :domain,    "localhost"
  set :deploy_to, "/tmp/proj_prod"
end

By not specifying domain or deploy_to globally you force the use of an environment whenever you invoke a vlad task:

% rake vlad:debug | egrep "(domain|deploy_to):"
rake aborted!
Please specify the deploy path via the :deploy_to variable

Here is what it looks like with one of the three defined environments:

% rake beta vlad:debug | egrep "(domain|deploy_to):"
domain: localhost
deploy_to: /tmp/proj_beta
% rake dev vlad:debug | egrep "(domain|deploy_to):"
domain: localhost
deploy_to: /tmp/proj_dev
% rake prod vlad:debug | egrep "(domain|deploy_to):"
domain: localhost
deploy_to: /tmp/proj_prod

As you can see by yesterday's humongous release, I'm working on getting vlad lively again. My current plan is/was:

1. [DONE] Get vlad on its feet.
2. [DONE] Triage all bugs. Fix the biggies.
3. [DONE] Pull as much as we can from The ClusterFuck™ (aka github).
4. [DONE] Release 1.3.0
5. Release 1.3.1 with any fixes from 1.3.0 fallout.
6. Decide what the current 80% case is for rails these days and possibly change our defaults to fit that.
7. Find owners for all other vlad plugins, split them off as separate gems (eg: vlad-mercurial, vlad-nginx, etc).
8. Release 2.0.0, the newer, thinner, prettier vlad. Consider adding bows in vlad's hair.

So, I'd like your feedback:

What is the current favored deployment strategy? (I mean in terms of actual numbers, not this week's popular toy.)

Currently vlad has the following defaults:

  :app    => :mongrel,
  :scm    => :subversion,
  :web    => :apache,

Should any of these change?

ETA:

I just deleted a bunch of comments chock-full with that railz0r "+1" horse-shit. The plural of anecdote is not data. I'm not asking people to vote. I'm asking for actual numbers on big installations out there. I want the few people who own the hardware the slices are running on, not the individuals using the slices.

Vlad the Deployer is pragmatic application deployment automation, without mercy. Much like Capistrano, but with 1/10th the complexity. Vlad integrates seamlessly with Rake, and uses familiar and standard tools like ssh and rsync.

Impale your application on the heartless spike of the Deployer.

Changes:

1.3.0 / 2009-03-04

• 9 major enhancements:

  • Added darcs support. (Brian Palmer)
  • Added git support. (Garry Dolley)
  • Added lighttpd support.
  • Added merb support. (Jamie Macey)
  • Added passenger support. (Alan Harper)
  • Added/merged god, nginx, thin, and maintenance tasks. (github clusterfuck)
  • Allow set to specify that a proc value is :per_thread.
  • Apply Mercurial SCM support patch. Closes ticket 13475
  • remote_task now supports args and supplies task (by Daniel P. Kionka).

• 19 minor enhancements:

  • Add role toplevel method similar to namespace.
  • Added #put method that wraps up Tempfile/rsync pattern.
  • Added #role toplevel method, similar to #namespace.
  • Added FAQ for using vlad through a gateway.
  • Added Phil Hagelburg's one-line multi-stage deployment patch
  • Added rake tracing for rsync command.
  • Added umask variable.
  • Adds specific order to loading. Should fix a number of bugs.
  • Extended vladdemo.sh to allow for N simulated hosts (mostly for testing)
  • Fixed tempfile dependency in #put if you don't load lighttpd or perforce (yipstar)
  • Mercurial now automatically initializes the repository. (Jamie Macey)
  • Moved everything over to put.
  • Now requires rake 0.8.1+.
  • Parameterized 'head' into 'revision' variable (with head as default).
  • Split shared symlink creation to a separate task. (Steve Purcell)
  • Support rake 0.8.
  • Switched to ThreadGroup for Action#execute
  • Updated rakefile for new hoe abilities
  • remote_task :role now allows an empty list of hosts.

• 11 bug fixes:

  • Fixed vladdemo.rb, now uses my checkout for further stress testing.
  • Moved core recipe to front. Was breaking mongrel setup.
  • Added automatic client setup for perforce.
  • Fix mercurial support.
  • Fixed 'too many files' error.
  • Fixed a lame warning in the tests.
  • Fixed cleanup to actually properly clean up.
  • Fixed rake var doco
  • Moved generic app setup to core from mongrel.
  • SSH flags are now an Array for proper inclusion in the command. (Guillaume Pierronnet)
  • git archive now specifically specifies tar format. (knaveofdiamonds)

• http://rubyhitsquad.com/

• http://rubyforge.org/projects/hitsquad/

I've been meaning to write and run this benchmark for a while to see how things fare in the view world these days. Initially I did markaby vs tagz (my favorite at a svelte 244 lines). I then added builder out of curiosity's sake. Thanks to atmos I was able to get code and numbers for erubis and haml.

Builder is slightly faster than tagz, but not enough for me to want to switch to it. Tagz and markaby read so much better than builder, but markaby is so much slower (4.73 times slower than builder) that I can't justify its use.

Now if only I could get tagz working correctly with sinatra. :(

# iterations = 10000
#
#               user     system      total        real   multiplier
#
# builder   1.910000   0.000000   1.910000 (  1.918751) (1.00)
# tagz      2.310000   0.020000   2.330000 (  2.357710) (1.23)
# haml      5.370000   0.020000   5.390000 (  5.418876) (2.82)
# erubis    5.390000   0.020000   5.410000 (  5.446929) (2.84)
# markaby   8.980000   0.030000   9.010000 (  9.078748) (4.73)

Code behind the cut...

8 days, 5 hours, 24 minutes, and 52 seconds after I sent out my enigmatic post, Mr. Black (me, duh), Mr. White (Eric Hodel), Mr. Pink (Aaron Patterson, duh), and Mr. Blonde (John "Which one was Michael Madsen?" Barnette) all received offer letters from AT&T Interactive to work on one of their new ideas (totally green field! I don't think any of us have seen an empty repository in years and years!).

I'm amazed. I'm in awe. I had no idea that such a thing was possible, let alone so incredibly effortless. Thank you Ruby community for making such a thing possible and thank you ATTi for making such a bold move.

>> require 'time'
=> true
>> t0 = Time.parse "January 22, 2009 12:05:56 PM"
=> Thu Jan 22 12:05:56 -0800 2009
>> t1 = Time.parse "January 30, 2009 5:30:48 PM"
=> Fri Jan 30 17:30:48 -0800 2009
>> t = (t1 - t0).to_i
=> 710692
>> u = []
=> []
>> [86400, 3600, 60, 1].inject(t) { |t, n| m = t / n; u << m if m != 0; t % n }
=> 0
>> puts u.map {|t| '%02d' % t }.join(":").sub(/^0/, '')
8:05:24:52

Mr. Black, Mr. White, Mr. Pink, and Mr. Blonde are immediately available for hire. Package deal. 49 years of programming experience, 28 in Ruby. You know their names. Get in touch.