In order to make creating a web application like "configuring an XML file", your framework must be very opinionated, which Pyramid is not. I think there are two different audiences here and you are never going to change Django "configurers" into Pyramid programmers with a great book.
Maybe they would be better suited with a book on one of the opinionated frameworks built on top of Pyramid. (Kotti, Ptah, Khufu, Akhet) Those frameworks have made many of the tough decisions for them and, if one of them meets their needs, they just need a little help "configuring" it. There is another, maybe smaller, set of programmers that do use Pyramid directly to either create an "opinionated" framework or to solve a problem that is difficult to do with other frameworks. For them, extra books on integrating various pieces are very valuable, although whether that value adds up to enough to make it worth the authors time is another story. Which takes us back to the first point of the OP: * What kind of book about Pyramid do you think would be successful? That is tricky because it may depend on what projects people are currently working on. However, there probably is some common ground in topics like database back-end integration, error reporting, and long running process integration (judging from topics that come up often on this forum). A list of possible topics could be put on an online poll and let current developers mark those that they have either struggled through in the past, would like more direction on, or anticipate using in the future. An aspiring author could take the top picks from that list and develop a book that at least would have the interest of a good percentage of the current user base. Likely that would translate also to a good percentage of future users. However, it is unlikely that it will ever be the sheer number of people that might buy a Django book for the reasons mentioned earlier. On Mon, Mar 25, 2013 at 10:09 AM, Jonathan Vanasco <[email protected]>wrote: > 1. I'd agree that the current docs are great. I wonder what a book > would be. > > 2. fwiw, friends who have written/edited tech books have said this: > > you basically get paid nearly nothing / a vanity fee for your book. > it works out to less than minimum wage. > > the terms get better as you work with a publisher more. once you do a > few books, it becomes worth it. > > > 3. it's too hard to say this delicately, so i'm going to send the > blunt statements to address Mike's points about Django docs to him > personally. publicly... i think the bulk of django users I've met > would largely be scared of pyramid and not care for it. and that is > simply because they program in "Django" not "Python". it's a similar > phenomena to how many people program in "Rails" and not "Ruby". The > full-service frameworks have attracted a following of people who pick > up the frameworks but not the language -- and the level of behind-the- > scenes magic + coding style keep people from really using the actual > language. coding in many of these frameworks is more like configuring > an XML file than writing a program. > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/pylons-discuss?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
