Digital Apollo

It’s no secret that I was a child during the space age, going to the moon was just taking a different kind of plane and there was no doubt, we all were going to spend y2k vacations on some asteroids or even Mars. Rockets and space keep fascinating me even when I got to know y2k for another reason and now that Mars still remains a distant shore where no man has gone before (and possibly it will take yet some more time to get there).

Growing older, and becoming an engineer just increased my respect and admiration for those people that using 60’s technology achieved such an incredible goal. Space is hard, unforgiving, there are millions of things that could go wrong. Timing and counting are especially critical. Just the first example that comes to my mind – switch the rocket off too early and you’ll plunge back to Earth, switch the rocket off too late and you’ll be cruising on a non-return-path to the Sun or the Outer Space.

This book starts from the beginning of the space era in the USA and follows the story up to the moon landings.

A bit surprisingly, the first half of the book is focused on the human side – the test pilots, the political propaganda, the strong will about having a human in the cockpit and in command of the mission. Von Braun, the German scientist behind many successes of the American rocket science, was a strong supporter of having humans out of the control loop – the rocket is fired, autopilot and physical laws of gravity take it to the destination, without the need of a pilot doing anything. This view was strongly opposed by the ideology of the space hero – the man that conquest the space, driving rockets and starships.

From the first orbital maneuvering it was clear that the pilot intuition was too misleading to proper control the spaceship – changing the orbit to get closer or farther from Earth it’s too different from the action you do on a plane, you need to take in orbital speeds when approaching your target, not just the relative positions.

Eventually the space program came to agree on avoiding human piloting the rocket during the launch phase and having some control operations with man in the loop and some other completely automatic. Humans where there as a reliability and recovery mechanism in the control loop. Having a spaceship flying to the Moon, is a very complex operation, that requires many activities to keep the capsule functional, aligned with the objects and preserving the passengers’ life.

While the story narrated in the book unfolds, the digital computer appears on stage. It was back in the sixties, when the single chip computer was yet to come. So the MIT took the task to design and build the so called Apollo Guidance Computer. It had 2k of work memory and 36k of persistent memory and ran at 2Mhz. The book describes the story of the development of the hardware and the software never going into technical details. You get to know that the computer was built using only NOR gate chips to ease repair and replacement of faulty components (operation that was later ruled out from on-board activities). Also you get to know that the user launched specific subprograms by input a number describing the “verb” followed by another one describing the “noun” of the required operation. Also all the operations that involved firing rockets were programmed to require the pilot authorization. This lock saved at least one mission when, during a lunar orbit, the pilot accidentally attempted to run a pre-launch sequence.

Maybe the digital computer played an even more crucial role in the lunar lander. This flying machine was something so radically different from every machine built to that time that designers and pilot could not tap into any previous experience.

The flight was not based on aerodynamics, but was only powered by rockets. By properly controlling the rocket attitudes and thrust the lander could move around and hover at a fixed point. Engineers and programmers made an incredible achievement by having such a complex machine controlled via a joystick, that proved quite intuitive to the pilot.

The computer on the lander had several programs to be selected according to the flight phase. A specific one had to be selected for landing. A graduate ruler was print on the portholes. By aligning the view of the pilot to the desired landing point, you get a reading on the ruler that had to be input in the computer. An automatic program would take control of the lander and took it to the desired position. This struck me for the ingenuity of the designers. They had to overcome the lack of interactive computer and did it in a simple yet effective way by using low technology equipment. Kudos!

During the first mission to the moon – Apollo 11 – the story wants that the landing computer failed requiring the two astronauts in the cockpit – Neil Armstrong and Buzz Aldrin – to manually take control. This is partly true. First because the lander couldn’t fly at all without a computer that translated manual input on the control joystick to rocket pulses. Second because the computer was in fact working properly reporting a real problem that, thanks to the ability of the programmers, had no consequences on the computer reliability.

