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

Prezzo: EUR 5,87
Da: EUR 9,60
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.]

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.

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

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.

PHP In Action

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 surprises. 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

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 elephants 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

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 crisis. 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.