Book review: The 5 Dysfunctions of a team

This is a spur-of-the-moment review of The 5 Dysfunctions of a Team, a business novel on team health that I've read today as part of the quarterly Professional Development Days I take as part of working at eLife.

As a follow-up to my role evolution into Software Engineer in Tools and Infrastructure, I am looking again more into the people skills side of my job (as opposed to purely technical skills). I have done this cyclically during my career, as the coder hat becomes too restrictive and you have to pick up other tools to achieve improvement. In particular, I am working on eLife's Continuous Delivery platform and it is crucial to work with multiple product-oriented teams to have them adopt your latest Jenkins pipelines and Github reports.

Dysfunctions

Patrick Lencioni's model of team dysfunctions (or of blessed behaviors if you flip all definitions) is a pyramid where each dysfunction prevents the next level from being reached. It would be a disservice to how well and quickly this is got across in the novel to just try to list them here, but if I had to summarize this in a long paragraph it would look like:

Building trust between team members allows constructive conflicts, which enable people to commit to action and hold each other accountable for what has been decided; all in the service of results. -- not really a quote

The dysfunctions are the flip side of these positive behaviors, for example lack of trust or fear of conflict. The definitions of some of these terms are more precise than what you find in many Agile and business coaching books; so don't dismiss trust as just a buzzword, for example.

Some context

The case being treated in the book, which comes from the author's management consulting firm, is that of a CEO turning around a team of executives. This makes for a somewhat more fascinating view of results as it's talking about a (fictional) company's IPO or eventual bankruptcy. Despite not being a clear parallel to a software development team, I do think this is applicable in every situation where professionals are paid to work daily together, with some caveats.
In fact, I suspect the level of commitment to the job that you see in the book would be typical of either high stakes roles (executives) or a generally healthy organization that has already removed common dysfunctions at the individual level. If in your organization:

• people are primarily motivated by money
• they look forward to 5 PM
• they browse Facebook and Twitter for hours each day

then there are personal motives that have to be addressed before teams can start thinking about collective health.

Yes but, what can I do in practice?

After the narrative part, an addendum to the book contains a self-administered test to zoom in on which possible dysfunctions your team may exhibit at the moment. It continues with a series of exercises and practices that address these topics, with an estimation of their time commitments or how difficult they would be to run. I definitely look forward to anonymously try out the test with my technical team, out of curiosity for other views.

My conclusions

I think most of the dysfunctions are real patterns, that can only be exacerbated by the currently distorted market for software developers and CV-driven development. The last dysfunction, Inattention to results, is worth many books on its own on how to define those results as employees at all levels are known for optimizing around measurable goals to the detriment of, for example, long-term maintenance and quality.
So don't start a crusade armed by this little book, but definitely keep this model in your toolbox and share it with your team to see if you can all identify areas for collective improvement; it is painfully obvious to say you can't work on this alone!
The author is certainly right when writing that groups of people truly working together can accomplish what any assembly of single individuals could never dream of doing.

Book review: Production-ready microservices

Production-Ready Microservices is a short book about consistently practicing architecture and design over a fleet of microservices.
In general, I think the principles described here apply very much to any service-oriented initiative, even more so if the services are coarse grained and hence require more maintenance than finely isolated ones.

Uber

The book extrapolates from the author's experience at Uber "standardizing over a thousand microservices". Given a few developers for each microservice team, that makes up 2000-3000 engineers from the total >10000 Uber employees (I wonder how many are lawyers). After WhatsApp's famous story of being acquired at 55 employees in total, that really highlights the difficulty level of running a business and operations all over the physical world (sending cars and drivers around in dozens of countries) with respect to a digital-only enterprise. We should remember this and many other directions of change the next time we hear a technology advocate saying how much the cost of his 2-people startup has been reduced by $technology.

The main message

You should be this tall to use microservices; this architecture doesn't necessarily fit every context; although integrating separate services of some size is becoming a standard after the API revolution (before that, it was integrate through the database which is arguable worse).
You will encounter many different social and technical problems, such as:

• Inverse Conway's Law, with the shape of the products defining the shape of the company. Although I found out this doesn't really apply at smaller scales as development teams can own more than one service and experience a successful decoupling between people and code.
• Technical sprawl, where multiple languages, databases and other key choices spread without a consistent, central planning.
• More ways to fail: distributed and concurrent systems are more difficult to work with and to reason upon, plus the fact that there are more servers, containers or applications will simply multiply the failures you'll see.

There are lots of non-functional requirements like scaling each microservice and isolating it from the rest of the fleet; perhaps don't go too micro- if you don't have the resources to ensure an acceptable level in each service. Perhaps in your context the acceptable SLA for some particular service is low, because it's not change often or is only internally facing or is only used several times per day.
One particular aspect of the Consistency is important lesson is that the whole lifecycle of services should be considered. Maintenance and even decomissioning are as important as producing new MVPs: but I've seen many times services being neglected, or being considered very easy to migrate away from one some new shiny substitute was available. In reality, it takes time and effort to keep services up and running, and to finally kill them when you have an alternative, as data and users are slowly migrated off from the old to the new platform.
Lots of requirements are also overlooked but often turn out to be important as you increase your population of services: the scalability of a single endpoint, fault tolerance, even documentation (ADR are the only form I trust very much right now in a fast-moving organization context.) Every single section of this book will make you think about it, but won't give much of an overview: you're better served by reading the SRE book for example.

Value for money

This book is a short read which gives you an overview of what microservices challenges you're likely to face down that rabbit hole; in particular, it focuses on a medium-to-large organization context. I'm not sure this book is worth the price tag however: 20 pounds for a Kindle edition of ~170 pages, where ~25 pages are glossary, index and lots of checklists.

Book review: Algorithms to live by

Algorithms to Live By: The Computer Science of Human Decisions is a book that puts together the domains of computer science and real life. The ensemble of topics being touched is wide. The book treats deterministic algorithms such as optimal sorting, but then moves on to more context-dependent strategies for caching and scheduling. The last chapter even get to model identification, (tractable and intractable-made-tractable) optimization problems, stochastic algorithms and game theory.

All the while, computer science concepts are compared to conscious and unconscious human processes. For example, caching and the memory hierarchy have great parallels with how the human brain recollects memories of recent events, and how we can augment our brain with external, slower supports like paper. Scheduling is useful not only to allocate processes on CPU cores, but also to make an explicit choice of strategy when prioritizing the tasks that you or your team face. Up to the more extreme examples of game theory and mechanism design, when the incentive system becomes more important than the individual agents (manage the system, not the people rings a bell?)

