Libro: Piano. La historia de un Steinway de gran cola

Titulo: Piano. La historia de un Steinway de gran cola.
Autor: James Barrow 
Editorial: Alba 

Qué pasada de libro.
Imagino que no todo el mundo lo verá así, pero para mi, leer esta obra está al nivel de catarsis tras años de clases de piano practicamente olvidadas (más por imposibilidad de practicar que por desgana). Ha supuesto volver a escuchar las obras de Beethoven, Bach, Tchaikovsky o Rachmaninov con un interés adicional y un conocimiento orgánico del instrumento en si y de su historia (sin ser más que aficionado, ojo). Y ha supuesto volver a avivar con mi interés de la niñez por dos fabricantes de instrumentos: Steinway y Stradivari.
Puede que a quien no haya estudiado piano, o a quien no le interesan la fabricación (diseño, avances técnicos…) de instrumentos (no solo los musicales) no le parezca una obra tan buena, pero desde luego, es una buena obra. De ello se encarga James Barrow (perfectamente traducido), que transpira calidad al narrar el relato, ejerciendo como dios manda el oficio de periodista.
Retrospectivamente, es posible que leer este tipo de obras (aun tengo pendiente la reseña del de violín) me hubiesen animado más y mejor en el aprendizaje de un instrumento, pero esa historia ya es agua pasada, y a día de hoy su lectura me anima a educar en lo musical y en lo científico/técnico a mi hija. Así que si eres un nuevo estudiante de música (no exclusivamente de piano), un viejo aficionado, un fan de la música clásica, un fabricante de herramientas (desarrolladores de software incluidos), o incluso un aspirante a empresario, deberías leer este libro.
El siglo de historia que narra, nos acerca, no solo a la fabricación de un instrumento de precisión moderno, sino a la historia de una empresa, la de los cambios tecnológicos y económicos acaecidos, y la relación del hombre, del especialista, con sus herramientas.
Como hay más y mejores críticas en lugares como Amazon http://www.amazon.com/Piano-Making-Steinway-Concert-Grand/dp/0805078789, lo dejaré aquí, solo para recomendarlo encarecidamente y para poner las habituales citas interesantes.

La RCA comercializaba la marca de radios más vendida en la nación y Sarnoff comprendió lo que podían ofrecer: entretenimiento con solo girar un botón… No hacían falta ni clases ni talento y las radios eran más baratas que los pianos, que los Steinway en particular. [Tras haber sobrevivido al fonógrafo y al tocadiscos…] en 1933 dos terceras partes de los hogares estadounidenses tenían receptor de radio.

-o-

Incluso los clientes que querían comprar un piano de cola no querían modelos grandes. Las casa adosadas iban desapareciendo en Nueva York y, en su lugar, surgían edificios de apartamentos. Henry Z. Steinway nación en un piso del edificio que se erigió en el solar de la Cuarta Avenida que ocupaba la primera fábrica Steinway. Lo que mantuvo a Steinway & Sons cuando la gente tuvo que conformarse con viviendas más pequeñas que las casas adosadas de sus padres fue el modelo M, un piano de cola que empezó a fabricarse en 1912 y que medía un metro menos que los gran cola como el K0862 (el protagonista del libro, un modelo D).

-o-

El problema de los pianos es que son orgánicos y cambian constantemente. No tienen nada que ver con la fabricación de neveras y cosas así.

-o-

[Acerca del ajuste de cuerdas en el piano] Utiliza una herramienta que tiene una especie de gancho al final y tira con fuerza. “Algunos llevamos pinzas de médico, de las que usan para cortar hemorragias, que parecen unas tijeras largas”, dice. Se refiere a las pinzas de hemostasia; algunas tienen dientes en los filos y vienen muy bien para tirar de las cuerdas.

Anuncios

Code as Design: Three Essays by Jack W. Reeves

 
 
 
Por alguna razón tengo en la recámara desde hace meses una versión alternativa del artículo sobre La programación como proceso de diseño. Y como creo que es bastante diferente del “original”, además de que siempre es buena idea hablar sobre desarrollo de software, lo añado a continuación. 
 
🙂
 

Code as Design: Three Essays by Jack W. Reeves

Estos ensayos con casi veinte y diez años de antiguedad, siguen siendo una verdad como un templo y comenta cosas que la mayoría de las personas en el mundo del software ignoran (y olvidamos), con consecuencias negativas a corto, medio y largo plazo.

