Me mudo

Este blog no recibirá ya más actualizaciones. Ve al nuevo blog enricflorit.com o averigua por qué me mudo.

viernes, 26 de octubre de 2012

Mejora tu código adoptando una guía de estilo

La mayoría de veces, un proyecto de código es mantenido por mas de una persona. Aunque sea un equipo pequeño, cada programador tiene una forma de entender, leer y escribir el código, de la misma manera que cada uno tiene una forma de hablar y expresarse.
En estos equipos de mas de una persona mantener código escrito por cualquiera del equipo puede llegar a ser una pesadilla. Y ya no hablemos del código libre/open source, en el cual la mayoría de los programadores están dispersos por el planeta y conectados solo por una lista de correo o un tracker de bugs.
La mejor manera de solucionar estos problemas de comprensión en el código es bastante lógica: establecer unas normas que cada desarrollador deberá seguir, de modo que todo el código presente más o menos consistencia independientemente del programador autor de cada parte del código.
Algunos grupos de programadores incluso han dado un paso mas, publicando el estándar que siguen internamente bajo el nombre de "Guías de estilo”. Estas guías son una serie de normas a seguir para un código legible y unificado, y suelen tratar estos puntos de la sintaxis y el formateo del código:
  • La indentación del código
  • El tamaño máximo de una línea
  • La separación mediante líneas en blanco
  • La codificación de caracteres
  • Uso de sentencias específicas del lenguaje
  • Escritura de comentarios
  • Formato de las estructuras (if, while, for, switch, catch...)
  • Uso de las expresiones lógicas &&, ||, !==/!=
  • Nombres para variables y funciones
Como se puede ver, en estas guías se tratan casi todos los aspectos a tener en cuenta a la hora de programar en un lenguaje específico.
Por si os interesa, os pongo algunas de las guías que se pueden encontrar por la red (si queréis más simplemente id a Google):
Qué método usáis vosotros? Os “auto-definís” unas reglas propias o seguís fielmente una de estas guías de estilo?

lunes, 22 de octubre de 2012

Aplicaciones con AJAX

Hola!

Hace poco me he mudado de blog, ahora mis posts están en enricflorit.com. Para ver este post:

http://www.enricflorit.com/aplicaciones-web-con-ajax/

miércoles, 17 de octubre de 2012

Detección del navegador vs. detección del soporte

Un problema que se han planteando los desarrolladores web desde que la web existe es la compatibilidad con navegadores. Hablo del código para JavaScript, donde en ocasiones podemos llegar a multiplicar el código necesario para cualquier aplicación por dos o tres. Por suerte, la mayoría de problemas más básicos se están solucionando al introducir nuevas versiones en los navegadores. O tal vez no?
Algo de historia
Antaño, los desarrolladores web (en aquellos tiempos, “webmasters”) tenían que preocuparse por dos plataformas: Internet Explorer y Netscape Navigator. Pero era algo casi normal, y tenías tres opciones:
  • Soportar ambos navegadores
  • Soportar uno de los dos. El que te hiciera menos rabia, el que te gustara más o el preferido por tus visitantes.
  • No soportar ninguno de los dos. Las webs no tenían tantas necesidades multimedia como hoy, y la mayoría de efectos JS solían ser puras chorradas.
