Posts about python

2019-09-16 21:45

Episodio 8: Complejo y Complicado

Un intento (probablemente fallido) de explicar complejidad algorítmica, o por lo menos lo más básico del tema sin complicarla demasiado.

2019-09-03 21:46

Complicame la vida!

Como estoy medio corto de ideas de charlas para la PyconAr de este año, les pido una mano!

Hice un sitio rapidito para que puedan proponerme temas y/o votar temas que proponga otro: Complicale la vida a Ralsina

Prometo dedicarle 4(cuatro) días a intentar aprender/hacer lo que sea que gane, e intentar dar una charla sobre eso.

Si me sale, será una charla sobre la cosa maravillosa que hice.

Si no sale, será una charla sobre la experiencia de querer hacer esa cosa.

Creo que en cualquier caso va a ser divertido.

2019-08-13 20:55

Episodio 5: Muchos Pythons

Una pseudo secuela de "Puede Fallar" mostrando varias cosas:

  • Anvil: una manera de hacer aplicaciones web full-stack con Python!
  • Skulpt

Y mucho más!

La aplicación que muestro en el video: En Anvil

El código: lo podés clonar

Detalle: "lo de twitter" quedó reducido a un botón adentro de la aplicación, pero sirvió como disparador :-)

2019-08-05 21:46

Old Guy @ The Terminal Ep 3: Puede Fallar!

Episodio 3!

Igual que casi nadie publica los estudios con resultados negativos, nadie hace videos en Youtube acerca de como no le sale hacer algo. Bueno, yo sí.

Este episodio es sobre una de las cosas que más me interesan en el desarrollo de software, especialmente para alguien que está aprendiendo (o sea todo el mundo) y más aún para un principiante: el fracaso.

Véanme fracasar durante unos 20 minutos, mientras trato infructuosamente de hacer una cosa que tenía ganas de hacer!

¡Y no pasa nada! Es imposible tener sindrome de impostor si uno no hace como que sabe.

2019-07-26 18:47

Programación, matemática, y el problema de los tomates venenosos.

Malditos Tomates

Mucha gente, cuando no sabe programar, tiene prejuicios. Algunos de los más comunes son:

  • "Para programar hay que ser un bocho."
  • "Para programar hay que saber matemática."

Ambos prejuicios son perjudiciales para ese posible futuro programador por varios motivos. El primero y más obvio es que no son ciertos. Pero no es que no son ciertos en la manera en que "el tomate es una verdura" no es cierto, son falsos de la misma manera que "el tomate es venenoso" es falso.

Eso es lo que lo hace complicado. Porque el tomate ... el tomate es venenoso.

En el siglo 18, uno de los sobrenombres del tomate era "manzana venenosa"1 porque la gente rica solía comer tomates y morir envenenada. Porque comía en platos de peltre, que contiene plomo y el jugo del tomate disolvía el plomo, y comer plomo es malo, gente.

Por otro lado el tomate es venenoso en sí mismo. Es una solanácea, un género de plantas que producen alcaloides. La tomatera produce solanina, un tóxico que provoca diarrea, vómito y dolor abdominal.

O sea, decir "el tomate es venenoso" es técnicamente cierto que es la peor manera de estar equivocado. Lo mismo pasa con decir "para programar hay que saber matemática".

Es técnicamente cierto. Pero no es importante. Igual que es técnicamente cierto que el tomate es venenoso, pero no es importante, y por eso comemos tomate igual.

Me voy a concentrar en el segundo prejuicio, acerca de programar y matemáticas, porque el primero no resiste el mas mínimo contacto con programadores (yo incluído).

¿Por qué es técnicamente cierto?

1. Te enseñan cosas que son "matemática" cuando aprendés a programar

Por ejemplo, te van a hablar de cosas como números binarios, hexadecimales y hasta octales. Y sí, eso es "matemática" y es necesario para ... ¿para qué, exactamente?

Para casi nada. Estas son las cosas que más frecuentemente encuentres programando para las cuales eso es útil:

  1. binarios: para calcular subredes IP
  2. octales: para calcular permisos en sistemas UNIX-like
  3. hexadecimal: interpretar archivos o datos binarios a mano sin escribir los bytes en decimal

Mentira. El uso más frecuente del hexadecimal es buscar palabras que se pueden escribir como números hexa. Aguante DEADBEEF!

Si este año tengo que usar números binarios más allá de saber "un byte cuenta hasta 255" va a ser la segunda vez en la década.

