El Blog de Joac

noreply@blogger.com (Joac) — Fri, 22 Aug 2025 17:25:00 +0000

Debugging the Human Layer

How philosophy, radical ideas, and a few humbling books reshaped how I understand software engineering.

I. The Most Dangerous Idea I Ever Learned

I still remember the moment I first read the story of Socrates, as told by Plato. There he was: a man wandering Athens, annoying the powerful, relentlessly questioning everything. But what struck me most was his conclusion: “I know that I know nothing.”

At the time, I didn’t realize it would become a survival skill.

I learned to code on my own, as a kid, without formal instruction or community. For years, I thought being good at programming meant knowing things. Now I know better: it means knowing how little you know, and how fast everything can change. That epistemic humility—that awareness of your own ignorance—is what truly stuck with me. And it’s the thread that ties together my entire journey.

II. Dijkstra, and the First Shock of Radical Thinking

My first encounter with Edsger Dijkstra was jarring. Here was someone who didn't just love correctness—he demanded it. To him, programming was mathematics in disguise. The sloppiness we tolerated was unacceptable. His writing felt like a slap across the face.

But it was also a gift.

Dijkstra taught me to take programming seriously. He showed me that under the hood of our “move fast and break things” culture, there’s a deeper discipline—one that demands clarity, precision, and restraint. He didn’t make me a purist. But he made me humble.

III. From Code to Product: My Second Awakening

My early years were all about code. I loved it, and I thought that was the job. Then I entered the workforce—and everything changed.

Suddenly, my brilliant code wasn’t enough. Features didn’t ship because requirements changed. Deadlines slipped because of unclear priorities. Merge conflicts became emotional conflicts.

That’s when I realized something: building software is not about writing code. It’s about delivering value to real people, within real organizations, with real constraints. And that means dealing with complexity—not just technical complexity, but social complexity.

IV. The Mythical Man-Month: A Book Everyone Quotes Wrong

Reading The Mythical Man-Month by Fred Brooks was like finding the missing manual to software teams. The famous line—“Adding manpower to a late software project makes it later”—is just the beginning.

Brooks was trying to show that software development isn’t like manufacturing. It’s about communication, shared mental models, and the cost of coordination. And yet, the book is constantly misquoted to shut down hiring or collaboration efforts, instead of sparking deeper questions.

V. Conway’s Law: Your Org Chart Is in Your Codebase

Next came Melvin Conway’s 1968 paper, “How Do Committees Invent?”—a short, strange little document that continues to explain why so much software is weird.

Conway’s Law says that systems reflect the communication structure of the organizations that build them. And once you see it, you can’t unsee it. The front end talks to the back end like two rival departments. The database mirrors the ops team’s paranoia. Microservices become miniature fiefdoms.

Understanding this changed how I looked at software architecture—and org design.

VI. Peopleware: Where Everything Finally Made Sense

Peopleware, by DeMarco and Lister, broke me open. It said, plainly: the biggest problems in software are not technical—they’re sociological.

It talked about flow, distractions, toxic management, and the importance of safety and trust. It felt like someone was finally saying out loud the things we all sensed but couldn’t articulate. And for someone with ADHD like me, it gave language to the invisible frictions I felt every day.

VII. Thinking in Systems: Donella Meadows and the Hidden Loops

Donella Meadows’ Thinking in Systems was the last major piece of the puzzle.

Her book introduced me to feedback loops, delays, leverage points, and the subtlety of change. It showed me why naive interventions often backfire. Why “more engineers” doesn’t always mean “faster delivery.” Why teams plateau, burn out, or spin in circles.

This was the moment I realized I wasn’t working on a product—I was working inside a system.

VIII. Modern Software Engineering: Science, Feedback, and Flow

David Farley’s Modern Software Engineering helped me reconcile rigor with iteration. He showed that engineering is not about certainty—it’s about learning. It’s the scientific method under constraints. Test, observe, adapt.

This clicked with my experience. It gave a name to the intuitive loop I’d been building: act, reflect, refactor. And it gave me permission to be curious instead of dogmatic.

IX. Debugging the Human Layer

All of this led me to a simple, hard-earned conclusion:

The hardest bugs are social.

It’s not your code that will sink the project—it’s the trust that was never built, the message that was never sent, the expectation that was never aligned.

Good engineers aren’t the best coders. They’re the ones who can listen, co-create, and build systems—of people, of habits, of care.

Final Thought

We’ve spent decades trying to make software better by writing smarter code.

Maybe it’s time we wrote kinder systems instead.

Algo mas de 140 caracteres.

noreply@blogger.com (Anonymous) — Fri, 28 Aug 2015 22:46:00 +0000

Desde hace un tiempo, lo único que cuento lo hago por twitter. Cientos de mensajes cortos que intentan comunicar lo que pasa con la causa.

Hay días que también hablo sutilmente, de como me siento yo.

Pero, releyéndolos, me encuentro con que en el fondo, no logro expresar del todo las cosas. Esos 140 caracteres obligan a reducir, recortar, y de alguna manera auto censurarnos.

Es que los últimos 64 días que pasaron desde el reporte de la vulnerabilidad y el ataque informático que estaba sufriendo MSA, fueron muy intensos.

Antes del allanamiento, miedo a que las personas responsables del ataque informático me hicieran daño a mi o a mi familia.

Después, miedo a que la justicia no opere de forma correcta, que me condenen sin pruebas, que la causa sea solo para meter miedo.

Alrededor de esas cosas quedan otras: el desgaste sobre los afectos, el estrés, y la enorme impotencia de ser considerado culpable por amistades.

Si, adentro de MSA, hay varias personas que, mas allá de las diferencias políticas e ideológicas que podamos tener, consideraba amigas.

¿Será acaso que, por estar en contra de los sistemas de votación electrónica que ellos proponen, piensen que no tengo ética profesional?

¿O que consideren que soy capaz de hacer daño en sus servidores solo para demostrar los riesgos?

Están equivocados.

Porque en el momento en que les avisé, pude separar mis propias convicciones, de lo estrictamente ético y profesional.