If you like viewing the world throughout the lens of algorithms and see how the strategies of humans and computer compare with each other, I would strongly recommend this book as it will make for an entertaining read and some principles to take away for real life usage (I hope sorting socks will be easier now). Skip it if you have a very wide knowledge of computer science, operations research, Nash equilibria... but even if I was familiar with the technical part, I was missing the connection to different domains or everyday, real world problems. I listened to the audiobook version, which lasts about 12 hours. You may find it easier to skim through some chapters if you are more (or less) interested in some topics. The problem with audiobooks is that I can't easily take notes, while highlighting on an e-book reader is quick and lets me recollect all important gotchas later into a text file.

Book review: Building Microservices

Building Microservices: Designing Fine-Grained Systems by Sam Newman is the seminal book on microservices as a concept. It was published at the start of 2015 (that's a long time ago in tech... or is it?), it's focused on high-level topics rather than implementation and hence has aged well.

There are in fact several concepts, both at the methodology and the technical level, that the books does justice to. Here's what turned on the light bulb over my head.

Modeling

Modeling is important and a whiteboard discussion can save weeks of implementation down the line. Both me and Sam Newman are not the first to say this. Modelling in microservices, like in Domain-Driven Design, is all built around business capabilities and the shape of your organization (yes, Conway).

Styles of integration

Like for other design choices, especially at the architectural level, it's important to explicitly choose whether to go for a shared database (please don't), synchronous or asynchronous communication; orchestration through a Facade or coreography distributing responsiblities between services; explicit versioning the kinds of backward compatibility; pushing or pulling data from one physical location to another, and with which granularity of time and entity.
There are also styles of isolation, not just of integration: code reuse is maturely described on a trade-off scale with decoupling. It feels like a pattern book in which these options are given a standard name for further discussion, and evaluated with respect to the contexts in which they work well.

Deployment

Should you go for virtual machines or containers? How do you map services to physical or virtual machines? The book couldn't possibly keep up with the rise of container orchestrators in the last couple of years, so it won't be a complete guide but could give you a sense of the problems that virtual machines create and that we are going to solve in this next generation. What will be the problems that containers create, and most of all how to solve them, is not in the scope of this book instead.

Testing

After the basics like a testing pyramid, I don't find myself in complete agreement with large scale testing strategies proposed here like consumer-driven contract testing. Yes, it works well enough if you can specify a formal contract that a service should adhere to, and test it in isolation in the implementer service. But the overhead of doing so, in a context in which we are supposed to create dozens if not hundreds of service, is very significant.
At eLife we have relied on a wide RESTful API specification, each group of endpoints implemented by a different service. As such, the overhead is limited, and this is just a description for validating requests and responses rather than a full contract, as most of these services are read-only.
All in all, I find myself relying on the end2end beast to get heterogeneous services, written in multiple languages, in different times by different people, to talk together reliably. I would spend a lot of energy in trying to square the circle of contracts, but I suppose they work well at an higher scale of traffic or on selected services.
The end2end tests we use are limited in their scope, constrained by being at the top of the pyramid; they do not necessarily cover a full end2end scenario but rather a data path involving more than on service, often skipping the user interface. It helps that we have no Selenium-based testing in the end2end layer, as the user interface is fully accessible to a HTML parser and requires no Javascript.
The problems that we encounter daily happen in production all the same: timeouts, dirty data, the automation challenge of turning on and off new nodes reliably, the race conditions that come from distributed executions. I'd rather not hide these problems but solve them, and I'm looking at containers instead to try to shrink the big picture and have a simpler end2end environment, easier to spin up and down, or to provide with clean databases.

Hidden gems

There are several hidden gems that would let you pick the brain of the author on a common problem cited in a chapter. For example, we have such a problem in integrating with a CRM that doesn't even support PHP 7 (what is it with CRMs and always being sources of technical debt?) There are some example patterns that you could apply in that situation, like hiding the CRM behind a specialized service that cleans up its API. Nothing miraculous, but a glimmer of hope for these desperate situations.

Conclusions

If you are going to work with microservices, or milliservices, or small enough services, this book is worth a read. If you are only having troubles with a particular area, such as testing or security, going through a single chapter will give you a big picture before you go in depth with further sources.
Remember that this book is starting to become a bit dated, so you cannot take highly technical lessons from it (and I doubt books are a great tool for those in general in this fast-moving environment). Think about your context, learn the theory, and fill in the parts in which the map is blank (or erased) with what you are learning from the web in 2017 (soon to be 2018 - attempt to make this review valid for one more year).

Book review: Site Reliability Engineering

The overwhelming majority of a software system’s lifespan is spent in use, not in design or implementation. So, why does conventional wisdom insist that software engineers focus primarily on the design and development of large-scale computing systems? -- the book tagline

Site Reliability Engineering - How Google runs production systems is a 2016 book about the ops side of Google services, and the set of principles and practices that underlie it.

A Site Reliability Engineer is a software engineer (in the developer sense) that designs and implement systems that automated what would otherwise be done manually by system administrators. As such, SREs have a directive for employing a minimum 50% of their time in development rather than firefighting and maintenance of existing servers (named toil in the book).

The book really is a collection of chapters, so you don't have to be scared by its size as you don't necessarily need to read it cover to cover. You can instead zoom in on the interesting chapters, being them monitoring, alerting, outage tracking or even management practices.

Principles, not just tools

I like books that reify and give names to concepts and principles, so that we can talk about those concepts and refer to them. This book gives precise definitions for the Google version of measures such as availability, Service Level Objectives and error budgets.
This is abstraction at work: even if the examples being used show Google specific tools like Borgmon or Outalator, the solutions are described at an higher abstraction level that makes them reusable. When load balancing practices are made generic enough to satisfy all of Google services, you can bet that they are reusable enough to be somewhat applicable to your situation.

Caveat emptor

Chances are that you're not Google: the size of your software development effort is order of magnitudes smaller, and even when it is of a comparable size it's not easy to turn an established organization into Google (and probably not desirable nor necessary.)
However, you can understand that Google and the other giants like Facebook and Amazon are shaping our industry through their economically irresistible software and services. Angular vs React is actually Google vs Facebook; containers vs serverless is actually Kubernetes vs Lambda which is actually Google vs Amazon. The NoSQL revolution was probably started by the BigTable and Dynamo papers... and so on: when you deployed your first Docker container, Google engineers had already been using similar technology for 10 years; as such, they can teach you a lot at a relatively little cost through the pages of a book. And it's better to be informed on what may come to a cloud provider near you in the next years.

