From sl4mmy at zerosphere.org  Sun Jun  8 19:14:11 2008
From: sl4mmy at zerosphere.org (Kent R. Spillner)
Date: Sun, 8 Jun 2008 18:14:11 -0500
Subject: [Chirb] REMINDER: New M.C. for tomorrow's meeting
Message-ID: <AB0E2C6D-D35C-4EF3-B4A7-E4803F73A618@zerosphere.org>

Hi, everybody!  (Hi, Dr. Nick!)

Since Josh is livin' large on the West Side for the time being, I'll  
be filling in as temporary M.C. for tomorrow night's RSpec experience  
report & discussion.

If you haven't already RSVP'd for the meeting (http://www.chirb.org/event/show/29 
), please take a moment to do so before tomorrow afternoon.  I'll be  
sending the list of names to the security ninjas at the Aon Center  
tomorrow around my lunch time.

We'll still be able to get you in for the meeting if you don't RSVP,  
but you'll need to call me on my cell: 312-961-9807.

See you tomorrow!

Best,
Kent


From jcroneme at thoughtworks.com  Mon Jun  9 13:46:27 2008
From: jcroneme at thoughtworks.com (Josh Cronemeyer)
Date: Mon, 9 Jun 2008 12:46:27 -0500
Subject: [Chirb] REMINDER: New M.C. for tomorrow's meeting AND NINJA
	RUMBLE
In-Reply-To: <AB0E2C6D-D35C-4EF3-B4A7-E4803F73A618@zerosphere.org>
Message-ID: <OFAEEBE765.96F226EF-ON86257463.00614630-88257463.0061A306@thoughtworks.com>

I updated the chirb site to have kent's celly-cell on there instead of 
mine.  Once again your best option is the RSVP before noon, but sometimes, 
yaknow, it's like hard to remember.  In that case flying fist of cellphone 
is the only way past the security ninjas.  Actually, with the lobby full 
of gongs I would say the AON is the perfect place for a huge ninja 
rumble!!

Josh Cronemeyer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080609/2e2c50da/attachment.html>

From jason at hostedlabs.com  Mon Jun  9 17:47:09 2008
From: jason at hostedlabs.com (Jason Rexilius)
Date: Mon, 09 Jun 2008 16:47:09 -0500
Subject: [Chirb] BARcamp 2008 organizer meeting
Message-ID: <484DA4DD.4060403@hostedlabs.com>

Organizer kick-off meeting

Friday, June 13th @ 18:30
Rock Bottom Brewery (dont like it but its close to Red Line).

Be there.. be square.. they're orthogonal.

-jason
847.208.1000

From andy at obtiva.com  Mon Jun  9 18:21:05 2008
From: andy at obtiva.com (Andy Maleh)
Date: Mon, 9 Jun 2008 17:21:05 -0500
Subject: [Chirb] BARcamp 2008 organizer meeting
In-Reply-To: <484DA4DD.4060403@hostedlabs.com>
References: <484DA4DD.4060403@hostedlabs.com>
Message-ID: <620ca2c40806091521p18d6e460r8f7c1b1186ac3380@mail.gmail.com>

Is everyone welcome? Will there be a flag to recognize the table (or bar
stool) ? :) What topics are being discussed?

Andy

On Mon, Jun 9, 2008 at 4:47 PM, Jason Rexilius <jason at hostedlabs.com> wrote:

> Organizer kick-off meeting
>
> Friday, June 13th @ 18:30
> Rock Bottom Brewery (dont like it but its close to Red Line).
>
> Be there.. be square.. they're orthogonal.
>
> -jason
> 847.208.1000
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>



-- 
//Obtiva - Agility Applied. Software Delivered.
www.obtiva.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080609/cd3432bc/attachment.html>

From dchelimsky at gmail.com  Tue Jun 10 00:31:52 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 9 Jun 2008 23:31:52 -0500
Subject: [Chirb] tools, already in play and coming soon
Message-ID: <9F8A0414-5152-4E38-8068-719E2D4042C9@gmail.com>

Hey Chirb,

I want to thank Nate for presenting his experiences with the Story  
Runner. It was good to hear about a team struggling through the  
problems and ultimately finding solutions and value.

I also want to thank you for sticking around for my follow up. I know  
I stuffed a lot into just a few minutes, but I was grateful for the  
opportunity to share some of the things I've learned since Story  
Runner's appearance on the scene. For those interested, the slides  
from my talk at RailsConf (of which you saw just a few) is at http://rubyurl.com/xtbQ 
.

During Nate's talk I mentioned a couple of tools: screw-unit and  
johnson. Both can be found at github:

http://github.com/jbarnette/johnson
http://github.com/nathansobo/screw-unit

At this point johnson is still incubating but I'm told that in the  
next month or so you'll be able to say something like  
Johnson.require('johnson/browser/ff') and you're running the js in  
ruby in memory w/ firefox's particular idiosyncrasies. Rinse, repeat  
with 'johnson/browser/ie' ... you get the idea.

screw-unit is an in-browser js unit testing tool modeled after RSpec.  
I just started using it but I really like it and it's getting some  
mind-share (so it's moving quickly).

Lastly, I may have mis-spoke about rails loading up columns from  
schema.rb - I'm looking into it and will follow up when I learn the  
truth. So Ryan - keep using unit-record for now :)

Cheers,
David

From pgross at gmail.com  Tue Jun 10 01:02:44 2008
From: pgross at gmail.com (Paul Gross)
Date: Tue, 10 Jun 2008 00:02:44 -0500
Subject: [Chirb] tools, already in play and coming soon
In-Reply-To: <9F8A0414-5152-4E38-8068-719E2D4042C9@gmail.com>
References: <9F8A0414-5152-4E38-8068-719E2D4042C9@gmail.com>
Message-ID: <484E0AF4.7050508@gmail.com>


> Lastly, I may have mis-spoke about rails loading up columns from 
> schema.rb - I'm looking into it and will follow up when I learn the 
> truth. So Ryan - keep using unit-record for now :)
>

UnitRecord (http://unit-test-ar.rubyforge.org/) parses schema.rb to 
determine the columns and overrides the connection method on 
ActiveRecord::Base, so there will be no database hits.  The philosophy 
is that unit tests should be entirely isolated, including no database 
access.

The meat of stub_model is:

def stub_model(model_class, stubs = {})
  returning model_class.new do |model|
    (class << model; self; end).class_eval do
      def connection
        raise Spec::Rails::IllegalDataAccessException.new("stubbed 
models are not allowed to access the database")
      end
    end
  end
end

It defines connection on the singleton class to raise an exception.  
However, as soon as you do model_class.new, rails goes to the database 
to fetch the columns.  So, stub_model will still cause a database hit 
once for every object, but not again.  The philosophy here seems to be 
that a few database hits are ok for ease of use.

Thanks,

Paul Gross
http://www.pgrs.net



From cremes.devlist at mac.com  Tue Jun 10 14:34:53 2008
From: cremes.devlist at mac.com (Chuck Remes)
Date: Tue, 10 Jun 2008 13:34:53 -0500
Subject: [Chirb] need a TDD/BDD class in Chicago
Message-ID: <E1D1FCD3-6FC8-4D23-8D2D-0B873C7B135B@mac.com>

I've been doing Ruby for a while now and have jumped on the rspec  
bandwagon. However, I still don't feel that I really grok the whole  
BDD mindset so I'm looking for some external help.  Does anyone know  
of a company that does a Ruby TDD/BDD class anywhere in Chicago (or  
nearby)?

If anyone knows of a class that I could take, I would really  
appreciate it. Or, if someone wants to tutor me at a north side  
meetup, that would be cool too. :-)

cr


From dchelimsky at gmail.com  Wed Jun 11 02:36:24 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 11 Jun 2008 01:36:24 -0500
Subject: [Chirb] tools, already in play and coming soon
In-Reply-To: <9F8A0414-5152-4E38-8068-719E2D4042C9@gmail.com>
References: <9F8A0414-5152-4E38-8068-719E2D4042C9@gmail.com>
Message-ID: <56E43D91-0EA7-44AA-8982-60C7593E6F3B@gmail.com>

On Jun 9, 2008, at 11:31 PM, David Chelimsky wrote:

> Hey Chirb,
>
> Lastly, I may have mis-spoke about rails loading up columns from  
> schema.rb - I'm looking into it and will follow up when I learn the  
> truth. So Ryan - keep using unit-record for now :)

I definitely mis-spoke. I don't know where I got that in my head, but  
it seems I did.

I don't recall who said it, but unit_record does the column caching I  
thought rails did. So now it's off to figure out how to get rspec to  
play nice w/ unit_record.

More soon.

Cheers,
David

From ryan at platte.name  Wed Jun 11 09:37:35 2008
From: ryan at platte.name (Ryan Platte)
Date: Wed, 11 Jun 2008 08:37:35 -0500
Subject: [Chirb] tools, already in play and coming soon
In-Reply-To: <56E43D91-0EA7-44AA-8982-60C7593E6F3B@gmail.com>
References: <9F8A0414-5152-4E38-8068-719E2D4042C9@gmail.com>
	<56E43D91-0EA7-44AA-8982-60C7593E6F3B@gmail.com>
Message-ID: <2f1a1dcb0806110637t259fc04dtcc2170a7fa233fa7@mail.gmail.com>

Here are some Rake tasks I created to use RSpec with UnitRecord. I set the
default task to first run spec:fast, then spec:slow, so if the fast ones
fail we don't have to wait on the slow ones to set up and run.

The fly in the ointment is that schema.rb has to be current.

namespace :spec do

  desc "Run all fast specs in spec directory (excluding plugin specs)"
  Spec::Rake::SpecTask.new(:fast) do |t|
    t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
    t.spec_files = FileList['spec/**/*_fast_spec.rb']
    #t.ruby_opts = ['-r spec/spec_helper', '-rubygems', '-runit_record', "-e
'ActiveRecord::Base.disconnect!'"]
  end

  desc "Run all non-fast specs in spec directory (excluding plugin specs)"
  Spec::Rake::SpecTask.new(:slow => spec_prereq) do |t|
    t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
    t.spec_files =
FileList['spec/**/*_spec.rb'].exclude('spec/**/*_fast_spec.rb')
  end

end


On Wed, Jun 11, 2008 at 1:36 AM, David Chelimsky <dchelimsky at gmail.com>
wrote:

> On Jun 9, 2008, at 11:31 PM, David Chelimsky wrote:
>
>  Hey Chirb,
>>
>> Lastly, I may have mis-spoke about rails loading up columns from schema.rb
>> - I'm looking into it and will follow up when I learn the truth. So Ryan -
>> keep using unit-record for now :)
>>
>
> I definitely mis-spoke. I don't know where I got that in my head, but it
> seems I did.
>
> I don't recall who said it, but unit_record does the column caching I
> thought rails did. So now it's off to figure out how to get rspec to play
> nice w/ unit_record.
>
> More soon.
>
>
> Cheers,
> David
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>



-- 
Ryan Platte
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080611/2bfb3a1f/attachment.html>

From jake.scruggs at gmail.com  Wed Jun 11 10:26:00 2008
From: jake.scruggs at gmail.com (Jake Scruggs)
Date: Wed, 11 Jun 2008 09:26:00 -0500
Subject: [Chirb] tools, already in play and coming soon
In-Reply-To: <2f1a1dcb0806110637t259fc04dtcc2170a7fa233fa7@mail.gmail.com>
References: <9F8A0414-5152-4E38-8068-719E2D4042C9@gmail.com>
	<56E43D91-0EA7-44AA-8982-60C7593E6F3B@gmail.com>
	<2f1a1dcb0806110637t259fc04dtcc2170a7fa233fa7@mail.gmail.com>
Message-ID: <215638340806110726o15cd8ecav3c54868c6a401d7c@mail.gmail.com>

I've been using the NullDb (http://agilewebdevelopment.com/plugins/nulldb)
plugin to disconnect RSpec from the database.

I don't like the global disconnect (for all specs everywhere) that the web
page suggests, so I set up this in my spec_helper:

describe "Unit Spec", :shared => true do
  before :all do
    ActiveRecord::Base.establish_connection(:adapter => :nulldb)
  end

  after :all do
    ActiveRecord::Base.establish_connection(:test)
  end
end

and then say this inside any describe block I want to disconnect from the
db:

require File.dirname(__FILE__) + "/../spec_helper"

describe User do
  it_should_behave_like "Unit Spec"
.
.
.

using nested describes to separate my unit (don't hit the db) from my
functional (do hit the db) specs

-Jake

On Wed, Jun 11, 2008 at 8:37 AM, Ryan Platte <ryan at platte.name> wrote:

> Here are some Rake tasks I created to use RSpec with UnitRecord. I set the
> default task to first run spec:fast, then spec:slow, so if the fast ones
> fail we don't have to wait on the slow ones to set up and run.
>
> The fly in the ointment is that schema.rb has to be current.
>
> namespace :spec do
>
>   desc "Run all fast specs in spec directory (excluding plugin specs)"
>   Spec::Rake::SpecTask.new(:fast) do |t|
>     t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
>     t.spec_files = FileList['spec/**/*_fast_spec.rb']
>     #t.ruby_opts = ['-r spec/spec_helper', '-rubygems', '-runit_record',
> "-e 'ActiveRecord::Base.disconnect!'"]
>   end
>
>   desc "Run all non-fast specs in spec directory (excluding plugin specs)"
>   Spec::Rake::SpecTask.new(:slow => spec_prereq) do |t|
>     t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
>     t.spec_files =
> FileList['spec/**/*_spec.rb'].exclude('spec/**/*_fast_spec.rb')
>   end
>
> end
>
>
> On Wed, Jun 11, 2008 at 1:36 AM, David Chelimsky <dchelimsky at gmail.com>
> wrote:
>
>> On Jun 9, 2008, at 11:31 PM, David Chelimsky wrote:
>>
>>  Hey Chirb,
>>>
>>> Lastly, I may have mis-spoke about rails loading up columns from
>>> schema.rb - I'm looking into it and will follow up when I learn the truth.
>>> So Ryan - keep using unit-record for now :)
>>>
>>
>> I definitely mis-spoke. I don't know where I got that in my head, but it
>> seems I did.
>>
>> I don't recall who said it, but unit_record does the column caching I
>> thought rails did. So now it's off to figure out how to get rspec to play
>> nice w/ unit_record.
>>
>> More soon.
>>
>>
>> Cheers,
>> David
>> _______________________________________________
>> ChicagoGroup-Members-List at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>
>
>
>
> --
> Ryan Platte
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080611/6c250425/attachment-0001.html>