Les pido, a aquellos que trabajan en MSA con los que compartimos cosas en espacios de las comunidades de software libre, que traten de hacer lo mismo.

Porque con lo que está pasando, perdemos todos.

Pixels de colores.

noreply@blogger.com (Anonymous) — Fri, 03 Oct 2014 16:08:00 +0000

Desde que tengo memoria, pintar cosas con colores me costó muchísimo.

En la escuela primaria, por ejemplo, mis cuadernos tenian dibujos en lápiz negro, y grisados. Mi abuelo dibujaba así y lograba efectos buenísimos.

Para mi los lápices de colores se transformaban en bestias indomables que desparramaban color sin llegar a gustarme.

Cuando empecé a programar, siempre me escudé en "Yo hago la lógica, que otro le ponga colores". En fin, años de traumas por no poder combinar dos colores o mas.

Hace un par de años, en una de las visitas a mi genial sobrina Catalina, mis tios le mandaron conmigo una caja de acuarelas, y yo le llevaba libros de Oliver Jeffers.

Fue asombroso.

Probablemente tendría que escribir un post entero sobre como el hacer actividades en las que nos sentimos inseguros, junto con niños, puede cambiar nuestras perspectivas.

El resultado, montones de dibujos "en colaboración" con mi sobrina, analizamos juntos los dibujos de Jeffers y tratamos de darnos cuenta como lograba los efectos.

En ese momento, me di cuenta que necesitaba volver a dibujar y mejorar mi tema con los colores.

Miré videos, lei tutoriales sobre teoria del color y nada parecia mejorar.

Entonces mi primo Nahuel, me recomendó una charla, que me hizo cambiar mucho mi forma de ver las cosas:

En resumen, si no van a ver el video completo:

Dibujar todos los días, analizar que nos gusta de las cosas que nos gustan, copiar y transformar.

Una de esas cosas que hice fue mi portada para twitter usando pixeles grandotes. Para eso usé inkscape, y fue bastante engorroso.

Terminada la portada, me animé a hacer un patron para usar de fondo, el resultado... triste...

Es difícil hacer patrones repetitivos, sin que "el atomo" que se repite sea demasiado obvio.

Por eso, luego de escribir toneladas de javascript para el proyecto en el que estoy laburando, decidí tomarme un rato de programación lúdica, y armé pixium, una herramienta muy sencilla, para crear patrones.

El resultado, adictivo.

Como conclusión: dibujar y programar son cosas parecidas, ambas implican creatividad, y la mejor manera de estimularla es haciendo y analizando. Eso, creo, es fundamental para aprender.

Chau Carlitos

noreply@blogger.com (Anonymous) — Mon, 16 Sep 2013 13:38:00 +0000

La semana pasada falleció mi querido abuelo Carlos, un inmenso filosofo y guia en el trajín de la existencia.

Sentí la necesidad de escribir unas palabras para leerle a la familia, antes de que su cuerpo sea cenizas. Lo comparto aquí:

Pensé que sabía como era la tristeza.
Pero no sabia.
En este ultimo tiempo, empece sin darme cuenta a vivir como vivías: mas despacio, mas en el presente; saboreando el tiempo sin apuro, disfrutando toda la belleza sutil que los hombres pudieron ver en un tiempo. Y es tan bello.
Que suerte tuvimos de tenerte cerca, paisano del medioevo. Nos dejaste las herramientas y la sabiduría para transformarte en leyenda. Nos dejaste el amor por la simpleza, por lo bello, por los culos de rebosantes gorditas porteñas.
Nos querias. Lo demostrabas con formas acordes a tu personalidad. Nunca regalaste un libro. Regalaste invitaciones a leerlos, y cumpliste tu objetivo de despertar miradas y enseñar a ver.
Ahora la digestora del tiempo nos hará recordarte. Nos la dejaste fácil. Basta con repetir tus frases, escuchar tus canciones favoritas. Mirar con ojos atentos, o sentarse en el banquito (del museo de Bellas Artes) a planear un robo romantico e imposible. Como vos.
Vas a ser el héroe de tataranietos curiosos por saber de ese pequeño cúmulo de sabiduría, amor y sensibilidad. Gracias. Por escuchar y por ser. Por dejarnos un cacho tuyo aun por descubrir.
Ha muerto un gran hombre. Lloro por los irreversible.

El pequeño imcomprendido

noreply@blogger.com (Anonymous) — Thu, 06 Jun 2013 18:05:00 +0000

Este post podría hablar de mi mismo, de los problemas que creo que tengo para lograr que otras personas me entiendan, pero no, eso lo dejo para otro día, o mejor para el diván.

Hoy revisar un poco sobre otro pequeño incomprendido, que comparte mis iniciales: JavaScript

Un poquito de historia

JavaScript fué creado en Netscape por Brendan Eich. Querían un lenguaje interpretado fácil de aprender, en cierta forma, como Visual Basic. El nombre en clave era "Moca", pero como en ese momento estába de moda Java, le pusieron JavaScript. Esa fué, en mi opinión uno de los principales vectores de la confusión e incomprensión que sufre el lenguaje. Si querés aprender y no sabes la diferencia, podes llegar a seguir un tutorial complejo de Java por error, y los lenguajes, en si, solo comparten cierta sintaxis heredada de C.

Según cuenta la leyenda, a javascript lo crearon entre gallos y madrugada, y como estaba aparentemente listo y completo, lo metieron en Netscape, así como estaba. No es que JavaScript no sea un lenguaje de programación "turing completo", es que hay algunos comportamientos que son distintos de lo que un programador con cierta experiencia podría esperar.

Como lo viví yo.

Si bien mi primer lenguaje fue Logo, allá por 1994, y tuve pasos fugaces por Visual Basic y C++, mi romance mas fuerte fue con python. Python es un lenguaje lindo, es como una chica linda, inteligente y comprensiva, que te ayuda a que programar, te avisa cuando estas haciendo burradas, y por lo general es sincera con vos. Esas "bondades" hacen que uno analice muchos aspectos de otros lenguajes de programación. Desde ese punto de vista, JavaScript es horrible, criptico, e impredecible.

