7 reglas para realizar Javascript de calidad

junio 19, 2009

Siete consejos para realizar un javascript de calidad y no intrusivo:

  • No hagas suposiciones: no pienses que el usuario tendrá el javascript activado o que usará un navegador adecuado.
  • Usa IDs y relaciones entre elementos: para no depender de un HTML mal estructurado y que el javascript sea imposible de realizar, utiliza IDs para acceder a los elementos con los que se quiere tratar y busca elementos que faciliten acceder a otros elementos.
  • Utiliza estilos: en vez de modificar los estilos de los elementos HTML mediante Javascript, usa clases CSS que modifiquen los estilos, y mediante Javascript se le puede añadir la clase a un elemento superior.
  • Comprende el navegador y a los usuarios: debes pensar cómo funciona un navegador, no sobre saturar su comportamiento (abuso de drag&drop, eventos, …). Además debes pensar qué espera el usuario que haga el navegador, y respetarlo.
  • Comprende los eventos: los eventos no solo corresponden a un objeto, sino a los elementros hijo que contiene. Así se pueden realizar eventos sobr un único elemento y no tener que modificar los demás.
  • Respeta el código de otros: seguro que a parte de tu código existe algún otro que has añadido, por lo que deberás programar teniendo en cuenta que hay que evitar conflicto entre funciones.
  • Después de ti vendrá otro: es muy frecuente que alguien acabe modificando tu código, ten un poco de consideración por los demás y escribe código legible y entendible.

The seven rules of Unobtrusive JavaScript

Vía / @dcedilotte

Anuncios

Guía para desarrollar Javascript accesible

junio 8, 2009

Interesante tutorial que nos enseña que problemas pueden encontrarse las personas con alguna discapacidad que le obligue a prescindir de Javascript (o usuarios con dispositivos móviles), y cómo solucionarlo.

Los mayores problemas con el que se encuentran las personas que no ejecutan javascript en sus navegadores son en la navegación (menús dinámicos), contenido oculto (accesible mediante Ajax), controles dinámicos (eventos de ratón, drag&drop, …) y confusión (la web está pensada para el uso de Javascript y no usarlo conlleva un contenido inicial deficiente).

Como resumen diría que hay que ofrecer los contenidos sin necesidad de javascript, éste sólo debe ser un apoyo, y que para comprobar si tu web es accesible lo mejor es probarlo inhabilitando el javascript en tu navegador.

Creating Accessible JavaScript

Vía / @maxkuri

Fuente: http://sentidoweb.com/2009/06/04/guia-para-desarrollar-javascript-accesible.php



¿C++ y Java casi muertos?

mayo 11, 2009

FonolaMe gustaría hablar de los legados que nos han dejado C++ y Java. Se menciona muchas veces errores en el diseño de ambos, aunque si hacemos una retrospectiva en forma positiva podemos concluir que los dos lenguajes tuvieron  un papel importante en la evolución de los lenguajes de programación y nos han dejado un legado importante y positivo.

Entonces, ¿no será muy temprano para hablar de sus legados? ¿O quizás pensamos que estos lenguajes están ya en su período de decadencia?

C++

Eckel, un miembro formado de C++ Standadrs Committee recordó la decisión tomada en relación a la compatibilidad con versiones anteriores del lenguaje con C desde el comienzo:

Para comprender porqué el lenguaje puede ser desagradable y complicado, y a la vez contar con un buen diseño, es necesario tener en cuenta la primer decisión de diseño que afecta a todo en C++: compatibilidad con C. Stroustrup deció -y al parecer de forma correcta- que la forma  de hacer que la gran masa de programadores de C cambien a objetos era hacer que eso fuese transparente: permitir que ellos pudiesen compilar sus códigos en C sin tener que cambiarlos para C++.

Mientras que C++ ha tenido éxito en atraer a la mayoría de los desarrolladores de C a C++, la decisión sobre la compatibilidad tiene un severo impacto negativo en la evolución del lenguaje:

