Master on Libre Software Planet

June 20, 2016

Andrés Maneiro

Dos ideas funcionales

En la evolución de cómo se hacen aplicaciones web, la mutación principal del ciclo anterior habría sido la separación API/interfaz. En el actual, apostaría que lo fundamental se deriva de que el ecosistema JavaScript (tanto el lenguaje como las librerías a su alrededor) ha interiorizado dos ideas del mundo de la programación funcional: las funciones puras y la inmutabilidad. Esta hipótesis serviría para explicar, por ejemplo, la popularidad de React y Redux que no son más que la aplicación de estos conceptos a la creación de interfaces y la gestión del estado.

by Andrés at June 20, 2016 12:40 PM

June 18, 2016

Andrés Maneiro

La arquitectura de la complejidad

Herbert A. Simon dedicó su vida al estudio de sistemas: organizaciones, economía o inteligencia artificial. En 1962, publicó un paper titulado «The architecture of complexity» donde presenta cómo el estudio general de sistemas significa entender la formación de jerarquías.

Sistemas complejos y jerarquías

Simon aproxima un sistema complejo como aquél que está compuesto por un número grande de componentes que interactúan de manera no trivial. Un sistema jerárquico sería aquél que se puede descomponer en subcomponentes interrelacionados, que no necesariamente tienen que estar subordinados en una relación de autoridad maestro-esclavo.

La razón por la que es más habitual encontrar jerarquías de cualquier tipo en los sistemas complejos es porque forman estructuras estables de manera más rápida. Para defender esta tesis repasa ciertos ejemplos de la naturaleza y sociales, pero baste cita la famosa parábola de los dos relojeros para entender lo que quiere decir:

There once were two watchmakers, named Hora and Tempus, who manufactured very fine watches. Both of them were highly regarded, and the phones in their workshops rang frequently – new customers were constantly calling them. However, Hora prospered while Tempus became poorer and poorer and finally lost his shop. What was the reason?

The watches the men made consisted of about 1.000 parts each. Tempus had so constructed his that if he had one party assembled and had to put it down -to answer the phone, say- it immediately fell into pieces and had to be reassembled from the elements. The better the customers liked his watches, the more they phone him, the more difficult it became for him to find enough uninterrupted time to finish a watch.

The watches that Hora made were no less  complex than those of Tempus. But he had designed them so that he could put together subassemblies of about ten elements each. Ten of these subassemblies, again, could be put together into a larger subassembly; and a system of ten of the latter subassemblies constituted the whole watch. Hence, when Hora had to put down a partly assembled watch in order to answer the phone, he lost only a small part of his work, and he assembled his watches in only a fraction of the man-hours it took Tempus.

Es decir, la organización en subsistemas, facilitaría la estabilidad de la estructura global.

Sistemas casi-descomponibles

Para entender las jerarquías, Simon propone dos aspectos fundamentales:

  • el número de componentes en que se particiona el sistema: o el span. En los límites, un sistema jerárquico con span = 1 sería una cadena de componentes; un sistema jerárquico se consideraría como plano si su span es alto.
  • cómo se agrupan sus componentes: aunque los sistemas físicos y químicos se suelen agrupar por las propiedades espaciales y los sociales por la interacción entre componentes, Simon argumenta que esta es una falsa dicotomía. Él propone que los componentes de un sistema se agrupan por la “intensidad de la interacción” entre ellos y que la cercanía espacial es un subproducto de ciertas estructuras físicas que necesitan cercanía para intercambiar información.

Es precisamente la interacción –entre subsistemas y dentro del subsistema- lo que Herbert usa para estudiar las jerarquías. Su tesis es que podemos entenderlas como sistemas casi-descomponibles: es decir, que las interacciones dentro de un subsistema son muy intensas mientras que las interacciones entre subsistemas son más débiles aunque no despreciables. En parábola:

Consider a building whose outside walls provide perfect thermal insulation from the environment. We shall take these walls as the boundary of our system. The building is divided into a large number of rooms, the walls between them being good, but not perfect, insulators. The walls between rooms are the boundaries of our major subsystems. Each room is divided by partitions into a number of cubicles, but the partitions are poor insulators.

A thermometer hangs in each cubicle. Suppose that at the time of our first observation of the system there is a wide variation in temperature from cubible to cubicle and from room to room – the various cubicles within the building are in a state of thermal disequilibrium. When we take new temperature readings several hours later, waht shall we find? There will be very little variation in temperature among the cubicles within each single room, but there may still be large temperature variations among rooms. When we take readings again several days later, we find an almost uniform temperature throughout the building; the temperature differences among rooms have virtually disappeared.

Es decir, a  corto plazo, se podría entender el comportamiento de un subsistema de manera individual; sin embargo, a largo plazo, necesitaríamos incluir en la ecuación el resto de componentes de manera agregada para tener en cuenta los efectos de esas interacciones.

La descripción de la complejidad

El hecho de que muchos sistemas complejos tengan una estructura jerárquica casi-descomponible, facilita nuestra comprensión de ellos. O quizás nuestra comprensión de otro tipo de sistemas está limitada por nuestra capacidad de procesamiento. En cualquier caso, según Simon, cualquier actividad humana que suponga problem-solving se puede asimilar a un sistema de este tipo: el progreso hasta llegar al objetivo se produciría por un proceso de prueba/error selectivo; nos apoyaríamos en resultados intermedios que tendrían la misma función que los subsistemas biológicos (estabilizar la estructura) y nos señalizarían el camino hacia el objetivo.

¿Cómo, pues, podemos usar en nuestro beneficio las jerarquías para entender y construir sistemas complejos?

  • La jerarquía es, al fin y al cabo, una manera de encapsular la redundancia del sistema y hacerlo más económico en términos de esfuerzo.
  • Aunque no conocemos reglas generales que describan cómo encapsular esa redundancia para cualquier sistema, tenemos a nuestra disposición dos tipos de representaciones útiles: describir su estado y describir el proceso.

Usando la descripción de estado, podríamos definir un círculo como “el lugar de los puntos equidistantes de un punto dado“. La definición del proceso podría ser algo como “pinchar el compás en un punto del plano y rotar el otro brazo hasta que dé una vuelta completa“.

Coda

La arquitectura de la complejidad, de Herbert A. Simon aborda una tarea difícil y consigue reducirla a algo manejable: propone que el estudio de sistemas complejos es fundamentalmente el estudio de su jerarquía, encontrar la redundancia que nos permita representar su estructura de manera comprensible, para lo que tenemos a nuestra disposición dos herramientas fundamentales, estado y proceso.

Una teoría de sistemas aplicable a multitud de entornos (biología, sociales, etc) es necesariamente generalista. Como programador, sin embargo, hay lecciones en este paper que se pueden extrapolar a nuestro día a día.

code-hierarchy

La teoría de la casi-descomponibilidad es atractiva. Explica, por ejemplo, por qué los tests unitarios en subsistemas son posibles pero no suficientes para modelar el comportamiento del sistema. Explica también que para una mayor eficiencia en nuestro trabajo deberíamos enfocarnos en la búsqueda de submódulos estables. No menos importante: apunta que para agregar código en componentes (funciones, clases, módulos, etc) deberíamos primar agregaciones con gran interacción interna pero con interacción externa baja – es decir, loose coupling y high cohesion.

Por otro lado, alguna vez he bromeado con que el título que mejor me representa es el de físico-químico de sistemas de control interactivos. Tras la boutade se esconde una pequeña píldora de verdad: en el fondo, el día a día de todo programador consiste en eliminar la redundancia de un sistema. Me paso el día codificando esa redundancia con 2 herramientas principales: estado y proceso, datos y algoritmos.

by Andrés at June 18, 2016 07:31 PM

June 16, 2016

Andrés Maneiro

3 design principles for product listing information

3 Key Design Principles for Product Listing Information. Un estudio sobre cómo mostrar info de productos enfocado al comercio electrónico. Aplicables a la hora de mostrar listas de elementos.

by Andrés at June 16, 2016 05:04 AM

June 15, 2016

Andrés Maneiro

Modern Layouts

Jen Simmons, editora del podcast The Web Ahead, presentó en el último AnEventApart una charla sobre la evolución de los layouts para la web y las nuevas posibilidades que existen. Muy recomendable en conjunción con los experimentos y demos que pueden verse en The Layout Ahead.

by Andrés at June 15, 2016 06:29 AM

June 13, 2016

Andrés Maneiro

Xerox Star

El Xerox Star fue el primer ordenador moderno que salió a mercado. Lanzado en 1981, definió una nueva relación con los ordenadores que prevalece todavía hoy en los sistemas que usamos a diario.

El contexto

En los 70, las computadoras estaban reservadas a entornos militares y universitarios, tenían el tamaño de una habitación y eran sistemas de tiempo compartido: un ordenador central al que se conectaban “terminales tontos”. Las interfaces eran orientadas a texto.

A mediados de la década, el signo de los tiempos apuntaba ya en otra dirección: la de las computadoras personales. Xerox, que era una de las mayores compañías tecnológicas del mundo gracias al negocio de copiadoras, no era ajena a ese ambiente y su visión era que los ordenadores podrían automatizar la oficina: fundamentalmente ayudando en la creación de informes y documentos – que se podrían imprimir con sus copiadoras, claro. Su visión -y la de muchos otros- era que el negocio estaba en el WordProcessing no en el DataProcessing.

Rank_Xerox_8010+40_brochure_front

Los anuncios del  Xerox 8010 InformationSystem –como era conocido el Star en el mercado- captan muy bien esa atmósfera. El que vemos a continuación es uno de los primeros que le muestran al público un ordenador con ventanas, iconos y otro tipo de metáforas referidas al escritorio (carpetas, archivadores, impresoras, etc):

Xerox PARC

En Xerox PARC, el centro neurálgico de Xerox, se reunía la gente que había estudiado y trabajado con los pioneros de la generación anterior (Douglas Englebart e Ivan Sutherland) para investigar y aterrizar qué podía significar eso de la automatización de la oficina. Un caldo de cultivo que favoreció multitud de invenciones: desde la impresión por láser, hasta el estándar de comunicaciones Ethernet, incluyendo la interfaz gráfica de usuario y el primer lenguaje de programación orientado a objetos, SmallTalk. Incluso habían construido un prototipo de “ordenador personal“: el Xerox Alto, bajo el tutelaje del Learning Research Center liderado por Alan Kay y que pretendía concretar las ideas en torno al Reactive Engine o el Dynabook.

