Tuesday, July 28, 2009
Traduccion de +14,000 terminos tecnicos
Hoy salio en twitter el tema de la traduccion de terminos tecnicos, de hecho hasta decidimos crear una pagina con terminos tecnicos comunes, la cual pueden encontrar aca: Traduccion de terminos
Despues recorde que por algun lado habia yo visto un archivo excel publicado por Microsoft que contenia traducciones de muchos terminos en ingles, la traduccion no solo es al Español, sino a unos 45 idiomas
bastante util el archivito, lo pueden encontrar aqui: Microsoft Terminology
Este post es traido a ustedes por: Un-post-mas-para-servir-de-futuro-recordatorio
Friday, July 17, 2009
Como guardar archivos .GIF desde MS Outlook
Por alguna razon MS Outlook no tiene una
Les menti en el titulo, si hay forma de guardar archivos .GIF desde MS Outlook, pero por los pasos requeridos mejor no me meto ahi, pero les dire que hay una forma mucho mas facil de hacerlo, solo tienes que enviarte el mensaje a una cuenta de web email, como GMail, Yahoo o Hotmail (que conste que no he probado en Yahoo ni Hotmail, pero creo que funciona ahi tambien)
Una vez que lo abras en tu correo web lo podras guardar normalmente como uno esperaria que se puede hacer, dando click derecho en la imagen, guardar como... y ya esta
Labels:
MS Outlook,
tips,
trucos
Wednesday, July 15, 2009
Estas cansado de XML? yo tambien. proyecto JINI.
Nunca me ha gustado XML, lo he odiado desde "el primer dia", pienso que el formato es demasiado ineficiente, demasiado inflado; He tenido algunas ideas sobre que se puede hacer para reducir el tamaño de archivos xml, tal como tener una cabecera con la definicion de la estructura y otras dias, pero el punto de este post no es hablar sobre esas ideas, sino de mi propuesta para comenzar a dejar de usar XML.
Un area en que XML me parece particularmente molesto es en los archivos de configuracion, y mi propuesta para atacar este problema consiste en formalizar un nuevo formato que por ahora llamo JINI. JINI es un subconjunto de JSON similar a los viejos archivos .ini en simplicidad y es usado especificamente para configuracion para reemplazar todos esos archivos app.config
Beneficios
- Simple
- No mas <>
- Simple
- mas corto
- mas facil de leer
- Mas Simple
- Todo lo que se puede expresar en XML, se puede expresar en JINI, pero es mas simple
Lo malo es que "jini" ya esta tomado (segun los 2 millones de resultados en Google y 714K Bing)
Pense que la idea ya se le habia ocurrido a alguien pero una busqueda rapida me dio cero resultados, asi que pense que seria bueno sacar la idea y ver que opinan al respecto
nota: me comentaron sobre YAML, pero no me convence mucho
que piensan de la idea? son felices con XML?
Un area en que XML me parece particularmente molesto es en los archivos de configuracion, y mi propuesta para atacar este problema consiste en formalizar un nuevo formato que por ahora llamo JINI. JINI es un subconjunto de JSON similar a los viejos archivos .ini en simplicidad y es usado especificamente para configuracion para reemplazar todos esos archivos app.config
Beneficios
- Simple
- No mas <>
- Simple
- mas corto
- mas facil de leer
- Mas Simple
- Todo lo que se puede expresar en XML, se puede expresar en JINI, pero es mas simple
Lo malo es que "jini" ya esta tomado (segun los 2 millones de resultados en Google y 714K Bing)
Pense que la idea ya se le habia ocurrido a alguien pero una busqueda rapida me dio cero resultados, asi que pense que seria bueno sacar la idea y ver que opinan al respecto
nota: me comentaron sobre YAML, pero no me convence mucho
que piensan de la idea? son felices con XML?
Labels:
xml
Tuesday, July 14, 2009
La programacion es como un juego de ajedrez
Por mucho tiempo he pensado que el desarrollo de software es como un juego de ajedrez, pero aparentemente nadie ha hecho esta analogia antes, solo basta *bingearlo* para ver que hay exactamente (al tiempo de escribir este post) cero resultados (los mismos resultados en Google), afortunadamente esta situacion esta a punto de revertirse al tiempo que escribo este post y todo mundo vee la luz... o talvez no
Y bien, permitanme explicarles un poco sobre mi analogia
El programador mediocre
Uno podria argumentar que este es el programador promedio, pero eso es otra historia, este hace un movimiento sin pensar en los efectos secundarios, su capacidad de analisis es muy poca, hay tantos efectos secundarios (introducir nuevos bugs, seguridad, etc) pero este jugador ni siquiera esta enterado de ello, basicamente se basa en el debugueador y si corre en su maquina entonces esta listo; cuando las cosas inevitablemente no funcionan en produccion el simplemente hace otro movimiento que parece corregir el problema, este ciclo es frecuentemente repetido, si le das un proyecto grande a este tipo muy seguramente hara un movimiento estupido que resultara en Jaque Mate en el proyecto
El buen programador
Este analiza diferentes rutas y escoge la que cree adecuada, este jugador puede hacer un buen juego, de vez en cuando su analisis falla y comete algunos errores, pero el puede aprender de estos, este tipo normalmente entrega buen software con pocos errores que puede corregir rapidamente sin muchos problemas
El mejor
Genio, Guru o como quieras llamarle, este tipo puede hacer una gran cantidad de movimientos rapidamente, y todo en su cabeza, esta informado siempre de las mas recientes tecnicas para vencer a su oponente, pero no cae en el error de simplemente usarlas en su juego, sino que las prueba primero en sus proyectos privados y una vez que el mismo comprobo que son utiles entonces las usa en proyectos reales, conoce las tecnicas mas rapidas, cortas y que le dan el mayor beneficio, sabe las tecnicas para usar en los proyectos pequeños y las que debe usar en proyectos grandes, y sabe tambien que son muy diferentes, este jugador sabe lo que el oponente esta pensando, sabe como respondera el oponente a cada uno de sus movimientos asi que escoge cuidadosamente el mejor movimiento, este jugador conoce los efectos secundarios; las palabras "funciona en mi maquina" no estan dentro de su vocabulario.
Como podran ver las diferencias principales en mi analogia son la capacidad de analisis (seleccionar el movimiento) y los efectos secundarios (que pasa despues de hacer el movimiento). El oponente es tu proyecto de software, el movimiento es escribir el codigo, los efectos secundarios son todo lo demas que es afectado por este.
Cuando fue la ultima vez que creaste un nuevo bug cuando arreglabas aquel otro o agregabas funcionalidad a tu applicacion? o cuando *ellos* encontraron errores en la aplicacion justo despues de lanzarla a produccion? o cuando funciono en tu maquina pero no en el servidor?
Cada vez que vas a hacer un movimiento, detente un momento y piensa en los efectos secundarios, siempre hay efectos secundarios, si no puedes identificarlos, hay herramientas que te pueden ayudar a pensar, como las pruebas unitarias, y entre mas lo practiques, mejor jugador seras, y eso es una promesa
Y bien, permitanme explicarles un poco sobre mi analogia
El programador mediocre
Uno podria argumentar que este es el programador promedio, pero eso es otra historia, este hace un movimiento sin pensar en los efectos secundarios, su capacidad de analisis es muy poca, hay tantos efectos secundarios (introducir nuevos bugs, seguridad, etc) pero este jugador ni siquiera esta enterado de ello, basicamente se basa en el debugueador y si corre en su maquina entonces esta listo; cuando las cosas inevitablemente no funcionan en produccion el simplemente hace otro movimiento que parece corregir el problema, este ciclo es frecuentemente repetido, si le das un proyecto grande a este tipo muy seguramente hara un movimiento estupido que resultara en Jaque Mate en el proyecto
El buen programador
Este analiza diferentes rutas y escoge la que cree adecuada, este jugador puede hacer un buen juego, de vez en cuando su analisis falla y comete algunos errores, pero el puede aprender de estos, este tipo normalmente entrega buen software con pocos errores que puede corregir rapidamente sin muchos problemas
El mejor
Genio, Guru o como quieras llamarle, este tipo puede hacer una gran cantidad de movimientos rapidamente, y todo en su cabeza, esta informado siempre de las mas recientes tecnicas para vencer a su oponente, pero no cae en el error de simplemente usarlas en su juego, sino que las prueba primero en sus proyectos privados y una vez que el mismo comprobo que son utiles entonces las usa en proyectos reales, conoce las tecnicas mas rapidas, cortas y que le dan el mayor beneficio, sabe las tecnicas para usar en los proyectos pequeños y las que debe usar en proyectos grandes, y sabe tambien que son muy diferentes, este jugador sabe lo que el oponente esta pensando, sabe como respondera el oponente a cada uno de sus movimientos asi que escoge cuidadosamente el mejor movimiento, este jugador conoce los efectos secundarios; las palabras "funciona en mi maquina" no estan dentro de su vocabulario.
Como podran ver las diferencias principales en mi analogia son la capacidad de analisis (seleccionar el movimiento) y los efectos secundarios (que pasa despues de hacer el movimiento). El oponente es tu proyecto de software, el movimiento es escribir el codigo, los efectos secundarios son todo lo demas que es afectado por este.
Cuando fue la ultima vez que creaste un nuevo bug cuando arreglabas aquel otro o agregabas funcionalidad a tu applicacion? o cuando *ellos* encontraron errores en la aplicacion justo despues de lanzarla a produccion? o cuando funciono en tu maquina pero no en el servidor?
Cada vez que vas a hacer un movimiento, detente un momento y piensa en los efectos secundarios, siempre hay efectos secundarios, si no puedes identificarlos, hay herramientas que te pueden ayudar a pensar, como las pruebas unitarias, y entre mas lo practiques, mejor jugador seras, y eso es una promesa
Labels:
analogias,
literatura de software
Subscribe to:
Posts (Atom)