Pero claro, con el tiempo fueron llegando más necesidades, más soluciones... y los navegadores modernos. Es decir, la popularización de los navegadores modernos. Navegadores que respetaban los estándares (todavía a medias, pero empezaba a existir esa idea). Y algunos de los webmasters empezaron a ver que era mucho mejor adaptar sus aplicaciones para estos navegadores e Internet Explorer.
La gran pérdida de tiempo
Como IE lo hacía todo al revés, era sencillo diferenciar entre el código moderno y el antiguo. Bastaba detectar el navegador, y se popularizaron el uso de scripts cortos como /*@cc_on!@*/false o '\v'=='v', basándose en errores del motor de JavaScript de IE.
Pero poco a poco, sucedió que las versiones nuevas de IE (que no modernas) empezaron lentamente a soportar formas estándar y de acuerdo con los navegadores modernos. Problemas? Sí, muchos. Se fueron cambiando los métodos de trabajo, y era asunto del desarrollador meterse en problemas de cómo se soluciona cada caso en cada navegador.
Una solución parcial: las bibliotecas JavaScript
Con la llegada de bibliotecas como jQuery, Mootools, etc., el problema de la compatibilidad parecía que se arreglaba por completo. Está demostrado que no es así, pero se acortó sustancialmente el tiempo de mejoras de compatibilidad en una web.
Así que, ¿porqué nos seguimos complicando la vida? ¿No tenemos suficientes herramientas con estas bibliotecas, como para que aún queramos más? La respuesta es no, y tiene explicación en algo de lo que se habla mucho en estos tiempos: HTML5.
La llegada de HTML5, un quebradero de cabeza (otro más)
HTML5 mola, ya lo he dicho alguna que otra vez. Pero como todo lo nuevo, tardará un tiempo en ser aceptado por todos los navegadores. Algunos puede que no lo lleguen a soportar nunca, pero qué le haremos. Hay un montón de cosas nuevas: etiquetas semánticas, vídeo y audio nativos, canvas, svg, nuevas API de JavaScript, nuevo código CSS...
Parece ser que vuelven los problemas... Que si este navegador soporta esto, que si no lo soporta... Ha llegado el momento de ser más selectivos, escribir nuestro código en función del soporte de una característica y no del navegador y/o su versión (como hacíamos con Internet Explorer). Pero cómo lo hacemos?
Sencillamente, con bibliotecas de test. Modernizr es una muy famosa y que se ha sabido desenvolver bien, es pequeña y sencilla. Además es modular, así que podemos compilar nuestra propia versión desde la web para que solo haga lo que necesitamos. Os recomiendo que la descarguéis para probarla: http://www.modernizr.com/
Para acabar, parece que tenemos solucionado el tema de la compatibilidad, con algunos baches (de escribir varias versiones del código no nos libramos), pero lo que sí que nos es útil es el uso de bibliotecas.
Aún así, creéis que hay algún asunto pendiente en el tema de la compatibilidad? Cuál?
Un saludo! ;-)

domingo, 14 de octubre de 2012

Reescribir código o reutilizarlo?