Merece la pena recordar todo el background, ideas y trabajo previo que recoge el Star con un gráfico realizado por los propios diseñadores para la retrospectiva del producto que publicaron en 1989.

star_influences

Se puede ver en este gráfico también las influencias sobre los productos posteriores, que no son exclusivamente de ideas, sino que vienen muchas veces derivadas de personas que cambian de equipos: Larry Tesler que se va a Apple para trabajar en el diseño del Lisa, donde también estuvo Tom Malloy creando el LisaWrite, Simonyi a Microsoft para crear el Word continuando así el trabajo que él mismo había hecho con Lampson en la aplicación Bravo, el primer editor WYSIWYG y un largo etc.

El Xerox 8010 Information System

Para llevar a mercado esas invenciones, los directivos de Xerox decidieron crear el SDD (Systems Development Department), una división interdepartamental que contaba con 2 centros situados en California: Palo Alto y El Segundo. Dirigidos por David Liddle, el SDD inició su tarea en el verano de 1978 y tres años después, en 1981, el Star se presentó al público.

Esta división, además de nutrirse de muchos ingenieros de PARC, también contrató gente externa como Bill Verplank, un consultor de lo que entonces se conocía como Human Factors. Liddle describe el proceso de trabajo como:

It began with task analysis, looking at a fairly wide range is users. Next came the job of developing scenarios for uses of the imagined product based on the task. Then, it proposed a model for a graphical user interface, carefully distinguishing three aspects: the display of information, the control or command mechanisms and the user’s conceptual model.

Es decir, trabajaron con conceptos como análisis orientado a la tarea, design personas, prototipos como herramienta de selección de conceptos, etc.

El resultado fue un ordenador que costaba, consumía y pesaba un tercio menos que cualquier otro de la época:

El diseño de interacción

Una de las cosas verdaderamente únicas del Star fue proponer el escritorio como metáfora central para organizar los elementos y sus interacciones. Sorprende descubrir hasta qué punto se adhiere a esa metáfora. Vale la pena revisar videos y capturas de pantalla para descubrir pequeñas joyitas y grandes ideas que, en cierta medida, muchos sistemas operativos modernos están tratando de recuperar.

Algunas cosas que me han parecido curiosas del sistema y que son todavía hoy novedosas:

— Objetos y propiedades, no menús

El sistema es una verdadera interfaz orientada a objetos: cada elemento es un objeto y, por lo tanto tiene ciertas propiedades. Los objetos de texto (carácter, párrafo, etc) tienen propiedades de alineación, tipográficas, etc; los gráficos tienen como propiedades los datos que representan, visualización, colores, etc.

Por ejemplo, al abrir el editor de documento no hay menú, es una hoja en blanco. Se empieza a escribir y, para poner algo en cursiva no seleccionamos una herramienta de un menú una sino que se selecciona lo que se quiere modificar y se abre su panel de propiedades. De alguna manera, la no existencia de menús refleja la no existencia de estado o variables globales en la aplicación. Una interfaz orientada a objetos pura.

text_property_sheet

— Comandos generales

No tener un menú tiene limitaciones, ya que hay ciertas acciones que son entre objetos: buscar, copiar, mover, etc. La manera en que resolvieron esto fue creando comandos generales que tenían sus propias teclas en el teclado del Star.

Estos comandos son usados ampliamente en el sistema y mantienen su coherencia a lo largo de los diferentes contextos: mover, por ejemplo, puede significar tomar una frase de un párrafo y llevarla a otro; pero también significa lanzar una impresión si se mueve un documento al icono de la impresora.

— Orientación a la tarea: no se abren aplicaciones, sino documentos

El Star no tenía iconos para aplicaciones, esto fue algo que se introdujo en sistemas posteriores. Por otro lado, como dije anteriormente, funciones como la impresión o el envío de un mail se tratan como cualquier otro elemento: existe la impresora y la bandeja de salida de mail como objetos independientes; para imprimir se copia el documento sobre el objeto impresora; para enviar un mail se copia el documento sobre el objeto bandeja de entrada. La diferencia es sutil y separa la metáfora del escritorio (donde sólo hay documentos) de la metáfora del banco de trabajo (donde hay herramientas que aplicamos sobre un elemento).

Así lo definieron los propios diseñadores del Star en 1989:

«Having windows and a mouse does not make a system an embodiment of the Desktop metaphor. In a Desktop metaphor system, users deal mainly with data files, oblivious to the existence of programs. They do not “invoke a text editor”, they “open a document”. The system knows the type of each file and notifies the relevant application program when one is opened.

Most systems, even many windowed ones, use a Tools metaphor, in which users deal mainly with applications as tools: users start one or more application programs (e.g., word processor, spreadsheet), then specify one or more data files to edit with each. Such systems do not explicitly associate applications with data files; the burden of doing that — and of making sure not to try to edit a spreadsheet file with the text editor or vice-versa — is on users. Different kinds of files are distinguished by user-convention, usually via filename extensions (e.g., memo.txt). Star relieves users of the need to keep track of which data file goes with which application.

SunView is an example of a window system that is based upon the Tools metaphor rather than the Desktop metaphor. Its users see a collection of application program windows, each of which is used to edit certain files. Smalltalk-80, Cedar, and various Lisp environments also use the Tools metaphor rather than the Desktop metaphor.

This is not to say that the Desktop metaphor is superior to the Tools metaphor. The Desktop metaphor was intended for office automation and publishing. It may not be appropriate for other applications (e.g., software development). However, it can be argued that orienting users toward their data rather than toward application programs and employing analogies with the physical world are useful techniques in any domain

— Y mucho más

Para una revisión de las interfaces del Star es necesario desaprender lo que uno sabe de las interfaces actuales. Conceptos como el WYSIWYG fueron usados en un sistema comercial por primera vez aquí, también el uso de teclados virtuales para la introducción de fórmulas o la escritura en múltiples idiomas (incluyendo los RTL). Podríamos hablar también de cómo el Star usaba técnicas como el progresive disclosure, direct manipulation, etc.

Es muy recomendable revisitar los videos del producto y abrir bien los ojos y la mente.

¿Por qué no tuvo éxito el Star?

Sin embargo, a pesar de lo maravilloso del producto, el Star no fue un éxito comercial, como sí lo fueron sus inmediatos competidores que copiaron sus ideas. ¿Qué falló?

Jobs argumenta que Xerox sufrió lo que otras compañías con un cuasi-monopolio: la gente que influye en el futuro de la compañía era gente que veían de las posiciones de ventas y márketing, no los de producto. Debido al cuasi-monopolio, el common wisdom de la compañía es que lo que la hace más exitosa no es crear una nueva copiadora, sino aumentar el mercado mediante márketing y ventas. De esa manera, progresivamente la gente de producto queda relegada de los puestos de decisión hasta que, las compañías, en cierta manera, olvidan cómo se hacen buenos productos.

Complementariamente a lo que dice Jobs hay otras razones de peso para el fracaso, algunas de las cuales eran ya claras en 1989 para el equipo de diseñadores del Star:

  • Prestar atención a las tendencias de la industria y reducir los tiempos de salida del producto.

«At the time they were developed, these technologies were unique in the industry. Xerox elected to keep them proprietary for fear of losing its competitive advantage. With hindsight, we can say that it might have been better to release these technologies into the public domain or to market them early, so that they might have become industry standards. Instead, alternative approaches developed at other companies have become the industry standards.»

  • Prestar atención al mercado: el hecho de haber sido una plataforma cerrada les impidió ser beneficiarios de la innovación que estaban realizando otros.

«The personal computer revolution has shown that it is futile to try to anticipate all of the applications that customers will want. Star should have been designed to be open and extensible by users from the start, as the Alto was. In hindsight, extensibility was one of the keys to the Alto’s popularity. The problem wasn’t that Star lacked functionality, it was that it didn’t have the functionality customers wanted. An example is the initial lack of a spreadsheet application. The designers failed to appreciate the significance of this application, which may have been more important even than word-processing in expanding the personal computer revolution beyond engineers and hobbyists into business. Eventually realizing that Star’s closedness was a problem, Xerox replaced it with ViewPoint, a more “open” system that allows users to pick and choose applications that they need, including a spreadsheet and IBM PC software. Apple Computer learned the same lesson with its Lisa computer, and similarly replaced it with a cheaper one having a more open software architecture: Macintosh.

  • Conocer el mercado al que te diriges.

«Star’s initial per-workstation price was near that of time-shared mini-computers, dedicated word-processors, and other shared computing facilities. Star was, however, competing for desktop space with micro-computer-based PCs.»

En definitiva, el fracaso de Xerox parece que tuvo más que ver con la desalineación con el mercado que con las bondades del producto. Sin embargo, hablar con la sabiduría que nos da la perspectiva histórica es ventajoso. Muy pocos podrían haber predicho que una aplicación con el VisiCalc, crearía el término Killer Application y convertiría un mercado para ingenieros amateurs en uno de computadores personales para profesionales del conocimiento, creando y dando el pistoletazo de salida a la carrera por el dominio del nuevo mercado.

by Andrés at June 13, 2016 05:32 PM

June 10, 2016

Andrés Maneiro

How Elm Slays a UI Antipattern

How Elm slays an UI antipattern. Un ejemplo de cómo la estructura de datos (o las abstracciones que construyes) pueden simplificar el código y minimizar los errores.

by Andrés at June 10, 2016 05:08 AM

June 09, 2016

Andrés Maneiro

Treinta y cuatro

Hace unas semanas he cumplido mi vuelta al Sol número 34. ¿Qué ha pasado en todo este tiempo? Lo resumo con este post, para mi yo futuro y porque recordar todo lo que uno ha hecho ayuda a no perder la perspectiva.

iCarto

Este año ha sido el 5º aniversario de iCarto y lo hemos celebrado con familia/amigos. Los primeros años fueron duros, probablemente cometimos todos y cada uno de los errores que una nueva empresa puede cometer, esas cosas que no salen en los manuales de MBA y que suponen una verdadera prueba de resistencia. El futuro de la empresa ahora es muy prometedor. Las heridas se han convertido en marcas que uno enseña con orgullo y guarda como recordatorio. Haber contribuido a construir una dinámica de sostenibilidad en el medio de una profunda crisis económica como no se recordaba es algo que quedará para siempre grabado en mi memoria.

icarto