Conclusions

It took some time to get through this book, but it gives a realistic picture of running systems that undergo a large scale of traffic and changes at the same time. Besides the lessons you can directly get from it, I would recommend it to many system administrators and "devops guys" as a way to think more clearly about which forces and solutions are at play in their datacenters (or more likely, virtual private clouds).

Book review: The Power of Habit

Charles Duhigg, a New York Times reporter, collects stories of building and breaking habits, supporting the thesis that habits form an important part of our lives and that they can make a big difference for better or worse. Both in the case of positive training or learning habits, or in the case of addictions, repeated behavior influences our energy levels, our free time and in the end many of our long-term results at work and in life (we will all go the gym in the new year, right?)

The storytelling style of the book may smell like anecdotal evidence, but it keeps the reader intruigued and entertained long enough the get its message across, without delving into fictional stories. Take the science expressed here with a grain of salt (like you would with Malcom Gladwell): all experiments are real but they may have been cherry-picked to prove a point.

The key take away for me was to think about our habits, try to influence them to stop or reinforce them depending on our second-order desires; for example with the cue-routine-reward framework proposed in the book but ultimately with whatever works for you as habit building and destroying must be very context-specific. Another concept that we find reasonable is ego depletion (willpower as a finite resource that must be renewed), but the jury is still out on whether it is a confirmed and sizable effect, as meta-analysis of hundreds of studies do not agree yet (for good reasons).

From exercising to learning, or from quitting smoking to a Facebook addiction, this self-reflection can have a large impact over our lives. Maybe it should be an habit?

Selected quotes from the book follow:

This process within our brains is a three-step loop. First, there is a cue, a trigger that tells your brain to go into automatic mode and which habit to use. Then there is the routine, which can be physical or mental or emotional. Finally, there is a reward, which helps your brain figure out if this particular loop is worth remembering for the future [...] Every McDonald’s, for instance, looks the same—the company deliberately tries to standardize stores’ architecture and what employees say to customers, so everything is a consistent cue to trigger eating routines.

“Even if you give people better habits, it doesn’t repair why they started drinking in the first place. Eventually they’ll have a bad day, and no new routine is going to make everything seem okay. What can make a difference is believing that they can cope with that stress without alcohol.”

Where should a would-be habit master start? Understanding keystone habits holds the answer to that question: The habits that matter most are the ones that, when they start to shift, dislodge and remake other patterns.

“Small wins are a steady application of a small advantage,” one Cornell professor wrote in 1984. “Once a small win has been accomplished, forces are set in motion that favor another small win.” Small wins fuel transformative changes by leveraging tiny advantages into patterns that convince people that bigger achievements are within reach.

“Sometimes it looks like people with great self-control aren’t working hard—but that’s because they’ve made it automatic”

“By making people use a little bit of their willpower to ignore cookies, we had put them into a state where they were willing to quit much faster,” Muraven told me. “There’s been more than two hundred studies on this idea since then, and they’ve all found the same thing. Willpower isn’t just a skill. It’s a muscle, like the muscles in your arms or legs, and it gets tired as it works harder, so there’s less power left over for other things.”

As people strengthened their willpower muscles in one part of their lives—in the gym, or a money management program—that strength spilled over into what they ate or how hard they worked. Once willpower became stronger, it touched everything.

Book review: Java Puzzlers

Java Puzzlers is a nice book on the corner cases of the Java language, taken as an excuse to explain its inner workings. I have read it over the holidays and I found it a nice refresher over the perils of some of Java's features and types.

What you'll learn

A first example of feature under scrutiny is the casting of primitive types to each other (byte, char int), with the related overflows and unintended loss of precision. Getting to one of these conditions can result in an infinite loop, so it's definitely something you want to be able to debug in case it happens.
There are more esotheric corner cases in the book, such as the moment in which i == i returns false; or the problem of initializations of classes and objects not happening in the order you expect.

Method

I don't want to spoil the book, since it's based on trying to run the examples yourself and propose an explanation for the observed behavior. I'd say this scientific method is very effective in keeping the reader engaged, to the point that I finished it in a few days.
To run the puzzles, you work on self-contained .java files provided by the books website; you can actually compile and run them from the terminal as there are no external dependencies.
Incidentally, this isolation also means you're working on the language and in some cases on the standard library; the knowledge you acquire won't be lost after the next release of an MVC framework.
Again, work on the pc and not on a printed book only; in that case, you won't be able to experiment and you will be forced to read solutions instead of try and solving the puzzles yourself.

Argh, Java!

It's easy to fall into another pitfall: bashing the Java language and its libraries. The authors, however, make clear that the goal of the book is just to explain the corner cases of the platform so that programmers can be more productive. Java has been a tremendously successful platform all over the world, the strange behaviors shown here notwithstanding.
Thus instead of saying This language sucks you can actually think If this happens in my production code I will know what to do. The biggest lesson of the book is to keep the code simple, consistent and readable so that there are no ticking time bombs or hidden, open manholes in a dark and stormy night.

Some sample quotes

Clearly, the author of this program didn’t think about the order in which the initialization of the Cache class would take place. Unable to decide between eager and lazy initialization, the author tried to do both, resulting in a big mess. Use either eager initialization or lazy initialization, never both.

the lesson of Puzzle 6: If you can’t tell what a program does by looking at it, it probably doesn’t do what you want. Strive for clarity.

Whenever the libraries provide a method that does what you need, use it [EJ Item 30]. Generally speaking, the libraries provides high-quality solutions requiring a minimum of effort

Conclusions

Some of these pitfalls may be found through testing; some will only be found when the code is heavily exercised in a production environment; some may remain traps never triggered. Yet, having this knowledge will make you able to understand what's happening in those cases instead of just looking for an unpleasant workaround. This is also a recreational book for programmers, so if you're working with Java get to know it with an easy and fun read.

Book review: Java Concurrency In Practice

I just finished reading the monumental book Java Concurrency in Practice, the definitive guide to writing concurrent programs in Java from Brian Goetz at al. This books gives you lots of information in a single easy place to find, so I'll delve immediately into describing what can you learn from it.

A small distributed system

