Re: On the scaleability of Perl Development Practices

Certainly each option is a good solution for a specific kind of situation, but how do we know *which* module works for *this* solution?

There does tend to be a huge variety of modules for every common task on CPAN, but I don't think that creates much of a problem in practice. If you ask for recommendations, or search for old ones, you're likely to find a small handful of commonly recommended modules for each common task.

It isn't like there are 196 advocates cheerleading for 196 different Config:: modules. I don't even think I can think of a half dozen config-related modules that I've seen people praise.

I would rather have the options than not have the options, but it would be great if we could get some good documentation together that would detail how to build a web application using DBIx::Class, mod_perl and Catalyst, vs using HTML::Mason, FastCGI and Rose::DB::Object (just contrived examples of options, nothing more).

You want a tutorial on how to "write a web application using <DB Abstraction Module>, <Templating System>, and <Runtime Backend>." There are likely a half dozen reasonable choices for the first two, and three or four choices for the backend.

I am not sure I understand why you need a tutorial explaining how to use three systems in concert when they are all so well isolated.

However scaling out means sharing Session and Application state. It means managing more than one server. It means you need to be capable of deploying updates to all servers in a way that won't cause errors, undesirable behavior or downtime. In any case, it means much more than just setting up another server behind a load-balancer.

It shouldn't mean much more than setting up another server. Just store your session information in your database and you'll be fine, all your front end servers will be able to hit it. This will work if you start with a combined database and web server, it will work when you split those out to their own boxes, and it will work as you add web servers. Scalability won't start getting expensive until you outgrow your database server.

Of course, that is pretty much how it is with any language, not just Perl.

While one programmer can handle dealing with the Dev->QA->Prod push just fine (in most cases), 2 developers or more can really cause problems. Since mod_perl generally means restarting Apache httpd each time a code change has been made, you may end up running a local version of the code (and possibly the database). Having a local version implies that you are using CSV, SVN or some other revision control system (yes, another set of options with no clearly-defined winner).

Again, these are the same problems you have with any language. You need whole other instances of all the services that your application needs. They may be another set of identical servers, a scaled down set of servers, or just might be running on someone's desktop (VMware and friends work great for this).

Thankfully, there is no clearly defined winner in the world of revision control. For the longest time, CVS was the only open source game in town. Now there is a ton of innovation and competition in this arena. You are doing yourself a serious disservice if you don't try one of the distributed systems, but that is a whole different story.

The total lack of a dead-simple IDE (like Visual Studio) means that we get different people using different tools. Again - another set of options with no clearly-defined winner (even though we all have our favorites). On the other hand, the ability to use whichever editor we want without relying on the IDE to generate code, line up dependencies or compile the project gives us the flexibility we have come to expect.

I won't touch a language that forces (or even very strongly encourages) me to give up my editor and use their IDE. It seems that with the MS languages I'd either be hobbled by their editor, or I'd be hobbled by mine. I suppose at least the choice would be mine, eh? :p

Each of these options will need to account for configuration files and other differences between Dev, QA and Production.

This isn't a Perl related problem, either. Every language has this problem.

The problems we face right now are Good Problems to Have. We have several options to choose from and there is a great deal of work happening in the areas I've pointed out above.

I don't think most would agree with you that points you bring up are actually problems, and more than half of your points are related to working with any language at all.

There are multiple solutions to most of what you see as a problem. The trouble is, most of them are already solved. The part you don't seem to like is that there is more than one solution for each of them.

There is more than one way to deploy a program to production, interact with a database, or scale a web site. The problem is that the right answer for you isn't the right answer for me. Maybe your application can scale well by doing a bunch of caching on the web servers and only keeping a single database server. Maybe that doesn't work well for me, and I need a database cluster. There is a reason these decisions aren't being made for you ahead of time.

With enough time and entropy the winners will reveal themselves. Until then, we can make our own choices.

Fortunately, there can be more than one winner. Most of the individual components you mentioned are very good at what they do. Thankfully, we can pick and choose the modules in each category that best fit our style and needs.

Oknow

Comment on Re: On the scaleability of Perl Development Practices

Replies are listed 'Best First'.
Re^2: On the scaleability of Perl Development Practices by dragonchild (Archbishop) on Aug 18, 2008 at 15:33 UTC
You want a tutorial on how to "write a web application using <DB Abstraction Module>, <Templating System>, and <Runtime Backend>." There are likely a half dozen reasonable choices for the first two, and three or four choices for the backend. I am not sure I understand why you need a tutorial explaining how to use three systems in concert when they are all so well isolated. Ah, but they aren't. For example, the support for using TT and DBIC with Catalyst is much stronger than using TT and DBIC with CgiApp. Or, using Text::Template and Rose::DB with Mason. And so on. While you can mix'n'match, there are some that work better with each other than with others. Hence, the usefulness of the requested documentation. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re^3: On the scaleability of Perl Development Practices by talexb (Chancellor) on Aug 18, 2008 at 16:10 UTC
For example, the support for using TT and DBIC with Catalyst is much stronger than using TT and DBIC with CgiApp. I disagree -- the module CGI::Application::Plugin::TT ties Template Toolkit and CGI::Application together very nicely, and you can see piles of plugins for CGI::Application if you do a CPAN search on 'CGI::Application::Plugin'. I used CGI::Application::Plugin::Session, CGI::Application::Plugin::DBH and CGI::Application::Plugin::Stream in a recent web application. I'm a fan. Alex / talexb / Toronto "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds	[reply]
Re^3: On the scaleability of Perl Development Practices by perrin (Chancellor) on Aug 18, 2008 at 18:33 UTC
the support for using TT and DBIC with Catalyst is much stronger than using TT and DBIC with CgiApp I don't actually see much integration between Catalyst and TT or DBIC. It's not really possible when you take a hard line on being able to switch components. Jifty is the only really integrated perl dev framework I can think of.	[reply]
Re^3: On the scaleability of Perl Development Practices by oknow (Chaplain) on Aug 18, 2008 at 21:00 UTC
Ah, but they aren't. For example, the support for using TT and DBIC with Catalyst is much stronger than using TT and DBIC with CgiApp. Or, using Text::Template and Rose::DB with Mason. And so on. While you can mix'n'match, there are some that work better with each other than with others. Hence, the usefulness of the requested documentation. I suppose I should remember that it is rarely safe to speak in absolutes. The modules that play better with certain modules than others state that pretty clearly in their documentation, don't they? Modules that don't play well with others are far less common than those that do. Oknow	[reply]
Re^4: On the scaleability of Perl Development Practices by dragonchild (Archbishop) on Aug 19, 2008 at 00:51 UTC
I've found it to be pretty rare for modules to say which work better with whom. For example, even though Catalyst and DBIx::Class were practically designed to work together (given that mst is the primary dev on both), there's little in the documentation of either that states that. Same with the fact that TT tends to be the templating system of choice for that sort of system. Modules that don't play well with others are actually the rule. A given module will only work well with those systems that the author(s) know well. For example, Excel::Template needs to have a wrapper in order to work with Template Toolkit, even though I worked with TT before writing E::T. DBM::Deep doesn't work at all with objects that have $dbh's in them, even though I'm also a DBA. It's hard to write completely general-purpose code. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]


Think about Loose Coupling
	PerlMonks