From dchelimsky at gmail.com  Wed Jun 11 11:08:38 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 11 Jun 2008 10:08:38 -0500
Subject: [Chirb] tools, already in play and coming soon
In-Reply-To: <215638340806110726o15cd8ecav3c54868c6a401d7c@mail.gmail.com>
References: <9F8A0414-5152-4E38-8068-719E2D4042C9@gmail.com>
	<56E43D91-0EA7-44AA-8982-60C7593E6F3B@gmail.com>
	<2f1a1dcb0806110637t259fc04dtcc2170a7fa233fa7@mail.gmail.com>
	<215638340806110726o15cd8ecav3c54868c6a401d7c@mail.gmail.com>
Message-ID: <A97BCD24-4AB5-439F-9BD9-7402541B7D32@gmail.com>

Hey Jake - thanks for sharing this. Couple o' comments below:

On Jun 11, 2008, at 9:26 AM, Jake Scruggs wrote:

> I've been using the NullDb (http://agilewebdevelopment.com/plugins/nulldb 
> ) plugin to disconnect RSpec from the database.

The only drawback I've heard about NullDb is that it fails silently in  
certain cases - has led to some painful debugging. Have you had that  
experience?

> I don't like the global disconnect (for all specs everywhere) that  
> the web page suggests, so I set up this in my spec_helper:
>
> describe "Unit Spec", :shared => true do
>   before :all do
>     ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>   end
>
>   after :all do
>     ActiveRecord::Base.establish_connection(:test)
>   end
> end
>
> and then say this inside any describe block I want to disconnect  
> from the db:
>
> require File.dirname(__FILE__) + "/../spec_helper"
>
> describe User do
>   it_should_behave_like "Unit Spec"

This is cool that it works, but using it_should_behave_like feels odd  
to me in this case. The User should not behave like a Unit Spec, the  
examples should be disconnected.

You can do this instead if you like:

share_as :Disconnected do
   before :all do
     ActiveRecord::Base.establish_connection(:adapter => :nulldb)
   end

   after :all do
     ActiveRecord::Base.establish_connection(:test)
   end
end

describe User do
   include Disconnected
...

Right now we don't have an arbitrary tagging mechanism but it's  
something we've talked about. This gives me an idea that I'd like to  
implement, and everything is pretty much in place to support this,  
where the options hash is available to you in the before and after  
blocks, so you could do this (CAREFUL - THIS DOES NOT WORK TODAY):

Spec::Runner.configure do |config|
   config.before(:all)
     if example_group_options[:disconnected]
       ActiveRecord::Base.establish_connection(:adapter => :nulldb)
     end
   end
   config.after(:all)
     if example_group_options[:disconnected]
       ActiveRecord::Base.establish_connection(:test)
     end
   end
end

Then you'd be able to say:

describe User, :disconnected => true do
   ...

WDYT about that?

Cheers,
David



>
> .
> .
> .
>
> using nested describes to separate my unit (don't hit the db) from  
> my functional (do hit the db) specs
>
> -Jake
>
> On Wed, Jun 11, 2008 at 8:37 AM, Ryan Platte <ryan at platte.name> wrote:
> Here are some Rake tasks I created to use RSpec with UnitRecord. I  
> set the default task to first run spec:fast, then spec:slow, so if  
> the fast ones fail we don't have to wait on the slow ones to set up  
> and run.
>
> The fly in the ointment is that schema.rb has to be current.
>
> namespace :spec do
>
>   desc "Run all fast specs in spec directory (excluding plugin specs)"
>   Spec::Rake::SpecTask.new(:fast) do |t|
>     t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
>     t.spec_files = FileList['spec/**/*_fast_spec.rb']
>     #t.ruby_opts = ['-r spec/spec_helper', '-rubygems', '- 
> runit_record', "-e 'ActiveRecord::Base.disconnect!'"]
>   end
>
>   desc "Run all non-fast specs in spec directory (excluding plugin  
> specs)"
>   Spec::Rake::SpecTask.new(:slow => spec_prereq) do |t|
>     t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
>     t.spec_files = FileList['spec/**/*_spec.rb'].exclude('spec/**/ 
> *_fast_spec.rb')
>   end
>
> end
>
>
> On Wed, Jun 11, 2008 at 1:36 AM, David Chelimsky  
> <dchelimsky at gmail.com> wrote:
> On Jun 9, 2008, at 11:31 PM, David Chelimsky wrote:
>
> Hey Chirb,
>
>
> Lastly, I may have mis-spoke about rails loading up columns from  
> schema.rb - I'm looking into it and will follow up when I learn the  
> truth. So Ryan - keep using unit-record for now :)
>
> I definitely mis-spoke. I don't know where I got that in my head,  
> but it seems I did.
>
> I don't recall who said it, but unit_record does the column caching  
> I thought rails did. So now it's off to figure out how to get rspec  
> to play nice w/ unit_record.
>
> More soon.
>
>
> Cheers,
> David
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
>
>
> -- 
> Ryan Platte
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080611/e34d434c/attachment.html>

From trevorturk at yahoo.com  Wed Jun 11 17:10:05 2008
From: trevorturk at yahoo.com (Trevor Turk)
Date: Wed, 11 Jun 2008 16:10:05 -0500
Subject: [Chirb] [Job] LifeSnapz
Message-ID: <d54e183d0806111410v56688e89k240aabb897c1652b@mail.gmail.com>

The place I've been working for the past 2 months is hiring. I've been
really happy here so far - maybe somebody on this list would be
interested? Here's the job posting:

http://jobs.illinoistech.org/jobs/show/169428-senior-rails-developer

Let me know if you have any questions,
- Trevor

From mmangino at elevatedrails.com  Wed Jun 11 20:55:14 2008
From: mmangino at elevatedrails.com (Mike Mangino)
Date: Wed, 11 Jun 2008 19:55:14 -0500
Subject: [Chirb] [Job] LifeSnapz
In-Reply-To: <d54e183d0806111410v56688e89k240aabb897c1652b@mail.gmail.com>
References: <d54e183d0806111410v56688e89k240aabb897c1652b@mail.gmail.com>
Message-ID: <D5C6318A-EE77-4C9C-A08D-932B82793EA2@elevatedrails.com>

Cool! It's worth noting that the site that is serving that job ad is  
running Rails, and based in Chicago. Check out http://www.jobcoin.com

Mike

On Jun 11, 2008, at 4:10 PM, Trevor Turk wrote:

> The place I've been working for the past 2 months is hiring. I've been
> really happy here so far - maybe somebody on this list would be
> interested? Here's the job posting:
>
> http://jobs.illinoistech.org/jobs/show/169428-senior-rails-developer
>
> Let me know if you have any questions,
> - Trevor
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list

--
Mike Mangino
http://www.elevatedrails.com




From jake.scruggs at gmail.com  Thu Jun 12 20:23:19 2008
From: jake.scruggs at gmail.com (Jake Scruggs)
Date: Thu, 12 Jun 2008 19:23:19 -0500
Subject: [Chirb] tools, already in play and coming soon
In-Reply-To: <A97BCD24-4AB5-439F-9BD9-7402541B7D32@gmail.com>
References: <9F8A0414-5152-4E38-8068-719E2D4042C9@gmail.com>
	<56E43D91-0EA7-44AA-8982-60C7593E6F3B@gmail.com>
	<2f1a1dcb0806110637t259fc04dtcc2170a7fa233fa7@mail.gmail.com>
	<215638340806110726o15cd8ecav3c54868c6a401d7c@mail.gmail.com>
	<A97BCD24-4AB5-439F-9BD9-7402541B7D32@gmail.com>
Message-ID: <215638340806121723m976e915pc743a223eb4648f3@mail.gmail.com>

I haven't had any problems with NullDB, but failing silently is its thing
(Null Object Pattern and all) so be careful.  I think the tagging bit you
describe as coming soon to RSpec is pretty cool.

I'm probably going to blog about this soon and will quote some things from
Ryan and David's responses -- unless of course either of you object.
-Jake

On Wed, Jun 11, 2008 at 10:08 AM, David Chelimsky <dchelimsky at gmail.com>
wrote:

> Hey Jake - thanks for sharing this. Couple o' comments below:
> On Jun 11, 2008, at 9:26 AM, Jake Scruggs wrote:
>
> I've been using the NullDb (http://agilewebdevelopment.com/plugins/nulldb)
> plugin to disconnect RSpec from the database.
>
>
> The only drawback I've heard about NullDb is that it fails silently in
> certain cases - has led to some painful debugging. Have you had that
> experience?
>
> I don't like the global disconnect (for all specs everywhere) that the web
> page suggests, so I set up this in my spec_helper:
>
> describe "Unit Spec", :shared => true do
>   before :all do
>     ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>   end
>
>   after :all do
>     ActiveRecord::Base.establish_connection(:test)
>   end
> end
>
> and then say this inside any describe block I want to disconnect from the
> db:
>
> require File.dirname(__FILE__) + "/../spec_helper"
>
> describe User do
>   it_should_behave_like "Unit Spec"
>
>
> This is cool that it works, but using it_should_behave_like feels odd to me
> in this case. The User should not behave like a Unit Spec, the examples
> should be disconnected.
>
> You can do this instead if you like:
>
> share_as :Disconnected do
>   before :all do
>     ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>   end
>
>   after :all do
>     ActiveRecord::Base.establish_connection(:test)
>   end
> end
>
> describe User do
>   include Disconnected
> ...
>
> Right now we don't have an arbitrary tagging mechanism but it's something
> we've talked about. This gives me an idea that I'd like to implement, and
> everything is pretty much in place to support this, where the options hash
> is available to you in the before and after blocks, so you could do this
> (CAREFUL - THIS DOES NOT WORK TODAY):
>
> Spec::Runner.configure do |config|
>   config.before(:all)
>     if example_group_options[:disconnected]
>       ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>     end
>   end
>   config.after(:all)
>     if example_group_options[:disconnected]
>       ActiveRecord::Base.establish_connection(:test)
>     end
>   end
> end
>
> Then you'd be able to say:
>
> describe User, :disconnected => true do
>   ...
>
> WDYT about that?
>
> Cheers,
> David
>
>
>
>
> .
> .
> .
>
> using nested describes to separate my unit (don't hit the db) from my
> functional (do hit the db) specs
>
> -Jake
>
> On Wed, Jun 11, 2008 at 8:37 AM, Ryan Platte <ryan at platte.name> wrote:
>
>> Here are some Rake tasks I created to use RSpec with UnitRecord. I set the
>> default task to first run spec:fast, then spec:slow, so if the fast ones
>> fail we don't have to wait on the slow ones to set up and run.
>>
>> The fly in the ointment is that schema.rb has to be current.
>>
>> namespace :spec do
>>
>>   desc "Run all fast specs in spec directory (excluding plugin specs)"
>>   Spec::Rake::SpecTask.new(:fast) do |t|
>>     t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
>>     t.spec_files = FileList['spec/**/*_fast_spec.rb']
>>     #t.ruby_opts = ['-r spec/spec_helper', '-rubygems', '-runit_record',
>> "-e 'ActiveRecord::Base.disconnect!'"]
>>   end
>>
>>   desc "Run all non-fast specs in spec directory (excluding plugin specs)"
>>   Spec::Rake::SpecTask.new(:slow => spec_prereq) do |t|
>>     t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
>>     t.spec_files =
>> FileList['spec/**/*_spec.rb'].exclude('spec/**/*_fast_spec.rb')
>>   end
>>
>> end
>>
>>
>> On Wed, Jun 11, 2008 at 1:36 AM, David Chelimsky <dchelimsky at gmail.com>
>> wrote:
>>
>>> On Jun 9, 2008, at 11:31 PM, David Chelimsky wrote:
>>>
>>>  Hey Chirb,
>>>>
>>>> Lastly, I may have mis-spoke about rails loading up columns from
>>>> schema.rb - I'm looking into it and will follow up when I learn the truth.
>>>> So Ryan - keep using unit-record for now :)
>>>>
>>>
>>> I definitely mis-spoke. I don't know where I got that in my head, but it
>>> seems I did.
>>>
>>> I don't recall who said it, but unit_record does the column caching I
>>> thought rails did. So now it's off to figure out how to get rspec to play
>>> nice w/ unit_record.
>>>
>>> More soon.
>>>
>>>
>>> Cheers,
>>> David
>>> _______________________________________________
>>> ChicagoGroup-Members-List at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>>
>>
>>
>>
>> --
>> Ryan Platte
>> _______________________________________________
>> ChicagoGroup-Members-List at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>
>
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
>
>
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080612/99acf5a5/attachment-0001.html>

From dchelimsky at gmail.com  Thu Jun 12 20:26:49 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 12 Jun 2008 19:26:49 -0500
Subject: [Chirb] tools, already in play and coming soon
In-Reply-To: <215638340806121723m976e915pc743a223eb4648f3@mail.gmail.com>
References: <9F8A0414-5152-4E38-8068-719E2D4042C9@gmail.com>
	<56E43D91-0EA7-44AA-8982-60C7593E6F3B@gmail.com>
	<2f1a1dcb0806110637t259fc04dtcc2170a7fa233fa7@mail.gmail.com>
	<215638340806110726o15cd8ecav3c54868c6a401d7c@mail.gmail.com>
	<A97BCD24-4AB5-439F-9BD9-7402541B7D32@gmail.com>
	<215638340806121723m976e915pc743a223eb4648f3@mail.gmail.com>
Message-ID: <DB1AF113-78F9-43A2-895C-D1D05179C1DD@gmail.com>

On Jun 12, 2008, at 7:23 PM, Jake Scruggs wrote:

> I haven't had any problems with NullDB, but failing silently is its  
> thing (Null Object Pattern and all) so be careful.  I think the  
> tagging bit you describe as coming soon to RSpec is pretty cool.
>
> I'm probably going to blog about this soon and will quote some  
> things from Ryan and David's responses -- unless of course either of  
> you object.

No objection here.

