> -----Original Message----- > From: Tomas Doran [mailto:bobtf...@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:auta...@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 _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/