A nivel proyectos, lo más significativo del último año ha sido:

  • Bantegal: la aplicación del banco de tierras de Galicia. He colaborado con un grupo de otros 10 desarrolladores con un background muy diferente al mío, lo que me ha exigido mucho a nivel personal. A nivel funcional, lo más reseñable quizás sea que he desarrollado el componente de cobros y pagos para interactuar con los bancos, implementando el estándar SEPA. Tecnologías: Java, Spring, Wicket, Struts, JSP.

Captura de pantalla de 2016-06-08 20:46:02

ccsi

  • En los últimos meses, he estado centrado en idear y desarrollar una aplicación para la gestión de explotaciones y usuarios del agua que se usará en Mozambique. Fran me ha ayudado a programar lo que teníamos entre manos, que era bastante ambicioso. Es un producto empaquetado con Electron que se divide en 3 componentes principales: una interfaz web, un API REST y una base de datos. Ésta es una arquitectura que ya he usado en otros proyectos y que poco a poco se está convirtiendo en mi default. Continuando con mi evolución hacia la  creación de librerías reutilizables siguiendo la filosofía UNIX, en este proyecto he publicado backbone-uilib, backbone-geojson y leaflet-table. Tecnologías: JavaScript, HTML/CSS, Backbone, Bootstrap, Python, Pyramid, SQLAlchemy y PostgreSQL/PostGIS.

utentes-show

El mundo maker

El último año he estado especialmente activo en el mundo maker. En Mayo del 2015 me convertí en el nuevo presidente de Makers.Lugo, lo que significó poner al día la asociación a nivel burocrático y consolidar un creciente grupo de gente alrededor nuestra. Por tercer año consecutivo, hemos realizado el GenuinoDay en Lugo. Este año la organización la ha liderado Sancos, que ha conseguido organizar el mejor evento hasta la fecha y al que agradeceré eternamente el esfuerzo inmenso que ha hecho durante todos estos meses.

OLYMPUS DIGITAL CAMERA

En Otoño me he pegado un buen recorrido por ferias y conferencias, con un enfoque muy maker: en Santiago la mini maker faire, la OSHDEM en Coruña, el Somero en Gijón; he vistado a la gente del Fablab León y he participado en mi primera conferencia de diseño.

Azuzado en parte por experimentos que hice años atrás, me decidí a proponer una actividad para los miembros del Club de Las Indias: recuperar los valores de la abundancia en la navidad mediante los objetos con los que la celebramos. Un arrebato a lo William Morris. La propuesta fue acogida con entusiasmo y en estos meses de principio de 2016 hemos acabado la fase de investigación, cuyo resultado se puede leer en este epub. Hemos también ideado ya algún producto y estamos ahora con las manos en la masa.

A nivel personal

En este blog he estado bastante activo y casi sin darme cuenta he escrito un ensayo sobre desarrollo de software en una PYME, ordenando las notas que había interiorizado en mi cabeza a partir de la experiencia de los últimos años. He arrancado también un blog musical y otro donde recopilo notas de diseño de interacción.

He visitado Nueva York, Madrid, Berlín, San Petersburgo y París.

IMG_20160418_151631955 DSC05416 2015-12-12 14.53.20 DSC05689 IMG_20160413_203716616 DSC05547 DSC05574 DSC05962 IMG_20160416_210242328_HDR DSC05377 DSC05428 2015-12-12 10.30.43

He leído más libros de diseño que de cualquier otra cosa y algunos han pasado a mi lista de recomendados. La scifi se ha hecho un hueco también: Oveja mansa de Connie Willis y La mano izquierda de la oscuridad de Ursula K. Le Guin. Me he puesto al día en novela negra leyendo la serie creada por Domingo Villar que tiene como personaje principal al inspector Leo Caldas: Ollos de auga y A praia dos afogados. Siguiendo con el consumo cultural, esta temporada me han cautivado Halt and Catch Fire y El Ministerio del Tiempo.

A principios de 2016, he recuperado la trompeta para tocar en un concierto con amigos. He aprendido las reglas del go. Estoy preparando el certificado Advance de inglés. Esta temporada de la competición de trivial nos ha ido mal, pero nos seguimos divirtiendo. Además de un nuevo portátil, me he comprado mi primer coche.

La lección vital más importante que he aprendido es ésta: uno es lo que hace, no lo que representa. La vida merece la pena sólo si la compartimos con otros que nos ayuden a ser una versión mejor de nosotros mismos.

Lo que me lleva directamente a la banda sonora de este año:

La vuelta 34 ha sido muy intensa. Estoy listo para la siguiente!

by Andrés at June 09, 2016 01:28 PM

June 08, 2016

Andrés Maneiro

June 06, 2016

Andrés Maneiro

Spotify Culture

Actualización de un viejo artículo que ya comentamos aquí alguna vez. Para los que prefieren video en vez de texto:

 

 

by Andrés at June 06, 2016 05:06 AM

June 03, 2016

Andrés Maneiro

May 31, 2016

Andrés Maneiro

Experimento de renta básica

La aceleradora YCombinator va a realizar un experimento sobre la renta básica. Durante 5 años, una serie de personas que elegirán entre la población de Oakland recibirá un ingreso mínimo. Esto es parte de un plan piloto que, si sale bien, pretenden ampliar a larga escala. Es interesante seguir esta iniciativa en paralelo a los debates sobre Renta Básica Universal en otros lugares, como España, donde las condiciones de partida son distintas (existe un estado de bienestar que no deja de ser un sistema de renta básica selectivo).

by Andrés at May 31, 2016 07:13 PM

Cuídate de los high-performers

Odds are far better than good that your high performers are achieving what appears to be high levels of productivity by building technical debt into the application by taking shortcuts whether intentionally or unintentionally. Examples of shortcuts are not taking the time to design and architect things well at all levels (low to high — think objects and object hierarchies, database schema changes, etc.), failing to test adequately, and crafting code that is hard to read, maintain and extend.

These kinds of high performers are actually low performers when when TCO is factored in.

Cuídate de los high-performers. Un artículo interesante sobre gestión de equipos de desarrollo de software.

by Andrés at May 31, 2016 06:43 AM

May 30, 2016

Andrés Maneiro

Peticiones de datos modularizables

Recomiendo que echéis un vistazo al video Data fetching for React applications:

Obviando los detalles específicos a ReactJS, Relay y GraphQL la propuesta tiene 2 ideas interesantes:

  • la primera sería que el servidor no tiene muchos endpoints específicos, sino uno al que se le hacen consultas en un formato determinado (GraphQL) y devuelve respuestas en JSON. Hasta aquí nada novedoso porque este estilo de APIs han emergido en los últimos años en muchos productos, sobre todo usando la potencia de SQL (ej: CartoDB).
  • lo novedoso sería cómo se contruye esa petición. Lo típico sería hacerlo en un componente padre que “conoce” lo que necesitan sus hijos. Pongamos un ejemplo usando SQL: el padre lanzaría al API del servidor una consulta tal que «SELECT name, image, etc FROM users » porque sabe que uno de sus hijos necesita la propiedad name y otro la propiedad image. Esta aproximación provoca acoplamiento ya que si uno de los hijos cambia la propiedad que necesita, es necesario hacer cambios en todo el árbol hasta llegar al padre. La propuesta que hacen invierte el control: son los componentes hijos los que declaran qué propiedades necesitan. En este escenario, el padre es agnóstico respecto a los datos que piden los hijos al servidor y centraliza esta lógica en cada componente.

by Andrés at May 30, 2016 01:57 PM

May 13, 2016

Andrés Maneiro

imgui

Estoy estos días madurando las lecciones aprendidas de uno de mis últimos desarrollos -una librería de componentes para backbone– y me he encontrado de nuevo con Casey Muratori, un programador de videojuegos independiente. Digo de nuevo porque en este blog ya he publicado sobre un proyecto suyo y una charla sobre diseño de componentes reutilizables. Pero parece que este chico es una fuente inagotable de ideas. O quizás el solape entre las técnicas de desarrollo en videojuegos y el mundo JavaScript es todavía más grande del que yo imaginaba. La última que he documentado en mi glosario: las diferencias entre el Immediate Mode y el Retained Mode.

by Andrés at May 13, 2016 02:36 PM

Compare workflows not frameworks

In general, comparing frameworks in terms of features seems inferior to examining the model it imposes on the programmer.

The latter will inform you about how well the code will fare over time as the product matures and the team grows, but the former won’t. It will also empower you to foresee what the evolutionary path of the technology looks like.

— Guillermo Rauch, en Pure UI, sobre el proceso de rediseño de VideoPress.

by Andrés at May 13, 2016 07:09 AM

May 12, 2016

Andrés Maneiro

60 FPS on Mobile Web

60 FPS on mobile web. Cómo el equipo de ingeniería de FlipBoard ha acelerado la experiencia de usuario en móviles.

by Andrés at May 12, 2016 08:22 AM

May 09, 2016

Andrés Maneiro

El Ministerio del Tiempo

Los lunes, en casa, son el día del Ministerio del Tiempo, la serie de TVE creada por los hermanos Pablo y Javier Olivares y que va por su segunda temporada. A veces comedia, a veces thriller, siempre entretenimiento. Cada capítulo es una novedad y los recientes de esta segunda temporada están a la altura de la primera.

mdt

Personalmente me gustaría ver más historias de la periferia en la trama de la serie, capítulos contando una España alternativa: una historia ucrónica (de ésas que tanto me gustan) que explorase el qué hubiese ocurrido si … Por otro lado, el guión deja entrever pullas o complejos generacionales y, en muchos casos, no explota todos los recovecos que podría de la historia. A pesar de todo ello, de lo que a mí me gustaría que hubiese sido la serie, lo que importa es lo que está siendo: y el resultado es desde luego una ficción muy entretenida.

A nivel transmedia es de lo mejorcito que he visto: la webserie de Angustias, el podcast de Julián, el paseo en realidad virtual por el ministerio, permiten dejarte llevar por el mundo y explorar otras caras de los personajes más allá de la serie. No recuerdo haber disfrutado tanto con estos juegos desde que el Sherlock de Moffat para la BBC, nos invitase a explorar los blogs y comentarios de Watson y Holmes .

by Andrés at May 09, 2016 10:32 PM

May 07, 2016

Andrés Maneiro

Professional corner-cutting

Lo que significa ser un buen programador, según Havoc Pennington:

Hazte responsable de tus decisiones, entiende el contexto del proyecto y no seas vago.

by Andrés at May 07, 2016 08:18 AM

May 06, 2016

Andrés Maneiro

Vagrant con Debian Jessie

Estos días he estado creando un entorno de desarrollo con vagrant para un nuevo proyecto que corre sobre Debian Jessie con tecnologías un poco antiguas.