Pero siempre en la vida de un programador, por necesidad, o eventualidad tenes que escribir código PHP

(que tire la primera piedra quien esté libre de PHP...) y ahí la visión cambia. PHP es como el estereotipo de minita, es lo que quiere el mercado, cuando las cosas no andan bien no te dice nada, cuanto mas lo conoces mas de mentira te das cuenta que es, y termina siendo una relación dolorosa (Por ahí para PHP no porque es bien minita). Desde esa comparación, JavaScript queda bien parado. Vendría a ser el lenguaje mas humano posible, con sus idas y vueltas, pero real, sin mentiras. Los lenguajes de programación, son en cierta forma como las personas, si te dejas llevar por la primera impresión, te podes equivocar, y tienen imperfecciones, como todos, si, hasta Python tiene sus grises.

Por donde arrancar

Al menos para mi, es importante estar motivado para hacer algo, las cosas que mas me motivan de JavaScript, es que esta cada vez en mas lugares, o mejor dicho, hay cada vez en mas dispositivos que tienen browsers. Por otra parte, existe node.js, que nos permite escribir servidores asincronos usando el lenguaje, e incluso hay robots que usan JavaScript.

Lo que considero clave para aprender y querer al lenguaje, es aceptar que es distinto. No tiene clases "per se", y los ciudadanos de primer nivel son las funciones. Es un lenguaje funcional.

Muchas veces me paso de encontrarme con código en el lenguaje "X" como si fuese el lenguaje "Y". (Python como si fuese java, ultimamente). Es algo muy normal cuando trabajamos con una mezcla de tecnologías (en el caso de que desarrollemos web), pero lentamente, es importante profundizar en las diferencias, para escribir mejor JavaScript.

Los materiales que mas me sirvieron

Mi heroe personal en materia de Javascript es Douglas Crockford, autor de el ya mítico "The World's Most Misunderstood Programming Language", lamentablemente, no puedo recomendar traducciones, porque... no me gustan las traducciones.

Para seguir avanzando, y entendiendo el lenguaje, el elegido es "JavaScript the good parts".

Paul Irish, también es un crack, el screencast de "10 cosas que aprendí mirando el código fuente de JQuery", es un material tremendo.

Zafá del xml con Tryton Builder!

noreply@blogger.com (Anonymous) — Wed, 05 Jun 2013 17:23:00 +0000

Hay cosas que no me gustan, y hay cosas que detesto. En esa escala de valores, en el primer lugar está PHP y en el segundo los XMLs. Como conté en el post anterior, estoy desarrollando algunos módulos para Tryton, que define sus vistas, y elementos de interacción usando ese lenguaje de markup.

Hay varios artículos que hablan que uno tiene que ser un programador vago, yo estoy totalmente de acuerdo con que hay que ser un programador que automatiza al máximo el trabajo que no le gusta hacer, para poder dedicar el tiempo a problemas mas complicados o atractivos, o a mirar por la ventana.

En mi intento por zafar de escribir varios cientos de '<',' /', y '>' a mano nació Tryton Builder (Que tiene logo y todo!)

Por el momento, para generar un módulo, hay que escribir un pequeño archivo de código (Si, es código python, porque me gusta programar, no parametrizar, yamls, csv, y ese tipo de cosas) de este estilo:

En el ejemplo, estoy realizando todos los pasos para generar el modulo de ejemplo del wiki de tryton

Solo para comparar la diferencia de caracteres escritos versus generados:

El proximo paso, es armar una interfaz de consola como la de los scaffolders de Ruby On Rails

Monkey Patcheando Element tree para soportar cdata

noreply@blogger.com (Anonymous) — Tue, 04 Jun 2013 17:04:00 +0000

Hace un tiempo que estoy trabajando con Tryton, el ERP libre, escrito en python, y como me gustan los scaffolders de Rails, decidí escribir uno para armar los esqueletos de los módulos. Tryton, no se bien por que motivo, utiliza mucho xml, para definir vistas, y fixtures de datos. Como me gusta programar en python, me empezé a escribir una especie de DSL para definirlos de una manera mas amigable:
https://github.com/joac/tryton_builder

Python permite trabajar con xml con un montón de bibliotecas distintas, pero las mas amigable de usar, para mi es ElementTree

Cuando empece a escribir el codigo, y hacer pruebas, me encontré con varios problemas, el primero, ElementTree no tiene "Pritty Print"
para que el xml generado sea mas cómodo de leer, por suerte encontré esta receta:

en http://effbot.org/zone/element-lib.htm#prettyprint que resolvió correctamente el problema

Avanzando en el diseño de los scaffolders me encontré con otra limitación ElementTree no soporta el tag CDATA. Usted podria preguntarse "¿Que es el tag CDATA?", Básicamente un tag que le dice al parser "Lo que esta aca adentro es un conjunto de caracteres, no lo parsees"
Si bien se puede evitar el uso del tag, ingresando el texto escapado (por ejemplo, en lugar de '>' escribir '&gt' ) el objetivo es que el XML no deje de ser legible, encontré otras recetas en StackOverflow:
http://stackoverflow.com/questions/174890/how-to-output-cdata-using-elementtree

Pero finalmente, decidí escribir mi propia versión basada en algunos de los comentarios (la receta con mas votos no funciona en python 2.7+)

Finos Dardos

noreply@blogger.com (Anonymous) — Tue, 26 Feb 2013 00:03:00 +0000

Noche cerrada,

el momento de atacar

No es la victima dormida su presa,

es el noctambulo despierto

Carecen de veneno,

elijen preciso donde impactar.

Volando entre nubes neuronales,

minúsculos misiles dirigidos a las raíces.

Fibras que lo atraviesan todo,

hasta el descanso.

Luego la pausa,

la tormenta que no llega.

Las nubes que prometieron lluvia,

se van secas.

El viento que decide no soplar mas,

y disfrazarnos de silencio.

Y la lluvia empieza.

Salada.

Tibia.

De pronto sin aviso,

es río bravo.

Al momento amaina,

dejando ese sabor amargo.

Algunos lo taparan con vino.

