Archive | octubre 2012

En el principio… fue la línea de comandos

En el principio… fue la línea de comandos

Neal Stephenson

Por qué lo he leído

Había oído hablar de este libro en la universidad, y me picó la curiosidad, pero nunca me había decidido a encontrarlo y leerlo. Pero hace poco, viendo uno de los hangouts de Desarrollo Web, lo comentaron y no perdí ni un minuto. Lo descargué y a leer se ha dicho.

Qué esperaba

No recuerdo muy bien qué esperaba. Siempre había oído hablar de este libro en contextos de sistemas operativos, ordenadores antiguos. Temas más bien históricos. Así que, lo que esperaba era una especie de Historia de los sistemas operativos

Qué encontré

Neal Stephenson cuenta una historia, la historia de los sistemas operativos, no hasta nuestros días, porque el libro tiene sus añitos, pero sí una historia que resulta bastante actualizada. La verdad es que todo aquello que cuenta sobre Apple y Microsoft, todavía sigue vigente hoy en día. Hay más actores, sí (Google por ejemplo), el hardware es muy distinto (móviles, tablets), pero la esencia persiste todavía.

Conclusiones

En definitiva, el libro me ha encantado. No es sólo porque el autor critica a varias super-empresas (que siempre gusta ver cómo reciben los poderosos), no es sólo por el tono de humor que usa Neal, no es sólo porque es un libro muy geek. Es por todo eso y además porque es un clásico, y sólo leyéndolo se entiende por qué es un clásico.

Si a eso le añadimos que lo puedes adquirir libremente y que está disponible una traducción al castellano, ya no hay escusa para no leerlo.

Un libro muy recomendable, que se puede leer de una sentada (o casi)

Pasajes que quiero recordar de este libro

Solo hay dos modos de vender un producto (software): precio y funcionalidades. Cuando los sistemas operativos son gratuitos, las compañías de sistemas operativos no pueden competir mediante precio, así que compiten mediante las funcionalidades. […] Esto explica por qué Microsoft añadió un navegador a su sistema operativo, por ejemplo.

Así como la interfaz de línea d ecomandos abre un canal mucho más direcot y explícito entre usuario y máuqina que la GUI, lo mismo suced con palabras, escritor y lector comparado con Disney (que es todo imagen)

La Disney y Apple/Microsoft están en el mismo negocio: cortocircuitar la laboriosa y explícita comunicción verbal con interfaces de disño caro.

El problema es que una vez que nos hemos librado d ela capacidad de juzgar lo bueno y lo malo, loverdadero y lo falso, ya no queda cultura. La capacidad de juicio, de creencia, es el fin mismo d etener una cultura.

¿Por qué triunfan Miscrosoft y Apple si nos engañan con sus GUI’s? Porque estamos demasiado ocupados hoy en día como para comprenderlo todo con detalle. Y es mejor comprenderlo por una interfaz, oscuramente, que no comprenderlo en absoluto.

Lo primero que hicieron los hackerrs de Apple cuando consiguieron que MacOS fuese funcional fue recrear la interfaz de Unix, para poder hacer algún trabajo útil. En aquel momento, en lo que concernía a los hackers de Apple, la muy pregonada GUI del Mac era un impedimento, algo a evitar […]

Unix es el hole hawg de los sistemas operativos.

Al tratar de comprender el fenómeno Linux tenemos que contemplar no a un único innovador, sino na especia de extraña Trinidad: Linus Torvals (por Linux), Richard Stallman (por las herramientas GNU) y Bill Gates (por el abaratamiento del hardware). Elimínese cualquiera d elos 3, y Linux no existiría.

A menudo, este tipo de archivos pueden encontrarse en un directorio con el nombre /src, que es la abreviatura hebraica del hacker para source, fuente.

Si hubiera algún ordenador, en algún lugar, que pudiera escupir unikversos con valores aleatoriamente escogidos para sus constantes fundamentales, por cada universo como el nuestro produciría 10^229 universos fallidos […] así que cada vez que tu meñique pulsa ENTER, lo estás intentando.

Otras lecturas y enlaces relacionadas

Anuncios

Enlaces de los martes (16 oct 2012)

Otro martes más con unos cuantos enlaces interesantes. Esta semana he recopilado temáticas muy diversas, desde temas técnicos (excepciones), hasta temas familiares (geek dads):