Una de las bases de datos de ese proyecto tiene más de 12Gb de volcado, pero la máquina de debian viene con 10Gb para todo el sistema, así que me puse manos a la obra para redimensionar el espacio asignado en disco en la máquina virtual.

Esto resultó un proceso menos trivial de lo que yo me esperaba, asi que publico aquí unas notas sobre la configuración completa de la máquina para mi yo futuro y como ayuda para cualquiera al que le pueda ser útil.

Instalar el entorno base

Lo primero fue descargarme el binario de vagrant. No usé el propio que viene en los repos de mi sistema porque ellos no lo recomiendan. Luego, me puse a buscar una máquina Debian Jessie de 64 bits y me encontré con la “oficial“. Así que tener un Debian listo para poder jugar fue tan sencillo como:

vagrant init debian/jessie64

Configurar la zona horaria

Instalando ciertas librerías de i18n y l10n para el proyecto, me encontré con problemas porque la VM no tenía la zona horaria correcta, así que me instalé un plugin que me permite configurar la zona horaria de la VMs.

vagrant plugin install vagrant-timezone

En mi caso, he seteado la zona horaria para todas las máquinas, aunque se puede configurar de manera individualizada para cada una. He puesto mi zona horaria como “CET”. Aunque en la docu del proyecto dicen que es posible usar la variable :host para que la tome automáticamente del equipo, a mí no me funcionó.

Así que en mi ~/.vagrant.d/Vagrantfile he incluido:

Vagrant.configure("2") do |config|
  if Vagrant.has_plugin?("vagrant-timezone")
    config.timezone.value = "CET"
  end
end

Aumentar el espacio en disco

En este apartado necesitamos hacer 2 cosas: primero, asignar más espacio a la máquina virtual; luego, configurar internamente las particiones para que reconozca ese espacio. Para la primera parte estuve viendo este tutorial. Para la segunda, lo hice de otra manera inspirado por éste.

Lo primero que hay que saber es que vagrant puede usar diferentes providers, que son los sistemas de máquinas virtuales. El que tenía yo era VirtualBox, así que al crear la base vagrant, lo que ocurre es que se guarda un archivo VDMK en el lugar donde mi VirtualBox almacena las VM. En mi caso, esto fue en un directorio tal que “~/VirtualBox VMS/debian-jessie/”, donde encontré el fichero debian-jessie.vdmk que era el que tenía que ampliar. Al parecer, esta funcionalidad sólo está disponibles en discos con formato VDI nativos, no con el VDMK, así que lo primero que tuve que hacer fue convertir el disco a VDI y luego ampliarlo a unos 52GB:

VBoxManage clonehd --format VDI debian-jessie.vmdk debian-jessie.vdi
VBoxManage modifyhd debian-jessie.vdi --resize 50000

A partir de aquí, la operación es la misma que cuando uno hace particiones, aunque yo no lo tenía muy fresco porque hacía años que no me enfrentaba a ello. Lo primero a recordar es que para manejar particiones, los discos tienen que estar desmontados. La idea es arrancar con una ISO como la de GParted y realizar las operaciones desde ese entorno. ¿Cómo hacer esto con una VM de VirtualBox? Pues:

  • añadiendo la ISO como CD al sistema de almacenamiento de la VM

vm_gparted

  • configurando el arranque indicando que lo intente como CD primero y luego como disco

vm_cd

  • Et voilà!

vm_gparted_iso

Como mi VM no tenía sistema de ventanas, arranqué desde consola luego de aceptar los diversos menús que aparecen e hice las operaciones de edición de tabla de particiones con parted. En mi caso, tenía una partición primaria y una extendida con la SWAP en el disco /dev/sda, así que mi plan fue:

  • borrar la partición extendida
  • reclamar para la partición primaria todo el espacio de disco menos el último giga
  • extender el sistema de ficheros al tamaño total de la partición
  • añadir de nuevo la partición extendida con la SWAP

Que viene a ser lo siguiente:

parted /dev/sda
rm 2
resizepart 1 -1GB
quit
e2fsck -f /dev/sda1
resize2fs -p /dev/sda1
exit

Tuve problemas para crear la SWAP con parted, así que hice este último paso posteriormente con cfdisk ya desde vagrant, que es mucho más sencillo y visual.

Para finalizar, hay que recordar desmarcar el arranque por CD y eliminar la ISO de Gparted  del sistema de almacenamiento de la VM en VirtualBox. Entonces ya podemos arrancar nuestro vagrant de nuevo con normalidad y comprobar  que todo ha ido bien.

vagrant up
vagrant ssh
df -h

by Andrés at May 06, 2016 05:02 PM

April 27, 2016

Andrés Maneiro

100 objetos

El Consello da Cultura Galega inaugura el 10 de mayo la expo Galicia 100 que imita la A history of the world in 100 objects, del British. Últimamente se imponen los itinerarios para descubrir colecciones en los museos.

by Andrés at April 27, 2016 05:05 PM

April 26, 2016

Andrés Maneiro

Stripe contrata equipos

Stripe anuncia que ofrecerá contratos a equipos de entre 2 y 5 personas. Las razones:

Do you know anyone who makes you incredibly better at what you do? People who motivate and inspire you, complement your strengths and shore up your weaknesses, help you achieve things you could never do on your own? Maybe it’s your old co-founders, your college roommates, your collaborators on an open source project, or even your siblings; whoever it is, you’re stronger as a team than you are apart.

by Andrés at April 26, 2016 08:57 PM

April 21, 2016

Andrés Maneiro

Etsy currency

How Etsy formats currency. Etsy es una web de compraventa de productos que permite operar en 9 lenguajes, 23 monedas distintas y centenares de regiones. Ésta es la historia de cómo aborda el formato de monedas en su web.

by Andrés at April 21, 2016 04:59 AM

February 06, 2016

Andrés Maneiro

Los mundos de Ursula K. Le Guin

Acabo de apoyar la realización del documental sobre la vida y obra de Ursula K. Le Guin. Si te han gustado sus novelas, no hay mejor momento que ahora para colaborar con este proyecto. Si todavía no la conoces, te recomiendo que le eches un ojo a Los desposeídos o La mano izquierda de la oscuridad.

by Andrés at February 06, 2016 12:08 AM

February 05, 2016

Andrés Maneiro

La mano izquierda de la oscuridad

Esta novela de Ursula K. Le GuinTheLeftHandOfDarkness1stEd fue publicada en 1969. Ambientada en el planeta Gueden (llamado también Invierno porque su superficie está siempre helada), la historia narra la visita de Genri Ai, un diplomático que tiene por objetivo conseguir la adhesión del planeta al Ekumen, algo así como una alianza interplanetaria para fomentar el libre comercio e intercambio de ideas.

Aunque en todo el planeta hay un cierto desarrollo tecnológico e industrial, las civilizaciones que lo habitan no han desarrollado conocimiento (ni imaginación) para volar y mucho menos saben de la existencia de otros seres en el universo más allá de sí mismos y los dioses que los acompañan. Las dos organizaciones más grandes del planeta son Karhide (un estado en fase tribal) y Orgoyen (un estado que está en fase de desarrollo de la capa funcionarial y burocrática).

Los habitantes de Gueden tienen varias características especiales, la primera de ellas es que son andróginos y hermafroditas: no tienen un sexo definido, sino que una vez al mes entran en celo y desarrollan un sexo. Cualquier persona puede ser un hombre en un ciclo y mujer al siguiente; de igual modo, cualquiera puede dar a luz. La segunda es que tienen un sistema muy sofisticado de orgullo personal (el shifgredor) pero no conocen la violencia organizada, las guerras y las luchas en grupo. El shifgredor vendría a ser algo así como la sombra de uno, su karma o capacidad de influir en los demás, también el respeto que le tienen. Han desarrollado por ello grandes habilidades diplomáticas y se puede decir que son incapaces de mentir, aunque juegan con las medias verdades.

A nivel narrativo, la tarea de Genri es doble: convencer a Gueden de las ventajas de unirse al Ekumen y sobrevivir a las intrigas que ponen en riesgo su vida. El personaje sirve, además, de conducto para que Le Guin nos presente unas cuantas ideas interesantes:

  • ¿Qué ocurre en una sociedad donde nadie es completamente hombre ni nadie mujer? Es sin duda un libro para darse cuenta de los costes sociales asociados al género: se habla de sexo, de cualidades masculinas y femeninas, de maternidad y paternidad, etc.
  • ¿Cuáles son los beneficios del libre comercio e intercambio de ideas? Genri, como diplomático del Ekumen que desea firmar algo así como un Tratado de Libre Comercio, está despojado de la visión colonialista de los humanos que llegan al mundo Bosque y la lógica extractiva de lo que hoy día conocemos como TLCs. Eso permite algunas conversaciones muy ponderadas sobre el desarrollo humano asociado al mercado, escondidas bajo la lógica de la liga internacional de mundos.

Tanto esta novela como Los desposeídos me parecen pequeños laboratorios humanos, ejercicios de investigación sociológica. Son obras que, a pesar de haber sido escritas en plena época hippie, han desarrollado de manera muy madura temas complejos como la anarquía, el rol del libre comercio en el desarrollo o la perspectiva de género. Me atrevería a decir que son novelas muy del siglo XXI. Son entretenimiento puro, que nos hace pensar sobre otros mundos posibles, en todas sus dimensiones, con sus problemas e incentivos, firmadas por la gran maestra en la creación de utopías ambiguas.

by Andrés at February 05, 2016 11:54 PM

February 01, 2016

Andrés Maneiro

Dangerous UI team

The dangerous “UI team”, de Havoc Pennington. Nos recuerda que, para hacer productos, necesitamos equipos que resuelvan problemas.

by Andrés at February 01, 2016 06:52 AM

January 30, 2016

Andrés Maneiro

En las PYMES hay futuro

En las PYMES también hay futuro es un artículo que pone sobre la mesa las ventajas de trabajar en pequeñas empresas (que aglutinan el 74% del empleo de España y son el bastión contra la crisis): mayor autonomía y perfiles pluriespecialistas, en un entorno que necesita la innovación continua para sobrevivir.

by Andrés at January 30, 2016 02:12 PM

January 29, 2016

Andrés Maneiro

Las raíces de la longevidad