Otros con distancia.

Y los terceros, engranajes pensantes,

tratarán de separar los gustos.

Así, algún día puedan,

hallar esa neurona amarga.

Dolor de espalda.

noreply@blogger.com (Joac) — Mon, 17 Dec 2012 21:32:00 +0000

Desde ayer estoy con un dolor de espalda importante, incomodo. Decidí reposar un poco, y evitar mayoritariamente estar con la computadora, que claramente, no me ayuda a mejorar mi postura.

En este rato largo, de unas 20 horas para pensar desenfrenadamente, me dediqué a revisar las cosas que me hacen sentirme raro cuando estoy con otra gente y las que me dan miedo.

La conclusion es bastante clara: soy una máquina de pensar, y en ciertos casos, de pensar de mas.

Me sorprende pensar, que muchas veces las cosas que quiero, son mas simples que el modelo mental que fabrico de ellas y mas espontaneas. Usted, querido lector, comprenderá que me gusta hacer música y otro tipo de cosas llamemos creativas, movilizadas, principalmente por la espontaneidad.

Hace un tiempo leí un libro llamado "Free Play" que habla un poco de lo procesos creativos y la improvisación musical. El autor diferencia claramente el "Juego Libre" que acompaña la creación de cosas (no nos importa si nuevas o no) y el proceso posterior de edición que completa, o refina la creación.

Me di cuenta, que en mi cabeza los dos procesos ocurren simultáneamente, por algún designio de un gen adicto a la concurrencia y la paralelización de procesos. Y como me gusta generarme paradigmas validos para seguir pensando mas y mas, a raiz de eso puedo explicarme, de alguna forma lógica, rebuscada e inhumana, varios comportamientos o cosas que nunca puedo lograr. O que al menos no puedo observar que logro.

Es ese proceso de autocensura constante, que no logra llevarme a intentar. Y ahi, es donde está la trampa. Porque, de las experiencias podemos aprender, y sacar conclusiones que nos ayuden a abordar otros intentos con mayor exito.

Y la pregunta de como medimos el éxito, lo dejo como tarea para el hogar. Quizás una respuesta esta justo al costado, y como sigo mirando para adelante, solamente, cual caballo con anteojeras, siga un largo trecho sin notarla.

Las Cosas Cambian

noreply@blogger.com (Joac) — Wed, 12 Dec 2012 03:40:00 +0000

Hace bastante, pero bastante en serio, que no escribo en este blog. Pero hoy, robándole un rato al sueño, me compro el desafio, y despunto al vicio de contar.

Es que las cosas cambian, y lo que uno vió ayer, y consideró una referencia válida, absoluta e inamovible, no es ni valida, ni absoluta, ni inamovible hoy. Es que la vida es mas compleja, es mucho mas compleja.

Porque tengo la certeza de que todos vamos a morir sin entenderla. Pero quizas, si logramos ser sabios, y aprender del vasto conflicto, lleguemos a ese punto de inflexión, al menos con la certeza de que buscamos todas las formas posibles de disfrutarla al máximo.

Es que existe mas que la búsqueda "estrella", "primero en profundidad" y otras que pregonan los textos de inteligencia artificial. Es la búsqueda, que ya de nacimiento sabe de la infinitud del universo y la certeza de que nunca se llegará a la respuesta esperada. Pero igual decide ser. Y transcurrir, despacio, muy despacio, llevandonos.

Y en el camino nos acerca a cosas, a gente, a proyectos, a historias, que valen la pena. Y la búsqueda en pleno ejercicio de sus derechos, se redefine y vuelve a llevarnos.

Y los seguira haciendo.

Decaer como cesio 137

noreply@blogger.com (Joac) — Fri, 21 Oct 2011 04:10:00 +0000

(leer escuchando esto)

Decaer.

Dejar que la vida lleve hacia abajo.

Mojar la medialuna en el café.

Prometerse a uno mismo que no llegará tan abajo.

Mirar el mar.

Esconderse en la bruma de la mañana.

Llorar por lo que paso.

Reirse de uno mismo.

Lo mas que se pueda.

Sonreir como si no importara el vuelo de los mirlos.

Prometerle a la mañana.

Que ella.

Será, por adelantado,

la dueña de la mañana.

Recordar los cuatro años.

Por que allí,

Y solo allí.

Aprenderas a decaer,

lentamente,

como el cesio 137.

Up things

noreply@blogger.com (Joac) — Fri, 30 Sep 2011 19:09:00 +0000

Después de la charla de Kragen Javier Sitaker en Pyconar 2011 me puse a trabajar en algunas obras de arte electrónico.

Así nació Up things (no pregunten el porque del nombre ), un repositorio en github donde voy poniendo las cosas que se me ocurren.

El primer proyecto es el lanzador de partículas. Les dejo unos screenshots:

Wish-list (Distancia)

noreply@blogger.com (Joac) — Wed, 15 Jun 2011 10:57:00 +0000

Quisiera que todo fuese mas fácil.

Quisiera despertarme con el sol pegándome en la cara.

Quisiera poder encontrarme conmigo. Invitarme a tomar un café. Preguntarme que es lo que me pasa. Contarme porque a veces tengo miedo. Y que el miedo paraliza. Pedirme disculpas. Perdonarme.

Quisiera estar parado en el filo de un cerro. Y sentir. La lejanía del valle. El viento desempolvando mis sueños. El aire rozando las alas de los cóndores.

Quisiera tener menos lastre.

Quisiera caminar sobre un suelo mas blando.

Quisiera mostrar mi debilidad y creer en la fortaleza.
Quisiera que los dos aprendamos de la distancia.

Atrapado en /dev/null

noreply@blogger.com (Joac) — Wed, 18 May 2011 11:54:00 +0000

Me estoy dando cuenta, soy un terrible procastinador. No se si sera porque pretendo abarcar todo, que mi ambición de conocimientos es intensa, pero no se prolonga demasiado en el tiempo.

Ya busque en Google...