The problem was that the lander computer had to be used for many different things, as the computer in the Apollo spaceship, it was controlled by the user that launched subprograms for every specific phase or maneuver during the mission. The landing sequence had many abort points, i.e. specific moments when the pilots had to decide whether abort the descent to the moon surface and get back to the Apollo capsule (the Command Module), or to proceed. Each part of the sequence had a specific procedure to operate. Right after the lander detached from the Command Module a first decision had to be taken – dock back to the Command Module or proceed to the next step? If the descent was aborted at that point, the pilot had to switch on the docking radar and use the computer to execute the docking sequence.

The docking radar had to be engaged also during the flight to the Moon when the lander was extracted from the 3rd stage of the rocket and then docked to the Control Module. So, during the simulations, the astronauts asked whether they could keep the radar on to avoid having something to think of in the case they aborted the descent.

This switch caused data from the radar to be fed to the lander computer causing some extra processing. The operating system and the programs were designed with a 30% margin on CPU load, and an error were reported if the load exceeded a safety threshold. Being a real time operating system with sound priorities, the computer continued working properly offering reliable pilot controls and descent trajectory. Nonetheless during the mission the mission control preferred to avoid any risk and asked the pilots to switch off the trajectory control, leaving Neil Armstrong and Buzz Aldrin to manually operate the lander to the landing spot.

This served also the propaganda to claim the reliability of human and the fallibility of the machine. In the next missions most the pilots decided to avoid automatic landing and go for manual landing even if there were no problems in the software and they landed very close to the programmed spot.

Very interesting also the role that the software played in the design and development of the missions. Initially no one considered software. I mean literally – there was no account for software on the initial plan. Likely it was considered part of the engineering system, not a main activity. Also the activity of software production started without an industrial process and without an effective leader. Around mid ’66, things changed, software switched from being a pet project for a few tens of programmers into a project with hundreds of people, project managers, documentation, review…

Overall I enjoyed this book a lot. In the first part felt a bit slow, and apparently not going to the point of computers in space, but in the next chapters that long introduction helps to better understand the human factor behind the story.

Zen and the Art of Motorcycle Maintenance

It was a long time I’d like to read Zen and the Art of Motorcycle Maintenance. It came to my knowledge several years ago while browsing hacker culture stuff, like the Jargon File. Regrettably I can’t find now, even with the power of modern web search engines, which reference I stumbled upon.

I knew that this book has not much to do with real motorbike maintenance (and not much about Zen as well), but motorbike maintenance is used by the author to make his points about a more general pictures. So, when I found this book on the Amazon Kindle daily deals, purchasing it was a no brainer.

The book is about a journey through USA on an old motorcycle. The main character is a dad, traveling with his son. The book is written in first person and is split between the present where the road unfolds before the duo and the past, when the character worked as a University professor, so intelligent and focused that became mad while restructuring in his mind the whole philosophy.
Eventually his journey through philosophical systems ended with an electroshock that turned him into another self. A less introverted person, possibly somewhat less sharp (even if his reconstruction of the thought of the previous self is really deep).

I liked the book, but I cannot define it an eye-opener. Here and there you can find interesting notes and thoughts on issues like technology and people, technology and maintenance, quality. On the other hand, if you are interested in philosophy, you will find this book quite interesting since it tackles about all major philosophers and their systems, applying their thoughts to concrete aspects of life.

[Btw, all these Amazon ads you find in this post (and in the next ones), are just a desperate attempt in recovering some cents to contribute to my website hosting. I don’t want you to but anything you wouldn’t have bought, but if you are interested you can click on the link.]

Mazzo di carte

“Ho capito che ognuno di noi nasce con un mazzo di carte diverso, chi ha il punto servito e chi un mucchio di scarti, ma questo non vuol dire che non si possa giocare lo stesso. E magari vincere. Dipende tutto da come si affronta la partita.” [Da “Morto a 3/4” di Francesco Balletta]

