1. Cache, cache y mas cache

Es totalmente innecesario acceder a los mismos datos en la base de datos una y otra vez, es mucho mejor, guardar estos datos en memoria o en disco, y utilizarlos en las sucesivas llamadas.

Además de este tipo de datos, están los parámetros, las preferencias de usuarios, etc…

El uso de cache, mejora radicalmente la velocidad de una aplicación.

2. Arranque Rápido.

Esta es mi técnica preferida, ideal para redes lentas. No es fácil de implementar y requiere un poco de lógica. Se recoge estadística de las tablas y recursos más usados por la aplicación cuando arranca, por ejemplo, podemos tener una aplicación que normalmente abre un formulario y que tiene una lista desplegable con provincias.

Basándonos en las estadísticas, hacemos que arranque en paralelo y proceso que precarge los datos más usado, de forma que cuando el usuario acceda, no tiene que esperar que lleguen los datos.

3. Optimización de Base de Datos

No voy a detallar todas las técnicas, pues hay muchas, pero las principales son optimización de índices, minimizar los accesos a bases de datos, desnormalización cuando es necesario, estudio de planes de ejecución de consultas, etc..

4. Escalabilidad

Quizás, la parte más complicada a la hora de desarrollar una aplicación. Lo primero es ¿como sabemos si es escalable? Existen herramientas que simulan la carga de trabajo de miles de usuairos, es un buen punto de partida.

Pero ¿como lo hacemos más escalable? Existen muchas técnicas, pero la más sencilla y útil es diseñar los sistemas para que se puedan ejecutar en paralelo, no diseñar un proceso central que lo hace todo en el servidor, es mejor diseñar, pequeños procesos de trabajo que se pueden ejecutar en paralelo.

Ahora estamos probando la ejecución distribuida de los procesos del servidor, de forma, que todos los ordenadores de la oficina, participan en el proceso global, aportanto parte de su CPU.

5. Sensación y percepción

Un día llegó a mis manos un documento de Microsoft muy curioso, sobre la percepción que tiene el usuario de la velocidad de un programa, y me pareció muy interesante. La típica barra de progreso que tenía Windows al principio al iniciar, fue sustituida por una barra que se movía a toda prisa y daba varias vueltas. La percepción del usuario es importante, y tenemos que cuidar todos los tiempos muertos de la aplicación, utilizar iconos con reloj, animaciones, etc….

Hagamos un poco de historia….. Java aparece en 1995, aportando “Applets” a las páginas Web, de forma que era posible construir aplicaciones complejas dentro de un explorador web. Esto supuso toda una revolución para muchos desarrolladores que encontraron en esta tecnología una solución a sus problemas, los applets mas famosos fueron los menús, tratamiento de imágenes, calculadoras, visores, etc… pero no llegaron a extenderse para el desarrollo de grandes aplicaciones.

Debido al enfrentamiento legal que tuvieron Microsoft y Sun con respecto a la máquina virtual, Microsoft ideo una alternativa a los Applets, y a finales de los 90 sacó al mercado DHTML y un motor de scripintg muy avanzado que permitía código en JavaScript y VisualBasic Script. Y como ejemplo de esta tecnología, el equipo de desarrollo preparó las mismas demos que Sun publico para explicar las bondades de los Applets, hechas todas con DHTML.

Los Applets poco a poco fueron desapareciendo, sobre todo cuando Netscape desapareció en la lucha con Internet Explorer.

En este punto, Microsoft apostó por su versión de los Applets, los controles ActiveX, los cuales tendrían que retirar años más tardes debido a una patente.

Pero fue en el año 99 cuando descubrí Microsoft Remote Scripting, esta tecnología permitía desde una página web llamar a un procedimiento remoto del servidor, como ejemplo, una lista desplegable de provincia que al cambiarla se recargaba la lista de municipios, ¿os suena?¿AJAX?

Remote Scripting fue realmente complicado de programar, sobre todo por la carencia de herramientas efectivas para la depuración.

Con la salida al mercado de .NET, Microsoft nos dá una sorpresa que nadie se esperaba: Smart Clients, bajo este nombre se esconde una tecnología que permite colocar un ejecutable en una página web, y que se ejecute desde el explorador sin problemas, descargando las DLLs que sean necesarias y comunicandose con el servidor para acceder a los datos.

