Tardate 2016

[フレーム]

If I had to pick two..

Design Patterns in Ruby by Russ Olsen is the first technical book in a very long time that I have enjoyed reading from cover to cover.

It's more than just a naïve translation of the classic GoF patterns. Olsen manages the dual trick of not only demonstrating how the classic patterns can still be relevant in Ruby, but how to approach them with the full power of ruby at your disposal.

I liked the way that Olsen avoided doing bare minimum implementations. So when looking at the Composite pattern, he spruces things up with a little operator overloading. And where ruby affords a number of possible approaches, these get discussed and compared (like with the Decorator pattern).

The final chapters in the book present a few additional patterns that go beyond the GoF and are particularly topical and relevant for ruby: DSLs, meta-programming, and convention over configuration.

In short, Design Patterns in Ruby is a grand tour, an effective tutorial in a selection of ruby practices, and ultimately a very enjoyable, rewarding, and sometimes even funny book to read.


[フレーム]The second book I'd stowaway with is Ruby Best Practices by Gregory Brown.

It doesn't pretend to be encyclopedic in the manner of The Ruby Way. However, where sometimes I find The Ruby Way curtails topics just when they start to get interesting, Brown dives deep with Ruby Best Practices.

Clear examples are accompanied by thoughtful and full treatments of the subject at hand. It has particularly useful focus on "Mastering the Dynamic Toolkit", "Text Processing", "Functional Programming Techniques", and "Designing Beautiful APIs".

So they're my picks. Now, obviously these are not ideal books for learning ruby from scratch, but once you're past the basics these are the two at the top of my pile;-)

Anyone willing to counter with their top two picks? Agree or disagree with my choice?


Soundtrack for this post: I Like Your Old Stuff Better than Your New Stuff - Regurgitator from the album Unit Re-Booted

I was pleasantly surprised; this is a great little book for stimulating some thinking around the role of an architect for the advanced reader. But I worry that it attempts to position itself as "An Introduction". A novice, unprepared to read the text critically, may easily be mislead by the book's definitive statements about what a software architect is and what they do.

Personally, I believe the book is fundamentally flawed in three important aspects:

1. Are we really in Crisis because we lack a Software Architecture Profession?

Firstly, the premise that today's Crisis in Software -

[the] parade of failures and half-failures that has grown over the years as a result of a world without an established profession of software architecture

- is wholly unsupported by any direct evidence. The authors' central argument is flawed by asserting an apparent causal relationship when in fact only coincidence had been established beyond doubt. A number of well-known software runaways and failures are mentioned, but I don't know of any where the original case studies attributed the failure primarily to the lack of "an established profession of software architecture". The authors get around this problem by redefining the conclusions and suggesting that all faults may eventually be explained by architecture. It seems to me self-serving and circular.

2. A Flawed Analogy with Building Construction

Second, the authors attempt to reinforce their argument with the proposition that the analogy with building architecture is self-evident. Buildings need architects. Software is like building. Therefore software needs architects. Hmmm. I am reminded of Bernard Rudofsky's book "The Prodigious Builders" which celebrates the history of vernacular architecture. That is, architecture without Architects (unfortunately a stunningly boring book for what ought to be a highly inspirational subject).

I particularly disagree with the authors' contention that software is not developed: it is built (with a sense of finality). The Google-inspired trend towards the perpetual beta is the most visible evidence to the contrary. The authors object to the notion that to develop implies to unfold, uncover, and make known. On the contrary, I find this a most apt description of what we do within the software profession: the youth and continuing innovation within the field does mean that software development and the architecture it requires is more akin to exploration, invention and discovery than to a formalised application of the tried and true.

Strike two.

3. Premature Specialisation

I began to renew my hope for the book as it explored the historical foundations of architecture. Michelangelo can truly lay claim to the title of Architect ("master builder"); his work on St Peter's Basilica epitomizes the unltimate balance between function, beauty, and structure,

Vitruvius is famous for asserting in his book De architectura circa 50BC that a structure must exhibit the three qualities of firmitas, utilitas, venustas — that is, it must be strong or durable, useful, and beautiful. A sense of proportion and harmony is represented in Leonardo Da Vinci's famous illustration of Vitruvian Man.

Such ideas begin to shape the conventional definition of an architect. A master who not only understands structure, utility, and beauty in order to successfully render a design into plans, but has the practical experience to supervise their realisation through construction.

At this point, I think the authors are getting onto the right track. However they stumble at the last post by then inexplicably turning this into an argument for a limited and specialised concept of a "Software Architecture Profession", where the architect only retains responsibility for venustas (design/beauty). Utilitas (function/utility) is the client's problem, and firmitas (form, materials, logistics) is the province of the engineers, scientists and code monkeys.

Time for the Renaissance?