Il Mistero della Sibilla Appenninica

“Il tuo codice è scritto bene, raffinato, solido ed evoluto, tutti dovrebbero scrivere codice così, ma gli altri hanno difficoltà a capirlo e sarebbe meglio che tu abbassassi un po’ il tuo livello così che sia più semplice per loro capirlo e modificarlo”. Questo, parafrasato, è quello che ho sentito in un paio di esperienze lavorative. La mia reazione, scoramento a parte, era che in realtà avrei ben volentieri aiutato tutto il team a crescere piuttosto che abbassare il livello.
Questo è un po’ il mio parallelo conclusivo de “Il Cacciatore di Sibille”, ma andiamo con ordine.
È la prima volta che mi capita di recensire (e leggere) un libro scritto da un mio amico.
Ho conosciuto Michele a Perugia in pieni anni 80. Condividevamo la passione per la programmazione (con lo Zx Spectrum) e la fantascienza.
Ci siamo persi di vista dopo i miei trasferimenti e la mia pigrizia epistolare.
Grazie a Facebook ho letto della sua attività di scrittore e del suo primo (credo) libro e d’impulso ho acquistato una copia in formato Kindle. A proposito, ottima idea quella di utilizzare questo canale di distribuzione.
Scrivere qualcosa mi è piuttosto difficile perché “il cacciatore di Sibille” è un libro molto diverso e lontano dalle mie abituali letture. Quando non leggo testi tecnici in inglese, i miei gusti sono orientati alla fantascienza e al fantastico. Mi piacciono i libri di azione, mistero, intrigo che abbiano comunque una trama solida (non tipo Dan Brown per intenderci).
Il libro che ho appena finito è un libro ricercato, raffinato, dove ogni parola, ogni aggettivo, ogni periodo è ricercato e calibrato. Dove intenzionalmente la lettura è impegnativa: aggettivi desueti (10 punti per l’uso di “onusto” e “ctonio” sicuramente una delle poche, se non l’unica parola dell’italica favella, che contenga la sequenza ‘ct’). Dopo averlo letto mi sento un po’ come un estimatore dei fast food reduce da una cena di novelle cuisine.
Il mio problema con il libro è probabilmente legato ai miei limiti di lettore. Nei primi quattro quinti del racconto non succede molto. La storia della Sibilla appenninica viene presentata attraverso tutti i vari personaggi storici che ne hanno parlato nei loro racconti. Il libro è scritto curiosamente in prima persona, ma il protagonista rimane indefinito. Non sono riuscito a cogliere alcuna motivazione più o meno profonda che spingesse il narratore in questa impegnativa e sofferta ricerca, né cosa gli facesse cambiare idea in merito all’oggetto delle sue ricerche nel corso della narrazione. Perfino l’occupazione del protagonista rimane misteriosa.
Un altro aspetto che mi suscita qualche perplessità è che molte svolte importanti nella ricerca avvengono più o meno per caso. Sfogliando una guida turistica o un tomo in una libreria… come se l’attività di ricerca fosse solo documentativa e i veri avanzamenti nella conoscenza del mistero fossero casualità (adesso che l’ho scritto mi viene da pensare che spesso è proprio quello che avviene in realtà).
(Nel prossimo paragrafo parlo della fine del libro, il che potrebbe rovinare il piacere della scoperta a chi non l’ha ancora letto).
Ultimo punto di alzamento sopracciliare riguarda la conclusione. Ribadisco che anche questo è probabilmente conseguenza della mia insana dieta letteraria. Alla fine arriva il tanto sofferto incontro con la Sibilla, a il protagonista non trova niente di meglio che scappare. Cioè per pagine e pagine si prepara l’ineluttabilità di questo incontro nefasto, blasfemo, illuminante… e poi non succede nulla. Anche la torcia del nostro che sembrava essersi spenta per arcano potere magico viene riaccesa semplicemente come se nulla di soprannaturale fosse intervenuto.
Il mio spirito di “consumatore” di letteratura fast food un po’ rimane deluso più che altro dall’occasione persa: ci sono tutti gli elementi per un grande romanzo di mistero, azione ed intrigo. Cambiando registro e aggiungendo qualche ingrediente più dinamico, questo libro avrebbe potuto raggiungere una popolarità molto maggiore.
Vorrei però che di questa mia recensione rimanesse soprattutto questa nota positiva: Il cacciatore di Sibille è un grande libro. Lo dico convinto, non per piaggeria. È uno scritto erudito, complesso, scritto con una reverenza ed una cura per la lingua italiana quasi religiose. Volendo banalizzare è come un libro di Eco riscritto da un accademico della crusca. Questa sua eccellenza è al tempo stesso il suo limite: non è un libro per tutti.

