As for a book, many posts make a chapter and enough chapters make a book. Dave Cross has been promoting a space for self-publishing with https://perlschool.com/ so this is within the realm of possibility. Would you like to join in?
]]>That being said, a chapter on how to make PDL work with Windows would make any book that much nicer. Do you fancy sharing some of your pain?
]]>As an author, you won't get better unless you write and I will do my utmost to enable that! If you can reply here, I would think you can also post here on blogs.perl.org (look for the Post link at the top). The locals are quite polite, so it's a good place to get started. It's not the best interface in the world, so if you get frustrated, I'll post it for you. I know some people with wordpress accounts, if that's your thing.
]]>I think Dave Cross suggested to me that an e-book could be like a short story, only as long as it needs to be to complete an idea. Or you could think of it as an Agile approach to authoring. I'm just trying to keep to a schedule of one post every 2 weeks and an investment of 3 hours effort (which explains the glib and haphazard style :)
]]>However, good books take quite a bit of time and effort. It's not a matter of simply writing. Most of the pain is in sequencing—what's the minimal amount someone needs to know to do the next step?
My Learning Perl 6 book raised $40k on Kickstarter. I got about $37k after fees, and spent about half of that on buying the books wholesale to ship to people. I don't think I'd do a niche book like that for that little again because that's all the money I'd ever get. With Learning Perl, my royalties are still decent and that's been paying off for years.
Some people have mentioned a TPF grant, and they've affirmatively told me that they want to support something I'd do. However, their cap is $10k. I can make about that much in month of contract work. Although I don't write because it's making me rich, I do have bills to pay just like everyone else.
For anyone thinking about doing this, my advice is to ignore the mechanics. Forget about the tools, websites, whatever. Plenty of enthusiastic people start projects by setting up GitHub accounts, blogs, project boards, and whatnot. We can publish stuff on Perl.com as a start. The goal is to get content, not create a content management system (although that's more fun).
Instead, write half the book. Do that in Word, vim, whatever, in any format that you care to use. It doesn't matter because it can always be converted to something else. I mostly write in PseudoPod and have converters to Markdown, LaTex, DocBook, WordML, and so on (based on whatever the publisher wants at the end). Forget about the process for now, because that's really easy later when you get stuck or start to hate writing: drop into some fun ETL stuff (and that's all it is).
There are three sorts of books you get to write, generally: references, tutorials, or cookbooks. Programming Perl is a reference book and was the basis for a lot of the original Perl documentation. But, it's also literally at the limit of its physical binding and a massive undertaking. Learning Perl is a tutorial, in which we carefully guide the reader to our goal and during which we expect readers to go in order. Effective Perl Programming is a cookbook in which you can drop into any chapter and start reading. There's a grouping and no sequence. These are easy to write because I allow myself to presume a level of knowledge that lets me ignore almost everything I have to think about in the other two sorts of books.
When you are writing, figure out what you need to cover. So, pick something in the middle and just write the chapter. Then look at the chapter and list the assumptions you made:
Now, divide those concerns into what you can cover in the book and what you can defer. For example, you can punt to Learning Perl or Intermediate Perl for many things, so you don't have to reteach these. You note the level of proficiency you expect upfront, give them some pointers, and move on. Where you draw the line depends on your audience.
For example, in Mojo Web Clients, I covered several basic Perl features that people may not have used if they've been programming Perl for a long time, such as postfix dereferencing and subroutine signatures. I wanted to use those features and they don't appear in any other Perl books (that I know about). I also covered some basic Mojo utility modules so I could use them without explanation later. I think both of these chapters are in the free sample on LeanPub.
After that, you have the list of things you need to include in the book. Your job as the author is to present those in an order and in a way that makes sense for the audience. That is probably not the way that you want to think about them. Randal Schwartz was always insistent that we never suddenly start using some feature we hadn't explained yet, and that approach generally works. This is painful indeed. You really beat yourself up because you have to justify everything you do. Every feature in every expression has to serve the point you are want to highlight, and feeds back into that list of assumptions. Things you do with no thought now become major points of contention because you can't casually drop those things on the reader and expect them to separate the importance of the point from its concrete demonstration.
Oh, hey, this is a comment, I guess, so I should probably stop. Finally, I'll say that I'd love to write a PDL book and if someone with deep pockets wants to fund it, lets talk.
]]>It warmed my heart when I recently tripped over 40 pages on the internals of PDL to find it was written only 3 years ago. It's still an active project with a lot to offer today's audience. I guess that means I should get another post out.
]]>