[Catalyst] RFC: The paradox of choice in web development

[Matt Pitts]

> -----Original Message-----
> From: Tomas Doran [mailto:bobtfish at bobtfish.net]
> Sent: Friday, February 20, 2009 4:08 AM
> To: The elegant MVC web framework
> Subject: Re: [Catalyst] RFC: The paradox of choice in web development
> 
> 
> On 19 Feb 2009, at 20:07, Matt Pitts wrote:
> 
> >> -----Original Message-----
> >> From: Dave Rolsky [mailto:autarch at urth.org]
> >> Sent: Thursday, February 19, 2009 2:21 PM
> >> To: The elegant MVC web framework
> >> Subject: RE: [Catalyst] RFC: The paradox of choice in web
> development
> >>
> >> On Thu, 19 Feb 2009, Matt Pitts wrote:
> >>
> >>> I myself am currently trying to support multiple developers
> (content
> >> &
> >>> perl) working on a Catalyst app from Windows desktops and it's
been
> > a
> <snip>
> >> Getting _way_ off-topic, but if your target environment is Linux,
> >> this
> >> is
> >> insane. VMWare is easy to set up and would let your Windows
> developer
> >> run
> >> the app in something much closer to its target environment.
> >
> > Thanks for the input...
> >
> > VMs were considered as an option, but since the Windows folks aren't
> > Linux-savvy, this means even more systems I have to maintain, perl
> > CPAN,
> > updates, etc.
> 
> Where are you finding perl programmers from who can't use ubuntu?

We're not, 2 of the devs are content guys who also work on M$ projects
(.NET). I don't expect them to learn Ubuntu nor do I want to further
confuse their day-to-day work effort by making them boot a VM and learn
basic Linux skills in order to work on this one client (yes, we only
have one Perl/Catalyst client right now). Maybe I'm being too nice.

The other dev (besides me) also works on M$ projects as a coder and has
become our Perl newbie - she volunteered to learn Perl/Catalyst and
become my backup. The Perl newbie is open to whatever method I want to
use for her to run the app, but the content devs would have a tough go
with VMs and I don't want to support more than one type of DEV
environment.

> Also, how does having people building software for a platform they're
> unfamiliar with work for you?

Because we're a small outfit and we're trying to stay lean due to the
current economy. Hiring any more full-up Perl devs is not an option.
Yes, it's a risk, but it's one we're probably just going to live with.

Besides, part of the appeal of Catalyst (and web frameworks in general)
is that they abstract away the low-level details, so for my perl newbie
I don't consider her role "Linux dev", I consider it "Perl/Catalyst
dev". Maybe that will change once she feels more comfortable with
Perl/Catalyst, but for now, she's helping to offload some of my work and
it makes a big difference. I actually have time to participate in the
mailing list now :-).

> > Not to mention the system resources used by the VM which
> > could be quite taxing on some of our developers' systems. For me,
> this
> > was the insane option.
> 
> I'm sorry, but if you're not prepared to buy your developers
> reasonable workstations then you've already lost - it doesn't take
> much effort to do a cost/benefit analysis and the cost of developing
> on a platform which (a) is causing you pain, and (b) is nothing like
> your production environment.

Agreed and if I really wanted to run VMs I'm confident that the $boss
would approve any performance upgrades necessary for users' machines. As
for (b), I have been very impressed with Catalyst's cross-platform
consistency. After 2 years of production (SLES10 on x86_64), I've never
once had a bug related to actual app code (not performance or server
config related) that I couldn't duplicate in DEV (either cgywin or
Ubuntu x86).
 
> This cost cannot be trivial even with the simple factors, and even
> higher once you factor less easy to analyze things such as the
> additional risk of your software having had less testing an the
> correct environment, and the staff motiviation as developing your
> application sounds painful.
> 
> How many days of lost time/work is the cost of a reasonable
> workstation? 2, 3? Less than a week certainly..
> 
> The highest cost to a knowledge based organisation is human
> resources, and so not providing your people the right kit to do their
> jobs effectively is just cutting your own throat.

Agreed. Agreed. Agreed.
 
> > In reality, two of the devs _are_ currently running the app on
> > Linux, in
> > their $HOME on a shared DEV server, and using Samba to access their
> > $HOME from windows. This setup has its own issues that I won't go
> > into.
> 
> Shared dev servers are fail to start with for a number of reasons -
> each developer needs their own environment they can mess up as they
> wish.
> 
> That aside, I don't see why there is any need to share a home
> directory between where you're developing and where your workstation
> is - all your code is in revision control, right? I suppose you'd
> want this if you used a graphical editor, but remote X works nicely
> in cygwin, so that could theoretically be a solution (other than the
> fact that having several people run a desktop environment on the same
> box is going to suck pretty quickly).

Because the content devs have a set of tools they like to use and are
most productive in - and they run in Windows.

> I'd recommend having a 'standard' development vmware rig which people
> can download, use, trash (and delete / get another one when they
> trash) isn't any more effort to setup than 1 new machine +
> development environment.

If I decide to go with VMs, this will likely be the route I take, but
I'd _prefer_ to just be able to run the app native in Windows - this
goes back to my original statements about Windows, Linux and Perl. It's
not a request, or a complaint; it's just a desire and if I get
determined enough I'll probably get it working one day.

> Keeping it up to date after that is again keeping 1 machine up to
date.
> 
> Don't worry about the individual workstations, they're disposable
> (and developers should be able to say sudo apt-get upgrade or
> equivalent).. Again, if you _can't_ get your development environment
> down to this level of isolation, then something is horribly, horribly
> wrong somewhere..
> 
> > Anyway, this is a long story, I'll stop ranting. My point was just
> > that
> > there is no easy way to "just run" the Cat app in Windows.
> 
> I do feel your pain, but I think that's down to the modules you're
> using in your application, rather than Catalyst itself (which as many
> people will attest, installs and runs fine on windows).

Agreed. The original point I was trying to make was just that Catalyst,
because of Perl and CPAN dependencies, is less likely to be adopted as a
platform by many companies because it's not as inherently easy to
install and run in Windows as it is in *nix platforms. It wasn't a
statement _against_ Perl or Catalyst is was _just_ a statement.

Thanks for your thoughts on this t0m.

v/r
-matt pitts