Categoría: Programacion
Turista del software

1. You will not speak their language even though they will probably speak English.
(no hablas su idioma aún cuando ellos probablemente hablen inglés)
2. You will not be able to locate their country on a map even though they could probably name all 50 states.
(no podrías ubicar su país en el mapa aunque ellos probablemente puedan nombrar los 50 estados)
3. You won’t know who their national leader is even though they will not only tell you the name of our President, but also give you a nice summary of his foreign policy exploits over his last two terms in office.
(no conoces a su presidente aunque ellos no sólo te diran el nombre de tu presidente si no que harán un lindo resumen de tu política internacional durante los dos últimos gobiernos)
Y según él les pasa lo mismo cuando son developers de .NET y ven al resto de los lenguajes y sistemas desde una total ignorancia. Y lo dice siendo él el programador de .NET y norteamericano, es decir, que se ofendan sus propios compañeros en tal caso.
Lo interesante del caso es que él quiere empezar a conocer todo el resto del ecosistema y piensa cambiar esa forma de ver el mundo. Interesante y positiva, pero a mi me divirtió la comparación. Hace poco había discutido con uno fanático de .NET y él decía "para mi no hay nada que se tenga que hacer con otra cosa que no sea .NET" y yo le repliqué "me acabás de demostrar que sos un mal programador", se ofendió (Si Manu, fuiste vos!



Después Russell tiene un post como turista en Ruby On Rails, interesante para ver desde su punto de vista

PHP Cheat Sheet
Completo cheat sheet de referencias para programadores de PHP bastante útil a la hora de querer recordar cómo trabaja alguna función, etc.
Importar una base UTF-8

En mi caso la migración ni se sintió salvo por el tema de las fechas, servidores con una fecha pasando a otro con otra fecha, generó un poco de conflicto, pero fue todo "sin grandes problemas"
Ahora bien, el tema de la codificación es un martirio, unas fechas se arreglan, pero que te rompan todas las tildes y eñes es un dolor de huevo (si, literal), y noto que cada vez que alguien quiere migrar algo, revienta.
Posibles causas: MySQL Server, MySQL Client, Phpmyadmin
Cuando uno exporta una base de datos, habitualmente comprimida para que no pese mucho y la quiere subir a otro server, la codificación es lo que complicará las cosas.
Lo que descrubrí es muchos servers que tienen estas tres aplicaciones configuradas distinto, ejemplo. El server por default utf-8, el cliente latin1 (ISO), listo, cóctel para el desastre.
En el caso de anoche, ayudando a un amigo con su blog, teniendo la base creada en UTF 8 volvía una y otra vez a reventar los caracteres. Resulta que el cliente de mysql estaba en Latin1, así que por SSH más o menos logré cargar la base así:
gunzip < archivo.sql.gz | mysql -u usuario -p --default-character-set=utf8 base_destino
(el Gunzip es porque lo estaba sacando desde un archivo comprimido)
La cuestión está en --default-character-set=utf8 , esto le obliga a usar una codificación que queramos y no la que tiene por default.
Esto no te lo explican casi en ningún lado, jeje, pero está bueno saberlo, te puede salvar el día y ahorrarte horas y horas de dolor de cabeza.
El PHP My Admin tiene el problema que exporta como dice el cliente de MySQL y confunde como dice el server de MySQL, así que es muy factible exportar el archivo .sql con errores o, lo que es peor, ya sin una codificación correcta, una conversión de conversión que directamente arruina TODOS los caracteres y no hay forma de resolverlo. Así que primero revisen bien el archivo generado (sea ISO o UTF-8), que lo puedan abrir en alguno de esos modos y recién después lo importan.
Otro detalle: no hay ningún encabezado que nos diga si un tipo de caracteres es uno o el otro, se van a dar cuenta por los erroes agregados

Y para completar: en estos días migran mi base de datos también


PS: post auspiciado por el famoso gato
Pequeña actualización del blog

Editando el perfil se pueden agregar algunas cosas más como también una pequeña descripción de ustedes mismos, la idea es, con el tiempo, ir armando una pantallita donde cada usuario pueda compartir la información de sí mísmo que considere interesante o pertinente. Probablemente no les sirva demasiado si no son de frecuentar el blog o si no tienen usuario registrado, pero para los que postean aquí o los que pasan muy seguido, puede servirles de "conector" entre sus trabajos-vidas sociales habituales y otros lectores del blog.
Sigue funcionando el visor de usuarios online (medio como el culo




Los mails aparecerán solamente para otros usuarios registrados y logueados, esto veré si lo modifico en algún momento, pero por ahora está así "oculto" sólo logueado se pueden ver. Lo mismo para el listado de usuarios. Es que no creo que todos quieran que los anónimos visitantes vean que estan registrados aquí, así que sólo usuarios logueados pueden ver el listado de miembros.
¿y que pasó con el registro? ¿porqué está cerrado? lamentablemente no me venía funcionando el sendmail (la función que envía mails del servidor) así que deshabilité el sistema de registro por un rato, ya le daré más foco a ello, pero si alguno está desesperado y cree que la solución del alargamiento peneano está en registrarse en este blog, bienvenido sea, me envía un e-mail y armamos su cuenta

Es tan sólo experimental y para que lo use quien quiera, se aceptan sugerencias de que otros sistemas linkear (hasta ahora sólo puse a Flickr como ejemplo), total... como mucho me lleva 20 años programando resolver todos los caprichos

Y no, esto tampoco entra en el PostRev 0.7 que durante esta semana sale la versión final luego de los últimos detalles que me pasaron Zurdito y GFer, mis "betatesters"

Ahora bien, da un blog para ser un nodo de una red social? pregunta para bloggers 2.0, yo sigo siendo 1.0, pero esa es ya otra historia

Salida a producción a destiempo
Artículo techie-programador-nerd, no se quejen que hace rato que no sale uno de estos

Un caso muy particular está sucediendo con KDE4 y es que los desarrolladores estan por lanzarlo en una semana sin haberlo terminado. La excusa es "KDE4 no es KDE 4.0", como queriendo decir que cambia de versión pero todavía falta mucho para ser lanzado.
Esto puede sorprender a muchos que no son usuarios típicos de software libre, donde cada versión es un misterio si funcionará como queremos salvo en casos puntuales como Apache, Tomcat, MySQL, PHP y Firefox, el resto tiene esa tendencia de lanzar versiones que no estan al 100%. Otros dicen que no existe software terminado, que nunca se termina.

Microsoft lanzó Windows Vista y se habló desde un principio que todos los problemas estarían resueltos en el primer SP1 (Service Pack), es decir, comprás un software de 400u$s para enterarte que no está terminado y en un año lo verás funcionar correctamente. No es precisamente algo que el público quiere oír, ni menos hacer, instalar un parche gigante para algo que hoy debería funcionar bien.
"Release often and release early!" -Eric S. Raymond/Cathedral Bazaar
Para el "usuario final" no hay diferencias entre KDE4 y KDE 4.0, para los developers si, y es un error importante el no poder mirar desde el punto de vista del usuario final. Si creaste tantas expectativas con un proyecto y una fecha, o cumplís o admitís que no estas a la altura de dicha fecha/promesas, pero lanzarlo igual "total, que puede pasar...", es casi una burla a su propio trabajo... ¿o no?

Está el ejemplo de Valve que lanzó su plataforma Steam cuando era un desastre y la fue emparchando hasta que más o menos estuvo pulida, para ese entonces Half Life 2 estaba siendo desarrollado y lanzaron esta plataforma para forzar a los jugadores de Counter Strike, Half Life y Day of Defeat a comprar licencias y dejar de usar los "truchos". Estuvieron meses lanzando parches que, para colmo, debían ser bajados por el mismo sistema y se tomaba todo el tiempo del mundo.
Al lanzamiento del Half Life 2, cualquier error en el soft, se bajaba otro parche enorme, es decir, ni el mismo juego era un release final, era un beta eterno.
Casi como Google que acostumbra lanzar todo en beta, ellos te dicen eso y se libran del problema de que el software esté incompleto o falle, es beta, jodete. Pero KDE4 no es beta, es KDE4, que no es 4.0, pero para la mayoría eso no es una diferencia.

Por otra parte, y volviendo al caso de KDE 4, parece que la presión de SUSE es la que obligó a estas fechas, en vez de aplazar una vez más el lanzamiento, algo razonable debido al estado de algunas partes del software, hay que cumplir con una fecha específica, algo que no suena muy coherente en, justamente, el ambiente del software libre.
Por mi parte saben muchos que soy usuario de KDE, así que no escribo esto de criticón, se que los usuarios de Gnome dejarán comentarios diciendo lo maravilloso que es y un largo etcétera de cosas que no tendrán nada que ver con el artículo, la cuestión aquí es otra y mucho más importante. ¿cuanto está afectando al software libre o abierto esta tendencia de lanzamientos incompletos? porque pocos se salvan de semejante problema y falta de QA a la hora de lanzar versiones y, peor, utilizando excusas constantemente para deslindar responsabilidades.
¿No es más fácil decir que está incompleto y ya?
Iconos en links usando CSS
Hay una propiedad de CSS que no conocía, hasta ver este mini tutorial, que permite agregarle íconos a los links respectivos a la extensión del archivo:
a[href *="flickr.com/photos/"], a[href *="zooomr.com"], a[href *="imageshack.us"], a[href *="bubbleshare.com"], a[href *="sevenload.com/bilder/"] {
padding: 5px 20px 5px 0;
background: transparent url(icons/icon_pic.gif) no-repeat center right;
}

Se le puede asignar a cada enlace con una o más extensiones una imagen para imprimir y que se vea como en la imagen de ejemplo, tampoco es necesario agregarlo para todos, sólo las extensiones que nos interese, una entrada en el CSS y listo!
me pareció una excelente forma de aclarar los links a archivos, más aquí donde está el archivo CSS y las imagenes para descargarse.
12 señales de que eres un mal programador


1. Java es todo lo que necesitas.
No ves la necesidad de usar ningún otro lenguaje, ¿por qué no se puede hacer todo con Java? No te importa ver código en Python o Ruby que logra en 10 lineas lo que llevaría varias hojas de código Java. Además, seguramente las nuevas características de la próxima versión del lenguaje lo arreglaran de todas formas. (Esto es aplicable a casi cualquier lenguaje, pero ocurre que entre la comunidad Java parece estar más extendida esta forma de pensar)
2. El término "enterprisey" (NT: se trata de un término sarcástico utilizado para designar productos complejos más allá de lo necesario) no te suena a broma.
"Enterprise" no es sólo una palabra, es una filosofía, una forma de vida, un camino a la iluminación. Cualquier cosa que pueda ser escrita, desplegada o actualizada con un trabajo mínimo es descartada como un juguete que no "escalará" para futuros usos. Mientras tanto la mayor parte del trabajo real en tu oficina se hace enviando hojas de cálculo en Excel mientras esperan a que termines de construir tu nueva visión corporativa.
3.Te opones férreamente a las funciones/métodos de más de 20 líneas de código.
(o 30 o 10 o cualquier otro número) Lo siento, algunas veces una función larga es justamente lo que necesitas. Normalmente las funciones cortas son más sencillas de entender, pero algunas veces se pueden expresar más fácilmente en una sola función más larga. El código no debería hacerse más complejo sólo para adecuarse a criterios arbitrarios.
4. "¡OH DIOS MÍO! ¡PATRONES!"
Los desarrolladores que buscan constantemente la forma de aplicar patrones a cualquier problema de código con el que se encuentran están añadiendo una complejidad innecesaria. Lejos de ser algo que busques, deberías sentirte mal cada vez que tienes que utilizar un patrón de diseño, significa que estás escribiendo código que hace las cosas más complicadas y que puede ser de dudosa utilidad. Pero, ¡ey!, tu código tiene patrones, bien por ti.
5. Los ciclos de CPU son un recurso precioso y tu estilo de programación y lenguaje reflejan esas creencias.
Hay montones de problemas en los que tienes que tener muy en cuenta el consumo de CPU (modelado/simulación, procesado de señales, kernels de sistemas operativos, etc), pero no es tu caso. Para la mayor parte de los desarrolladores de software sus principales problemas de rendimiento están relacionados con las bases de datos y la entrada/salida. El único efecto de optimizar tu código para mejorar el uso de CPU será disminuir en 2 milisegundos el tiempo necesario para la próxima consulta a la base de datos. Mientras tanto el desarrollo de la aplicación se hace más lento, no puedes hacer frente a los nuevos requerimientos y te encuentras con problemas serios de calidad. Pero al menos estás ahorrándote montones de ciclos de CPU… eventualmente.
6. Piensas que ninguna función/método debería tener más de un return.
Esta la he oído alguna que otra vez, y normalmente la razón que me dan es que el código es más sencillo de analizar. ¿Según quién? Yo encuentro más fácil de leer un código más simple, y normalmente el tener más de un return simplifica el código.
7. Tus usuarios son estúpidos. Realmente estúpidos.
Simplemente no puedes creer lo estúpidos que son, olvidándose constantemente de hacer las cosas más sencillas del mundo y cometiendo errores tontos al usar tu aplicación. Nunca has considerado que quizás es tu aplicación la que es estúpida porque eres incapaz de escribir software decente.
8. Te enorgulleces enormemente del gran volumen de código que escribes.
Ser productivo es bueno, desafortunadamente escribir montones de líneas de código no es lo mismo que ser productivo. Los usuarios nunca comentan "Guau, este programa puede ser difícil de usar y estar lleno de errores, pero al menos sé que hay un montón de código por debajo." En lugar de ser productivo, generar toneladas de mal código retrasa a los demás desarrolladores y en el futuro su mantenimiento constituirá una pesada carga.
9. Copiar y pegar es genial, te ayuda a escribir código desacoplado.
Defiendes tu uso del copy paste con extraños argumentos sobre desacoplar código y eliminar dependencias, mientras ignoras el aumento del tiempo de mantenimiento y los problemas de duplicación de errores. A esto se le llama "racionalizar tus acciones".
10. Piensas que la gestión de errores consiste en capturar todas las excepciones, registrarlas, y continuar como si nada.
Eso no es gestionar errores, eso es ignorar errores y es el equivalente semántico al "on error next" de VB. Sólo porque hayas registrado el error en algún sitio no significa que lo estés tratando. Tratar errores es algo duro. Si no sabes qué hacer exactamente cuando te encuentras con un cierto error, simplemente deja que la excepción se propague y que un nivel más alto del código lo trate.
11. Modelas todo tu código en UML antes de escribirlo.
El modelado entusiasta de UML se lleva a cabo normalmente por aquellos que no escriben demasiado código, sino que se consideran arquitectos de software. Las herramientas de modelado atraen más a aquellos que piensan que el código se puede escribir en una sala de conferencias manipulando pequeños gráficos. Los gráficos no son el diseño, y nunca serán el diseño, para eso está el código.
12. Tu código borra datos importantes.
Escribiste un cierto código que se supone que debe sobrescribir los archivos de la aplicación con otros nuevos, pero se vuelve loco y borra todos los datos del usuario.
Leyendo varios de estos recuerdo cuantas veces discutí con fanáticos por puntos como el 1 o el 4

Vía MundoGeek que lo tradujo, del original de Damien Katz, gracias a la fuente (!).
Buscando programador Java para móviles
Así rapidito y sencillo, ando necesitando consultoría de un developer de aplicaciones JAVA para teléfonos móviles, no es para mí pero aprovecho por aquí para buscar, por ahí uno me lee
No es para juegos, es para una aplicación offline-online, Java obviamente. Interesados escriban a fabiomb(arroba)gmail.com
El bot atacando infraganti
Me puse a ver las visitas online que había hace un ratito, y una de las particularidades de dicho script es que me dice que sección estan visitando en ese momento, como un log, para ver donde está cada uno en ese momento o que noticia se está viendo.
Muchas veces me encuentro con los spiders de Google o MSN inspeccionando el sitio, o con usuarios de este mismo blog, pero hoy me encontré con uno muy particular que decía algo así:
Anónimo 211.43.222.218 66 seg
http://www.fabio.com.ar/verpost.php?id_noticia=http://sabo.i-s-o.net/.
libwww-perl/5.65
¿libwww-perl? eso no es un browser, ¿pasar una url como variable? papito, eso todavía funciona pero fue cochino de tu parte
Y si, me encontré con varios intentos de XSS (Cross-site Scripting), pero lo más interesante del caso es que proviene de múltiples IPs, es obvio que alguien está queriendo divertirse con este blog con unos lindos proxys de por medio para que no lo agarre y es muy probable, también, que lo esté haciendo con un bot que hace todo esto por él (lammer)
Día del programador
Dicen que hoy es el día "no oficial" del programador, si, el día 256 del año (salvo que sea bisiesto, claro) así que, aunque no sea un día oficialmente reconocido, feliz día a todos los que disfrutan del código.
Alguno tiene más info del tema? alguna web que quiera imponerlo como fecha oficial? algo más o menos actualizado?
A todo esto, y como programador lo digo, el imbécil (se sintió dolido, dice) de "Chabacano", ese usuario de Wikipedia español que me persigue y me baneó sin mediación alguna, ahora quiere borrar mis artículos en wikipedia en inglés ¿alguien con ganas de ayudar por mi lado? porqué no se dedica a borrar los de Jacobo Winograd?
Actualizado: Ahí ta, lo encontré Programmer Day