Mostrando las entradas con la etiqueta libros. Mostrar todas las entradas
Mostrando las entradas con la etiqueta libros. Mostrar todas las entradas

sábado, 21 de marzo de 2015

The Gervais Principle

Para aquellos a los que les gusta (o no pueden para de mirar) The Office y se ríen (o lloran) con Dilbert y están dispuestos a leer largo duro y parejo, y a pelearse con un inglés un poquito más difícil que la media:

The Gervais Principle, Or The Office According to “The Office”

Para tentarlos y de paso tenerlos a mano para cuando se necesite, dos botones de muestra:

hughMcLeodCompanyHierarchy compLifeCycle

Ojo que es más serio que lo que parece. Lo encontré leyendo el blog de Erik Dietrich, también recomendable para agregar al feed.

PD para cuando lean un poco de eso: yo me considero claramente un looser, y -creo- es fácil distinguir a los sociopaths (antes de que alcancen el nivel al que sólo ellos pueden llegar, si no pierde la gracia)... lo divertido es ponerse a discutir quiénes son los clueless. Tengan en cuenta que no todos son tan "puros" como Michael.

miércoles, 10 de febrero de 2010

Frases: principios y prioridades.

Los que sobreviven en este oficio son los que tienen prioridades y no principios.

Leída en El Juego del Angel, de Carlos Luis Zafón, novela que empecé a leer hoy para sacarme de encima el polvo de tanto picar código y que ya puedo recomendar tranquilamente (espero que siga tan bien como empieza).

Esto viene a reforzar aquello de que quien está atento encuentra máximas en cualquier lado, que es buen alumno aquel que busca un maestro, y cosas por el estilo.

Por cierto, paciencia, paciencia que ya voy a postear algo consistente… espero.

martes, 19 de mayo de 2009

1984

Puede que George Orwell (antes de empezar permítanme decirles que si no han leído 1984 han aprendido a leer para nada) haya cometido apenas un pequeño (en proporción) error con las fechas, después de todo. Digamos unos 30 años. O menos.

Pensaba en eso después de leer esta nota en público.es, de la que transcribo (qué viejo suena eso. Corto y pego, digamos) el primer párrafo:

Hace 24 años, Ivana P. cometió un delito por el que fue condenada y posteriormente indultada. Sin embargo, esta madrileña aún está pagando aquella deuda. Los detalles de los hechos por los que la condenaron aparecen relatados en la web del BOE, y después han sido clasificados en Google, el buscador que utiliza más del 90% de los internautas españoles. Aunque esta mujer ha presentado varias reclamaciones, la web sigue trayendo al presente aquella historia de hace casi un cuarto de siglo.

Orwell imaginó un Gran Hermano omnipresente y controlador. Puede que el ¿futuro? sea apenas sutilmente diferente.

Si bien es cierto que la red nos ofrece anonimato no es menos cierto que la línea entre el espacio público y el privado es, en algunos casos, confusa (claro ejemplo: Facebook), y en otros difusa.

Dejemos por un momento de lado los casos en los que los problemas puedan adjudicarse a la torpeza o ignorancia del propio navegante afectado. Son cada vez más los registros públicos por naturaleza -tales como las sentencias de los jueces- fácilmente rastreables vía buscadores. Se va conformando, con el paso del tiempo, el avance de la digitalización de la información y su anexión a la red, un gran repositorio (internet, no Google) que todo lo recuerda y todo lo publica.

Somos (y seremos cada vez más) conscientes de que teniendo disponible una memoria tan poderosa se nos cobra caro hasta el más pequeño desliz. Podría ser en el fondo de una foto inocente tomada durante una salida y publicada en el perfil de una amistad donde la señora (futura ex) encuentre por casualidad al marido peligrosamente cerca de la (futura ex) mejor amiga… un par de años después del incidente inmortalizado en unos y ceros (que, imaginemos, no pasó de una indiscreción inducida por el alcohol).

Lo que hacemos en público es público. El marido de la historia anterior poco tiene que reclamarle a Facebook sobre la desgracia de su matrimonio. Poco -creo yo- tiene que reclamarle Ivana P. a Google o al BOE la distribución de información absolutamente correcta (y pública por naturaleza), por más que afecte su vida cotidiana.

Una línea difusa… ¿y lo que hacemos en privado y es ventilado por algún torpe, indiscreto o vengativo observador? Pregúntenle si no a… (no voy a volver a cometer la torpeza de escribir otra vez ese nombre, por más visitas que genere).