Want Great Longevity and Health? It Takes a Village, presenta las cosas que tienen en común las poblaciones que él llama «blue zones», las regiones con mayor longevidad del planeta (que presentan además menor índice de enfermedades asociadas al envejecimiento: cardiovasculares, artitris, psiquiátricas, etc): actividad física moderada a diario, sentido de propósito en la vida, balance vida/trabajo, relaciones intercomunitarias fuertes, dieta basada en legumbres y verduras con baja presencia de carne.

También ha presentado alguna charla en TED:

by Andrés at January 29, 2016 06:55 PM

January 25, 2016

Andrés Maneiro

Spotify agile revisited

Una actualización de un viejo paper sobre cómo Spotify crea su producto de una manera ágil [PDF]. El proceso está orientado a minimizar su mayor riesgo: crear el producto equivocado.

Captura de pantalla de 2016-01-17 13:11:26

by Andrés at January 25, 2016 07:04 AM

January 20, 2016

Andrés Maneiro

Color practice

Color practice es una aplicación web y para móvil que contiene puzzles de color. Figuras que bien formadas son escaleras de colores en brillo y saturación.

color_practice

by Andrés at January 20, 2016 01:59 PM

January 19, 2016

Andrés Maneiro

Libro sobre desarrollo de software en una PYME

Estos días me he dado cuenta de que en 2015 he escrito sin proponérmelo un ensayo sobre la vida en una PYME de desarrollo de software del que me siento muy orgulloso. Está en las 7.400 palabras. Para convertirlo en librito convendría incluirle un glosario como anexo, para suplir la falta de enlaces complementarios. También hacer algo de trabajo para homogeneizar la lectura y eliminar la necesidad de los videos. ¿Algún consejo sobre edición, longitud, maquetación, las gestiones para conseguir el ISBN, etc?

by Andrés at January 19, 2016 09:30 AM

January 18, 2016

Andrés Maneiro

5 pasos para una navidad de la abundancia en 2016

Este post es una propuesta de actividad/proyecto para el club indiano a lo largo de 2016. Recupera una inquietud que me surgió hace un par de navidades y que tuve que dejar de lado en éstas. Me gustaría retomarla y me parece que es más divertido con amigos!

La idea fundamental es diseñar productos inspirados en la idea de la abundancia, que nos guste regalar o con los que decorar nuestras casas en navidad. Por ejemplo: árboles de navidad controlados por arduino, una serie de postales sobre la abundancia navideña, broches para vestir durante las cenas, etc. Las posibilidades son infinitas! Al igual que infinitas las maneras de implicarse o las herramientas que se pueden usar: escribir un post sobre los mitos navideños o enviar comentarios, hacer un sketch de arduino para controlar luces y sonido, diseñar una línea gráfica o música para el producto, dedicar un tiempecito a manualidades, etc.

Para organizar los esfuerzos, os propondría una serie de fases:

  1. Las raíces de la abundancia en la navidad (online)
    • Tiempos: hasta Abril.
    • Objetivo: entender la ritualidad y mitología navideña, el origen de los objetos que usamos (árboles, luces, postales, cenas, etc), con un enfoque en la investigación de la abundancia.
    • Qué se necesita:
      • persona/equipo que dinamice la búsqueda de referencias y escritura de posts públicos.
      • los demás, aportaríamos en forma de comentarios, nuevas elaboraciones sobre las propuestas del dinamizador, etc.
    • Resultado:
      • aprendizaje general.
      • un ebook con las investigaciones que le correspondería comercializar a la persona/equipo dinamizador.
  2. Los objetos de la abundancia I (online + encuentro)
    • Tiempos: Abril / Junio.
    • Objetivo: ideación de productos.
    • Qué se necesita:
      • persona/equipo que recoja las investigaciones de la anterior fase y explore ideas concretas de productos.
      • persona/equipo que organice un encuentro con uno o varios expertos a principios de verano, que ayuden a elaborar las ideas seleccionadas.
    • Resultado:
      • aprendizaje general gracias al encuentro con expertos donde todo el mundo puede participar.
      • catálogo navideño de ideas locas para la abundancia! :)
      • selección de 1 o varias ideas a desarrollar y formación de equipos para desarrollarlas.
  3. Los objetos de la abundancia II (online)
    • Tiempos: Junio / Otoño.
    • Objetivo: elaboración de los productos seleccionados.
    • Qué se necesita:
      • que los equipos desarrollen las ideas.
    • Resultado:
      • prototipo funcional, que le correspondería comercializar a cada equipo.
      • documentación para que pueda ser replicado por otros.
  4. Somero: presentación de prototipos (encuentro)
    • Tiempos: ¿Otoño?
    • Objetivo: presentar en sociedad los prototipos.
    • Qué se necesita:
      • que al menos alguien de cada equipo participe en el Somero!
    • Resultado:
      • recibir feedback sobre los prototipos de gente con muchas ideas
  5. Navidad: testeo en el mundo real! (online)
    • Tiempos: Otoño / Navidad.
    • Objetivo: completar los prototipos y/o tener una pequeña tirada para regalar/decorar nuestras casas.
    • Qué se necesita:
      • que los equipos desarrollen las ideas.
    • Resultado:
      • una navidad de la abundancia!

Una organización así requiere un poco de esfuerzo, es verdad. Pero me parece que es posible hacer algo de lo que nos sintamos orgullosos sin comprometer el resto de nuestra vida y trabajo. Además me parece modular, ya que uno puede tener interés y disponibilidad para participar investigando sobre los mitos (por poner un ejemplo), pero no en las siguientes fases -o viceversa. Aunque es una actividad cultural y de juego, a la vez permite ir generando proyectos que pueden ser comercializables a futuro.

Cómo yo podría participar

La propuesta implica 1 encuentro a principios de verano, a mayores del Somero (¿en Otoño?). Todo lo demás sería online. Creo que es compatible con otras propuestas, donde me veo más participando que dinamizando.

Considero que estoy flojo para hacer una buena fase inicial de mitología/ritos y estoy deseoso por oir que a alguien le apetece liderar esta parte! Para las siguientes fases, yo me puedo comprometer a tirar más, pero evidentemente hay espacio para mucha más gente y equipos.

¿Y vosotros, os véis colaborando en algo así?

by Andrés at January 18, 2016 02:22 PM

Cómo trabajan en Treehouse

Aumentar la productividad en jornadas de 32h/semana. Sus claves: eliminar los emails internos y las reuniones, prescindir de los managers y aceptar que los proyectos se hacen si hay gente interesada internamente en hacerlos.

by Andrés at January 18, 2016 05:52 AM

January 16, 2016

Andrés Maneiro

Arquitecturas para la participación

Este post cierra la serie que inicié hace unos meses sobre desarrollo de software en una PYME. En el primer post, escribría sobre cómo seleccionar tecnología; en el segundo, sobre un mecanismo para objetivar el diseño y reducir los costes de producción. En este último escribiré sobre cómo la organización del código que escribes habilita relaciones con otros.

Programar es una comunicación entre personas

«Programs must be written for people to read, and only incidentally for machines to execute»

Esta frase extraída del prólogo del mítico SICP es una de las perlas que, entre los hackers, define el buen hacer de la profesión y que pone sobre la mesa toda una declaración de intenciones por parte de Abelson y Sussman: la programación es un nuevo medio de comunicación y expresión de ideas entre personas. De este enfoque se deriva que lo fundamental a la hora escribir programas de software es hacerlo de tal manera que nuestros limitados cerebros puedan navegar rápidamente entre los múltiples detalles, con sus distintos niveles de complejidad.

Al escribir código, un primer nivel de comunicación se daría entre programadores (con otros o con nosotros mismos dentro de unos meses). La buena o mala comunicación de las ideas a través del código tendría un impacto económico que se observaría en los tiempos necesarios para la adaptación, mantenimiento y aprendizaje de un programa. Entender un programa es un acto intelectual donde entra en juego la experiencia previa, la capacidad de relación de ideas y la compresión lectora, pero también la buena maña del que lo haya escrito para hacerlo de un modo inteligible. Al igual que un ensayo, un programa requiere cohesión interna y ritmo para ser entendible.

Un segundo nivel de comunicación se daría entre programadores y analistas del dominio y/o clientes. Ese tipo de conversaciones modela cómo se comporta el sistema y se transmiten al código en forma de estructuras de datos y algoritmos.  Un programa no es más que la declaración de un proceso que tiene entradas y salidas.

El hecho de que el software refleje estas relaciones sociales es conocido desde hace décadas y cristaliza en una de las más populares leyes de la programación, la ley de Conway:

«Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.»

Es decir, las conversaciones, grupos y jerarquías existentes en el proyecto se trasladarán al código de manera inevitable. La arquitectura reflejará tu estructura de comunicación y poder, determinando el tipo de relaciones que puedes tener con tu entorno. Toda una profecía ciberpunk.

Pero … ¿cómo habilita o dificulta relaciones la arquitectura?

Una PYME pequeña funciona como una comunidad: aunque existen roles y división de responsabilidades (diseñador, programador, administrador de sistemas, analista), hay mucho de pluriespecialismo. Además, por el propio tamaño de empresa, en muchas ocasiones existen proyectos que se realizan con otros equipos. Existen arquitecturas o maneras de modularizar el código que te permiten que esa división del trabajo sea más efectiva. Veamos algunos ejemplos:

Diseño orientado al dominio

La programación es fundamentalmente la transcripción de las conversaciones entre programadores y analistas. Es necesario tener un un lenguaje común y existir entendimiento entre ambos para que la cosa salga bien. Una de las prácticas que más me ha ayudado a organizar el código es el diseño orientado al dominio, es decir: organizar el código en torno a la interacción de las entidades que se definen en la conversación analista-programador. Aunque parezca una obviedad, no lo es, tiene sus trampas y se hace menos de lo que parece. El impacto de esta práctica deriva de cómo facilita las conversaciones y el entendimiento del programa.

Separación de API e interfaz

Esta técnica, conocida ya por los pioneros, ha retomado fuerza en la era de la web ubicua y la arquitectura REST. Con este mecanismo de modularización, el API define el acceso a datos y acciones que permiten usar el sistema. El interfaz es un mero usuario del API. Además de beneficios técnicos, esta frontera tiene beneficios sociales: facilita una división del trabajo en aspectos muy distintos de la aplicación, que requieren conocimientos, técnicas y herramientas diferentes. Esto permite que la colaboración diseñador-programador sea más fluida.

