Home
CV
Blog
Photos
book reviews
downloads
work
links
F.A.Q.
interests
travels
trekking
videogames
programming
playing
miniatures
fitness
programming
C, C++
Java
Shell
misc.
guestbook
mail
|
Spoiling Warning. Here I write comments for the books I read... it is likely that I'll put some notes on book endings or plots, so if you don't want to be spoiled be careful.
Well, this is just an incomplete list... of course :-)
RSS Feed specific for book reviews.
|
What does it mean?
Archive
|
Agile Estimation and Plannning
2012-Nov-08 Thursday 14:45 CET
 
Agile methodologies yield appealing promises - deliver the maximum value for customer money by frequently releasing a shippable version of the software kept in sync with the customer's needs by the presence of a customer proxy in the development team.
I hadn't really bought in all the hype of agile, but I think that there are a bunch of principles that make a lot of sense. Unit testing and make the simplest working solution are the first two that come to mind. Beside that I was very curious about how the agile deals with planning.
In fact, though agile preaches not investing on documentation and does not make any warranty about reaching any given feature set in a given time, agile uses estimation to size iteration time span and move one to the next. The same estimation is also used to assess the "speed" of the team and as such forms the base for next estimations.
In XP you have the so called "planning game", where programmers confront each others bidding for features ("I can do this in 3 days", "I can do it in 2" and so on).
"Agile Estimation and Planning" is a very good book, it presents the matter in a smooth way, with many examples, but not too much. It doesn't tackle a specific process, but illustrates a way to estimate and plan that is compatible with the agile practice.
Such compatibility is also a limit. In fact, in order to have the agile working, you need to find a suitable context. One where everyone is willing to accept that at the end of the budget there won't be what we agree on today, but (if everything goes fine) the best value for the money spent. Let's say that if you find such a context of trust and understanding, then it is likely that any methodology will work. But I am digressing.
Nonetheless Mike Cohn manages to provide how-to guide for the cases for the rest of us, i.e. when the customer wants something for a given date and in a given budget. The method described accounts for evaluation of worst case and some statistical mumbo-jumbo to get a number that is less than the sum of the global worst case. That makes sense, though I didn't find in the book any mathematical support for his method. Well this doesn't mean that the method has no mathematical ground, just that it is presented as something "given" rather than derived.
Overall the book is a pleasant and inspiring reading regardless you are on an agile project or not. I recommend it to anyone who is required to estimate software development task.
The Practical Guide to Defect Prevention
2012-Oct-26 Friday 13:53 CEST
 if you happen to be involved in software development you know how much it costs and you can't ignore the chances of reducing defect count and thus increasing the cost-effectiveness of the process.
So I started reading this book with much interest also because the word "Practical" in the title looked very promising.
I had some trouble to get over the slightly disturbing detail that a book on defect prevention has been written draining experience and making examples from the development of the Microsoft Windows Vista. Despite of this, the book is very well detailed and offers indeed practical approach, though "practical" does not imply that you can easily apply in your working context.
In my workplace software development barely reaches level 2 of CMM and the main management idea is that software development should cost no money and give results by yesterday. In this context (that I feel is not so infrequent) I find quite hard to ask for simulation software or defect classification software when they cost several thousands bucks.
Anyway the overall structure of the book is good in teaching what is the state of the art in preventing software defects, but basically it sums up to go up in the CMM level.
Some points in the book made me raise my eyebrow more than once. For example when praising the qualities of code review the author states that the best time to peer review the code is as soon as it is written, even before it is run through the compiler. The reason is that in this way the maximum number of error is caught by the process. That's puzzling because a great deal of the same errors may be caught automatically by the compiler itself. So, though the number of detected errors is high, the advantage in doing so seems IMHO quite reduced.
Nonetheless I think this is a good read worth reading, even if most of us fellow programmers won't see any of those techniques in they everyday software development (I'm not talking with you working at NASA ;-)).
Does God Play Dice? The New Mathematics
2012-Oct-24 Wednesday 14:02 CEST
 What if you discover that what you know about math physic is wrong? That would be quite a surprise, but it is what actually is if you haven't studied chaos theory.
