jueves, 21 de abril de 2011

Escribir codigo que, simplemente funcione

No hay mucho para explicar o agregar: 
 
> can you try following change ? it will push gart to 0x80000000
>
> diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
> index 86d1ad4..3b6a9d5 100644
> --- a/arch/x86/kernel/aperture_64.c
> +++ b/arch/x86/kernel/aperture_64.c
> @@ -83,7 +83,7 @@ static u32 __init allocate_aperture(void)
>         * so don't use 512M below as gart iommu, leave the space for kernel
>         * code for safe
>         */
> -       addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
> +       addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21);

What are all the magic numbers, and why would 0x80000000 be special?

Why don't we write code that just works?

Or absent a "just works" set of patches, why don't we revert to code
that has years of testing?

This kind of "I broke things, so now I will jiggle things randomly
until they unbreak" is not acceptable.

Either explain why that fixes a real BUG (and why the magic constants
need to be what they are), or just revert the patch that caused the
problem, and go back to the allocation patters that have years of
experience.

Guys, we've had this discussion before, in PCI allocation. We don't do
this. We tried switching the PCI region allocations to top-down, and
IT WAS A FAILURE. We reverted it to what we had years of testing with.

Don't just make random changes. There really are only two acceptable
models of development: "think and analyze" or "years and years of
testing on thousands of machines". Those two really do work.

                   Linus

miércoles, 23 de marzo de 2011

Intención del código (o, me descargo un poco)

Este post, probablemente, parezca una pelotudez. Probablemente alguien diga "esto es obvio"o "no me digas", pero, es que lo he visto tantas veces, me he topado con esto tanto, que empiezo a creer que no es tan obvio.


Me ha tocado leer/mantener código que no fue escrito por mi. Es decir, meterme a tocar, mejorar, fixear, código ajeno en vez de escribirlo desde cero. En esos casos, me he topado con cosas como esta (*):

Function Foobar(n){
    n = n * 3
    return n
}


El tema es el siguiente, dada una función escrita en algún lenguaje de programación, puedo saber si está bien?

Esa función, es correcta o no es correcta?? Digamos, desde el punto de vista de la sintaxis (suponiendo que eso es la sintaxis de algún lenguaje) puede no fallar. Pero, está bien? Cómo se que intención tenía? Qué se supone que hace? O que esperar? Por qué nos cuesta tanto documentar eso en comentarios?

En casos peores, he visto cosas como:

Function Foobar(n){ //Devuelve n multiplicado por 3
    n = n * 3
    return n
}


Donde, no solo sigo teniendo el problema de no saber si está bien o no, sino que, además, me dice algo que es obvio.

Entonces, queridos amigos programadores, cuando comentemos procuremos poner la intención de ese cacho de código. NO quiero que me digan lo que puedo ver leyendo el código, sino, justamente, lo que se les pasó por la cabecita cuando lo escribieron. Por qué? Porque es mucho más sencillo arreglarla (si fuera necesario) sabiendo que se supone que hace, que tener que deducirlo teniendo en cuenta quien la llama, por ejemplo. Además, si la función estuviera mal, es más complejo deducir que en realidad, quisieron poner, no se, n = n + 3, por decir algo, aumentando mis posibilidades de romper algo que estaba bien, pero que parecía mal.

Gracias

(*) Aclaración para los despistados, esa función es solo ilustrativa, no es un caso real =)

jueves, 10 de marzo de 2011

Magia Negra: Un ActiveRecord en pytnon

Pensando en un proyecto cuasi muerto que tengo, me vino a la mente que, aprovechando el código ya escrito y con muy poco esfuerzo/código más, puedo armar un framework que implemente ActiveRecord


Y acá está (solo está creado el espacio y subido un commit inicial) pero promete.
El nombre, inspirado en el efecto mágico y, un tributo a las viejas bandas del metal quizá?

Status: Muerto por falta de interés.

lunes, 31 de enero de 2011

Quick Hack

Tenia que resolver lo siguiente:

Una macbook que baja mails desde un servidor propio (con un Kerio en la empresa)

Un router que no soporta loopback

Entonces, cuando la mac esta fuera de la empresa, se podia hacer referencia, en el cliente de mail, al DNS, que llamaremos empresa.dyndns.ws (para no revelar datos reales)
Pero, dentro de la empresa, el DNS empresa.dyndns.ws, simplemente no funciona.
Habia que resolverlo, y rapido[0].

Python al rescate!
Colorized Source Code


He aquí el script (es feo, muy feo, pero salio rapidisimo y con fritas!)

import os
from subprocess import Popen, PIPE, STDOUT
esta = False
p = Popen(['ping','-c','1','server'], stdout = PIPE)
output = p.stdout.read()
p.wait()

if 'bytes from' in output:
    ok = True
else:
    ok = False

f = open('/etc/hosts', 'r')
f2 = open('/etc/hosts2', 'w')

for i in f:
    if 'empresa.dyndns' in i:
        esta = True
        if ok:
            f2.write(i)   
    else:
        f2.write(i)      

if not esta and ok:
    f2.write('192.168.0.1    empresa.dyndns.ws \n')	


f.close()
f2.close()

os.remove('/etc/hosts')
os.rename('/etc/hosts2','/etc/hosts')

