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.
disculpa que te corrija, pero un proxy no limita el número de usuarios sino que limita el número de conexiones a la base de datos y de ejecuciones de, por ejemplo, php, mostrando una versión “precargada” de la web.
Un saludo.
marketing en internet
disculpa que te corrija, pero un proxy no limita el número de usuarios sino que limita el número de conexiones a la base de datos y de ejecuciones de, por ejemplo, php, mostrando una versión “precargada” de la web.
Un saludo.
Hola Alejandro, yo no he dicho que el proxy limite el número de usuarios, sino el número de peticiones (tal y como dices tú) para que asà no todos los usuarios se queden sin servicio, sino que al menos algunos puedan acceder.
Saludos