Qué debería tener un proyecto web Open Source

ByLuis

El uso de herramientas web open source es muy frecuente tanto en proyectos personales como profesionales. Existen alternativas de código abierto para casi todo lo que podemos necesitar: blogs, CMS, gestión de proyectos, galerías de imágenes, … Desgraciadamente, algunas veces estos proyectos open source no son demasiado “buenos” y trabajar con ellos puede ser un verdader suplicio.

Quizás hablo desde la desesperación que sufro últimamente por tener que lidiar con el desarrollo de otros, pero me gustaría compartir una serie de aspectos que debería tener un proyecto web open source, sobre todo aquellos que ya tienen unos cuantos años, lógicamente, sin desmerecer el trabajo altruista de nadie.

  • Buena documentación: imprescindible, ya sea para el usuario como para el desarrollador.
  • MVC: bueno, cualquier proyecto debería seguir esta arquitectura, pero en el caso de un proyecto open source en el que cualquiera puede echar mano al código, se convierte en algo absolutamente necesario ya que normalmente se requiere una personalización y si se ha de tocar el core para realizar los cambios necesarios, mal vamos. Además, el MVC te permite quitar las odiosas tablas que te encuentras en muchos proyectos.
  • Plugins: el proyecto deberá permitir que otros añadan funcionalidades a tu código. El éxito de un proyecto open source depende de la comunidad, y es la comunidad la que se suele encargar de los plugins. En versiones iniciales es posible que esta funcionalidad no exista, pero debería ser una futura implementación.
  • Themes: para proyectos de CMS, blogs o con frontend público, siempre viene bien tener una lista de themes donde poder elegir y diferenciar tu aplicación de otras similares. Además, también es un origen de colaboraciones por parte de la comunidad (al igual que los plugins) y existen numerosas webs o empresas que ofrecen themes de pago, lo cual aporta negocio e interés para los usuarios/desarrolladores.
  • I18N: aunque muchos estamos acostumbrados al inglés, es necesario que el proyecto permita la internacionalización para que existan versiones en diferentes idiomas; a todo el mundo le gusta usar las aplicaciones en su propio idioma.
  • Comunidad: el Santo Grial, si tienes comunidad, tendrás éxito (o casi). Creo que esto debe ser lo más complicado de obtener, porque en parte no depende de tí, depende del gusto de los otros desarrolladores, por eso, quizás, los puntos anteriores sean tan importantes.
  • Foro: aunque algunos crean que los foros están obsoletos, no hay nada más utilizado y necesario que un foro para resolver dudas, sobre todo si existe un foro mayoritario y no tienes que buscar en otros 100, y más importante aún, que las respuestas las ofrezcan, entre otros, los desarrolladores del proyecto open source.
  • Gestor de errores: da igual si es Trac, Bugzilla u otro similar. El problema de todo proyecto es la detección, corrección y seguimiento de errores, si se ofrece una herramienta para que la comunidad se involucre en esta fase el proyecto irá mucho mejor.
  • Gestor de versiones: SVN, git o similares, para que la gente se pueda descargar las últimas modificaciones
  • API: al igual que los plugins, permite que otros interactuen con tu aplicación, sobre todo desde otras aplicaciones diferentes, por lo que se añade riqueza al proyecto.
  • Código documentado: aunque exista una documentación del uso de las funciones “públicas”, siempre viene bien tener la documentación de core.
  • Sencillez: por favor, que para crear un plugin, módulo o componente no sea necesario crear 20 archivos y 30 directorios
  • Estándares: si todos vamos a nuestra bola, al final habrá que aprender 100 métodos distintos, siempre es mejor seguir los eśtandares y no volver loco al personal. Por ejemplo OAuth, no te crees tu propio método de autenticación porque si la gente lo necesita usar le causarás un inconveniente, y si no lo necesita usar se echará para atrás y cambiará de opinión porque no le apetecerá usarlo.
  • Interacción con otras aplicaciones: en el punto en el que nos encontramos es absurdo pensar únicamente en nuestra aplicación, ahora es necesario que todo se conecte con todo, no nos olvidemos de los archifamosos Google, Facebook y Twitter

Actualizado desde aquí

  • Administración: existe algunos proyectos que van por ficheros de configuración, lo cual no quiere decir que sea difícil de administrar, pero no todos los usuarios son avanzados y hay que poner las cosas fáciles a la gente.
  • Instalador: como bien dice Chema un instalador sencillo y paso a paso puede ser fundamental para el éxito del proyecto, ya que si la instalación es complicada, probablemente el usuario no avance y descarte usar nuestro proyecto.

No son nuevas verdades, pero aunque parezca mentira en muchos proyectos que he visto algunos puntos brillan por su ausencia y en otros se hace justamente lo contrario

Consejos para desarrollar en la nube

ByLuis