Realmente es una de esas cosas que uno aprende, las guarda en un rincón de la cabeza y después las saca a pasear una vez cada tanto cuando se encuentra con un problema específico, igual que la explicación de la regla del offside o como se organiza un torneo por sistema suizo.

2. Algunas áreas del desarrollo de software tienen realmente una base matemática

Si querés hacer machine learning tenés que saber hacer regresión lineal. tenés que tener idea de cálculo. Te va a venir bien saber montones de cosas más.

De la misma manera si vas a hacer un sistema de liquidación de sueldos te va a ser útil saber sobre legislación laboral.

Si sos un médico y querés saber si la aspirina hace bien vas a tener que saber diseño experimental y estadística.

Si sos un manager de baseball y querés saber si te conviene comprar un bateador con un OPS de .575 pagándole 23 millones de dólares vas a necesitar probabilidad y estadística y contabilidad.

Si querés programar un algoritmo de crypto tenés que parar y no programarlo porque no es buena idea.

Que para una tarea en particular necesites saber algo no hace que sea un prerequisito para el área en general. Nadie sabe hacer todo. Nadie sabe programar todos los tipos de cosas. Eso es simplemente la condición humana.

Yo no sé hacer todo. Y no, no sé hacer machine learning. Y tampoco te puedo hacer un programa de trading. Y si vamos al caso tampoco puedo hacer una simple media tejida porque no sé tejer.

Para saber hacer cosas hay que estudiar, no hay mucho secreto. Entonces, para programar hay que estudiar como se programa, y para programar algunas cosas en particular hay que estudiar otras cosas también.

3. La programación en sí es matemática

Este motivo es más esotérico, pero si, es cierto. La matemática y los matemáticos te van a decir alegremente que el concepto mismo de algoritmo es matemática.

En cuyo caso, obviamente, apenas aprendés a hacer un if ya aprendiste matemática y es imposible expresar un programa sin matemática y pasamos de "técnicamente cierto" a "obvio e inútil". Si todo es matemática entonces el "hay que saber matemática" es una trivialidad. Será que sí, pero ¿cuánta? y ¿cuál?

4. La matemática es útil para hacerte mejor programador

Si aprendés complejidad algorítmica programás mejor.

Si aprendés suficiente "number sense" para saber cuando vale la pena hacer algo programás mejor.

Si aprendés suficiente probabilidad como para saber si algo es un riesgo que vale la pena atacar programás mejor.

Y varias cosas similares.

Éste es tal vez el sentido en el que estoy más dispuesto a decir que "para programar hay que saber matemática" pero tiene el problema de que no es lo que el receptor entiende cuando se lo decís.

Si el objetivo de comunicarse es que se transmita un mensaje (hey, teoría de la información! Más matemática!) es importante no sólo ser correcto en lo que se dice, es importante que lo que uno dice sea entendido de manera correcta por el receptor.

Así que ...

Mi declaración sobre la programación y la matemática a ver si me explico, mire

La matemática es una cosa super amplia, y en la vida nos cruzamos todo el tiempo con ella.

El saber la trayectoria que va a hacer la pelota cuando pateás con comba es matemática. Pero cuando pateás lo hacés sin calcularla porque sabés esa parte de la matemática. No hace falta que la expreses "matemáticamente". no te ponés a calcular el efecto Magnus de acuerdo a la velocidad de rotación de la número cinco y la influencia de los gajos en la aerodinamia.

Programar, en la súper gran mayoría de los casos, se parece mucho más a eso que a lo que te viene a la cabeza cuando te dicen matemática.

Vas a tener que aprender algunas herramientas. Y te las vas a olvidar. ¿Y sabés qué? No hay problema. Las aprendés de vuelta.

Y vas a hacer cosas como mirar un cacho de código y decir ... "ajá, complejidad logarítmica". Y mientras te acuerdes que forma tiene el dibujo comparado con una parábola, hasta ahí llegó lo que te importa en ese momento.

Y a veces vas a tener que meterte hasta las cachas en matemática, y vas a tener que ver como hacer una transformada afín, o como hacer un curve fitting, o un montón de otras cosas. ¡Yo una vez tuve que hacer análisis de regresión para ver como organizar una tabla HTML! ¿Y?

La matemática está por todos lados. Para programar vas a usar matemática. También podés usar matemática para vender chancletas.

