Una pseudo secuela de "Puede Fallar" mostrando varias cosas:
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 :-)
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.
Mucha gente, cuando no sabe programar, tiene prejuicios. Algunos de los más comunes son:
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?
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:
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.
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.
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?
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 ...
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.
De ahora en más se van a imaginar a Blancanieves morfándose un tomate. Sorry. ↩
Episodio 2! Oh yeah!
Esta es una charla relámpago que dí en la PyCon Argentina de 2018, es cortita y sencilla, ojalá les guste!
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
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.
Architecture, when it comes to software, can be defined in many ways, but one way I like is to say that architecture involves:
There is a lot more, but you start with that, and that is more or less enough to explain monoliths and microservices.
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?
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:
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.
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.
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.
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.
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.
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.
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.
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 :-)
I wrote a git tutorial for those who don't know git where I tried to explain how to use Git for version control on your local machine.
Of course those of you who know about these things already know that half the fun of git is not using it locally, but using a server that can centralize the develpment and allow collaboration.
Well, good news! I just wrote the chapter where I cover that part!
Read and let me know what you think:
I want to learn new languages. But new as in "new to me", not new as in "created last week". So I decided to play with the grandaddy of all cool languages, LISP. Created in 1958, it's even older than I, which is good because it's experienced.
One "problem" with LISP is that there are a million LISPs. You can use Scheme or Common Lisp, or Emacs' Lisp, or a bazillion others. I wanted something simple so it was supposed to be Scheme... but a few days ago I ran into something called Picolisp and it sounded so cool.
A few days ago I saw a mention in twitter about a language called Nim
Se ve interesante ~90% Python-like, compila a Binario o JS, no dependencias ni runtime.https://t.co/JF3vIScWqG
— Juan_Carlos (@juancarlospaco) 27 de abril de 2018
And... why not. I am a bit stale in my programming language variety. I used to be fluent in a dozen, now I do 80% python 10% go, some JS and almost nothing else. Because I learn by doing, I decided to do something. Because I did not want a problem I did not know how to solve to get in the way of the language, I decided to reimplement the example for the python book I am writing: a text layout engine that outputs SVG, based on harfbuzz, freetype2 and other things.
This is a good learning project for me, because a lot of my coding is glueing things together, I hardly ever do things from scratch.
So, I decided to start in somewhat random order.
I read the Nim Tutorial quickly. I ended referring to it and to Nim by example a lot. While trying out a new language one is bound to forget syntax. It happens.
Wrote a few "hello world" 5 line programs to see that the ecosystem was installed correctly. Impression: builds are fast-ish. THey can get actually fast if you start using tcc instead of gcc.
I looked for libraries that were the equivalent of svgwrite, which I am using on the python side. Sadly, such a thing doesn't seem to exist for nim. So, I wrote my own. It's very rudimentary, and surely the nim code is garbage for experienced nim coders, but I ended using the xmltree module of nim's standard library and everything!
import xmltree import strtabs import strformat type Drawing* = tuple[fname: string, document: XmlNode] proc NewDrawing*(fname: string, height:string="100", width:string="100"): Drawing = result = ( fname: fname, document: <>svg() ) var attrs = newStringTable() attrs["baseProfile"] = "full" attrs["version"] = "1.1" attrs["xmlns"] = "http://www.w3.org/2000/svg" attrs["xmlns:ev"] = "http://www.w3.org/2001/xml-events" attrs["xmlns:xlink"] = "http://www.w3.org/1999/xlink" attrs["height"] = height attrs["width"] = width result.document.attrs = attrs proc Add*(d: Drawing, node: XmlNode): void = d.document.add(node) proc Rect*(x: string, y: string, width: string, height: string, fill: string="blue"): XmlNode = result = <>rect( x=x, y=y, width=width, height=height, fill=fill ) proc Text*(text: string, x: string, y: string, font_size: string, font_family: string="Arial"): XmlNode = result = <>text(newText(text)) var attrs = newStringTable() attrs["x"] = x attrs["y"] = y attrs["font-size"] = font_size attrs["font-family"] = font_family result.attrs = attrs proc Save*(d:Drawing): void = writeFile(d.fname,xmlHeader & $(d.document)) when isMainModule: var d = NewDrawing("foo.svg", width=fmt"{width}cm", height=fmt"{height}cm") d.Add(Rect("10cm","10cm","15cm","15cm","white")) d.Add(Text("HOLA","12cm","12cm","2cm")) d.Save()
While writing this I ran into a few issues abd saw a few nice things:
To build a svg tag, you can use <>svg(attr=value) which is delightful syntax. But what happens if the attr is "xmlns:ev"? That is not a valid identifier, so it doesn't work.
So I worked around it by creating a StringTable filling it and setting all attributes at once.
A good thing is the when keyword. usingit as when isMainModule means that code is built and executed when svgwrite.nim is built standalone, and not when used as a module.
Another good thing is the syntax sugar for what in python we would call "object's methods".
Because Add takes a Drawing as first argument, you can just call d.Add() if d is a Drawing. Is simple, it's clear and it's useful and I like it.
One bad thing is that sometimes importing a module will cause weird errors that are hard to guess. For example, this simplified version fails to build:
import xmltree type Drawing* = tuple[fname: string, document: XmlNode] proc NewDrawing*(fname: string, height:string="100", width:string="100"): Drawing = result = ( fname: fname, document: <>svg(width=width, height=height) ) when isMainModule: var d = NewDrawing("foo.svg")
$ nim c svg1.nim Hint: used config file '/etc/nim.cfg' [Conf] Hint: system [Processing] Hint: svg1 [Processing] Hint: xmltree [Processing] Hint: macros [Processing] Hint: strtabs [Processing] Hint: hashes [Processing] Hint: strutils [Processing] Hint: parseutils [Processing] Hint: math [Processing] Hint: algorithm [Processing] Hint: os [Processing] Hint: times [Processing] Hint: posix [Processing] Hint: ospaths [Processing] svg1.nim(9, 19) template/generic instantiation from here lib/nim/core/macros.nim(556, 26) Error: undeclared identifier: 'newStringTable'
WAT? I am not using newStringTable anywhere! The solution is to add import strtabs which
defines it, but there is really no way to guess which imports will trigger this sort of issue.
If it's possible that importing a random module will trigger some weird failure with
something that is not part of the stdlib and I need to figure it out... it can hurt.
In any case: it worked! My first working, useful nim code!
In my python version I was using docopt and this was smooth: there is a nim version of docopt and using it was as easy as:
import docopt in the scriptThe usage is remarkably similar to python:
import docopt when isMainModule: let doc = """Usage: boxes <input> <output> [--page-size=<WxH>] [--separation=<sep>] boxes --version""" let arguments = docopt(doc, version="Boxes 0.13") var (w,h) = (30f, 50f) if arguments["--page-size"]: let sizes = ($arguments["--page-size"]).split("x") w = parse_float(sizes[0]) h = parse_float(sizes[1]) var separation = 0.05 if arguments["--separation"]: separation = parse_float($arguments["--separation"]) var input = $arguments["<input>"] var output = $arguments["<output>"]
Not much to say, other that the code for parsing --page-size is slightly less graceful than I would like because I can't figure out how to split the string and convert to float at once.
So, at that point I sort of have the skeleton of the program done. The missing pieces are calling harfbuzz and freetype2 to figure out text sizes and so on.
One of the main selling points of Nim is that it interfaces with C and C++ in a striaghtforward manner. So, since nobody had wrapped harfbuzz until now, I could try to do it myself!
First I tried to get c2nim working, since it's the recommended way to do it. Sadly, the version of nim that ships in Arch is not able to build c2nim via nimble, and I ended having to manually build nim-git and c2nim-git ... which took quite a while to get right.
And then c2nim just failed.
So then I tried to do it manually. It started well!
To link libraries you just use pragmas: {.link: "/usr/lib/libharfbuzz.so".}
To declare types which are equivalent to void * just use distinct pointer
To declare a function just do some gymanstics:
proc create*(): Buffer {.header: "harfbuzz/hb.h", importc: "hb_buffer_$1" .}
Creates a nim function called create (the * means it's "exported")
It is a wrapper around hb_buffer_create (see the syntax there? That is nice!)
Says it's declared in C in "harfbuzz/hb.h"
It returns a Buffer which is declared thus:
type Buffer* = distinct pointer
Here is all I could do trying to wrap what I needed:
{.link: "/usr/lib/libharfbuzz.so".} {.pragma: ftimport, cdecl, importc, dynlib: "/usr/lib/libfreetype.so.6".} type Buffer* = distinct pointer Face* = distinct pointer Font* = distinct pointer FT_Library* = distinct pointer FT_Face* = distinct pointer FT_Error* = cint proc create*(): Buffer {.header: "harfbuzz/hb.h", importc: "hb_buffer_$1" .} proc add_utf8*(buffer: Buffer, text: cstring, textLength:int, item_offset:int, itemLength:int) {.importc: "hb_buffer_$1", nodecl.} proc guess_segment_properties*( buffer: Buffer): void {.header: "harfbuzz/hb.h", importc: "hb_buffer_$1" .} proc create_referenced(face: FT_Face): Font {.header: "harfbuzz/hb.h", importc: "hb_ft_font_$1" .} proc shape(font: Font, buf: Buffer, features: pointer, num_features: int): void {.header: "harfbuzz/hb.h", importc: "hb_$1" .} proc FT_Init_FreeType*(library: var FT_Library): FT_Error {.ft_import.} proc FT_Done_FreeType*(library: FT_Library): FT_Error {.ft_import.} proc FT_New_Face*(library: FT_Library, path: cstring, face_index: clong, face: var FT_Face): FT_Error {.ft_import.} proc FT_Set_Char_Size(face: FT_Face, width: float, height: float, h_res: int, v_res: int): FT_Error {.ft_import.} var buf: Buffer = create() buf.add_utf8("Hello", -1, 0, -1) buf.guess_segment_properties() var library: FT_Library assert(0 == FT_Init_FreeType(library)) var face: FT_Face assert(0 == FT_New_Face(library,"/usr/share/fonts/ttf-linux-libertine/LinLibertine_R.otf", 0, face)) assert(0 == face.FT_Set_Char_Size(1, 1, 64, 64)) var font = face.create_referenced() font.shape(buf, nil, 0)
Sadly, this segfaults and I have no idea how to debug it. It's probably close to right? Maybe some nim coder can figure it out and help me?
In any case, conclusion time!
I will keep it in mind if I need to write fast code with limited dependencies on external libraries.
As part of a book project aimed at almost-beginning programmers I have written what may as well pass as the first part of a Git tutorial. It's totally standalone, so it may be interesting outside the context of the book.
It's aimed at people who, of course, don't know Git and could use it as a local version control system. In the next chapter (being written) I cover things like remotes and push/pull.
So, if you want to read it: Git tutorial for people who don't know git (part I)
PS: If the diagrams are all black and white, reload the page. Yes, it's a JS issue. Yes, I know how to fix it.