Ya leí (como cruel motivo de dispersión) cientos de articulos de como Internet cambia nuestras vidas, nos roba la capacidad de conectración. Probé de usar pomodoros, GTD y cuanta metodologia de "reducción de las distracciones" encontré por ahi. Pero, como tantas otras cosas en mi vida, duraron solo un ratito.

Pero lo mas grave es que...

No puedo con la facultad.

Mi historial universitario no diverge mucho de lo que me sucede en otros ambitos de mi vida.

Cuando me vine para Capital en 2007, mi objetivo era estudiar, tratando de bancarme por mi cuenta(unica opción), pero la vida me llevó por otros caminos:
mudanzas, cambios de trabajo, vida en pareja, cambios de carrera ....

Aquí estoy ahora, des(orientado, motivado, animado). Me gusta la carrera que estoy estudiando (Ciencias de la Computación en la UBA). Pero no puedo avanzar. No es que sea un retardado, es que no puedo conectar con mi parte que
quiere estudiar y recibirse.

Ni comentar que el cuatrimestre pasado curse algebra y le puse todas las pilas a la teorica, me lei cuanto libro del tema encontre... pero hice menos del 10% de las practicas. Hoy la estoy recursando totalmente frustrado

¿Como salgo de este ciclo vicioso?

Puertos Serie Virtuales en Gnu/Linux

noreply@blogger.com (Joac) — Sun, 03 Oct 2010 23:12:00 +0000

Hoy estaba preparando mi charla para la PyCon2010 y me vi con la necesidad de crear puertos serie virtuales, para unos ejemplos que quiero dar...

La solución fue utilizar socat:

"Socat is a command line based utility that establishes two bidirectional byte streams and transfers data between them. Because the streams can be constructed from
a large set of different types of data sinks and sources (see address types), and because lots of address options may be applied to the streams, socat can be used
for many different purposes."

La linea en cuestión:

joac@pepino ~ $ socat PTY,link=vserial1 PTY,link=vserial2

Despues, desde pyserial, por ejemplo nos conectamos con:

import serial

ser = serial.Serial("/home/joac/vserial1")

Grupos vs Individuos

noreply@blogger.com (Joac) — Thu, 23 Sep 2010 11:45:00 +0000

Ahora que empezó la primavera, y el sol pega directo en la ventana de mi pieza, ayudándome notablemente a despertar, voy a tratar de resucitar mi blog.

Grupos vs Individuos

Me gusta programar, me gustan los desafíos, y me gusta aprender cosas nuevas. Tengo una especie de lema que dice "Si lo hizo un ser humano entonces puedo entender como esta echo", quizás demasiado abarcativo (notar que dije puedo entender). Esto es un arma de doble filo, por un lado, porque aprendo cosas nuevas, pero por el otro, desvaloriza los conocimientos de los demás.

Desde que trabajo en gcoop (ver posts anteriores) no trabajo mas solo, trabajo con un grupo. Este es un fuerte cambio en el paradigma que traigo desde (el autor no logra recordar, quizás se remonte a estados fetales pre-parto), y me hizo reflexionar bastante sobre esta forma de encarar los problemas.

Cuando uno trabaja solo, la comunicación sobre las tareas es básicamente con uno mismo. Pero cuando uno trabaja en grupo, la comunicación es distinta (Pensaba hacer una analogía con una Red pero es muy de ñoño), la toma de decisiones tiene mas posturas, y es ahí donde esta la verdadera riqueza.

Creo, que no existen dos personas que piensen parecido, todos tenemos nuestras propias estructuras mentales, y reaccionamos de distintas formas, a veces muy sutiles, frente a los estímulos externos. Es común que se encuentren diferentes formas de resolver un mismo problema.

Pero no todo es color de rosa...

Creo que uno de los principales problemas mundiales, después de los realmente importantes (como que miles de niños muren de hambre día a día), es la falta de comunicación.

Y en los grupos pequeños también pasa.

Quizás la cuestión importante es que desarrollar software no es solamente uno con las manos sobre el teclado, sino, que requiere de comunicación en su mayor parte.

(Este post va a ser editado, es un boceto)

Jueguito v2

noreply@blogger.com (Joac) — Sat, 17 Jul 2010 16:01:00 +0000

Ayer empecé el proyecto de un minijuego, clón de uno de blackberry.
Me di cuenta que sin colores era injugable, así que me puse a investigar como agregar colores a los prints de python, y me encontré con [1] en Stack Overflow, que explica como hacerlo.

Es muy fácil, con la salvedad que yo aproveche y cambié el color de fondo, en lugar del color del texto.

Ahora es mas cómodo de jugar.

La ultima versión (Provisoria) la encuentran en [2]

[1] http://stackoverflow.com/questions/287871/print-in-terminal-with-colors-using-python

[2] http://github.com/joac/joac-python/blob/master/minigame/minigame.py

Dejo unas capturas que hice:

El inicio del juego

Un par de jugadas despues

Ganamos!

Si no alcanzan los movimientos... Nos espera la derrota

Jueguito

noreply@blogger.com (Joac) — Sat, 17 Jul 2010 01:12:00 +0000

El otro día, me prestaron un blackberry que tenia un jueguito que me gusto, asi que hice una versión, para la consola, del juego, he aquí el código:

import random
import os

class Square:
    """This is the abstraction of one Square"""
    def __init__(self, x, y, attrib, root):
        self.x = x
        self.y = y
        self.attrib = attrib
        self.root = root
        self.rep = attrib

