This is a book about the Magellan mission, whose purpose was to gather topographical/geological data about Venus. I wanted to read it since a while ago (because of this recommendation), but I sort of gave up on reading it, since it is not available as an ebook, and there seems to be no way of getting hold of a physical copy, from where I live at least.

But after a while I thought of checking the Open Library of the Internet Archive, and lo and behold: there it is. You must use their in-browser reader, and you are reading scanned pages, but despite that, reading it that way (using a tablet) is not a bad experience. Except for having to be connected to Internet to read it, sighs. But that's not the Library's fault. Anyway.

The book presents a good overview of the scientific process around the mission: the history/previous efforts to map Venus, both from Earth observations, and Soviet and American probes. It also presents the scientific team (mostly geologists, and geophysicists) that receives the data, and provides a good overview of their analyses, the different hypotheses used to explain the geological features of Venus, etc., with a nice peek into the social process of the construction of this knowledge: the in-fights, ego clashes, squabbles for resources/recognition, etc.

You will have to go and get yourself a basic geology vocabulary (lithosphere, asthenosphere, plate tectonics, that kind of thing) to be able to follow those presentations. To me all of the geology stuff was somewhat dry but still interesting.

I think it's important to note here that the book has maps of the Venus areas discussed, in its final pages, so you can ground/relate them to all of the features discussed in those geological analyses; I didn't discover that until I finished the book, and it would have made my reading way more amenable. (This is where physical books have an advantage, I would have found that right away with a physical copy...)

Another main theme in the book is the mission from an engineering point of view: descriptions of the spacecraft, particularly focused in their computer systems, and of the operation of the spacecraft: all the work required to send and receive data between the spacecraft and the team, via the Deep Space Network, the work involved in processing the data and converting it into something a scientist can interpret, the spacecraft maneuvering and so on; also, of course, the handling of unexpected failures: the spacecraft control systems crashed (went into RPE, Runaway Program Execution) several times, provoking LOS (Loss Of Signal), and the book presents all of this in a detailed yet accessible fashion: what kind of resources they used to debug the issue, their hypotheses around the cause, the hacks they used to ameliorate it, and how they ended up diagnosing and correcting it.

Finally, the book is also about NASA project/mission management: building and launching a spacecraft requires a large effort, but keeping it running, analysing the data, planning/executing more operations with it, also involves a fair amount of effort and money, and even if a mission was approved, its budget for future years might go away, regardless of the spacecraft still being operational or not, and we get to see a bit of the managerial aspect of getting those resources: changes of plans/goals for the mission, optimizations from engineering, taking resources from "competing" projects, lobbying to your congressmen, people working for free, you name it.

It's quite an interesting read.

Also, if this book interests you, you might also be interested in Computers in Spaceflight: the NASA Experience: it's a book written by the NASA, about the computers they used in several missions, both manned and unmanned: the requirements around them, the technical characteristics of the computers, and their software and hardware architecture, and a little of the process of building the hardware and writing the software for the mission, particularly from the management point of view.

Una señora descubre que criar un niño es una tarea emocionalmente exigente.

Las exigencias físicas de la crianza no hacen parte de este descubrimiento, que la autora le ahorra a la protagonista con atajos como:

• Instalar al niño mágicamente dentro de la historia, y darle la edad suficiente para:

  • Estar en control de sus esfínteres.
  • Ser capaz de hablar, expresar su estado físico y mental, y contar con un vocabulario y contexto cultural adecuados y compatibles con la protagonista.

• Poner a la protagonista en la posición de permitirse no tener que trabajar para poder mantener al niño y pasar tiempo con él.

Este conmovedor viaje está salpicado con múltiples descripciones de las pequeñas ansiedades que llenan la cabeza de la protagonista, y las maromas intelectuales usadas para (intentar) exprimirles una gota de belleza y significado.

El autor es el profesor Luis Miguel Bermúdez, quien recientemente ha recibido varios reconocimientos a su trabajo como docente en un colegio distrital de Bogotá, en particular en lo relacionado con educación sexual.

En el libro cuenta en primer lugar cómo fue su experiencia personal con la educación sexual, tanto en el colegio como en el hogar, y luego en la universidad, con la ventaja adicional de poder analizar, en retrospectiva, qué tipo de educación era, qué enfoques tenía (de moralista, a puramente biológico, a enfocado a prevención de ETSs), y de qué cosas carecía (hablar acerca del componente afectivo, del componente erótico). Menciona también un evento a primera vista fortuito, pero que tuvo bastante impacto en su carrera: tener acceso en su adolescencia a un ejemplar de La sexualidad humana, de Masters y Johnson.