>
> -Jake
>
> On Wed, Jun 11, 2008 at 10:08 AM, David Chelimsky <dchelimsky at gmail.com 
> > wrote:
> Hey Jake - thanks for sharing this. Couple o' comments below:
>
> On Jun 11, 2008, at 9:26 AM, Jake Scruggs wrote:
>> I've been using the NullDb (http://agilewebdevelopment.com/plugins/nulldb 
>> ) plugin to disconnect RSpec from the database.
>
> The only drawback I've heard about NullDb is that it fails silently  
> in certain cases - has led to some painful debugging. Have you had  
> that experience?
>
>> I don't like the global disconnect (for all specs everywhere) that  
>> the web page suggests, so I set up this in my spec_helper:
>>
>> describe "Unit Spec", :shared => true do
>>   before :all do
>>     ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>>   end
>>
>>   after :all do
>>     ActiveRecord::Base.establish_connection(:test)
>>   end
>> end
>>
>> and then say this inside any describe block I want to disconnect  
>> from the db:
>>
>> require File.dirname(__FILE__) + "/../spec_helper"
>>
>> describe User do
>>   it_should_behave_like "Unit Spec"
>
> This is cool that it works, but using it_should_behave_like feels  
> odd to me in this case. The User should not behave like a Unit Spec,  
> the examples should be disconnected.
>
> You can do this instead if you like:
>
> share_as :Disconnected do
>
>   before :all do
>     ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>   end
>
>   after :all do
>     ActiveRecord::Base.establish_connection(:test)
>   end
> end
>
> describe User do
>   include Disconnected
> ...
>
> Right now we don't have an arbitrary tagging mechanism but it's  
> something we've talked about. This gives me an idea that I'd like to  
> implement, and everything is pretty much in place to support this,  
> where the options hash is available to you in the before and after  
> blocks, so you could do this (CAREFUL - THIS DOES NOT WORK TODAY):
>
> Spec::Runner.configure do |config|
>   config.before(:all)
>     if example_group_options[:disconnected]
>       ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>     end
>   end
>   config.after(:all)
>     if example_group_options[:disconnected]
>       ActiveRecord::Base.establish_connection(:test)
>     end
>   end
> end
>
> Then you'd be able to say:
>
> describe User, :disconnected => true do
>   ...
>
> WDYT about that?
>
> Cheers,
> David
>
>
>
>>
>> .
>> .
>> .
>>
>> using nested describes to separate my unit (don't hit the db) from  
>> my functional (do hit the db) specs
>>
>> -Jake
>>
>> On Wed, Jun 11, 2008 at 8:37 AM, Ryan Platte <ryan at platte.name>  
>> wrote:
>> Here are some Rake tasks I created to use RSpec with UnitRecord. I  
>> set the default task to first run spec:fast, then spec:slow, so if  
>> the fast ones fail we don't have to wait on the slow ones to set up  
>> and run.
>>
>> The fly in the ointment is that schema.rb has to be current.
>>
>> namespace :spec do
>>
>>   desc "Run all fast specs in spec directory (excluding plugin  
>> specs)"
>>   Spec::Rake::SpecTask.new(:fast) do |t|
>>     t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
>>     t.spec_files = FileList['spec/**/*_fast_spec.rb']
>>     #t.ruby_opts = ['-r spec/spec_helper', '-rubygems', '- 
>> runit_record', "-e 'ActiveRecord::Base.disconnect!'"]
>>   end
>>
>>   desc "Run all non-fast specs in spec directory (excluding plugin  
>> specs)"
>>   Spec::Rake::SpecTask.new(:slow => spec_prereq) do |t|
>>     t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
>>     t.spec_files = FileList['spec/**/*_spec.rb'].exclude('spec/**/ 
>> *_fast_spec.rb')
>>   end
>>
>> end
>>
>>
>> On Wed, Jun 11, 2008 at 1:36 AM, David Chelimsky <dchelimsky at gmail.com 
>> > wrote:
>> On Jun 9, 2008, at 11:31 PM, David Chelimsky wrote:
>>
>> Hey Chirb,
>>
>>
>> Lastly, I may have mis-spoke about rails loading up columns from  
>> schema.rb - I'm looking into it and will follow up when I learn the  
>> truth. So Ryan - keep using unit-record for now :)
>>
>> I definitely mis-spoke. I don't know where I got that in my head,  
>> but it seems I did.
>>
>> I don't recall who said it, but unit_record does the column caching  
>> I thought rails did. So now it's off to figure out how to get rspec  
>> to play nice w/ unit_record.
>>
>> More soon.
>>
>>
>> Cheers,
>> David
>> _______________________________________________
>> ChicagoGroup-Members-List at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>
>>
>>
>> -- 
>> Ryan Platte
>> _______________________________________________
>> ChicagoGroup-Members-List at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>
>> _______________________________________________
>> ChicagoGroup-Members-List at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
>
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080612/6be753d2/attachment.html>

From ryan at platte.name  Thu Jun 12 21:29:54 2008
From: ryan at platte.name (Ryan Platte)
Date: Thu, 12 Jun 2008 20:29:54 -0500
Subject: [Chirb] tools, already in play and coming soon
In-Reply-To: <215638340806121723m976e915pc743a223eb4648f3@mail.gmail.com>
References: <9F8A0414-5152-4E38-8068-719E2D4042C9@gmail.com>
	<56E43D91-0EA7-44AA-8982-60C7593E6F3B@gmail.com>
	<2f1a1dcb0806110637t259fc04dtcc2170a7fa233fa7@mail.gmail.com>
	<215638340806110726o15cd8ecav3c54868c6a401d7c@mail.gmail.com>
	<A97BCD24-4AB5-439F-9BD9-7402541B7D32@gmail.com>
	<215638340806121723m976e915pc743a223eb4648f3@mail.gmail.com>
Message-ID: <2f1a1dcb0806121829g76587d50lf6aba4e495b7a8e5@mail.gmail.com>

Go for it, Jake. I'm interested to see what you'll write.

On Thu, Jun 12, 2008 at 7:23 PM, Jake Scruggs <jake.scruggs at gmail.com>
wrote:

> I haven't had any problems with NullDB, but failing silently is its thing
> (Null Object Pattern and all) so be careful.  I think the tagging bit you
> describe as coming soon to RSpec is pretty cool.
>
> I'm probably going to blog about this soon and will quote some things from
> Ryan and David's responses -- unless of course either of you object.
> -Jake
>
>
> On Wed, Jun 11, 2008 at 10:08 AM, David Chelimsky <dchelimsky at gmail.com>
> wrote:
>
>> Hey Jake - thanks for sharing this. Couple o' comments below:
>> On Jun 11, 2008, at 9:26 AM, Jake Scruggs wrote:
>>
>> I've been using the NullDb (http://agilewebdevelopment.com/plugins/nulldb)
>> plugin to disconnect RSpec from the database.
>>
>>
>> The only drawback I've heard about NullDb is that it fails silently in
>> certain cases - has led to some painful debugging. Have you had that
>> experience?
>>
>> I don't like the global disconnect (for all specs everywhere) that the web
>> page suggests, so I set up this in my spec_helper:
>>
>> describe "Unit Spec", :shared => true do
>>   before :all do
>>     ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>>   end
>>
>>   after :all do
>>     ActiveRecord::Base.establish_connection(:test)
>>   end
>> end
>>
>> and then say this inside any describe block I want to disconnect from the
>> db:
>>
>> require File.dirname(__FILE__) + "/../spec_helper"
>>
>> describe User do
>>   it_should_behave_like "Unit Spec"
>>
>>
>> This is cool that it works, but using it_should_behave_like feels odd to
>> me in this case. The User should not behave like a Unit Spec, the examples
>> should be disconnected.
>>
>> You can do this instead if you like:
>>
>> share_as :Disconnected do
>>   before :all do
>>     ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>>   end
>>
>>   after :all do
>>     ActiveRecord::Base.establish_connection(:test)
>>   end
>> end
>>
>> describe User do
>>   include Disconnected
>> ...
>>
>> Right now we don't have an arbitrary tagging mechanism but it's something
>> we've talked about. This gives me an idea that I'd like to implement, and
>> everything is pretty much in place to support this, where the options hash
>> is available to you in the before and after blocks, so you could do this
>> (CAREFUL - THIS DOES NOT WORK TODAY):
>>
>> Spec::Runner.configure do |config|
>>   config.before(:all)
>>     if example_group_options[:disconnected]
>>       ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>>     end
>>   end
>>   config.after(:all)
>>     if example_group_options[:disconnected]
>>       ActiveRecord::Base.establish_connection(:test)
>>     end
>>   end
>> end
>>
>> Then you'd be able to say:
>>
>> describe User, :disconnected => true do
>>   ...
>>
>> WDYT about that?
>>
>> Cheers,
>> David
>>
>>
>>
>>
>> .
>> .
>> .
>>
>> using nested describes to separate my unit (don't hit the db) from my
>> functional (do hit the db) specs
>>
>> -Jake
>>
>> On Wed, Jun 11, 2008 at 8:37 AM, Ryan Platte <ryan at platte.name> wrote:
>>
>>> Here are some Rake tasks I created to use RSpec with UnitRecord. I set
>>> the default task to first run spec:fast, then spec:slow, so if the fast ones
>>> fail we don't have to wait on the slow ones to set up and run.
>>>
>>> The fly in the ointment is that schema.rb has to be current.
>>>
>>> namespace :spec do
>>>
>>>   desc "Run all fast specs in spec directory (excluding plugin specs)"
>>>   Spec::Rake::SpecTask.new(:fast) do |t|
>>>     t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
>>>     t.spec_files = FileList['spec/**/*_fast_spec.rb']
>>>     #t.ruby_opts = ['-r spec/spec_helper', '-rubygems', '-runit_record',
>>> "-e 'ActiveRecord::Base.disconnect!'"]
>>>   end
>>>
>>>   desc "Run all non-fast specs in spec directory (excluding plugin
>>> specs)"
>>>   Spec::Rake::SpecTask.new(:slow => spec_prereq) do |t|
>>>     t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
>>>     t.spec_files =
>>> FileList['spec/**/*_spec.rb'].exclude('spec/**/*_fast_spec.rb')
>>>   end
>>>
>>> end
>>>
>>>
>>> On Wed, Jun 11, 2008 at 1:36 AM, David Chelimsky <dchelimsky at gmail.com>
>>> wrote:
>>>
>>>> On Jun 9, 2008, at 11:31 PM, David Chelimsky wrote:
>>>>
>>>>  Hey Chirb,
>>>>>
>>>>> Lastly, I may have mis-spoke about rails loading up columns from
>>>>> schema.rb - I'm looking into it and will follow up when I learn the truth.
>>>>> So Ryan - keep using unit-record for now :)
>>>>>
>>>>
>>>> I definitely mis-spoke. I don't know where I got that in my head, but it
>>>> seems I did.
>>>>
>>>> I don't recall who said it, but unit_record does the column caching I
>>>> thought rails did. So now it's off to figure out how to get rspec to play
>>>> nice w/ unit_record.
>>>>
>>>> More soon.
>>>>
>>>>
>>>> Cheers,
>>>> David
>>>> _______________________________________________
>>>> ChicagoGroup-Members-List at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>>>
>>>
>>>
>>>
>>> --
>>> Ryan Platte
>>> _______________________________________________
>>> ChicagoGroup-Members-List at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>>
>>
>> _______________________________________________
>> ChicagoGroup-Members-List at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>
>>
>>
>> _______________________________________________
>> ChicagoGroup-Members-List at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>
>
>
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>



-- 
Ryan Platte
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080612/4c13e906/attachment-0001.html>

From jason at hostedlabs.com  Fri Jun 13 10:58:07 2008
From: jason at hostedlabs.com (Jason Rexilius)
Date: Fri, 13 Jun 2008 09:58:07 -0500
Subject: [Chirb] BARcamp organizer meeting tonight
In-Reply-To: <620ca2c40806091521p18d6e460r8f7c1b1186ac3380@mail.gmail.com>
References: <484DA4DD.4060403@hostedlabs.com>
	<620ca2c40806091521p18d6e460r8f7c1b1186ac3380@mail.gmail.com>
Message-ID: <48528AFF.2090905@hostedlabs.com>

Is anyone going to make it?

I should probably try and reserve a table if possible for n people...

Organizer kick-off meeting

Friday, June 13th @ 18:30
Rock Bottom Brewery (dont like it but its close to Red Line).

-jason
847.208.1000

From greg.pederson at gmail.com  Fri Jun 13 12:05:34 2008
From: greg.pederson at gmail.com (Greg Pederson)
Date: Fri, 13 Jun 2008 12:05:34 -0400
Subject: [Chirb] BARcamp organizer meeting tonight
In-Reply-To: <48528AFF.2090905@hostedlabs.com>
References: <484DA4DD.4060403@hostedlabs.com>
	<620ca2c40806091521p18d6e460r8f7c1b1186ac3380@mail.gmail.com>
	<48528AFF.2090905@hostedlabs.com>
Message-ID: <71a71480806130905t4cbdd59fw842724dc5616d6c9@mail.gmail.com>

Hey all,
I just thought I'd drop a line to say hi and that I'll be in the Chicago
area 8/6 - 8/12 and would love to attend any events going on during that
time.  I lived in Chicago for 10 years when I worked at Motorola and I now
live in Orlando, FL and have been doing web development full time for about
1.5 years and coding RoR for about 15 months.

Anyway, I'm interested in meeting more RoRers and expanding my knowledge and
networking group.

Greg

On Fri, Jun 13, 2008 at 10:58 AM, Jason Rexilius <jason at hostedlabs.com>
wrote:

> Is anyone going to make it?
>
> I should probably try and reserve a table if possible for n people...
>
> Organizer kick-off meeting
>
> Friday, June 13th @ 18:30
> Rock Bottom Brewery (dont like it but its close to Red Line).
>
> -jason
> 847.208.1000
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>



-- 
Greg Pederson
Founder and Technical Director

Nsight Development, LLC.
www.NsightDevelopment.com

Greg at NsightDevelopment.com
407-641-0327

Quis custodiet ipsos custodes

Greg.Pederson at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080613/fbe08afe/attachment.html>

From joshua.mcadams at gmail.com  Fri Jun 13 22:37:26 2008
From: joshua.mcadams at gmail.com (Joshua McAdams)
Date: Fri, 13 Jun 2008 21:37:26 -0500
Subject: [Chirb] Perl Conference In Chicago
Message-ID: <49d805d70806131937h53caea88o2fda5ef9c55e06c4@mail.gmail.com>

Hi Ruby Folks,

I was just sending a note to remind you all that YAPC::NA (the Perl
Conference) is being held in Chicago again.... next week!  We have
some hack-a-thons going on now, a few social outings, and of course
the conference happening next week.  If you are interested, please
check out the website at http://yapc.org/America or send me a note for
more information.

Hope to see a few of you there,
Josh McAdams

From natebkirby at yahoo.com  Thu Jun 19 19:14:03 2008
From: natebkirby at yahoo.com (Nate Kirby)
Date: Thu, 19 Jun 2008 18:14:03 -0500
Subject: [Chirb] tools, already in play and coming soon
In-Reply-To: <2f1a1dcb0806121829g76587d50lf6aba4e495b7a8e5@mail.gmail.com>
References: <9F8A0414-5152-4E38-8068-719E2D4042C9@gmail.com>	<56E43D91-0EA7-44AA-8982-60C7593E6F3B@gmail.com>	<2f1a1dcb0806110637t259fc04dtcc2170a7fa233fa7@mail.gmail.com>	<215638340806110726o15cd8ecav3c54868c6a401d7c@mail.gmail.com>	<A97BCD24-4AB5-439F-9BD9-7402541B7D32@gmail.com>	<215638340806121723m976e915pc743a223eb4648f3@mail.gmail.com>
	<2f1a1dcb0806121829g76587d50lf6aba4e495b7a8e5@mail.gmail.com>
