[Catalyst] Re: So, what do we want in the -next- book?

[Ian Sillitoe]

I get the impression that persuading a decent publisher to properly back a
500+ page Catalyst book covering all aspects, discussions, internals, best
practices, cookbook, etc. is just not going to happen (unfortunately),
certainly not at the moment. The point has been made before, but I think it
is worth reiterating: writing a decent book requires an enormous
commitment/investment of money, time, skill and effort from both the authors
and publishers. Even with all those things you can end up with a bad
product, but you're almost certainly guaranteed a bad product without them.

If people are serious about trying to get another book commissioned, written
and published, then perhaps there are two separate issues:

 - what do we *want* in the next book?
 - what do we think *we might realistically be able to get* in the next
book?

Yes, it would be great to see O'Reilly give Catalyst the full 'Camel Book'
treatment, but the initial comments from O'Reilly make this seem at best
unlikely (at least in the near future). However, it's worth noting that I
remember my first copy of the Camel Book (2nd ed?) being a great deal
smaller than the latest edition - so maybe it's worth being a bit more
pragmatic - choosing a format that would be most useful and sell well, while
being easiest to produce - with the view that increased coverage/backing
would help the project perhaps as much as book itself.

So again, my vote is for Catalyst Best Practices - I get the impression that
this format would require less editing/structuring - i.e. providing code
snippets and accompanying discussion for a whole number of FAQs, gotchas,
recommended plugins, common development scenarios. However, I very much take
the point that if this is going to be useful it should provide opinions on a
number of non-Catalyst topics - e.g. providing opinions on DBIx::Class,
Moose, setting up MVC applications outside of Catalyst would be relevant and
a Good Thing.

Like PBP, it would take someone (or preferably a group of people) to agree
on a bunch of points that they think are important - then be brave and say
this is what I/we think is the best way of doing them and why (perhaps even
breaking things down to a simple set of 'rules' as in PBP). This could also
help to address the other discussion currently going on about providing a
set of standards for internal coding practices. Inevitably there will be
disagreements (e.g. Class::Std/Moose in PBP), especially in hindsight.
However just like PBP, I for one would be very happy to take the advice of
someone who has spent time getting these things working in commercially
successful applications.

Ian

On Mon, Apr 28, 2008 at 11:11 AM, Tobias Kremer <list at funkreich.de> wrote:

> Quoting "Ali M." <tclwarrior at gmail.com>:
> > Sorry to say this, but your book is not a good book!
> > I cannot in good faith recommend it to anyone. Please consider
> > believing the bad review your book got, because they are correct.
>
> And here we are again, waiting for the usual "If you don't like what's out
> there, roll/write/code your own" response which is not gonna make things
> better
> for Catalyst or Perl in general ... I bought the book, put it in my shelf
> and
> never looked into it. I seriously doubt that's a good sign for any book
> ...
>
> Writing a book IS hard and I appreciate the work Jonathan put in the first
> Catalyst book. But the book in its current form really is not very
> appealing
> especially to people who're not involved in the Cat community at all.
>
> I don't know why the Perl community in general is having such a hard time
> making
> its favourite language and tools like Catalyst appealing to the outside
> world. I
> suppose all those Ruby and PHP dudes are better at this because many of
> them
> once started out as "web designers" before becoming "web developers" ...
> It
> seems there are too few top-notch developers in the Perl community who
> have a
> sense for the "soft" factors that make or break a product.
>
> --Tobias
>
> _______________________________________________
> List: Catalyst at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20080428/709be=
77d/attachment.htm