On modern processor architectures, multithreading and concurrency have in general become a small distributed system inside a motherboard, spanning the centimeters that separate the CPU cores and the RAM.
In fact, you can see many parallels between the two field: CPUs are different machines, and coordinating between them is relatively more costly than allowing independent executions. The L1, L2 and L3 caches near the CPU cores behave as replicas, showing tunable consistency models and forcing compilers to introduce synchronization where needed.
Moreover, partial failure is always round the corner as threads run independently. Forcing programmers to deal with possible failure is one of the few usages of checked exceptions that I find not only acceptable but also desirable. I tend not to like checked exceptions too much as they tend to be replicated in too many places in the code, creating coupling. Still, they make forgetting about a possible thread interruption harder and also push for isolating the concurrent code from the domain models it is using underneath, to avoid throws clause contaminations.

Relevant JVM topics

The book is ripe with Java Virtual Machine concurrency concepts, building a pattern language for talking about thread safety and performance (which are the goals we are pursuing with concurrent applications.) Java's model is based on multithreading and shared memory, where the virtual threads are mapped 1:1 over the OS threads:

• thread safety is based on confinement, atomicity, and visibility. These are not generic terms but are really concrete, explained with many code samples.
• Publication and synchronization makes threads communicate, and immutable objects help keeping the collaboration simple. Immutability is not just a conceptual suggestion, because the JVM actually behaves differently when final fields are in place.
• Every concept boils down to an explanation built over the underlying Java Memory Model, a specification that JVMs have to respect when implementing primitive operations.

Libraries

Basic concepts are necessary for understanding what's going on in your VM, but they are an insufficient level of abstraction for productive work. For this reason, the book explains the usage of several standard libraries:

• synchronized data structures and their higher performance. ConcurrentHashMap is a work of art as it implements lock striping to avoid coordination when accessing different buckets in the map.
• The Executor framework provides thread pools, futures, task cancellation and clean shutdown. Creating threads by hand is a beginner's solution.
• Middleware such as latches, semaphores, and barriers to coordinate threads and stop them from clashing with each other without having to manually write synchronized blocks all over the place.

Thus part of the book has an emphasis of using the best tools available in Java SE instead of reinventing the wheel with Object.wait() and Object.notifyAll(), which are still explained thoroughly in the advanced chapters. Reinventing the wheel can be an error-prone task that produces inferior results, and it should not be the only option just because it's the only approach you know.

Be aware that...

The book is updated to Java 6 (it's missing the Fork/Join framework for example), but fortunately this version contains much of what you need on the theory and basic libraries. You will still need to integrate this knowledge with Java 8 parallel streams.
It takes focus to get through this book, and I spent several dozen hours to read the 16 chapters.
The annotations (such as @GuardedBy) won't compile if you don't download a separate package; it's too bad they're not a standard, since the authors are luminaries of the Java concurrency field, experts from many JSR groups and Java programming language authors.
As always for very technical books, I suggest to read it on a pc, with your preferred IDE and JUnit open to write tests and experiment with what you are learning. You probably will need some review on the most difficult topics, just to hear them as explained from different people. Stack Overflow and many blog articles will be your friend as you look for examples of unsafe publication or of the Java Memory Model.

Conclusions

I'm a fan of getting to the bottom of how things do work (and don't). I would definitely recommend this book if you are executing your code in multiple threads, as sooner or later you will be bitten without even understanding what went wrong. Even if you're just writing a Servlet, that code could become a target for concurrency.
Moreover, as for distributed systems, in concurrency simple testing is not enough: problems can be hard to find and combinatorially difficult to reproduce. You need theory, code review, static analysis: this book is one of the tools that can help you avoiding pesky bugs and much wasted time.

Book review: Thinking in Java

I recently read the 1000-page tome Thinking in Java, written by Bruce Eckel, with the goal of getting my feet wet in the parts of the language that were still obscure to me. Here is my review of the book, containing its strong and weak points.

Basic topics

This is a book that touches on every basic aspect of the Java language, keeping an introductory level throughout but delving into deep usage of the Java standard libraries when treating a specific subject.
The basic concepts are well covered by the first 200 pages:

• primitive values, classes and objects, control structures, and operators.
• Access control: private, package, protected, public for classes, methods and fields.
• Constructors and garbage collection.
• Polymorphism and interfaces that enable it.

Most of the basic topics are oriented to programmers coming from a C procedural background, so they don't dwell on syntax but instead focus on the semantics and the JVM memory model.
Even if you come from a modern dynamic language, you will still find this first part useful to intimately understand how the language works. You will learn common idioms and patterns such as delegating to parent methods, getting a feel for Java code instead of trying to write Ruby code in a Java environment.

Wide coverage

The larger part of the book instead will be useful to cover new ground, if your knowledge is lacking in some areas or if you want a complete understanding of it. For example, I have a good knowledge of data structures such as ArrayList, HashMap and HashSet; still the 90 pages on the Java collections framework introduced me to structures such as the PriorityQueue whose usage is infrequent but can be very useful when you encounter a problem that calls for them.
Here is a full list of the specific topics treated in the book:

• Inner static and non-static classes.
• Exceptions management with try/catch/finally blocks.
• Generics and all their advanced cases including example such as class SelfBounded<T extends SelfBounded<T>>.  I thought I knew generics until I read this chapter.
• The peculiarities of arrays, still present in some parts of the language such as method calls with a variable number of arguments.
• The Java collections framework, much more than List, Set and Map; lots of different implementations and a conceptual map of all the interfaces and classes.
• Input/Output at the byte and text level, plus part of the java.nio evolution.
• Enumerated types.
• Reflection and annotations (definition and usage).

By the way, a few of the chapters can safely be skipped to make the book shorter. Drop the graphical user interfaces chapter as totally outdated, I don't even write user interfaces different without HTML anymore nowadays. probably the most popular GUI framework right now is the Android Platform rather than what's described here.
I also suggest to skip the concurrency and threading chapter, since such a small treatment cannot do justice to this topic. I would prefer another dedicated introduction and then go on with a more advanced book like Java Concurrency in Practice, which will tell you also what not to do instead of showing all the language features.
On this point, I find the writing of Bruce Eckel conservative, showing caution with advanced and obscure features rather than showing off with the risk of writing unmaintainable code down the line. The point is making you able to read complex Java code, not enabling you to write a mess more quickly.

Style

The book is quite lengthy, but lets you select a subset of the chapters pretty well if you need to dig into a particular topic. The text is driven by code samples, and to experimenting instead of reciting theory.
I suggest to read a digital version with your IDE ready: at least in my case, I found it easier to pick up concepts and get involved by writing my own examples. A 1000-page book would be pretty daunting if read on a device with no interaction, as it's the polar opposite of dense.
I created many test cases like this one, which lead me to verify the assumed behavior of Java libraries and features with my own hands:

Currency

The drawback of this book is its not being up-to-date with the current version of the platform, Java 8. The most recent version is the 4th edition, available on Amazon since 2006, which treats every feature up to Java 5.
You will have to piece together knowledge of Java 8 and the intermediate versions from other sources. I would have expected this book to at least be up-to-date with Java 7 due to its popularity.
However, due to Java's backward compatibility, what you read is still correct: I only found one code sample to have a compilation problem. I wonder how long would this book be if it was edited again to include Java 8: it could probably get to 1500 pages or more and implode under its own weight.

Conclusions

If you work with Java, Thinking in Java is a must-read, either to get a quick introduction to the basic features or to delve into one of the specific areas when you need it. You will probably never be surprised by reading Java syntax or idioms again. However, don't expect a complete coverage of such a huge world: this should be your first Java book, not the last.

Weekly roundup: going to the roots of TDD

I'm reading Test-Driven Development by example by Kent Beck, the original book where TDD was presented to the public. I'm getting many insights on the Red-Green-Refactor process, but one thing is becoming clear (and it is also explicitly stated): TDD is not a substitute for design choices. It gives you a quick feedback about the current code design, its testability and coupling; but choosing metaphors, names and patterns is up to you.
Unless you were once bitten by a radioactive Kent Beck, your design-sense should be nurtured with practice, like any other skill.

Here are my articles published this week, some of which regard testing as well.
Practical PHP Testing Patterns: Configurable Test Double is the main method for building Test Doubles.
How to enrich lawyers explains the goals of the patent system, and its many issues.
Practical PHP Testing Patterns: Hard-Coded Test Double is a type of Test Double written by hand, and very explicative.
Web Workers, for a responsive JavaScript application is a running example of this HTML 5 innovation.

Get an ebook reader

Only if you enjoy reading books, of course.

I recently ordered a Bebook Neo, the European equivalent of the Amazon Kindle. It arrived from the Netherlands in two business days (there is no custom between European Union countries). It has wi-fi and an headphones jack if you want to listen to music, but these features do not interest me. I want to tell you about the reading experience.

As a programmer and engineer, I read a lot of books, on various subjects:

• technical ones (Kent Beck, Martin Fowler, Uncle Bob...)
• managerial ones (Peopleware, Agile Estimating and Planning)
• science fiction (Asimov, Dune, Philip K. Dick...)
• fiction (Zen and the art of motorcycle maintenance)
• personal development (Getting things done)
• cooking (well...)

For some of these books, I don't even know if an Italian version exist. Instead, ebooks (mostly in PDF format) are ideal to get them in their original English edition. For example, Packt Publishing sent me a PDF copy of some of their books for review in less than a minute from my registration.
Furthermore, there are other publications available in electronic format only, like DZone Refcards and free ebooks from SitePoint.

The only problem with reading ebooks is the device you use to read them. My Asus EeePC 701 (the first netbook in the market segment) is good for writing articles, and skimming blog posts, or for a bit of PHP programming by SSHing into my home machine. But for reading extensively, LCD screens will kill us.

First, there is backlight. You know when, as a child, you were told not to stare at the Sun? Here is the same mechanism, on a smaller scale. Direct light is sent from the LCD screen to your eyes, and over the minutes or the hours staring at it becomes not very beneficial for the eyes. Besides the protracted direct lighting, the LCD screen has a very different light intensity from the surrounding environment (from objects which do not emit own light, of course), which causes eyes to strain to continuously adapt between the screen and the rest of the world:

When reading a good book, I usually get in a flow state and do not make 5-minutes pauses, which sound innatural and break the natural page turn rhythm I am accustomed to since I was 6.
With an LCD, the brighter the environment, the less you see on the screen (outdoor you can't see anything, especially with modern glossy displays). With a e-ink screen like Kindle's or Nook's Bebook's ones, you have to actually provide external light to read. This is an advantage for e-ink devices, since you can easily provide light when it's needed, like you do for paper books. I do so with an abat-jour over my bed. On the contrary, it's quite difficult to obscure the sun if you want to read outdoors with an LCD screen.
As any library affectionate can tell you, an LCD-based device is not an ebook reader, period. Forget about iPads - those can make for wonderful trays for Martini glasses like my CD drive does, not for readers that do not cause headaches.

Second, there is the user experience. I used Evince, the Ubuntu equivalent. The ebook reader software is specialized and offers a simpler interface. Zooming have several acceptable levels and text is automatically reflowed to fit the pages. There's no fine tuning of the horizontal scrolling bar to have all the text visible at the same time, nor continuos adjustment of the vertical one; only two buttons to go to the next or previous page.

Third, there is battery life. I haven't still recharged my Bebook after the initial unpacking day more than a week ago. It basically consumes energy only for its idle cycle and during page turns. Requiring no own lighting mechanism, when you're reading a page it is essentially not consuming. Its charge is estimated to last between 4,000 and 7,000 page turns. In comparison, for my netbook I have a choice between attaching a cable to the nearest power outlet or using a half-kilogram battery.

Fourth, there is size and weight convenience: the internal memory of Bebook Neo is 512 MB and a book commonly occupies from 1 to 10 MB of storage space. This particular device has an SD card slot that you can use to expand the memory further: with 8-16GB of SD cards, you have practically infinite memory (unless you own the Library of Congress). You're helping the environment at the same time - I bet the material used for manufacturing an ebook reader and the energy it used during its lifecycle are a more efficient choice over printed books. If there are doubts, maybe we can recharge readers with solar panels. :)

Fifth, there is the absence of distractions. On my netbook, I'm one click away from opening my mailbox or twitter account. In the latest versions of Ubuntu, new messages from instant messenger buddies shows up as notifications (in some also Twitter mentions), and I have to close Pidgin or Empathy.

Sixth, it is very trendy. No one I know in Italy has an ebook reader. When people brag with their iPhones you can peacefully continue reading your favorite book and ignore them. :)

The downside of the solution is only its cost. A device from the Bebook series costs between 250 and 350 Euros. If you live in the US, the Kindle and the Nook are available and cost much less. Take into account custom duties if you decide to buy from another country.

These costs are comparable or inferior to those of netbooks, but ebook readers are much more specific devices. However, if you read a lot, embracing an ebook reader will give you all the advantages above.

We're not superheroes

I was reading bits of Coders at work, a book of interviews to famous programmers. I didn't like it very much: here's why.