Hay 2 ejemplos que ilustran muy bien mi experiencia. En ciertos proyectos donde creamos formularios para la introducción de datos con una aplicación de escritorio, aplicar este principio nos ha permitido que nuestros analistas (repito: analistas, no programadores ni diseñadores) hayan diseñado por sí mismos los formularios que luego los programadores integran en la aplicación. En otros proyectos, hemos contratado a empresas para que nos ayudasen a crear un API mientras nosotros nos centrábamos en el diseño de la interfaz (y viceversa). Ambas situaciones serían muy complejas de delegar (o casi imposibles) si no hubiésemos hecho un uso intensivo de este principio a la hora de desarrollar el producto.

Creación de plugins o módulos

Otra manera muy evidente de crear espacios para la colaboración es permitir añadir nuevas funcionalidades a tu software mediante la creación de plugins o módulos. Este tipo de arquitectura minimiza la barrera de entrada para que nuevos colaboradores puedan ser productivos muy pronto, ya que no necesitan conocer todo el proyecto antes de incluir una funcionalidad, sino que les basta con conocer sólo lo que necesitan.

En nuestra experiencia colaborando con un proyecto empezamos por el desarrollo de pequeñas extensiones o plugins con funcionalidades limitadas. Pasados unos meses, nos sentimos cómodos y con conocimiento suficientes de ciertas partes internas de la aplicación como para modificarlas y enviar mejoras. Los primeros plugins fueron exploratorios, nos permitieron familiarizarnos con el código y el producto; una vez confiamos, nos lanzamos a cosas mayores. Fue precisamente un aspecto técnico (la creación de plugins) el que nos habilitó para iniciar una relación comercial con el proyecto: de no existir esa posibilidad al principio, se nos hubiese hecho muy difícil como PYME invertir todo el tiempo necesario para entender un proyecto tan grande.

Estos son algunos ejemplos de cómo la arquitectura habilita o impide relaciones, pero existen otros miles de pequeños detalles. La modularización del código es fractal, influye en todas las capas de la aplicación.

Conclusión

El programador es, principalmente, un organizador de ideas y un ensayista. Necesita cierta capacidad lógica para analizar y diseñar un sistema, pero también para organizarlo de manera que habilite buenas conversaciones y una división del trabajo efectiva. Necesita entender a las personas con las que trabaja.

Por ello no me parece casual que Kent Beck, el gran recuperador de ideas de nuestra generación, apuntase que uno de los factores con más impacto a la hora de ser un buen programador es la empatía.

 

 

 

by Andrés at January 16, 2016 09:06 PM

January 15, 2016

Andrés Maneiro

Nacho Varela

Diferencias entre scripts Bash (gnu/linux) y Batch (windows)

Si estás acostumbrado a un lenguaje de scripting y tienes que trabajar en otro resulta muy engorroso y desesperante. 

Para echar una mano en este cambio, me ha sido muy útil el anexo de la guía "Advanced Bash-Scripting Guide" siguiente:


En ella, el autor Mendel Cooper expone mediante una tabla las equivalencias de palabras clave, sintaxis básica, variables y operadores. También se recogen equivalencias de programas o comandos básicos para mover y renombrar ficheros, listar un directorio, etc.

 Ánimo!

by Nacho Uve (noreply@blogger.com) at January 15, 2016 01:52 AM

January 14, 2016

Andrés Maneiro

William Morris para makers

William_Morris_age_53

«To give people pleasure in the things they must perforce USE, that is one great office of decoration; to give people pleasure in the things they must perforce MAKE, that is the other use of it.»
— William Morris, The lessert arts

Morris en el siglo XIX

William Morris vive entre 1834 y 1896, entre la primera revolución industrial y la segunda.  Es decir, un período donde los beneficios de la primera industrialización no eran visibles pero sí toda su dureza (horas interminables en trabajos alienantes, ciudades no preparadas para la masificación y que se convierten en cultivo para las epidemias, etc). Por entonces, el corazón de Inglaterra es el BlackCountry, donde se ambientan las novelas victorianas de Dickens. Las arterias, son las vías de tren, que estallan en la crisis a mediados de siglo.

Es por ello que la vida de William Morris puede leerse como un resumen de los debates y fuerzas que latían bajo el siglo XIX, una sociedad de incipiente capitalismo industrial y moral victoriana. A lo largo de su vida, trabajó dos ideas básicas: por un lado, una teoría del consumo fundamentada en dotar de sentido y belleza a los objetos de la vida cotidiana; por el otro, una teoría de la producción que se sustentase en la recuperación del placer en el trabajo.

Morris y el consumo

«I do not want art for a few, any more than education for a few , or freedom for a few.»

— William Morris, The lessert arts

A mediados de siglo, culminan los esfuerzos de Henry Cole por organizar la primera exposición internacional industrial y de comercio, «The great exhibition» en 1851, que fue todo un éxito: 14.000 expositores, 100.000 artículos en exposición, 6 millones de visitantes. Aunque la idea es francesa sólo un país con debates sobre libertad de comercio recientes como Inglaterra estaba preparada por entonces para llevarla a cabo. El mismo Cole, veía la exhibición como la muestra de que Inglaterra estaba preparada para el libre comercio y la primera globalización.

Pero para Cole la exposición era también un impulso a lo que él mismo había iniciado dos años antes con la publicación de la revista «Journal of design and manufacturers»: estimular el debate del diseño en la producción en serie. En este aspecto, la exhibición fue polémica. Muchos la consideraron un horror, la confirmación de que la deshumanización del trabajo que supuso la industrialización no podía producir cosas bellas. De fondo, lo que se estaba rumiando era un debate estético: ¿son las bellas artes (pintura, escultura, …) y las artes decorativas (orfebrería, cerámica, textiles, …) la misma cosa? ¿es posible que la producción en serie integre la belleza?

Owen Jones, uno de los pioneros del diseño, decía que la decoración de los objetos no era importante:

«Ornament must be secondary to the thing decorated, wallpapers and carpets must not have any patterns suggestive of anything but a level or plain.»

Era algo que se hacía a posteriori, una vez la pieza está acabada. El barniz.

Morris, sin embargo, consideraba que la búsqueda de la belleza trascendía el arte y las actividades artísticas (pintura, escultura, etc), que el diseño de los objetos importa. Esta declaración es lo que pone a Morris en el árbol genealógico del diseño industrial. Según él, el objeto en sí mismo porta contextos y la relación que tenemos con ellos debe tener significado. La felicidad no estaría en el número de objetos que poseemos, sino en la belleza y significado que tengan. Critica, además, cómo esa diferenciación entre bellas artes y artes decorativas favorece la creación de clases sociales: los artistas, que serían personas intelectuales, gentilhombres y profesionales; los artesanos, que serían mano de obra asalariada que cobran por semanas.

Se consolida así en Morris el deseo de producir objetos bellos, de calidad y duraderos que puedan ser asequibles para todos.

Morris y la producción

De formación arquitecto, la vida de Morris es en realidad la de un renacentista: diseñador de interiores, tipógrafo, poeta, traductor, escritor de novelas de ciencia ficción, pintor, fundador de la Sociedad por la Recuperación de edificios históricos, etc. Aunque quizás por lo que hoy en día más se le conoce es por haber sido uno de los fundadores del movimiento Arts&Crafts. Y todo empezó con una casa.

Con motivo de su boda, consigue reunir a sus amigos para construir una nueva vivienda familiar como regalo a su esposa, la Red House.Philip_Webb's_Red_House_in_Upton

Al acabarla, unidos por el sentimiento cooperativo y el juego que ha supuesto esa creación inician una empresa conjunta de diseño de interiores que todavía hoy existe, y que se consolida en los siguientes años como la Morris&Co. Es en esta compañía en la que Morris puede aplicar las ideas renacentistas del trabajo desarrollando una teoría organizativa que bebe de los gremios medievales:

  • orgullo por el trabajo bien hecho
  • una relación maestro/aprendiz en las relaciones internas
  • productos de calidad, duraderos y con sentido hacia el mercado

Aunque Morris no era un ludita, consideraba aberrantes las condiciones de trabajo industriales que ponían al hombre al servicio de la máquina, desconectaban al artesano de su relación con los objetos y desposeían de placer al trabajo mismo. Tampoco era ajeno a que la industrialización suponía que el capitalista era el que tenía la relación con el mercado, no el trabajador/artesano.

Es decir, la lectura que hace Morris de la industrialización es que supone una pérdida de independencia que la clase media había ganado en el medioevo.

Morris como activista y filósofo

Morris se define a sí mismo como un socialista constructivo, que ofrece esperanza frente al socialismo destructivo que piensa que la situación actual es insoportable y horrible y la manera de superarla es conmover la sociedad a golpes hasta que se tambalee y caiga. Su objetivo es la búsqueda de la abundancia para todos:

El progreso y victoria sobre la naturaleza para generar riqueza es clara en nuestra época. Todos deberíamos ser ricos. Sin embargo existe un gran masa social explotada que no puede acceder a los bienes más básicos y muchos otros que no pueden perseguir sus disfrutes y deseos para los que la civilización es mezquina y torturadora. Los frutos del progreso nos han sido robados, impidiendo el disfrute de las tres esperanzas.

A nivel político, plantea una visión muy moderna que desarrolla principalmente en «Cómo vivimos y cómo podríamos vivir»: la competencia comercial entre naciones lleva a la guerra, la colonización y al desaprovechamiento de recursos. Como alternativa, propone una aldea global con producción y distribución coordinada en calidad/cantidad, libre comercio y movilidad de personas y el renacimiento social basado en el empoderamiento e independencia de la clase media.

A nivel individual, considera que existen 3 facetas principales que nos harán personas plenas:

  • Esperanza del descanso, o de reposar lo suficiente: seremos mejor que las bestias.
  • Esperanza de obtener un buen resultado y disfrutar de lo realizado: seremos mejor que las máquinas.
  • Esperanza por tener placer en el propio trabajo: seremos hombres.

Su programa político podría definirse como la subordinación del trabajo y capital a las necesidades de la comunidad a la que sirve. No producir objetos inútiles o sin sentido, no crear tareas vacías o no gratas.

Morris en los albores del mundo maker