In fact I felt quite surprised when I read this book by Ian Steward. Surprised and Enlighted. The book is a divulgative essay on the math physic history and the most recent advances on the so-called theory of chaos.
Basically the core concept is that the classic equations describing system motions have been developed in the 17th century properly describes only ideal cases. It was thought that the real world effects, being small could be considered negligible.
What the real world insistently taught us in these years is that those small contribution can not be ignored for given enough time they will sum up and will turn you neat and smooth equations into the negligible part. The worst part is that for most system, even after a short time the system becomes unpredictable.
The author is a university professor and does a great job in presenting the matter, there are few equations, but they are thoroughly explained. Still with my aging university math (I studied analysis in 1988) I found I could follow easily the topic.
This book is fascinating under many aspects - historical and phylosophical. I also found very enlightening some ideas. For example everyone knows the so-called butterfly effect - a butterfly flaps her wings in Tokio and your weather forecast on the East Coast are totally messed up. Now I always thought about this effect as an annoyance in getting the right weather forecast. But correctly you may see on the other side - it is an amazing mean of control. With so little energy you may control huge phenomena.
I also loved the part at the end of the book where Steward defends mathematicians against the popular belief they are closed in their Ivory Towers without doing anything useful. As he - correctly - points out, they are doing their work (as anyone else on the World) and their work usually has useful applications in everyday life even though they could not happen immediately.
(Italian title: "Dio gioca a dadi? La nuova matematica del Caos")
PHP In Action
| Title: | PHP In Action |
| Author: | D. Reiersol, M. Baker, C. Shiflett |
| Publisher: | Addison Wesley |
| Pages: | 552 |
| Date: | 2007 |
| Read on: | Fall 2009 |
| Read in: | English |
| ISBN: | 978-1932394757 |
| Vote: | 10 |
2010-May-06 Thursday 13:54 CEST
Being a fair programmer may not always be enough to be a fair web programmer. Web programming has some peculiarities on its own. Defining a sound architecture for a web site is all but a straightforward task. This may explain why the software I wrote for this blog has grown a bit out of control O:-) (and, put it in this way, allows my ego to be safe).
That's why I looked for a book to improve my PHP web programming and found "PHP in Action".
The book is packed with pleasant surpises. First of all it is a darn good book on web programming. Author spends a good time in explaining scenarios and examining programming patterns in easy-to-complex order able to solve the related problems.
But the book is a really good book on design in general. Several patterns are described in a hands-on, no-nonsense approach. More are introduced when dealing with specific aspects of web programming. A brief introduction to object oriented programming is included as well.
I found very valuable the presentation on Unit Test and the arguments for Test Driven Design, so much that I promptly searched a unit test library suitable for C and C++, so that I could use the same approach on my daily job.
If you are interested in PHP programming for Web I highly recommend this book.
The Last Hero
| Title: | The Last Hero |
| Author: | Terry Pratchett |
| Publisher: | Addison Wesley |
| Pages: | 160 |
| Date: | 2007 |
| Read on: | Winter 2009-2010 |
| Read in: | English |
| ISBN: | 978-0575081963 |
| Vote: | 7 |
2010-Feb-10 Wednesday 16:50 CET
This is the first illustrated Terry Pratchett's novel that I read. According to the legend, the first Hero stole the fire from gods. Now the Silver Horde - a bunch of elderly, but nonetheless lethal, heroes - is committed to bring back the fire to gods with interests - the Discworld equivalent of an atomic bomb.
Unfortunately the detonation on the god citadel would cause the dispersion of all the magic bringing Discworld to death.
All the discworld nations ask Ank-Morpork to save the world. So the patrician assigns this mission to Captain Carrot, Rincewind the Wizard and the inventor Leonard of Quirm.
I found Rincewind and Leonard very fit in their part, while I had more surprise with the parts played by Carrot and by the Patrician. I can't imagine capt Carrot joining the terror hymn that goes like "Aaaaaarrrrrggggghhhhh". Carrot character has always given the impression of blind faith in the system. Thus he should have a wonderful faith in what the system has produced to save the world. The patrician is a fine connoisseur of human minds, I feel uneasy when he fails to understand Ponder Stibbons. Also very far of the image I have of this character that he propose so plainly to kill the Librarian to save the mission. The patrician is subtle, manipulating, not plain, nor direct. And the story, at a given point, cites a B plan, that is very Patrician, but the topic is not evolved... it seems more of a device to talk briefly about the attempt of ecumenism on Discworld. Also Death, who usually is very attentive to the fate of Discworld was a bit lacking, he just takes a look at the hourglass of the giant A'Tuine (the turtle that floats in the space void carrying four elefants that, in turn, carry the Discworld.
So... this is not one of the best book by Terry Pratchett - it is better than Erik, but worse of the other books. Nonetheless the drawings are gorgeous and the story is entertaining.
Slack
| Title: | Slack |
| Author: | Max |
| Publisher: | Addison Wesley |
| Pages: | 228 |
| Date: | 2001 |
| Read on: | Fall 2009 |
| Read in: | English |
| ISBN: | 0-7679-0769-8 |
| Vote: | 10 |
2009-Oct-19 Monday 14:07 CEST
I hate wasting time. If you have time don't wait for (more) time, that's one of my favorite savings.
When I started working I had a small commute by car and some time got wasted waiting for the traffic light to become green. So I started reading books in those waits.
With my MS-Windows becoming slower and slower at startup, I decided to spend the waiting time reading books. At work I started a copy of "Slack" by Tom De Marco. Being a book on efficiency I found fitting to read it in recycled time.
If you work in software development (or if you are a "white collar" at large) you ought know who Tom De Marco is. Or, at least, you should have heard about the book he wrote with Timothy Lister - Peopleware. This is one of the most referenced book, almost every book on project management written in recent years quotes Peopleware.
Back to Slack, this is a book intended to be read in a short time to convey good an bad practice about efficiency, innovation and risk taking in today's organizations.
The author states about an hour and half as reading time, I guess it is somewhat more even if you read from page 1 to the end at the same time (and not scattered over a couple of month of PC boots), nonetheless the thought-provoking stuff is very dense. Chapter are short and almost everyone made me think.
It is possible I will write a resume of it in the future, but I strongly encourage you to read by yourself.
Tom hacks through myths trying to grasp what is needed by an organization to survive in times of change and crysis. First myth to fall is the one of total efficiency. Total efficiency means total rigidity. An organization that maximizes efficiency cannot withstand change because lacks of the buffer and the spaces to react to change and adapt.
Then he digs through the (wrong) assumptions about making the organization more productive - pressure, competition, fear and so on.
Eventually he bashes the Management By Objects and illustrates what really means to deal with risk.
For example planning should be an estimation and as a such should offer a range defined by: cannot complete before X and surely completed after Z, with a best estimation at Y, with X <= Y <= Z. Now that's a planning, that's quite different by setting a goal. From my experience, someone defines a planning, someone else carves it in stone and says that's the goal. This way of operation ignores the risk, ignores that an estimation is just an estimation, not a commitment, and it is just a sure way to have a delay on the completion. In fact, even if the most likely date (Y in the example above) is taken, this is usually achievable only with a probability of 33%.
De Marco also marks "Management by Objectives" (MBO) as "don't". I already read about criticisms at MBO, but more about the bonus system rather than objectives by themselves. De Marco states that it is hard, if not impossible, that the defined objectives for employees lead the organization toward company objectives. Also in a time of changes it is hard to hit an objective even if the actions taken are excellent for the company.
I found this particular opinion a little forced on software development. I think that an objective and bonus scheme over the course of a project, if properly done, could be helpful. Maybe MBO is just crap if applied to vending or other areas.
I liked the book a lot and I think it is not just for managers (regardless of their level). The more widespread the ideas here contained the better the life of fellow programmers.
The Ultimate Guide to Videogame Writing and Design
2009-Aug-19 Wednesday 13:19 CEST
Video gaming is for sure one of the reasons I got so addicted in computer programming. Being forced out of the videogame industry in 2004 had not been an happy experience at all and I am still trying to make sense out of it. But life goes on and if I am not really capable of "letting go" that part of my life, I am gardening the (possibly false) hope of making some games in my spare time.
I am just a programmer and I know my game design skills will never rival with even to the scantest game designer. That's why I bought and read this book. Not with the intent of becoming a game designer, rather with the desire of filling some of the gap and better understand the techniques and the mechanics of their work.
The book is easy to read and concepts are easily grasped. I found some little inspiring pearls. The first is the introduction itself. Authors claim that in an ideal world they would have suspended their work for at least one year in order to properly write the book. Actually this is impossible, as is impossible to do with much of the work they do - multiple projects are developed in parallel and the successful worker has to deal with this rather than complaining.
The first drawback is, IMO, a direct consequence of this - the book is not very well organized. I found that some chapters are out of order and oftentimes an overall picture is missing. It is not too bad, you may argue that is just "creative" at work.
Another interesting concept is that writing a game (o a show, a movie) is not "art" but "craft". I.e. "art" is about inspiration and cannot be relied on for day-to-day work. "Craft" is something that gets thing done, in the best way, even when your muse is on vacation.
The book propose a good number of exercises. I started with the intention of doing them all, but some of them are too time consuming to be done on holiday, with an inviting sea in front of you (and your children yelling around).
The other big drawback is that this book is much more about "writing" than "designing". The distinction may be thin, but "writing" pertains to the story, while "designing" pertains to the mechanics of the game. Most of (if not all) the problems are seen from the story point of view. Therefore characters are examines and created starting from their story, their internal struggle, their relationship, i.e. everything that is story, rather than from "powers" and which "actions" they perform.
This is not bad per se, it is just that the title may result a little misleading.
I have mixed feeling about suggestions given in the book about the job at large. At one extreme are good advises about how to deal with conflict in the team or with other project stakeholders (even if not everything is applicable in working context other US). At the other end are obvious suggestion (don't live over your possibilities and subscribe a pension fund).
The book proposes a set of templates for the definition of characters, parties and world. The approach is good and likely the tables contain the right set of questions. In fact I found myself to develop an unexpected and quite awesome background for the videogame I am working at.
To sum it up, read this book if you are interested at story in videogame.
On The Edge
| Title: | On The Edge |
| Author: | Brian Bagnall |
| Publisher: | Variant Press |
| Pages: | 548 |
| Date: | 2005 |
| Read on: | Winter 2009 |
| Read in: | English |
| ISBN: | 978-0973864908 |
| Vote: | 9 |
2009-Feb-18 Wednesday 16:59 CET
As far as it may seem odd nowadays, there was a time when BASIC was the language, computers from different vendors were 100% not-compatible and resources were so constrained that your average mobile phone could be considered a supercomputer when compared to. It was the Home Computer Era.
Back then, it was the first half of the 80s, home computers started to spread around even in Italy. I was fourteen and started programming (and playing) with my ZX Spectrum 48k.
We hadn't Windows or Linux, Vi or Emacs, Java or C#, but we had our religion wars - the most bloody, was Sinclair vs. Commodore and more precisely Spectrum vs. C64.
Owning a Spectrum I was in the Sinclair's party - the gummy keyboard machine with a nice rainbow. Spectrum had superior BASIC and faster CPU. I like to think I always have an open mind, in fact, some years later, I was about to buy a C64. The Commodore machine sported for sure a superior hardware - more memory, more graphic modes, better audio, sprites, and decent keyboard. [...]
iWoz
| Title: | iWoz |
| Author: | Steve Wozniak, Gina Smith |
| Publisher: | Addison Wesley |
| Pages: | 304 |
| Date: | 2007 |
| Read on: | Summer 2008 |
| Read in: | English |
| ISBN: | 978-0393330434 |
| Vote: | 7 |
2008-Dec-01 Monday 13:42 CET
Although I am not addicted to retrocomputing, I quite enjoy reading about Good Ol' Days when Real Men where up to forge the computer revolution. Given this premise it was rather impossible to skip over the Amazon suggestion when I received it.
iWoz is the story of Wozniak, the engineer among the two Steves that founded Apple back in the seventies, told by Steve Wozniak himself (or at least edited as if it sounds so).
The book is a pretty smooth reading up to the point where he left Apple, but I think it's just me loosing somewhat interest in the narrated matter.
I found very emotionally touching the first chapters where Steve writes about his infancy and his father. Maybe it is because I had lot of thoughts recently on being father, but I found this figure of father-engineer really fascinating - never forcing his kid on learning something, but let his strong passion for technology and science "infect" his child. Also noteworthy the strong ethic component of this father about nearly everything. I'd like to be a father like this.
Also the book proves that some kind of chances could have occurred just there. I think nowhere in the world (and likely in time) a group of children could receive as gift from a telephone technician some hundreds meters of telephone wire. Also the home computer revolution had to start right there - all the players were there and they much knew each others.
In some parts of the book I read some naïvety. E.g. the Atari affair. Jobs always did the marking and commercial part of their projects. So they got this deal to build a videogame prototype for Atari. In change of one week effort Wozniak got few hundred dollars, because Jobs told him he got the same. Only later Wozniak discovered that Atari paid several thousand dollars for the project (and obviously Jobs kept the difference). This didn't made Wozniak upset with his partner. He candidly states that Jobs needed money at that time and later (after Apple IPO) money ceased to become an issue.
Another aspect of the book I found somewhat uneasy with is that Wozniak claims to be a first in many key technologies of the emergent home computing industry - the first computer with video output and keyboard built in, the first color computer, the first computer with audio, the first microprocessor based videogame, remarked more or less with "something unheard of at those times". I don't want to take off anything from the pioneering work of Wozniak, but most of those technologies where really about to spring to life in those years and, there were other companies providing the same stuff in different degrees of completion.
Despite of these two aspects I am pretty satisfied of this reading and I recommend if you are interested in the topic.
Jingo
| Title: | Jingo |
| Author: | Terry Pratchett |
| Publisher: | Addison Wesley |
| Pages: | 448 |
| Date: | 1998 |
| Read on: | Summer 2007 |
| Read in: | English |
| ISBN: | 0061059064 |
| Vote: | 10 |
2007-Sep-17 Monday 13:29 CEST
For those of you that know me, it is not a surprise that I really like Terry Pratchett work. So before the holidays I placed a huge order to amazon comprising all his book I haven't yet read.
"Jingo!" is the first popped out from the reading queue. I though this summer I would have read a bit more, but traveling throughout USA, trekking in parks and keeping an attentive eye on a teen nephew it's time consuming as it sounds.
Back to the book. This time an island is rising from the ocean about halfway from Ankh-Morpork and Klatch. The island is discovered at the same time by two fishermen from the two towns. Everyone claims his country rights on the new land, and this leads to political frictions between countries. [...]
The Celestines Company
2007-Apr-17 Tuesday 15:32 CEST
This is another Italian book without an English translation, at least not one you can buy on Amazon.
The story is about a group of orphans that escapes from the orphanage to participate in the secret world championship of StreetBall. StreetBall is a specific variation of the football played along the streets of nearly everywhere with much passion and fantasy. The Great Bastard himself, the God of all the orphans, has dictated the rules for Street Ball.
The story takes place in the rich and corrupted country of Gladonia. The orphans are chase both by the (equally rich and corrupted) church in the person of Don Biffero and Don Bracco and the media personified by the journalist Fimicoli. And behind those pawns the egoarch Mussolardi supreme ruler and mostly owner of Gladonia.
As I have already expressed before in other posts, Benni is one of my favorite writers. In this case he manages to achieve a good tale telling, while keeping a meta register. Situations and characters usually live at different levels. The story level is nice, but the plot twists are a bit forced, situations are mostly resolved via Deus Ex Machina. The next level is satirical, Benni portrays the changing Italy, a beautiful country losing its genuine and true origins to progress, corruption, hypocrisy and indifference. What was clean and nice now is polluted, what once was quiet and calm now is crowded and noisy, what once was honest and private, now is criminal and reality show.
Characters are caricatures of real people, the county politician, the clergymen, the orphans, the media, the TV channel owner, and the army.
At a deeper level we find messages. Messages about what is going wrong and what would doom us. The strong message is about the importance of unadulterated youth. Children deserve to grow in a free and genuine environment. Benni strongly criticizes everything menacing this.
I have to admit that I lost most of these deeper levels at my first reading. But the book is so intriguing that the second read was swift.
|