Archive

Posts Tagged ‘book’

Book review: Growing Object-Oriented Software, Guided by Tests

mars 17, 2014 1 commentaire

Not being fully satisfied about my TDD practices, I was reading The Failures of « Intro to TDD », which sums up nicely bits of the uneasiness I’m facing and offers a nice way of handling it. While tweeting about the article, I was once more told to read Growing Object-Oriented Software, Guided by Tests, and so I finally did and here is my feedback on it 🙂

Lire la suite…

Étiquettes : , , , ,

Book Review : Implementing Domain-Driven Design

février 11, 2014 Laisser un commentaire

I had a bit of free time recently (I guess finishing the 15 books of Games of thrones I was given did help as well lol), so I could tackle some books resting on my shelves. Among them, Implementing Domain-Driven Design, by Vaughn Vernon.

Well, first of all, contrary to Mobile First Bootstrap (cf previous review), Implementing Domain-Driven Design is a massive kind of book: about 600 pages. With plenty of code samples. And actually, that’s were, IMHO, the book is a pain: it goes too much into details. I don’t care too much of Spring xml config. Or some coherence API details. Or some REST based communications between parts of the same application (heck, is it really a good idea anyway ?). My mind is set more on akka, and turns out Vaugh Vernon just as well.

The level of details and the lengthy code samples really killed my attention times and times again. It’s a pity. A first the book starts well, Vaugh Vernon does a great job highlighting the usual pitfalls of non Domain Driven Design. It really rings a bell quite a few times. But then, the technical details get in the way, especially for opinionated coder like me. Supposedly immutable value objects without final fields always hurts me. The extensive use of static methods as well (I just remind one « disclaimer » saying it was for the sake of concision, and pretty late in the book).

That’s why, I think, very detailed and framework related code samples are quite a gamble in a « design level book » : if you don’t care too much about the frameworks and some code hurts your eyes, you tend to forget about the design level stuff.

It wasn’t all bad, for sure. It was nice to go through, again, the ideas contained in Domain-Driven Design: Tackling Complexity in the Heart of Software (I wrote a review on it in 2010, here). Some refreshers were really welcomed.

Another aspect which disappointed me was a feeling of a lack of « hands on » feedbacks, of first hands experiences/insight. When reading Uddi Dahan, for example, there were plenty of times where I thought « yes, that’s the issue, he nailed it ». It almost didn’t happen on Implementing Domain-Driven Design. Maybe the burden of detailing Spring and the others chosen stacks killed the « light revealing » feedbacks, the perls of wisdoms which really help one progress. Maybe, as well, I’m biased there: I’ve read a lot on the matter, played with akka persistence, helped Uwe creating his homegrown CQRS framework (still unpublished by the way, isn’t it mate ?). And I’ve plenty of design/implementation related questions in mind which haven’t found their answers yet, but maybe only walking the path would provide them. Yet, nothing about handling eventually consistency in the user interface in the book for example, despite it being quickly an issue, potentially at least, in event driven systems. What if events change over time, how to handle such changes in the event store ?

So, to sum up, if you’re planning to use Spring and some RESTish stuff, the details could be a real enhancement of the book. Otherwise, like me, I fear they risk to wear you off quickly, killing the interest of the book. Furthermore, if you’re a lot into event driven/CQRS and the like, these parts aren’t handled with too much details, more as an overview, which might disappoint as well.

Well, I feel a bit hard. I hope I’m not unfair and that my disappointment doesn’t make me harsh. If you think so, let me know…

Étiquettes : , , ,

Book review : Mobile First Bootstrap

février 11, 2014 1 commentaire

The other day, I was trying to grab a free copy of Getting Started with Twitter Flight, but instead I got a choice among a few titles and settled for Mobile First Bootstrap. Why is that ? Well, I’m mostly a Java developer, and there is no plan yet to move our 10 years old web app to something recent, but still I’m willing to keep an eye on Mobile First and the like, so I gave Mobile First Bootstrap a try.