Lla compatibilidad con C fue una gran limitación, y siempre ha sido la mayor fuerza de C++ … y su perdición. Eso es lo que ha hecho que C++ fuera un éxito y eso es lo que hizo que fuese complejo de la forma que lo es.

Por ejemplo, reconoce que el operador de sobrecarga es difícil de utilizar en C++:

Quienes no entienden C++ muy bien piensan que la sobrecarga de operadores es muy difícil para que los desarrolladores la usen de forma adecuada. Lo qué es básicamente cierto en C++, porque C++ tiene ambas: reserva de pila y reserva de heap, precisamos sobrecargar los operadores para poder manejar todas las situaciones y no causar pérdidas de memoria. De hecho, eso es difícil.

Por supuesto, estas declaraciones generan un debate. Archilleas Margaritis no cree que la compatibilidad con C sea un problema:

No creo que C++ no tenga un buen diseño debido a la compatibilidad con C. ADA es compatible con C, y es un lenguaje muy bueno, con un fuerte liderazgo de su concepción de ingeniería.

Lo que está mal en C++ es el nivel de compatibilidad de código fuente con C. Para que fuese posible incluir las cabeceras de C, C++ mantiene el sistema preprocesador de C. Esto llevó a una gramática extraña y sin contexto, lo que llevó a una sintaxis extraña que se tiene que mantener compatible con C.

Michele Costabirle considera que una de las fallas de C++ fue la falta de una librería normalizada desde el principio:

Creo que una pesada carga de C++ es la falta de una librería normalizada.

Si recuerdo bien, Stroustroup escribió en “El Diseño y la Evolución de C++”, que dejó de lado una librería normalizada en favor de la herencia múltiple. Creo que hubiera sido más ventajoso de la otra manera.

Se pueden decir muchas cosas respecto a C++, pero una cosa es cierta: C++ llevó a los programadores a subir un más alto en la escalera de la programación.

Java

Hablando de un lenguaje diferente en el mismo tono, Eckel reitera algunos errores de diseño cometidos en Java:

Durante muchos años, la línea del equipo de Java fue “la sobrecarga de operadores es algo demasiado complicado”. Esta y muchas otras decisiones muetran claramente que alguien no hizo la tarea en su casa, y es el motivo por el cual tengo la reputación de criticar muchas decisiones tomadas por Gosling y el equipo de Java. …

Los tipos primitivos “tienen que ser incluidos por eficiencia.” La respuesta correcta sería la de permanecer fiel a “Todo es un objeto” y proporcionar algún truco para realizar actividades de bajo nivel cuando hay una necesidad de eficiencia (lo que es cierto para tecnologías hotspot, que hacen las cosas más eficientes de una manera transparente, como evetuamente ocurriría) . Ah, y de paso no vayamos a utilizar el procesamiento de puntos flotantes directamente para calcular funciones transcedentales (en cambio, eso se hace en el software). …

Cuando escribí acerca de qué tan malo se hizo el diseño de los generics, obtuve la misma respuesta, junto con “tenemos que tener compatibilidad con las (demás) decisiones tomadas en Java anteriormente.” Últimamente cada vez más personas han adquirido experiencia con generics para ver cómo es realmente difícil de utilizar.

Bill Venners recuerda las cosas de manera diferente:

No estoy seguro de cuando me dio la impresión de que la elección de dejar la sobrecarga de operadores de lado fue hecha porque alguien no hizo la tarea en casa. Recuerdo preguntar a Gosling en una de mis entrevistas con él porque estaba dejando la sobrecarga de operadores de lado (no creo que esta pregunta y respuesta acabaran siendo publicada). Lo que él básicamente dijo fue lo mismo que le oí decir en otros contextos: Gosling consideró que el nivel de abuso de la sobrecarga de operadores que él vio en la práctica en otros lenguajes (no estoy seguro de si se estaba refiriendo sólo a C++ pero sin duda incluía a C++) había anulado los beneficios de la misma. Eso es todo. Fue una elección subjetiva de diseño.