The first thing I noticed is that many questions are biographical. I do not care about knowing if Ken Thompson, which built Unix, worked on a PDP-10 or a PDP-11 or a PDP-7. By the way, I do not even know how those things look like: I was born in 1988.

Besides that, this kind of books tells you how to live like a superhero coder, but most of us just aren't (me too).
Thompson could work out the design of software in his mind for a month before starting coding, I can't (or I can waste less time by writing something in code).
Knuth could design and code LaTeX in pencil and write for six months before do any testing. I can't (or I can, but I would be much more efficient with a quick feedback loop like Test-Driven Development's one.)
Zawinski could pick up rolls of duct tape and make Netscape work in six months (picking up also a lot of technical debt and vanishing from the market in the following years). I prefer working software over comprehensive documentation but not over sustainable development.

So we're not superheroes: test suites, source control, Continuos Integration are our bat-gadgets which enable us to deliver software while working for a living and not living for work, like Ken Thompson and his 28-hour days or Bill Gates and his nights at school programming. Let the people with the superpowers shoot webs all night long, while we go back to Wayne Manor and throw a party. At least Batman hasn't a day job: poor's Peter Parker must live a miserable life.

Expert PHP 5 Tools review

The book I'm reviewing today is Expert PHP 5 Tools, which in the last month has gained a lot of momentum in the blogosphere.

One of the first part of this book makes a great deal (correctly) of coding standards. Although this focus on the code, this is not a book on how to write code (with topics like object-oriented design for example), but as the title suggests on tools that supports the development, and on how to deal with the infrastructure necessary to maintain a project.

Some of the main topics treated by this book are version control (with Subversion), and debugging/error management in PHP (Xdebug). Sure you'll never introduce breakpoint in PHP, debugging is much simpler than in other languages as a script terminates after every request; but having the right tools can speed up you very much. I still prefer thorough testing to debugging.
Another interesting topic is the use of PHP open source frameworks, with a panoramic of the available solutions and a Zend Framework example. Don't worry about the particular technology since MVC stacks of the different frameworks (which are the innovation that makes a framework different from a library, as it manages HTTP requests and responses) are usually equivalent.
 
The second part of the book goes on to cover topics such as testing (a delicate topic for me), and deployment of applications. PHPUnit is introduced from the ground up, with all its features like annotations, fixtures and code coverage reports. Even Test-Driven Development is discussed to some extent.

A bit out of place was the introduction to Uml, a dangerous standard when applied in the large or at a great level of detail. Remember though that understanding of basic Uml (class, sequence) diagrams is a requirement since many patterns are explained with this kind of documentation. Moreover, small and focused Uml diagrams can communicate very much about a design.
The practice of Continuos Integration is explained with a nice idea: setting up a CI server for Zend Framework. Leveraging open source projects gives some points to this book.

Some points I did not like was the idea of favoring IDEs very much, which is quite the contrary of the toolbox metaphor, a set of small tools you can combine instead of a monolithic one. Another minor point is the large preference for PHP tools over the ones written in other languages: after all the author is using Eclipse, which is certainly not written in PHP.

I'm not severe on this type of readings, because I always have to remember that a book is a starting point: you have to actually use the practices described here and gain experience to be effective. Thus, if you are a project manager which wants to really empower his developers instead of limiting them, check out this book.

Growing object-oriented software review

Growing object-oriented software, guided by tests is a masterpiece on Test-Driven Development, a valid guide for the beginner in this field and for the almost expert as well. This book guides the reader through a world where TDD is not only always applied, but it is kept in its pure form.
The title describes exactly the purpose of the practices presented in the book: starting an ambitious project from scratch, and expand the product from an empty skeleton to a fully-featured application. Unit, integration and acceptance tests are the specifications which are written before the production code, and that drive the development in an agile way towards a the end of an iteration or a release.

Structure
The book is divided in five parts:

• Introduction to Test-Driven Development and design principles for object-oriented applications. This part bridges the beginner with the rest of the book, written for a programmer at an intermediate level.
• The process of Test-Driven Development: TDD in a double cycle, mocking, third-party code, and every bit of theory you need to know about Red-Green-Refactor.
• A worked example: 150 pages where the authors build from scratch an application which interfaces with the web and a user interface, by adding one test at the time and justifying every single step. The code is available in different programming languages on the official web site.
• Sustainable Test-Driven Development: TDD is often abandoned when issues arise due to its incorrect usage. Managing the test suite is the most important part of long-term maintainability and readability, expressiveness and consistency are taught here.
• Advanced topics: persistence, threading and asynchronous calls are often a difficult field for test-driven applications, enhancing the omnipresent danger of introducing brittle and slow tests. Though, it is not impossible to extend testing in these areas by tweaking the original approach. Remember that if you code test-first, nothing can stop you from writing testable code.

As you can see from the Advanced topics part, the book is oriented to a Java audience, but if you exclude the last two chapters every practice and principle is just tied to real object-oriented programming and not to particular programming languages. For examples, PHP 5 has a complete object paradigm and the necessary tools (PHPUnit, Zend_Test) to practice the techniques described in the book.
A basic knowledge of Java helps, though, because the code samples are written in Java and make use of frameworks such as Swing; of course JUnit-based tests are instead perfectly equivalent to test written with any other xUnit testing framework.

Some concepts explained by this book - such as the Walking Skeleton and Acceptance TDD - were very enlightening. I guess there is a reason why Misko Hevery recommends this book:

Reading the book I sometimes felt that I was listening to myself, especially when the authors warned about global state, singletons, overusing mocks, and doing work in constructors among other things. But unlike myself, who draws sharp lines between right and wrong, the authors did a good job of presenting things on the gray scale of benefits and drawbacks. The book shows what a typical code most people will write, and then show how tests point a way towards refactoring.

Also Robert C. Martin, also known as Uncle Bob, has words of praise for Growing object-oriented software:

At last a book, suffused with code, that exposes the deep symbiosis between TDD and OOD. The authors, pioneers in test-driven development, have packed it with principles, practices, heuristics, and (best of all) anecdotes drawn from their decades of professional experience. Every software craftsman will want to pore over the chapters of worked examples and study the advanced testing and design principles. This one’s a keeper.

I am glad I have finished reading it before starting my thesis on a large project. If you do not trust me, trust them. :)

Domain-Driven Design review

Domain-Driven Design, by Eric Evans, is the masterpiece of the DDD movement. It introduced to the world the harvested experience of Evans in working on model-driven development on a variegate group of object-oriented projects, presenting it as a series of patterns and meta-patterns (such as the Ubiquitous Language), and ranging from the design of a single class to a large map of different applications.

