[Catalyst] "Catalyst - The Definitive Guide" and the "Catalyst Cookbook"

[David K Storrs]

On Dec 23, 2005, at 6:30 AM, Sean Davis wrote:

>
>
>
> On 12/22/05 2:16 PM, "Charlton Wilbur" <cwilbur at tortus.com> wrote:
>
>> On Dec 22, 2005, at 11:13 AM, David K Storrs wrote:
>>
>>> I would suggest dividing the book into two sections:  quick start
>>> and Everything There Is To Know.  The quick start section should be
>>> just that--a heavily emphasized section right at the front that
>>> says "Here is what you need to know to have your app running and
>>> doing useful things in 4 minutes, and doing 80% of what you need it
>>> to do in 30 minutes."
>>
>> I'd like to strongly caution against this sort of hyperbolic time
>> estimate, because it's the sort of thing that registers with pointy-
>> haired bosses and buzzword fanatics and is impossible to get un-
>> registered.
>>
>> I'm dealing with a client right now who has a complicated, finicky,
>> inconsistent, and ever-changing business model.  I'm the programmer
>> on the team that's putting his website together.  The *last* thing I
>> want to impinge on his consciousness is "doing 80% of what you need
>> your app to do in 30 minutes."  I couldn't put together the database
>> definition for his business model in 30 minutes, let alone get his
>> application running; in fact, the most difficult part of this whole
>> thing has not been programming but in wringing the business rules out
>> of him and getting him to make at least tentative decisions about his
>> business model.

*laugh*  Ok, I see your point, and I agree with it; we shouldn't use  
this as a tagline which PHBs will misunderstand.

However, since it's just us chickens here, I'll point out:

	1) Building the first 80% of anything is usually easy, it's the last  
20% that eats you alive.

	2) It's really not fair to include time spent doing requirements  
gathering and design work in the amount of time that it takes to use  
Catalyst.  That time is a function of your interpersonal and design  
skills, and is completely orthogonal to the platform, technology, or  
methodology you are using to generate code.




>> [...]
>> [....W]hy not emphasize [...]
>> ("using an MVC framework means you aren't tied to the web, and can
>> automate things without any less power"; "we have CPAN"; "object-
>> oriented development means you can modularize and unit-test
>> everything to help catch bugs"; or the one I'd like to see, "we make
>> AJAX in Perl painless for the developer and reliably cross-
>> platform"), to catch the attention of people who aren't working on
>> small applications?
>
> I couldn't agree more here.  Again, this comes back to what the  
> audience is
> and from where that audience is starting.  Toy examples are nice  
> for folks
> and good candy

You know...that phrase "toy examples" is starting to become one of my  
personal pet peeves.  The kind of examples I'm thinking of would  
leave you with a fully functional ecommerce site (well, right up to  
the edge of the merchant gateway, anyway) with an up-and-running  
database, scripts to load data in from CSV, the ability to support  
user login, and an attractive interface that was cross-browser/cross- 
platform, and a clean and straightforward way to reskin the site as  
you wish.  How exactly is that a "toy example"?

--Dks