Otra de las secciones del libro presenta su trabajo en el colegio Gerardo Paredes, específicamente la construcción del plan curricular para la clase de educación sexual, para los distintos cursos. Una de las ideas centrales de esa construcción fue involucrar a los estudiantes, identificar cuáles son sus dudas y necesidades. También fue una de las principales dificultades, por la desconfianza que los estudiantes tienen de los los adultos como fuente de información, en lo que tiene que ver con sexo.

Fue muy interesante ver el análisis de esos problemas iniciales, ver de dónde viene esa desconfianza, y luego ver el resultado del proceso, para los distintos cursos/grupos etáreos:

Para adolescentes, la virginidad, la pornografía, dudas acerca de distintas prácticas sexuales, planificación/anticoncepción, y la dimensión erótica del sexo en general.

Para niños en bachillerato (grados octavo hacia abajo), la temática está alrededor del auto-descubrimiento, la masturbación, los cambios en el cuerpo debidos a la pubertad. Y también, identifica en esa exploración que debe incluir la temática del abuso sexual.

En primaria el foco está en desaprender muchas de las violencias de género/estereotipos/discriminación que adquirimos básicamente como parte de nuestra cultura, sin ser realmente conscientes de ello.

Complementando esas secciones más «estructuradas» del libro, hay varias otras con anécdotas, casos de estudiantes particulares y cómo ponen a prueba la capacidad del profesor, y del colegio, para afrontar los imprevistos/situaciones tan sorprendentes en las que terminan involucrados, y otras misceláneas pero no por eso menos interesantes, como examinar el concepto de clase/riqueza/pobreza que tienen los estudiantes, y hacer que reflexionen sobre ello.

Es un muy buen libro, y se lee fácil y rápido ---lo leí en una noche---. Mi única crítica va al estilo/edición del libro; tiene uno que otro gazapo (nada inesperado), pero en donde siento que de verdad faltó trabajo adicional fue en tener voces/personas consistentes en las distintas secciones del libro: en ocasiones habla el profesor en primera persona, en ocasiones el texto se estructura como diálogo, en otras ocasiones en tercera persona. Pero es un detalle menor, y no afecta el contenido/legilibidad/mensaje.

Muy recomendado.

Code style

This is an idea I noticed in a response at a tweet from @garybernhardt.

Indenting with tabs, spaces, two or four spaces, where do you place the opening/closing braces, how do you break long lines, whether you place spaces or not around operators, and in which contexts, how many white lines you place between class declarations, all of those things, should be irrelevant. All of those are just visual aids, which:

• Should not show up in your diffs, when you are reviewing a pull request from somebody.
• They should be ignored by your version control system; any commit that merely changes whitespace/formatting is a non-change, since nothing changes functionally.
• You should be able to tell your IDE how you want to look at the code, what code style you want to use. Yet that should not provoke/show up as a change (a commit) in your VCS.

Files

Your IDE should take care of creating/naming files. It should also take care of where to put the things you create as a programmer: globals, functions, classes, modules, etc.

Ideally, your only responsibility should be telling your IDE what's your module structure. It should deal with the rest.

Also, your VCS should stop caring about files. We don't need to know that 'a file was renamed', we also don't need to know that 'a function was moved from this file to that file', if it didn't change.

But, 'a function was moved from this module to this other module' is something I do care about. As I also care about 'all the changes made to this single function'. Perhaps the VCS should version not files, but a standarised, machine friendly, machine-diffable version of the code we write. The IDE, or your VCS should know how to generate those for you, automatically. Possibly the IDE would be a better fit, and the VCS should just be considered a dumb storage, versioning a standarized representation of the code generated by the IDE.

Code analysis

Before, and mostly because of this article from Joel Spolsky, and my own experience as a reviewer, I tried to avoid exceptions, and preferred error codes, because error codes:

• Are visible to the reader.
• Their handling (or lack of thereof) is visible to the reader.

Because of that, you don't have to zip around your whole codebase when reading some piece of code in order to check whether a method throws an exception or not, and the opposite situation, to check all of the places where an exception is handled, and figure out which one of those is the one calling the function you are reading right now.