El punto clave del ensayo es que desarrollar código, es un proceso de diseño, y es uno muy complicado.

Siempre se compara el desarrollo de software con otras ingenierías donde se diseña y construye algo físico. Pero es incorrecto. Si hacer aviones se pareciese a hacer software, entonces pulsando un botón, los planos y especificaciones de un Boeing 747 se convertirían en un avión real y en pleno vuelo en cuestión de segundos o minutos a coste cercano a cero. Si se tratase de hacer puentes, el F5 nos permitiría levantar un puente para comprobar cuanto peso aguanta con pilares de un material u otro en el mismo tiempo y al mismo coste.

La naturaleza de las ingenierías “normales” es construir algo en base a unas especificaciones. Algo caro de diseñar, pero muchisimo más caro de construir (tiempo, recursos, gente). En software la “build“, es decir el producto final construido, es cuestión de un compilador y un par de minutos (o segundos). Lo realmente caro es el diseño, y el diseño (especificaciones, planos…) es el código. Construir en base al diseño es labor del compilador y al contrario que en todas las demás ingenierías, tiene un coste en tiempo y dinero cercano a cero.

Partiendo de esa premisa, es fácil de donde vienen ciertos problemas, como las especificaciones mutantes, el scope creep, etc.


A continuación dejo algunas citas interesantes.

 

Revelation number two: it is cheaper and simpler to just build the design and test it than to do anything else. We do not care how many builds we do—they cost next to nothing in terms of time, and the resources used can be completely reclaimed later if we discard the build. Note that testing is not just concerned with getting the current design correct, it is part of the process of refining the design. Hardware engineers of complex systems often build models (or at least they visually render their designs using computer graphics). This allows them to get a “feel” for the design that is not possible by just reviewing the design itself. Building such a model is both impossible and unnecessary with a software design. We just build the product itself. Even if formal software proofs were as automatic as a compiler, we would still do build/test cycles. Ergo, formal proofs have never been of much practical interest to the software industry.

-o-

The overwhelming problem with software development is that everything is part of the design process. Coding is design, testing and debugging are part of design, and what we typically call software design is still part of design. Software may be cheap to build, but it is incredibly expensive to design. Software is so complex that there are plenty of different design aspects and their resulting design views. The problem is that all the different aspects interrelate (just like they do in hardware engineering).

-o-

[…] no other modern industry would tolerate a rework rate of over 100% in its manufacturing process. A construction worker who can not build it right the first time, most of the time, is soon out of a job. In software, even the smallest piece of code is likely to be revised or completely rewritten during testing and debugging. We accept this sort of refinement during a creative process like design, not as part of a manufacturing process. No one expects an engineer to create a perfect design the first time. Even if she does, it must still be put through the refinement process just to prove that it was perfect.

-o-

The software design is not complete until it has been coded and tested. Testing is a fundamental part of the design validation and refinement process. The high level structural design is not a complete software design; it is just a structural framework for the detailed design.

-o-

It would be nice if high level software design could be a more rigorous engineering process, but the real world of software systems is not rigorous. Software is too complex and it depends on too many other things. Maybe some hardware does not work quite the way the designers thought it did, or a library routine has an undocumented restriction. These are the kinds of problems that every software project encounters sooner or later. These are the kinds of problems discovered during testing (if we do a good job of testing), for the simple reason that there was no way to discover them earlier. When they are discovered, they force a change in the design. If we are lucky, the design changes are local. More often than not, the changes will ripple through some significant portion of the entire software design (Murphy’s Law). When part of the effected design can not change for some reason, then the other parts of the design will have to be weakened to accommodate. This often results is what managers perceive as “hacking”, but it is the reality of software development.

-o-

As just a small point, all programmers know that writing the software design documents after the code instead of before, produces much more accurate documents. The reason is now obvious. Only the final design, as reflected in code, is the only one refined during the build/test cycle. The probability of the initial design being unchanged during this cycle is inversely related to the number of modules and number of programmers on a project. It rapidly becomes indistinguishable from zero.

-o-