Hay varias lecciones que podemos aprender de la historia de Morris:

  • la clase media como esperanza: si el cambio productivo significa algo es ganar la capacidad de vender productos diseñados por nosotros mismos en un mercado global. Es decir: apostar por la globalización de los pequeños. El enfoque es recuperar la autonomía que se perdió en la industrialización.
  • el diseño en el centro: fue medio siglo después de que Morris apostase por el diseño en los objetos cotidianos, que las modernas escuelas de diseño rusa (Vkutemas) y alemana (Bauhaus) consiguieron imponer su legado. Hoy, como entonces, el diseño es el centro de la producción.
  • productos, no artesanía: si bien el movimiento Arts&Crafts acertó el diagnóstico (integrar el arte en la producción de objetos cotidianos), erró en la receta (quedar al margen de la industrialización y la producción en masa). Fueron empresarios como Thonet, con 50 millones de sillas vendidas entre 1859 y 1930, los que llevaron su arte a las clases populares, siendo la gran tragedia de Morris (y una de las razones por las que abandonó la empresa) que su base de cliente fuesen las clases adineradas. Aunque no eran luditas, sí tardaron en crear un discurso favorable al uso de tecnología e introducirlas en su trabajo, y eso impidió que sus ideas de organización del trabajo y la sociedad tuviesen mayor recorrido.

El mundo de Morris tiene muchas similitudes con el nuestro. Vivimos, al igual que él, en un futuro muy steampunk.

by Andrés at January 14, 2016 12:44 PM

January 12, 2016

Andrés Maneiro

2 historias para recordar la Alemania nazi

Hoy os quiero recomendar 2 películas basadas en hechos reales sobre la Alemania nazi:

Valkiria Los_falsificadores

Valkiria narra los hechos del atentado del 20 de Julio de 1944 contra Hitler por parte de cuadros del ejército alemán. Visibiliza parte de la resistencia alemana descontenta con las atrocidades del régimen, pero también con ciertas decisiones militares y el instinto de supervivencia de otros (que ven cómo el Reich está a punto de desmoronarse y no desean estar en el bando perdedor).

Los falsificadores es una película diferente. Ambientada en el campo de concentración de Sachsenhausen, cuenta la historia de un grupo de prisioneros a los que usaron para falsificar moneda con la que financiar la guerra en la llamada Operación Bernhard. El nudo de la película es el debate interno que tienen entre salvar su vida y privilegios en el campo continuando con la falsificación o poner trabas a la falsificación para minar otra de las fuentes de financiación nazi y acelerar el fin de la guerra.

Ambas nos recuerdan el peligro de la historia única. El hecho de que el monstruo haya sido tan grande y se haya construido sobre la inacción, nos hace olvidar lo atrevido que era rebelarse en un régimen como el nazi.

by Andrés at January 12, 2016 08:23 AM

January 11, 2016

Andrés Maneiro

December 30, 2015

Andrés Maneiro

The roles trilogy

La consultoría cooper, una de las referencias del sector, ha publicado un artículo que podría pasar desapercibido con facilidad: the roles trilogy. Dice que el diseño de un producto depende de la conjunción entre análisis de negocio, diseño y desarrollo.

by Andrés at December 30, 2015 04:50 PM

Una visita al Cooper-Hewitt

Aprovechando mi reciente visita a Nueva York para el CB15, hice una parada en el Cooper-Hewitt. Además de la mejor colección permanente de diseño de todo Estados Unidos, tenía un par de exposiciones que me interesaban: Pixar: the design of story y How posters work.

El Cooper-Hewitt

El museo nace de iniciativa privada, impulsado por las nietas de Peter Cooper bajo la tutorización de la Cooper Union for the Advancement of Science and Art, que nació como el primer club y luego universidad pública de Estados Unidos. La historia de este político, inventor e industrial es interesante por sí misma, al igual que la del Cooper Union.

Se dice que Sarah, Eleanor y Amy tomaron la inspiración del VAM londinense, fundado a mediados del siglo XIX, durante la revolución industrial y, al igual que éste, nace con el encargo de extender la cultura del diseño en el país.

El museo en sí es pequeño, aunque la colección se podría decir que tiende a infinito. Tienen, pues, un problema y las soluciones que han diseñado para resolverlo son interesantes. Por un lado, en su web, tienen una sección llamada “Object of the day” que destaca uno de los objetos de la colección. Permite, además, buscar objetos relacionados por ciertas temáticas y etiquetas.  En el museo, esta exploración se puede hacer mediante la mesas digitales y otros dispositivos donde juegas con formas, la inmersion room, etc:

Pero quizás lo más interesante del museo sea la experiencia pre y post-visita. Esto es algo que he visto por vez primera en el Cooper-Hewitt. Con la entrada, generan un código único para tu visita que luego puedes ver online. Durante tu visita, puedes guardar elementos en tu cuenta online interactuando con un bolígrafo digital que recibes con la entrada: con él puedes usar las mesas digitales para hacer tus propios diseños (dibujos de personajes de Pixar, muebles, etc), seleccionar objetos durante la visita, etc. Al llegar a casa, te conectas con el código que te han dado y puedes ver todo lo que has guardado.

Por otro lado, ciertas exposiciones como la de How Posters Work, tienen una experiencia pre-visita inmejorable.

Las exposiciones

Las expos temporales fueron de lo más divertido. Quizá la de Pixar sea la más atractiva para el público general por lo que significa aprender e interactuar con los personajes de pelis que nos han enamorado. Actividades para diseñar tus personajes, herramientas para entender el proceso de diseño de Pixar, etc. Aunque a mí, sólo por ver la evolución gráfica o las inspiraciones que tuvieron para diseñar los escenarios de Los increíbles ya habría valido la pena. Además de ver todas sus pelis he estudiado cómo trabaja Pixar así que puede que no sea muy objetivo.

Lou Romano, colorscript,

Sin embargo, originalmente la visita la planifiqué por la exposición How Posters Work, de Ellen Upton. La exposición está organizada en torno a ideas y conceptos claves de diseño gráfico, no por cronología o familias, es decir, está orientada al aprendizaje y la transmisión de conocimiento. Para incidir en esto último, han creado un MOOC donde la propia comisaria ejerce de guía e introduce los conceptos más relevantes.

howposterswork_color

Como aprendiz de diseño, tener un contexto previo de los objetos que voy a visitar me ha ofrecido una experiencia más profunda y enriquecedora. El arte y los museos pueden tener un fin distinto al mero regocijo del alma, pueden también servir para nuestra educación y crecimiento.

by Andrés at December 30, 2015 04:40 PM

December 18, 2015

Andrés Maneiro

December 07, 2015

Andrés Maneiro

FEED15DAG

Desde hace meses vengo reservando un tiempo a estudiar diseño: su historia y referentes, el encaje e impacto que tiene en una organización, elementos de percepción, técnicas de composición e interactividad, etc. De cuando en vez echo un ojo a los eventos de diseño pero nunca me había animado a ir a uno. Éste es el resumen de mi participación en el  #FEED15DAG.

feed15dag

Lo primero que me llamó la atención fue el programa y ponentes. No sólo conocía a algunos que eran referentes, sino que me parecía muy redondo: diseño de servicios, historia del diseño, etc.

Taller: crear un fab lab

El FEED15DAG empieza para mí el viernes, en el taller de Massimo Menichinelli. Nos enfrentamos al reto de diseñar un espacio maker. Embarcado como estoy en crear uno en mi ciudad ¡no me pudo parecer más oportuno! Massimo demostró una concisión y practicidad que agradecí mucho: no se trata de diseñar sólo un espacio con máquinas, sino una comunidad con actividades y relaciones entre personas. Manejó conceptos muy indianos como el análisis de redes, la economía directa y la producción industrial de baja escala y largo alcance. En cierta medida fue para mi una continuación de la gira maker de estos meses y que me llevó a Gijón, Santiago o Coruña.

Las charlas del primer día

El pistoletazo de salida para el público general lo dió por la tarde Pepe Barro, con la historia del logo de Zeltia. Para mi desgracia, desconocía la figura de Pepe y su trabajo. Una puesta en escena brillante de un tema que además me apasiona: la historia que esconden las cosas. Pepe ejerció de detective y, con las mejores maneras de sherlock, nos descubrió un mundo de relatos personales, viajes clandestinos, … para contar la historia de cómo el trisquel se convirtió en el logo de Zeltia.

Óscar Otero, centró su presentación en los 3 pies del desarrollo web. Óscar, no sólo ha hecho trabajos muy buenos, sino que ha escrito sobre cosas fundamentales como la tipografía. De su charla, me quedo con el concepto de micro-interacción y un montón de ejemplos que explorar para notas, mi almacén de ideas.

Miguel Sabel, consultor de innovación y diseño en DesignIt centró su exposición en el encaje entre diseño y negocio así como el encaje organizacional: design thinking, service & business design, etc. Su charla ha ilustrado y matizado conceptos a los que llego por la lectura reciente de Bill Buxton y su Sketching User Experiences (la primera parte del libro está centrado en una reflexión acerca del encaje organizacional del diseño).

Cerró la tarde Massimo de nuevo, ampliando conceptos que habíamos trabajado por la mañana, como el diseño colaborativo, open design y su historia.

Taller: diseño para big data

El sábado la mañana empieza con un taller de Javier Cañada sobre diseño para big data. Además de compartir conocidos y amigos comunes, a Javier lo llevaba tiempo siguiendo por su trabajo y me hacía especial ilusión su taller. Con una capacidad de síntesis enorme nos presenta primero los conceptos teóricos con los que trabajaremos: la diferencia entre analógico y digital según Otl Aicher, las 3v del big data, los elementos de percepción y las variables de composición que manejamos como diseñadores. Y nos suelta frente a un reto / problema que tenemos que resolver en las siguientes 2 horas. A nuestro grupo le tocó diseñar la interfaz e interacción de un wearable, al que ya le tenía ganas! Es imposible describir lo que uno aprende de colaborar con maestros del diseño y recibir feedback de tu propuesta de otros 20 alumnos y Javier Cañada.

Las charlas del segundo día

La tarde se inicia con otra de las más esperadas: el infografista Álvaro Valiño. Una de las cosas más agradecidas de estudiar diseno son las infografias: composición y narrativa en acción. A Álvaro lo conocía porque, investigando sobre esto, me he encontrado como curiosidad que empezó trabajando en LaVozDeGalicia, donde coincidieron algunos infografistas de gran prestigio internacional en la actualidad: Álvaro, Xocas, Chiqui Esteban y más! Luego de un recorrido por algunos ejemplos históricos, repasa las capacidades y técnicas que un buen infografista debe conocer, para finalizar diseccionando en profundidad el proceso creativo de uno de sus trabajos. Fue muy agradecido tener una ventanita a ese proceso y tratar de entender cómo uno afronta ese tipo de trabajo.