The authors' call for the codification and ossification of a software architecture practice is I think at least 50 years premature.

What an "Architect" needs to be concerned with is still going through successive waves of tumultuous change. Up to the green-screen era, computer system architecture necessarily had a strong hardware component. Come the GUIs and increasing processing power in the 90s, it seemed a singular focus on "software architecture" as a technical discipline was a valid vocation. Now the waves of web-driven innovation and the emergence of the "Rich Internet Application" is again challenging our notions of what architecture entails. And again, the "real world" is encroaching the pure software realm with the rise of increasingly powerful and widely available mobile computing platforms (think iPhone, Android), and the revolution in pervasive automation (think Arduino).

I think the Java Posse were spot on when they discussed the growing need for cross-fertilisation and collaboration between designers and developers on podcast #247 - Design and Engineering. This is a time of divergence, not convergence, in the business of producing software & technology-based systems.

In truth, I question how appropriate both words are in the term "Software Architect":

• Software - it is perhaps only in the last 10-20 years that it has been possible to construct computer software at the level of complexity that warrants the existence of an architect in the classical sense. And I suspect that in another 10 years it will seem ludicrous to suggest that you can be an Architect of only software ("just a turn-of-the-century fad"). Software is just one component of a "built environment" that encompasses everything from the information infrastructure and systems technology to the psychology, art and design of human interaction; ultimately leading to a desired collaboration between people and machines in the context of real-world objectives.
  
• Architect - the common use of the term in the computing field has stripped this word of it's more noble dimensions. No longer is the architect "the person with the vision and skill to make dreams a reality". They are more likely to be the person in the corner who produces nothing but paper, leaves no fingerprints on the pages of history, and is generally ignored by those who are really making things happen.

I don't know what you should call the people who have the experience and ability to lead others to do amazing things with the information technology we have at our disposal.

I'm just pretty sure that "Software Architect" doesn't even come close to being adequate. And building a "profession" around a woefully inadequate definition is a one-way ticket to irrelevance and obscurity.

I've fallen in love with bookjetty, a great new site for books by Herryanto Siatono.

Although my It's a Prata Life blog is officially dedicated to prata (and always will be!), I also use it to keep a diary of the books I'm reading. I probably always will, but I do make sure to try out all the "book tracking" sites, facebook apps and so on that I come across.

None have really jiggled my worm until I discovered bookjetty.

The killer feature for me is the great library integration on the site. It helps answer all the usual questions I have whenever I hear about a new book..

• Have I already got it or read it before?


• Does one of my friends have it? Maybe I can borrow it..


• Can I get it from the local library?


• Can I buy it online?


• (oh, and if the last two steps fail, I may actually visit a real bookstore!)

The library catalogue checks work a treat - right within your booklist. I used this feature yesterday as I knew I would be heading to the library. Within 5 minutes on bookjetty I had added a few books I'd been interested in reading and found out that 3 of them were available and on the shelf at my local library. An hour later, I had them checked out.

The bookjetty developer(s?) have done a great job of integrating the libraries, especially considering that most are still running archaic web 0.1 systems which are not very mashup friendly. I've posted before about a kludge to do library lookups from an amazon page, but it never works very reliably because of the dumb library catalogue it needs to talk to, so I can appreciate some of the challenges they may have had.

And here's an example of how the library checks appear...


If you are into books, I heartily recommend you go and register at bookjetty and check it out!

As I studied the authors' recipe for profitable community-building I found myself challenging the principle that success requires an imposition of control by an organisation: the company studies the market, decides what community should be built, writes a business case for it, and appoints the expert team to design, build, launch, and market the community.

This is an astonishing proposition given the book's initial premise:

The rise of virtual communities .. has set in motion an unprecedented shift in power from vendors of goods and services to the customers who buy them.

"Over my dead body!" I can hear the voices echoing from the boardroom - undoubtedly the prime audience for this book, which I think could reasonably be subtitled "how to (try) and make the new economy work like the old one".

The idea of a "community" that is both external to the organisation while remaining under its control permeates the book, and is perhaps the primary misconception that has taken the past 10 years to rethink and recognise for the oxymoron that it is.

This is closely related to the fundamental yet unspoken assumption of a hard boundary between the corporation and the customer/community. In parts of the book that consider the use of communities within the corporation, the emphasis is very much on within the corporation, or at most, between business partners.

My comments have been a little disparaging, and it is perhaps unfair to find fault in failing to predict the future accurately. It does mean that this book is now little more than a historical curiosity.

However, the book I would be very interested to read is a "10th anniversary rewrite". For my money, I'd say that's Wikinomics: How Mass Collaboration Changes Everything (any other recommendations? I'm keen to hear..)

For now, I think I'll let Geek and Poke have the last word...

Geek and Poke


Originally posted on It's a Prata Life