Mostrando entradas con la etiqueta reflexiones. Mostrar todas las entradas
Mostrando entradas con la etiqueta reflexiones. Mostrar todas las entradas
lunes, 16 de julio de 2012
Inventando...
Cierto post de ralsina me hizo acordar a un video que vi hace un tiempo y que me pareció muy, muy bueno.
Espero que les guste!!
Bret Victor - Inventing on Principle from CUSEC on Vimeo.
Link a Vimeo
domingo, 15 de enero de 2012
martes, 11 de octubre de 2011
It Sucks! (parte 2)
Ejemplo: WebService SOAP doloroso:
Producto: MSCRM 2011
Accion: Login con Live + retrieve de una cuentaEs necesario? Realmente tiene que ser tan mugroso?
Para mí, es un Epic Fail.
viernes, 7 de octubre de 2011
IPnaf IDE - La IDE definitiva para python
Dentro del titulo mentiroso, que usé para atraer la atención (el plan B era poner "cerveza gratis!") encierro un pensamiento mío, pero que creo que muchos compartimos. Pero, primero lo primero:
IPnaf IDE quiere decir: IPnaf Please Not Another Fucking IDE!!
Aunque, debería ser "not another fucking python IDE!" Y a qué me refiero con esta misteriosa frase?? He visto, y ultimamente mucho mas, una proliferacion de lo que hacen llamar IDEs. Pero, me voy a centrar en IDEs para el lenguaje pythyon: cito, spyder, Ninja, entre otros, que aparecieron como "somos la IDE definitiva".
Hay un chiste de Xkcd donde, la idea más o menos es que, alguien dice "uh, hay n maneras de hacer x! No puede ser, hay que generar un standard. Horas luego hay n+1 maneras de hacer x"
Y es así. Siempre. Siempre?? Bueno, no siempre, pero en el 99.9% de los casos. Otras veces, ese pensamiento da lugar a innovaciones. Pero, es lo común?? Diríamos que no.
Vuelvo a los ejemplos que cité: Spyder y Ninja. Ambas las bajé, instalé y probé. Aclaro que no tengo nada en contra de quienes la desarrollan (ni los conozco) ni me parece que su trabajo y esfuerzo sea malo. Al contrario. Pero, veo que está desperdiciado. Gente con talento claro, pone esfuerzo en cosas que ya existen y, sin innovaciones reales. A qué me refiero??
Spyder y Ninja [0] son, sin duda esfuerzos de desarrollo y diseño. Pero, que son? Editores de texto lindos y python friendly. Nada más. Ah, y que ejecutan código. Nada que no puede hacer con Emacs y un poco de tiempo + macros.
Debugger? No, gracias. [1]
Ojo, no es que sea fácil hacer un debugger como la gente, que corrar el código paso a paso y podamos inspeccionar varibles, ejecutar código en el contexto de ejecución, editar código on the fly, hacer remote debugging etc. [2]
Pero, es lo que falta!! (en general) Y si, es más lindo ponerse a escribir la IDE desde cero [3], y luego agregarle esas funcionalidades superstar, pero, primero hay que hacer el editor, el highlighter, el buscador de código, el generador de plugins, el pseudo intellisense, etc. Y, para cuando llegamos a las funcionalidades breakers, rockstar, "la papa", quizá el proyecto ya murió.
"No necesitamos esos features de maricones". Diría el macho programmer. (y esto me hizo acordar a otro chiste de Xkcd) pero, la realidad es que, cuando más cómodo esté uno, mejor trabaja y más se puede concentrar en el problema puntual que esté resolviendo.
Por qué no tomar una IDE existente y opensource y mejorarla en vez de arrancer una from scratch?
Entonces, si se van a poner a programar, aviso, no necesitamos más IDEs =)
EOF
[0] Elegí Spyder y Ninja porque son 2 que recuerdo haber visto últimamente, y que además las instalé y probé.
[1] Creo que Spyder estaba implementando pdb y winpdb. De todos modos, mi punto sigue en pie.
[2] Acá es cuando alguien me va a decir, "vos, porque estás acosbumbrado a visual basic" Puedo asegurar que he programado en editores de texto plano como en Visual Studio, Eclipse o Netbeans. Uno puede usar un debugger o usar prints, pero, las funcionalidades rock star en las IDEs, son geniales!! No es que uno no pueda vivir sin ellas, pero, si existen, mucho mejor!!
[3] Es como el caso de las n distribuciones de Linux. Ya hay suficientes en variedad como para parar un poco, si tenés tantas ganas de laburar en una distro, contribuí con una que exista!!!
IPnaf IDE quiere decir: IPnaf Please Not Another Fucking IDE!!
Aunque, debería ser "not another fucking python IDE!" Y a qué me refiero con esta misteriosa frase?? He visto, y ultimamente mucho mas, una proliferacion de lo que hacen llamar IDEs. Pero, me voy a centrar en IDEs para el lenguaje pythyon: cito, spyder, Ninja, entre otros, que aparecieron como "somos la IDE definitiva".
Hay un chiste de Xkcd donde, la idea más o menos es que, alguien dice "uh, hay n maneras de hacer x! No puede ser, hay que generar un standard. Horas luego hay n+1 maneras de hacer x"
Y es así. Siempre. Siempre?? Bueno, no siempre, pero en el 99.9% de los casos. Otras veces, ese pensamiento da lugar a innovaciones. Pero, es lo común?? Diríamos que no.
Vuelvo a los ejemplos que cité: Spyder y Ninja. Ambas las bajé, instalé y probé. Aclaro que no tengo nada en contra de quienes la desarrollan (ni los conozco) ni me parece que su trabajo y esfuerzo sea malo. Al contrario. Pero, veo que está desperdiciado. Gente con talento claro, pone esfuerzo en cosas que ya existen y, sin innovaciones reales. A qué me refiero??
Spyder y Ninja [0] son, sin duda esfuerzos de desarrollo y diseño. Pero, que son? Editores de texto lindos y python friendly. Nada más. Ah, y que ejecutan código. Nada que no puede hacer con Emacs y un poco de tiempo + macros.
Debugger? No, gracias. [1]
Ojo, no es que sea fácil hacer un debugger como la gente, que corrar el código paso a paso y podamos inspeccionar varibles, ejecutar código en el contexto de ejecución, editar código on the fly, hacer remote debugging etc. [2]
Pero, es lo que falta!! (en general) Y si, es más lindo ponerse a escribir la IDE desde cero [3], y luego agregarle esas funcionalidades superstar, pero, primero hay que hacer el editor, el highlighter, el buscador de código, el generador de plugins, el pseudo intellisense, etc. Y, para cuando llegamos a las funcionalidades breakers, rockstar, "la papa", quizá el proyecto ya murió.
"No necesitamos esos features de maricones". Diría el macho programmer. (y esto me hizo acordar a otro chiste de Xkcd) pero, la realidad es que, cuando más cómodo esté uno, mejor trabaja y más se puede concentrar en el problema puntual que esté resolviendo.
Por qué no tomar una IDE existente y opensource y mejorarla en vez de arrancer una from scratch?
Entonces, si se van a poner a programar, aviso, no necesitamos más IDEs =)
EOF
[0] Elegí Spyder y Ninja porque son 2 que recuerdo haber visto últimamente, y que además las instalé y probé.
[1] Creo que Spyder estaba implementando pdb y winpdb. De todos modos, mi punto sigue en pie.
[2] Acá es cuando alguien me va a decir, "vos, porque estás acosbumbrado a visual basic" Puedo asegurar que he programado en editores de texto plano como en Visual Studio, Eclipse o Netbeans. Uno puede usar un debugger o usar prints, pero, las funcionalidades rock star en las IDEs, son geniales!! No es que uno no pueda vivir sin ellas, pero, si existen, mucho mejor!!
[3] Es como el caso de las n distribuciones de Linux. Ya hay suficientes en variedad como para parar un poco, si tenés tantas ganas de laburar en una distro, contribuí con una que exista!!!
jueves, 6 de octubre de 2011
It Sucks!
Ultimamente he tenido que interactuar con varios productos de una empresa "muy conocida" (que tienen, entre otros productos un CRM y un ERP) y, me he topado con un viejo amigo: los webservices.
Y, claro, no es que no los conociera pero, hacía mucho que no me topaba y, ya había olvidado lo feo que son, lo lentos, lo roto que está el modelo en general (SOAP, REST o POX, da igual)
O lidias con librerias horrendas, o parseas xmls.
Y me pregunto: Por qué? No deberíamos (los informáticos) facilitar el acceso a los datos?? No debería ser todo, cada vez más fácil y lindo?
OData, ya es algo, pero, como todo, hasta que sea realmente un standard, vamos a seguir sufriendo con, mixturas de tecnologias (y tampoco se si es la solución al problema)
En fin, mi opinón es que, en lo que es acceso a datos abierto y fácil para todos, We Suck!
Lecturas relacionadas:
SOAP
REST SOAP POX
Y, claro, no es que no los conociera pero, hacía mucho que no me topaba y, ya había olvidado lo feo que son, lo lentos, lo roto que está el modelo en general (SOAP, REST o POX, da igual)
O lidias con librerias horrendas, o parseas xmls.
Y me pregunto: Por qué? No deberíamos (los informáticos) facilitar el acceso a los datos?? No debería ser todo, cada vez más fácil y lindo?
OData, ya es algo, pero, como todo, hasta que sea realmente un standard, vamos a seguir sufriendo con, mixturas de tecnologias (y tampoco se si es la solución al problema)
En fin, mi opinón es que, en lo que es acceso a datos abierto y fácil para todos, We Suck!
Lecturas relacionadas:
SOAP
REST SOAP POX
lunes, 1 de agosto de 2011
La frase del día...
"Google+ isn’t about sharing cat pictures, it’s about serving ads. Twitter’s massive network of 140-character bits of information isn’t about connecting people across the globe or to view current trends in worldwide thinking, it’s about serving ads. Facebook isn’t about entertaining yourself with games or sharing interesting links, it’s about serving ads."
No es que no lo sepamos, pero...
Fuente.
Info relacionada.
No es que no lo sepamos, pero...
Fuente.
Info relacionada.
miércoles, 27 de julio de 2011
Otra idea loca: MyGoogle
Lamentablemente, esto no puedo, ni siquiera soñar con llevarlo a la práctica (ni siquiera sé si lo puede hacer google) y, aunque la idea es simple, su implementación no lo es tanto.
Google, como buscador es un servicio, personalizado (hasta cierto punto) pero... Qué pasa si yo quiero mi buscador? Y no me refiero un buscador de mis archivitos en mi pc, no.
Yo quiero mi google.
Quiero decirle a mi "googlito" que indexe, por ejemplo, datos sobre fútbol, porque quiero una base de datos del tema, o que indexe info sobre la bolsa, porque soy un corredor de bolsa y quiero datos estadísticos.
Es decir, quiero que mi "googlito" me genere una base de datos, que yo pueda consultar (como hoy se consulta el google normal) pero, "saborizada" con mi forma particular de indexar.
Así, tendría una cuenta de google index (como hoy tengo de Gmail, por ejemplo) donde customizo "mi google", diciendole (de alguna forma) como quiero que indexe, con qué criterios, qué relaciones, etc, etc.
Así mismo, puedo publicar esos "googles" customizados para que los usen otras personas.
De esta forma, no sé, Bonadeo capaz tiene su google (como hoy tenés tu twitter) donde, vas a www.google.com/#bonadeo y buscás data sobre, que se yo, tennis de forma más personalizada y enfocada en el tema tennis, y no tan general como hoy buscaríamos sobre tennis en el google normal.
Es medio porrera la idea, pero, ojalá papa noel me traiga algo así para navidad.
Google, como buscador es un servicio, personalizado (hasta cierto punto) pero... Qué pasa si yo quiero mi buscador? Y no me refiero un buscador de mis archivitos en mi pc, no.
Yo quiero mi google.
Quiero decirle a mi "googlito" que indexe, por ejemplo, datos sobre fútbol, porque quiero una base de datos del tema, o que indexe info sobre la bolsa, porque soy un corredor de bolsa y quiero datos estadísticos.
Es decir, quiero que mi "googlito" me genere una base de datos, que yo pueda consultar (como hoy se consulta el google normal) pero, "saborizada" con mi forma particular de indexar.
Así, tendría una cuenta de google index (como hoy tengo de Gmail, por ejemplo) donde customizo "mi google", diciendole (de alguna forma) como quiero que indexe, con qué criterios, qué relaciones, etc, etc.
Así mismo, puedo publicar esos "googles" customizados para que los usen otras personas.
De esta forma, no sé, Bonadeo capaz tiene su google (como hoy tenés tu twitter) donde, vas a www.google.com/#bonadeo y buscás data sobre, que se yo, tennis de forma más personalizada y enfocada en el tema tennis, y no tan general como hoy buscaríamos sobre tennis en el google normal.
Es medio porrera la idea, pero, ojalá papa noel me traiga algo así para navidad.
jueves, 16 de junio de 2011
Advide from an old programmer
Advice From An Old Programmer
You have finished this book and have decided to continue with programming. Maybe it will be a career for you, or maybe it will be a hobby. You will need some advice to make sure you continue on the right path, and get the most enjoyment out of your newly chosen hobby.I have been programming for a very long time. So long that it is incredibly boring to me. At the time that I wrote this book I knew about 20 programming languages and could learn new ones in about a day to a week depending on how weird they were. Eventually though this just became boring and couldn't hold my interest.
What I discovered after this journey of learning is that the languages did not matter, it's what you do with them. Actually, I always knew that, but I'd get distracted by the languages and forget it periodically. Now I never forget it, and neither should you.
Which programming language you learn and use does not matter. Do not get sucked into the religion surrounding programing languages as that will only blind you to their true purpose of being your tool for doing interesting things.
Programming as an intellectual activity is the only art form that allows you to create interactive art. You can create projects that other people can play with, and you can talk to them indirectly. No other art form is quite this interactive. Movies flow to the audience in one direction. Paintings do not move. Code goes both ways.
Programming as a profession is only moderately interesting. It can be a good job, but if you want to make about the same money and be happier, you could actually just go run a fast food joint. You are much better off using code as your secret weapon in another profession.
People who can code in the world of technology companies are a dime a dozen and get no respect. People who can code in biology, medicine, government, sociology, physics, history, and mathematics are respected and can do amazing things to advance those disciplines.
Of course, all of this advice is pointless. If you liked learning to write software with this book, you should try to use it to improve your life any way you can. Go out and explore this weird wonderful new intellectual pursuit that barely anyone in the last 50 years has been able to explore. Might as well enjoy it while you can.
Finally, I will say that learning to create software changes you and makes you different. Not better or worse, just different. You may find that people treat you harshly because you can create software, maybe using words like "nerd". Maybe you will find that because you can dissect their logic that they hate arguing with you. You may even find that simply knowing how a computer works makes you annoying and weird to them.
To this I have one just piece of advice: they can go to hell. The world needs more weird people who know how things work and who love to figure it all out. When they treat you like this, just remember that this is your journey, not theirs. Being different is not a crime, and people who tell you it is are just jealous that you have picked up a skill they never in their wildest dreams could acquire.
You can code. They cannot. That is pretty damn cool.
Fuente
miércoles, 1 de junio de 2011
El programador pesimista
Esto es algo que, si bien suena obvio, parece que no lo es porque, una y otra vez me encuentro con gente del "ambiente" que parece ignorarlo o, por lo menos, lo pasa por alto.
Todo el mundo Muchos programamos como si el mundo fuera de colores y los duendes con sombreros divertidos bailaran a nuestro alrededor.
Es decir, como si todo fuera a salir bien.
Y es por programar de esta forma, optimista que, uno se sobresalta y se rompe la cabeza cuando algo sale mal[0].
El programador pesimista
Lo que propongo (o más bien, resalto porque estoy seguro de que esto no se me ocurrió a mi) es, programemos como si todo fuera a fallar.
Si lo que estoy escribiendo se rompe, cómo evito datos incongruentes? como le doy la posibilidad al usuario de arreglarlo él mismo? o cancelarlo? o volver a hacerlo?
Cómo escribo el código/comentarios de manera que, si falla o se rompe pueda arreglarlo fácil sin tener que volver a pensar todo de nuevo?
Cómo escribo ese mismo código para que, si hay un problema y lo tiene que arreglar un compañero (porque yo no estoy) lo pueda hacer sin problemas y entienda todo como si fuera yo?
Es decir, pensar en el peor escenario posible y, anticiparse con medias preventivas que, en el momento son hasta triviales, pero nos pueden ahorrar horas.
Posibles programadores pesimistas:
Es decir, como si todo fuera a salir bien.
Y es por programar de esta forma, optimista que, uno se sobresalta y se rompe la cabeza cuando algo sale mal[0].
posible duendes divertidos
es sarcasmo Marge
El programador pesimista
Lo que propongo (o más bien, resalto porque estoy seguro de que esto no se me ocurrió a mi) es, programemos como si todo fuera a fallar.
Si lo que estoy escribiendo se rompe, cómo evito datos incongruentes? como le doy la posibilidad al usuario de arreglarlo él mismo? o cancelarlo? o volver a hacerlo?
Cómo escribo el código/comentarios de manera que, si falla o se rompe pueda arreglarlo fácil sin tener que volver a pensar todo de nuevo?
Cómo escribo ese mismo código para que, si hay un problema y lo tiene que arreglar un compañero (porque yo no estoy) lo pueda hacer sin problemas y entienda todo como si fuera yo?
Es decir, pensar en el peor escenario posible y, anticiparse con medias preventivas que, en el momento son hasta triviales, pero nos pueden ahorrar horas.
Posibles programadores pesimistas:
lunes, 30 de mayo de 2011
Todo Inventado, o...
Un poco para paliar el famoso burnout de, nosotros, los programadores, me decidí a ponerme a programar algo que me guste, en un lenguaje que no use para el trabajo (python, probablemente) y, de paso, si es útil, mejor!
Pero, o bien estoy escaso de ideas o bien, todo está inventado pero, cada cosa que se me """ocurre""" ya existe.
Dos ejemplos:
1) Un buscador de imagenes inverso. Esto es, en vez de poner una palabra y que tire imagenes, poder subir una imagen y que te tire que palabras tiene asociadas.
Ya existe.
2) Un visitador de páginas. Esto es, un servicio que, entre a una web y que, cuando hay cambios en la misma (según keywords) me genere un mail, feed o postee en algun lado o, whatever.
Ya hay algo parecido.
Otro.
Estos son 2 ejemplos cercanos, me viene pasando hace mucho. Será que estoy viejo y falto de creatividad?? O será que, realmente, la frase poco feliz "ya está todo inventado" es cierta?
Acepto donadores de ideas.
Nota: Probablemente exista un post así, en otro blog. :)
Pero, o bien estoy escaso de ideas o bien, todo está inventado pero, cada cosa que se me """ocurre""" ya existe.
Dos ejemplos:
1) Un buscador de imagenes inverso. Esto es, en vez de poner una palabra y que tire imagenes, poder subir una imagen y que te tire que palabras tiene asociadas.
Ya existe.
2) Un visitador de páginas. Esto es, un servicio que, entre a una web y que, cuando hay cambios en la misma (según keywords) me genere un mail, feed o postee en algun lado o, whatever.
Ya hay algo parecido.
Otro.
Estos son 2 ejemplos cercanos, me viene pasando hace mucho. Será que estoy viejo y falto de creatividad?? O será que, realmente, la frase poco feliz "ya está todo inventado" es cierta?
Acepto donadores de ideas.
Nota: Probablemente exista un post así, en otro blog. :)
sábado, 21 de mayo de 2011
Ubuntu: Hasta los grandes deben aprender sobre interfaces
Ayer, no me andaba el teclado numérico en Ubuntu.
Me extrañó mucho dado que hacía poco estaba funcionando y, que todo ese sector del teclado se haya roto me parecía raro.
Busqué en google.
Me encontré con que, a varios les había pasado lo mismo, en algún momento.
No se si fue al actualizarse una versión, o si hay algún atajo raro que hace esto, o que tipo de bug raro lo ocasionó.
Al parecer, existe una opción de manejar el mouse con el teclado que, se activó mágicamente.
Claro, si uno conoce que existe la opción, es probable que se de cuenta rápido de cuál es el problema.
El tema es que, yo no conocía que existía esa opción y, como al querer teclear los números, uno pasa rápidamente por las teclas, no percibía que había un movimiento en el puntero del mouse (que sí es obvio cuando uno deja apretada una de las teclas)
Entonces, para qué toda esta historieta?
Cuando hay una opción activada y esta es poco convencional y además produce un resultado confuso (en este caso, uno piensa que no funciona el teclado numérico) se debe indicar en pantalla, con un icono o algo que dicha opción está activada.
Sorry Ubuntu, pero en esta le pifiaron.
Me extrañó mucho dado que hacía poco estaba funcionando y, que todo ese sector del teclado se haya roto me parecía raro.
Busqué en google.
Me encontré con que, a varios les había pasado lo mismo, en algún momento.
No se si fue al actualizarse una versión, o si hay algún atajo raro que hace esto, o que tipo de bug raro lo ocasionó.
Al parecer, existe una opción de manejar el mouse con el teclado que, se activó mágicamente.
Claro, si uno conoce que existe la opción, es probable que se de cuenta rápido de cuál es el problema.
El tema es que, yo no conocía que existía esa opción y, como al querer teclear los números, uno pasa rápidamente por las teclas, no percibía que había un movimiento en el puntero del mouse (que sí es obvio cuando uno deja apretada una de las teclas)
Entonces, para qué toda esta historieta?
Cuando hay una opción activada y esta es poco convencional y además produce un resultado confuso (en este caso, uno piensa que no funciona el teclado numérico) se debe indicar en pantalla, con un icono o algo que dicha opción está activada.
Sorry Ubuntu, pero en esta le pifiaron.
sábado, 23 de abril de 2011
Clap, clap, clap
“If Java had true garbage collection, most programs would delete themselves upon execution.”
(Robert Sewell)
(Robert Sewell)
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 (*):
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:
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 =)
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 =)
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 =)
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:
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"
"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"
lunes, 13 de septiembre de 2010
Por qué la gente no usa Linux?
Detrás de la pregunta que es, más que nada, "marketinera", hay algo que me hizo meditar un poco (milagro!)
Cuantas veces hemos oído o leído a los típicos linux-fan-boys decir
"Usen linux! El que no lo hace es estúpido!" y, por otro lado, los windows-fan-boys responden "Linux es dificil, queremos que todo sea amigable" y millares de explicaciones similares. Líneas y líneas de mails, foros, etc.
Lo que nadie dice, o al menos, nunca leí ni oí es algo más simple. Algo, tan evidente, que parece escapar a la vista de hasta los más despabilados. Y es lo siguiente:
La gente (toda) es un animal de costumbre.
Parece una frase hecha, es verdad. Pues lo es. Y es cierta, lamentablemente o no.
Windows, se malo o bueno, es lo que se mantuvo. Es lo que hay.
No voy a hacer de esto una clase de historia, pero, más o menos, es sabido como prevaleció por sobre otros sistemas operativos. Cómo lo hizo? En su momento fue una suma de suerte, olfato para los negocios, manejos oscuros y oportunismo. Así fue que, para bien o para mal, cuando mucha gente vió por vez primera una computadora (me incluyo) ya venía con windows. Windows era lo que no se cuestionaba. Ya estaba ahí.
Al desconocer uno no cuestiona.
Hardware + Windows = Computadora.
Así me lo presentaron, a mi y a millones. Como un televisor, una radio o una video casettera. Casi nadie se anda preguntando qué sistema operativo tiene una TV, o basado en qué está. Simplemente está ahi y es el medio para que usemos el aparato en sí. Así ve a windows el usuario normal.
Desde que fui al colegio (en mi casa no tuve computadora sino hasta ser maś grande) nunca me pregunté: Por qué windows? Ni siquiera me puse a pensar si existiría algo más. En ese momento, Linux, por ejemplo, era mucho menos popular que hoy en día. Nunca nadie me lo comentó tampoco (mis profesoras de computación eran casi amebas). Pensemos en que, en esa época, la computadora era, un lujo que no todos podían darse. Internet era solo para nerds raros que conectaban el teléfono para navegar entre las BBS. La gente no sabía que es Linux (hoy, un alto % por lo menos sabe qué es)
No fue hasta tener una pc que me interesó el tema y, leyendo mucho y interesandome por temas de seguridad y, los mal llamados hackers[0], fue leí que existía algo llamado Linux y decidí instalarlo.
Ahora bien, el usuario normal, es curioso por los temas de computación? NO. Rotundamente, no. El usuario común usa la pc porque le sirve para algo. O para trabajar, o para entretenerse, o para estudiar. Pero nada más. Esto es algo que, la gente que estamos en computación, a veces olvidamos. Al usuario estandar NO le interesa como funcionan las cosas. Sólo que funcionen. Al usuario normal no le gusta pasar horas en la pc y resolver problemas. Si fuera por él, usaria 2 o 3 programas y nunca cambiaría nada. Y acá aparece la resistencia el cambio.
El usuario normal no es como nosotros (los informáticos) no les importa instalar la nueva versión de XXYY, ni configurarla para que haga N, ni entender como funciona, ni los detrás de escena, ni si hay tal o cuál distro de linux, nada.
Mientras cualquiera de nosotros pasaría (y con gusto) horas configurando nuestro sistema, instalando X dependencia, compilando, programando, etc, al usuario esto le parecería, simplemente, un problema, una molestia.
Ya adivinan por qué la gente no usa Linux?
La gente (usuario estandar) no usa Linux porque no quiere algo distinto a lo que está acostumbrada. No le importa que funcione mejor o si es gratis. Quiere que sea como se acostumbró a usar. Quiere que el messenger tenga al tipito verde y el office sea el office y no el OpenOffice, por más que haga exactamente lo mismo o mejor, no le interesa. Y no es que sea idiota. No. Es que quiere el mismo paradigma, desea la sensación de "esto lo conozco". El, "esto es nuevo" lo aterra, y repito, NO es que sea un idiota, es la naturaleza humana!! Todos somos así.
Muchos creen que la gente usa windows porque windows hace algo mejor que Linux. Esto es, cuando menos una opinión desinformada. Alguien que haya usado (y use) ambos sistemas operativos, no puede NUNCA pensar algo así. Es naive, cuando menos. Lo único que le brinda windows a la gente es la sensación de seguridad. Seguridad, no porque sea más "inviolable" sino, la seguridad de la familiaridad. Más vale malo conocido, dicen, no?
Otros dicen que la gente no usa Linux porque es dificil. Lo mismo que lo anterior, nadie que haya usado o instalado una distro moderna, puede opinar eso. Dicho argumento es de, por lo menos, 10 años atrás cuando, debo reconocer, Linux era un poco para usuario más avanzados.
Hoy en día esto no es así[1]
Yo soy un usuario de Linux, no soy un fanático pero, estoy de acuerdo con la filosofía del OpenSource[2]. La principal razón por la cuál yo instalé Linux fue debido a mi curiosidad. Luego, al instalarlo noté mejoras en ciertos aspecto como, más comodidad y rendimiento en herramientas que yo uso como programador. Luego vi que ya no necesitaba un antivirus y que, todo lo que pasaba en el sistema podía ser tan transparente o tan "verboso" como yo quisiera. Pero eso ya es mi historia personal...
No estoy exponiendo razones de por qué Linux es o no mejor. Sino que, no hay razones (reales técnicas) para no usarlo más que el simple miedo al cambio.
-----------------------------------------------------------------------------------------------------------------------------
[0] hackers, entendido como "piratas informáticos" y sólo eso, es algo que hay que agradecerle al periodismo, mayormente. Obviamente, esto no es correcto, hay mejores definiciones.
[1] http://www.youtube.com/watch?v=zVmpTQW_fP8
http://www.guia-ubuntu.org/index.php?title=Instalaci%C3%B3n_est%C3%A1ndar
[2] en.wikipedia.org/wiki/Open_source
Cuantas veces hemos oído o leído a los típicos linux-fan-boys decir
"Usen linux! El que no lo hace es estúpido!" y, por otro lado, los windows-fan-boys responden "Linux es dificil, queremos que todo sea amigable" y millares de explicaciones similares. Líneas y líneas de mails, foros, etc.
Lo que nadie dice, o al menos, nunca leí ni oí es algo más simple. Algo, tan evidente, que parece escapar a la vista de hasta los más despabilados. Y es lo siguiente:
La gente (toda) es un animal de costumbre.
Parece una frase hecha, es verdad. Pues lo es. Y es cierta, lamentablemente o no.
Windows, se malo o bueno, es lo que se mantuvo. Es lo que hay.
No voy a hacer de esto una clase de historia, pero, más o menos, es sabido como prevaleció por sobre otros sistemas operativos. Cómo lo hizo? En su momento fue una suma de suerte, olfato para los negocios, manejos oscuros y oportunismo. Así fue que, para bien o para mal, cuando mucha gente vió por vez primera una computadora (me incluyo) ya venía con windows. Windows era lo que no se cuestionaba. Ya estaba ahí.
Al desconocer uno no cuestiona.
Hardware + Windows = Computadora.
Así me lo presentaron, a mi y a millones. Como un televisor, una radio o una video casettera. Casi nadie se anda preguntando qué sistema operativo tiene una TV, o basado en qué está. Simplemente está ahi y es el medio para que usemos el aparato en sí. Así ve a windows el usuario normal.
Desde que fui al colegio (en mi casa no tuve computadora sino hasta ser maś grande) nunca me pregunté: Por qué windows? Ni siquiera me puse a pensar si existiría algo más. En ese momento, Linux, por ejemplo, era mucho menos popular que hoy en día. Nunca nadie me lo comentó tampoco (mis profesoras de computación eran casi amebas). Pensemos en que, en esa época, la computadora era, un lujo que no todos podían darse. Internet era solo para nerds raros que conectaban el teléfono para navegar entre las BBS. La gente no sabía que es Linux (hoy, un alto % por lo menos sabe qué es)
No fue hasta tener una pc que me interesó el tema y, leyendo mucho y interesandome por temas de seguridad y, los mal llamados hackers[0], fue leí que existía algo llamado Linux y decidí instalarlo.
Ahora bien, el usuario normal, es curioso por los temas de computación? NO. Rotundamente, no. El usuario común usa la pc porque le sirve para algo. O para trabajar, o para entretenerse, o para estudiar. Pero nada más. Esto es algo que, la gente que estamos en computación, a veces olvidamos. Al usuario estandar NO le interesa como funcionan las cosas. Sólo que funcionen. Al usuario normal no le gusta pasar horas en la pc y resolver problemas. Si fuera por él, usaria 2 o 3 programas y nunca cambiaría nada. Y acá aparece la resistencia el cambio.
El usuario normal no es como nosotros (los informáticos) no les importa instalar la nueva versión de XXYY, ni configurarla para que haga N, ni entender como funciona, ni los detrás de escena, ni si hay tal o cuál distro de linux, nada.
Mientras cualquiera de nosotros pasaría (y con gusto) horas configurando nuestro sistema, instalando X dependencia, compilando, programando, etc, al usuario esto le parecería, simplemente, un problema, una molestia.
Ya adivinan por qué la gente no usa Linux?
La gente (usuario estandar) no usa Linux porque no quiere algo distinto a lo que está acostumbrada. No le importa que funcione mejor o si es gratis. Quiere que sea como se acostumbró a usar. Quiere que el messenger tenga al tipito verde y el office sea el office y no el OpenOffice, por más que haga exactamente lo mismo o mejor, no le interesa. Y no es que sea idiota. No. Es que quiere el mismo paradigma, desea la sensación de "esto lo conozco". El, "esto es nuevo" lo aterra, y repito, NO es que sea un idiota, es la naturaleza humana!! Todos somos así.
Muchos creen que la gente usa windows porque windows hace algo mejor que Linux. Esto es, cuando menos una opinión desinformada. Alguien que haya usado (y use) ambos sistemas operativos, no puede NUNCA pensar algo así. Es naive, cuando menos. Lo único que le brinda windows a la gente es la sensación de seguridad. Seguridad, no porque sea más "inviolable" sino, la seguridad de la familiaridad. Más vale malo conocido, dicen, no?
Otros dicen que la gente no usa Linux porque es dificil. Lo mismo que lo anterior, nadie que haya usado o instalado una distro moderna, puede opinar eso. Dicho argumento es de, por lo menos, 10 años atrás cuando, debo reconocer, Linux era un poco para usuario más avanzados.
Hoy en día esto no es así[1]
Yo soy un usuario de Linux, no soy un fanático pero, estoy de acuerdo con la filosofía del OpenSource[2]. La principal razón por la cuál yo instalé Linux fue debido a mi curiosidad. Luego, al instalarlo noté mejoras en ciertos aspecto como, más comodidad y rendimiento en herramientas que yo uso como programador. Luego vi que ya no necesitaba un antivirus y que, todo lo que pasaba en el sistema podía ser tan transparente o tan "verboso" como yo quisiera. Pero eso ya es mi historia personal...
No estoy exponiendo razones de por qué Linux es o no mejor. Sino que, no hay razones (reales técnicas) para no usarlo más que el simple miedo al cambio.
-----------------------------------------------------------------------------------------------------------------------------
[0] hackers, entendido como "piratas informáticos" y sólo eso, es algo que hay que agradecerle al periodismo, mayormente. Obviamente, esto no es correcto, hay mejores definiciones.
[1] http://www.youtube.com/watch?v=zVmpTQW_fP8
http://www.guia-ubuntu.org/index.php?title=Instalaci%C3%B3n_est%C3%A1ndar
[2] en.wikipedia.org/wiki/Open_source
sábado, 19 de junio de 2010
Top 5 tips para desarrollar mejores aplicaciones
Muchas veces me pongo a pensar en retrospectiva, acerca de cosas que se han hecho bien y cosas que se han hecho mal. Aquí escribo un resumen de las principales cosas que recomiendo hacer para ser un programador más feliz.
1- El usuario no tiene tiempo, ni quiere leer.
Olvidense del RTFM. Nadie lo lee. Hay que imaginarse que el usuario está inmerso en un caos tremendo, teléfonos sonando, gente, alarmas, etc. Lo que menos quisiera es estar lidiando con carteles del tipo "está seguro que desea cerrar etc", o, con aplicaciones oscuras que, si bien hace lo que se debe, tienen muchos botones, radio button y demás, y que, ni el mismo desarrollador entiende sin mirar el código.
Por eso, las aplicaciones tienen que ser intuitivas, se tienen que "auto-explicar". Lo mismo se aplica para los carteles y pop-ups que requieren una decisión del usuario. Si no hay más remedio que poner un cartel, que sea corto y puntal. Por ejemplo:
¿Está seguro que desea cerrar la aplicación?
[si] [no]
Cuando se podría:
¿Salir?
[si] [no]
Mucho más corto y al pie.
Por último, recuerden la página de Google, un cuadro de texto y un botón. ¿Qué mas?
2- Refactorizar vs From Scratch.
No siempre es bueno reescribir todo, ni tampoco siempre lo es reusar. Hay que usar esto de forma inteligente. Por un lado el código viejo no es necesariamente malo o confuso. Hay que tener en cuenta que, por un lado, leer código es más dificil que escribirlo (por eso siempre es tentador el reescribir todo) y por otro, el código viejo es, muchas veces, un código ya testeado, con bugs correjidos, en fin, es tiempo de trabajo. Reescribir todo desde cero significaría, tirar todo eso a la basura.
Lo ideal es un balance entre, reescribir las partes "mal escritas" tratando de reusar lo más posible. Es significativamente menos tiempo que escribir todo desde cero, sobre todo, si tenemos en cuenta que, el código desde cero va a tener bugs nuevos.
3- Pensar en grande.
Todo buen programa tiene que empezar cómo algo simple, pero, pensado a lo grande. Esto es, pensar que en un futuro, el programa puede crecer. Por eso, hay que escribir todo de forma flexible, aunque lleve más tiempo ahora, en un futuro va a ser más facil expandir y mantener. Mucho se ha hablado de la deuda técnica.Esto es un poco lo que trato de comunicar aquí: El tiempo que se ahorra escribiendo código chapucero ahora, lo pagás mañana.
4- Keep it simple.
Muchas aplicaciones tienen varias faces de desarrollo. Esto es, se reune con el cliente, se diseña, se programa, se vuelve a ver con el cliente, se corrijen cosas, se agregan otras. Entonces, es de esperar que el cliente no sea muy lógico, que haga cambios sobre la marcha y que no tenga en cuenta el diseño general del sistema. Para eso nos paga a nosotros ¿Verdad? Por eso, siempre hay que hacer limpieza del código y del programa. Lo que no se usa, fuera (por lo menos, de la vista) Esto ayuda mucho a que se cumpla el punto 1.
Si la aplicación en si, estaba pensada con otro espiritu y luego, se modificó, tratar de quitar todo lo que sobre. A veces más es menos. Muchos botones y radio button, checks, etc, para mantener un poco la idea anterior y que conviva con la idea nueva genera más problemas que soluciones. Use it or lose it.
5- Testing
Esto es obvio, pero, no se respeta mucho. El cliente no es un beta tester. Si se programa con la idea "que tenga bugs, total lo corrijo rápido" se arriesga, primero, problemas en datos que haya que resolver (esto es tiempo) y, segundo, da la idea de que el programa anda mal.
1- El usuario no tiene tiempo, ni quiere leer.
Olvidense del RTFM. Nadie lo lee. Hay que imaginarse que el usuario está inmerso en un caos tremendo, teléfonos sonando, gente, alarmas, etc. Lo que menos quisiera es estar lidiando con carteles del tipo "está seguro que desea cerrar etc", o, con aplicaciones oscuras que, si bien hace lo que se debe, tienen muchos botones, radio button y demás, y que, ni el mismo desarrollador entiende sin mirar el código.
Por eso, las aplicaciones tienen que ser intuitivas, se tienen que "auto-explicar". Lo mismo se aplica para los carteles y pop-ups que requieren una decisión del usuario. Si no hay más remedio que poner un cartel, que sea corto y puntal. Por ejemplo:
¿Está seguro que desea cerrar la aplicación?
[si] [no]
Cuando se podría:
¿Salir?
[si] [no]
Mucho más corto y al pie.
Por último, recuerden la página de Google, un cuadro de texto y un botón. ¿Qué mas?
2- Refactorizar vs From Scratch.
No siempre es bueno reescribir todo, ni tampoco siempre lo es reusar. Hay que usar esto de forma inteligente. Por un lado el código viejo no es necesariamente malo o confuso. Hay que tener en cuenta que, por un lado, leer código es más dificil que escribirlo (por eso siempre es tentador el reescribir todo) y por otro, el código viejo es, muchas veces, un código ya testeado, con bugs correjidos, en fin, es tiempo de trabajo. Reescribir todo desde cero significaría, tirar todo eso a la basura.
Lo ideal es un balance entre, reescribir las partes "mal escritas" tratando de reusar lo más posible. Es significativamente menos tiempo que escribir todo desde cero, sobre todo, si tenemos en cuenta que, el código desde cero va a tener bugs nuevos.
3- Pensar en grande.
Todo buen programa tiene que empezar cómo algo simple, pero, pensado a lo grande. Esto es, pensar que en un futuro, el programa puede crecer. Por eso, hay que escribir todo de forma flexible, aunque lleve más tiempo ahora, en un futuro va a ser más facil expandir y mantener. Mucho se ha hablado de la deuda técnica.Esto es un poco lo que trato de comunicar aquí: El tiempo que se ahorra escribiendo código chapucero ahora, lo pagás mañana.
4- Keep it simple.
Muchas aplicaciones tienen varias faces de desarrollo. Esto es, se reune con el cliente, se diseña, se programa, se vuelve a ver con el cliente, se corrijen cosas, se agregan otras. Entonces, es de esperar que el cliente no sea muy lógico, que haga cambios sobre la marcha y que no tenga en cuenta el diseño general del sistema. Para eso nos paga a nosotros ¿Verdad? Por eso, siempre hay que hacer limpieza del código y del programa. Lo que no se usa, fuera (por lo menos, de la vista) Esto ayuda mucho a que se cumpla el punto 1.
Si la aplicación en si, estaba pensada con otro espiritu y luego, se modificó, tratar de quitar todo lo que sobre. A veces más es menos. Muchos botones y radio button, checks, etc, para mantener un poco la idea anterior y que conviva con la idea nueva genera más problemas que soluciones. Use it or lose it.
5- Testing
Esto es obvio, pero, no se respeta mucho. El cliente no es un beta tester. Si se programa con la idea "que tenga bugs, total lo corrijo rápido" se arriesga, primero, problemas en datos que haya que resolver (esto es tiempo) y, segundo, da la idea de que el programa anda mal.
sábado, 12 de diciembre de 2009
El funesto caso de Is y ==
Hace varios días (creo que pasaron meses) inicié una discusión en la lista de mail (creo yo, más famosa y con más gente que sabe en serio) de python. PyAr.
La cosa empezó por un artículo que leo, donde se mostraba lo siguiente:
Luego
Claro. Al ser relativamente nuevo en python, ver esto me sorprendió, por lo que decido preguntar de que se trataba en la lista.
Mi pregunta no fue del todo clara, (y acepto 100% la culpa) por lo que se entendió que mi sorpresa venia por una confusión de conceptos y que, lo que no sabía era la diferencia entre "is" y "==".
Lo que pasó:
En realidad, yo posteo todo el ejemplo (que incluye "is" y "==") para dar un contexto, pero, en si, mi sorpresa venía SOLAMENTE por ver como el operador "is" se comportaba aparentemente distinto en dos situaciones aparentemente iguales.
Noten el uso de aparentemente. Esto es:
[entero_valor_x] is [entero_valor_x]
[entero_valor_Y] is [entero_valor_Y]
False
Olvidemos que comparar enteros con "is" es una chanchada, es incorrecto y no tiene mucho sentido. Más allá de eso, no me parecía (noten que uso el tiempo pasado) que comparar enteros (del mismo valor numérico) con "is" resultara True en algunos casos y False en otros. No veia el por qué, y me parecía feo (noten que sigo usando el pasado).
Pero claro, como se interpretó mal mi pregunta, todo se enfocó a explicarme que "is" no era "==", lo cuál, no era PARA NADA el punto del topic.
Claro, fue mi culpa por no ser claro en una primera instancia. Luego, traté de remediarlo, pero ya era tarde y... el resto es historia.
La explicación:
La explicación la había encontrado muy al comienzo del thread. Posteo una que me gustó y es sencilla:
Autor: Facundo Batista
Fecha: 2009-11-04 12:192009-11-04 15:19 -300UTC
A: pyar
Asunto: Re: [pyar] WTF?
Esa es sólo una, varios usuarios lo explicaron muy bien también. =)
Y eso era todo lo que quería escuchar. Una explicación sobre el funcionamiento, en apariencia, raro del "is" comparando enteros. No que me digan que usar "is" en ese caso estaba mal (cosa que sabía) ni que "is" no es "==" (cosa que sabía), y un largo etc.
La cosa empezó por un artículo que leo, donde se mostraba lo siguiente:
>>> a = 10
>>> b = 10
>>> a == b
True
>>> a is b
True
>>> b = 10
>>> a == b
True
>>> a is b
True
Luego
>>> a = 500
>>> b = 500
>>> a == b
True
>>> a is b
False
>>> b = 500
>>> a == b
True
>>> a is b
False
Claro. Al ser relativamente nuevo en python, ver esto me sorprendió, por lo que decido preguntar de que se trataba en la lista.
Mi pregunta no fue del todo clara, (y acepto 100% la culpa) por lo que se entendió que mi sorpresa venia por una confusión de conceptos y que, lo que no sabía era la diferencia entre "is" y "==".
Lo que pasó:
En realidad, yo posteo todo el ejemplo (que incluye "is" y "==") para dar un contexto, pero, en si, mi sorpresa venía SOLAMENTE por ver como el operador "is" se comportaba aparentemente distinto en dos situaciones aparentemente iguales.
Noten el uso de aparentemente. Esto es:
True
Olvidemos que comparar enteros con "is" es una chanchada, es incorrecto y no tiene mucho sentido. Más allá de eso, no me parecía (noten que uso el tiempo pasado) que comparar enteros (del mismo valor numérico) con "is" resultara True en algunos casos y False en otros. No veia el por qué, y me parecía feo (noten que sigo usando el pasado).
Pero claro, como se interpretó mal mi pregunta, todo se enfocó a explicarme que "is" no era "==", lo cuál, no era PARA NADA el punto del topic.
Claro, fue mi culpa por no ser claro en una primera instancia. Luego, traté de remediarlo, pero ya era tarde y... el resto es historia.
La explicación:
La explicación la había encontrado muy al comienzo del thread. Posteo una que me gustó y es sencilla:
Autor: Facundo Batista
Fecha: 2009-11-04 12:192009-11-04 15:19 -300UTC
A: pyar
Asunto: Re: [pyar] WTF?
a apunta a un 3 en memoria, y b apunta al mismo 3 en memoria. Python
no creó dos objetos "3", sino que usó el mismo para los nombres a y b.
no creó dos objetos "3", sino que usó el mismo para los nombres a y b.
a apunta a un 500 en memoria, y b apunta a otro 500 en memoria. Python
sí creó dos objetos "500".
La pregunta es... ¿por qué la diferencia de comportamiento? Como bien
dijo Nati arriba, Python precachea (o tiene internalizado) algunos
enteros chicos, porque sabe que siempre se van a usar.
sí creó dos objetos "500".
La pregunta es... ¿por qué la diferencia de comportamiento? Como bien
dijo Nati arriba, Python precachea (o tiene internalizado) algunos
enteros chicos, porque sabe que siempre se van a usar.
Esa es sólo una, varios usuarios lo explicaron muy bien también. =)
Y eso era todo lo que quería escuchar. Una explicación sobre el funcionamiento, en apariencia, raro del "is" comparando enteros. No que me digan que usar "is" en ese caso estaba mal (cosa que sabía) ni que "is" no es "==" (cosa que sabía), y un largo etc.
sábado, 14 de noviembre de 2009
Mi Filosofía de la Programación
a) Los nombres de variables y procedimientos deben ser descriptivos, pero, lo más breves posibles. Lo mismo se aplica a nombres de tablas y campos de las mismas.
b) Los nombres de variables auxiliares deben ser más cortos aún. Si es una sola letra, mejor.
c) Todo código que se puede reutilizar se debe reutilizar.
d) Si vas a escribir 2 veces algo similar, es probable que tengas que separar ese trozo en un procedimiento aparte.
e) Es preferible que el código se explique a si mismo que escribir código ofuscado y necesitar n líneas de comentarios (salvo que genere una alta considerable en el rendimiento)
f) El CamelCase da legibilidad, pero no hay que abusar. Lo mismo se aplica al underscore.
g) Una pequeña línea de comentarios a veces ayuda mucho, pero, no abusar, si quisieramos escribir tanto seríamos escritores.
----------------------------------------------------------------------------------------------------------------------------------
Esa es mi filosofía en cuanto a la programación. Se puede estar de acuerdo o no. Paso a explicar cada punto:
a) Esto es, no usar nombre del tipo xuiud, xxsw, x45, n45. Pero tampoco utilizar nombres como NrodeCuentaBancariadelCliente. clie, nomb, arti son óptimas para variables o campos, Articulos, Clientes, VeriDeuda para tablas o procedimientos. Sentido común, yo puedo llamar a una funcion VerificarDeudaCliente, pero podría abreviarla con VeriDeuda y se seguiría entendiendo de qué se trata.
b) Si se va a usar una varible que, por ejemplo, se incrementa en una iteración el nombre tiene que se más corto aún que en a), por ejemplo: i, e, r.
c) Este punto es bastante obvio. Si ya lo pensaste ayer, reciclalo.
d) No dudar en separar código en común en una subturina o función pasandoles argumentos.
e) Eso es algo que siempre discuto. Es preferible escribir código un poco más largo en líneas pero que se entienda fácil a escribir algo ofuscado y necesitar varias líneas de comentarios para explicarlo. Esto es más obvio cuando se escribe algo hoy y se tiene que modificar en 2 o 3 meses. Ese sería el filtro.
La única excepción sería si escribirlo así me diera un rendimiento mayor y notorio.
f) Usarlos con sentido común. VeriClie o veri_clie, son aceptables. VeRiClIe o ve_ri_cli_e, es abusar.
g) Relacionado con el punto e). Agregar una línea de comentario para aclarar un poco el panorama está bien. Ahora, líneas y líneas por todos lados demuestra que algo no anda bien, por qué tu código necesita tanta explicación??
Además, si tanto te gusta escribir, capaz deberías considerar la literatura =)
Suscribirse a:
Comentarios (Atom)
Entradas