class Screen:
    """The Screen Array of the game"""
    def __init__(self, x_size, y_size, tokens):
        self.x_size = x_size
        self.y_size = y_size
        self.tokens = tokens
        self.childs = []
        self.squares = []
        self.populate()
        self.childs.append(self.squares[0][0])
        self.childs[0].rep = '#'

    def get_near_to(self, child):
        vecinos = []
        if child.x - 1 >= 0:
            vecinos.append(self.get_square(child.x - 1, child.y))
        if child.y - 1 >= 0:
            vecinos.append(self.get_square(child.x, child.y - 1))
        if child.x + 1 < self.x_size:
            vecinos.append(self.get_square(child.x +1, child.y))
        if child.y + 1 < self.y_size:
            vecinos.append(self.get_square(child.x, child.y + 1))
        
        return [vecino for vecino in vecinos if(not vecino in self.childs)]


    def get_square(self, x, y):
        return self.squares[y][x]

    def populate(self):
        for y in xrange(0, self.y_size):
            self.squares.append([self.random_square(x, y) for x in xrange(0, self.x_size)])

    def random_square(self, x, y):
        
        attrib = random.choice(self.tokens)
        square = Square(x, y, attrib, self)
        
        return square
    
    def check_arround(self, child):
        """We check the attrib of the near squares"""
        vecinos = self.get_near_to(child)
        if vecinos:
            for vecino in vecinos:
                if (vecino.attrib == child.attrib):
                    vecino.rep = '#'
                    self.childs.append(vecino)

    def __repr__(self):
        output = ''
        for row in self.squares:
            output += ''.join(['%s ' % str(a.rep) for a in row])
            output += '\n'
        return output
    
    def update(self, attrib):
        for child in self.childs:
            child.attrib = attrib[0]
            self.check_arround(child)
            

if __name__ == '__main__':
    screen = Screen(10, 10, ['1', '2', '3', '4', '5'])
    print screen
    screen.update(screen.childs[0].attrib) #dirty Hack
    limit = 18 
    win = False
    for b in xrange(1, limit):
        a = raw_input('_ ')
        screen.update(a)
        os.system('clear')
        print screen
        print "%4d moves of %4d" % (b, limit)
        if len(screen.childs) == screen.x_size*screen.y_size:
            win = True
            break
    if win:
        print "You Win"
    else:
        print "You loose"

Volando por la Mañana...

noreply@blogger.com (Joac) — Sat, 17 Apr 2010 13:35:00 +0000

Mi vuelo sale a las 7:55, estoy en aeroparque en este momento. La verdad que el año pasado me diverti mucho riendome de mi pobre cuñada que perdió el micro en retiro, pero a mi, esta vez me paso algo mucho peor, pero por suerte sali bien parado (aunque un poco despeinado)...

¡¡¡¡Me quede dormido!!!!!!!!!

Si señor, si señora, a las 5:50 me pasaba a buscar un taxi, que reserve ayer a las 12 de la noche.
Mientras estaba tranquilo, soñando un sueño hiperrealista, breeeeeep, la chicharra del portero tuneado de casa me quito el sueño. En dos segundos, pense que era algun borracho confundido, que venia a buscar a algun amigo y le habia pifiado al departamento.....

Pero no.

Era el taxi.
Así, que en un tris, guarde la laptop, y las cosas que faltaban en la mochila y salí.
Llegué bien (excesivamente temprano, como a mi me gusta) y ahora estoy todo despeinado en el aeropuerto.
De esta experiencia aprendi dos cosas:

- Si vas a salir en un vuelo matutino y vas a ir en taxi, reservalo de antemano en una empresa seria (En mi caso, Radiotaxi Del Plata), ya que esta precaución me salvo el vuelo.
- Dejar seteado mas de un reloj. En mi caso la falla fue que me olvide de eliminar la opcion de que no suene los sábados.
- Por las dudas.... Bañate la noche anterior.... mas vale estar excesivamente limpio que tener que bancarte un dia entero todo mugroso.

Como frutilla de la torta, justo anteayer estaba realizando un plan de reorganización de los metodos de auto-encendido (Lease, "La forma en que uno se despierta"). Me quede hasta las 2 de la mañana armando un crontab (Que no tenia idea de como se usaba) para que a la mañana me despierte arrancando el totem con una playlist. Si lo hubiese seteado para hoy, esto no pasaba....

Ahora estoy embolado en el aeropuerto, jugando con nmap contra la wifi paga... en 1 hora despego :P
--

El amanecer en el Río de la Plata

UPDATE: Estoy sano y salvo en Córdoba

Buenas Nuevas

noreply@blogger.com (Joac) — Wed, 31 Mar 2010 16:50:00 +0000

Hace rato que no posteo algo por acá, pero tengo buenas noticias, y las buenas noticias son para compartirlas.

Cambio de Trabajo!

Un poco de background:
Hace 3 años (y un poco mas) que me viene a estudiar (aunque no solo a estudiar) a Buenos Aires, desde ese momento vengo laburando en la empresa de mi tío. Donde comenzé siendo un tablerista, y termine siendo proyectista eléctrico, programador de PLC, SysAdmin, Tablerista, Encargado de Postventa, Desarrollador de Scadas.... (y la lista sigue). Todo esto, amparado en la confianza de ser familia.

Pero.... siempre hay un pero: No está tan bueno. Ser un empleado multifuncional, con muchas cosas diferentes que abarcar logró que mi estrés y mi panza crezca, que mi capacidad de resolver problemas específicos disminuya y algo muy importante:
La sensación de soledad, de no tener un par con el que discutir como encarar un proyecto, alguien con quien repartir las responsabilidades cuando la cosa no funciona y finalmente, alguien con quien aprender en conjunto.

Ademas.... quería programar, Python de ser posible...

Empecé a mirar un poco la oferta laboral, pero el panorama era mas que deprimente (desde mi punto de vista): Muchas búsquedas de desarrolladores junior, con sueldos malos.
Yo, siendo un (proto)programador autodidacta, no tenia ningún papel, ninguna experiencia laboral en el desarrollo de sistemas, no tenia la cara para presentarme a un laburo mejor.
Mi forma de vida (la autosuficiencia en pareja) y el nivel de gastos (depto, gastos de facultad, alimentos, transporte) me hacia imposible pensar en entrar a una empresa donde me paguen 2,50$ la hora.

Pero las cosas fueron cambiando:

En marzo participe en el pycamp, un campamento en el que programadores de python de argentina, desde newbies como yo, hasta tipos con trayectoria internacional. Fue increíble: muchos geeks, mucha buena onda, mucha humildad.
Aprendí mucho, muchísimo, mas que en mucho tiempo.
Ahí mismo me di cuenta (nuevamente) que estaba cansado de trabajar tan solo y que realmente quería trabajar con gente así y que realmente mi codigo no apestaba (tanto...).

