[ADV] Want to Write a Book?

D

Dave Thomas

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!

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:[email protected]' 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
 
M

markusjais

hi Dave

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
 
S

Stefan Schmiedl

I want this!

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.
 
M

martinus

With my current knowledge about semantic web, i could not even write a
leaflet.

martinus
 
M

Michael Neumann

Stefan said:
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?

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
 
S

Stefan Schmiedl

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.

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.
 
M

Michael Neumann

Stefan said:
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 ;-)
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.




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
 
S

Stefan Schmiedl

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.
 
P

pat eyler

While I lack the chops to write it (which is why I want it so badly),
I'd love to see a book on Inversion of Control/Dependency Injection
with Needle.

-pate
 
D

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
 
C

Cameron McBride

Using Ruby in Scientific Applications
- Numerical applications
- Analysis
- Data Acquisition
- Control
- Visualization
- Data archiving and retrieval

yes, yes. it'd be lovely.

Cameron
 
S

Steven Jenkins

David said:
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
 
J

Joel VanderWerf

David said:
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


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.
 
D

David G. Andersen

- 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?

Steven said:
"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?
 
M

Martin DeMello

David G. Andersen said:
-- 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
 
B

Brian Schröder

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.

+1 From me
 
S

Steven Jenkins

David said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,054
Latest member
TrimKetoBoost

Latest Threads

Top