El hecho objetivo es que, en público o en privado, cada vez hay más ojos alrededor nuestro, inocentes o no. Ojos que no sólo ven sino que también recuerdan. El hecho objetivo es que esa información, una vez liberada, es muy difícil de destruir.

¿Llegaremos al punto en el que la amenaza de una exposición descontrolada pese lo suficiente como para reprimir hasta el más mínimo atisbo de cualquier conducta que pudiese calificarse negativamente en el presente o el futuro? ¿Llegaremos al punto de sentirnos siempre observados y continuamente juzgados por lo que hacemos y decimos y por lo que hicimos o dijimos? ¿Presos de por vida en nuestras propias palabras y acciones pasadas?

Orwell imaginó un Gran Hermano, pero parece ser que nadie puede controlar, encauzar o reprimir el flujo de información en la red. El archivo afecta tanto a gobernantes y empresarios poderosos como a ilustres desconocidos.

Así, Gran Hermano, el gran represor, lo conformamos todos al juzgar socialmente y tomar decisiones basadas en esa información. ¿Sufre Ivana P. las consecuencias de la publicación de una condena o el hecho -innegable- de que pocos avalan con hechos la opinión expresada de que quien ha cometido un crimen puede (y merece) pagar sus deudas y vivir una vida honrosa de allí en más? ¿El marido porque la mujer ha descubierto esa foto o la imposibilidad -de ambos- de reconstruir la relación luego de eso? ¿Sufre el joven por la aparición de una foto que lo muestra pasado de copas o por el prejuicio del empleador que infiere de ella que es una persona poco seria (y que opina que la competencia va de la mano de la seriedad)?

Si, como decía antes, errare humanum est, tal vez deberíamos preocuparnos menos por la disponibilidad de la información histórica acerca de grandes y pequeños errores y momentos poco afortunados que por la interpretación y el uso que cada quien hace de ella.

Si encontrar cierta información sobre una persona en la red nos parece escandaloso deberíamos pensar por qué, qué esperábamos encontrar, y qué nos dice el hecho de que la estemos buscando (y las decisiones que tomemos en base a ella) sobre nosotros mismos y nuestros propios prejuicios.

lunes, 13 de abril de 2009

9 reglas para una mejor orientación a objetos.

Sebastian Hermida comparte unos posters y y folletos con las “9 rules for a better object orientation” inspiradas en el libro ThoughtWorks Anthology (hizo también algunas viñetas, la primera de ellas aquí).

En el artículo “Object Calisthenics” Jeff Bay propone el ejercicio de elaborar un programa de 1000 líneas siguiendo estas reglas estrictamente (verán que son terriblemente restrictivas) con el objetivo de mejorar la orientación a objetos de nuestro código.

Primero lean, luego seguimos con mi propia verborragia.

  1. Use only one level of indentation per method. If you need more than one level, you need to create a second method and call it from the first. This is one of the most important constraints in the exercise.

  2. Don’t use the ‘else’ keyword. Test for a condition with an if-statement and exit the routine if it’s not met. This prevents if-else chaining; and every routine does just one thing. You’re getting the idea.

  3. Wrap all primitives and strings. This directly addresses “primitive obsession.” If you want to use an integer, you first have to create a class (even an inner class) to identify it’s true role. So zip codes are an object not an integer, for example. This makes for far clearer and more testable code.

  4. Use only one dot per line. This step prevents you from reaching deeply into other objects to get at fields or methods, and thereby conceptually breaking encapsulation.

  5. Don’t abbreviate names. This constraint avoids the procedural verbosity that is created by certain forms of redundancy—if you have to type the full name of a method or variable, you’re likely to spend more time thinking about its name. And you’ll avoid having objects called Order with methods entitled shipOrder(). Instead, your code will have more calls such as Order.ship().

  6. Keep entities small. This means no more than 50 lines per class and no more than 10 classes per package. The 50 lines per class constraint is crucial. Not only does it force concision and keep classes focused, but it means most classes can fit on a single screen in any editor/IDE.

  7. Don’t use any classes with more than two instance variables. This is perhaps the hardest constraint. Bay’s point is that with more than two instance variables, there is almost certainly a reason to subgroup some variables into a separate class.

  8. Use first-class collections. In other words, any class that contains a collection should contain no other member variables. The idea is an extension of primitive obsession. If you need a class that’s a subsumes the collection, then write it that way.

  9. Don’t use setters, getters, or properties. This is a radical approach to enforcing encapsulation. It also requires implementation of dependency injection approaches and adherence to the maxim “tell, don’t ask.”