En la reunión de PyAR (en el marco del PyCamp), Alecu planteo que existen un montón de programadores de Python, que no trabajan en Python, y que estaría bueno, revertir esa situación.

De vuelta en casa decidá tirarme a la pileta: Mande un curriculum a GCoop, una cooperativa de desarrollo de software libre, y... me eligieron!!!!, así que, fines de abril, estaré estrenando nuevo trabajo.

La verdad que agradezco a la gente de la comunidad de Python Argentina, que confiaron en mi, como colaborador en los eventos que se organizaron y me ayudaron (sin darse cuenta) a dar este paso.

Recalculando

noreply@blogger.com (Joac) — Thu, 11 Feb 2010 12:52:00 +0000

Haciendole un apt-get dist-upgrade a mi cerebro.

Ultimamente estoy consumiendo demasiada información y produciendo poca. Ni bien logre cambiar la tendencia, escribo algo interesante.

TSXCUSB485 en GNU/Linux!

noreply@blogger.com (Joac) — Wed, 16 Dec 2009 17:51:00 +0000

Arranque esta semana testeando un dispositivo MODBUS, sobre un enlace RS485. Para ello decidi utilizar un lindo conversor usb a RS485, de la firma Schneider Electrics: el TSXCUSB 485.El aparatito en Cuestión

Probe en Win, lo detecto como un puerto com, usando un driver privativo. Probe en GNU/Linux y.... nada... me mostraba el vendor id y el product id del dispositivo pero no me lo montaba como un "ttyUSBx".

Las opciones: resignarse y usarlo bajo windows, o buscar, escribir, parchar lo que fuera necesario.

Obviamente, elejí la opción 2, ya que si lo sacaba funcionando tenia resuelto un punto importante en materia de comunicaciones industriales, rubro al que me dedico.

Empeze leyendo un poco de guias sobre como son los drivers usb en linux, y googleando si alguien lo habia hecho andar, pero, se ve que a los que trabajan de esto usan solo windows.

El primer paso para hacer ingeniería inversa, era ver el hardware que componia la placa:

Detalle de la Plaqueta

Ya, de un golpe de vista nos encontramos con el corazón de la conversión usb-rs232, el ft232bl, un chip bastante estandar.
El lugar mas ovio para encontrar información era la pagina del fabricante, y ¡Oh Sorpresa! estaba el driver para nuestro querido pinguÑu, incluso una guia para agregar vendor y product ids pero:
La edición del driver, para que reconozca el dispositivo, en si, es bastante trivial, pero el problema es compilarlo: hay muchas versiones del driver y muy pocas de ellas son compilables, porque, según entiendo, el soporte de usb del kernel se fue modificando con cada versión.

Finalmente, termine buceando en el git de www.kernel.org y encontré uno que compilo de maravillas.

La verdad que me sorprende cuan poderoso es el software libre: en el sistema de la ventana, ante un problema así ¡estas fregado!
En balance de tiempo tarde unas 3 horas en resolverlo, pero ya esta!!! cuando consiga comittear mi pach para el driver, en futuros kernels, el dispositivo va a tener soporte, ¡para mucha gente!

Mandando el contenido de un directorio como archivos adjuntos

noreply@blogger.com (Joac) — Tue, 01 Dec 2009 20:03:00 +0000

Hoy necesitaba mandar un archivo dividido en 18 partes de 400kB, debido a las limitaciones del proveedor de correo de un colega cubano. La opción de hacerlo a mano es realmente engorrosa, asi que con la ayuda de la documentación de python me mande este script:

import smtplib
import os
from email.mime.text import MIMEText
from email.mime.base import MIMEBase
from email.mime.multipart import MIMEMultipart
from email import encoders
import getpass
directorio = 'Directorio de donde Sacamos los Archivos'
asunto = 'Aca va el asunto'
destinatarios = ['complete aqui con sus destinatarios',]
sender = 'Aca va Nuestra Direccion'
contenido = 'Texto que queremos que se lea en los mensajes'
host = 'servidor SMTP que vamos a usar'
login = 'nuestro usuario'
#creamos el contenedor
listademails = []
numeroParte = 1
listadoArchivos = os.listdir(directorio)
listadoArchivos.sort()
for archivo in listadoArchivos:
    path = os.path.join(directorio, archivo)
    msg = MIMEMultipart()
    msg['Subject'] = asunto + ' %d de %d' % (numeroParte, len(listadoArchivos)))
    numeroParte += 1
    msg['From']= sender
    msg['To']=', '.join(destinatarios)
    #msg.preamble = ''
    texto = MIMEText(contenido, 'plain')
    msg.attach(texto)
    #Adjuntamos el Archivo
    fp = open(path, 'rb')
    adjunto = MIMEBase('application', 'octet-stream')
    adjunto.set_payload(fp.read())
    fp.close()
    encoders.encode_base64(adjunto)
    adjunto.add_header('Content-Disposition', 'attachment', filename = archivo)
    msg.attach(adjunto)
    listademails.append(msg.as_string())

server = smtplib.SMTP(host)
server.login(login, getpass.getpass())
for mail in listademails:
    server.sendmail(sender, destinatarios, mail)
server.quit()

Dejo en el lector las criticas pertinentes a esta 'Belleza'(ironicmode =True) que sorprende por su extrema pythonicidad :P

Segundas Charlas Tecnicas Trimestrales - CafeLug

noreply@blogger.com (Joac) — Sat, 28 Nov 2009 20:54:00 +0000

Hoy me levante temprano, decidí postergar los estudios de química (esto me saldrá caro a futuro) , y me fui al Centro Cultural San Martín, en Sarmiento y Paraná, a las segundas charlas técnicas trimestrales organizadas por Cafelug.

Las charlas estaban divididas en dos grandes grupos: Desarrollo y Administración.
Elejí arrancar con las charlas de administración:

La evolución del shell. Por Nubis G Bruno

