[Camps-users] Integration with related projects

[Jon Jensen]

On Tue, 9 Dec 2008, Ethan Rowe wrote:

> In Railsland at least, people are often fairly happy just developing on 
> a local instance on SQLite using webrick rather than a full Apache (or 
> other) web server; they don't try to solve the development environment 
> question beyond that, presumably because the apps are often small enough 
> that having absolutely consistency between production and development is 
> just not a pressing concern.
>
> For bigger apps with a long production history, or for complex apps 
> where you have significant amounts of logic across multiple tiers in the 
> stack, it seems like having something like camps is an obvious need and 
> I would think companies that have embraced Puppet in particular would 
> have an interest.

Yeah, there are lots of cases where the WEBrick local development model 
breaks down:

* when you need to have remote business users test your code

* if you have any intelligence in the web server at all

* if you use a caching reverse proxy -- whether using ESI or not, it still 
makes a difference and the caching strategy needs to be tested

* when you have a database of any size and complexity at all, and an empty 
schema with test fixture data loaded between each unit test just won't cut 
it

* when you don't want to waste time trying to track down problems caused 
by differences between the exact versions and builds of software on each 
developer's machine (that diversity is a strength when developing software 
for distribution, but only a liability when developing software to be 
hosted in your own monolithic environment)

> Ah, the language question.

Yes, that one. :)

> There are of course lighter-weight versions/derivatives of Moose that 
> may mitigate that cost.  However, that strikes me as fairly speculative 
> at the moment.

Coat has been around for over a year, actively maintained, so I don't 
think it's terribly speculative. And at least it's self-contained. But 
it'd still be nice to not have to worry about choosing an object system.

> The only major downside I see with moving to a language other than Perl, 
> other than my personal love for Perl of course, is the fact that it 
> means we cannot move incrementally.

That's true, though we can plug away on the existing codebase just fine 
until we're sure Whatever Comes Next is real. But the next big move 
probably won't be very incremental anyway, given the kinds of changes 
we've been considering.

Davor wrote:

> I've taken a look at Camps' Perl code, and also I've been working on 
> Ruby projects for the past few months, and the 'niceness' of Ruby code 
> compared to Perl is becoming more and more obvious to me. I've come to a 
> point where I'm preferring Ruby over Perl any time.

Ruby's nice, but I still like Perl a lot. But my main concern here is 
about Camps themselves, what they do, their interface, and their 
documentation. The actual implementation is less crucial, just as I don't 
much worry about how Git, PostgreSQL, bash, or many other things I 
regularly use are implemented, as long as they work well and are free 
software.

> Btw, we've been developing an application in Ruby 1.8, and hoping that 
> we'd be able to use Ruby 1.9 by the time the software is shipped 
> (problem were some library bindings not available in Ruby 1.9). Anyway, 
> long story short, we got it working on Ruby 1.9, and worth noting, 1.9 
> gives 4 to in some cases 20 times better performance over 1.8.

That's great news. Startup time for many Ruby tools really is noticeably 
and annoyingly slow, so if 1.9 improves that, hooray!

Jon