James Watson favorece las limitaciones deliberadamente introducidas en Java:

Lo que hizo a Java un lenguaje de fácil adopción fue su simplicidad. Sí, en cualquier lenguaje podemos escribir código que es imposible de mantener, pero tendremos que trabajar duro para hacerlo en Java. Esto es porque no se ofrecen una serie de recursos fáciles de abusar, que otros lenguajes si ofrecen.

Desde una perspectiva individual, esto es terrible. Si no quiero utilizar una funcionalidad no la uso. ¿Quién es Sun para decirme lo que debo o no debo hacer? Pero cuando se considera a todo un grupo de desarrolladores que tienen ideas diferentes spbre lo que es un buen enfoque, el juego cambia. El tener un número limitado de formas de hacer las cosas comienza entonces a tener sentido.

Noel Grandin dijo lo suyo, ampliando aún más el debate incluyendo a nuevos lenguajes:

La mayoría de los otros lenguajes atrayentes como Ruby y Scala nunca serán los principales, y es proque están todos fuertemente sesgados en favor de escribir código, en lugar de leer código.

Java es correctamente equilibrado – Java puede ser expresivo y no tener una serie de funcionalidades legadas, y es muy fácil de averiguar lo que algún código aleatorio está haciendo.

Al final, Eckel habló sobre el legado de Java:

Java acercó el mundo del garbage collection a la mayoría de los desarrolladores, también a las máquinas virtuales y un modelo consistente de manipulación de errores (especialmente, si dejamos de lado las checked exceptions, que es una que puede ser utilizada como he mostrado en Pensando en Java, 4e) . Con todas sus fallas, Java nos elevó a un nivel superior, hasta al punto donde estamos ahora, y listos para lenguajes de niveles más altos.

El factor más positivo es preparar el camino para los lenguajes del futuro:

En cierto modo, C++ fue el lenguaje principal y las personas pensaron que siempre sería así. Muchos pensaron lo mismo respecto de Java, pero Java hizo tadavía más fácil sustituirse a sí mismo, a causa de la JVM. Ahora es posible que cualquiera cree nuevos lenguajes y los ejecute con tanta eficiencia como Java. … …

Y estamos viendo ocurrir esto – con lenguajes de alto nivel como Scala, y con lenguajes dinámicos como Groovy, JRuby y Jython. … …

El beneficio no es intencional, el verdadera brillo o genialidad accidental de Java es que fue creando un camino para su propia sustitución, aunque el propio Java haya alcanzado un punto donde ya no pueda evolucionar. Todos los lenguajes del futuro tienen que aprender de eso: crear una cultura en la que pueda haber refactorización (como Python y Ruby han hecho) o permitir el crecimiento de especies competitivas.

Conclusión

Java encendió muchas controversias cuando apareció, especialmente entre los desarrolladores de C++ y los nuevos desarrolladores de Java. Las voces se han calmado desde entonces, y ahora podemos ver claramente dónde estamos y cuál es el legado dejado por los dos lenguajes.

¿O quizás todavía es demasiado pronto para hablar de su legado? Hablar de “legado” suena como si fuesen lenguajes muertos o lenguajes que están muriendo. ¿Es así? ¿Qué lenguajes evolucionará para reemplazar a C++ y Java? (las opiniones son siempre bienvenidas).

Fuente:http://www.dosideas.com/reflexiones/560-ic-y-java-casi-muertos.html


Precargar Imagenes con JS

abril 27, 2009

Luego del post Precargar imágenes con CSS en el cual comentábamos como colocar una imagen de fondo para indicar que se esta cargando una imagen, esta vez les presentamos una solución mas completa el cual incluye javascript.

jspreload