Lean software development

Lean software development

Mary Poppendieck, Tom Poppendiek:

Por qué lo he leído

Después de leer Scrum y XP desde las trincheras, me quedé con ganas de leer algún libro más de temática Agile, de desarrollo de software siguiendo prácticas lean. Me llaman mucho la atención las metodologías ágiles de desarrollo de software, y creo que son una buena alternativa a las metodologías tradicionales (aunque voy descubriendo otras como FDD que parecen igualmente interesantes).

Busqué un libro antiguo, alguno donde pudiera leer los inicios de estas metodologías, para así poder contextualizar todo lo que escucho y leo de las metodologías ágiles a diario.

Qué esperaba

Esperaba un libro dedicado exclusivamente al software, que expusiera ideas que podían parecer pasadas de moda, pero que siguieran de actualidad en algún sentido.

No había oído nunca nada de los autores, así que tampoco me había formado grandes espectativas, simplemente, quería conocer los inicios de las metodologías ágiles.

Qué encontré

Me encontré un libro muy útil, y aunque es de hace bastantes años (para tratar sobre desarrollo de software), es de total actualidad. De hecho, me sorprende que todavía haya empresas, personas, organizaciones, que no hayan oido hablar de los conceptos que se hablan en el libro.

Conclusiones

Me sorprendió mucho que el origen de las metodologías ágiles esté en la industria de la manufactura. Me parece difícil que una metodología haya pasado de esa industria a la del desarrollo del software. Pero como indican los autores (y es la idea principal del libro), no se pueden transladar prácticas de un entorno a otro, hay que transladar principios (ideas) y crear las nuevas prácticas para el nuevo entorno.

Y es de lo que trata este libro, de exponer una serie de herramientas, un toolkit, para ayudar a comprender y a transladar una serie de principios, que está demostrado que funcionan en una industria, al desarrollo del software.

Otras lecturas y enlaces relacionadas

Pasajes que quiero recordar de este libro

Los siete principios del pensamiento Lean:

  1. Elimina desperdicios
  2. Amplifica el aprendizaje
  3. Decide tan tarde como sea posible
  4. Entrega tan rápido como sea posible
  5. Fortalece al equipo
  6. Trabajar para que haya integridad
  7. Centrarse en el todo

Cualquier cosa que no crea valor para el cliente es desperdicio. Y, sí, los defectos (bugs, incidencias, …) son desperdicion.

Es difícil encontrar control sin realimentación (feedback), porque la realimentación de mucho mejor control y determinismo que complicados procesos de control con algoritmos predefinidos.

En la mayoría de los casos, incrementar la realimentación, en lugar de reducirla con rigurosos procesos secuenciales, es la forma más efectiva de lidiar con entornos y proyectos de desarrollo de software en problemas.

Set-based software development: se desarrollan varias alternativas, se comunican las restricciones (en lugar de las soluciones) y se deja que la solución emerja cumpliendo todas las restricciones.

Retrasar decisiones irreversibles mientras se reduce la incertidumbre tiene valor económico. Esto lleva a tomar mejores decisiones, limita los riesgos, ayuda a gestionar la complejidad, reduce el desperdicio y hace felices a los clientes.

Los procesos de desarrollo ágiles se pueden entender como la creación de opciones que permiten retrasar las decisiones hasta que las necesidades del cliente son mejor entendidas y haya menos riesgo.

Los marines planifican, pero no predicen. Comprenden la esencia de las situaciones, buscan simplificar las suposiciones y alternan aproximaciones. Cuando entran en una misión, la estructura organizativa se diluye, y aquellos que están en el frente, quienes tienen acceso a la información más directa, son los responsables de tomar las decisiones.

El principio ‘entrega tan rápido como sea posible’ complemente a ‘decide tan tarde como sea posible’. Cuanto más rápido entregues, más podrás retrasar tus decisiones.

(hablando de los pull systems) en lugar de planificar, sistemas como Kanban consiguen que los jefes no intervengan porque cada persona sabe qué hacer en cada momento.

Creemos que transferir prácticas de un entorno a otro es, casi siempre, un error. En lugar de ello, uno debe entender los principios fundamentales detrás de las prácticas y transformar esos principios en nuevas prácticas para el nuevo entorno.