Basicamente, hace un ping al nombre del servidor donde esta el servidor de mail (el Kerio) con el nombre local, 'server'. Si esta, estoy en le empresa, sino, no.
Entonces, basado en eso, toco el archivo hots (gracias Apple por hacer su OS un UNIX) y listo[1]. Se agrego al inicio y se corre con permisos de root y logramos lo que esta persona queria, una solucion rapida y magica.

No estoy orgulloso del script en si, sino, del poder de python para hacer estos quick hacks, que te salvan la papas. =)


[0] Dicen que rapido y bien, es imposible.
[1] Pero, como decia TuSam, puede fallar. Por ejemplo, si justo hay otro 'server', donde esta esta persona (shit happens)

lunes, 17 de enero de 2011

Status: RESOLVED FIXED

Mi primer bug en mozilla! (si, es trivial pero, me pone contento igual!)

https://bugzilla.mozilla.org/show_bug.cgi?id=606824
http://hg.mozilla.org/mozilla-central/rev/a5092e4ae324

Solo puedo agregar lo siguiente:

=)

lunes, 6 de diciembre de 2010

Simplemente Firefox...

Por este tipo de cosas (y por muchisimas otras) es que me gusta firefox.

No hay mucho más que comentar, hay que ver el link =)

sábado, 6 de noviembre de 2010

Programar: Ensuciarse hace bien

A quienes hayan podido ver en "la caja boba" la publicidad de una conocida marca de productos para lavar la ropa, les sonará esta frase con la que titulo esta entrada:

"Ensuciarse hace bien"

Lo que quizá no se entienda es por qué la adopto, o qué puede tener que ver con la programación.

La historia

Brevemente, y para no aburrir a quienes ya conocen el aviso, trata de unos niños jugando, ensuciandose y de cómo eso es beneficioso para estos chiquitos. Obviamente, el ensuciarse beneficia a la marca, pero ese es un tema aparte. Lo que me interesa es el concepto:

jugar + ensuciarse + cansarse + ensuciarse de nuevo = beneficio

Esto es muy cierto y, creo que se aplica a la programación. No es que me haya dado cuenta de golpe, pero, algo que experimenté hace unas horas, hizo que me inspire y escriba esta entrada.

Estaba (y estoy) escribiendo una mini-nano-IDE en python+pyqt4. Lo que hace es levantar una ventanita gráfica muy simple con un editor de texto con highlighter de sintaxis de python y, lo más interesante, quería que tuviera un debugger.

Entonces, me puse a leer. ¿Cómo demonios hago un debugger? Obviamente, nunca pensé escribirlo desde cero, no es la idea reinventar la rueda (más allá de que sería interesante) por lo que, caí en lo más básico que se me ocurrió, Pdb.

Y acá empieza todo el tema del juego: comencé a jugar con la clase, probé como funcionaba (hacía mucho que no la usaba y no recordaba los comandos) y estuve así un rato. Después, leí un poco de la documentación como para ser un poco más prolijo.

Luego, empecé a escribir códigos de prueba, donde heredé la clase, y seguí jugando un poco más.

Luego, usando mi editor de texto favorito (¿cuál será?) abrí el módulo pdb.py, y me lo puse a mirar. Ahi noté que, la clase Pdb heredaba otras dos clases: cmd y, la más interesante, Bdb que, no era otra cosa que un framework para implementar debuggers!! Así que abrí también el módulo bdb.py y me puse a leerlo, junto con un poco de la documentación.

Pero, estaba avanzando lento, quería realmente zambullirme de lleno, quería experimentar con el código un poco más, involucrarma más, en fin, quería ensuciarme.

Así que: ¿que hice? Cómo tampoco la idea es romper (sobre todo, bibliotecas estandard) me copié el módulo como pdd.py a la carpeta de mis scripts y, ahi, con una copia del pdb.py original, me arremangué y metí los dos brazos de lleno en el barro y la mugre.
Y me puse a chapotear: Agregué prints con estados (que forma moderna de debuggear, ¿no?) cambié cosas, saqué otras cosas más, agregué atributos y métodos nuevos a la clase, sobreescribí algunos métodos originales, en fin, toqué el código como si fuese mío y, en cierto sentido, lo hice mío, me sumergí y salí, tiempo después, escupiendo código python (es sólo una metáfora) y, lo más importante, terminé de definir cómo voy a hacer el debugger usando, la clase original pdb (y no su versión diezmada por mí)

Moraleja

Y, luego de todo esto, ¿cuál es la moraleja?
La moraleja es que, cuando uno quiere entender algo que, como en este caso, es código ajeno y es un tema nuevo para uno, no alcanza con leer el código y la documentación.
Uno tiene que, apropiarse del código, meterle mano, cambiarle cosas, ensuciarse de él. Haciendo esto, uno logra entender de forma más profunda, e incluso, más rápida, el código ajeno.

Así que, la próxima vez que quieran entender código ajeno, ya se una biblioteca estandar, una biblioteca de terceros o, simplemente, el módulo que escribió tu compañero de trabajo, no tengas miedo de mirar el código, ejecutarlo, tocarlo (haciendo una copia, claro) porque, como dije al principio:

"Ensuciarse hace bien"