Message-ID: <485AE83B.90401@yahoo.com>

Jake,

Did this blogging ever take place?  I am also quite interested. 

Does UnitRecord play nice with Story Runner?

Blessings,
Nate

Ryan Platte wrote:
> Go for it, Jake. I'm interested to see what you'll write.
>
> On Thu, Jun 12, 2008 at 7:23 PM, Jake Scruggs <jake.scruggs at gmail.com 
> <mailto:jake.scruggs at gmail.com>> wrote:
>
>     I haven't had any problems with NullDB, but failing silently is
>     its thing (Null Object Pattern and all) so be careful.  I think
>     the tagging bit you describe as coming soon to RSpec is pretty cool.
>
>     I'm probably going to blog about this soon and will quote some
>     things from Ryan and David's responses -- unless of course either
>     of you object.
>     -Jake
>
>
>     On Wed, Jun 11, 2008 at 10:08 AM, David Chelimsky
>     <dchelimsky at gmail.com <mailto:dchelimsky at gmail.com>> wrote:
>
>         Hey Jake - thanks for sharing this. Couple o' comments below:
>
>         On Jun 11, 2008, at 9:26 AM, Jake Scruggs wrote:
>>         I've been using the NullDb
>>         (http://agilewebdevelopment.com/plugins/nulldb) plugin to
>>         disconnect RSpec from the database.
>
>         The only drawback I've heard about NullDb is that it fails
>         silently in certain cases - has led to some painful debugging.
>         Have you had that experience?
>
>>         I don't like the global disconnect (for all specs everywhere)
>>         that the web page suggests, so I set up this in my spec_helper:
>>
>>         describe "Unit Spec", :shared => true do
>>           before :all do
>>             ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>>           end
>>
>>           after :all do
>>             ActiveRecord::Base.establish_connection(:test)
>>           end
>>         end
>>
>>         and then say this inside any describe block I want to
>>         disconnect from the db:
>>
>>         require File.dirname(__FILE__) + "/../spec_helper"
>>
>>         describe User do
>>           it_should_behave_like "Unit Spec"
>
>         This is cool that it works, but using it_should_behave_like
>         feels odd to me in this case. The User should not behave like
>         a Unit Spec, the examples should be disconnected.
>
>         You can do this instead if you like:
>
>         share_as :Disconnected do
>
>           before :all do
>             ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>           end
>
>           after :all do
>             ActiveRecord::Base.establish_connection(:test)
>           end
>         end
>
>         describe User do
>           include Disconnected
>         ...
>
>         Right now we don't have an arbitrary tagging mechanism but
>         it's something we've talked about. This gives me an idea that
>         I'd like to implement, and everything is pretty much in place
>         to support this, where the options hash is available to you in
>         the before and after blocks, so you could do this (CAREFUL -
>         THIS DOES NOT WORK TODAY):
>
>         Spec::Runner.configure do |config|
>           config.before(:all)
>             if example_group_options[:disconnected]
>               ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>             end
>           end
>           config.after(:all)
>             if example_group_options[:disconnected]
>               ActiveRecord::Base.establish_connection(:test)
>             end
>           end
>         end
>
>         Then you'd be able to say:
>
>         describe User, :disconnected => true do
>           ...
>
>         WDYT about that?
>
>         Cheers,
>         David
>
>
>
>>
>>         .
>>         .
>>         .
>>
>>         using nested describes to separate my unit (don't hit the db)
>>         from my functional (do hit the db) specs
>>
>>         -Jake
>>
>>         On Wed, Jun 11, 2008 at 8:37 AM, Ryan Platte
>>         <ryan at platte.name <mailto:ryan at platte.name>> wrote:
>>
>>             Here are some Rake tasks I created to use RSpec with
>>             UnitRecord. I set the default task to first run
>>             spec:fast, then spec:slow, so if the fast ones fail we
>>             don't have to wait on the slow ones to set up and run.
>>
>>             The fly in the ointment is that schema.rb has to be current.
>>
>>             namespace :spec do
>>
>>               desc "Run all fast specs in spec directory (excluding
>>             plugin specs)"
>>               Spec::Rake::SpecTask.new(:fast) do |t|
>>                 t.spec_opts = ['--options',
>>             "\"#{RAILS_ROOT}/spec/spec.opts\""]
>>                 t.spec_files = FileList['spec/**/*_fast_spec.rb']
>>                 #t.ruby_opts = ['-r spec/spec_helper', '-rubygems',
>>             '-runit_record', "-e 'ActiveRecord::Base.disconnect!'"]
>>               end
>>
>>               desc "Run all non-fast specs in spec directory
>>             (excluding plugin specs)"
>>               Spec::Rake::SpecTask.new(:slow => spec_prereq) do |t|
>>                 t.spec_opts = ['--options',
>>             "\"#{RAILS_ROOT}/spec/spec.opts\""]
>>                 t.spec_files =
>>             FileList['spec/**/*_spec.rb'].exclude('spec/**/*_fast_spec.rb')
>>               end
>>
>>             end
>>
>>
>>             On Wed, Jun 11, 2008 at 1:36 AM, David Chelimsky
>>             <dchelimsky at gmail.com <mailto:dchelimsky at gmail.com>> wrote:
>>
>>                 On Jun 9, 2008, at 11:31 PM, David Chelimsky wrote:
>>
>>                     Hey Chirb,
>>
>>
>>                     Lastly, I may have mis-spoke about rails loading
>>                     up columns from schema.rb - I'm looking into it
>>                     and will follow up when I learn the truth. So
>>                     Ryan - keep using unit-record for now :)
>>
>>
>>                 I definitely mis-spoke. I don't know where I got that
>>                 in my head, but it seems I did.
>>
>>                 I don't recall who said it, but unit_record does the
>>                 column caching I thought rails did. So now it's off
>>                 to figure out how to get rspec to play nice w/
>>                 unit_record.
>>
>>                 More soon.
>>
>>
>>                 Cheers,
>>                 David
>>                 _______________________________________________
>>                 ChicagoGroup-Members-List at rubyforge.org
>>                 <mailto:ChicagoGroup-Members-List at rubyforge.org>
>>                 http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>
>>
>>
>>
>>             -- 
>>             Ryan Platte
>>             _______________________________________________
>>             ChicagoGroup-Members-List at rubyforge.org
>>             <mailto:ChicagoGroup-Members-List at rubyforge.org>
>>             http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>
>>
>>         _______________________________________________
>>         ChicagoGroup-Members-List at rubyforge.org
>>         <mailto:ChicagoGroup-Members-List at rubyforge.org>
>>         http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
>
>         _______________________________________________
>         ChicagoGroup-Members-List at rubyforge.org
>         <mailto:ChicagoGroup-Members-List at rubyforge.org>
>         http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
>
>
>     _______________________________________________
>     ChicagoGroup-Members-List at rubyforge.org
>     <mailto:ChicagoGroup-Members-List at rubyforge.org>
>     http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
>
>
>
> -- 
> Ryan Platte
> ------------------------------------------------------------------------
>
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080619/126f9e59/attachment-0001.html>

From jake.scruggs at gmail.com  Thu Jun 19 23:36:21 2008
From: jake.scruggs at gmail.com (Jake Scruggs)
Date: Thu, 19 Jun 2008 22:36:21 -0500
Subject: [Chirb] tools, already in play and coming soon
In-Reply-To: <485AE83B.90401@yahoo.com>
References: <9F8A0414-5152-4E38-8068-719E2D4042C9@gmail.com>
	<56E43D91-0EA7-44AA-8982-60C7593E6F3B@gmail.com>
	<2f1a1dcb0806110637t259fc04dtcc2170a7fa233fa7@mail.gmail.com>
	<215638340806110726o15cd8ecav3c54868c6a401d7c@mail.gmail.com>
	<A97BCD24-4AB5-439F-9BD9-7402541B7D32@gmail.com>
	<215638340806121723m976e915pc743a223eb4648f3@mail.gmail.com>
	<2f1a1dcb0806121829g76587d50lf6aba4e495b7a8e5@mail.gmail.com>
	<485AE83B.90401@yahoo.com>
Message-ID: <215638340806192036t1e581a42h2826b2e2de8552f3@mail.gmail.com>

yep, at
http://jakescruggs.blogspot.com/2008/06/disconnecting-rspec-from-database.html

I mostly just talk about my experiences with NullDB and call out Ryan to
talk about UnitRecord.
-Jake

On Thu, Jun 19, 2008 at 6:14 PM, Nate Kirby <natebkirby at yahoo.com> wrote:

>  Jake,
>
> Did this blogging ever take place?  I am also quite interested.
>
> Does UnitRecord play nice with Story Runner?
>
> Blessings,
> Nate
>
> Ryan Platte wrote:
>
> Go for it, Jake. I'm interested to see what you'll write.
>
> On Thu, Jun 12, 2008 at 7:23 PM, Jake Scruggs <jake.scruggs at gmail.com>
> wrote:
>
>> I haven't had any problems with NullDB, but failing silently is its thing
>> (Null Object Pattern and all) so be careful.  I think the tagging bit you
>> describe as coming soon to RSpec is pretty cool.
>>
>> I'm probably going to blog about this soon and will quote some things from
>> Ryan and David's responses -- unless of course either of you object.
>> -Jake
>>
>> On Wed, Jun 11, 2008 at 10:08 AM, David Chelimsky <dchelimsky at gmail.com>
>> wrote:
>>
>>>  Hey Jake - thanks for sharing this. Couple o' comments below:
>>> On Jun 11, 2008, at 9:26 AM, Jake Scruggs wrote:
>>>
>>> I've been using the NullDb (
>>> http://agilewebdevelopment.com/plugins/nulldb) plugin to disconnect
>>> RSpec from the database.
>>>
>>>
>>>  The only drawback I've heard about NullDb is that it fails silently in
>>> certain cases - has led to some painful debugging. Have you had that
>>> experience?
>>>
>>> I don't like the global disconnect (for all specs everywhere) that the
>>> web page suggests, so I set up this in my spec_helper:
>>>
>>> describe "Unit Spec", :shared => true do
>>>   before :all do
>>>     ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>>>   end
>>>
>>>   after :all do
>>>     ActiveRecord::Base.establish_connection(:test)
>>>   end
>>> end
>>>
>>> and then say this inside any describe block I want to disconnect from the
>>> db:
>>>
>>> require File.dirname(__FILE__) + "/../spec_helper"
>>>
>>> describe User do
>>>   it_should_behave_like "Unit Spec"
>>>
>>>
>>>  This is cool that it works, but using it_should_behave_like feels odd
>>> to me in this case. The User should not behave like a Unit Spec, the
>>> examples should be disconnected.
>>>
>>>  You can do this instead if you like:
>>>
>>>  share_as :Disconnected do
>>>   before :all do
>>>     ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>>>   end
>>>
>>>   after :all do
>>>     ActiveRecord::Base.establish_connection(:test)
>>>   end
>>> end
>>>
>>>  describe User do
>>>   include Disconnected
>>> ...
>>>
>>>  Right now we don't have an arbitrary tagging mechanism but it's
>>> something we've talked about. This gives me an idea that I'd like to
>>> implement, and everything is pretty much in place to support this, where the
>>> options hash is available to you in the before and after blocks, so you
>>> could do this (CAREFUL - THIS DOES NOT WORK TODAY):
>>>
>>>  Spec::Runner.configure do |config|
>>>   config.before(:all)
>>>     if example_group_options[:disconnected]
>>>        ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>>>     end
>>>    end
>>>    config.after(:all)
>>>     if example_group_options[:disconnected]
>>>        ActiveRecord::Base.establish_connection(:test)
>>>     end
>>>   end
>>>  end
>>>
>>>  Then you'd be able to say:
>>>
>>>  describe User, :disconnected => true do
>>>   ...
>>>
>>>  WDYT about that?
>>>
>>>  Cheers,
>>> David
>>>
>>>
>>>
>>>
>>> .
>>> .
>>> .
>>>
>>> using nested describes to separate my unit (don't hit the db) from my
>>> functional (do hit the db) specs
>>>
>>> -Jake
>>>
>>> On Wed, Jun 11, 2008 at 8:37 AM, Ryan Platte <ryan at platte.name> wrote:
>>>
>>>> Here are some Rake tasks I created to use RSpec with UnitRecord. I set
>>>> the default task to first run spec:fast, then spec:slow, so if the fast ones
>>>> fail we don't have to wait on the slow ones to set up and run.
>>>>
>>>>  The fly in the ointment is that schema.rb has to be current.
>>>>
>>>>  namespace :spec do
>>>>
>>>>    desc "Run all fast specs in spec directory (excluding plugin specs)"
>>>>   Spec::Rake::SpecTask.new(:fast) do |t|
>>>>     t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
>>>>     t.spec_files = FileList['spec/**/*_fast_spec.rb']
>>>>     #t.ruby_opts = ['-r spec/spec_helper', '-rubygems', '-runit_record',
>>>> "-e 'ActiveRecord::Base.disconnect!'"]
>>>>   end
>>>>
>>>>    desc "Run all non-fast specs in spec directory (excluding plugin
>>>> specs)"
>>>>   Spec::Rake::SpecTask.new(:slow => spec_prereq) do |t|
>>>>     t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
>>>>     t.spec_files =
>>>> FileList['spec/**/*_spec.rb'].exclude('spec/**/*_fast_spec.rb')
>>>>   end
>>>>
>>>>  end
>>>>
>>>>
>>>> On Wed, Jun 11, 2008 at 1:36 AM, David Chelimsky <dchelimsky at gmail.com>
>>>> wrote:
>>>>
>>>>> On Jun 9, 2008, at 11:31 PM, David Chelimsky wrote:
>>>>>
>>>>>  Hey Chirb,
>>>>>>
>>>>>> Lastly, I may have mis-spoke about rails loading up columns from
>>>>>> schema.rb - I'm looking into it and will follow up when I learn the truth.
>>>>>> So Ryan - keep using unit-record for now :)
>>>>>>
>>>>>
>>>>> I definitely mis-spoke. I don't know where I got that in my head, but
>>>>> it seems I did.
>>>>>
>>>>> I don't recall who said it, but unit_record does the column caching I
>>>>> thought rails did. So now it's off to figure out how to get rspec to play
>>>>> nice w/ unit_record.
>>>>>
>>>>> More soon.
>>>>>
>>>>> Cheers,
>>>>> David
>>>>> _______________________________________________
>>>>> ChicagoGroup-Members-List at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>>>>
>>>>
>>>>
>>>>
>>>>  --
>>>> Ryan Platte
>>>> _______________________________________________
>>>> ChicagoGroup-Members-List at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>>>
>>>
>>> _______________________________________________
>>> ChicagoGroup-Members-List at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>>
>>>
>>>
>>> _______________________________________________
>>> ChicagoGroup-Members-List at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>>
>>
>>
>> _______________________________________________
>> ChicagoGroup-Members-List at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>
>
>
>
> --
> Ryan Platte
>
> ------------------------------
>
> _______________________________________________ChicagoGroup-Members-List at rubyforge.orghttp://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
>
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080619/a60438b7/attachment.html>