In short, with my limited daily use of html and mobile related web apps, it was really instructive. The book does a lot to present the differences between desktop and mobile and provides helpful ways of solving them both. Well, actually, turns out the help comes from the third version of Bootstrap, but still, the overview and the solutions presented are interesting. For example, the way Bootstrap components display differently depending on the resolution is really impressive. And it’s not something straightforward to get by just looking at the github project, as I did before.

I like as well the way tools and useful libraries are covered… My coworkers already had some samples of it. IMHO it’s a part which is always bit tricky to get purely online (which tools, which libraries to go to for what), so I really appreciate.

However, I feel some parts would have deserved a deeper coverage, especially the bit about touch enhancement through jquery mobile, which then interacts with Bootstrap own’s JavaScript. If ever I want to go more into this direction, I would have to dig around significantly: the book doesn’t provide enough leads, IMHO, which it does for the rest.

In terms of target audience, I guess people already pretty familiar with Bootstrap would already know most of the content of the book. Neither does the book contain any extra hint on how to make the latest crazy hot design magic.

In the end, a book worth reading, putting my web design knowledge on a better foot. Exactly what I wanted !

Étiquettes : , , , , ,

IT employers: have your staff buy IT books!

mars 31, 2011 1 commentaire

Well, all is in the title…

Still, it really matters. Not all software developers can be self taught. Neither do they all necessarily like everything they work with. Neither is it always possible for all software developers to buy 3 books a quarter.

I don’t really know if I’ve to go over all the advantages of books… Quickly said, I guess just clicking on the book tag on the right here should provide most of the answers and make obvious the added values of books.

And there are some less obvious advantages, more « work wise » ones:

  • books fit very well with one of our modern time habits: commuting. Really: it makes self improvement possible for people having almost no other free time in the day.
  • books which wouldn’t have been necessarily bought end up being read and useful… Crazy 😉
  • overall quality of the staff work is bound to rise. Which generally improves employees self esteem and work satisfaction.
  • the whole staff feels valued and grateful, for something like a few hundred bucks per quarter (200€ can already buy quite some books !). Way less than a pay rise. And most likely it can be reduced from some taxes. So the cost is really low.

All of this post might seem obvious for some or even most of the readers, I really don’t know.

However, for me, this wasn’t the case: my current employer is the first one to have a « book budget » which can be spend on any IT book. It doesn’t have to be strictly work related, IT related is enough. It doesn’t have to fit why what the boss would currently read. No, it just has to please one of us. And, for sure, if the book is good, other might well end up reading it as well, or at least being directed to it when having related questions. Really great and helpful.

The freedom we’re granted there is, I think, fundamental to the whole story. It’s again on the « self empowerment » side of the story. Team members aren’t irresponsible subordinates, no, they have (loosely coupled) work related interests which matters enough the company. Very nice isn’t it?

That was lurking in my mind since a while, it’s now out, I can go back to normal life 😉

++

Étiquettes : , , ,

Book: Patterns of Enterprise Application Architecture

I have a hate/love relationship with IT books. Really. On one hand, I love to read them. On the other, when they’re good enough, I feel compelled to blog about them. And it bugs me so much I’ve to do it before being totally free for some other books. As such, let’s speak of Patterns of Enterprise Application Architecture, by Martin Fowler.

As said in the title, the book is all about enterprise patterns and actually does it very well. Indeed, crazily enough, there’s more in IT than just the Gang of Four patterns… Stuff like optimistic (offline) locking, the Active Record pattern, Gateway and way more.

The book is divided in 2 parts: first Martin walks over what he calls « The Narratives ». There the stage is set, and the general issues are introduced for the reader to get a proper overview and understanding. Layering, mapping aspects, transactions isolation levels, ACID implications, session, remoting… All these concepts are nicely put together.