¡Ja! Dos preguntas: ¿Estas reglas llevan a una mejor orientación a objetos? ¿Qué opinan de seguir estas reglas a rajatabla en “la vida real”?

Yo creo que sí, que indudablemente llevan a una mejor orientación a objetos. En cuanto a la segunda pregunta, mi propia opinión se resume en aquel principio de diseño del BDFL Guido van Rossum:

“Lo pragmático gana a la pureza”.

Y que el ejercicio de aplicarlas estrictamente debería quedarse en eso: un ejercicio acotado a un sistema de más o menos 1000 líneas.

Si programar es como escribir, un sistema es como un libro: hay un argumento central con algunos pasajes magistrales, algunos secundarios que hacen a que la historia sea completa y coherente, y mucho relleno y lugares comunes que siempre –o casi siempre- tienen que estar. La proporción de unos sobre otros determinará la calidad del resultado final, que puede ir del folletín a la obra maestra.

Todo es cuestión de saber dónde y cuándo utilizarlas, porque conllevan cierto esfuerzo adicional. Aplicadas en las funcionalidades críticas del sistema (en aquellas más complejas o indefinidas que se llevarán el grueso de las horas de cambios y mantenimiento) supondrán un ahorro considerable y la diferencia entre el código que resiste las modificaciones (e incluso mejora con ellas) y el que cae sobre sí mismo como un castillo de naipes al viento, convirtiéndose en una masa desordenada de clases. Utilizadas obsesivamente a través de todo el sistema no es más que una pérdida de tiempo.

Las reglas son muy bonitas pero, como decimos a veces en el trabajo “hay que pensar, no queda otra”, todavía no encontramos el método que nos libre de eso… por suerte, porque ese día nos quedamos sin trabajo.

De todas maneras me llamó la atención el libro, habrá que conseguirlo.

miércoles, 4 de marzo de 2009

Mejorando el trabajo en equipo.

Saltando desde el blog de Sebastián Hermida me encontré en abetterteam frente a una buena implementación de una encuesta incluida en el libro Art of Agile Development, de James Shore y Shane Warden.

El cuestionario evalúa el estado de un equipo de desarrollo ágil (se basa en XP, aunque creo que podría aplicarse a otras metodologías, con algunas salvedades) en 5 aspectos: Thinking, Collaborating, Releasing, Planning y Developing.

Hay una corta serie de preguntas Si/No para cada uno de ellos. Al final se presenta un panorama general del estado del equipo y se sugieren prácticas ágiles concretas para mejorar los puntos flojos detectados. También propone la posibilidad de registrarse para evaluar el progreso del equipo.

La encuesta comienza aquí.

domingo, 28 de diciembre de 2008

Libros: Federico Frischknecht - Dirección Recursiva.

Una de mis últimas materias en la facultad fue Organización, a cargo de Pedro Basualdo (en la Facultad de Ciencias Económicas de la UBA, carrera de Sistemas, lástima que no encuentro algún sitio con información actualizada, si alguien lo conoce se agradece el dato), materia a veces criticada por algunos contenidos demasiado teóricos que costaba enlazar con el día a día.

Críticas que tenían su razón de ser, hay que reconocerlo. Recuerdo la sensación de "muy interesante, pero ¿y con esto qué?" con la que me quedé al terminar la cursada. No recordaba prácticamente ningún tema en particular, y sentía que no me había llevado nada en concreto.

Realmente mucho, mucho después (casi tres o cuatro años) algunas situaciones del día a día activaron un camino neuronal poco transitado que me condujo hacia ellos, y fue como una revelación.

Estoy hablando del terrible Federico Frischknecht con su Dirección Recursiva (ISBN 950-02-3624-9), uno de los libros más difíciles de entender con los que me topé, pero realmente increíble (hay un pequeño resumen referente al conflicto en las organizaciones a cargo del Lic. Guillermo Bilancio aquí).

El autor construye un sistema para representar la toma de decisiones en las organizaciones (una verdadera catedral), y lo utiliza luego para analizar sus elementos: el conflicto, el cambio, la crisis, la estrategia, etc.