Creando los estilos
Lo primero es crear dos estilos, un estilo que contiene una imagen de precarga y otro que elimina la imagen de fondo.

  1. .loading {
  2. background: url(loading.gif) no-repeat center center;
  3. }
  4. .loaded {
  5. background: none;
  6. }

Cargando la Imagen de Precarga
Lo siguiente es cargar al inicio la imagen del precargador, esto para que se pueda mostrar como fondo de las imágenes a precargar. Esto lo colocamos en el header de nuestro html.

  1. <script type=“text/javascript”>
  2. loadImage = new Image();
  3. loadImage.src = “loading.gif”;
  4. </script>

Incluyendo las Imagenes
Lo que sigue es incluir las imágenes que deseamos mostrar, esto lo hacemos de la forma normal, pero le aplicamos el estilo .loading para mostrar la imagen de precarga.

  1. <img src=“img1.png” width=“512” height=“387” class=“loading” />
  2. <img src=“img2.png” width=“512” height=“387” class=“loading” />

Finalmente completamos el proceso creando un javascript que recorra todas las imágenes que contiene nuestro HTML, esto lo hacemos con la función getElementsByTagName, luego detectamos el evento onload de cada imagen para aplicarle el estilo que elimina la imagen de fondo.

  1. <script type=“text/javascript”>
  2. var imgs = document.getElementsByTagName(‘img’);
  3. for(i in imgs) {
  4. imgs[i].onload = function() {
  5. this.className = “loaded”;
  6. }
  7. }
  8. </script>

Este script lo colocamos al final del HTML antes del tag </body> y listo ya tenemos nuestro script de precarga de imágenes completo que lo podemos incluir en cualquier en cualquier página html. Pueden ver el ejemplo funcionando en jspreload.

Fuente: http://blog.unijimpe.net/precargar-imagenes-con-js/


¿Elegancia o sencillez?

abril 25, 2009

En el trabajo llevamos varios días peleándonos con la instalación de una versión de nuestro software en uno de nuestros sistemas. El sistema consta de unas diez estaciones de trabajo solaris y unos veinte PCs con Windows. En todos ellos corren aplicaciones nuestras, en su mayoría java. Estas aplicaciones tienen algunas partes comunes, pero son distintas en cada una de las estaciones y de los PCs (cada uno está especializado en diversas funciones, algunas comunes, otras no y comparten mucha información entre ellos). En las estaciones hay bases de datos Oracle, con muchas tablas comunes, pero otras distintas en cada estación. Y en todo esto reside el problema de la instalación.

La gente está dividida en dos posibles tipos de instalación.

Junto con algunos, yo soy partidario de implementar las distintas funcionalidades del sistema en jar distintos e instalar en cada estacion/PC sólo aquellos jar que son necesarios, de forma que ninguna estación/PC lleve más jar o ficheros de configuración que no va a usar. Esta es la solución que considero elegante, pero es más compleja. Requiere generar instaladores/zips disintos para cada estación/PC, así como ser mucho más cuidadoso en esta generación de instaladores/zips, muchos jar, muchos grupos de ficheros de configuración, partes comunes y partes específicas.

Otros piensan que es mejor hacer un único mega-jar, o unos pocos jar grandes, un único mega-grupo de ficheros de configuración e instalar todo en todos lados. De esta forma, un único instalador o un único zip vale para todas las estaciones/PCs. Luego es el propio software el que mirando el nombre de la estación/PC en el que corre, sabe qué fichero concreto de configuración leer, de qué clase principal hacer el new y actuar como lo que le toca. Esta instalación es, desde mi punto de vista, más chapuza, pero es innegable que es infinitamente más sencilla.