Por otro lado, Sun no tardó en responder a esta tecnología, llamandola Java Web Star.

¿Pero a donde vamos?

El problema principal es que las aplicaciones web no son lo suficientemente buenas, ni ofrecen la misma usabilidad y funcionalidad que una aplicación cliente. Y que las aplicaciones clientes no son tan fáciles de instalar y tan “bonitas” como una aplicación web.

En este sentido hay dos tendencias, llevar las aplicaciones de escritorio a web (Thin Client) o mejorar las capacidades de los browsers de internet, como AJAX, Google Gears, Adobe Flex, etc…

Es decir, llevamos más de 10 años con lo mismo, sacando tecnología sobre tecnología, para lo mismo, y cuando una de ellas parece consolidarse, aparece otra alternativa mejor que descarta las anteriores.

Aunque esto parezca bueno, pues la innovación es buena, en mi opinión, es una lucha de poderes entre Sun, Microsoft y ahora Google, que reinventan la rueda a su manera, involucrando a miles de empresas y programadores, con cambios constantes.

• Hudzilla.org – Paul Hudson’s excellent beginner-expert guide to PHP.
• W3Schools – Quick start with PHP for beginners.
• The Oracle+PHP Cookbook – Explore a broad range of HowTos for leveraging Oracle’s PL/SQL APIs in PHP applications.
• PHP.net – The PHP website. This is where you go to both get PHP and to read the documentation.
• The PHP Manual – Extensive information about PHP.
• PHP Developers Network – Network of PHP-resource driven websites.
• PHP Book Chapters – Sample PHP books chapters, read online.
• Computer-Books.us – A collection of PHP books available for free download.
• PHPFreaks.com – Learn PHP, PHP Tutorials / Howto, code examples, PHP scripts.
• PHP-Help.net: PHP codes, PHP scripts, PHP examples – PHP help, PHP codes examples, PHP scripts.
• PHP Documentation – Searchable documentation with user comments.
• PHP Books – A large collection of PHP related books.
• PHPSC – PHP Security Consortium. Guides, etc. on security in PHP code.
• Programmabilities.com – PHP scripts and tutorials.
• PHP-Resources.org – Tutorials, docs, newgroups and scripts.
• PHP Resources – Resources and techniques.
• PHP Resource Index – Another nice PHP portals for various PHP resources.
• PHP Builder – A website for PHP news, articles, code library, forums, etc.
• PHPPatterns – Raising awareness and bringing PHP to the Enterprise Creating understanding of PHP’s Advanced Capabilities.
• Good PHP Tutorials – A categorized collection of PHP tutorials.
• Mojavi – One of the most popular MVC framework of PHP.
• PHP Web Application Component Toolkit http://phpwact.org/ – It’s a wiki.
• Hotscripts.com :: PHP – A very good PHP portal.
• PHP MySQL Tutorial – Very good beginners tutorial.
• Notepad++ – Very simple yet effective source code editor. Supports highlighting and folding.
• EvilWalrus.org – Hundreds of user-contributed scripts and articles; tagged and searchable.
• NuTutorials PHP Section – Categorized tutorials (~500) for PHP.
• Beginners PHP – Tutorials and resources.
• Symfony – Advanced MVC framework for PHP.
• SELFPHP – A very good PHP portal. Searchable documentation with examples, PHP Code Book, Code library, forums and Tutorials.

El mercado actual es totalmente diferente, Firefox ha recuperado la cuota perdida por Netscape, y entran en juego más exploradores como el Opera. Los desarrolladores se ven forzados a hacer sus páginas más compatibles, al menos para Firefox e Internet Explorer.

Cuando todos creíamos que Apple se había rendido a Firefox y Camino (también basado en el mismo motor de Firefox), nos encontramos con una sorpresa, una apuesta muy fuerte de Apple por extender Safari, siguiendo un plan perfectamente trazado:

1. Lo primero ha sido, quitarse la etiqueta de incompatible, actualmente Safari 3.1 es el navegador más compatible que existe con los estándares actuales.
2. Han convertido a Safari en multiplataforma, con versiones para Windows, OSX, iPhone y con su motor webkit, compatible con Linux.
3. Han creado una política de distribución perfecta: todos los iPhone y todos los iPod, tienen instalados Safari (y muy pronto Apple TV). Todos los usuarios en Windows con iTunes o QuickTime, se han encontrado al actualizar la ultima versión con un icono de Safari 3.1.
4. ¿Cómo destacar con respecto al resto de navegadores? En lugar de desarrollar navegadores cada vez más grandes, con más características (que nadie utiliza), Apple se ha dedicado a mejorar la velocidad, teniendo un rendimiento muy superior a sus competidores.
5. Apoyo a los desarrolladores. Por un lado, Safari está basado en el navegador Konqueror de Linux, el motor sigue siendo Open Source. Por otro lado, encontramos en la versión 3.1 un menú “Desarrollo”, creado para ayudar a los desarrolladores.

¿Es hora de ir de “Safari”?

Pues la verdad es que aún es pronto, que Safari sea el navegador más compatible del mercado, no significa que funcionen todas las páginas web. Hay que tener en cuenta, que el HTML es un lenguaje que permite errores, trucos, uso de características propietarias del navegador, etc.

No obstante, como desarrolladores, debemos ir empezando a probar nuestras páginas con Safari.

¿Por qué utilizar Safari?

En los próximos años, el panorama de los navegadores cambiará radicalmente:

• Cada vez hay más dispositivos con acceso a Internet; móviles, PDA, Nintendo Wii, Playstation 3, Nintendo DS.
• Linux y Apple le van ganando terreno a Microsoft.
• Google apuesta por contenido estándar, penalizando a las web que utilizan contenido no compatible.
• La única solución para hacer páginas compatibles es seguir un estándar, de esta forma nuestro contenido se verá en todos los medios.

Utilizando Safari desde ahora, conseguiremos que nuestro contenido sea accesible en cualquier navegador.

Más información

• http://www.apple.com/safari/
• http://www.anomalousanomaly.com/2008/03/06/acid-3/
• http://www.w3schools.com/browsers/browsers_stats.asp

Sigue el Código Samurai

Los antiguos samurais, cuando luchaban, se pasaban horas observándose mutuamente hasta que repentinamente uno de ellos lanzaba un sólo golpe y derrotaba al contrincante.

Cuando vayas a programar, antes de nada, piensa, luego piensa un poco más, hasta que tengas una idea de conjunto de todo el proyecto. Luego piensa en un problema concreto con el que vayas a comenzar a programar, piensa de nuevo en el conjunto y en como encaja esta pieza en él. Entonces comienza a escribir código. No escribas una sola línea de código hasta que no tengas claro que es lo que vas a hacer.

Si eres de los que necesitan escribir para pensar: escribe en una carpeta aparte, crea tantas nuevas carpetas como bocetos necesites y cuando ya tengas el dibujo completo entonces escribe en la carpeta o proyecto definitivo; reutilizando los fragmentos de código que son de calidad y reescribiendo de nuevo lo que haya salido emborronado.

Escribe todo el código “en limpio” la primera vez que lo escribas. No hagas una chapuza pensando que lo arreglarás más tarde, de hecho nunca lo arreglarás. Utiliza clases para todos. Usa tipos enumerados.

Escribe código robusto y “a prueba de balas” desde el principio. Piensa en todo lo que podría causar un fallo y toma medidas preventivas como si el fallo ya hubiera ocurrido.

Cada vez que retoques tu código para añadir funcionalidades o corregir un fallo aprovecha para hacer limpieza. Haz limpieza todo el rato. Pasa el paño cada vez que veas una mota de polvo afeando tu código.

Menos código casi siempre es mejor. Mejor para depurar, mejor para que lo entiendan otro programadores o tu mismo en el futuro, menos código son menos fallos. No añadas funciones adicionales a una clase pensando que las necesitarás en el futuro. Escribe sólo lo que necesites ahora. Cuando necesites contemplar nuevos casos escribe una función más genérica, que admita parámetros, pero no lo hagas hasta que no estés usando esa función en dos o más lugares de tu aplicación.

No te obsesiones con la velocidad y la eficiencia de tu código al principio. Tu tiempo de programador es caro, el hardware es rápido y barato. Cuando tu código funcione y esté depurado podrás hacer test de rendimiento y encontrar los cuellos de botella que merece la pena optimizar.