Es (como toda construcción teórica) una herramienta, y ésto fue lo difícil de entender para mí en su momento. El libro no tiene recetas ni guías ni respuestas, sino un marco teórico para analizar a las organizaciones que tendremos que aprender a utilizar para que nos sea útil.

lunes, 27 de octubre de 2008

Indexed

Vía Malas palabras caí en Indexed, un blog en el que la autora, Jessica Hagy... no sé cómo describirlo, supongo que ahí está la gracia. A continuación un botón de muestra, el resto véanlo por ustedes mismos.

jueves, 16 de octubre de 2008

La biblia del desarrollo de software.

Frederick Brooks

Algunos parrafitos robados citados de Las bases de la gestión de proyectos software y los mitos del "hombre-mes", comentario en kybele consulting del mítico libro de Frederick Brooks:

Brooks (1931) fue director del desarrollo del famoso OS/360 de IBM, y a raíz de sus experiencias, éxitos y fracasos escribió “The Mythical Man-Month: Essays in Software Engineering” (aqui la reedición 20 aniversaro de 1995), libro al que deben su mayor fama, aunque no suficiente, frases como:

  • “Añadir recursos humanos a un proyecto con retraso provocará un retraso mayor”.
  • “En un proyecto la figura del arquitecto software es esencial”.
  • “Medir el progreso de un proyecto en función del tiempo que lleva desarrollándose es un error”
  • “¿Cómo puede un proyecto acumular un retraso de un año?... acumulando retrasos día a día”.

[...]

El libro de Brooks es de 1975, y lo más curioso es como más de 30 años después afirmaciones como las anteriores son muy poco conocidas así como frecuentemente incumplidas. Ya lo dijo el propio Brooks... "They call this book the Bible of Software Engineering... and that's because everybody reads it but nobody does anything about it!"

viernes, 19 de septiembre de 2008

97 Things Every Software Architect Should Know

97 Things Every Software Architect Should Know es un interesantísimo proyecto en forma de wiki. La idea es reunir axiomas de la arquitectura de software propuestos por y discutidos entre quienes desempeñan este papel.

Cada tanto entro y pispeo las modificaciones y contribuciones. Sinceramente me muero de ganas de meter bocadillo, pero armar una frase que pegue en inglés y argumentar con la exactitud de conceptos requerida es un desafío que hasta ahora no pude superar.

Hay algunas realmente buenas:

  • If there is only one solution, get a second opinion - Timothy High
  • Avoid "Good Ideas" - Greg Nyberg
  • A rose by any other name will end up as a cabbage - Sam Gardiner
  • Get the 1000ft view - Erik Doernenburg

Hay para relamerse, y las discusiones asociadas son muy buenas. Es recomendable leer sobre aquellas con las que uno no está de acuerdo. Las mejores 97 serán incluidas en "97 Things Every Software Architect Should Know", un libro que será publicado por O'Reilly Media, Inc.

Visto en Pensamientos ágiles.

martes, 29 de julio de 2008

5 libros 5

5 libros 5 que nada tienen que ver con sistemas, recomendados por las más variadas razones en desorden, sin ánimos de hacer ranking.

lunes, 28 de julio de 2008

C# Coding Standards

En más de una entrada he insistido sobre lo importante que es la uniformidad en el estilo de codificación en un equipo.

Desde que empecé con C# utilicé C# Coding Standards for C#, by Lance Hunt (creo que alguien me pasó la referencia, lamento no poder darle el crédito correspondiente, mi memoria es pobre).

Tiene la ventaja de ser muy claro y compacto, cercano a todo el código que se ve en internet, y alineado con el formato que está configurado por defecto en el Visual Studio de Microsoft.

sábado, 17 de mayo de 2008

Libros recomendados: Kent Beck. Extreme Programming Explained.

Extreme Programming Explained: Embrace Change. Addison-Wesley, 2000. ISBN 0-201-61641-6. Second edition 2005 with Cynthia Andres. ISBN 0-321-27865-8.

La biblia acerca de las metodologías "ágiles" de programación, tanto para desarrolladores como para líderes de proyecto, analistas, o cualquier interesado. Sus postulados rompen los axiomas más establecidos de las metodologías de desarrollo tradicionales. Estemos de acuerdo o no con sus postulados, es imprescindible conocerlos. El libro está excelentemente estructurado, es corto y muy ameno.