Cosas que he aprendido sobre desarrollo web

Tanto en mi primer blog como en Sentido Web, el motivo fundamental ha sido compartir conocimientos con los demás. No hablo de enseñar, sino de aprender y compartir. Pero de donde más se aprende es de la experiencia que se adquiere trabajando y dándote de bruces con situaciones o problemas. Y basándome en mi experiencia, que ni es la mejor ni la más extensa, me gustaría compartir qué cosas he ido aprendiendo sobre desarrollo web.

Vales lo que sabes

Para dedicarse al desarrollo web hay que tocar todos los palos, no vale con saber sólo HTML y CSS o sólo Javascript (o JQuery) o sólo PHP. Está claro que no todo el mundo sabe diseñar, pero si debería saber maquetar. Y una maquetación no es nada sin la parte cliente, porque siempre es necesario cierta interacción. Y ahora no hay ni una sola aplicación web que no requiera una aplicación en el servidor, ya sea en PHP o Java o la que más te guste.

Es absolutamente necesario aprender día a día, porque lo que hoy es actualidad, dentro de unos meses estará deprecated. Suscríbete a unos cuantos blogs y aprende algo nuevo cada día.

No es jQuery todo lo que reluce

jQuery está genial, pero nos olvidamos de algo muy importante: el Javascript. Hay algunos que sólo se preocupan de aprender jQuery, cuando lo realmente importante es aprender Javascript. Si sabes manejarte en Javascript, te da igual usar jQuery, Mootools o simplemente hacer tus propias librerías. Además, no se puede aprender realmente jQuery si no conoces la base.

Lógicamente, esto es extensible a cualquier framework Javascript, los cuales nos facilitan mucho la vida, pero también su mal uso hace que caigamos en vicios a la hora de programación, por ejemplo:

$('#id').fn();
$('#id').bar();
// en vez de
$obj = $('#id');
$obj.fn();
$obj.bar();

No sólo de SQL vive la BD

Viva el noSQL. Se nos enseña todo sobre el SQL y las bases de datos relacionales, pero no siempre es necesario o recomendable usar las bases de datos relacionales. Cada día se habla más del noSQL, y no en plan moda con el cloud computing, sino con datos y casos prácticos.

El noSQL es bastante útil para temas de rendimiento, aunque existen otras alternativas como Sphinx o HBase que también nos pueden venir muy bien.

Cachea, cachea

Cachear es una parte fundamental de cualquier desarrollo, evita que la BD se cargue de consultas repetitivas, mejora el rendimiento y ahorra recursos. No hablo únicamente de grandes aplicaciones, en cualquier cosa debería plantearse el cachear el contenido. Importante son las llamadas Ajax, los plugins de WordPress que acceden a contenidos externos u otros desarrollos parecidos.

Divide y vencerás

Grandes problemas, pequeñas soluciones… bueno, muchas pequeñas soluciones. Dividir los problemas en pequeñas tareas será la solución más óptima que encontraremos.

Uno de los mayores problemas con los que nos encontramos en nuestras aplicaciones son las consultas lentas a la BD. Cuando nos enseñan bases de datos algo en lo que insisten es en la normalización y en las joins. Las joins pueden ser un problema cuando se trata de tablas muy grandes y tenemos que juntarlas. Por ejemplo, tenemos dos tablas que se unen mediante una primary key y una foreign key, la consulta sería algo así:

/* Da igual usar left joins, sigue siendo lento */
select * from tablaA as A, tablaB as B where A.id = B.idA and A.campo = 'lo que sea'

En los casos en que las tablas son muy grandes, es preferible obtener primero los IDs de una tabla y luego realizar la consulta sobre una de las tablas:

/* Obtengo los IDs */
select id from tablaA where campo = 'lo que sea';
/* Almaceno los IDs obtenidos y ejecuto la query principal */
select * from tablaB where id in (id1, id2, id3, id4, id5, ..., idN)

Y si por algún motivo hay que juntar los datos de tablaA y tablaB, se realiza mediante código.

Un clásico, no reinventes la rueda

Esta premisa es aplicable a muchos aspectos. Hay herramientas que ya hacen lo que queremos nosotros: blogs, redes sociales, agregadores, portales, … a no ser que quieras algo realmente específico y muy personalizable, es recomendable que uses las herramientas que ya existen, las cuales tienen detrás a mucha gente desarrollando, y es bastante posible que lo hagan mejor que nosotros.