"Contemple desecharlo; de todos modos tendrá que hacerlo." (Fred Brooks, The Mythical Man-Month, Capítulo 11)
Esta es una frase que leí referenciada hace algún tiempo en un artículo del hacker Eric S. Raymond, "La Catedral y el Bazar". En ese artículo se habla sobre el éxito de un desarrollo al estilo linux, pero no es el tema que traigo hoy. Hoy quiero hablar de algo distinto: ¿Es necesario desechar totalmente código de un proyecto (o parte de él) en el momento en que nos damos cuenta que hay una solución y/o implementación mucho mejor que la actual?
Difícil decirlo, ¿verdad?. Este es un tema que me suele preocupar bastante en mis desarrollos web. Como es lógico, jamás podrá nadie a estas alturas aprender todo cuanto se ha descubierto, escrito o dicho alguna vez. En cualquier ámbito pasa esto, excepto si nos metemos en un tema muy específico y limitado (y aún tendría serias dudas). Es imposible conocer absolutamente todo lo que está disponible en Internet, por ejemplo. ¿Tiene Google indexadas todas las webs del mundo? No, y cada día se crean aún más.
Pasemos a un ámbito más concreto, dejando de lado reflexiones existencialistas. El desarrollo web. Podríamos decir que esta parte de la informática incluiría, a grandes rasgos y sin contar la especialización, algunos pilares: HTML, CSS, algo de JavaScript, las bases del protocolo HTTP... Cualquiera que sepa esto se puede llamar desarrollador web? Lo dejaremos en que se le podría empezar a llamar así.
Ahora dejemos de lado los conocimientos básicos sobre la web, y diré que siempre existe la especialización. Pongo mi caso personal: estoy especializado en PHP y en su relación con AJAX. Ni de lejos soy el más bueno, ¡Me queda mucho por aprender! Pero cada vez que descubro algo nuevo que realmente me interesa, lo primero que quiero hacer es implementarlo. Probarlo. Experimentar con ese "algo" que me fascina, del cual quiero tener más conocimiento.
Ahí entramos en el problema: qué pasa si descubrimos algo que nos permitiría tener grandes beneficios (a nivel de código) en una parte de nuestra aplicación? Pondré un ejemplo práctico y de relativa actualidad (aunque aún no se ha manifestado demasiado): Backbone.js
Si habéis oído hablar de Backbone.js, sabréis que es un framework destinado a trabajar con proyectos web de gran complejidad del lado del cliente (aunque también se puede usar con node.js). Uno de los modos de uso que se proponen en la web del proyecto es la combinación con jQuery. Ahora supongamos que tienes un proyecto enteramente hecho con jQuery, y es bastante grande. ¡Backbone.js parece ser tu solución! Pero, espera un momento... La solución a qué? No está tu web acabada?
La decisión depende de tu situación
Si tu proyecto no está acabado, plantéate en qué estado de desarrollo está. Si te encuentras en una fase avanzada, no cambiarás, no? Lógico, sería desechar mucho trabajo.
Pero si hablamos de un código pequeño, que de momento es solo el esbozo de una idea, o incluso una parte a medias de una idea, contempla reescribir el código usando la herramienta nueva. Aquí es donde quería llegar con la frase del principio - si ya has resuelto un problema una vez, o ya sabes en qué dirección apuntar, será mucho más fácil resolver el problema con un nivel de complejidad mayor: la nueva herramienta. Es decir, en este caso SÍ reescribiríamos.
Pero, ¿Qué pasa si el proyecto está terminado? Excelente pregunta. Y creo que no debería quedar sin responder. Pero de nuevo daré la respuesta (o mejor, mi opinión) con condicionales. Si es un proyecto no demasiado grande, no tienes ideas para mejorarlo y/o tienes tiempo para reescribirlo... Hazlo, seguramente el cambio será para mejor. Pero si estás en lo contrario de uno de estos tres casos, lo mejor sería desarrollar cualquier parte nueva usando lo último que hayas aprendido, y aceptar que, lentamente, la parte antigua de tu código la irás modificando y modernizando con el tiempo. Dicho de otro modo, REUTILIZA tu código.
Cuál es tu opinión? Qué haces frente a un problema de cambio de código?

jueves, 11 de octubre de 2012

Cómo subir archivos al servidor con AJAX - Parte 1

Me he mudado! Este blog pasa a llamarse enricflorit.com. Puedes encontrar esta entrada aquí:

http://www.enricflorit.com/como-subir-archivos-al-servidor-con-ajax-parte-1/

lunes, 8 de octubre de 2012

Cómo usar correctamente el RewriteEngine (parte 1)

En este primer post sobre configuración de servidores Apache voy a empezar a hablar del RewriteEngine, posiblemente uno de los casos en que más usamos el fantástico archivo .htaccess (otro sería la creación de errores personalizados).
Aviso que en este post no pondré ningún ejemplo, así que habrá que esperar a otro en el que sí pondré ejemplos de cada una de las maneras de usar el mod-rewrite que menciono :).
Saber si lo tienes activado
Lo primero que necesitas saber es si puedes usar RewriteEngine en tu servidor. Si no lo está y no tienes acceso a la configuración de apache, lo siento pero tendrás poco que hacer. Así que para no perder el tiempo con el resto de ejemplos, primero haz lo siguiente:
  1. Crea un archivo llamado .htaccess en la carpeta raíz de los archivos de tu servidor.
  2. En el archivo, introduce estas líneas:
    RewriteEngine On
    RewriteRule prueba\.html http://www.google.es [R]
  3. Guarda, sube el archivo al servidor remoto
  4. Abre la dirección http://tudominio.com/prueba.html
  5. Si se abre la página principal de Google, ¡Enhorabuena! Tienes RewriteEngine disponible. Si no es así... Lo siento, tendrás que usar otra forma de crear URLs amigables (que las hay ;)).