Writing exception-based code does give you clean code, with centralized/localized handling of errors (when used properly). You basically end up with the code that handles the happy path, in a single place, and code for handling the possible errors, somewhere else, wherever the exceptions that might be raised are handled. But, that code is awfully hard to read with our current tools, because all of that error handling is littered over so many different files/places in your project, many times even with no obvious connection of how to get it, because many "final" exception handlers (like, for example, DRF's custom exception handlers) are defined dynamically, just by putting a class name in a string in a settings file somewhere... you will not find them by just following the call chain, when reading the code.

But, that is a limitation from our current development tools, nothing more. All in all, I think exception-based code is better than error-status-based code, fundamentally because a dead program is better than a limping program, and exceptions guarantee you that if you did not handle them, your program crashes, (and you get to see the stacktrace of when it crashed) instead of carrying on with God-knows-what you get after something fails and somebody didn't handle that error code properly.

As for reading exception-based code, I wish I was able to ask to my IDE to:

• Show me what non-runtime exceptions a given function raises, which is of course the aggregate of whatever exceptions it, or its callees, raise. (This is one of the things that I think Java got right, the compiler tells you that, and the language has the concept of runtime errors and business-logic-related exceptions, ...)
• Show me the call tree of a given function: who calls it, who calls its caller(s), and so on and so forth until hitting either main or whatever is the boundary for the framework I'm using: e.g., a Rails controller, a Django view, etc.
• Show me all of the places where a given exception (or its ancestors) is handled. And show that somehow in the call tree.

Also related, and occasionally useful, is being able to see the (for lack of a better name) reverse call tree of a function: which functions it calls, which functions those functions call, and so on and so forth. Of course skipping (optionally) the core language/framework stuff.

When analyzing a function, it would also be nice to be able to ask the IDE to show you the dependencies of a variable: where has it been changed in the current function so far (something function-aware, not just a find-in-file), and which other variables/expressions are used to calculate this variable.

Testing

Somewhat related to the code analysis section; I should be able to modify something in the codebase, and have my IDE to run only the affected tests, and no others. The IDE should figure out where what I modified is tested, maybe from coverage information from previous test runs/static analysis/whatever.

Un par de veces terminé metido en restaurantes costosos, en donde la comida era tan maluca, el servicio tan malo, y todo tan caro, que no podía atribuir la experiencia sencillamente a la mediocridad y pereza de los involucrados; no, era tan absurda la situación, que me hacía pensar en una broma práctica: «están haciendo esto a propósito, es un experimento social, a ver qué tantas estupideces tolera la gente, antes de mandarlos a la porra, a ver cómo racionalizan gastarse tanta plata en algo a todas luces malo». La versión consumista del experimento de Milgram.

Leer este libro de Amelie Nothomb se sintió igual a estar en uno de esos restaurantes.

posdata: incluso comprar el libro hizo parte de la experiencia. En la librería fuimos asaltados por una artista en una exposición de su obra allí, que quería convencernos de comprar sus manteles floridos manchados de pintura por cinco millones de pesos la unidad.

Pensé que me gustaba uno de sus trabajos, hasta que noté que estaba mirando el estampado de la tela que ella usó como lienzo...

This is a novel about first contact with another sentient species, the Moties. I ended up reading it because of this handy chart that helps your choose which popular sci-fi book you should read.

Overall I liked the book. I miiiiight re-read it. Not great, but a good read.

This alien race has some rather interesting features ---although maybe constraints is a better word for some--, some of them not really believable, but nothing that makes the book inedible. Things like the mechanics of travelling between star systems of this universe are quite interesting. Even more so is the depiction of the politics of that first contact: deciding what you want the other race to see, what don't, why do or do not, and how to get your population to play along with the charade; in the book you get to see that from both the Motie and the human side. Also, the plot twists are really really good: unexpected, yet congruent with the story.

But, the thing I liked the most was the discussion of a particular aspect (I would dare say central) of the Motie's psychology: Crazy Eddie.

For a variety of reasons, hope is something the Moties feel very rarely, and express even less. It is not frowned upon, but at least is considered very weird/unusual by them.

So, when the Moties talk about certain things, like their sending a hibernating Motie in a space probe to the nearest habitable star system (which they suspect is inhabited, and actually is, by humans), in a trip of hundreds of years, in order to establish contact, or about that particular point in space in their star system which might allow them to travel instantaneously to the closest star, but from which none of their ships has ever returned (because the endpoint for that trip lies inside the closest star, and their ships are immediately destroyed upon arrival), they refer to those things not with adjectives (such as hopeful), but reaching for an archetypal Motie they call "Crazy Eddie", who in their stories is prone to that kind of behaviour. So you have the Crazy Eddie probe, the Crazy Eddie point, etc.

They also say that about plans, ideas, and even certain Moties: that's Crazy Eddie, he's Crazy Eddie, they are Crazy Eddie. But humans are also Crazy Eddie, all of them.

It's only after seeing many times how the Moties use the expression "Crazy Eddie" that it dawns upon you they are talking about hope. Regardless of all their technology, advanced social and intellectual capabilities, they are not given to attempt things based (to a large extent) on hope. To feel/believe something that (quoting from Wikipedia) "serves as a promise or reason for expecting a better future".

Their biology forces them to live an eternal cycle of development, overpopulation, and catastrophic war; you can't really blame them for not expecting a better future, and for mocking those who do, and labelling them and their ideas "Crazy Eddie". That's what I liked the most from the book: learning how they feel about hope by the very absence of that concept in their language, and watching them getting "infected" by hope from the visiting humans that interact with them.

Just as as side note, in this universe, the Russians and the Americans seem to have ended the Cold War not by attrition, but by joining forces/becoming a single government. I don't remember if the authors explain that explicitly in the book, but it becomes quite obvious when you see characters with last names like Kutuzov, and when you see spaceships called MacArthur or Lenin.

Un abogado desempleado es abandonado por su gato, y poco después por su esposa.

Después de un tiempo al abogado le sale una mancha enorme en la mejilla, y encuentra trabajo permitiendo que riquillos laman su mancha hasta inducirle un orgasmo.

Con los ingresos que obtiene de su peculiar ocupación, consigue comprar un terreno con un pozo seco, que usa para conectarse al Internet de los Espíritus (TM), en donde pasa la mayor parte de su tiempo buscando a (el avatar de) su malvado cuñado (responsable del abandono de su esposa) en ese mundo virtual.

El abogado logra provocarle un ataque (cardiaco/cerebral/no recuerdo) a su malvado cuñado, a través de sus acciones en el Internet de los Espíritus (TM). Luego de esto, su esposa asesina a su hermano en el hospital (al vegetal que quedó luego del ataque sufrido a «manos» del abogado), y va a prisión. El abogado espera su regreso.

La mancha en la cara del abogado desaparece después de atacar a su malvado cuñado, quedando así desempleado de nuevo.

...

Un poco más en serio, en el libro hay descripciones bellísimas de la soledad del abogado.

The book was kind of meh. The British aristocracy was deposed by the "intellectual class" (thanks to the development of the Analytical Engine), and the former aristocrats plot to take their position back. In this version of history, the British Empire is stronger than the original one; it ended up allied (kinda) with the French Empire, and so America is more of a mess, with colonies, and small republics here and there. But none of that really makes a difference because everything happens in London/Paris. I did not really "feel" anything different because of that early development.

The characters chase one another trying to acquire the book's MacGuffin, a set of punched cards (apparently written by Ada Lovelace) containing what might be either:

• The perfect mathematical/statistical model for placing bets (the Modus).
• A computer virus, possibly the first of its kind.
• An example program demonstrating/exemplifying the Incompleteness Theorem, discovered in the 19th century thanks to the early development of computing.

This happens in three sort-of-related stories, each with its own main character, each dealing in some way with the mess created by the punched cards, or the people trying to acquire them for $WHATEVER_REASON.

However, the book made me curious about some things. So.

Things I learned thanks to the book (or, more exactly, wikipedia pages I read because of it):

• Isambard Kingdom Brunel. I had already heard about him here, but did not bother to check what he did. Now I did, it was interesting.
• London doesn't seem to have decent air quality
• The Japanese build (since a while, it seems) human-like automatons: Karakuri_puppet

Finally, what is it with William Gibson? Does he have to have a computer becoming sentient in every one of his books? Meh.

Having a way of importing a single class/function into the current file/module:

# ---------- A.py -------------
class MyClass:
    ...

def my_func():
    ...

# ---------- B.py -------------
from A import my_func

my_func()

The language support for named arguments, and variable number of arguments, specially when calling functions with many arguments:

def my_func(a, b, c=2):
    print(a, b, c)

my_func(0, 1, 3)
# 0 1 3

my_func(0, 1)
# 0 1 2

my_func(0, b=2, c=4)
# 0 2 4

my_func(b=2, c=4, a=0)
# 0 2 4

The awareness in the community (and by extension in the documentation and other online resources) about how to handle bytes vs. strings in your program. Precious little other languages take care of talking about this.

The handling of negative indexes for lists, and the range() method for generating sequences. Some other languages have syntax for ranges, but they end up being either more limited, or unfriendly in non-standard situations (I'm looking at you and your handling of negative endpoints in ranges, Elixir.)

Also, IPython, and its automatic module reloading.

You cannot behave like a militant atheist all the time. The idea of God/Gods/the supernatural is important to most of us, because you can find strength, relief, resolution, even joy in it. In the most intense times of your life, it helps you cope with the magnitude of reality. So don't be an asshole to people who believe in some God. They need the idea. You might need it, only you haven't been unfortunate enough to ending up there (or fortunate enough, some might say).

As Regina Spektor puts it:

Religion might be valuable as a personal thing. As a social/public institution, it must be destroyed. We are long past due realizing that we don't need it to define our ethics/moral, that the state is now (must be) capable of providing all the social services associated to its institutions in the past, and that we are better off without those potential (and many times actual) nurseries of fascism.

We need to be done with those creepy groups of people that already know what's good and proper for everybody and will ram their ideas of the world down all of our throats.

As Regina Spektor puts it:

(Comments? email me! jerojasro AT devnull.li)