No hay mucho más que comentar, hay que ver el link =)
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, 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!
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, 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.
Suscribirse a:
Entradas (Atom)
Entradas