Aunque no soy muy fan de la moda del cloud computing, quizás porque se habla de ello muchas veces un tanto a la ligera, si que creo que desarrollar aplicaciones en arquitecturas basadas en la nube es algo que en el futuro tendremos que realizar (más basado en hosting que en servicios). Por ello estos consejos pueden ser interesantes:

  • Las máquinas son igualmente inseguros: es por ello que tampoco merece la pena gastar más medios en máquinas más críticas como la BD. Toda máquina falla, por lo que es mejor diseñar la arquitectura teniendo esto en mente para poder recuperarnos de una caída más facilmente.
  • Una aplicación en la nube depende absolutamente de la red y el IO, por lo que no es buena idea tenerlos “físicamente” muy lejos. Esto es uno de los motivos por los que yo, personalmente, no creo que tenga mucho éxito el concepto nube pensado como aplicación en Google y BD en Amazon (o parecido), algo que muchos se dedican a “vendernos”.
  • La red no es fiable, por lo que es conveniente tener sistemas de monitorización para saber qué ocurre en las máquinas y si tienen accesos unas a otras

El post original explica mejor cada punto y ofrece otros consejos más, que recomiendo leer.

Designing applications for cloud deployment

Consejos para jQuery

ByLuis

Últimamente hablo mucho de jQuery, y no es para menos, ya que este framework de Javascript es muy bueno y la gente realiza grandes plugins que nos ayudan en nuestros desarrollos. En este caso se trata de varios consejos que nos serán muy útiles a la hora de desarrollar:

  • Carga la librería desde Google Code
  • Almacena en variables los selectors que vayas a usar en varias ocasiones
  • Evita la manipulación DOM lo máximo que puedas, es mejor realizar una llamada “gorda” que varias pequeñas
  • Usa preferiblemente IDs en vez de nombres de clase cuando realices búsquedas
  • Realiza la captura de eventos correctamente, muchas capturas suele ser ineficiente
  • Usa los nombres de clase para guardar el estado de un objeto
  • Incluso mejor que el anterior, usa el método data() para guardar datos en un objeto
  • Aprende a crear tus propios selectores
  • Usa noConflict() para renombrar el objeto jQuery y no tener problemas con otras librerías
  • Aprende a controlar cuando se cargan las imágenes
  • Usa .lenght en un selector para saber si un objeto existe
  • Añade una clase al objeto HTML para modificar elementos por CSS cuando el documento se haya cargado

Improve your jQuery – 25 excellent tips

Vía / Intenta

Consejos para pasar a XHTML Strict

ByLuis

Buena serie de consejos a seguir para aquellos que quieran empezar a realizar webs usando XHTML Strict:

  • Declara el Document Type
  • Declara el Content Type
  • Añade la barra final a los tags de una sola referencia, por ejemplo <br /$gt;
  • Usa la entidad &amp; para el ampersand (&)
  • No olvides el atributo alt par alas imágenes
  • Referencia correctamente el Javascript
  • Usa la etiqueta fieldset en los formularios
  • Anida correctamente el HTML
  • No uses elementos o atributos deprecated

Web Design Tip: XHTML Strict Transition

Consejos para tener un buen código Javascript

ByLuis

Consejos que nunca vienen mal para desarrollar un código Javascript decente:

  • Que sea limpio y esté bien documentado: esto no es exclusivo de Javascript, pero parece que en este lenguaje se olvida. También es recomendable tener dos versiones del script, uno de desarrollo y otro de producción (que estará comprimido).
  • Usa ficheros externos: no incluyas los scripts dentro de tu HTML, usa scripts externos. A parte de ser más eficiente en el gasto del ancho de banda es reutilizable y más legible.
  • Separa la capa de presentación de la capa lógica: no añadas eventos en las etiquetas HTML, create Javascripts no intrusivos que modifiquen los elementos y añadan los eventos.
  • Define el ámbito de las variables: aunque no sea necesario usar var para definir las variables, hay que hacerlo, así evitarás sorpresas de modificación de variables, sobre todo si usas recursividad.
  • No pienses que por defecto se soporta Javascript: no todo el mundo dispone de javascript, por ello no es conveniente llamar a funciones javascript dentro del href de los enlaces, y es conveniente tener acción por defecto en un enlace cuando se quiere modificar su funcionalidad por javascript:
<a href="#" onclick="javascript:accionClick()">enlace</a>
<a href="enlace.html" onclick="accionClick(); return false;">enlace</a>

5 JavaScript Best Practices

Consejos para cuando uses Ajax

ByLuis