The generally accepted definition is that a “specification” states the what, which is followed by a design document that details the how. While there is a certain amount of flexibility allowed of the compiler in determining the how of object code, there is certainly no creativity involved. And that is where I draw the line. When the document is detailed enough, complete enough, and unambiguous enough that it can be interpreted mechanistically, whether by a computer or by an assembly line worker, then you have a design document. If it still requires creative human interpretation, then you don’t.

-o-

Back to software. We in the software industry also refine our designs, only we don’t get to call it engineering. We call it “testing and debugging”. This phase of the software lifecycle takes a long time. All too often it takes longer than planned. Unfortunately, it is often not enough and the final designs that we turn into deliverable software are still not as good as they should be. This seems like a fact of software life. Many people lament it and ask why we software developers do not “engineer” our designs better? Many explanations are offered, but never the one most obvious to me — simple economics. Software is dirt cheap to build.

-o-

I suspect that most engineers in other disciplines haven’t a clue about what percentage of their time is spent actually creating a design and what is spent on testing and debugging the result. Some industries are probably better than software. I am pretty sure that other industries are actually much worse. Consider what it must take to “design” a new airliner.

-o-

I get somewhat testy when people start making gratuitous comparisons between software design and other engineering disciplines. Major microprocessors have been shipped with bugs in their logic, bridges have collapsed, dams broken, airliners fallen out of the sky, and thousands of automobiles and other consumer products recalled – all within recentmemory and all the result of design errors.

-o-

The bottom line is that my design must be correct, or every piece of software built from it will be erroneous. Therefore I concentrate on doing it right, and it takes mental effort and skill, just like any other creative design activity.

-o-

Even the best of the traditional approaches continue to try to break software design into disjoint steps with separate notations and products, and then they continue to wonder why they have problems getting a final software product that is correct.

-o-

Same thing. Likewise, Warner-Orr diagrams, Booch diagrams, object diagrams, you name it. Each has its strengths, and a single fundamental weakness – it really isn’t a software design. Ultimately, improvements in programming techniques are overwhelmingly more important to software development than anything else.

Libro: Matar a un elefante



Titulo: Matar a un elefante
Editorial: Turner

“Matar a un elefante” es una crónica de Orwell de cuando servía a Su Majestad en la India. Y es la crónica que muy acertadamente da nombre a este conjunto de artículos y crónicas del escritor aglutinadas en formato libro.

No se trata de un libro especialmente interesante, pero dada la variedad de textos y el intervalo temporal que abarcan, puede resultar suficientemente interesante para los admiradores de Orwell que quieran saber algo más de el como pensador de su época y no solo como escritor de ficción (si no has leído 1984 y Rebelión en la Granja, ya estás tardando).

A mi en particular me ha parecido bastante prescindible, a excepción del primer relato, el del elefante que tiene que sacrificar (o ejecutar, según se mire) bajo la opresiva mirada de los aldeanos y que da que pensar sobre la importancia del entorno y las circunstancias en los actos de cada uno, muy al estilo de Philip Zimbardo en El Efecto Lucifer. El resto de capítulos creo que me los podría haber ahorrado, aunque no está de más leer sus opiniones sobre la Segunda Guerra Mundial y la Guerra Civil Española (la del 34).

A continuación, algunos extractos de muestra:


[Sobre la Guerra Civil Española] Los fascistas ganaron la guerra porque eran más fuertes. Disponían de armamento moderno que el otro bando no poseía. No hay estrategia política que pueda paliar tal deficiencia.


-o-

Los llamados dominios de habla inglesa […] son rehenes que están en manos de Norteamérica. Por lo tanto, siempre existe el poligro de que Estados Unidos rompa toda coalición europea, arrastrando a Gran Bretaña fuera de ella.


-o-

Los pueblos de Europa, y en especial los británicos, desde hace mucho deben su elevado nivel de vida a la explotación directa o indirecta de los pueblos de color, Esta es una relación que nunca se ha aclarado debidamente en la propaganda oficial del socialismo, y el trabajador británico, en vez de recibir el mensaje de que, según la media mundial, vive por encima de sus posibilidades, ha sido aleccionado para pensar que es un esclavo que trabana en exceso y que está pisoteado por el patrón. Para las masas, el “socialismo” significa o al menos se relaciona con salarios más altos, jornadas laborales más cortas, viviendas mejores, seguridad social para todos, etc. Ahora bien, de ninguna manera es seguro que sea posible financiar tales ventajas si se prescinde de los beneficios que acarrea la explotación colonial.