A brief summary
DDD is a very dense book, and it is logically divided in four parts:

• Putting the Domain Model to work, which covers the importance of the Ubiquitous Language and the centrality of the model of the application domain.
• The building blocks describes the patterns used at the finer level, such as Entity, Value Object, Aggregate, Service, Factory and Repository. 
• Refactoring towards deeper insight covers the continuos process of adapting the Domain Model to new insights and crunched knowledge, believing firmly that an hidden model exists and will be reached with a supple design. Modelling as described here is like applying an unification theory to software.
• Strategic design introduces the techniques for large scale structure and separation of contexts, such as the famous Anticorruption Layer (although it is not the only communication medium between different Domain Models.)

In my opinion the third and fourth parts are the most difficult to digest, due to their abstractness (not everyone of us has worked at that scaling level) and the perceived distance from working code. In fact, the first two parts are rich in code samples, which gradually vanishes towards the end of the book while the view on object-oriented applications is taken to an higher level. Diagrams, both based on Uml and not, are preferred throughout the last chapters.

How to read it
Many people start reading DDD full of confidence, scheduling five chapters a day, only to struggle very quickly, usually in the second part, and abandone it. Even in my recently completed reading from cover to cover, I waited some time before starting the third part.
This book is intended as a series of patterns - notice the capital letters used for most of the names - those names are specific terms with a precise meaning. In the case of the Gang of Four book on design patterns, this made it hard to read cover to cover because of the lack of a common thread between the chapters.
But in this book's case, the main theme is the model-driven design practice that evolves from the finest level - the class and its methods - to BoundedContexts and Responsibility Layers. That said, the information contained is very dense and I have never read more than 15-20 pages on a given day. I suggest you do to the same or you risk burning out before reaching half of the book. Also taking notes is a mean that forces high focus of the content and may help.

Other resources
There is a lighter book freely available - Domain-Driven Design quickly - which promises to explain you DDD in 100 pages. Don't read it: when I tried, I understood a concept only as long as I have already read it on the original DDD book, and never learn anything on the new material. The original is 400-page long, but it is already condensed as much as possible.
A book that expands on the code samples and the design process is Applying Domain-Driven Design and Patterns, which is a good read to combine with DDD (in fact, it is 600-page long.) You may refer to it when you want more practical examples of a pattern treated in the original book.

In sum, this book is often cited as the DDD book, and in the future it may be considered the bible of real object-oriented development. If you have it on your shelf, I suggest you to read as much as you can beginning from the start, skipping only the fourth part if you do not ordinarily deal with large-scale applications.

PHP in Action review

PHP in Action is a hands-on PHP book written by Dagfinn Reiersol, Marcus Baked and, most notably, Chris Shiflett. PHP in Action is maybe the only PHP-specific books which bridges typical PHP topics, such as forms and database handling, to object-oriented design. It is very rare to encounter a book like this, which teaches object-oriented programming from a non naive point of view (How do I write those "classes?") in the PHP environment. PHP is still catching up with other languages in this field and many developers can only benefit from improving their modelling skills and design practices.

