Perl publishing and attracting new developers

[Kieren Diment]

Writing a book is fun so long as you are backed by a good team (co-authors,
editor, tech reviewer, project manager, copy editor and a mate who happens
to write dictionaries for a living spotting the copy editor's slip-ups).
>From a purely financial perspective it doesn't pay well, but so long as the
book ends up well regarded (and maybe if it doesn't) it can be good for the
career.  It's certainly the best thing I've ever done in terms of
generating instant credibility for myself.

If you're interested in writing a perl book, I would recommend going with
chromatic's mob, and doing it as a not-especially-commercial proposition.
While I got to feed my family, and a nice musical instrument from the
Catalyst book it was: a.  the subsequent benefits (I got some opportunities
to do small team, high impact stuff with perl which previously seemed
closed to me) and b.  the ability to point people asking questions at the
relevant part of the book/downloadable code that previously would take long
IRC sessions.  Although the book sold reasonably well - should pay back its
advance this year, and continues to sell slowly -  the publisher hasn't
(yet) approached me for a new edition.

Anyone who wants to approach Apress about a 2nd edition, please do.  If
they're interested, you can have first author slot, so long as you let me
keep an eye over your shoulder while you're updating it.  Applicatants
should send me an outline of a chapter to replace the final chapter on
Reaction which is no longer relevant.  The outline should be three headings
deep, and contain a chunk of prose (e.g. the introductory paragraphs).
This is essentially a micro version of the process that publishers normally
require for a book proposal.  Maybe the chapter should be replaced with
something about web programming with Catalyst for async applications, or
job queues or similar.  All example code should result in a minimal working
application.


On Thu, Sep 19, 2013 at 6:03 AM, gvim <gvimrc at gmail.com> wrote:

> On 18/09/2013 18:48, Peter Corlett wrote:
>
>>
>> Dancer and Mojolicious are lightweight, DBIx::Class only slightly less
>> so, and are not separately enough material for a full-sized book. At best,
>> you're talking a 100 page print-on-demand labour of love.
>>
>>
> I've come across no less than 3 Sinatra books so why should a Dancer book
> be considered lightweight?
>
>
>  Mojolicious and Moose *have* such a book, and although I can't find the
>> ISBN for the Moose book, Mojolicious's is http://www.amazon.co.uk/exec/**
>> obidos/ASIN/3848200953/**improtripe-21<http://www.amazon.co.uk/exec/obidos/ASIN/3848200953/improtripe-21>
>> .
>>
>>
> I don't think a book published purely in German is that relevant.
>
>
>  The hypothetical "Modern Perl Cookbook" is a layering violation. Perl
>> Cookbook is a collection of short hints and tips on how to do simple tasks.
>> Modern Perl is how to architect a large system. That's two separate topics,
>> and thus two separate books. Which already exist.
>>
>>
> Perl Cookbook is 10 years old so not relevant to Perl 5.10+, ie. Modern
> Perl. Hence my "layering violation". Python Cookbook has had 2 new editions
> since the 1st edition appeared in 2002. All I'm saying is that when major
> pillars of the Perl library fall behind like this it gives the impression
> that the language is also dated. We don't see it that way from the inside,
> of course, but I'm addressing how Perl appears to new developers making a
> choice of language.
>
>
>  Then you have books where you've taken some other topic, and just stick
>> "with Perl" on the end:
>>
>>  Agile Development with Perl & Moose
>>> RESTful APIs with Perl
>>> HTML5, Javascript & Perl
>>> Network Programming with Perl (maybe an update from Lincoln Stein)
>>> Scientific Programming with Perl
>>>
>>
>> What does the "and Perl" add to the material? It may as well say "and
>> Intercal" for all the good it does.
>>
>>
> The "and Perl" makes all the difference. If I'm a new developer choosing a
> language and I see "RESTful APIs with Python/PHP/Ruby" and nothing from
> Perl it may influence my choice of language even if there is a chapter
> tucked away in a Catalyst book somewhere. Whether it's marketing or not,
> Ruby and Python are taking the initiative, as I see it, by producing plenty
> of books which combine the language with another technology. You may not
> like it but it seems to interest developers.
>
>
>  Analysing Big Data with Perl
>>>
>>
>> This is also just a "with Perl" title, but merits picking out. "Big Data"
>> is a nebulous term of art much like "Web 2.0" is, and roughly means "the
>> fashionable technologies we're using with a big layer of marketing
>> slathered on so people don't realise it's mostly hot air".
>>
>>
> I'm sure your purist's aversion to mixing Perl with any other technology
> serves you  well but the fact remains that Ruby and Python seem to have
> benefited from doing a little of what the publishers want. Contrasted with
> the dearth of Perl publications a newcomer to the scene can be forgiven for
> surmising that Perl has become less relevant.
>
> gvim
>