From ryan.platte at gmail.com  Fri Jun 20 08:49:13 2008
From: ryan.platte at gmail.com (Ryan Platte)
Date: Fri, 20 Jun 2008 07:49:13 -0500
Subject: [Chirb] tools, already in play and coming soon
In-Reply-To: <215638340806192036t1e581a42h2826b2e2de8552f3@mail.gmail.com>
References: <9F8A0414-5152-4E38-8068-719E2D4042C9@gmail.com>
	<56E43D91-0EA7-44AA-8982-60C7593E6F3B@gmail.com>
	<2f1a1dcb0806110637t259fc04dtcc2170a7fa233fa7@mail.gmail.com>
	<215638340806110726o15cd8ecav3c54868c6a401d7c@mail.gmail.com>
	<A97BCD24-4AB5-439F-9BD9-7402541B7D32@gmail.com>
	<215638340806121723m976e915pc743a223eb4648f3@mail.gmail.com>
	<2f1a1dcb0806121829g76587d50lf6aba4e495b7a8e5@mail.gmail.com>
	<485AE83B.90401@yahoo.com>
	<215638340806192036t1e581a42h2826b2e2de8552f3@mail.gmail.com>
Message-ID: <AE021326-166E-4BA5-85BD-02C15B012AA8@gmail.com>

I'm sorry to keep everybody on pins and needles, I simply don't have  
leisure time to work up a blog post on this right now, and I'm not  
sure when I will. Apologies to all.

On Jun 19, 2008, at 10:36 PM, Jake Scruggs wrote:

> yep, at
> http://jakescruggs.blogspot.com/2008/06/disconnecting-rspec-from- 
> database.html
>
> I mostly just talk about my experiences with NullDB and call out  
> Ryan to talk about UnitRecord.
> -Jake
>
> On Thu, Jun 19, 2008 at 6:14 PM, Nate Kirby <natebkirby at yahoo.com>  
> wrote:
> Jake,
>
> Did this blogging ever take place?  I am also quite interested.
>
> Does UnitRecord play nice with Story Runner?
>
> Blessings,
> Nate
>
> Ryan Platte wrote:
>>
>> Go for it, Jake. I'm interested to see what you'll write.
>>
>> On Thu, Jun 12, 2008 at 7:23 PM, Jake Scruggs  
>> <jake.scruggs at gmail.com> wrote:
>> I haven't had any problems with NullDB, but failing silently is  
>> its thing (Null Object Pattern and all) so be careful.  I think  
>> the tagging bit you describe as coming soon to RSpec is pretty cool.
>>
>> I'm probably going to blog about this soon and will quote some  
>> things from Ryan and David's responses -- unless of course either  
>> of you object.
>> -Jake
>>
>>
>> On Wed, Jun 11, 2008 at 10:08 AM, David Chelimsky  
>> <dchelimsky at gmail.com> wrote:
>> Hey Jake - thanks for sharing this. Couple o' comments below:
>>
>> On Jun 11, 2008, at 9:26 AM, Jake Scruggs wrote:
>>> I've been using the NullDb (http://agilewebdevelopment.com/ 
>>> plugins/nulldb) plugin to disconnect RSpec from the database.
>>
>> The only drawback I've heard about NullDb is that it fails  
>> silently in certain cases - has led to some painful debugging.  
>> Have you had that experience?
>>
>>> I don't like the global disconnect (for all specs everywhere)  
>>> that the web page suggests, so I set up this in my spec_helper:
>>>
>>> describe "Unit Spec", :shared => true do
>>>   before :all do
>>>     ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>>>   end
>>>
>>>   after :all do
>>>     ActiveRecord::Base.establish_connection(:test)
>>>   end
>>> end
>>>
>>> and then say this inside any describe block I want to disconnect  
>>> from the db:
>>>
>>> require File.dirname(__FILE__) + "/../spec_helper"
>>>
>>> describe User do
>>>   it_should_behave_like "Unit Spec"
>>
>> This is cool that it works, but using it_should_behave_like feels  
>> odd to me in this case. The User should not behave like a Unit  
>> Spec, the examples should be disconnected.
>>
>> You can do this instead if you like:
>>
>> share_as :Disconnected do
>>
>>   before :all do
>>     ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>>   end
>>
>>   after :all do
>>     ActiveRecord::Base.establish_connection(:test)
>>   end
>> end
>>
>> describe User do
>>   include Disconnected
>> ...
>>
>> Right now we don't have an arbitrary tagging mechanism but it's  
>> something we've talked about. This gives me an idea that I'd like  
>> to implement, and everything is pretty much in place to support  
>> this, where the options hash is available to you in the before and  
>> after blocks, so you could do this (CAREFUL - THIS DOES NOT WORK  
>> TODAY):
>>
>> Spec::Runner.configure do |config|
>>   config.before(:all)
>>     if example_group_options[:disconnected]
>>       ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>>     end
>>   end
>>   config.after(:all)
>>     if example_group_options[:disconnected]
>>       ActiveRecord::Base.establish_connection(:test)
>>     end
>>   end
>> end
>>
>> Then you'd be able to say:
>>
>> describe User, :disconnected => true do
>>   ...
>>
>> WDYT about that?
>>
>> Cheers,
>> David
>>
>>
>>
>>>
>>> .
>>> .
>>> .
>>>
>>> using nested describes to separate my unit (don't hit the db)  
>>> from my functional (do hit the db) specs
>>>
>>> -Jake
>>>
>>> On Wed, Jun 11, 2008 at 8:37 AM, Ryan Platte <ryan at platte.name>  
>>> wrote:
>>> Here are some Rake tasks I created to use RSpec with UnitRecord.  
>>> I set the default task to first run spec:fast, then spec:slow, so  
>>> if the fast ones fail we don't have to wait on the slow ones to  
>>> set up and run.
>>>
>>> The fly in the ointment is that schema.rb has to be current.
>>>
>>> namespace :spec do
>>>
>>>   desc "Run all fast specs in spec directory (excluding plugin  
>>> specs)"
>>>   Spec::Rake::SpecTask.new(:fast) do |t|
>>>     t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
>>>     t.spec_files = FileList['spec/**/*_fast_spec.rb']
>>>     #t.ruby_opts = ['-r spec/spec_helper', '-rubygems', '- 
>>> runit_record', "-e 'ActiveRecord::Base.disconnect!'"]
>>>   end
>>>
>>>   desc "Run all non-fast specs in spec directory (excluding  
>>> plugin specs)"
>>>   Spec::Rake::SpecTask.new(:slow => spec_prereq) do |t|
>>>     t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
>>>     t.spec_files = FileList['spec/**/*_spec.rb'].exclude('spec/**/ 
>>> *_fast_spec.rb')
>>>   end
>>>
>>> end
>>>
>>>
>>> On Wed, Jun 11, 2008 at 1:36 AM, David Chelimsky  
>>> <dchelimsky at gmail.com> wrote:
>>> On Jun 9, 2008, at 11:31 PM, David Chelimsky wrote:
>>>
>>> Hey Chirb,
>>>
>>>
>>> Lastly, I may have mis-spoke about rails loading up columns from  
>>> schema.rb - I'm looking into it and will follow up when I learn  
>>> the truth. So Ryan - keep using unit-record for now :)
>>>
>>> I definitely mis-spoke. I don't know where I got that in my head,  
>>> but it seems I did.
>>>
>>> I don't recall who said it, but unit_record does the column  
>>> caching I thought rails did. So now it's off to figure out how to  
>>> get rspec to play nice w/ unit_record.
>>>
>>> More soon.
>>>
>>>
>>> Cheers,
>>> David
>>> _______________________________________________
>>> ChicagoGroup-Members-List at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>>
>>>
>>>
>>> -- 
>>> Ryan Platte
>>> _______________________________________________
>>> ChicagoGroup-Members-List at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>>
>>> _______________________________________________
>>> ChicagoGroup-Members-List at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>
>>
>> _______________________________________________
>> ChicagoGroup-Members-List at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>
>>
>> _______________________________________________
>> ChicagoGroup-Members-List at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>
>>
>>
>> -- 
>> Ryan Platte
>> _______________________________________________
>> ChicagoGroup-Members-List at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080620/eb1feb20/attachment-0001.html>

From dchelimsky at gmail.com  Fri Jun 20 09:43:52 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 20 Jun 2008 08:43:52 -0500
Subject: [Chirb] tools, already in play and coming soon
In-Reply-To: <AE021326-166E-4BA5-85BD-02C15B012AA8@gmail.com>
References: <9F8A0414-5152-4E38-8068-719E2D4042C9@gmail.com>
	<56E43D91-0EA7-44AA-8982-60C7593E6F3B@gmail.com>
	<2f1a1dcb0806110637t259fc04dtcc2170a7fa233fa7@mail.gmail.com>
	<215638340806110726o15cd8ecav3c54868c6a401d7c@mail.gmail.com>
	<A97BCD24-4AB5-439F-9BD9-7402541B7D32@gmail.com>
	<215638340806121723m976e915pc743a223eb4648f3@mail.gmail.com>
	<2f1a1dcb0806121829g76587d50lf6aba4e495b7a8e5@mail.gmail.com>
	<485AE83B.90401@yahoo.com>
	<215638340806192036t1e581a42h2826b2e2de8552f3@mail.gmail.com>
	<AE021326-166E-4BA5-85BD-02C15B012AA8@gmail.com>
Message-ID: <EFB8E5A8-78B4-496C-BF0B-9D06B9F6B1E0@gmail.com>

Any chance you can give us the 5 line "here's what you do" in the mean  
time? We *are* on pins and needles.

On Jun 20, 2008, at 7:49 AM, Ryan Platte wrote:

> I'm sorry to keep everybody on pins and needles, I simply don't have  
> leisure time to work up a blog post on this right now, and I'm not  
> sure when I will. Apologies to all.
>
> On Jun 19, 2008, at 10:36 PM, Jake Scruggs wrote:
>> yep, at
>> http://jakescruggs.blogspot.com/2008/06/disconnecting-rspec-from-database.html
>>
>> I mostly just talk about my experiences with NullDB and call out  
>> Ryan to talk about UnitRecord.
>> -Jake
>>
>> On Thu, Jun 19, 2008 at 6:14 PM, Nate Kirby <natebkirby at yahoo.com>  
>> wrote:
>> Jake,
>>
>> Did this blogging ever take place?  I am also quite interested.
>>
>> Does UnitRecord play nice with Story Runner?
>>
>> Blessings,
>> Nate
>>
>> Ryan Platte wrote:
>>>
>>> Go for it, Jake. I'm interested to see what you'll write.
>>>
>>> On Thu, Jun 12, 2008 at 7:23 PM, Jake Scruggs <jake.scruggs at gmail.com 
>>> > wrote:
>>> I haven't had any problems with NullDB, but failing silently is  
>>> its thing (Null Object Pattern and all) so be careful.  I think  
>>> the tagging bit you describe as coming soon to RSpec is pretty cool.
>>>
>>> I'm probably going to blog about this soon and will quote some  
>>> things from Ryan and David's responses -- unless of course either  
>>> of you object.
>>> -Jake
>>>
>>>
>>> On Wed, Jun 11, 2008 at 10:08 AM, David Chelimsky <dchelimsky at gmail.com 
>>> > wrote:
>>> Hey Jake - thanks for sharing this. Couple o' comments below:
>>>
>>> On Jun 11, 2008, at 9:26 AM, Jake Scruggs wrote:
>>>> I've been using the NullDb (http://agilewebdevelopment.com/plugins/nulldb 
>>>> ) plugin to disconnect RSpec from the database.
>>>
>>> The only drawback I've heard about NullDb is that it fails  
>>> silently in certain cases - has led to some painful debugging.  
>>> Have you had that experience?
>>>
>>>> I don't like the global disconnect (for all specs everywhere)  
>>>> that the web page suggests, so I set up this in my spec_helper:
>>>>
>>>> describe "Unit Spec", :shared => true do
>>>>   before :all do
>>>>     ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>>>>   end
>>>>
>>>>   after :all do
>>>>     ActiveRecord::Base.establish_connection(:test)
>>>>   end
>>>> end
>>>>
>>>> and then say this inside any describe block I want to disconnect  
>>>> from the db:
>>>>
>>>> require File.dirname(__FILE__) + "/../spec_helper"
>>>>
>>>> describe User do
>>>>   it_should_behave_like "Unit Spec"
>>>
>>> This is cool that it works, but using it_should_behave_like feels  
>>> odd to me in this case. The User should not behave like a Unit  
>>> Spec, the examples should be disconnected.
>>>
>>> You can do this instead if you like:
>>>
>>> share_as :Disconnected do
>>>
>>>   before :all do
>>>     ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>>>   end
>>>
>>>   after :all do
>>>     ActiveRecord::Base.establish_connection(:test)
>>>   end
>>> end
>>>
>>> describe User do
>>>   include Disconnected
>>> ...
>>>
>>> Right now we don't have an arbitrary tagging mechanism but it's  
>>> something we've talked about. This gives me an idea that I'd like  
>>> to implement, and everything is pretty much in place to support  
>>> this, where the options hash is available to you in the before and  
>>> after blocks, so you could do this (CAREFUL - THIS DOES NOT WORK  
>>> TODAY):
>>>
>>> Spec::Runner.configure do |config|
>>>   config.before(:all)
>>>     if example_group_options[:disconnected]
>>>       ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>>>     end
>>>   end
>>>   config.after(:all)
>>>     if example_group_options[:disconnected]
>>>       ActiveRecord::Base.establish_connection(:test)
>>>     end
>>>   end
>>> end
>>>
>>> Then you'd be able to say:
>>>
>>> describe User, :disconnected => true do
>>>   ...
>>>
>>> WDYT about that?
>>>
>>> Cheers,
>>> David
>>>
>>>
>>>
>>>>
>>>> .
>>>> .
>>>> .
>>>>
>>>> using nested describes to separate my unit (don't hit the db)  
>>>> from my functional (do hit the db) specs
>>>>
>>>> -Jake
>>>>
>>>> On Wed, Jun 11, 2008 at 8:37 AM, Ryan Platte <ryan at platte.name>  
>>>> wrote:
>>>> Here are some Rake tasks I created to use RSpec with UnitRecord.  
>>>> I set the default task to first run spec:fast, then spec:slow, so  
>>>> if the fast ones fail we don't have to wait on the slow ones to  
>>>> set up and run.
>>>>
>>>> The fly in the ointment is that schema.rb has to be current.
>>>>
>>>> namespace :spec do
>>>>
>>>>   desc "Run all fast specs in spec directory (excluding plugin  
>>>> specs)"
>>>>   Spec::Rake::SpecTask.new(:fast) do |t|
>>>>     t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
>>>>     t.spec_files = FileList['spec/**/*_fast_spec.rb']
>>>>     #t.ruby_opts = ['-r spec/spec_helper', '-rubygems', '- 
>>>> runit_record', "-e 'ActiveRecord::Base.disconnect!'"]
>>>>   end
>>>>
>>>>   desc "Run all non-fast specs in spec directory (excluding  
>>>> plugin specs)"
>>>>   Spec::Rake::SpecTask.new(:slow => spec_prereq) do |t|
>>>>     t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
>>>>     t.spec_files = FileList['spec/**/*_spec.rb'].exclude('spec/**/ 
>>>> *_fast_spec.rb')
>>>>   end
>>>>
>>>> end
>>>>
>>>>
>>>> On Wed, Jun 11, 2008 at 1:36 AM, David Chelimsky <dchelimsky at gmail.com 
>>>> > wrote:
>>>> On Jun 9, 2008, at 11:31 PM, David Chelimsky wrote:
>>>>
>>>> Hey Chirb,
>>>>
>>>>
>>>> Lastly, I may have mis-spoke about rails loading up columns from  
>>>> schema.rb - I'm looking into it and will follow up when I learn  
>>>> the truth. So Ryan - keep using unit-record for now :)
>>>>
>>>> I definitely mis-spoke. I don't know where I got that in my head,  
>>>> but it seems I did.
>>>>
>>>> I don't recall who said it, but unit_record does the column  
>>>> caching I thought rails did. So now it's off to figure out how to  
>>>> get rspec to play nice w/ unit_record.
>>>>
>>>> More soon.
>>>>
>>>>
>>>> Cheers,
>>>> David
>>>> _______________________________________________
>>>> ChicagoGroup-Members-List at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>>>
>>>>
>>>>
>>>> -- 
>>>> Ryan Platte
>>>> _______________________________________________
>>>> ChicagoGroup-Members-List at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>>>
>>>> _______________________________________________
>>>> ChicagoGroup-Members-List at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>>
>>>
>>> _______________________________________________
>>> ChicagoGroup-Members-List at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>>
>>>
>>> _______________________________________________
>>> ChicagoGroup-Members-List at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>>
>>>
>>>
>>> -- 
>>> Ryan Platte
>>> _______________________________________________
>>> ChicagoGroup-Members-List at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>
>> _______________________________________________
>> ChicagoGroup-Members-List at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>
>> _______________________________________________
>> ChicagoGroup-Members-List at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080620/b3d1fd6c/attachment.html>