Otro tema que incluir es el de los frameworks, algunos están en contra de su uso, pero yo creo que usar un buen framework es bastante útil. Si nos ponemos a pensar, un framework es la base para desarrollar un proyecto, y queramos o no, o usamos una base ya hecha o no la creamos nosotros: necesitaremos la capa de abstracción de la BD, seguridad, logs, cache, MVC… al final nos crearemos nuestro propio framework, el problema está en realizarlo correctamente o en elegir un framework que sea eficiente.

Lo quieras o no, habrá cambios

Desarrolla tu aplicación pensando en el futuro, en las posibles mejoras o características nuevas que tendrá. Sé realista, tampoco te tienes que ir al extremo más lejano, basa tus expectativas en datos objetivos. Siempre habrá que realizar mejoras, nos encontraremos con fallos, porque toda aplicación web tiene sus bugs. Querremos quitar cosas y añadir otras nuevas.

Para no volverte loco con los cambios, o que se vuelva loco el que tenga que encargarse de tu código, es absolutamente necesario usar el patrón MVC, comentar bien el código, tener una herramienta de gestión de errores y tareas, y un SVN o similar.

Conclusiones

No dejes de aprender, ten cuidado de las “modas”, desarrolla eficientemente y huye de comerciales y vende motos.

¡Ah!, se me olvidaba, como diría un amigo: haz lo que yo te diga, no lo que yo haga.

Sphinx 0.9.9

Por fin ha salido la versión 0.9.9 de Sphinx, la cual llevaba en RC2 la tira de tiempo. Entre las novedades trae SphinxSE, un motor de MySQL. Además corrige más de 40 bugs. Otro aspecto importante es que Sphinx ha obtenido unos puertos oficiales de la IANA: 9312 para el API nativo y 9306 para SphinxQL.

Sphinx 0.9.9

Vía / MySQL Performance Blog

Lecciones sobre escalabilidad de eBay

El eBay Distinguished Architect, Randy Shoup, ofreción una presentación sobre la escalabilidad de eBay que es bastante interesante. Lógicamente, pocos de nosotros nos vamos a encontrar con una décima parte de lo que ellos tienen:

  • 89 millones de usuarios activos en el mundo
  • 190 millones de elementos en 50.000 categorías
  • 8.000 millones de URLs solicitadas cada día
  • 70.000 millones de operaciones de lectura/escritura cada día
  • 50TB de datos nuevos cada día
  • 50PB de datos analizados cada día

Pero las lecciones que nos ofrece son bastante interesantes, de las cuales me gustaría destacar:

  • Particionalo todo: si no puedes dividirlo no puedes escalarlo. Divídelo todo en elementos manejables separados por funcionalidad y tipo de datos.
  • Asincronismo: conecta componentes independientes mediante una cola de eventos.
  • Todo falla: monitorizalo todo, porque seguro que falla
  • Siempre hay cambios: diseña de forma que puedan añadirse nuevas funcionalidades
  • Automatízalo todo: aunque en este caso el autor se refiere a procesos de aprendizaje, yo lo enfocaría a que se eviten procesos manuales

eBay’s Challenges and Lessons: from Growing an eCommerce Platform to Planet Scale

Vía / High Scalability

Google pretende indexar AJA

Aunque es de hace unos días la noticia, ni me había enterado. Google pretende hacer crawlable las páginas basadas en AJAX, para que sus páginas sean accesibles por los resultados de búsqueda.

Lo que pretende es que tanto los usuarios como los motores de búsqueda puedan ver el mismo contenido, incluso que te lleve a la URL Ajax y no a una copia estática. Del mismo modo, el diseñador podrá comprobar que todo su contenido se indexa y que se reproduce correctamente.

Desgraciadamente, Google ya nos indica cómo debemos realizar nuestro AJAX para que podamos tenerlo indexado en Google, por lo que al final lo deberemos hacer tal y cómo ellos lo piden para que no nos penalice por temas de SEO y esas cosas.

Aquí nos dejan una presentación: http://docs.google.com/present/view?id=dc75gmks_120cjkt2chf

A proposal for making AJAX crawlable

Método para crear acortadores de URLs