No es que sea falso que "para programar hay que saber matemática" es que no es interesante.


  1. De ahora en más se van a imaginar a Blancanieves morfándose un tomate. Sorry. 

2019-07-17 20:33

Old Guy @ The Terminal: Episodio 1!

Este es el primer (y por ahora único, obviamente) episodio de un nuevo canal de video llamado "Old Guy @ The Terminal" en el que muestro algunas cositas de Linux, programación, como se relacionan cosas actuales con cosas viejas y veremos qué más a medida que se me ocurran temas.

Nunca había hecho algo parecido, así que no sean muy duros conmigo ;-)

En este episodio vemos qué es una terminal, como se hace un programa para terminal y una terminal para el programa, porque por qué no.

En algún momento va a haber una versión en inglés (tal vez).

El código: en GitHub

2019-05-16 22:30

Coffee As a Service Architecture

Coffee As A Service Architecture

Intro

Today I was in a meeting with recruiters (yes, really) because they want to be better at technical recruiting and they had the idea that talking to me would help them (oh, sweet summer children).

A nice time was had by all (I hope) and at one point I was asked about what architecture was, and more specifically, about the difference between microservices and a monolith.

Which I tried to explain using what I had at hand: coffee cups, sugar dispensers, a spoon and so on. It didn't quite work out but I kept thinking about it on my way home and ... let's try again.

What is Architecture?

Architecture, when it comes to software, can be defined in many ways, but one way I like is to say that architecture involves:

  • What the components of your system are
  • How they are done
  • How they talk to each other

There is a lot more, but you start with that, and that is more or less enough to explain monoliths and microservices.

The Coffee Service

One thing of massive importance about systems is that they are meant to do something. They exist for a purpose. So, let's suppose the purpose of our system is to make coffee and put it in a cup.

We can call the cup the "coffee client" and whatever we use to make the coffee is the "coffee system" or "coffee service"

So, assuming you have a can full of cofee beans and a cup, how do you make coffee?

The Coffee Monolith

This is my very own coffee machine. Not only is it monolith-shaped, it's functionally monolithic (it's also large enough to deserve its own table, as you can see).

It has two buckets on top. On one you put water, in the other you put coffee beans. Then, you put a cup under the spigot and press a button or two.

It will:

  • Grind the beans
  • Put the ground coffee in the right place and apply the "right" pressure
  • Heat the water to the "right" temperature
  • Run water through the coffee grounds
  • Pour the coffee into the cup
  • Discard the grounds into a hidden deposit

Sounds awesome, right? It is!

It takes all of 30 seconds to go from coffee beans to a nice cup of coffee! It tastes good!

And it's important to keep that in mind. IT IS GREAT.

Monoliths, when they done correctly and you are not expecting anything out of their operating parameters, are awesome.

The problem with monoliths is not that they can't be done right, it's that it's hard to do them right, and that even when you do get it right, in our industry the meaning of "right" is not fixed.

So, because the whole point is to ride this analogy into the ground, let's consider all the things about this awesome machine.

Flexibility

It grounds the coffee. What happens if you want it ground finer? Or coarser?

It turns out that if you have the right tool you can adjust the mill's output (it's not in the manual).

In a microservice-based coffemaker I would replace the grinder.

How about water temperature?

It has three settings. Want anything else? No luck.

In a microservice-based coffee service I would just use an adjustable kettle.

How about the amount of coffee per cup?

It has three settings. Want anything else? No luck.

In microservice-cofee I would just transmit as much coffee as I wanted.

How about changing the bean variety between cups?

The bean hopper takes half a pound of beans. It's not easy to get them out. So, no.

In microservice-coffee heaven I could have multiple hoppers providing beans of all varieties and just connect to the one I want today!

Cup size?

It does two sizes (but you reprogram those sizes)

In microservice-cofee I would just pour as much water as I liked.

A monolith has the flexibility its designers thought of adding, no more, no less. And changing it is ... not trivial.

I could use a vacuum cleaner to remove the beans from the hopper and change varieties. I would consider that a hack. I have also done it. I regret nothing.

Unused Features

It has a thing that lets you setup a credit system for coffee cups I will never use. A milk foamer I use once a week. Why? Because "we may need this and it's hard to add it later, so let's just do it from the beginning" ground coffee.

Sometimes yes, it's useful (capuccino!) but sometimes it's just something I paid for and will never use (coffee credits!)

In a microservice architecture I would just get a new milk foamer, use both for a while and then keep using the one I like.