From dchelimsky at gmail.com  Mon Jun 23 15:53:45 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 23 Jun 2008 14:53:45 -0500
Subject: [Chirb] [JOB] Inventables
Message-ID: <ED7A9455-4594-4E32-B85B-80F74DD80DCE@gmail.com>

Hey all you Chirbers,

Inventables is a Chicago-based company that helps manufacturers in  
their product development process. I'm going to be working on a  
project with them for the foreseeable future, and they are looking to  
hire permanent staff as well. I'd highly recommend you give them a  
shout if you're in the market.

http://www.inventables.com/AboutUs/Leaddeveloper.asp

Cheers,
David

ps - yeah, I know - the current site is in ASP, but the next one is in  
Ruby :)

From ryan at platte.name  Wed Jun 25 09:12:47 2008
From: ryan at platte.name (Ryan Platte)
Date: Wed, 25 Jun 2008 08:12:47 -0500
Subject: [Chirb] Book discounts
Message-ID: <48C58437-B9D4-467A-8684-6C8813A804D9@platte.name>

Hi Chirbers,

The fine folks at Pearson invited us to join their user group  
program, and it was easy enough, so I did so.

You can register as a member with them and get 35% off the following  
imprints: Addison-Wesley Professional, Cisco Press, Exam Cram, IBM  
Press, Prentice Hall Professional, Que Publishing, and Sams Publishing.

You can visit them at http://www.informit.com/usergroupwelcome for  
details and personal registration, including the discount code.

We are also members of O'Reilly's program. Through that program you  
can request a review copy of tech books. Here's the blurb on that  
program, I last posted it in September, so why not mention it again:

> Get 35% off from O'Reilly, No Starch, Paraglyph, PC Publishing,  
> Pragmatic Bookshelf, Rocky Nook, SitePoint, or YoungJin books you  
> purchase directly from O'Reilly.
>
> Just use code "DSUG" when ordering online at http://www.oreilly.com/ 
> store/ or by phone 800-998-9938.
>
> Did you know you can request a free book or PDF to review for your  
> group? Ask your group leader for more information.

Hope this helps someone.

-- 
Ryan Platte
ryan at platte.name



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080625/a7b9bd35/attachment-0001.html>

From krishicks at gmail.com  Sat Jun 28 12:40:29 2008
From: krishicks at gmail.com (Kris Hicks)
Date: Sat, 28 Jun 2008 11:40:29 -0500
Subject: [Chirb] Meeting Proposal
Message-ID: <1e59c0ea0806280940x4a68ed65x4d4a298dcc6711a5@mail.gmail.com>

Hello,

I have a proposal for a Chirb meeting.

I'm using the Watir library (http://wtr.rubyforge.org/) as an automation
tool, packaging it as an executable and distributing as an internal
application at First American Title, where I work.  The executable is
created with Exerb (http://exerb.sourceforge.jp/index.en.html), and includes
a Ruby interpreter and open-uri.  Upon execution, the executable contacts a
webserver (running Nginx/Merb/Thin) and downloads any gems that are required
to run the actual application from a source on the webserver.  The user is
then presented with a list of what automation tasks they have available to
them, they choose one, it downloads the automation task as a Watir script,
and they're off to the races.

I've talked with a few people about it and there seems to be a fair amount
of interest in a) Exerb, b) Merb, c) the basic premise of distributing a
barebones executable (running Ruby, no less) which is then built up
dynamically to run the automation script, d) using Watir as a sort of
end-user application instead of just as a tool for regression testing.

I can go to some lengths discussing this in a variety of different ways.
How the application was built, how it was then made to scale (it used to be
a self-contained executable), Merb, Watir, subverting the IT department of a
Fortune 500 company.. the list really goes on and on.

Thanks,

Kris Hicks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080628/e886eeaa/attachment.html>

From stcorbett at gmail.com  Sat Jun 28 12:51:15 2008
From: stcorbett at gmail.com (Sean Corbett)
Date: Sat, 28 Jun 2008 11:51:15 -0500
Subject: [Chirb] Meeting Proposal
In-Reply-To: <1e59c0ea0806280940x4a68ed65x4d4a298dcc6711a5@mail.gmail.com>
References: <1e59c0ea0806280940x4a68ed65x4d4a298dcc6711a5@mail.gmail.com>
Message-ID: <b7391af90806280951m40666cb8h521f7da76f2887fc@mail.gmail.com>

+1 How the application was built
+1 how it was then made to scale (it used to be a self-contained executable)
+1 Merb
+1 Watir
+2 Subverting the IT department of a Fortune 500  (is +2 allowed?)

Sounds like it could be several presentations.  Anyone else with
Merb/Watir/Scaling experience who wants to add another talk and flesh things
out into several Chirb meetings?

-Sean Corbett

On Sat, Jun 28, 2008 at 11:40 AM, Kris Hicks <krishicks at gmail.com> wrote:

> Hello,
>
> I have a proposal for a Chirb meeting.
>
> I'm using the Watir library (http://wtr.rubyforge.org/) as an automation
> tool, packaging it as an executable and distributing as an internal
> application at First American Title, where I work.  The executable is
> created with Exerb (http://exerb.sourceforge.jp/index.en.html), and
> includes a Ruby interpreter and open-uri.  Upon execution, the executable
> contacts a webserver (running Nginx/Merb/Thin) and downloads any gems that
> are required to run the actual application from a source on the webserver.
> The user is then presented with a list of what automation tasks they have
> available to them, they choose one, it downloads the automation task as a
> Watir script, and they're off to the races.
>
> I've talked with a few people about it and there seems to be a fair amount
> of interest in a) Exerb, b) Merb, c) the basic premise of distributing a
> barebones executable (running Ruby, no less) which is then built up
> dynamically to run the automation script, d) using Watir as a sort of
> end-user application instead of just as a tool for regression testing.
>
> I can go to some lengths discussing this in a variety of different ways.
> How the application was built, how it was then made to scale (it used to be
> a self-contained executable), Merb, Watir, subverting the IT department of a
> Fortune 500 company.. the list really goes on and on.
>
> Thanks,
>
> Kris Hicks
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080628/9f24f6a3/attachment.html>

From dave at obtiva.com  Sat Jun 28 13:12:24 2008
From: dave at obtiva.com (Dave Hoover)
Date: Sat, 28 Jun 2008 12:12:24 -0500
Subject: [Chirb] Meeting Proposal
In-Reply-To: <b7391af90806280951m40666cb8h521f7da76f2887fc@mail.gmail.com>
References: <1e59c0ea0806280940x4a68ed65x4d4a298dcc6711a5@mail.gmail.com>
	<b7391af90806280951m40666cb8h521f7da76f2887fc@mail.gmail.com>
Message-ID: <11c8704e0806281012o7bfde8fw8eb2a8e58c7b8682@mail.gmail.com>

On Sat, Jun 28, 2008 at 11:51 AM, Sean Corbett <stcorbett at gmail.com> wrote:
> Sounds like it could be several presentations.  Anyone else with
> Merb/Watir/Scaling experience who wants to add another talk and flesh things
> out into several Chirb meetings?

I could piggyback/assist/riff on the Watir side of things and talk
about the state/implementation of the SafariWatir project, if that
interests anyone.

Dave Hoover
//obtiva: Agility applied. Software delivered.

From dchelimsky at gmail.com  Sat Jun 28 13:31:02 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sat, 28 Jun 2008 12:31:02 -0500
Subject: [Chirb] Meeting Proposal
In-Reply-To: <11c8704e0806281012o7bfde8fw8eb2a8e58c7b8682@mail.gmail.com>
References: <1e59c0ea0806280940x4a68ed65x4d4a298dcc6711a5@mail.gmail.com>
	<b7391af90806280951m40666cb8h521f7da76f2887fc@mail.gmail.com>
	<11c8704e0806281012o7bfde8fw8eb2a8e58c7b8682@mail.gmail.com>
Message-ID: <57c63afe0806281031id02a994j76286d5fba875eab@mail.gmail.com>

On Sat, Jun 28, 2008 at 12:12 PM, Dave Hoover <dave at obtiva.com> wrote:
> On Sat, Jun 28, 2008 at 11:51 AM, Sean Corbett <stcorbett at gmail.com> wrote:
>> Sounds like it could be several presentations.  Anyone else with
>> Merb/Watir/Scaling experience who wants to add another talk and flesh things
>> out into several Chirb meetings?
>
> I could piggyback/assist/riff on the Watir side of things and talk
> about the state/implementation of the SafariWatir project, if that
> interests anyone.

I'd be interested in that as well.

From ryan.platte at gmail.com  Fri Jun 20 08:49:13 2008
From: ryan.platte at gmail.com (Ryan Platte)
Date: Fri, 20 Jun 2008 07:49:13 -0500
Subject: [Chirb] tools, already in play and coming soon
In-Reply-To: <215638340806192036t1e581a42h2826b2e2de8552f3@mail.gmail.com>
References: <9F8A0414-5152-4E38-8068-719E2D4042C9@gmail.com>
	<56E43D91-0EA7-44AA-8982-60C7593E6F3B@gmail.com>
	<2f1a1dcb0806110637t259fc04dtcc2170a7fa233fa7@mail.gmail.com>
	<215638340806110726o15cd8ecav3c54868c6a401d7c@mail.gmail.com>
	<A97BCD24-4AB5-439F-9BD9-7402541B7D32@gmail.com>
	<215638340806121723m976e915pc743a223eb4648f3@mail.gmail.com>
	<2f1a1dcb0806121829g76587d50lf6aba4e495b7a8e5@mail.gmail.com>
	<485AE83B.90401@yahoo.com>
	<215638340806192036t1e581a42h2826b2e2de8552f3@mail.gmail.com>
Message-ID: <AE021326-166E-4BA5-85BD-02C15B012AA8@gmail.com>

I'm sorry to keep everybody on pins and needles, I simply don't have  
leisure time to work up a blog post on this right now, and I'm not  
sure when I will. Apologies to all.

On Jun 19, 2008, at 10:36 PM, Jake Scruggs wrote:

> yep, at
> http://jakescruggs.blogspot.com/2008/06/disconnecting-rspec-from- 
> database.html
>
> I mostly just talk about my experiences with NullDB and call out  
> Ryan to talk about UnitRecord.
> -Jake
>
> On Thu, Jun 19, 2008 at 6:14 PM, Nate Kirby <natebkirby at yahoo.com>  
> wrote:
> Jake,
>
> Did this blogging ever take place?  I am also quite interested.
>
> Does UnitRecord play nice with Story Runner?
>
> Blessings,
> Nate
>
> Ryan Platte wrote:
>>
>> Go for it, Jake. I'm interested to see what you'll write.
>>
>> On Thu, Jun 12, 2008 at 7:23 PM, Jake Scruggs  
>> <jake.scruggs at gmail.com> wrote:
>> I haven't had any problems with NullDB, but failing silently is  
>> its thing (Null Object Pattern and all) so be careful.  I think  
>> the tagging bit you describe as coming soon to RSpec is pretty cool.
>>
>> I'm probably going to blog about this soon and will quote some  
>> things from Ryan and David's responses -- unless of course either  
>> of you object.
>> -Jake
>>
>>
>> On Wed, Jun 11, 2008 at 10:08 AM, David Chelimsky  
>> <dchelimsky at gmail.com> wrote:
>> Hey Jake - thanks for sharing this. Couple o' comments below:
>>
>> On Jun 11, 2008, at 9:26 AM, Jake Scruggs wrote:
>>> I've been using the NullDb (http://agilewebdevelopment.com/ 
>>> plugins/nulldb) plugin to disconnect RSpec from the database.
>>
>> The only drawback I've heard about NullDb is that it fails  
>> silently in certain cases - has led to some painful debugging.  
>> Have you had that experience?
>>
>>> I don't like the global disconnect (for all specs everywhere)  
>>> that the web page suggests, so I set up this in my spec_helper:
>>>
>>> describe "Unit Spec", :shared => true do
>>>   before :all do
>>>     ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>>>   end
>>>
>>>   after :all do
>>>     ActiveRecord::Base.establish_connection(:test)
>>>   end
>>> end
>>>
>>> and then say this inside any describe block I want to disconnect  
>>> from the db:
>>>
>>> require File.dirname(__FILE__) + "/../spec_helper"
>>>
>>> describe User do
>>>   it_should_behave_like "Unit Spec"
>>
>> This is cool that it works, but using it_should_behave_like feels  
>> odd to me in this case. The User should not behave like a Unit  
>> Spec, the examples should be disconnected.
>>
>> You can do this instead if you like:
>>
>> share_as :Disconnected do
>>
>>   before :all do
>>     ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>>   end
>>
>>   after :all do
>>     ActiveRecord::Base.establish_connection(:test)
>>   end
>> end
>>
>> describe User do
>>   include Disconnected
>> ...
>>
>> Right now we don't have an arbitrary tagging mechanism but it's  
>> something we've talked about. This gives me an idea that I'd like  
>> to implement, and everything is pretty much in place to support  
>> this, where the options hash is available to you in the before and  
>> after blocks, so you could do this (CAREFUL - THIS DOES NOT WORK  
>> TODAY):
>>
>> Spec::Runner.configure do |config|
>>   config.before(:all)
>>     if example_group_options[:disconnected]
>>       ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>>     end
>>   end
>>   config.after(:all)
>>     if example_group_options[:disconnected]
>>       ActiveRecord::Base.establish_connection(:test)
>>     end
>>   end
>> end
>>
>> Then you'd be able to say:
>>
>> describe User, :disconnected => true do
>>   ...
>>
>> WDYT about that?
>>
>> Cheers,
>> David
>>
>>
>>
>>>
>>> .
>>> .
>>> .
>>>
>>> using nested describes to separate my unit (don't hit the db)  
>>> from my functional (do hit the db) specs
>>>
>>> -Jake
>>>
>>> On Wed, Jun 11, 2008 at 8:37 AM, Ryan Platte <ryan at platte.name>  
>>> wrote:
>>> Here are some Rake tasks I created to use RSpec with UnitRecord.  
>>> I set the default task to first run spec:fast, then spec:slow, so  
>>> if the fast ones fail we don't have to wait on the slow ones to  
>>> set up and run.
>>>
>>> The fly in the ointment is that schema.rb has to be current.
>>>
>>> namespace :spec do
>>>
>>>   desc "Run all fast specs in spec directory (excluding plugin  
>>> specs)"
>>>   Spec::Rake::SpecTask.new(:fast) do |t|
>>>     t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
>>>     t.spec_files = FileList['spec/**/*_fast_spec.rb']
>>>     #t.ruby_opts = ['-r spec/spec_helper', '-rubygems', '- 
>>> runit_record', "-e 'ActiveRecord::Base.disconnect!'"]
>>>   end
>>>
>>>   desc "Run all non-fast specs in spec directory (excluding  
>>> plugin specs)"
>>>   Spec::Rake::SpecTask.new(:slow => spec_prereq) do |t|
>>>     t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
>>>     t.spec_files = FileList['spec/**/*_spec.rb'].exclude('spec/**/ 
>>> *_fast_spec.rb')
>>>   end
>>>
>>> end
>>>
>>>
>>> On Wed, Jun 11, 2008 at 1:36 AM, David Chelimsky  
>>> <dchelimsky at gmail.com> wrote:
>>> On Jun 9, 2008, at 11:31 PM, David Chelimsky wrote:
>>>
>>> Hey Chirb,
>>>
>>>
>>> Lastly, I may have mis-spoke about rails loading up columns from  
>>> schema.rb - I'm looking into it and will follow up when I learn  
>>> the truth. So Ryan - keep using unit-record for now :)
>>>
>>> I definitely mis-spoke. I don't know where I got that in my head,  
>>> but it seems I did.
>>>
>>> I don't recall who said it, but unit_record does the column  
>>> caching I thought rails did. So now it's off to figure out how to  
>>> get rspec to play nice w/ unit_record.
>>>
>>> More soon.
>>>
>>>
>>> Cheers,
>>> David
>>> _______________________________________________
>>> ChicagoGroup-Members-List at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>>
>>>
>>>
>>> -- 
>>> Ryan Platte
>>> _______________________________________________
>>> ChicagoGroup-Members-List at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>>
>>> _______________________________________________
>>> ChicagoGroup-Members-List at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>
>>
>> _______________________________________________
>> ChicagoGroup-Members-List at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>
>>
>> _______________________________________________
>> ChicagoGroup-Members-List at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>
>>
>>
>> -- 
>> Ryan Platte
>> _______________________________________________
>> ChicagoGroup-Members-List at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080620/eb1feb20/attachment-0003.html>

From natebkirby at yahoo.com  Sun Jun 29 21:36:58 2008
From: natebkirby at yahoo.com (Nate Kirby)
Date: Sun, 29 Jun 2008 20:36:58 -0500
Subject: [Chirb] Question...
In-Reply-To: <11c8704e0806281012o7bfde8fw8eb2a8e58c7b8682@mail.gmail.com>
References: <1e59c0ea0806280940x4a68ed65x4d4a298dcc6711a5@mail.gmail.com>	<b7391af90806280951m40666cb8h521f7da76f2887fc@mail.gmail.com>
	<11c8704e0806281012o7bfde8fw8eb2a8e58c7b8682@mail.gmail.com>
Message-ID: <486838BA.505@yahoo.com>

All,

I feel kind of like a ruby nubie saying this, but all of my work in ruby 
has been in rails.  I just got some work that does not require rails.  
When I work in rails, whenever metaprogramming is used to change the 
behavior of say String#length, it has gone in application.rb, so all 
those kinds of behavoir changes have been easy to locate.  However, now, 
when working without rails, these kinds of things go... well I assume 
there must be a ruby convention for this.  I have found 
http://rubygarden.org/ruby/page/show/RubyStyleGuide and 
http://blog.jayfields.com/2007/01/class-reopening-hints.html but am 
unsure that the real ruby convention for changing a previously defined 
classes' behavior is clear.

Does anyone out there know the right answer?  Where do class 
redefinitions go according to ruby conventions?

TIA,
Nate



From pgross at gmail.com  Mon Jun 30 08:10:43 2008
From: pgross at gmail.com (Paul Gross)
Date: Mon, 30 Jun 2008 07:10:43 -0500
Subject: [Chirb] Question...
In-Reply-To: <486838BA.505@yahoo.com>
References: <1e59c0ea0806280940x4a68ed65x4d4a298dcc6711a5@mail.gmail.com>	<b7391af90806280951m40666cb8h521f7da76f2887fc@mail.gmail.com>	<11c8704e0806281012o7bfde8fw8eb2a8e58c7b8682@mail.gmail.com>
	<486838BA.505@yahoo.com>
Message-ID: <4868CD43.5030805@gmail.com>

I'm not sure if it's the only convention, but on my projects at 
ThoughtWorks, we put all of our modifications into a folder called 
core_ext.  Each class modification gets one file, such as 
string_extension.rb, object_extension.rb, etc.  We create modules and 
include them on the original class (as mentioned in Jay's linked post).

Then, somewhere in the application, we have code to include them all like:

Dir.glob(File.expand_path('/some/path/to/core_ext/*')).each do |ext|
  require ext
end

For rails, we made this an initializer.

Thanks,
Paul Gross


Nate Kirby wrote:
> All,
>
> I feel kind of like a ruby nubie saying this, but all of my work in 
> ruby has been in rails.  I just got some work that does not require 
> rails.  When I work in rails, whenever metaprogramming is used to 
> change the behavior of say String#length, it has gone in 
> application.rb, so all those kinds of behavoir changes have been easy 
> to locate.  However, now, when working without rails, these kinds of 
> things go... well I assume there must be a ruby convention for this.  
> I have found http://rubygarden.org/ruby/page/show/RubyStyleGuide and 
> http://blog.jayfields.com/2007/01/class-reopening-hints.html but am 
> unsure that the real ruby convention for changing a previously defined 
> classes' behavior is clear.
>
> Does anyone out there know the right answer?  Where do class 
> redefinitions go according to ruby conventions?
>
> TIA,
> Nate
>
>
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list

From lfranklin at lumatila.com  Mon Jun 30 08:12:05 2008
From: lfranklin at lumatila.com (L. Franklin)
Date: Mon, 30 Jun 2008 07:12:05 -0500
Subject: [Chirb] Question...
In-Reply-To: <486838BA.505@yahoo.com>
References: <1e59c0ea0806280940x4a68ed65x4d4a298dcc6711a5@mail.gmail.com>	<b7391af90806280951m40666cb8h521f7da76f2887fc@mail.gmail.com><11c8704e0806281012o7bfde8fw8eb2a8e58c7b8682@mail.gmail.com>
	<486838BA.505@yahoo.com>
Message-ID: <45270174693B42D9942F6651BCB7929C@lukasswork>

Nate,

When you leave the comfortable confines of rails, you discover that ruby has
a wild-wild west side to it.  The only real convention that you see in Ruby
is that any code that you need to require/include in other code lives in a
/lib subdirectory on your project.  You will need to put in the appropriate
requires/includes to make sure your code pulls in your metaprogramming.  You
could store your metaprogramming and other includable routines elsewhere as
well; you just have to provide your requires an appropriate path to find
them.  Another possibility is to deploy your metaprogramming as a gem which
will slightly simplify the task of your code finding it.

Another alternative that I have adopted on several non-rails projects is to
go ahead and use the core components of rails anyway, stripping out AR and
other un-needed pieces.  This is a little easier to do with other frameworks
like merb which are more flexible about their components.  The benefit of
this is that you can still utilize the portions of rails/merb that are
convenient and take advantage of the huge library of plug-ins and deployment
tools.  I have taken this approach with several ruby applications that were
deployed as Windows executables using WxRuby as the GUI.  In that case I
still had a sqllite database managed by AR, but I stripped out all of the
web components.

We can chat more about this off-list about the specifics if you have more
questions.

Thanks!

Lukass

-----Original Message-----
From: Nate Kirby [mailto:natebkirby at yahoo.com] 
Sent: Sunday, June 29, 2008 8:37 PM
To: Chirb discussion list
Subject: [Chirb] Question...

All,

I feel kind of like a ruby nubie saying this, but all of my work in ruby 
has been in rails.  I just got some work that does not require rails.  
When I work in rails, whenever metaprogramming is used to change the 
behavior of say String#length, it has gone in application.rb, so all 
those kinds of behavoir changes have been easy to locate.  However, now, 
when working without rails, these kinds of things go... well I assume 
there must be a ruby convention for this.  I have found 
http://rubygarden.org/ruby/page/show/RubyStyleGuide and 
http://blog.jayfields.com/2007/01/class-reopening-hints.html but am 
unsure that the real ruby convention for changing a previously defined 
classes' behavior is clear.

Does anyone out there know the right answer?  Where do class 
redefinitions go according to ruby conventions?

TIA,
Nate


_______________________________________________
ChicagoGroup-Members-List at rubyforge.org
http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
No virus found in this incoming message.
Checked by AVG. 
Version: 8.0.101 / Virus Database: 270.4.3/1525 - Release Date: 6/29/2008
3:09 PM


From dave at obtiva.com  Mon Jun 30 08:55:05 2008
From: dave at obtiva.com (Dave Hoover)
Date: Mon, 30 Jun 2008 07:55:05 -0500
Subject: [Chirb] Question...
In-Reply-To: <4868CD43.5030805@gmail.com>
References: <1e59c0ea0806280940x4a68ed65x4d4a298dcc6711a5@mail.gmail.com>
	<b7391af90806280951m40666cb8h521f7da76f2887fc@mail.gmail.com>
	<11c8704e0806281012o7bfde8fw8eb2a8e58c7b8682@mail.gmail.com>
	<486838BA.505@yahoo.com> <4868CD43.5030805@gmail.com>
Message-ID: <11c8704e0806300555n5292a465mfad8f971e2043738@mail.gmail.com>

+1 on this convention, which is similar to how ActiveSupport is structured.
http://github.com/rails/rails/tree/master/activesupport/lib/active_support/core_ext


On Mon, Jun 30, 2008 at 7:10 AM, Paul Gross <pgross at gmail.com> wrote:
> I'm not sure if it's the only convention, but on my projects at
> ThoughtWorks, we put all of our modifications into a folder called core_ext.
>  Each class modification gets one file, such as string_extension.rb,
> object_extension.rb, etc.  We create modules and include them on the
> original class (as mentioned in Jay's linked post).
>
> Then, somewhere in the application, we have code to include them all like:
>
> Dir.glob(File.expand_path('/some/path/to/core_ext/*')).each do |ext|
>  require ext
> end
>
> For rails, we made this an initializer.
>
> Thanks,
> Paul Gross
>
>
> Nate Kirby wrote:
>>
>> All,
>>
>> I feel kind of like a ruby nubie saying this, but all of my work in ruby
>> has been in rails.  I just got some work that does not require rails.  When
>> I work in rails, whenever metaprogramming is used to change the behavior of
>> say String#length, it has gone in application.rb, so all those kinds of
>> behavoir changes have been easy to locate.  However, now, when working
>> without rails, these kinds of things go... well I assume there must be a
>> ruby convention for this.  I have found
>> http://rubygarden.org/ruby/page/show/RubyStyleGuide and
>> http://blog.jayfields.com/2007/01/class-reopening-hints.html but am unsure
>> that the real ruby convention for changing a previously defined classes'
>> behavior is clear.
>>
>> Does anyone out there know the right answer?  Where do class redefinitions
>> go according to ruby conventions?
>>
>> TIA,
>> Nate
>>
>>
>> _______________________________________________
>> ChicagoGroup-Members-List at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list

From jcroneme at thoughtworks.com  Mon Jun 30 11:20:27 2008
From: jcroneme at thoughtworks.com (Josh Cronemeyer)
Date: Mon, 30 Jun 2008 10:20:27 -0500
Subject: [Chirb] Meeting Proposal
In-Reply-To: <1e59c0ea0806280940x4a68ed65x4d4a298dcc6711a5@mail.gmail.com>
Message-ID: <OF1410D04F.8FF87866-ON86257478.0053D4A6-88257478.00544580@thoughtworks.com>

Kris,

Are you interested in giving your presentation at the July meeting?  If we 
play by the rules July 7th is our next meeting, but as it falls on the 
first day after a holiday weekend people might want to delay until July 
14.  So if you prefer that date we can make it happen.  If you weren't 
thinking July, let me know which month you want to schedule for and I'll 
put you on the calendar.

Josh Cronemeyer



"Kris Hicks" <krishicks at gmail.com> 
Sent by: chicagogroup-members-list-bounces at rubyforge.org
06/28/08 09:40 AM
Please respond to
Chirb discussion list <chicagogroup-members-list at rubyforge.org>


To
chicagogroup-members-list at rubyforge.org
cc

Subject
[Chirb] Meeting Proposal






Hello,

I have a proposal for a Chirb meeting.

I'm using the Watir library (http://wtr.rubyforge.org/) as an automation 
tool, packaging it as an executable and distributing as an internal 
application at First American Title, where I work.  The executable is 
created with Exerb (http://exerb.sourceforge.jp/index.en.html), and 
includes a Ruby interpreter and open-uri.  Upon execution, the executable 
contacts a webserver (running Nginx/Merb/Thin) and downloads any gems that 
are required to run the actual application from a source on the webserver. 
 The user is then presented with a list of what automation tasks they have 
available to them, they choose one, it downloads the automation task as a 
Watir script, and they're off to the races.

I've talked with a few people about it and there seems to be a fair amount 
of interest in a) Exerb, b) Merb, c) the basic premise of distributing a 
barebones executable (running Ruby, no less) which is then built up 
dynamically to run the automation script, d) using Watir as a sort of 
end-user application instead of just as a tool for regression testing.

