A couple of months ago I set out to write a book on NoSQL. It's about time I give an update on how it's been going, and when you can expect a book in your hands, or rather, on your screen.

After an initial burst of writing, I took somewhat of a break, so please excuse the delay in general. I spent the last weeks writing (a lot), and I'm currently trying to polish and finish up the existing content so that I can throw something out there for the world to peek at. Currently, the book covers MongoDB, Riak and Redis in varying detail, and I'm working to finish up loose ends to get into a good shape, before I'm starting work on more chapters.

A lot of people have asked me about pricing, distribution model, updates, and so on, so I'm following up with an FAQ section. In general, I'm as keen to get something out there as people have expressed their interest in reading it, believe me.

Turns out though: writing a book is hard. It takes a lot of work, a lot of discipline and creativity to come up with the right words and code examples. I'm not complaining, it's just something you don't realize from writing even slightly longer blog posts. It's still an incredible learning experience too, because I (and you) get to play with pretty much all of the features the databases covered have to offer.

So bear with me, I'm on it.

The book is not built around the idea that a big application is to be built with each database. I'm not a fan of that approach myself, as it makes it too easy to lose track of details. It's full of small examples, focused on specific features.

How many pages does it have?

As the book is still growing, and I'm still playing with layouting details, I can't give you an exact number, but the final book is probably going to have more than 200 pages.

What's the pricing going to be?

I haven't decided yet. It's not going to be in the single digits pricing range, and as the book is pretty dense with content, I don't want to undercharge. I'll keep you posted.

Will there be early access to the book?

Yes, there will be. You'll be able to buy the beta of the book for a reduced price, and follow the updates. Maybe even the commits on GitHub? I don't know. Let me know if that's something you're interested in.

Do you have some samples I can peek at?

Not yet. Layout is still far from final, but I'll throw something out as soon as an early access will be available.

What databases are being covered?

To reach my goal for a final release, I'm covering Redis, MongoDB, CouchDB, Riak, and Cassandra, all in varying detail. For some it makes more sense to go deeper than for others.

Are future updates included?

Yes, as content gets added, typos get fixed, and new databases pop up, I'll send updates to everyone buying the book. The updates are free. Consider buying the book a subscription for more chapters on other databases.

Are you extending the book with more databases over time?

Yes, I have an insatiable thirst to play with more databases, and I don't want to deprive you of experiencing that too.

Are you covering database SomeDB? I hear it's the next big thing!

For now, the list of databases is fixed. What's coming after that, on the other hand, is not. I'm open to suggestions, but I'd prefer some non-exotic over a very domain-specific database you wrote for a recent project. I'll set up some sort of voting when the final release is done.

What formats will be available?

I'm currently working on PDF and ePub, with Kindle to follow. Gotta have my priorities. A good-looking and readable PDF is my first priority, an ePub after that. Buying the book includes access to all formats.

Is there going to be a print edition?

Print is not a priority right now.

What are you using to write and generate the book?

The book is written in Markdown (I hate LaTeX), converted to HTML using Redcarpet, using Albino for syntax-highlighting, and converted to PDF using the awesome Prince XML library, I hope to eventually use DocRaptor to create the final result, as a Prince license is slightly out of budget, but DocRaptor is pretty affordable.

Where can I get updates on progress?

Mostly be following me or the handbook itself on Twitter.

There's a lot of complaining, especially from people coming to Ruby from the Java world, about the lack of a language specification. And while a lot of effort is put into the RubySpec project to at least have a test-driven specification, the written word has been silently ignored for a long time. At least in terms of information technology.

There used to be a book called "Ruby in a Nutshell", written by Matz himself, but it mainly dealt with Ruby 1.6, and is therefore seriously outdated.

David Flanagan (author of several great books on JavaScript and Java) set out to fix that problem. With the help of Matz he dove deep into Ruby and wrote what I can only describe as its only valid written language specification. The result is "The Ruby Programming Language".

The book doesn't take any unusual path when it comes to its structure. It deals with the basic structure of a Ruby program, datatypes and objects, expressions, operators, control flow, methods, procs, lambdas, classes, modules and finally, reflection and metaprogramming.