Scuola 2.0

Penso che mi si possa definire un entusiasta appassionato di computer ed elettronica, avendo iniziato ad usare i PC da quando ancora si chiamavano “home computer”. Ho passato però abbastanza tempo alla tastiera per raggiungere una certa obiettività la cui estrema sintesi con un po’ di esagerazione potrebbe essere riassunta dalla Quinta legge dell’inattendibilità: “Errare è umano, ma per incasinare davvero tutto ci vuole un computer”. E’ con questo spirito critico che accolgo le roboanti e propagandistiche dichiarazioni sulla Scuola 2.0 (qualunque cosa questo voglia dire).
E da veterano del byte mi preoccupo – perchè la scuola che vedo e che sento è una scuola agonizzante che avrebbe bisogno di quegli investimenti per ristrutturazioni, materiali didattici (per non parlare della carta igienica), personale qualificato, ma che sicuramente non ha bisogno di ulteriori responsabilità e problemi che potrebbero verosimilmente darle il colpo di grazia.
Infatti quello che manca in tutti gli articoli che ho letto è un dato di realtà, iPad e PC non sono taumaturgici oggetti che con la sola presenza hanno il potere di trasformare legioni di studenti caproni e ignoranti in eleganti dottori dal QI a fondo scala. Ci sono vantaggi, sicuramente, ma ci sono anche dei costi indiretti e delle problematiche d’uso. Cose di cui non v’è menzione in alcun articolo.
Un esempio stupido stupido è che iPad e netbook hanno bisogno di energia, ve lo immaginate in una classe un povero docente che fa lezione con un terzo degli studenti che deve ricaricare l’aggeggio elettronico, magari tra prese volanti e prolunghe collegate ad un impianto elettrico fatiscente?
O sempre lo stesso docente che si trova con metà classe che naviga su facebook anzichè leggere Petrarca? O che deve aspettare qualche minuto perchè tutti abbiano finito di accendere il PC?
E chi si occuperà di aiutare gli studenti a configurare il dispositivo, a sistemarlo quando, inevitabilmente, perderà la configurazione o i dati saranno danneggiati? E quando si perderà o si romperà? Un libro di testo sopravvive tranquillamente ad un volo da una finestra del terzo piano (magari si squinterna un po’, ma rimane comunque utilizzabile per il suo scopo), non si può dire lo stesso di un iPad.
Si dirà che queste scelte favoriscono le famiglie abbassando i prezzi dei libri di testo. Può essere, ma non ho letto nulla, in questi articoli, riguardo alle reali differenze tra un libro elettronico e un libro cartaceo.
A meno che non si espressamente richiesto dal legislatore sul tema libri di testo, un editore può rendere l’e-book nominale (non potrà essere ri-venduto, prestato o stampato senza cadere nell’illecito), revocabile |è capitato con 1984 di Orwell ed Amazon], o con data di scadenza (mi dicono che alcuni libri di testo scadono dopo 3 anni).
Nessuno ha sollevato il dubbio che studiare su un LCD retroilluminato può dare problemi alla vista e alla concentrazione (già pericolosamente in bilico tra Petrarca e Facebook).
Anche ammesso e non concesso che questa sia la via da seguire per il futuro, perchè nessuno ha messo in discussione le scelte? Ad esempio i lettori eInk sarebbero sicuramente più adeguati. Android invece di iPad sarebbe più economico. OpenOffice e Linux invece di Microsoft sarebbero gratis.
E’ difficile non pensare che dietro a questi pomposi annunci ci sia un duplice intento che poco ha a che vedere con la reale innovazione dichiarata. Da una parte si strizza l’occhio ai ragazzi (prossimi elettori) con la promessa di un elettronico oggetto del desiderio e dall’altro si fanno gli interessi di Apple e Microsoft e qualche grosso produttore di portatili.
Non ultimo, ma non trascurabile, non ho visto nessuno affrontare il tema dell’impatto sociale di queste operazioni. Personalmente credo che i lavori in obsolescenza vadano lasciati andare senza tenerli artificialmente in vita a tutti i costi a spese dei contribuenti (anche se sono altresì convinto che, a spese dei contribuenti, gli addetti debbano essere aiutati a riqualificarsi, a cercare un nuovo impiego e sostenuti in questo periodo di transizione). La rivoluzione Scuola 2.0 impatterà sicuramente su tipografie, magazzini, trasporti e librerie e cartolerie; probabilmente ci si aspetta che la nuova generazione di geni creata a suon di iPad e eBook risolva questo problema (e tutti gli altri).

