Pagina principal en GameJolt
Si te gusta mi trabajo, hay 2 formas de ayudarme:
1.
2. Correr la voz!! (para que mas gente me conozca a mí y a mi juego)
Hasta la próxima!
Trailer oficial:
Review:
Mostrando entradas con la etiqueta proyectos personales. Mostrar todas las entradas
Mostrando entradas con la etiqueta proyectos personales. Mostrar todas las entradas
domingo, 19 de mayo de 2013
Beelzeboy: Beta v2
Salió la beta v2 de mi juego:
Pagina principal en GameJolt
Si te gusta mi trabajo, hay 2 formas de ayudarme:
1.
2. Correr la voz!! (para que mas gente me conozca a mí y a mi juego)
Hasta la próxima!
Trailer oficial:
Review:
Pagina principal en GameJolt
Si te gusta mi trabajo, hay 2 formas de ayudarme:
1.
2. Correr la voz!! (para que mas gente me conozca a mí y a mi juego)
Hasta la próxima!
Trailer oficial:
Review:
miércoles, 27 de febrero de 2013
sábado, 23 de febrero de 2013
Beelzeboy: Mi 1er video juego
Básicamente, eso. Desde el año pasado que empecé a hacer un video juego de plataformas en Flash.
Por qué?
1- Porque es divertido
2- Porque puedo
Algunas capturas:
Lo estoy empezando a hacer publico ahora, porque estoy cerca de terminarlo y, quiero empezar a mostrarlo (más allá de que se lo mostré a amigos y demás, obviamente)
De python, casi nada, salvo pavadas que hice para automatizar algunas cosas (por ejemplo generación de código ActionScript) no hay mucho para destacar.
Donde se puede ver algo (más fotos)?
https://www.facebook.com/Beelzeboy
http://beelzeboy.wordpress.com
Proximamente en: http://www.newgrounds.com
Stay tuned.
martes, 10 de abril de 2012
Cloud.obj - Objetos Python en la nube
Primero que nada, un poco de historia. Estaba pensando: Se pueden importar módulos que estén en un servidor remoto? Y, si es sí, se puede hacer fácil, con poco código y, portable?
Todo eso, en Python, fue un SI.
La idea es, Cloud.Obj es un repositorio de modulos de Python, de donde todo el mundo puede hacer sus "imports", sin modificar demasiado el código que usarían para importarlo localmente.
Lo único que se necesita es bajar un modulito, "cloud.py" y ya está listo para usar, sin dependencias ni nada más extra.
Aquí, un ejemplo de uso:
Por supuesto, si picara la curiosidad o si, simplemente, quisieran montar su propio servicio, el código del "server", también está en GitHub, listo para que lo bajen, en sus versiones "Servidor local" y "listo para deploy en GAE"
Más adelante, tendrá dos sabores:
Public Repo: Módulos importables públicos, para todos.
Private Repo: Con login, para quienes quieran subir código importable, protegido con password.
Cabe aclarar que, si bien hablo de repositorios, la idea no es ser un github, sino, un lugar común y en la nube, desde donde importar la última versión del módulo X.
Aquí los links:
Servicio en GAE
Download
GitHub
Y, cómo siempre, se aceptan ideas, críticas y quien quiera participar, bienvenidisimo!
Todo eso, en Python, fue un SI.
La idea es, Cloud.Obj es un repositorio de modulos de Python, de donde todo el mundo puede hacer sus "imports", sin modificar demasiado el código que usarían para importarlo localmente.
Lo único que se necesita es bajar un modulito, "cloud.py" y ya está listo para usar, sin dependencias ni nada más extra.
Aquí, un ejemplo de uso:
- #A simple, example
- import cloud
- o = cloud.Obj("http://cloudobj.appspot.com/sys") #o is the module sys
- print "The path is ", o.path
- print o
Por supuesto, si picara la curiosidad o si, simplemente, quisieran montar su propio servicio, el código del "server", también está en GitHub, listo para que lo bajen, en sus versiones "Servidor local" y "listo para deploy en GAE"
Más adelante, tendrá dos sabores:
Public Repo: Módulos importables públicos, para todos.
Private Repo: Con login, para quienes quieran subir código importable, protegido con password.
Cabe aclarar que, si bien hablo de repositorios, la idea no es ser un github, sino, un lugar común y en la nube, desde donde importar la última versión del módulo X.
Aquí los links:
Servicio en GAE
Download
GitHub
Y, cómo siempre, se aceptan ideas, críticas y quien quiera participar, bienvenidisimo!
domingo, 11 de diciembre de 2011
Django-IDE: Ahora en GitHub!
Ya está subido el código de lo que hay hasta ahora, de la IDE que estoy cocinando:
Introducing: Django-IDE
Hay mucho por hacer y mucho por mejorarle, por lo que, colaboradores bienvenidos!
Introducing: Django-IDE
Hay mucho por hacer y mucho por mejorarle, por lo que, colaboradores bienvenidos!
martes, 25 de octubre de 2011
Django-IDE: Video preview
Luego de escribir este post IPnaf IDE - La IDE definitiva para python, y recibir algunos comentarios que me hicieron pensar (y ver que, estaba un poco equivocado en mis comentatios), me dije "y por qué no puedo ser yo quién arme una IDE?"
Y así fue que, pensando un poco, me puse a intentar llenar un hueco que, creo que está lo suficientemente vacío como para que un esfuerzo allí, valga la pena.
Entonces, empezó a nacer Django-IDE.
Les dejo un video con una preview muy muy muuuuy temprana (no tiene para nada todos los features que va a tener), en fin, acá va:
Espero comments!!! :)
Y así fue que, pensando un poco, me puse a intentar llenar un hueco que, creo que está lo suficientemente vacío como para que un esfuerzo allí, valga la pena.
Entonces, empezó a nacer Django-IDE.
Les dejo un video con una preview muy muy muuuuy temprana (no tiene para nada todos los features que va a tener), en fin, acá va:
Ver en youtube
What is Django-IDE good for?
Django-IDE helps you to:- Easily create Django projects.
- Manage and edit existing project
- Edit and Save your code, with a editor based on Ace.
- Run and debug.
Espero comments!!! :)
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, 14 de julio de 2011
Volvi a programar en mi "spare time": web_alert - Parte 2
En un post anterior, estuve contando sobre un proyectito que arranqué, por puro hobbie pero, esperando que sea útil a la vez.
La cosa es que me encontré con algo que me desaminó un poco: http://www.webalertpro.com/
Primero, es casi exactamente la misma idea.
Segundo, tiene casi el mismo nombre!
Obviamente, esto es culpa de mi, evidente, falta de inventiva.
Por ahora sigue el proyecto, pero lamentablemente, perdió un poco de empuje.
La cosa es que me encontré con algo que me desaminó un poco: http://www.webalertpro.com/
Primero, es casi exactamente la misma idea.
Segundo, tiene casi el mismo nombre!
Obviamente, esto es culpa de mi, evidente, falta de inventiva.
Por ahora sigue el proyecto, pero lamentablemente, perdió un poco de empuje.
martes, 28 de junio de 2011
Volvi a programar en mi "spare time": web_alert
Proyecto: web_alert
Objetivos: Divertirme, aprender y, en una de esas, sale algo útil.
Lenguajes: Python, obvio!
Queriendo meterme un poco con python+web, empecé un proyectito al que nombré "web_alert".
Primero lo armé versión consola y "on demand", luego la idea es que sea una especie de servicio web.
Qué haría? Fácil, toma como input urls que el usuario suministra y tags de interés que el usuario suministra, por ejemplo:
urls: http://barrapunto.com, http://www.lanacion.com.ar
tags: panchos, celulares, perros
La aplicación 'mira' esas urls, y genera como output links relacionados con los tags que le pasas como input y, te lo presenta donde vos le digas, por ejemplo:
mail, twitter, facebook.
Sirve? No se, pero que me voy a divertir, seguro. =)
P.D: Previews y el código en google, coming soon...
EDITADO: Este post estaba en planeta python y desapareció, jua! =)
Objetivos: Divertirme, aprender y, en una de esas, sale algo útil.
Lenguajes: Python, obvio!
Queriendo meterme un poco con python+web, empecé un proyectito al que nombré "web_alert".
Primero lo armé versión consola y "on demand", luego la idea es que sea una especie de servicio web.
Qué haría? Fácil, toma como input urls que el usuario suministra y tags de interés que el usuario suministra, por ejemplo:
urls: http://barrapunto.com, http://www.lanacion.com.ar
tags: panchos, celulares, perros
La aplicación 'mira' esas urls, y genera como output links relacionados con los tags que le pasas como input y, te lo presenta donde vos le digas, por ejemplo:
mail, twitter, facebook.
Sirve? No se, pero que me voy a divertir, seguro. =)
P.D: Previews y el código en google, coming soon...
EDITADO: Este post estaba en planeta python y desapareció, jua! =)
miércoles, 1 de junio de 2011
Framework web minimo
Estaba buscando algún framework web, chiquito y sencillo. Quería tirar código y que salga andando algo, fácil, sin instalar mucho ni configurar.
Se me ocurrió preguntar en la lista de python argentina[0].
Al instante, muchas respuestas y, una de ellas me nombraba web.py (que lo conocía) y otro más[1], que es el motivo de este post:
Muy zarpado. Lo primero que me cautivó:
"Bottle does not depend on any external libraries. You can just download bottle.py into your project directory and start coding."
Un solo archivo! Lo importo y, habemus web. Eso es lo que quería!
Luego, el hello world:
Creó que me enamoré =)
[0] PyAr
[1] Bottle
Se me ocurrió preguntar en la lista de python argentina[0].
Al instante, muchas respuestas y, una de ellas me nombraba web.py (que lo conocía) y otro más[1], que es el motivo de este post:
Muy zarpado. Lo primero que me cautivó:
"Bottle does not depend on any external libraries. You can just download bottle.py into your project directory and start coding."
Un solo archivo! Lo importo y, habemus web. Eso es lo que quería!
Luego, el hello world:
from bottle import route, run @route('/hello') def hello(): return "Hello World!"Cada vez se ponía mejor. Sintaxis clara y, una linda manera de resolver la relación url-código: Decoradores.
Creó que me enamoré =)
[0] PyAr
[1] Bottle
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. :)
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 =)
jueves, 10 de marzo de 2011
Magia Negra: Un ActiveRecord en pytnon
Status: Muerto por falta de interés.
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:
=)
https://bugzilla.mozilla.org/show_bug.cgi?id=606824
http://hg.mozilla.org/mozilla-central/rev/a5092e4ae324
Solo puedo agregar lo siguiente:
=)
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, 20 de septiembre de 2010
Client side Python
El pasado sábado 18-09, estuve en la Mozilla SFD y, en una de las charlas me enteré de un proyecto llamado DrumBeat.
Es realmente interesante: Basandose en el objetivo de Mozilla de mantener y ayudar a que la web sea cada vez más abierta, lo que proponen es un sitio donde se agrupan proyectos, ideas, sobre cosas que ayuden a que esto pase, es decir, a que la web sea cada vez más abierta.
Pueden ser proyectos de todo tipo, no tiene que ser necesariamente relacionado con programación.
La idea detrás de DrumBeat es conseguir apoyo y financiación de estos proyectos, con el fin de, claro está, concretarlos.
En fin, el día de la charla hubo un brainstorming y, me quedó el tema dando vueltas en la cabeza. En el camino de vuelta, se me ocurrió algo:
Un Python, Client-Side. =)
La idea es, para el desarrollo web, lo que es Server-Side, uno tiene alternativas, entre ellas, python, php, perl, ruby, etc. Pero, para el lado del cliente no hay tantas. Basicamente, javascript y, luego empezar a dar vueltas por soluciones oscuras, plugin-dependientes, etc.
Qué bueno sería tener más lenguajes disponibles para los scripts del lado del cliente, no? Y no sería genial arrancar por (a mi entender) el lenguaje más cómodo, amigable, divertido y, a la vez, poderoso del universo???
Así que armé el proyectito:
Client-Side Python en DrumBeat
Creo que la idea en si, no es mala... Obviamente, lo que necesita es notoriedad!! Por lo que, unos votos no le vendrían nada mal!
Es realmente interesante: Basandose en el objetivo de Mozilla de mantener y ayudar a que la web sea cada vez más abierta, lo que proponen es un sitio donde se agrupan proyectos, ideas, sobre cosas que ayuden a que esto pase, es decir, a que la web sea cada vez más abierta.
Pueden ser proyectos de todo tipo, no tiene que ser necesariamente relacionado con programación.
La idea detrás de DrumBeat es conseguir apoyo y financiación de estos proyectos, con el fin de, claro está, concretarlos.
En fin, el día de la charla hubo un brainstorming y, me quedó el tema dando vueltas en la cabeza. En el camino de vuelta, se me ocurrió algo:
Un Python, Client-Side. =)
La idea es, para el desarrollo web, lo que es Server-Side, uno tiene alternativas, entre ellas, python, php, perl, ruby, etc. Pero, para el lado del cliente no hay tantas. Basicamente, javascript y, luego empezar a dar vueltas por soluciones oscuras, plugin-dependientes, etc.
Qué bueno sería tener más lenguajes disponibles para los scripts del lado del cliente, no? Y no sería genial arrancar por (a mi entender) el lenguaje más cómodo, amigable, divertido y, a la vez, poderoso del universo???
Así que armé el proyectito:
Client-Side Python en DrumBeat
Creo que la idea en si, no es mala... Obviamente, lo que necesita es notoriedad!! Por lo que, unos votos no le vendrían nada mal!
sábado, 21 de agosto de 2010
VbAutodoc: Auto documentando VB
Qué lindo sería contar con una herramienta que, lea el código fuente (en este caso en VB) y me arme un archivo de documentación sobre las funciones y sub rutinas (preferentemente en html).
Cómo soy programador y me gusta python =) decidí hacerla. La bautizé vbautodoc (muy original) y está disponible una muyprecoz temprana versión.
Próximamente, voy a mejorar aspectos en cómo se construyó, por ejemplo, el pedazo de html que uso como base, lo metí dentro del código, y sólo funciona para documentar VB, cuando, si se parametriza podría servir para cualquie lenguaje.
Web del proyecto
Descargas
Cómo soy programador y me gusta python =) decidí hacerla. La bautizé vbautodoc (muy original) y está disponible una muy
Próximamente, voy a mejorar aspectos en cómo se construyó, por ejemplo, el pedazo de html que uso como base, lo metí dentro del código, y sólo funciona para documentar VB, cuando, si se parametriza podría servir para cualquie lenguaje.
Web del proyecto
Descargas
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.
domingo, 13 de diciembre de 2009
Octopys: Octopus para linux
Algún día prometí que iba a hacer una versión de octopus para linux, y cumplí. Por lo menos, ya hace algo, habrá que pulirlo un poco, lógicamente.
Está escrito en Python, con una GUI en Qt y lo pueden descargar desde acá.
O, pueden mirar el código directamente gracias a pastebin:
main.py
oct.ui
octo.py
Está escrito en Python, con una GUI en Qt y lo pueden descargar desde acá.
O, pueden mirar el código directamente gracias a pastebin:
main.py
oct.ui
octo.py
jueves, 15 de octubre de 2009
CodMACs/Python
Finalmente, subí a code.google la primera versión de CodMACs (implementación escrita en python) la pueden bajar desde acá.
El zip tiene clave. La idea es tener un poco de control sobre quién bajó el script. Todavía no estoy utilizando el sistema de control de versiones que provee google.
Quién desee la clave, me puede enviar un mail a mi dirección hosteada en gmail: martincerdeira.
Edito:
Nuevo blog dedicado: http://www.codmacs.blogspot.com/
El zip tiene clave. La idea es tener un poco de control sobre quién bajó el script. Todavía no estoy utilizando el sistema de control de versiones que provee google.
Quién desee la clave, me puede enviar un mail a mi dirección hosteada en gmail: martincerdeira.
Edito:
Nuevo blog dedicado: http://www.codmacs.blogspot.com/
Suscribirse a:
Entradas (Atom)
Entradas
