"ZeroMQ: Messaging for Many Application" by Peter Hintjens; O'Reilly Media;

Building Distributed Systems and Communities

I was pleasantly surprised by this book. I came in expecting to learn about the magic of ZeroMQ, and I came out knowing not only more about ZeroMQ itself, but also distributed systems and community building.

The first chapter primes the rest of the text, preparing the reader to not only learn more about the world of distributed computing, but also begins instilling a certain excitement about how things could be so much easier, and how ZeroMQ enables this. This is surprising, as very few technical texts manage to become page-turners so quickly.

The next four chapters are a deep dive into ZeroMQ (and distributed systems) best practices. Heartbeats, publish/subscribe, request/reply, round-robin task distribution, and then composing all of these patterns and more. It's a collection of best practices without seeming like a dictionary. I could spend a few months practicing and studying these best practices and I'd feel like I knew more about how to build reliable systems.

The last half of the book is all about how to build communities and processes that last. Building distributed systems requires effective communication. There's a wealth of knowledge in the last portion of the book about how to enable that. Some great advice includes:

- separate maintainers from contributors
- use Github (which can be interpreted as: make issue tracking, persistent comments, and code review *really* easy)

A good chunk of the community building advice is available as the ZMQ C4 guide. It's elaborated on much more deeply in this book, which I appreciate. C4 is the contract; this book is the rationale.

If you're interested in or need to build a system that's highly concurrent, has high reliability and/or performance requirements, and even if you can't use ZMQ to build said system, get this book anyway. You'll learn a lot in the process that you can apply to making network (and team) communication much more effective.

Sarah Mei. The Insufficiency of Good Design. Ruby Conf 2012.

Link:https://www.youtube.com/watch?v=UgrVdHYEZGg

Watch this at some point. If you work with people, even if you're not in the software development industry, you'll benefit from the ideas shared in this video.

I learned about this video today from a colleague. It turns out there's a lot of wisdom in it. It actually surprised me quite a few times. According to the video, which in turn cites a Carnegie Mellon University study conducted in 2007, the best predictor of quality in code is...

Good Communication

This trumps technical qualifications and domain-specific knowledge. I tried hard to find the exact paper Sarah spoke of, but the closest I could come to that study was this article published in 1999. As a side note, many of the papers listed on the parent page are very interesting from an organizational point of view. *bookmarked*

Before I go further, allow me to quote Conway's Law:

Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure.

Studies seem to indicate that this is real, real as in take a look at projects you've worked on and see for yourself real.

So given that Conway's Law is something that is affecting you right now, it means that you can actually debug your communication patterns. This was one of the surprising points Sarah brought up. It turns out that by reflecting on code that's been written, and "code smells" that keep coming up, you can determine missing links in communication. You could continue to solve those code smells. You could refactor them all away - once per sprint even! However, that's only addressing the symptoms. The underlying problem is more likely to be one of communication, and if you address that, it should follow that the anti-pattern in the code should go away. A lot of conjecture here - take home experiments?

To sum it up:

Every piece of bad code is trying to tell you something

It's up to you to listen. 

"21st Century C" by Ben Klemens; O'Reilly Media;

Disclaimer: I've received this book as a part of the O'Reilly Blogger Review Program.

In 21st Century C, Ben Klemens sets out to show you how much C has changed over the past two decades. Promising to show you how to make the most of modern C, he takes on a tour of the language, including features added by recent standards, and also indicates what features we should stop using.



Verdict: [||||||    ] (6 out of 10)

tl;dr - I wouldn't recommend this book in general. If you're looking for idiomatic C, and you're experienced enough with C to know what works and what doesn't, and are able to make judgment on a case-by-case basis with regards to the author's advice, you might be able to find a few interesting gems in here.

For the reader interested in a more detailed review:

I found Klemens' writing to be entertaining. The references to punk rock became a little groan-inducing after some time, but groans are better than snores - I wasn't put to sleep by the writing. His character definitely shows through his writing. I appreciate this, as all too many text books suffer from the formalism-first problem. Readers are humans, and Klemens addresses this well.

The tour of C history was also very interesting. The coverage of C from inception up to the latest standard (C11) and how things have changed since then was especially valuable to me. I even appreciated the mild coverage that was given regarding C on Windows, where C really seems to be an afterthought.

One more good point before I jump into the criticisms - the chapter covering pointer semantics was solid. Klemens explains how to use them, several of the associated gotchas, and what to look out for. Succinct, clear, and full of examples.

Things are not so bright every where in the book. One particular section that concerned me, was in Chapter 1: The Unified Header. Klemens contends that every project should use an "allheaders.h" because "Your compiler doesn't think 2,400 lines is a big deal any more, and this compiles in under a second". While I agree that compilation speed won't be a problem, the unified header approach has a few problems that are more troublesome for long-term maintenance. First and foremost, since C has very limited support for name-spacing, it'll be very difficult to new comers to your C library to determine where each imported function and structure comes from. When time to refactor comes along, it'll be more likely that the refactoring process will be difficult if the reader follows this unified header approach than if they made more clear separation of their modules by purpose, relationship, and abstraction level.

I leave you with this final note - one of the strengths of this book is that it is very opinionated. Unfortunately, this is also this book's greatest weakness. Take every claim made within with a grain of salt and you should emerge wiser.

"Python Cookbook (2013)" by David Beazley, Brian K. Jones; O'Reilly Media;

I recently purchased the Python Cookbook. The opinions below are all mine. This wasn't a gift, or an item gifted to me for review purposes - I really wanted this book!

Read more below to see why.

Python 3: The Power is Yours!

This book is an amazing resource for making the most of Python 3. This book truly makes it apparent what you're missing out on in the land of Python 2 and shows what can be accomplished more concisely in Python 3.

For example, as early as chapter 1, you're introduced to advanced unpacking techniques introduced in Python 3:

head, *tail = elems

The equivalent in Python 2 is:

head, tail = elems[0], elems[1:]

The chapter on generators and iterations techniques alone is worth the price of this book. It shows you how to "Loop Like a Native", all the way through using partial function application combined with lambdas to lazily loop over the contents of a file, ending when there's nothing left to read. Elegant!

There's more gems here, but I'll leave them for you to discover. The authors did a wonderful job of putting this book together, and I highly recommend this to anyone interested in becoming an effective Pythonista!

A Dry Spell, Some New Books

It's been awhile, readers. Sometimes things get so busy that finding the time to write a few sentences seems like more than I can afford! Here's a few quick points:

Joy of Clojure 2e: I reviewed this while it was still in early release format. It looks like a pretty solid book. I feel like I would've gotten more out of it if I had more experience with the JVM platform and Lisps overall.

New:

• ZeroMQ, O'Reilly Media: It looks like a very promising read. The technology has been around for awhile, and I've seen it come up more than once in casual technical discussion. I grabbed a copy of the book and I'll be reading up on it soon.
• Clojure Programming, O'Reilly Media: Lisps continue to elude me, and I thought I'd dive in with this O'Reilly publication. Having been published very recently, and having received rather high reviews, I'm excited to see what this will teach me, especially with how meta-programmable I've heard Lisps can be.

'til next time - happy reading!