Agile Estimation and Plannning

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

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 of Chaos

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 Enlightened. The book is an educational 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 philosophical. 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”)

Reading a quick summary – part 2

Software Creativity Robert Glass Software Creativity 2.0.
Quite an interesting reading. The author attempts to answer the recurring question whether writing software be a procedural task or a creative process. The question is very interesting and it is at the core of software engineering practices. If the answer is the first, then writing code can be automatized and programmers may be considered interchangeable. The topic is difficult and the author attempts to follow a pragmatic if not formal approach to give the answer. I liked the answer (yes it is a creative process, sorry to spoil, but I couldn’t resist), but I find the book somewhat weak in giving short and fit references to help programmers in dealing with management to get their points… not that management would care anyway.
James W. Grenning Test-Driven Development for Embedded System.
Firmware development tends to be one of those niche where the “NAH” (Not Applicable Here) defense is used for preventing proper software practices to be applied. Structured, Hardware independent, Object Oriented… in many circles are considered techniques unsuitable for embedded software. I am pretty convinced of the contrary, and this book really is a valuable allies. The book is about test driven development (that is, first write tests, then code) which is another “heresy” for bare metal programmers. I found very well presented, although sometimes a bit verbose (if you are an experienced programmer you may find yourself often skipping through some examples). If you are curious about unit test, and how to apply it to firmware then this book is a must read.
What you won’t find is how to unit test interrupt depending code (i.e. critical run and critical sections) and how to test multithreading code.
Umberto Eco Il Cimitero di Praga (The Cemetery of Prague).
I enjoyed reading Eco in the past (“Baudolino” and “Il pendolo di Focault“, “In nome della rosa“) although I found his book having two speeds – the first for the first half of the book quite modernly paced, the second, slow and hyper-detailed for the rest of the book. I had the impression the writer was more devoted in showing the result of his culture and his researches rather than telling the story. This is true to a lesser extent for this one.
The story is intriguing and I felt really at discomfort to read in first person the actions and the motivation of the main character (a late 1800 forger involved with European country intelligences) a selfish racist that has no hesitation in faking friendship and then killing those who trusted him. Nonetheless the book given big bytes of food for thoughts both about recent history and how intelligence works.
Alexander Stepanov, Paul McJones Elements of Programming.
The title is a clear declaration of intent – this is a text book, in the same shelf where you would look for elements of mathematical analysis, elements of algebra and so on. The book follows strictly the cliche, feeding theorems and lemmas to the reader. So it is not a light reading. By reading this book I finally discovered an application for those strangely named algebraic structures (Ring, Semi-Ring and so on). Basically when dealing with generic programming you need some mathematical tools to request the shape of the data types on which you may (or may not) instantiate the generic algorithm. The book is mostly about answering in a formal way to this need. Do you need to read this? I am quite doubtful, if you want to learn programming, this is not the book for you. If you are fluent with template metaprogramming, I guess you won’t find much for you in this book. If you are studying the theoretical connection between mathematics/algebra and meta programming, then maybe this is what you are looking for.