Whatever you consider part of the Ruby language, you'll be sure to find it in one of those chapters. David manages to get the whole of the language into a mere 300 pages. Both a testament to the compactness of Ruby and David's skill to explain each part as simple as possible.

You'd expect something like a language specification to be boring (if you don't, you obviously haven't read the Java Language Specification or The C++ Programming Language), but I'm happy to report that is not the case. While you shouldn't expect an entertaining read, you can expect to learn all the little details you somehow have not yet grokked about Ruby. The book finally opened my eyes on the difference of proc and lambda. The book ends with a discussion of the core classes of Ruby, including API changes between 1.8 and 1.9.

It is up-to-date with Ruby 1.8, and includes most of the features of Ruby 1.9 including of course, fibers.

My verdict is simple: If you work with Ruby, buy this book. It's pretty much the most complete book on Ruby you'll find. While "The Ruby Way" is an excellent reference "The Ruby Programming Language" is meant as a guide through the language. You can read it once, and get back to it when you need to. And seriously: You should read it. There's very likely some parts of Ruby you haven't worked with in all detail yet. This book does a good job in helping you uncover them.

Disclaimer: O'Reilly provided me with a copy of the book for reviewing purposes. My excitement about it is real.

There are some interesting books on Ruby and Rails related entering the fierce market, let's have a quick look.

The first worth mentioning is "Enterprise Recipes with Ruby and Rails" by Maik Schmidt, author of "Enterprise Integration with Ruby" (also highly recommended). Why should you read it? The book introduction answers that question short and painfully:

"Every web site project is really an enterprise integration project in disguise."

Though it's still in Beta it seems pretty complete already.

The next one is "Refactoring: Ruby Edition". It's not secret that Martin Fowler is a Ruby fan, so he teamed up with Jay Fields to bring the refactoring classic up to par, and port it to Ruby.

After "Design Patterns in Ruby" this is the next classic to be coming to Ruby. If you loved the original "Refactoring" book, this is a must. It's available as a Rough Cut, and is likely to come out in February.

Jenifer Altman did it. She finished the book for our Polaroid project. 25 Polaroid photographers from all over the world say farewell to a piece of photographic history. Here's a sneaky peek at the cover:

The book is available for pre-order, and will ship in the first weeks of July. It's strictly limited to 500 copies, so get it while you can.

Did I mention I'm in it? I can't wait to hold it in my hands, and browse through all the photos.

If you're living in Berlin, there's currently an exhibition on Polaroids called "The Last Ten" at the Bongout showroom.

"Working Effectively With Legacy Code" by Michael C. Feathers starts off with a bang, and probably the best and shortest definition of legacy code: "Legacy code is simply code without tests." I couldn't agree more.

The book is for all of us who have to deal with all kinds of code that is tangled, caught in a web of endless dependencies, or methods and classes that are simply too long, and/or do too much. Of course, said code usually comes along without unit tests. Now there you are, having to add a new feature or fix a bug. Where do you start? What's that scary piece code over there doing? Why is it staring at you?

That's where this book comes in. It's split into three parts. The first will give a general introduction to the subject, introducing the mechanics of change, the need for testing, the seam model and the tools you need.

The second part is where the dirt is thrown right at you. In a style of "I need to do this" or "How can I do that?", this part will shock you to your very core. No, probably not, but it will give you a lot of good advise on how to deal with a particular legacy-type situation. This part is where the book really shines. The examples given might be simple sometimes compared to real-world legacy code, but they give you a very good idea how to handle a particular situation.

In the last part Michael lists techniques for breaking dependencies. I'm not sure if I'd recommend reading these before the second part, but you should be aware that all of these techniques are regularly referenced in the first parts of the book. So be prepared to skim to this part if you need to know what a particular technique is about.

Consider "Working Effectively With Legacy Code" a companion to "Refactoring" by Martin Fowler. And while Fowler's book taught you all about refactoring and the things you can do with it, this book will teach you how to put these things into practice, how to get code untangled, so that you can finally write tests for it, and add those new features.

This book will not solve all your problems, but it will give you an excellent head start, and guide you through the process of handling legacy code. I found this book to be of great value, and I couldn't believe it took me so long to finally read it. Michael Feathers' writing style is most excellent and thankfully, entertaining. Even if you're not having the pleasure of working with legacy code right now, the time will come. You'll be glad to have this book on your side.

