Las 10 mentiras preferidas de los programadores
The top ten lies of engineers.
Debo reconocer que yo abuso de la 3 y la 7. Sobre todo de la 3...
« Marzo 2006 | Inicio | Mayo 2006 »
The top ten lies of engineers.
Debo reconocer que yo abuso de la 3 y la 7. Sobre todo de la 3...
We have to resist the urge to use Ajax for every interaction, just because it's cool.
La frase está copiada de un post de Pete Forde en unspace. Cambien ustedes Ajax por Flash, y tendremos una frase exactamente igual de válida.
Es nuestra responsabilidad como desarrolladores el implementar la mejor solución posible para el problema con el que nos encontremos. Y normalmente, la búsqueda de esa solución no debería nacer con limitaciones debidas a las preferencias personales del desarrollador.
Pero eso es válido tanto por exceso como por defecto. Al igual que "hagámoslo en flash" o "hagámoslo con mucho Ajax" no puede ser una solución por defecto, tampoco puede serlo "hagámoslo todo en HTML puro y duro, sin nada más". Si fuera así, nunca hubiéramos pasado del H1 nativo del navegador y del <blink> En parte gracias a que alguien tuvo la inquietud y las ganas de ir contra los postulados de cierto gurú de la usabilidad, hoy por hoy tenemos CSS, y podemos separar datos y presentación en una web.
Sirva como ejemplo este otro artículo del mismo autor en la misma web. El negarse a que lo que aparentemente es un muro insalvable (el hecho objetivo de que no todos los navegadores pueden mostrar contenido basado en JavaScript, o que el usuario puede haber capado el uso de controles ActiveX) suponga que sea imposible implementar una aplicación es lo que hace avanzar los desarrollos de software, la tecnología, y si me apuran, el mundo.
Pero para poder buscar soluciones imaginativas a los problemas, hay que tener imaginación. Lo que en el caso de un programador suele significar, en realidad, tener la capacidad de pensar de forma diferente a la que piensan todos los demás, tener una forma de actuar basada, no en recitar el "manual" o la API de su lenguaje de elección como un mantra, sino en cuestionarse siempre la solución que está adoptando, intentando asumir sus puntos débiles.
En realidad las mejores soluciones no provienen de los "gurús" de una plataforma, sino de la persona que es capaz de ver las cosas sin las orejeras que proporciona la vinculación emocional a un lenguaje. Véase, sin ir mas lejos, el ejemplo del link anterior. A veces las cosas son tan sencillas como eso. Basta con mirar el problema con ojos neutros, identificar los riesgos, encapsularlos y aislarlos lo más posible, y atacar el problema con desapasionamiento tecnológico.
Entre otras razones, porque esto, como tantas otras cosas, también va por modas. Hace cinco o seis años todo el mundo salía en desbandada del JavaScript, y pretendía colar como la mejor solución posible el hacer aplicaciones web basadas en applets. Posteriormente la solución a todos los problemas era el asp, con querys sql construídas en la misma página en la que se realizaba la presentación. Después fue flash, después los frameworks java, y ahora otra vez JavaScript. Y en cada paso, se demonizaba el paso anterior.
Ni la combinación XHTML+CSS es la solución a todos los problemas, ni lo es el uso masivo de flash, ni lo es el último framework de moda. Es la combinación de todas las soluciones posibles, y la utilización inteligente y objetiva de todas las herramientas que tenemos a nuestro alcance la que nos permitirá implementar aplicaciones cada vez más complejas, mejor estructuradas, más fáciles de mantener, y más agradables para el usuario, tanto desde un punto de vista estético como de usabilidad.
Rather than simply stating what we've done and how we did it, we feel compelled to puff it up into a spiny, intimidating best practice. We attach our egos to our code frameworks. If someone doesn't agree with our approach, they're attacking us personally. If someone has a different best practice, they're amateurs who don't understand the problem domain.
Suena conocido, ¿no?. Es una cita sacada de un post en codinghorror, que por cierto es uno de los blogs de referencia de la casa, y que hace clara referencia a la tendencia existente en el mundo del desarrollo de software a no aceptar como válida ninguna solución que no haya propuesto uno mismo, por un lado, y por otro, de llevar a extremos casi de fe religiosa la militancia en una tecnología.
Para cada problema suele haber una solución. Es muy difícil asumirlo, pero es parte de la obligación de un buen programador el saber reconocerlo, y hacer todo lo posible para conocer tanto el mayor número de soluciones posibles, como el tener un mínimo conocimiento sobre el alcance y ventajas de las mismas.
Por cierto, yo seguiría todos los links del post enlazado, hay algunos, como el que apunta a Creating Passionate Users, impagables.
Aquí tienen una clase para animar, hacia adelante o hacia atrás, en loop o con una sola repetición, un movieclip de forma procedural.
Para utilizarla, se le debe pasar como parámetro al constructor una instancia de un movieclip. A continuación, se debe llamar a un método play, que acepta como parámetros tres posibles constantes declaradas en la clase. Ej:
var animator: MCAnimator = new MCAnimator( nombreInstancia );
//Sin repetición, hacia adelante
animator.play( MCAnimator.FORWARD );
//En loop hacia atrás
animator.play( MCAnimator.BACKWARDS | MCAnimator.LOOP );
La cosa no tiene mucho misterio, al menos en Mac OS X. Basta con iniciar sesión de Terminal y escribir:
sudo gem install rails --include dependencies
En MacProgramadores.org acaban de publicar lo que han llamado un "tutorial" (aunque un documento de 152 páginas dificilmente se puede llamar así) sobre las herramientas de programación de GNU. Aunque el documento está escrito desde el punto de vista de un usuario de Mac OS X, es bastante neutro en lo referente a la plataforma, por lo que puede ser igual de útil para los usuario de Linux, FreeBSD o Windows.