Continúa la tarde con Marta Valverde, diseñadora de espacios interactivos. Marta ha trabajado con músicos y artistas en la creación de espacios y visualizaciones, así como con grandes compañías en la creación de espacios publicitarios. Marta se autodefine principalmente como programadora creativa: arduino y processing son las herramientas con las que ha creado cosas que los demás todavía sólo podemos imaginar. El gran descubrimiento de las jornadas.

El foro se cierra con Raquel Pelta y Javier Cañada, pero por problemas logisticos no pude estar.

Conclusión

El FEED15DAG ha sido, junto con el SOMERO15, el evento más inspirador del año. No sólo se habló de diseño gráfico e industrial, interactividad con arduino, interacción en productos digitales, infografía, design thinking, etc, sino también de aspectos transversales como la historia del diseño o el rol que puede desempeñar dentro de una organización.

La verdad es que luego de esos meses de gira, cierro el año 2015 con mucha energía que enfocar para 2016.

by Andrés at December 07, 2015 03:36 PM

December 02, 2015

Andrés Maneiro

Energía capturada

La noticia de la semana es que Iberdrola ha sido sancionada por manipulación de precios de mercado (PDF de la sanción). Está acusada de subir artificialmente el precio de la energía de las centrales hidroeléctricas a finales de 2013. Según el regulador, los beneficios habrían sido de 20 millones y la multa es de 25, aunque otros expertos dicen que los beneficios podrían haber sido el triple. Por ponerlo en perspectiva, si un particular usa para autoconsumo un panel solar no inscrito en el registro la multa puede llegar a 60 millones.

10306369695_7e94a2ca51_z

Para entender el caso, conviene saber cómo se establece el precio de la energía: a mayor uso de gas y carbón en la generación, mayor precio. Así, en períodos con mucho viento, lluvia o sol los precios son menores. La trampa de Iberdrola ha sido que, en un período de bajo uso de renovables, se guardó el agua disponible para generación hidroeléctrica (a pesar de que no era época de sequía) para favorecer que se tirase más de gas y carbón. El resultado fue que millones de consumidores de energía en España han pagado ese sobrecoste en sus facturas. Esto ocurrió días después de que el gobierno decidiese retirar 3.000 millones en subvenciones a las eléctricas para usarlos para paliar el déficit del estado.

¿Qué puedo hacer?

Lo cierto es que es un caso frustrante y humillante. Lejos de ser un algo aislado, es una gotita más que contribuye a extender la imagen de instituciones energéticas capturadas.

¿Qué puedo hacer ante esto? Usar mis superpoderes:

  • como consumidor, elegir distribuidoras energéticas que además apuesten por la producción de renovables.
  • como ciudadano, difundir esta vergüenza y ayudar a la creación de una opinión pública favorable a arreglar este desaguisado.
  • como votante, acudir a la cita del día 20D de diciembre favoreciendo opciones que tengan en su programa la creación de un verdadero mercado de la energía y la transición hacia energías verdes.

Pasa la bola. Compartir la frustación la hace más llevadera.

by Andrés at December 02, 2015 06:51 AM

November 25, 2015

Andrés Maneiro

Calypso

Automattic ha publicado una nueva versión de WordPress.com y liberado su tecnología base. TL;DR: tecnologías Javascript, Node y Electron con separación entre API e interfaz.

01-writing-with-dock

Su CEO, Matt Mullenweg, lo cuenta de la siguiente manera: una de las cosas más difíciles en tecnología es hacer productos disruptivos contra ti mismo, aunque sea fundamental para sobrevivir. A nivel negocio, un cambio de este calado promete habilitar de nuevo el crecimiento del producto.

Aunque los cambios se limitan a la interacción en wordpress.com, probablemente veamos pronto su extensión a la propia plataforma WordPress. Esto no va a ser sencillo. El reto aquí es mayúsculo, porque necesitan que miles de programadores y compañías que usan WordPress se migren a la nueva base tecnológica. ¡Y conservarlos! En Automattic saben bien que este ecosistema es su potencia y también saben lo difícil que puede ser una migración: la historia de adaptación de su equipo es tremenda e incluye cambios no sólo tecnológicos sino también de proceso. Aunque con vértigo, en Automattic el cambio se ha visto facilitado por una cultura que apuesta por la autonomía y la promoción/reciclaje interno de las personas. Por eso, al liberar su código están de alguna manera proponiendo a su comunidad que lo estudie y pueda empezar a trabajar usando patrones similares, bajando los costes iniciales de investigar y adaptarse. El Mumi propone una fiesta.

by Andrés at November 25, 2015 05:41 AM

November 04, 2015

Andrés Maneiro

Software en la industria del automóvil

Un comentario interesante sobre cómo desarrollan software en la industria del automóvil: un entorno con vida útil del sistema mayor a 10 años y con bajas especificaciones de hardware.

TL;DR: usan variables globales que sólo pueden ser ser escritas desde un único lugar para conseguir un entorno concurrente y determinista en cuanto a tiempos y memoria (todas las variables son estáticas). La unidad de encapsulación son las funciones. Se diseña para que la actualización de los sistemas o subsistemas resulte de cambiar una función por otra. A nivel control de versiones cada subsistema/módulo tiene su propio repositorio de código, creando otro de integración para cada coche/producto con los subsistemas deseados.

by Andrés at November 04, 2015 07:39 AM

November 02, 2015

Andrés Maneiro

Halt and Catch Fire

Scoot McNairy as Gordon Clark, Mackenzie Davis as Cameron Howe and Lee Pace as Joe MacMillan - Halt and Catch Fire _ Season 1, Gallery - Photo Credit: James Minchin III/AMC

Por recomendación indiana, he empezado a ver Halt and Catch Fire. El argumento se centra en una compañía de la pradera del silicio, que entra en la carrera por la fabricación de los ordenadores personales, con un clon de IBM. En muchas fases podría leerse como una historia de COMPACT, pero en realidad la serie pretende ser el relato de una generación y un mundo donde todo era posible.

Me encanta el planteamiento y los pequeños detalles: que la localización sea en Texas, la pradera del silicio, en vez de en el valle del silicio no me parece gratuita y es un golpe al ego de un lugar y mitología sobrevalorada, cuando no directamente falsa. Los personajes son grandiosos: un yuppie de los 80 que se ve reflejado en coetáneos como Jobs y Belfort , una punk brillante como programadora pero sin experiencia laboral a la que encargan construir la BIOS del sistema, un matrimonio de diseñadores de hardware que han abandonado sus aspiraciones de crear el mejor computador por asegurar la vida familiar. Y secundarios tan reales como rancios.

De ese cóctel surge una serie interesantísima que refleja las tensiones empresariales y creativas de un proyecto ambicioso, pero lleno de oportunidades.

by Andrés at November 02, 2015 01:54 PM

October 30, 2015

Andrés Maneiro

October 28, 2015

Andrés Maneiro

Safe Harbor

A raíz de la denuncia de un ciudadano austríaco contra el uso que hacía Facebook con sus datos, el tribunal europeo de justicia declara inválido el acuerdo Safe Harbor entre la Unión Europea y los Estados Unidos. Este acuerdo permitía a compañías que tenían sus servidores en Estados Unidos autocertificar que cumplían la directiva de privacidad europea y, por lo tanto, poder almacenar datos de caracter personal para clientes europeos.

Con la cancelación del acuerdo ya no lo están y, aunque se está trabajando en una actualización del acuerdo, ahora mismo, a nivel práctico, bien las compañías estadounidenses crean centros propios en Europa (y almacenan allí los datos de clientes europeos) o bien las compañías europeas cambian de proveedor y almacenan sus datos en empresas con hosting en Europa.

by Andrés at October 28, 2015 03:55 PM

October 21, 2015

Andrés Maneiro

Las economías de alcance, según Beck

«Mass production is founded on the assumption that the value of the things you produce is greater than the value of what you learn. As you make more, you learn more, but slowly. That’s okay, because you’re going to make millions more that will benefit from your learning. No rush.

image

When you reverse the proportion, when learning is more valuable than things, then economy of scale goes haywire. Putting off learning because “oh, we’ll make a million more,” no longer makes sense. The leverage is in learning, not production. You are willing to sacrifice today’s production for tomorrow’s improvement.»

image

Kent Beck ha escrito sobre las economías de escala VS las economías de alcance, comparándolas desde el punto de vista del proceso. Es importante lo que dice porque engancha el contexto que nos encontramos en el mercado (reducción de escala de producción) con las variables que necesitas optimizar en tus procesos (rapidez, aprendizaje), dándole a los ciclos ágiles de desarrollo una justificación económica, además de humana y tecnológica.

by Andrés at October 21, 2015 07:10 AM

October 14, 2015

Andrés Maneiro

Somero 2015

Me he pasado la semana pasada en Gijón, en el #Somero2015, un evento poco convencional donde podías a la vez desarrollar código, socializar con programadores y conversar con los líderes y policy-makers del futuro. Todo en un mismo pack. El hilo conductor fue el futuro en la sociedad distribuida: la producción de baja escala que habilitan el hardware y software libre, la resiliencia de las infraestructuras urbanas, el futuro de la banca y los cambios sociales que se avecinan.

Me resulta imposible resumir todas las conversaciones que he tenido con catedráticos de economía, jugadores de go, diplomáticos de comunas, presidentas de cámaras de comercio, programadores, activistas por los derechos civiles en internet, emprendedores tecnológicos, líderes políticos, etc; personas de Suecia, País Vasco, Estados Unidos, el levante español, Nápoles, Londres, Argentina o Madrid. No recuerdo jamás haber estado en un evento tan diverso y con gente tan dispuesta a entablar conversaciones con completos desconocidos. ¡Me lo he pasado en grande!

Esa sensación de cercanía y aprendizaje ha estado amplificada por el hecho de que el evento ha tenido una lectura interna para los que participamos en lamatriz.org: nos hemos desvirtualizado. Comparto todo lo dicho por Gustavo. Me ha sorprendido verme en conversaciones donde intuías lo que iba a decir alguno de los presentes, lo esperabas y repartías juego para que todos participásemos. He tenido una sensación de familiaridad y valores compartidos muy profunda sobre aspectos básicos de la vida: orientación a mercado, una cierta sensibilidad hacia estructuras distribuidas de poder y distribución, conocimiento y apuesta por las tecnologías libres, … son cosas que no se encuentran fácilmente en una conversación, o al menos no con tanta naturalidad.

En definitiva, el #Somero2015 me ha recargado las energías y me ha conectado con un montón de gente con la que quiero empezar o continuar haciendo cosas juntos. ¡Estoy deseando que venga ya el #Somero2016!

by Andrés at October 14, 2015 07:09 AM