On my quest for a good Flask book, I saw this book from Tarek Ziade. We are more or less of the same generation, both from France and he wrote a far better introductory book to Python in French than mine. He also founded the French Python community (AFPY), so I always had a huge respect for the guy. And the book was appetizing.
Category: Design Patterns
I had to port a simplex/Nelder-Mead optimizer that I already have in Python in C++. As for the Python version, I tried to be as generic as possible but as efficient as possible, so the state is no longer a dictionary, but a simple structure.
I could have used the Numerical Recipes version, but the licence cost is not worth it, and the code is not generic enough, not explained enough. And also there are some design decisions that are questionable (one method = one responsibility).
A few years ago, I mentioned that the registry pattern was my favorite pattern in Python. Well, it may also be my favorite C++ pattern.
Due to the end of the free lunch, manufacturers started to provide differents processing units and developers started to go parallel. It’s kind of back to the future, as accelerators existed before today (the x87 FPU started as a coprocessor, for instance). If those accelerators were integrated into the CPU, their instruction set were also.
Today’s accelerators are not there yet. The tools are not ready yet (code translators) and usual programming practices may not be adequate. All the ecosystem will evolve, accelerators will change (GPUs are the main trend, but they will be different in a few years), so what you will do today needs to be shaped with these changes in mind. How is it possible to do so? Is it even possible?
Test-Driven Development is one of the most controversial development processes. Instead of planning everything ahead, you develop your program incrementally as well as simultaneously and rigorously test it. Kent Beck is one of the most proeminent advocates of this method and this book is the Bible of TDD.
I bought this book as soon as it was published, and I sold it soon after. Suffice to say I had a very mitigated impression after reading it. There are good things in it, but also some very bad stuff. It doesn’t describe how to write your ultimate game engine, but the author’s game engine. What about some modesty?
Let’s start with the bad stuff.
After last week book review on Martin Fowler’s Refactoring, I’d like to review another book, more oriented towards patterns and refactoring.
I’ve read this book when I started my PhD thesis. It helped me laying down the basis of software conception.
It was the first book where I found the code smell concept. And my former code really smelt…
If last week’s book review was too complicated for you, perhaps this book is more suited for you. Less design patterns, but a funnier way to describe them.
As I’ve said before, I’ve done several book reviews in the past. I will start with a small serie on design patterns books.
This book is one of the “must-have” in your library. If you write some code or if you manage some IT or Computer Science projects, you will have this book to lay down the basic software architecture.