Buen método para crear acortadores de URLs, el truco está en usar números en base36 (incluye todos los números y letras): http://dominio.com/258j

El número 248j se traducirá a base 10 y nos dará el id de la tabla que almancena las URLs (que tendrá una primary key numérica y preferiblemente autoincremental). Así, por ejemplo, 258j equivale a 100099, por lo que sólo habría que obtener la URL que tenga esa ID.

How URL shortening scripts work?

Vía / DZone

Consejos para realizar un login seguro

Buena serie de consejos a tener en cuenta cuando desarrollamos nuestro sistema de login. Algunos son ya conocidos, pero no está mal recordarlos:

  • Logitud de la contraseña y nombre de usuario: tiene que tener mínimo 6-8 caracteres.
  • Encriptar la contraseña: aunque casi todo el mundo usa MD5 o SHA-1, no está mal del todo usar SHA-2 (disponible en PHP5), ya que las anteriores ya no son tan seguras como hace tiempo.
  • Añade una semilla a la contraseña: cuando encriptes la contraseña es recomendable añadirle un texto para que el hash sea mas seguro.
  • No uses nombres sencillos para el administrador: evita usar nombres como “admin”, “root”, …
  • Registra los intentos de login: así se podrá detectar cuando estamos siendo atacados.
  • Maneja los errores: cuando se produce un login fallido, o evita que se produzca un error, o muestra un error personalizado, no muestres errores de código que puedan dar pistas al atacante.
  • Filtra la entrada: filtra lo que el usuario meta en su usuario para evitar inyecciones de código y no compruebes si la contraseña es correcta mediante SQL.
  • Usa LIMIT o WHERE 1: es importante para evitar comprometer muchas cuentas si sufrimos un ataque.
  • Usa nonce: nonce es un número único para la sesión, así nos aseguramos de que no se realicen ataques de fuerza bruta usando diccionario.
  • Usa sólo $_POST: $_GET es más sencillo de usar que $_POST, aunque no quita que usando $_POST no nos encontremos con problemas.
  • Cuentas MySQL: utiliza un usuario con permiso de select para realizar el login, así, si rompen tu seguridad, no podrán hacer deletes, updates o inserts.
  • Auto logout: Si quieres darle mayor seguridad, desconecta al usuario automáticamente pasado un cierto tiempo de inactividad. Aunque desde el punto de vista de la usabilidad no es muy recomendable.
  • Bloque la cuenta: si se han intentado varios logins consecutivos y han sido fallidos, se debería bloquear la cuenta.

PHP Secure Login Tips And Tricks

Vía / DZone

Cherokee: servidor web rápido y potente

Cherokee es un servidor web muy rápido y con muchas funcionalidades. Según los benchmarks es el más rápido que existe, lo cual es bastante interesante.
Permite FastCGI, SCGI, PHP, CGI, SSI, TLS y conexiones encriptadas SSL, Virtual hosts, Authentication, codificación “on the fly”, Load Balancing, logs compatibles con Apache, balanceo de bases de datos, Reverse HTTP Proxy, Traffic Shaper, Video Streaming y mucho más.
Lo mejor del todo es que el proyecto lo lleva un madrileño, lo peor de todo es que desconocía totalmente el proyecto 🙁
Cherokee
Vía / HowtoForge

Gearman: crea aplicaciones distribuidas

Gearman provee un framework para distribuir aplicaciones entre diferentes máquinas o procesos. Permite realizar trabajo en paralelo, balanceo de carga y realizar llamadas de funciones entre diferentes lenguajes:

  • Open source
  • Multi-lenguaje: hay interfaz para varios lenguajes (cuya lista sigue creciendo), por lo que permite crear aplicaciones heterogéneas con clientes procesando trabajo en un lenguaje y la aplicación en otro.
  • Flexible: no está atado a un patrón de diseño específico. Puedes unir aplicaciones distribuidas con el modelo que elijas, por ejemplo Map/Reduce.
  • Rápido: tiene un protocolo y una interfaz simple con un servidor optimizado en C que minimiza la sobrecarga de la aplicación.
  • Incrustable: como es rápido y ligero, es válido para aplicaciones de todos los tamaños. Además es fácil añadir aplicaciones ya existentes.
  • Tolerancia a fallos: además de ayudar en la escalabilidad, permite tolerancia a fallos.

Gearman

Vía / Ronald Bradford