Ajax tiene muchos amigos debido a la Web 2.0 y muchos enemigos, sobre todo debido a la usabilidad. Al igual que dijimos con el tema de Flash, el problema no es Ajax, sino el uso que se da de él. Por eso, conocer estos consejos nos puede venir bastante bien:

  1. No actualices toda la página usando Ajax, ni modifiques elementos HTML que puedas modificar mediante Javascript y el DOM.
  2. Ten en cuenta que habrá visitantes que tengan el Javascript desactivado o usen un navegador con una version de Javascript antigua o no completa como la de los dispositivos móviles.
  3. Cachea, ya sea en el cliente o en el servidor, las peticiones más frecuentes. Por ejemplo, el autocompletado hace peticiones constantemente al servidor, lo que puede gastar recursos del servidor y la base de datos.
  4. No tengas muchas llamadas concurrentes para cambiar la interfaz, normalmente los navegadores solo realizan dos llamadas HTTP a la vez, por lo que si tienes muchas llamadas para cambiar las imágenes, puede volverse muy lenta la carga.
  5. Usa llamadas asíncronas, ya que si las realizas de forma síncrona y hay problemas de red, el navegador se quedará esperando la respuesta.
  6. Prueba tu aplicación web con una conexión lenta.
  7. Comprueba el uso de memoria del navegador mientras ejecutas tu aplicación web durante 1 ahora, 2, 10, un día.
  8. Comprueba el código de estado http que devuelve XMLHttpRequest.
  9. Prueba a desactivar el objeto XMLHttpRequest.
  10. Usa indicadores de carga para saber que la aplicación está cargando algo.
  11. Ten en cuenta que puedan usar el botón de “Atrás” del navegador.
  12. Si es necesario cancelar un petición ten en cuenta que la petición ya está procesándose en el servidor y que el cliente procesará la respuesta.

Yo añadiría que hay que tener en cuenta que el orden de llegada de las respuestas no tiene que ser el mismo que el de las peticiones, si es importante el orden, usa bloqueos pare evitar problemas de concurrencia.

The top 10 mistakes when using AJAX

Vía / dzone

10 reglas esenciales para depurar

ByLuis

Más consejos que siempre viene bien, algunos los conoceremos, otros simplemente los usaremos de forma automática y otros serán nuevos para nosotros. En este caso se trata de consejos para depurar nuestras aplicaciones.

  • Comprueba los datos: comprueba que los datos son los que se esperan. Una buena opción sería darle la funcionalidad al sistema de exportar los datos a un fichero de texto plano para poder comprobarlo mejor.
  • Comprende el sistema: leer el manual, seguir las instrucciones, compara tu código con los ejemplos que ofrecen, puede ayudarte a usar el sistema correctamente y no mandar datos que no son los correctos.
  • Hazlo fallar: para encontrar posibles fallos no hay nada mejor que hacerlo fallar a proposito. Si algo falla rara vez, puede ser algo bastante importante, no asumas cosas cuando intentes encontrar el problema, te puede hacer perder mucho tiempo.
  • Tómate tu tiempo: sacar conclusiones usando poca información nos puede hacer no encontrar el problema real, sino parchear un problema menor.
  • Divide y conquistarás: estrecha tu búsqueda, limita los sitios donde pueda darse el error, sigue el código hasta la zona más exacta donde pueda fallar.
  • Cambia cosas una a una: cuando encuentres varios errores, corrígelos uno a uno, para evitar encontrarte con otros errores, o que cuando algo falle por los cambios, no sepas por qué se ha producido.
  • Realiza una auditoría: da igual que parezca que todo funciona bien, sigue mirando los logs por posibles errores, por si aparecen casos que no habías visto antes.
  • Comprueba primero lo obvio: no asumas que tus ideas son correctas, cuestionate todo.
  • Pide ayuda: los test de caja negra dicen que quien debe testear la aplicación no debe ser quien la ha desarrollado, ya que muchas veces caemos en el error de pensar que algo en particular no va a fallar porque sabemos cómo funciona.
  • Si no lo corregiste, no está solucionado: las cosas no se arreglan solas, si no se reproduce de nuevo el error no quiere decir nada, el error sigue estando allí.

10 essential debugging rules

Vía / dzone

10 signos de una aplicación web insegura

ByLuis

Interesante lista de puntos que pueden evidenciar que nuestra aplicación web tiene problemas de seguridad:

Top 10 Signs You Have an Insecure Web App

Vía / dzone

Diferencias entre un buen diseñador y un gran diseñador

ByLuis

Estando a la espera de que nos cuenten las diferencias entre un mal diseñador y un buen diseñador, que sería algo que necesitamos algunos, nos quedamos con un buen artículo que nos explica las diferencias entre un buen diseñador y un gran diseñador.

Se trata del típico post que todo el mundo referencia y que uno se da cuenta que se entera de las cosas el último, por eso voy a referenciar donde lo he visto originalmente, donde lo he leido en español y por su puesto el original.

Entre las cosas que más me han gustado destaco lo siguiente:

Mientras un buen diseñador dispone de ciertos elementos y los organiza de manera estética, un gran diseñador se preocupa además porque el mensaje que expresa su diseño llegue a destino.

…los artistas crean problemas, los diseñadores los solucionan. Pero un gran diseñador se adelanta a un problema potencial, tiene visión.

La conclusión a estas ideas nos lleva nuevamente a la razón de ser del trabajo de diseño, que es justamnente lo que diferencia además a un diseñador de un artista: las necesidades y problemas que atiende el diseño suelen ser -por lo general- ajenas al diseñador. El diseñador no es más que un instrumento comunicativo en esencia.

Nine skills that separate good and great designers

9 habilidades que separan buenos y grandes diseñadores

Vía / Criterion