Usos de RewriteEngine
El uso más común que se le da a esta opción de configuración de Apache es para reescribir URLs y hacerlas más amigables, es decir, más sencillas para el usuario y para los motores de búsqueda. Pero también tiene otros usos, menos conocidos, y sobre todo, menos extendidos.
  • Como ya he dicho, la reescritura de URLs. Está claro que es mucho más legible /noticias/23 que ?id=23, y más cuando tenemos más de dos o tres variables que recoger de la URL. Esta aplicación no es, en principio, complicada, siempre que tengamos disponible el mod-rewrite de Apache.
  • Protección contra el robo de ancho de banda: puede que visitando algún foro hayas visto alguna vez una imagen que no aparece. En su lugar, una advertencia y, normalmente, una URL con la página original de la imagen. Esta imagen está protegida con RewriteEngine, y es una buena manera de proteger tu contenido propio de apropiamientos fáciles (al menos, que se tengan que descargar el archivo!).
  • Exclusividad de un enlace a un archivo o página: el caso anterior tiene otra aplicación. Pongamos que tienes un archivo PDF, pero no quieres que otros puedan enlazar directamente al archivo, sino solo a una página de aterrizaje que a su vez incluye un enlace al archivo. Esto es posible gracias también al RewriteEngine...
  • Sentencias para el mod-rewrite Para usar este módulo de apache, solo tenemos que activarlo desde un archivo .htaccess. Este archivo deberá estar dentro de la carpeta a la que queremos aplicar el mod-rewrite y las opciones que escribamos.
    La línea para inicializar el módulo es sencilla:
    RewriteEngine On A partir de aquí, podemos pasar directamente a las espresiones regulares, o bien definir algunos parámetros más:
    RewriteBase [directorio base de las url reescritas]
    RewriteCond [variable] [regexp a comparar con la variable]
    RewriteRule [regexp] [url a reescribir]


    *(regexp = expresión regular)
    Aplicando estos conceptos, y con la ayuda de flags (condiciones adicionales para las RewriteCond y RewriteRule), podremos aplicar RewriteEngine a los casos de más arriba. Nos vemos en la segunda parte del post!
    Saludos ;)

jueves, 4 de octubre de 2012

Webs para móviles: diseño propio desde cero

Este es el primero de una serie de artículos donde voy a comparar las diferentes opciones que se nos presentan a la hora de crear una web adaptada a móviles. Hoy empezamos con los diseños desde cero, partiendo solo de los tags html más básicos y de una hoja de estilos css vinculada. ¿Algo a decir?
Evidentemente, este método es uno de los más costosos a nivel de tiempo. Si lo comparamos con el uso de librerías o frameworks, hay que tener en cuenta que tendremos que crear la web absolutamente sin nada, como mucho, la idea del diseño que vamos a implementar.
También se nos presenta el problema del soporte. Por dos lados: el primero es el soporte de etiquetas HTML5 y estilos CSS3 por parte de los diferentes navegadores móviles. Este problema suele ser aún más grande con las fuentes de letra y su tamaño. Pese a tener disponible la opción @font-face, lo más normal es tener algún tipo de problema relacionado con esto.
Por otro lado estan las interfaces táctiles. Si queremos crear un menú que se deslice o una cabecera fija, la tendencia es a tener grandes problemas. Si en los navegadores de escritorio la compatibilidad ya es una pesadilla, aquí se multiplica por cuatro. Estamos tratando con dispositivos muy distintos entre sí, y el manejo de eventos táctiles es lo que más quebraderos de cabeza suele llevar.
Pero hay que tener en cuenta las ventajas. Ante todo, el diseño que vayamos a crear será, con toda seguridad, muy parecido a la versión de escritorio de nuestra web. Si la tuviéramos que crear con una librería, esto no sería para nada así.
Y como siempre (no me canso de decirlo), la velocidad. Las librerías no siempre son la mejor opción. En un móvil esto cuenta mucho más que en un ordenador. El uso de librerías siempre aumenta el peso de una web, y si la mayor parte de nuestros visitantes van a usar redes 3G para entrar a la web, no les hacemos un gran favor. Una web sencilla será siempre mucho más rápida que una pesada y con archivos grandes, así que es mejor no complicarse la vida en el campo móvil.
En resumen, si queremos una web móvil con la información básica sobre la web en sí, deberíamos optar por un diseño desde cero. Y si lo que queremos es una web con funcionalidades, con el sistema de usuarios activo... Tal vez sea mejor apostar por las demás opciones.
Hasta pronto!
Related Posts Plugin for WordPress, Blogger...