Y después de la pelea de estos días atrás para la instalación según mi punto de vista (disintos zips/instaladores que instalan en cada estación/PC sólo lo necesario), creo que estoy empezando a cambiar de opinión. Los instaladores/zips, desde luego, se hacen con procesos automáticos, pero alguien tiene que decirle a ese proceso qué debe meter. Según evoluciona el software y va llevando más funcionalidades y ficheros, hay que tocar la configuración de la herramienta que genera los instaladores/zips (izpack, maven assembly,…) y hay que hacerlo con cuidado. Este proceso es manual y está sujeto a errores humanos, por lo que a nuestros instaladores siempre les acaba faltando alguna cosa y necesitan su proceso de “depuración”.

En fin, no me gustan las chapuzas y tengo que pensar seriamente la forma de mejorar el proceso de generar los zips/instaladores, pero desde luego, es difícil resistirse a la facilidad de instalación de “todo va en todos sitios, aunque no se use”. Es mucho más fácil instalar un solo mega-jar en todos lados que instalar varios jar distintos en cada estación/PC.

Fuente: http://blog.chuidiang.com/2009/04/25/%C2%BFelegancia-o-sencillez/


¿JSP o PHP?

abril 23, 2009

Esta es una pregunta bastante habitual en la gente que empieza a hacer aplicaciones web o, incluso en la gente que ya lleva tiempo en uno de esos dos lenguajes y se plantea si merece la pena pasarse al otro. No pretendo aquí dar una relación exhaustiva de los pros y contras de cada uno de ellos, pero sí algunos de los puntos que considero importantes a la hora de decidirse.

Librerías disponibles

Tanto un lenguaje como otro tienen muchísimas librerías disponibles para hacer un montón de cosas. JSP/Java tienes bastantes más, pero también es un lenguaje multi-propósito, por lo que muchas de ellas no nos servirán para nada en una aplicación web. PHP está más pensado para web y todas sus librerías son útiles para web. Por ello, lo único que debemos tener en cuenta en este punto concreto es qué librerías vamos a necesitar para nuestras aplicaciones y si las tenemos disponibles en el lenguaje que vayamos a elegir. En su defecto, qué nos costaría desarrollar esa misma librería.

Hospedaje en el servidor

La aplicación web debe ir en un servidor. Normalmente es más fácil encontrar servidor PHP con base de datos gratuitos que servidores que ofrezcan JSP/Servlets gratuitos. Si vamos a los de pago, también es más fácil y barato encontrar servidores PHP. Por ello, si el coste es un problema, posiblemente PHP sea mejor opción.

Si nuestra aplicación web está pensada para que la gente en general la use y la instale en sus servidores (por ejemplo, un blog estilo wordpress, una wiki estilo Mediawiki, etc), también tendrá más aceptación posiblemente si la hacemos en PHP, ya que de todos esos posibles webmaster que queremos que usen nuestra aplicación, la mayoría tendrán PHP pero no JSP.

Si nuestra aplicación es para uso particular en una empresa o en casa y el servidor nos lo vamos a montar nosotros mismos, en principio no hay ningún problema con un lenguaje u otro. Es prácticamente igual de fácil instalar, por ejemplo, un servidor Apache con PHP que un servidor Tomcat para JSP/Servlets.

La aplicación y el lenguaje en sí mismos

Entre los lenguajes Java y PHP hay una diferencia que considero fundamental. El primero es tipado, es decir, hay que declarar los tipos de las variables, los parámetros de los métodos, etc, etc. En PHP no hay tipado, se pueden usar las variables sobre la marcha y pueden contener cualquier cosa en momentos distintos de la ejecución. Java es 100% orientado a objetos, mientras que PHP permite mezclar clases con funciones de programación estructurada. Esta diferencia hace que según el tipo de aplicación, sea mejor un lenguaje u otro.

Si nuestra aplicación es una aplicación puramente web, en la que principalmente hay presentación en navegador y transacciones con una base de datos, en la que van a participar un número de desarrolladores no muy grande y el tiempo de desarrollo no muy largo, PHP puede ser una buena opción.

