[ADV] Want to Write a Book?
Dave Thomas
I'm hoping to launch a new series of books from The Pragmatic
Bookshelf. "Facets of Ruby" will a a set of small, focussed, and
technical books about different aspects of Ruby. And I'm looking for
folks to write them!
I have no fixed ideas on the titles, but to give you an idea of the
kinds of things I'm looking for, you might well see books come out
named something like:
* Writing Ruby Extensions
* Using Ruby in the Semantic Web
* Creating E-Commerce Sites using Rails
* Rapid Application Development with Iowa
* Migrating from Java to Ruby
The intent is to create a series of books with a deeply practical
focus. We won't just document APIs. Instead, we want to show how to get
_value_ from those APIs---how to solve real-world problems. The books
will probably be 100-250 pages long, and full of code.
To do this, I'm hoping to attract the best and the brightest--the folks
who know. Which is why I'm posting the message to this list.
If you've always fancied writing a book on some aspect of Ruby, now's
your chance. When you work with us, you'll get to use a tool chain
that's the envy of the publishing industry in an extremely agile
production environment. We'll sell the books (in paper and PDF form)
off our web site, and the world-class O'Reilly team will distribute the
physical books to books stores and online retailers world-wide. Our
royalty scheme is simple, transparent, and generous.
You won't get rich--that's pretty much impossible in the technical book
market. But we'll have fun, and hopefully build a world-class resource
for the growing Ruby community.
If you're interested, send me an e-mail at
'mailto:facets-...@pragprog.com' containing a single paragraph
summary of the book you want to write. If we want to take a particular
project further, we'll then ask for an outline and a short extract from
the book. If everything works out, we'll then go on to write a book.
Just to get the ball rolling, I'm just starting to write the second
book in the series (if you count PickAxe II as the first)---I'm working
on an introduction to Rails.
Cheers
Dave
"Peña, Botp"
//Gentle Ruby folk:
//
//I'm hoping to launch a new series of books from The Pragmatic
//Bookshelf. "Facets of Ruby" will a a set of small, focussed, and
//technical books about different aspects of Ruby. And I'm looking for
//folks to write them!
[snip cool things]
this is a noble idea/task. Thanks sir Dave.
We'd appreciate very much if the projects will be posted publicly so we will
know if a project has been taken or not; or is it ok to dup? =)
//
//Dave
//
kind regards -botp
Dave Thomas
On Dec 9, 2004, at 20:18, Peña, Botp wrote:
> We'd appreciate very much if the projects will be posted publicly so
> we will
> know if a project has been taken or not; or is it ok to dup? =)
The way of the book world is that folks sign up to write, then
sometimes get sidetracked and don't finish. I don't want the community
to look at a list and expect to see the books on it materialize--I'd
rather the authors individually agreed before announcing their titles.
Cheers
Dave
marku...@gmx.de
although I lack the time to write
I will definitely buy the books !!
I am currently reading Pickaxe 2 and it
is the best book about a Programming language
I have ever read (and I have read a lot !)
a book on Rails would be great. I think
Rails will be Ruby's killer application. so a book
would be needed.
another Idea for a book would be
"Effective Ruby" in the style of the
"Effective C++/ Perl / Java, / J2EE " books
form Addison-Wesley.
thanks for your effort.
regards
Markus
martinus
I want this!
martinus
Stefan Schmiedl
Then write it!
It has several advantages:
- You are the first to read it.
- You can get the author to make changes.
- You get a lot of work with almost no pay.
- You get a tremendous amount of relief once the thing is out of your
hands.
Anybody up for collaboration on the RAD-IOWA book?
s.
Luc Heinrich
> I'm working on an introduction to Rails.
I KNEW IT ! :))
--
Luc Heinrich - luc...@mac.com
martinus
leaflet.
martinus
daniel cremer
> Anybody up for collaboration on the RAD-IOWA book?
>
> s.
I have been extremely busy recently, however, luckily it was time spent
working with Iowa. I definitely don't have the time to do much writing
but would be happy to chip in with proof reading, submitting ideas and
generally helping out on an IOWA book... Of course the authority on Iowa
at the moment is Kirk :)
Feel free to contact me off list if anyone wants to discuss this.
Daniel
Michael Neumann
Stefan, did you have taken a look at Wee? Or are you using IOWA due to
it's templating engine? Wee is much more like the current Seaside by Avi
Bryant, but not a plain port thereof. It's still in development,
currently I'm mostly on documenting it:
http://www.ntecs.de/viewcvs/viewcvs/*checkout*/Wee/branches/dev/doc/rdoc/index.html?rev=363
And someone mentioned that he's porting Mewa
(http://www.adrian-lienhard.ch/files/mewa.pdf) over to Ruby/Wee.
I'm currently further on extracting and cleaning up the core of Wee,
which is independent of HTTP and HTML, and includes only the component
logic (the session logic is pretty minimal). Templating is 100%
choosable, but it comes with a programmatical HTML generation API.
Lot's of parts of the source is now very clean, and all together it's
1600 LoC (600 for the core where near to 50% is documention)... And all
memory holes have been fixed.
Regards,
Michael
Stefan Schmiedl
Michael Neumann <mneu...@ntecs.de> wrote:
>
> Stefan, did you have taken a look at Wee? Or are you using IOWA due to
> it's templating engine? Wee is much more like the current Seaside by Avi
> Bryant, but not a plain port thereof.
Well, Iowa is production quality, and I needed something right away.
It's quite convenient to work with (after the first date, which would
have turned out quite awkward, had I not found a chapter about it in
a book co-authored by some chap calling himself Stefan Schmiedl).
Together with Kansas, it fits my current needs quite good.
> It's still in development,
> currently I'm mostly on documenting it:
>
> http://www.ntecs.de/viewcvs/viewcvs/*checkout*/Wee/branches/dev/doc/rdoc/index.html?rev=363
Documentation is a Good Thing. I knew about your efforts on Wee (Armin
has mentioned it on our blog somewhere), but I don't have as much
playtime now as I would like to have.
>
> And someone mentioned that he's porting Mewa
> (http://www.adrian-lienhard.ch/files/mewa.pdf) over to Ruby/Wee.
>
> I'm currently further on extracting and cleaning up the core of Wee,
> which is independent of HTTP and HTML, and includes only the component
> logic (the session logic is pretty minimal). Templating is 100%
> choosable, but it comes with a programmatical HTML generation API.
> Lot's of parts of the source is now very clean, and all together it's
> 1600 LoC (600 for the core where near to 50% is documention)... And all
> memory holes have been fixed.
Looks very promising, Michael. I do hope that business will calm down
a little over the holidays, so that I can catchup on my backlog, after
which I could let it build up again by checking out Wee :-)
s.
Michael Neumann
> On Fri, 10 Dec 2004 21:24:41 +0900,
> Michael Neumann <mneu...@ntecs.de> wrote:
>
>>Stefan, did you have taken a look at Wee? Or are you using IOWA due to
>>it's templating engine? Wee is much more like the current Seaside by Avi
>>Bryant, but not a plain port thereof.
>
>
> Well, Iowa is production quality, and I needed something right away.
> It's quite convenient to work with (after the first date, which would
> have turned out quite awkward, had I not found a chapter about it in
> a book co-authored by some chap calling himself Stefan Schmiedl).
> Together with Kansas, it fits my current needs quite good.
Sure, Wee is some steps away from production quality, just because
important parts have to be reworked (Session, Application classes, which
are not in the core ;-)). Nevertheless, those are only a few hundred
lines of code...
BTW, would be nice to hear why you did choose IOWA and not Rails. Simply
because you did not tried it, or for some other reasons... I'm just
curious ;-)
>>It's still in development,
>>currently I'm mostly on documenting it:
>>
>>http://www.ntecs.de/viewcvs/viewcvs/*checkout*/Wee/branches/dev/doc/rdoc/index.html?rev=363
>
>
> Documentation is a Good Thing. I knew about your efforts on Wee (Armin
> has mentioned it on our blog somewhere), but I don't have as much
> playtime now as I would like to have.
>
>
>>And someone mentioned that he's porting Mewa
>>(http://www.adrian-lienhard.ch/files/mewa.pdf) over to Ruby/Wee.
>>
>>I'm currently further on extracting and cleaning up the core of Wee,
>>which is independent of HTTP and HTML, and includes only the component
>>logic (the session logic is pretty minimal). Templating is 100%
>>choosable, but it comes with a programmatical HTML generation API.
>>Lot's of parts of the source is now very clean, and all together it's
>>1600 LoC (600 for the core where near to 50% is documention)... And all
>>memory holes have been fixed.
>
>
> Looks very promising, Michael. I do hope that business will calm down
> a little over the holidays, so that I can catchup on my backlog, after
> which I could let it build up again by checking out Wee :-)
Hope at that time, Wee is in a much better shape.
Regards,
Michael
Stefan Schmiedl
Michael Neumann <mneu...@ntecs.de> wrote:
>
> Sure, Wee is some steps away from production quality, just because
> important parts have to be reworked (Session, Application classes, which
> are not in the core ;-)). Nevertheless, those are only a few hundred
> lines of code...
The fewer, the better!
>
> BTW, would be nice to hear why you did choose IOWA and not Rails. Simply
> because you did not tried it, or for some other reasons... I'm just
> curious ;-)
errm... mainly gut feeling, I guess. There are some default settings
with Rails and its database backend which I don't like. I know that
I can override them, but still ... OTOH, Kansas as Iowa's preferred
backend (I wonder how that sounds to native speaker from Kansas ...)
is both very clever and very small.
I have to admit that I haven't followed the frequent announcement on
Rails improvements thoroughly, but just from the looks, Iowa seemed
easier to setup with it's own Webrick-based HTTP-server and indeed
proved to be absolutely no hassle thanks to the efforts of the rpa
packagers. Moving things between my development machine and the
production server is easy, too, as I just scp a tarball and change
the port webrick listens on.
I'm growing my pages in a single HTML file until they do what they
need. Then I improve code structure until changes in application logic
(mostly) won't influence the HTML part any more. Finally I split the
.iwa part off and refactor the code with the existing base. I will
repeat this until the project is finished.
Back to my gut feeling, which I can now summarize into a single
sentence: I think that Iowa makes things simple, but not too simple.
> Hope at that time, Wee is in a much better shape.
Wee will be, even if we will be not :-)
s.
pat eyler
I'd love to see a book on Inversion of Control/Dependency Injection
with Needle.
-pate
itsme213
"Michael Neumann" <mneu...@ntecs.de> wrote in message
news:41B99583...@ntecs.de...
> Stefan, did you have taken a look at Wee? Or are you using IOWA due to
> it's templating engine? Wee is much more like the current Seaside by Avi
> Bryant, but not a plain port thereof. It's still in development,
> currently I'm mostly on documenting it:
Wee is starting to look _really_ attractive. One early suggestion:
Don't bake the "render new
itsme213
"Michael Neumann" <mneu...@ntecs.de> wrote in message
news:41B99583...@ntecs.de...
> Stefan, did you have taken a look at Wee? Or are you using IOWA due to
> it's templating engine? Wee is much more like the current Seaside by Avi
> Bryant, but not a plain port thereof. It's still in development,
> currently I'm mostly on documenting it:
Wee is starting to look _really_ attractive. The size is lovely. One early
suggestion:
It may be better to not bake "render new page" into the render phase if that
means a whole new html page. I think something along the lines of partial
page replacement using xmlhttp, and the tiny bit of Javascript magic that
Avi wrote for this, would be a very attractive alternative
(http://www.cincomsmalltalk.com/userblogs/avi/blogView?showComments=true&tit
le=Cosying%20up%20to%20the%20client-side&entry=3268075684) It is really a
marvellous facility, and lines up quite well (I think) with Wee::Components.
Simon Strandgaard
>
> * Writing Ruby Extensions
I think im interested in contributing to the Regexp book. I have some
insight into regexps.
--
Simon Strandgaard
Josef 'Jupp' Schugt
>> books about different aspects of Ruby.
>
Especially the 'Writing Ruby Extensions' part. There still isn't very
much material on this subject.
Josef 'Jupp' Schugt NOTE: mails >100 KiB are ignored
--
German edition of comp.lang.ruby FAQ - http://oss.erdfunkstelle.de/ruby/
Aurox Linux - http://qurl.net/7q | http://qurl.net/7r - Firefox
Thunderbird - http://qurl.net/7s | http://qurl.net/7t - Liferea
Enigmail - http://qurl.net/7u | http://qurl.net/7v - GnuPG
David G. Andersen
>
> I have no fixed ideas on the titles, but to give you an idea of the
> kinds of things I'm looking for, you might well see books come out
> named something like:
>
> * Writing Ruby Extensions
> * Using Ruby in the Semantic Web
> * Creating E-Commerce Sites using Rails
> * Rapid Application Development with Iowa
> * Migrating from Java to Ruby
A book I wish I had the time to write, but I'm swamped:
Using Ruby in Scientific Applications
- Numerical applications
- Analysis
- Data Acquisition
- Control
- Visualization
- Data archiving and retrieval
I haven't had a chance to play with the acquisition and control
aspects yet, so I don't actually know what would go into this book
-- but I really wish I already had it on my bookshelf. Perhaps it
would turn into a giant users manual for NArray, but I think there's
a lot more. I promise to buy copies and hand them to my colleagues
and students if someone writes it. ;)
-Dave
--
work: d...@lcs.mit.edu me: d...@pobox.com
MIT Laboratory for Computer Science http://www.angio.net/
Cameron McBride
> - Numerical applications
> - Analysis
> - Data Acquisition
> - Control
> - Visualization
> - Data archiving and retrieval
yes, yes. it'd be lovely.
Cameron
Steven Jenkins
> A book I wish I had the time to write, but I'm swamped:
>
> Using Ruby in Scientific Applications
> - Numerical applications
> - Analysis
> - Data Acquisition
> - Control
> - Visualization
> - Data archiving and retrieval
>
> I haven't had a chance to play with the acquisition and control
> aspects yet, so I don't actually know what would go into this book
> -- but I really wish I already had it on my bookshelf.
I have a proposal in to IBM for an article for developerWorks on "Data
Acqusition with Linux, Comedi, SWIG, and Ruby. They said to check back
if I hadn't heard from the Linux editor in four weeks. (Why they need
more than ten minutes to accept a free article is another question. On
the other hand, the same topic was rejected for OSCON last year, so
maybe you and I are the only ones interested....)
> Perhaps it
> would turn into a giant users manual for NArray, but I think there's
> a lot more. I promise to buy copies and hand them to my colleagues
> and students if someone writes it. ;)
Have you seen ruby-gsl? Powerful stuff.
Steve
Joel VanderWerf
I'd be interested in reading that book, and maybe helping out with it.
Some more chapters of this hypothetical book that would be nice to have:
- Simulation, modeling, random number generation
- Interfacing with other tools: gnuplot, Matlab, Excel, R, etc.
- Using ruby efficiently: extensions, mmap, narray
- Crafting domain-specific sublanguages for scientific apps
- Ruby and distributed/parallel processing
- Managing legacy C and Fortran code
- Ruby in a real-time environment?
Some folks on this list (Ara Howard and Bil Kleb come to mind) are
eminently qualified to write on those topics.
David G. Andersen
> David G. Andersen wrote:
> >
> > Using Ruby in Scientific Applications
> > - Numerical applications
> > - Analysis
> > - Data Acquisition
> > - Control
> > - Visualization
> > - Data archiving and retrieval
>
> - Interfacing with other tools: gnuplot, Matlab, Excel, R, etc.
> - Using ruby efficiently: extensions, mmap, narray
> - Crafting domain-specific sublanguages for scientific apps
> - Ruby and distributed/parallel processing
> - Managing legacy C and Fortran code
> - Ruby in a real-time environment?
Steven Jenkins wrote:
> "Data Acqusition with Linux, Comedi, SWIG, and Ruby."
> [...] ruby-gsl
Steven's point about SWIG is well integrated into such a book,
and goes hand in hand with Joel's "Interfacing" and "Managing"
points.
I just looked at ruby-gsl; hadn't seen it before, but I _like_ it -
thanks, Steven!
Very nice, intuitive, and seems to behave in the way I'd expect
it to for simple things like vector and matrix manipulation.
It has one nice answer to the random number generation point
above, though I suspect there are others.
(Note that FreeBSD's "ruby-gsl" port is actually Ruby/GSL,
not the similarly named "ruby-gsl" project)
There's also the Lapack interface, which I haven't peeked at
lately.
So putting those all together and shaking a bit to get a book
that we'd all really like to have, hopefully. ;-)
- Numerical applications
- Variable precision math in Ruby
* BigDecimal, GMP, ??
- Simulation, modeling, random number generation
- Analysis
- Statistics
: NArray, GSL, ??
- Data Acquisition and Control
- Comedi
- Dealing with GPIB
- Visualization and plotting
- Gnuplot / ploticus / etc.
- NImage
- gd
- Something that differentiates between generating
images for publication vs. immediate UI images vs.
dynamic images for the web
- Data archiving and retrieval
- Local data
- Compressed data
- Databases
- Interfacing with other tools
- "Why SWIG is your friend". ;-)
- Matlab, Excel, R, etc.
- Managing legacy C and Fortran
- Optimization and Speed
- C extensions
- MMap and other cool tricks
- Distributed computing and parallel processing
- Crafting domain-specific sublanguages for scientific apps
- Ruby in a real-time environment?
Martin DeMello
> -- but I really wish I already had it on my bookshelf. Perhaps it
> would turn into a giant users manual for NArray, but I think there's
I wouldn't mind seeing that either :)
martin
Brian Schröder
Steven Jenkins
> I just looked at ruby-gsl; hadn't seen it before, but I _like_ it -
> thanks, Steven!
> Very nice, intuitive, and seems to behave in the way I'd expect
> it to for simple things like vector and matrix manipulation.
> It has one nice answer to the random number generation point
> above, though I suspect there are others.
> (Note that FreeBSD's "ruby-gsl" port is actually Ruby/GSL,
> not the similarly named "ruby-gsl" project)
Yes, Ruby/GSL is the one I meant. Sorry about the confusion.
Steve
Matt Pattison
<vj...@path.berkeley.edu> wrote:
> David G. Andersen wrote:
> > On Fri, Dec 10, 2004 at 10:52:18AM +0900, Dave Thomas scribed:
> >
I'd really like to read this book - a year ago. Seriously, this would
be a great book that I would definitely buy. A lot of the momentum
around Ruby tends to be related to the web, it would be great for Ruby
to have momentum also for scientific / numerical tasks, similar to
Python for example.
Matt
Michael Neumann
(forwarded to Avi)
I think what you describe is best accomplished with callbacks, that do
what the render-phase or action-phase would do. Or maybe with
continuations. It's currently not possible to generate a response in the
action-phase in Wee. If I change this, and be able to just register an
action callback which returns some html, then this should work.
Probably, it's only a few lines to change ;-)
Not that I would make much use of it, as I think it's only usable in a
very few cases, and would probably break portability (JavaScript), but
if it results in a simplicification of the current Wee, then I'll
implement it.
Regards,
Michael
gabriele renzi
> Not that I would make much use of it, as I think it's only usable in a
> very few cases, and would probably break portability (JavaScript), but
> if it results in a simplicification of the current Wee, then I'll
> implement it.
>
well, if you do some live update stuff with javascript using
XmlHTTPRequest you should be fine on mozilla/firefox, IE, safari, recent
konqueror and the next opera. It is the stuff used in many widely know
things such as flickr.com or gmail, wich have quite a big audience.
(ok, lynx would be out probably :)
Michael Neumann
okay, I'll implement it ;-)
Regards,
Michael
gabriele renzi
I just noticed that through the blog post referenced from itsme123 you
can get here:
http://www.papermountain.org/demos/live/
where the author has a Borges implementation.
I guess you can rip it out, at least the javascript magic :)
Bil Kleb
> On Sun, 12 Dec 2004 15:03:44 +0900
> Joel VanderWerf <vj...@PATH.Berkeley.EDU> wrote:
>
>>David G. Andersen wrote:
>>>
>>>
>>>A book I wish I had the time to write, but I'm swamped:
>>>
>>> Using Ruby in Scientific Applications
>>> - Numerical applications
>>> - Analysis
>>> - Data Acquisition
>>> - Control
>>> - Visualization
>>> - Data archiving and retrieval
>>
>>Some more chapters of this hypothetical book that would be nice to have:
>>
>> - Simulation, modeling, random number generation
>> - Interfacing with other tools: gnuplot, Matlab, Excel, R, etc.
>> - Using ruby efficiently: extensions, mmap, narray
>> - Crafting domain-specific sublanguages for scientific apps
>> - Ruby and distributed/parallel processing
>> - Managing legacy C and Fortran code
>> - Ruby in a real-time environment?
>>
>>Some folks on this list (Ara Howard and Bil Kleb come to mind) are
>>eminently qualified to write on those topics.
>>
>
> +1 From me
+1
Ara?
Regards,
--
Bil Kleb, Hampton, Virginia
Dick Davies
See Google Suggest too:
http://www.google.com/webhp?complete=1
these guys never cease to boggle my mind when I try to guess how many acres
of computing power they must have to do something like this. I picture scenes
from the Matrix, except with motherboards rather than people in the pods...
--
A little rudeness and disrespect can elevate a meaningless interaction
into a battle of wills and add drama to an otherwise dull day. - Calvin discovers Usenet
Rasputin :: Jack of All Trades - Master of Nuns
gabriele renzi
>>well, if you do some live update stuff with javascript using
>>XmlHTTPRequest you should be fine on mozilla/firefox, IE, safari, recent
>>konqueror and the next opera. It is the stuff used in many widely know
>>things such as flickr.com or gmail, wich have quite a big audience.
>>(ok, lynx would be out probably :)
>
>
> See Google Suggest too:
>
> http://www.google.com/webhp?complete=1
even google-groups2 uses a similar interface. And even if nobody "hyped"
it, even yahoo mail does
> these guys never cease to boggle my mind when I try to guess how many acres
> of computing power they must have to do something like this. I picture scenes
> from the Matrix, except with motherboards rather than people in the pods...
:)
Dee.Z...@freemail.hu
language itself, and as such it is expected to change in possibly
incompatible ways. Would not be than a safer bet sticking with SWIG for
interfacing, as a more _softer_ layer? I know, that would not be a Ruby
book :-(
--
Dee Zsombor
Brian Mitchell
Although it may change, a good book on ruby (the implementation)
internals has yet to be written in or translated to English. I would
love to see a version of the black book (Ruby Hacker's Guide) that I
could use more easily.
Brian M.
Dee.Z...@freemail.hu
always use the source ... Luke!
Brian Mitchell
That I know well. I wish I could just save some of my time as Ruby is
not the only thing I work on (in fact it's a small slice). Might
better source code documentation help? I don't know which would be
easier as good books are not easy to build overnight. Neither is good
documentation.
Brian M.
Lyle Johnson
I appreciate the sentiment, but that's like saying that if you want to
understand how a car works you just need to look under the hood.
I've dug through the Ruby source code on more than one occasion to try
to get a handle on some of the trickier aspects of Ruby's
implementation, such as garbage collection or threads. It's easy
enough to see that some isolated function sets some variable to some
value; but without some higher-level explanations of the important
data structures and processes, it's near impossible to understand how
that isolated function fits into the big picture.
And that's why we must all pray that Guy Decoux stays in good health. ;)
Steven Jenkins
> A book I wish I had the time to write, but I'm swamped:
>
> Using Ruby in Scientific Applications
> - Numerical applications
> - Analysis
> - Data Acquisition
> - Control
> - Visualization
> - Data archiving and retrieval
Maybe we should start a wiki and see where it goes. I'll contribute
something about the data acquisition work I've done with Comedi and Ruby.
Steve
Benedikt Huber
> David G. Andersen wrote:
>> A book I wish I had the time to write, but I'm swamped:
>>
>> Using Ruby in Scientific Applications
> Maybe we should start a wiki and see where it goes. I'll contribute
> something about the data acquisition work I've done with Comedi and Ruby.
>
> Steve
A wiki on this topic would be very interesting indeed.
Any chance of starting one ?
I'd like to see a book as well of course.
Benedikt
Kaspar Schiess
> Maybe we should start a wiki and see where it goes. I'll contribute
> something about the data acquisition work I've done with Comedi and Ruby.
I will contribute with the r4ruby project (R statistical analysis as a Ruby
library), but this has been rescheduled to middle/end of this year.
kaspar
hand manufactured code - www.tua.ch/ruby
gabriele renzi
maybe start a wikibook on hieraki :)
Vladare
Bil Kleb
> David G. Andersen wrote:
>
>> A book I wish I had the time to write, but I'm swamped:
>>
>> Using Ruby in Scientific Applications
>> - Numerical applications
>> - Analysis
>> - Data Acquisition - Control
>> - Visualization - Data archiving and retrieval
I thought Ara Howard was working on this book?
--
Bil Kleb, Hampton, Virginia