El mejor modo de mantener el conocimiento sobre un sistema y que sea mantenible es entregar, junto con el código, un conjunto de tests automáticos, complementados por un modelo superficial de alto nivel creado al final del esfuerzo inicial de desarrollo.

Integridad conceptual significa que los conceptos centrales de un sistema son vistos contínuos, como un todo cohesionado. La clave para alcanzarla es la efectividad en los mecanismos de comunicación desarrollados por los grupos que conforman el sistema según se van tomando las decisiones que afectan al resto de grupos.

¿De dónde ha tomado la genete la idea de que todo buen diseño ocurre al inicio de un proyecto? Mucha gente encargada de desarrollar productos entiende que los grandes diseños evolucionan con el tiempo.

¿Refactorizar es rehacer el trabajo? Mejorar un diseño durante el proceso de desarrollo no es rehacer el trabajo, es una buena práctica de diseño.

Los tests proporcionan una base en la que apoyarse para que los desarrolladores realizen cambios a lo largo de todo el proceso de desarrollo.

La metodologías tradicionales de desarrollo software tienen la manía de medir tareas complejas y desestructuradas a través de partir la tarea en otras más pequeñas. La forma de estar seguro de que todo está medido es mediante agregación, es decir, mover la medida a un nivel superior, no a un nivel inferior.

Un contrato con precio fijado donde el vendedor espera obtener beneficios de los cambios pedidos, combinado con mecanismos rigurosos de aceptación de cambios para controlar el gasto, puede doblar aproximadamente el coste y tiempo que se tarda en desarrollar un proyecto a la vez que produce un resultado de pésima calidad.

Un contrato de precio flexible está diseñado para lidiar con la incertidumbre y complejidad, pero esto no elimina el riesgo, sino que lo traslada del vendedor al cliente.

Enlaces de los martes (02 oct 2012)

Seguimos, un martes más, con una recopilación de los enlaces que me han parecido más interesantes, espero que a vosotros también os gusten:

  • Los desarrolladores odian las tareas sin valor (inglés), de Java Code Geeks: artículo donde el autor explora las razones de por qué los programadores odiamos las tareas sin valor (o que percibimos que no aportan valor) por ejemplo: una tarea repetitiva, una tarea que debemos hacer cada cierto tiempo, trabajo que antes de estar terminado alguien decide que ya no es necesario.
  • Comunicación productiva en equipo, de Think Wasabi, vía El Canasto: qué importante es una buena comunicación en un equipo. Descubre unos consejos para comunicarte mejor con tus contactos, ya sean del trabajo o no.
  • 6 ventajas de FDD frente a Scrum, de Javier Garzás: en el post anterior acerca de enlaces interesantes, dejé 2 de Javier acerca de la metodología FDD (Feature Driven Development), así que no podía dejar pasar este otro post acerca de esa metodología. Esta vez la compara con Scrum, una metodología ágil mucho más conocida y extendida, pero no por ello tiene que servir para todo tipo de proyectos. FDD se enfoca hacia un público muy distinto al de Scrum.
  • Cursos gratuitos de las universidades de Berkeley, Massachusetts y Harvard: no son simples cursos, creo recordar que son cursos académicos completos, es decir, un año de carrera en cualquiera de estas universidades. Los hay desde Introducción a Ciencia de Computadores (Computer Science) hasta temas tan punteros como Software as a Service (SaaS). Lo único no positivo que les veo es que son en inglés.
  • Groovy: The road map for the popular JVM language (inglés), de InfoWorld: Entrevista a los líderes de los proyectos Groovy y Graisç, Guillaume Laforge y Graeme Rocher respectivamente, donde comentan las futuras funcionalidades del lenguaje groovy y el framework web grails.
  • Prefiero github:pages a wordpress.com, de Roberto Vázquez: He descubierto el blog de Roberto a través de su post sobre la barcampes, y en particular, este post me ha gustado mucho. Me lo apunto como tarea, haré lo posible por tener tiempo para migrar mi blog de wordpress a github:pages, ¿por qué no?
  • Learnable programming (inglés), de Bret Victor, via Linking paths: según la fuente donde encontré el enlace, este es probablemente el ensayo técnico más importante del año, y la verdad es que promete. Fascinante lectura, en serio!