Sin embargo, en aplicaciones muy grandes, en la que pueda haber más código/algorítmica aparte de lo estrictamente presentación en navegador y transacciones en base de datos, va a haber muchos desarrolladores y tiene un tiempo de desarrollo largo, es mejor usar JSP/Servlets.

Y explico el motivo. Una función PHP puede parecerse a esto

function la_funcion ($el_parametro) {
$el_resultado = ….
return $el_resultado
}

mientras que un método similar en Java puede ser como este

public TipoResultado laFuncion (TipoParametro elParametro) {
TipoResultado resultado = …;
return resultado;
}

Mientras estamos codificando y con el código en la cabeza, casi da igual una cosa que otra. Pero si ese código no lo he hecho yo y tengo que mantenerlo o usarlo, o lo he hecho yo pero hace unas semanas, el código PHP no ayuda en absoluto a saber qué tipo de parémetro hay que pasar o qué devuelve (ni siquiera si devuelve algo), habría que leer el código interno de la función con detalle. El código Java, sin embargo, deja claro qué tipo espera como parámetro y qué devuelve, así que quizás no tengamos que mirar el código interno del método para usarlo.

El no saber los tipos de entrada/salida puede resolverse con una disciplina estricta y comentarios adecuados, pero recuerda, estamos hablando de un grupo de desarrolladores grande. En un grupo grande, siempre hay  un porcentaje importante de ellos que será poco disciplinado/novatos y pondrán comentarios graciosos.

Hay además otras dos ventajas fundamentales en los lenguajes tipados:

  1. Los IDE tienen un autocompletar mucho mejor. Cualquier IDE de java moderno, pones la variable, un punto y te saca los posibles métodos/atributos a los que puedes llamar. Un buen IDE de PHP lo intentará, pero no siempre lo conseguirá. En el ejemplo anterior, si en java escribimos elParametro., el IDE nos pondrá los posibles métodos porque sabe que elParametro es de tipo TipoParametro. En PHP, poniendo el_parametro->, el IDE no nos puede poner absolutamente nada, porque no sabe de qué tipo es eso.
  2. Precisamente por eso y por la necesidad de declarar los tipos, un IDE no nos dejará, por ejemplo, llamar a un método que no existe o asignar a una variable no declarada. PHP sí nos dejará hacerlo o nos dejará, por ejemplo, poner $nuemro (me he equivocado a posta, en vez de $numero he puesto $nuemro) y declarar sin querer una nueva variable. Todo esto fallará, si tenemos suerte, cuando hagamos nuestra ejecución. Pero si no tenemos suerte, errores de este tipo no saltarán al ejecutar, el programa símplemente no dará el resultado esperado y perderemos horas de depuración. En java directamente no compilará y el IDE nos cantará el error en cuanto lo escribamos.

Así que si la aplicación es grande y con muchos desarrolladores, es posiblemente mejor usar un lenguaje tipado.

Gustos personales

Finalmente, cómo no, los gustos personales de cada uno, las prisas, ganas de aprender, etc. Alquien puede tener preferencia por uno de los lenguajes, o bien ser el que domina y no querer meterse en el otro, o bien todo lo contrario, querer meterse para aprender. Si vas a hacer una aplicación web sencilla, pero dominas java, tienes prisa en hacerla y te importa tres pepinos PHP, posiblemente la hagas en JSP, aunque alguien que domine PHP quizás tardaría menos en hacerla en PHP.

En resumen

Supongo que al menos parte de estas razones son las causas principales por el que en el ambiente de internet al público, la mayoría de las aplicaciones son PHP (wordpress, mediawiki, etc), mientras que las aplicaciones JSP/Servlets se quedan más para ambientes empresariales o intranets. Ojo, hay cosas de ambos tipos en ambos ambientes, símplemente estoy indicando lo que parece ser mayoría.

¿A alguien se le ocurren más motivos a tener en cuenta?

Fuente: http://blog.chuidiang.com/2009/04/23/%C2%BFjsp-o-php/