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-of-r...@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.
//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? =)
> 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.
> 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-of-r...@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.
martinus <martin.ank...@gmail.com> wrote: >> * Using Ruby in the Semantic Web
> 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?
On Fri, 2004-12-10 at 18:47 +0900, Stefan Schmiedl wrote: > 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.
Stefan Schmiedl wrote: > On 10 Dec 2004 00:36:47 -0800, > martinus <martin.ank...@gmail.com> wrote:
>>> * Using Ruby in the Semantic Web
>>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?
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:
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.
> 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:
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.
> 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 :-)
Stefan Schmiedl wrote: > On Fri, 10 Dec 2004 21:24:41 +0900, > Michael Neumann <mneum...@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 ;-)
> 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.
>>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 :-)
> 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.
On Fri, 10 Dec 2004 10:52:18 +0900, Dave Thomas <d...@pragprog.com> wrote: > 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:facets-of-r...@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.
> 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:
> 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=tr... 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.
Peña, Botp wrote: > Dave Thomas [mailto:d...@pragprog.com] wrote: >> "Facets of Ruby" will a a set of small, focussed, and technical >> books about different aspects of Ruby.
> this is a noble idea/task.
Especially the 'Writing Ruby Extensions' part. There still isn't very much material on this subject.
On Fri, Dec 10, 2004 at 10:52:18AM +0900, Dave Thomas scribed:
> 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. ;)
> Using Ruby in Scientific Applications > - Numerical applications > - Analysis > - Data Acquisition > - Control > - Visualization > - Data archiving and retrieval
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 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. ;)
David G. Andersen wrote: > On Fri, Dec 10, 2004 at 10:52:18AM +0900, Dave Thomas scribed:
>>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
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.
> > Using Ruby in Scientific Applications > > - Numerical applications > > - Analysis > > - Data Acquisition > > - Control > > - Visualization > > - Data archiving and retrieval
> - 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 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?
Joel VanderWerf <vj...@PATH.Berkeley.EDU> wrote: > David G. Andersen wrote: > > On Fri, Dec 10, 2004 at 10:52:18AM +0900, Dave Thomas scribed:
> >>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
> 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.