Nos presento a la herramienta con la que él esta laburando ahora, llamada RUSH (RUby SHell??). Segun lo que yo entendí, es un shell interactivo de ruby que permite modelizar un host remoto en un objeto de ruby, con métodos ( como todo objeto...bueno, o casi todos) para realizar las tareas necesarias: copiar archivos, buscar usando expresiones regulares, levantar aplicaciones y daemons, y muchas cosas mas.
La aplicación se conecta, usando ssh, a un http server en la máquina remota, desde se ejecutan nativamente los comandos.
Esto permite tener scripts de administración bastante sencillos de comprender, y de escalar, para ejecutar tareas en múltiples hosts. Esto es muy piola para aplicaciones que estén en la nube, donde los hosts suelen ser dedicados y tenés que estar moviéndote de uno a otro todo el tiempo.
Hasta acá todo muy lindo, pero soy un tipo que en este momento no tiene ganas de aprender Ruby, de lo que surge una pregunta básica: ¿existe algo así para Python?. La respuesta es afirmativa y se llama Fabric, pero no es exactamente lo mismo.
Como propuesta a futuro, esta una implementación de objetos Host para python, integrada en IPython (Interesados en organizar un sprint bienvenidos!!).
Balance de la Charla: Muy Buena
Lo Mejor: Nubis la tiene muy clara, y es, en mi opinión todo un code-rockstar!
Lo Malo: La laptop en un momento no quiso saber mas nada con el proyector y nos quedamos sin ver todos los slides y ejemplos.

La siguiente charla fue:

Como Implementar Cloud Computing con Open Source, sobre
Open Solaris.
Por Gabriel Benselum y Pablo Oddera.

En esta charla presentaron un poco a Open Solaris (Instale uno en una VM con VirtualBox mientras daban las charlas) y a todas las herramientas y aplicaciónes que trae para implementar soluciones de cloud computing. Se armo un pequeño debate sobre discos SSD y sus ventajas y estado actual de desarrollo.
Comentaron todas las formas de implementar VM y sus ventajas entre las que destaco: flexibilidad, sea tanto para moverlas y replicarlas "on the fly", ahorro de espacio y ahorro energetico.

La segunda mitad de la charla fue sobre ZFS, el file system que implementa nativamente open solaris, que tiene varias ventajas: Journaling, snapshots, diferentes tipos de raids "Virtualizados" y muchas cosas piolas (Piolas para ambientes en los que no trabajo, con volumenes de datos bastante altos).

Balance de la Charla: Muy Buena.
Lo Bueno: Conoci un poco mas de open solaris y de su comunidad. El Tema de ZFS me parecio muy interesante
Lo Malo: En algunos momentos la charla se fue por las ramas, y terminaron medio ajustados de tiempo.
-------------------------------------------------------
Despues vino el break y me fui a Guerrin ingerir una pizza al paso

Despues del Almuerzo:

Video Streaming en grandes cantidades por Leito Monk

Esta charla fue muy motivadora, y me dejo bastante "caliente" por asi decirlo.
Leito junto con otro chico (averiguar nombre) contaron como resolvieron la infraestructura para proveer streaming de las charlas para wikimania 2009.
Utilizaron aplicaciones libres, contenedores y codecs libres, para proveer de un streaming http.
Fue muy ingeniosa la infraestructura y desmuestra como el software libre permite, gracias a la buena documentacion y el KISS crear cosas muy grossas con componentes sencillos.
Gastaron algo asi como 40u$s para contratar Amazon Elastic Cloud, que se encargo de balancear la carga, 500u$s para las computadoras de cada sala y las horas de los camarografos.

Fue una lastima que la PyCon 2009 fue casi pegada a Wikimania, y no se pudo adoptar lo mismo para nuestras charlas.

Balance de la Charla: exelente
Lo Bueno: Con el software libre se pueden hacer cosas muy buenas!
Lo Malo: Realmente nada

A pedido del publico: la documentación esta en http://trac.usla.org.ar/proyectos/wikimania-video

El Cierre fue con:

Introducción a Selenium (Un enanito que trabaja por vos) por Leito Monk

Esta charla fue del track de desarrollo y fue una somera introduccion a Selenium, una herramienta para crear test funcionales para aplicaciones web usando java script.
Yo no me dedico directamente al rubro web pero estub buena para conocer un poco por si las moscas.
Balance de la Charla: Buena
Lo Bueno: Me di un pantallazo de lo que es el testeo web.
Lo Malo: La VM que corria la app de Leito no levantaba la conexión de red y se perdio un buen rato hasta que la cosa salio andando.
---------------------------------------------
Balance General: Las Charlas estuvieron buenas, esperaba ver mas caras conocidas, pero a esta altura del Año todos estamos un poco hasta las manos :P.
Cada día aprecio mas el esfuerzo de toda la comunidad del SL para que estemos todos mas y mejor informados

Enfriando el Infierno (o Cooler DIY)

noreply@blogger.com (Joac) — Wed, 07 Oct 2009 16:39:00 +0000

En el trabajo tengo una laptop Toshiba L20-SP119, con un Celeron de 1.5GHz, medio viejita, que uso para laburar en plantas, programar plc y correr el Autocad (y alguna que otra aplicación para windows).
Funciona bastante bien, pero tiene un problema:
¡¡Se calienta como el mismísimo infierno!!

Si bien no te quemas al tocarla, es bastante incomodo, sobre todo cuando tengo que tipear.

Así que decidí poner manos a la obra y construir el "Definitive Cooling System"

¡Charaaan!

El monstruo sin la protección mecánica

Materiales Utilizados:

Ventilador de 80mm de una fuente ATX quemada
Caja de Ladrillitos Blocky que me regalaron para navidad de Officenet
Cinta para tapar los agujeros
Un Transformador de 12 voltios de corriente continua (tecnicamente: un transformador con rectificador...)
Un jefe permisivo que nos deje poner tamaña obra de arte en nuestro Box

El Monstruo con la proteción "Anti Dedos Curiosos"

El conjunto en toda su magnitud

Detalle del montaje del Ventilador, y la cinta (en este caso de papel) que tapa los agujeros

Gracias al nuevo ventilador, la máquina redujo su temperatura en un 40% (aproximado se queda corto)