Reading a quick summary

It is elapsed some time from the last time I wrote a book review, but, in fact I keep on reading. I am pretty sure I will never get through all the backlog, so I decided to go the quick and easy way with a list and a brief description. Should you like to have more information about any book I read, feel free to ask.

James Rollins Artico (Ice Hunt).
Quite fresh and addictive adventure book. The setting is not so original, but I liked it. The main character is genuine and true.
James Rollins La mappa di pietra (Map of Bones).
Nice adventure book, not exceptional. If you like unlikely historical reconstruction, scientific nonsenses and fast paced adventure, then this may be for you.
James Rollins Il marchio di Giuda (Giuda’s Strain).
Adventure book, this belongs to the same series of “Map of Bones”. It shares the same kind of adventure and narration. It’s a page turner, but it left me quite unsatisfied.
Scarlett Thomas PopCo.
Unusual novel. It talks about a young lady who works for a toys corporation. This fictional corporation is described to be the size of Hasbro and Mattel. The book talks at length about the life in such company, how they deal with customers, and the contradictions of capitalism and occidental life-style. Oh, and it also talks about cryptography (that was the main reason I bought this). The book is pleasant, although slow at times, but it is able to give many points to think about.
Terry Pratchett Wintersmith.
Very good book by Terry in the Discworld series. This is the third of Tiffany Aching. Entertaining and witty.
Terry Pratchett Unseen Academicals.
Another Discworld novel, this time I didn’t much like it – it takes too much time to get the narration up to speed and lacks of the very part that makes Pratchett’s books so good. The story is about a Football (or Soccer if you happen to live the other side of the big pond) Discoworld version, with the stereotypical player and the equally stereotypical top model girlfriend.
Terry Pratchett Nation.
This time a Pratchett’s book not set in the Discworld universe but on an alternate history on a fictional Earth. I found this book very good. Although its intended readers are in the teen range I really enjoyed it. The author is clearly at his best, writing about differences, leadership, belief, faith and the hard task of growing up. Highly recommended.
Scott Rogers Level Up.
This is a great school book for game design. Or, to put it better, this is The Book if you want to learn and understand how to design videogames. In many parts it can be considered just common sense, although it is a highly organized and outstandingly well written common sense. If you want to be really picky, you may say that this book is not game genre specific so it may be too generic if you are very in a specific kind of games. I can’t wait to apply everything I learned.
Tom Demarco, Peter Hruschka, Tim Lister, Suzanne Robertson, James Robertson, Steve McMenamin Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior.
Demarco and Lister are two great project engineers, their “Peopleware” is one of the best book on project management. One of the first that collected evidences and put it straight – in software project people matters. I had high expectations for this book. Unfortunately it is somewhat less than I expected. It is a collection of 1-2 pages articles describing one pattern. Some pattern are good, some are evil and some can be both. I found the book somewhat lacking of structure and poor in references to facts and studies supporting the claims. Thinking better about it I don’t see who is the intended reader – the project manager either is peopleware “enlighted” or is not and for sure this is not the book you can throw at him to make him change. The programmer may nod for one or more pattern, but there is no clear way to make and propose changes it his/her company to improve practices.

Here we go. I have another burst of books I’ll report about in the next days.