Then each pattern is seen in details: how it works, when to use it and some examples (mostly in Java, but C# and maybe some others are also covered). The presentations are well done, presenting pros and cons as well as the various way to implement each of the patterns.

The book shows hardly its age, having been written in 2002. For example, Dependency Injection isn’t spoken of. Similarly, at the time, XML was fancy, so Martin Fowler speaks of it several times, which is funny in retrospective. Still, most of the patterns are still relevant and are important to know, so it doesn’t matter.

In the end, I wish I had read this book (or learned its content) when doing my Computer Science Degree. Indeed, since, I’ve come to know them, but it’s really because I’m interested in the topic. Yet they are of the uttermost importance for anyone in the field. They should be basic knowledge, in order to have a better understanding of the problems at hand, communicate properly between practitioners of the art and not reinventing the wheel .

Furthermore, the extensive coverage of the book should still teach some stuff to most of us.

For example, Kent Beck at some point speaks of remote computing, saying that remote interfaces tend to be coarse grained, whereas local ones are fine grained. Indeed, when going over the network one wants to have as few calls as possible, whereas locally one wants clear intentions and fine control. While obvious, I wasn’t so aware that one interface would be at pain to serve both purposes.

I also loved Martin Fowler First Law of Distributed Object Design: Don’t distribute your objects!

Still, I’m only scratching the surface of this 500+ pages. Martin Fowler was nice enough to provide an online Catalog of Patterns of Enterprise Application Architecture, which should help to get a better view of the book’s content. Since the book publication, a new pattern was also made available online, the Domain Event concept, which is worth looking at.

One more thing: the book is part of the « Martin Fowler Signature Book » series, and thus has a proper hard cover and a nice red bookmark fabric. Cosy and very useful 🙂

To sum up, very nice book to get quite some overview of the general concepts at play in enterprise architecture. Almost a must read actually.

I stop here otherwise I fear I’ll write more than there’s in the book 😉

++

Book: Implementations Patterns

In Implementations Patterns, Kent Beck focuses on « low level » advices. It’s all about how to write nice, readable and maintainable code.

Such a narrow focus is good and provides a nice occasion to think on one own’s habits.The extensive thinking put down in the book quite often put words on feelings/intuitions one can have while coding. It makes them explicit/obvious and helps to think more rationally about them. It also put new light on different aspects, widening the comprehension.

The chapter « Theory of Programming » is also pretty nice, esp. when addressing flexibility. Indeed, flexibility is about being able to change easily the code, not providing the user with hooks all over the place to change everything in the software. Insisting on code readability is also always welcomed and well put in perspective. It somehow managed to feel more convincing than previous readings I had on the topic.

Yet it isn’t all nice in Implementations Patterns. The term pattern feels often overstretched. Kent Beck is mainly just browsing through the available options in Java and discussing their pro and cons. Sometimes it feels obvious and a bit overdone.

The chapter on collection performance feels also a bit like « space filling » rather than helping achieving the book goal. A nasty voice inside of me can’t help noticing that for a 129pages yet 45$ book, it’s comprehensible…

A point has also really surprised me: Kent Beck speaks of final fields and says he usually doesn’t bother writing the final keyword. He would only if his code would be changed by many people. Not only it’s contradict his main motto of communication to the readers, but it’s actually a big hole in the class, both in terms of performance and maintenance… Crazy it managed to go through the editing process IMHO.

To conclude, the book is helpful and hopefully my coworkers will appreciate its effects on my code. I’ve more tools/knowledge/options to write readable code, I just have to make good use of them by now… Is it a must read ? Dunno. Maybe I start to have read quite a bunch of such books to have a feeling of « deja vu ». Surely as well I’m getting older. Anyway, it was a good read, I recommend it. Whether it’s a must read is left to the reader as an exercise 😉

Side note: for a deeper look at the book content, there’s this infoq review Book Review: Implementation Patterns which shows it well.

Étiquettes : , , ,

Book: Domain Driven Design

octobre 1, 2010 1 commentaire

When I first started to work, I knew I was doing crap. Yep, really. We were using old stuff, copy/pasting heavily, editing config files by hand before deploying in production and so on. However, knowing you do crap doesn’t help you doing right, even if you had the occasion.

As time went by, however, I was lucky enough to work with real Software Developers, craftsmen as we would say today, learning a lot on the way.

Yet, even these bright guys were sometimes uneasy. Not on technical stuff, not on infrastructure, but, well, you know, on the classes and the like you’ve to do for your customer. How shall we split the different parts of the requirements? What should be top level code or just « code that works », intended not to be touched more afterwards. To which extend shall we integrate what’s the business requires, or shall we adapt it a bit to our stuff ?

Yet, these foggy stuff are the value of an application. Customers don’t care too much about how nice your XML described UI is. Nor does he care too much about maven and the like. He cares about these (often messy) code doing what he asked for. The code which enables dealership to get their good in time. The code which triggers automatically some buy on some mutual funds. The code which allows to display the breaking news. The user’s code. And on top of that, whatever the nice technical layers around, if the users’ domain is badly understood and/or translated into code, then it’ll be a mess and massive pain to work with.

Domain Driven Design is all about this code which actually is, or at least should be, the heart of your application. This « domain » code is where the real value is. Ṫhe book makes the obvious visible again: the domain, the users’ stuff, is what matters. Even better, the books describes plenty of means to handle this part of your application, from quite low lever to high ones. How to handle large domain. How to refactor towards greater insight (a chapter title actually). It even has a chapter called Strategic Design, speaking about how to handle these different domains which always coexist, and how to make the best of them. Most important of all, the books is all about the UBIQUITOUS LANGUAGE.

The uppercase is not mistake: the UBIQUITOUS LANGUAGE is what allows users and developers to understand each other effectively and over time. It matters. The UBIQUITOUS LANGUAGE deserves its uppercase. And by doing so constantly in the book, with the core concepts, Eric Evans makes it obvious what matters or not. After reading the book all these big uppercase words will stick to your mind with ease. ANTI CORRUPTION LAYER. REPOSITORIES. BOUNDED CONTEXT. They’re all still there 🙂

To tell more about the UBIQUITOUS LANGUAGE, it’s the language used to describe the domain, both by the users and the developers. It is should be reflected in the code. And, of the highest importance, is should evolve with the comprehension of the needs. This is the domain. This is the added value of your work. Eric Evans takes care of showing ways to handle this UBIQUITOUS LANGUAGE and make it pervasive and effective. His examples are clearly first hand ones, which smell and look like what you could expect tomorrow (or on Monday rather lol). No big word on SOA or Agile Manifesto. No, just how to make your users needs properly fulfilled. On top of that, the author speaks of organization at the code level and higher ones (like what to do with big blobs of codes or legacy systems). This uncommon « elevation » is very nice and helpful. Speaking of more than the GOF patterns as a way to make your code base intelligible is very nice. In fact, the book’s title second part « Tackling Complexity in the Heart of Software », is true and right to the topic.

I guess you got it, I liked this book. It makes you think and ponder often, on your current practices and on « industry wide » ones. Like the habit of affecting the best developers to the infrastructure teams. Common isn’t it ? These top notch guys can then develop some stack able to solve both desktops and web needs, transparently and recursively. Sounds all good, but is this what your users want ? They want their needs fulfilled, they want their reality to be tackled. And whatever your bells and whistles, if you can’t move stuff Y to point 1243, it’s no help.

Well, I fear I’m too verbose. By the way, the book is quite verbose as well. More than 500 pages and extensive texts. Reading it took quite some time, even if I liked it. It was just big, both in volume of text and on impact of its content. But it didn’t go in the way, apart that at the end I was wondering about stuff explain at the beginning. But then, no big deal: for sure I’ll read it again.

To kind of conclude, this book is the last bit of theory I was missing towards making great software, in the long run, in a sustainable way, for the users. It has already changed the way I approach design and it looks like my users felt and liked it already.

I already said too much: I’m off !

++
joseph

Étiquettes : , , , ,
%d blogueurs aiment cette page :