I can go to some lengths discussing this in a variety of different ways. 
How the application was built, how it was then made to scale (it used to 
be a self-contained executable), Merb, Watir, subverting the IT department 
of a Fortune 500 company.. the list really goes on and on.

Thanks,

Kris Hicks _______________________________________________
ChicagoGroup-Members-List at rubyforge.org
http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080630/9f5ea8b0/attachment.html>

From krishicks at gmail.com  Mon Jun 30 11:43:15 2008
From: krishicks at gmail.com (Kris Hicks)
Date: Mon, 30 Jun 2008 10:43:15 -0500
Subject: [Chirb] Meeting Proposal
In-Reply-To: <OF1410D04F.8FF87866-ON86257478.0053D4A6-88257478.00544580@thoughtworks.com>
References: <1e59c0ea0806280940x4a68ed65x4d4a298dcc6711a5@mail.gmail.com>
	<OF1410D04F.8FF87866-ON86257478.0053D4A6-88257478.00544580@thoughtworks.com>
Message-ID: <1e59c0ea0806300843m1a1f9e23u9c912b5a1c9a81b1@mail.gmail.com>

Josh,

The 14th works for me.

The way I was thinking of doing it originally was to run through the why and
how of its creation, and then how it was scaled.  That would expose the
different pieces of it and how they were used, which could then be used to
figure out where people's interests lie for scheduling later meetings about
specific parts of it.

It's up to the group, really;  I just need to know how to organize my
slides.

Thanks,

Kris

On Mon, Jun 30, 2008 at 10:20 AM, Josh Cronemeyer <jcroneme at thoughtworks.com>
wrote:

>
> Kris,
>
> Are you interested in giving your presentation at the July meeting?  If we
> play by the rules July 7th is our next meeting, but as it falls on the first
> day after a holiday weekend people might want to delay until July 14.  So if
> you prefer that date we can make it happen.  If you weren't thinking July,
> let me know which month you want to schedule for and I'll put you on the
> calendar.
>
> Josh Cronemeyer
>
>
>  *"Kris Hicks" <krishicks at gmail.com>*
> Sent by: chicagogroup-members-list-bounces at rubyforge.org
>
> 06/28/08 09:40 AM
>  Please respond to
> Chirb discussion list <chicagogroup-members-list at rubyforge.org>
>
>   To
> chicagogroup-members-list at rubyforge.org  cc
>   Subject
> [Chirb] Meeting Proposal
>
>
>
>
> Hello,
>
> I have a proposal for a Chirb meeting.
>
> I'm using the Watir library (*http://wtr.rubyforge.org/*<http://wtr.rubyforge.org/>)
> as an automation tool, packaging it as an executable and distributing as an
> internal application at First American Title, where I work.  The executable
> is created with Exerb (*http://exerb.sourceforge.jp/index.en.html*<http://exerb.sourceforge.jp/index.en.html>),
> and includes a Ruby interpreter and open-uri.  Upon execution, the
> executable contacts a webserver (running Nginx/Merb/Thin) and downloads any
> gems that are required to run the actual application from a source on the
> webserver.  The user is then presented with a list of what automation tasks
> they have available to them, they choose one, it downloads the automation
> task as a Watir script, and they're off to the races.
>
> I've talked with a few people about it and there seems to be a fair amount
> of interest in a) Exerb, b) Merb, c) the basic premise of distributing a
> barebones executable (running Ruby, no less) which is then built up
> dynamically to run the automation script, d) using Watir as a sort of
> end-user application instead of just as a tool for regression testing.
>
> I can go to some lengths discussing this in a variety of different ways.
>  How the application was built, how it was then made to scale (it used to be
> a self-contained executable), Merb, Watir, subverting the IT department of a
> Fortune 500 company.. the list really goes on and on.
>
> Thanks,
>
>
> Kris Hicks _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080630/e4979023/attachment-0001.html>

From ryan at platte.name  Mon Jun 30 11:51:21 2008
From: ryan at platte.name (Ryan Platte)
Date: Mon, 30 Jun 2008 10:51:21 -0500
Subject: [Chirb] Meeting Proposal
In-Reply-To: <1e59c0ea0806300843m1a1f9e23u9c912b5a1c9a81b1@mail.gmail.com>
References: <1e59c0ea0806280940x4a68ed65x4d4a298dcc6711a5@mail.gmail.com>
	<OF1410D04F.8FF87866-ON86257478.0053D4A6-88257478.00544580@thoughtworks.com>
	<1e59c0ea0806300843m1a1f9e23u9c912b5a1c9a81b1@mail.gmail.com>
Message-ID: <2f1a1dcb0806300851t4c97032bi450fa1b3ed65e50f@mail.gmail.com>

If this turns into multiple sessions, let's please get some hands-on coding
into those sessions. If we're discussing Merb, I should have a start at a
Merb app at session's end, for example.

On Mon, Jun 30, 2008 at 10:43 AM, Kris Hicks <krishicks at gmail.com> wrote:

> Josh,
>
> The 14th works for me.
>
> The way I was thinking of doing it originally was to run through the why
> and how of its creation, and then how it was scaled.  That would expose the
> different pieces of it and how they were used, which could then be used to
> figure out where people's interests lie for scheduling later meetings about
> specific parts of it.
>
> It's up to the group, really;  I just need to know how to organize my
> slides.
>
> Thanks,
>
> Kris
>
>
> On Mon, Jun 30, 2008 at 10:20 AM, Josh Cronemeyer <
> jcroneme at thoughtworks.com> wrote:
>
>>
>> Kris,
>>
>> Are you interested in giving your presentation at the July meeting?  If we
>> play by the rules July 7th is our next meeting, but as it falls on the first
>> day after a holiday weekend people might want to delay until July 14.  So if
>> you prefer that date we can make it happen.  If you weren't thinking July,
>> let me know which month you want to schedule for and I'll put you on the
>> calendar.
>>
>> Josh Cronemeyer
>>
>>
>>  *"Kris Hicks" <krishicks at gmail.com>*
>> Sent by: chicagogroup-members-list-bounces at rubyforge.org
>>
>> 06/28/08 09:40 AM
>>  Please respond to
>> Chirb discussion list <chicagogroup-members-list at rubyforge.org>
>>
>>   To
>> chicagogroup-members-list at rubyforge.org  cc
>>   Subject
>> [Chirb] Meeting Proposal
>>
>>
>>
>>
>> Hello,
>>
>> I have a proposal for a Chirb meeting.
>>
>> I'm using the Watir library (*http://wtr.rubyforge.org/*<http://wtr.rubyforge.org/>)
>> as an automation tool, packaging it as an executable and distributing as an
>> internal application at First American Title, where I work.  The executable
>> is created with Exerb (*http://exerb.sourceforge.jp/index.en.html*<http://exerb.sourceforge.jp/index.en.html>),
>> and includes a Ruby interpreter and open-uri.  Upon execution, the
>> executable contacts a webserver (running Nginx/Merb/Thin) and downloads any
>> gems that are required to run the actual application from a source on the
>> webserver.  The user is then presented with a list of what automation tasks
>> they have available to them, they choose one, it downloads the automation
>> task as a Watir script, and they're off to the races.
>>
>> I've talked with a few people about it and there seems to be a fair amount
>> of interest in a) Exerb, b) Merb, c) the basic premise of distributing a
>> barebones executable (running Ruby, no less) which is then built up
>> dynamically to run the automation script, d) using Watir as a sort of
>> end-user application instead of just as a tool for regression testing.
>>
>> I can go to some lengths discussing this in a variety of different ways.
>>  How the application was built, how it was then made to scale (it used to be
>> a self-contained executable), Merb, Watir, subverting the IT department of a
>> Fortune 500 company.. the list really goes on and on.
>>
>> Thanks,
>>
>>
>> Kris Hicks _______________________________________________
>> ChicagoGroup-Members-List at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>
>> _______________________________________________
>> ChicagoGroup-Members-List at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>
>
>
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>



-- 
Ryan Platte
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080630/9ce95351/attachment.html>

From jcroneme at thoughtworks.com  Mon Jun 30 16:21:57 2008
From: jcroneme at thoughtworks.com (Josh Cronemeyer)
Date: Mon, 30 Jun 2008 15:21:57 -0500
Subject: [Chirb] Meeting Proposal
In-Reply-To: <1e59c0ea0806300843m1a1f9e23u9c912b5a1c9a81b1@mail.gmail.com>
Message-ID: <OF030E3804.D7420854-ON86257478.006F2BB9-88257478.006FDF98@thoughtworks.com>

Ok, an event has been placed on the calendar.  
http://www.chirb.org/event/show/30

The title of the talk is tentatively set as: Merb, Watir and subverting 
the IT department of a Fortune 500 company.. :) Kris, let me know if you 
want me to change the title or the description of the talk.  (I just 
grabbed all those words from your proposal email, so don't blame me). ;)

Josh Cronemeyer



"Kris Hicks" <krishicks at gmail.com> 
Sent by: chicagogroup-members-list-bounces at rubyforge.org
06/30/08 08:43 AM
Please respond to
Chirb discussion list <chicagogroup-members-list at rubyforge.org>


To
"Chirb discussion list" <chicagogroup-members-list at rubyforge.org>
cc

Subject
Re: [Chirb] Meeting Proposal






Josh,

The 14th works for me. 

The way I was thinking of doing it originally was to run through the why 
and how of its creation, and then how it was scaled.  That would expose 
the different pieces of it and how they were used, which could then be 
used to figure out where people's interests lie for scheduling later 
meetings about specific parts of it.

It's up to the group, really;  I just need to know how to organize my 
slides.

Thanks,

Kris

On Mon, Jun 30, 2008 at 10:20 AM, Josh Cronemeyer <
jcroneme at thoughtworks.com> wrote:

Kris, 

Are you interested in giving your presentation at the July meeting?  If we 
play by the rules July 7th is our next meeting, but as it falls on the 
first day after a holiday weekend people might want to delay until July 
14.  So if you prefer that date we can make it happen.  If you weren't 
thinking July, let me know which month you want to schedule for and I'll 
put you on the calendar. 

Josh Cronemeyer 


"Kris Hicks" <krishicks at gmail.com> 
Sent by: chicagogroup-members-list-bounces at rubyforge.org 
06/28/08 09:40 AM 


Please respond to
Chirb discussion list <chicagogroup-members-list at rubyforge.org>


To
chicagogroup-members-list at rubyforge.org 
cc

Subject
[Chirb] Meeting Proposal








Hello,

I have a proposal for a Chirb meeting.

I'm using the Watir library (http://wtr.rubyforge.org/) as an automation 
tool, packaging it as an executable and distributing as an internal 
application at First American Title, where I work.  The executable is 
created with Exerb (http://exerb.sourceforge.jp/index.en.html), and 
includes a Ruby interpreter and open-uri.  Upon execution, the executable 
contacts a webserver (running Nginx/Merb/Thin) and downloads any gems that 
are required to run the actual application from a source on the webserver. 
 The user is then presented with a list of what automation tasks they have 
available to them, they choose one, it downloads the automation task as a 
Watir script, and they're off to the races.

I've talked with a few people about it and there seems to be a fair amount 
of interest in a) Exerb, b) Merb, c) the basic premise of distributing a 
barebones executable (running Ruby, no less) which is then built up 
dynamically to run the automation script, d) using Watir as a sort of 
end-user application instead of just as a tool for regression testing.

I can go to some lengths discussing this in a variety of different ways. 
How the application was built, how it was then made to scale (it used to 
be a self-contained executable), Merb, Watir, subverting the IT department 
of a Fortune 500 company.. the list really goes on and on.

Thanks,


Kris Hicks _______________________________________________

ChicagoGroup-Members-List at rubyforge.org
http://rubyforge.org/mailman/listinfo/chicagogroup-members-list 

_______________________________________________
ChicagoGroup-Members-List at rubyforge.org
http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
_______________________________________________
ChicagoGroup-Members-List at rubyforge.org
http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080630/30a7dad6/attachment.html>

From krishicks at gmail.com  Mon Jun 30 17:08:16 2008
From: krishicks at gmail.com (Kris Hicks)
Date: Mon, 30 Jun 2008 16:08:16 -0500
Subject: [Chirb] Meeting Proposal
In-Reply-To: <OF030E3804.D7420854-ON86257478.006F2BB9-88257478.006FDF98@thoughtworks.com>
References: <1e59c0ea0806300843m1a1f9e23u9c912b5a1c9a81b1@mail.gmail.com>
	<OF030E3804.D7420854-ON86257478.006F2BB9-88257478.006FDF98@thoughtworks.com>
Message-ID: <1e59c0ea0806301408p2116c8bbk605f95c0437187e7@mail.gmail.com>

On Mon, Jun 30, 2008 at 3:21 PM, Josh Cronemeyer <jcroneme at thoughtworks.com>
wrote:

>
> Ok, an event has been placed on the calendar.
> http://www.chirb.org/event/show/30
>
> The title of the talk is tentatively set as: Merb, Watir and subverting the
> IT department of a Fortune 500 company.. :) Kris, let me know if you want me
> to change the title or the description of the talk.  (I just grabbed all
> those words from your proposal email, so don't blame me). ;)
>
> Josh Cronemeyer
>


Looks good to me.

Thanks,

Kris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080630/6b59a391/attachment-0001.html>