As I said, this book is PHP-specific; though, many other titles proclaim they're teaching object-oriented PHP on their covers, while the only touched topics are public and private fields, and how to extend classes with inheritance (if that seems normal to you, read this book.) Many publishers jumped on the bandwagon of PHP 5 and proposed books focused on the language constructs instead of the things you can build with them.
PHP in Action is a bit different. For example, it includes some of the SOLID principles and examples of their application in PHP code, without too many assumptions about the overall knowledge of the reader. The most important Design Patterns are explained, with an eye to the native support offered by PHP 5 (SPL).
Advanced techniques (for the average developer) are also introduced, such as refactoring, unit testing and Test-Driven Development. By no means this is an in-depth read on these topics, but the average developer which has a deep understanding of the PHP technology (but not of OO as a decent support was introduced only a few years ago in the language) will find this book useful to start upgrading his skills to the next level. I think this is a common situation, and was also mine; if I had found this book previously, my journey would have been simpler as I wouldn't have had to translate knowledge from Java books. I hope these advanced parts will become a standard in the future.
That said, there is really no PHP book that describes in full depth object-oriented design. There are specific books on object-oriented development, which are very long and insightful and still not complete. These books usually choose Java for their code samples (or C++ if they're very old); you may want to refer to different titles for pure object-oriented learning.

About the material provided, the code samples are inserted in each chapter, and are also refactored while  iterative development takes place. There are many small Uml diagrams to help the reader understand what's going on - mainly class and sequence diagrams. Highlighting of relevant code and changed lines is the norm, along with ordered explanation lists linked to different point of the code samples that substitute intrusive comments.

The level of the book is adequate for the intermediate coder, thus I found it easy to read. Nevertheless, it is a good panoramic of the PHP landscape in term of the transition to object-oriented programming. The first edition is from 2007, and it is not outdated; though, you may consider using a framework to provide many of the infrastructure seen in the book, which is provided more for teaching than actual every day usage.

Some of the links in this post are affiliate links.

Zend Framework 1.8 Web Application Development review

This is my personal review of Zend Framework 1.8 Web Application Development, a book by Keith Pope (affiliate link).

First, a clarification on the book's name, which refers to Zend Framework 1.8: the book work flow is based on the 1.8 version but the Api of Zend Framework is now stable, and thus even if now the latest release is 1.10, the book is not outdated at all. Zend Framework 1 would have been the wrong title as the 1.5 and 1.8 (which saw the introduction of Zend_Tool) releases were the real turning points.

After having read its 300+ pages, my general impression of this book is good. A problem often faced by frameworks is the relearning of php basic features: how to pass a parameter, add a page, generate an url, etc. which were very quickly solved by the author in the first chapters. This book starts from the ground up and adds the functionalities that cover 80% of the use cases, harnessing the power of Zend Framework. Zend Framework has a large Api, and knowing the right methods to call is fundamental.
The author does not skip panoramics of what happens under the hood of Zend Framework, which is very useful for debugging purposes and for deepen the understanding of other infrastructure such as the ajax requests helper (not included) and Zend_Test.
The whole point of the book is in developing a showcase Zend Framework application for an online store, complete with an electronic cart. As you know, I prefer hands-on approaches to programming and I think code is the best model for a software, way better than diagrams. I was happy to see that every version of the application (which progresses trough the different chapters) is present in the downloadable package.

Components treated

• Zend_Controller and Zend_View (plus Zend_Layout) in the management of the Mvc machine.
• Zend_Db for the implementation of model persistence resources.
• Zend_Tool for the creation of an application from scratch.
• extensive guide to Zend_Form, which is one of the most time-saving components and one of the most difficult to leverage because of its large Api and many functionalities. Decorators, filters and validators are widely used.
• Zend_Session, in a quite elaborate example. I think I would have simply just put domain objects in a Zend_Session_Namespace.
• Zend_Auth and Zend_Acl for authentication and authorization (management of identity and permissions).
• Zend_Cache for optimization of different parts of the application. This is not micro-optimization, and the author highlights simple solutions like avoiding multiple actions dispatching and activating Apc over complicate practices.
• Zend_Test for integration testing of the controllers.

Model
The sample application in this book implements a maybe overengineered database-agnostic model, which would thus be a good solution for decoupling and testing purposes. Though, ZF 1.x does not have the infrastructure to achieve a pure Domain Model without a great effort (currently work is being done on integrating Doctrine for simpler object-relational mapping.) As a result, the domain model has highly specific ResourceItem and Resource classes which sit in the middle between the Active Record and the Data Mapper patterns.
This model design is not "pure", but it gets the job done, maintaining the fat model and skinny controller paradigm. Though, I would not purport it as an example. Remember that the Model part of your Mvc application is up to you: the book is only about learning how to leverage Zend Framework, not about object-oriented programming. There is a great example of a model that does not use the database at all: if you are stuck with ActiveRecord, this way of thinking will open your mind.

If you want to dive into Zend Framework, this book will teach you a lesson on the most important components, saving you hours of digging the Api and the reference manual.

Zend Framework 1.8 Web Application Development

I have started reading the book Zend Framework 1.8 Web Application Development, by Keith Pope (affiliate link).

From a first impression, it seems a thorough book, which covers testing, authorization, authentication and the various layers of a php application. The review will be available in the next weeks.

Angry monkeys and other stories

First, a story contained in The Productive Programmer, which I find really interesting and helpful. Neither I nor the author know if the story is real, but it has a powerful moral. Telling a story is often the best mean to communicate an interesting concept.

Angry monkeys
Once upon a time, there was a group of scientists who were experimenting on monkeys. They placed some of them in a closed room, along with a ladder that allowed them to grab a bunch of bananas hanging from the ceiling. The catch was - whenever a monkey went near the ladder, cold water was sprayed in the room. What the scientist get as the result of this experiment? Angry monkeys.
Then they remove one monkey from the group, and put in a brand new animal which was not aware of the cold water trap. His instinct suggested him to climb the ladder... Only to be suddenly beaten up by the other angry monkeys, which were tired of the cold feeling.
Continuing the experiment, they replaced one more monkey, and one more, until they have in the room only animals who have never experienced the cold water trap, which was now turned off. But still, if a monkey approached the ladder, he would have been stopped and beaten by his companions.
The moral is: why some practices are followed today? Because if they were not, a bunch of angry monkeys would yell at you. Some examples?

• Primitives in Java, supported because it was very strange to create classes for simple values (now recognized as immutable Value Objects).
• Making every entity class a bean or an Active Record was common practice between angry monkeys, but the situation has changed in the last years.
• constructors that perform real work, or that even creates other objects, because someone thinks that object-oriented programming means writing programs consting only of the line new ApplicationInstance().

Sometimes a standard is enforced because it provides consistency and interoperability; some other standards are relics of the past, craved by angry monkeys. Dare to not always follow the same road of others.

Here are similar software stories, in the form of fables. The power of metaphors allow us to explain software problems even to naive people.
How to kill a dragon? This is something many knigths would want to know. And what if they could use their preferred programming language to complete the quest?
In Deadline and Technical Debt, a valorous knight attempts to satisfy the requests of the king to marry his daughter, the princess Caroline. Will he be successful?
The Stone Soup story, reported also in the original Pragmatic Programmer book, teach us that people find easy to join an ongoing project and this is a powerful way to cooperate.

Learning how to refactor

Refactoring is the process of improving the design and the flow of existing, working code by applying common patterns, like extracting a superclass or a method, or even introducing new classes as well as deleting existing ones.
Probably if you are here you have already experienced the refactoring process, but I want to clarify the common iterative method I use, to get feedback and being helpful to developers who are naive in this practice.

This is the general process to learn how to refactor code, which wraps the basic refactoring cycle.
Step 1: get the book Refactoring: Improving the Design of Existing Code by Martin Fowler (a classic) or a refactoring catalogue on Wikipedia or Fowler's website. In the book or in a similar guide, there are two lists which are very boring if read sequentially: smells and refactorings. Smells are situations that arise in an architecture, while refactorings are the standard solutions to eliminate smells. It is annoying to keep something that smells in your office.
Since it is very boring to read the Refactoring book if you have even a small experience with the practice, the best way to extract all Fowler's knowledge is to apply it directly.
Step 2: For S in 'smells':

• Read about S; understand what is the problem behind a practice that you may have used without worries.
  
• Loof for S in one of your personal projects or where you have commit access and responsibility for the code base; get convinced that this smell should be eliminated. If you are not convinced, stop here this iteration and go to the next smell; your existing solution can be pragmatically correct in the context of your style or in your architecture. Note that there are no absolute reference points and refactorings often come in pairs: it is up to you to choose if refactor in a direction or in the opposite one (Extract Method or Inline Method?)
  
• Find an appropriate refactoring R; there are multiple solutions that can eliminate a smell. Be consistent in your choice in different places.
  
• Make sure there are unit tests for the code you're going to edit. No further action should be taken before you are sure functionality is preserved. This is the answer to the question "Why change something that works?"... Because it will still work, but much better.
  
• Apply R in small steps, running focused tests every time to ensure you have not break anything.
• Once the refactoring is complete, run the entire test suite to find out if anything is not working. Note that failures in points distant from refactored code constitute a smell too: they are a symptom of coupling.
  
• svn diff will calculate a picture of your modifications; ensure that debug statements or workarounds are not in place anymore.
• svn commit (or git equivalent commands) pushes your improvements to the repository. Using version control is also fundamental in case you get in a not recoverable state: svn revert -R . is the time machine button (no, Apple has nothing to do with it) to restore the original code.
  

The goal of learning various refactoring techniques is to easily see smells in the future, to improve the efficiency of the Refactor phase in the Red-Green-Refactor cycle. Your bricks (classes) are very malleable when fresh, but when they solidifiy it becomes harder to add further modifications: it is good to refactor as much as possible just as you have finished adding code for functional purposes.