I bought a nice stack of books recently, and I'm planning on buying some more. There's a lot of good stuff, not only new books, but also some older books (as in from 2004, I'm not talking about the C++ books on my shelf).

Currently reading:

• Working Effectively with Legacy Code by Michael C. Feathers. An outstanding book, review soon to come.

On the stack (in no particular order):

• Domain-Driven Design
• Practical JRuby on Rails Projects
• Microformats
• Programming Erlang. Not my new favorite thing, but I want to know what all the fuzz is about.
• Enterprise Integration Patterns. 700 pages on messaging and integration, oh my.
• Manage It!

Yet to arrive or to be bought:

• Patterns of Enterprise Application Architecture. Though from 2002 and on some topics maybe slightly outdates it's still a shame I haven't read it yet.
• Deploying Rails Applications. I'm browsing through the beta already. Book due in March.
• The Rails Way
• Design Patterns in Ruby
• Advanced Rails Recipes. Beta PDF already in the browsing process.
• The New PickAxe. Also beta PDF.

Books I'm considering to buy:

• xUnit Test Patterns. More than 800 on refactoring tests. The website already offers a lot of material, but also states that it might've been outdated by the book already.

There's also the occasional novel to be squeezed in. Oh well, lots of stuff to read I reckon. Thank goodness that the weekend is near. Time to read.

I've been a fan and user of continuous integration for quite a while now, yet I've been keen to pick up the book "Continuous Integration: Improving Software Quality and Reducing Risk" by Paul M. Duvall et. al. to see, if it can live up to be the first book dealing exclusively with the topic. They don't have to sell me on the idea anymore, but still, there's always something to learn.

The book is separated into two parts. The first one introduces the basic principles of continuous integration, and how it could/should work for you and your project. For me, this is the valuable part of the book. It introduces what CI can do for you, and the practices usually surrounding a project using CI are. If you didn't know that CI is more than just using CruiseControl or a similar CI server, I suggest you go out and pick up this book right away.

The second part describes five parts of a continuous integration system in detail. It deals with database integration, testing, inspection, deployment and feedback. A collection of recipes accompany each section to help you structure your project, code, configurations to make continuous integration a "non-event", as Martin Fowler put it.

Just as it should, the book emphasizes the importance of a good test suite to really find value in continuous integration. Without each other, continuous integration and testing can't unfold their full potential. The book is full of examples including configurations, code and build scripts, so you're not left standing in the rain, wondering how you can get that continuous integration magic to work for you.

Though I wouldn't say I'm the target audience for it, I still think there's a lot to learn from this book. Say, you just read Martin Fowler's original essay on the topic (which you should, anyway), and want to get more into detail, this book is for you. You'll find a good reference that'll help you introduce continuous integration into your project step by step.

The book focuses a lot on Java and its tools for examples, but you can easily apply the techniques in similar ways for, say Ruby/Rails projects or any other language. Database integration luckily is a topic you don't have to worry about that much in Rails projects.

It ends with a nice collection of tools that can be used for or with continuous integration, and an evaluation of CI servers and automated build tools.

My main gripe with this books is that when it comes to whys the book falls short from time to time. For someone who can make her own conclusions this shouldn't be a problem, but I think there would've been more in it. Two examples:

• The book uses short dialogues to explain how a specific technique would work in a team, or how a line of reasoning could come about. In my opinion they're too short. What they want to emphasize could've just as well been written in a paragraph and would've had the same result. They're missing a bigger picture, and personally, I never had conversations like that.

• The book states on two occasions that continuous integration should happen on the baseline of your project, and seems to imply that using it on branches is not a good idea. Why that is the case it doesn't explain. That the mainline is always the integration point of a project is pretty clear, but why that doesn't mean you can't integrate important branches remains unclear.

What struck me as odd was the constant mentioning of code inspection as part of continuous integration. I value code metrics for what they are (in fact, I used to be a big fan of them), and for what they can tell you about your code base, especially code coverage, but I have mixed feelings about including all of them in an integration build, because I have seen what time waster code metrics can be. But that might just be a matter of personal experience.

All that said, I still think this book is well worth the money, if you want to see what continuous integration can do for you and your project, and how you can apply the principles to your team. Paul M. Duvall did a great job compiling his experiences of applying and using continuous integrations, most of which I also had in one way or the other. In any way, I suggest reading Fowler's article firsthand, since it will give you a big picture about continuous integration, and then you can delve into the glory details with Duvall's book.

The book also has an accompanying website, where you can find a growing stack of videos explaining a lot of the principles of continuous integration in practice. If you're living in Germany, the book is currently on sale at Lehmanns.

Still a classic on the topic is Mike Clark's "Pragmatic Project Automation", one of the first books by the Pragmatic Programmers and, though slightly outdated, still a good reference. This book got me hooked onto the ideas of continuous integration and push-button builds in the first place.

The book market is being swamped with new books. It seems like every day I discover a new announcement for an upcoming book on Ruby or Rails. Let's see what's currently in stock, and what's waiting for us next year.

The first ones to start are, obviously, the Pragmatic Programmers.

• Dave Thomas just announced the third edition of the PickAxe which is currently in beta.

• Earlier this week he announced the beta release of Advanced Rails Recipes.

• Having been postponed the next due to be released is Deploying Rails Applications, written by Ezra Zygmuntowicz and Bruce Tate. It's been in beta for a while, but it got along quite slowly. Supposed to be released in January 2008.

• Rails for PHP Developers. The target audience is quite obvious, though it's not for me.

• FXRuby. Apparently the No. 1 choice for building GUIs with Ruby.

Apparently some of the authors of RSpec are also writing a book about Behavior-Driven Development for them.

Apress quickly became big on the Ruby/Rails bandwagon, and speaking of RSpec, they also have a book on it due in February, though it's not officially in their catalogue yet.

Just recently they put out several books:

• Pro Active Record. I'm still wondering how it's possible to write an entire book on Active Record, but apparently it's possible.

• Practical JRuby on Rails Web 2.0 Projects. I don't fancy the title, but I ordered this book anyway, since it's pretty much the only one on the topic of JRuby.

• Practical Rails Projects. Shows different aspects of Rails by using them in very different project. A nice approach compared to just developing one or two applications over the course of a book.

Upcoming books from Apress:

• Practical Reporting with Ruby on Rails. Reporting, business intelligence, etc.

• Scaling Rails: Building Giant Websites. I'm looking forward to this one, and I hope it won't disappoint.

• Agile Testing with Rails. I'm fond of agile principles and testing, but I'm rather sick of books containing "agile" in their titles, but the contents does look interesting. Written by two guys working for ThoughtWorks who obviously know their stuff.

O'Reilly already put out their share of Ruby and Rails books, but right now the queue looks rather slim.

• Advanced Rails. Seems to cover several topics of Rails that are, well, advanced, covering topics like Meta Programming, REST, developing plug-ins, etc.

• The Ruby Programming Language. Mats itself is writing this one together with David Flanagan (who wrote a lot of books on JavaScript). I'm not sure if it can replace the PickAxe as the most valuable Ruby book for me, but that might just be for strictly melancholic reasons, what with it being my first Ruby book.

Manning has only put out one book on Rails yet, the excellent "Ruby for Rails" by David Black. But they have some interesting stuff in the queue for 2008.

• Ruby in Practice. This could become the mother of books on advanced Ruby topics. The topics include testing, integration, indexing, asychronous messaging and much more.

• Flexible Rails. I can't say much on that topic, but maybe this book will change that. Flex and Rails. Nuff said.

Addison-Wesley recently released kind of the companion book to "The Ruby Way", a most excellent book.

• The Rails Way. Just been released, covers a lot of Rails grounds, from basic to advanced. Should make for a nice desktop reference.

• Design Patterns in Ruby. Though I have mixed feelings about design patterns and their overuse in the Java world, it should be interesting to read about how they can be useful in the Ruby world.

There, lots of new stuff to read for the new year. I'm sure there's more to come, as it naturally happens with a technology on the rise. The downside is that the quality of the books becomes more and more average over time, but there's a lot of talented people writing on these, so hopefully the Ruby/Rails book market will see more and more great books coming out in the near future.