Hard to Improve

How do I add a better foaming thingie?

By buying one and putting it in the table.

How do I add a more flexible coffee grinder?

I can't because this machine is incompatible with pre-ground coffee. There is a newer, more expensive model that can take that but this one? You need to throw it away.

Modifying a monolithic system is difficult because the pieces are tightly coupled. I can't use a separate grinder because the system requires the coffee grounds to arrive via a specific internal duct at a specific point in the coffee-making cycle, there is just no way to insert my grind-o-matic-3000 in there without a saw and duct tape.

In a modular system I would unplug the grinder and insert a compatible-but-different grinder, in a microservice architecture I would just use whatever grinder and put the coffee grounds in a message and have the next piece in the system pick it from there.

Expensive

This coffee machine is expensive. It's much more expensive than buying a grinder, a coffee machine a kettle and a milk foamer.

What it provides in exchange for the extra money (and reduced flexibility and so on) is performance. I don't boil water, I don't grind coffee, I don't pour, I just press a damned button and enjoy coffee.

Outsourcing

You can buy pre-ground coffee and effectively outsource that part of the process to some external provider.

I can't! I am doomed to ground my own coffee forever.

Maintenance

I have a lubrication schedule, or else my expensive machine will break.

I have to disinfect the coffee ground bin or else it will have maggots.

I have to empty the water waste tray before it overflows.

I have to have a thing to dump the bits of dirty water it uses to clean itself when it turns on/off.

I have to buy special acid to periodically remove scale from its innards or it will stop working. That costs actual money and takes half an hour.

I need to cleanup coffee crud from all the internal springs, levers and thingies every couple of weeks.

Now, you, readers with normal coffee making things? How is your coffee machine maintenance routine? What, you don't have one? Thought so.

Conclusion

So, that's why nowadays most people prefer to pay the performance penalty of a microservice architecture instead of using an awesome monolith.

This is not exhaustive, there is still separation of concerns, encapsulation, rigidity of contracts and a lot more, but it should be convincing enough without being dogmatic :-)

2019-01-06 19:55

Coding in anger: not-gitbook

I have, intermitently, for the past few months, been writing a book. You can see it here and I am fairly happy with how it's going.

I am not so happy with the tooling.

When I started writing it, I didn't want to write a tool, I just wanted to write a book. So, I looked for "things to make a book out of markdown" and found a few, including mdBook and gitbook and tried them both, then decided to go with gitbook because it seemed more developed.

But, you know how this works. Things started drifting.

One initial obstacle was that I wanted the code in the book to come from the actual working code, not be a copy. I also wanted to "execute" the chapters and make the output of the chapter's code part of the chapter itelf.

I found a nice tool for this called pyLiterate which... I ended up extending to allow for things such as "include this piece of code from that file but do not execute it" and whatever, and integrating it into gitbook involved ... a lot of Makefiles.

And then wen the output appeared in gitBook ... I really didn't like how syntax highlighting worked. I wanted prettier and specifically to be able to highlight some lines, and to have line numbers matching the file contents and not starting from 1 ... and I ended up writing a Gitbook Extension

And I added support for graphviz in pyLiterate because I wanted SVG diagrams as part of the code and not as separate things.

And I wrote and I wrote.

And then life happened and I stopped writing. And whenever I wanted to start writing again in a new setup something broke.

  • Maybe the gitbook version installed or its dependencies had a security issue and needed updating.
  • Maybe the updated gitbook broke my plugin
  • Maybe things just were "off" and I had to track it down*

And a couple of days ago, I just got angry. And what the hell this is just a lame static file generator and I know those suckers.

So, I decided to see how much work would it be to reimplement, somewhat dumbly, gitbook.

Well, really, it's about a day's work (for a low quality version)

  • Supports all I want
  • Supports plugins
  • Supports arbitrary markdown preprocessing
  • Supports arbitrary markdown renderer hacking
  • Uses mistune for markdown, which kicks ass
  • Uses jinja2 for templates and they are 10x simpler than in gitbook AND THE OUTPUT LOOK THE SAME. I mean, there is one template

I logged the work, which was at a very relaxed pace over a couple of days here and published not-gitbook in gitlab

I could migrate my book to the new toolchain in a day more work, mostly involving implementing things gitbook doesn't do and I am hacking via Makefiles.

It's surely not ready for any real usage but feel free to poke around and contact me if you want to use it.

Contents © 2000-2018 Roberto Alsina