Latest Entries »

Software libre en Windows

Filed Under: software, software libre, windows by castarco — 3 comentarios
agosto 21, 2010

A muchos no nos gusta trabajar sobre MS Windows por muchos y diversos motivos. Uno de los que acostumbran a tener más peso es que no es un sistema que no nos dé la suficiente libertad. Otros motivos son la falta de versatilidad, su shell, que no es demasiado potente.. (aunque lo han intentado subsanar con la Powershell), o, directamente, el mismo motivo que aducen los windowseros para no pasar a sistemas libres, que no estamos acostumbrados a sus programas (o nos parecen una grandísima boñiga).

Pero siempre podemos encontrar algo de esperanza. Hay gente que desarrolla software libre muy útil y que funciona sobre Windows. No solo nos ayudarán a pasar el mal rato cuando no tengamos más remedio que usarlo, sino que nos podrá servir para habituar a aquellos que queramos convencer para que abandonen Windows (sí, a veces el proselitismo es necesario, sobretodo si se es el pringado de turno que tiene que ir arreglando ordenadores con Windows por todas partes).

Aquí dejo mi lista del software libre para Windows que encuentro más útil,

Internet

  • Mozilla Firefox : Un gran navegador, y, todo hay que decirlo, parece funcionar mejor sobre Windows que sobre GNU/Linux. Tengo que añadir que la versión 4 será mítica en cuanto vea la luz del día.
  • Mozilla Thunderbird : A su vez, en su versión 3.1, resulta ser también un gran cliente de correo, y la experiencia puede mejorar notablemente si se combina con el plugin Lightning , actualmente en su versión 1 beta 2.

Oficina

  • OpenOffice ( aunque prefiero la versión de Novell, Go-OO ) : Una gran suite ofimática, mejorable sin duda, pero que está a la altura de las necesidades diarias y maneja por defecto el formato estándar ODF. Además nos permite trabajar también con los formatos de la suite ofimática de Microsoft y exportar nuestros documentos a PDF.
  • Mozilla Sunbird : Un buen programa para gestionar tus calendarios y horarios, se integra perfectamente con Google Calendars y también con Mozilla Thunderbird mediante el plugin Lightning que he mencionado anteriormente.

Utilidades varias

  • InfraRecorder : Muy útil para crear y quemar imágenes de CDs, así como hacer copias directas, o bién CDs con los archivos que quieras.
  • PeaZip : Para comprimir y descomprimir ficheros, tiene una interfaz muy agradable y simple.
  • 7-Zip : Lo mismo que PeaZip, algo más versátil, pero su interfaz gráfica tiene una apariencia menos cuidada.
  • Ghostscript : No es nada que se vaya a usar en el día a día, pero sirve como pieza indispensable para integrarse con otras herramientas de la talla de Scribus. Es útil para tratar con Postscript y PDF.

P2P

Hay muchos más programas de los que pondré en esta sección, simplemente pongo mis preferidos.

  • eMule : Todo un clásico, nos permite acceder a multitud de películas, música, documentos varios, programas, etc. Todo a través de las redes ed2k y Kademlia, una con puntos centralizados y la otra totalmente descentralizada respectivamente. Nos permite aplicar ofuscación de protocolo.
  • Deluge : Mi cliente favorito para torrents, rápido, sencillo, y libre. Permite cifrar las conexiones y tiene un plugin semi-oficial que nos permite bloquear las ips de ciertas entidades que actúan a modo de “polis malos de internet”.

Multimedia

Como antes, solo mencionaré los que me gustan.

  • Songbird : Un completo reproductor de música, con multitud de plugins. Podrás escuchar música, radios online, leer las letras de las canciones mientras las escuchas, sincronizar tus gadgets, cambiar su aspecto…
  • VLC : Uno de los mejores reproductores de vídeo del momento. Se distribuye de forma que no hace falta instalar códecs adicionales. La última versión es capaz de aprovechar aceleración por hardware en algunas tarjetas gráficas, con lo que el equipo podrá funcionar de forma fluida mientras visualizas películas.
  • Miro : Un programa para visualizar vídeo a través de Internet, particularmente no lo uso mucho porque paso mucho tiempo programando, pero es un buen programa para chafardear y encontrar cosas nuevas fácilmente.
  • LMMS : Pensado originalmente para Linux, ahora es multiplataforma. Es una especie de estudio para edición musical muy pero que muy chulo, supongo que habrá cosas más perfeccionadas en el aspecto técnico dentro del mundo del software cerrado, pero qué le vamos a hacer, a mi me gusta tal y como es.

Edición gráfica

  • The Gimp : Cómo no, el programa de retoque fotográfico más conocido del mundo del software libre, y el predecesor del proyecto Gnome. Ahora mismo la última versión estable es la 2.6 , tiene algunos defectos importantes, en parte causantes de su baja adopción entre artistas gráficos. El primero es su falta de soporte para los perfiles de color CMYK (aunque se espera que probablemente se le dé soporte en la próxima versión 2.8), el segundo es su interfaz, conformada por diversas ventanas independientes… y que nos puede llegar a marear. El segundo problema ya se ha solucionado en las versiones de desarrollo, aunque no hay todavía ninguna versión para Windows con ese cambio.
  • Blender : El programa que antes de ser libre fue usado en la película de Terminator 2 para crear el efecto de metal fundido del robot malo de la película. Actualmente la última versión estable es la 2.49 , pero ya está disponible la beta 2.53 , que incluye muchísimos cambios en la interfaz, y otros detalles internos que soy incapaz de describir por desconocimiento, aunque suenan espectaculares.
  • Inkscape : Un programa de dibujo vectorial, le queda mucho trecho por delante para ser perfecto pero es sin duda muy bueno en lo que hace.
  • Scribus : Un programa de maquetación, tal como Quark Express… solo que con menos fondos para ser desarrollado, así que no podemos esperar tanto, pero no todos necesitamos características demasiado avanzadas. Para trabajar perfectamente con él es bueno instalar Ghostscript previamente.

Desarrollo de software

  • Netbeans : Un muy buen IDE , permite trabajar con Java, C/C++, PHP… (y algunos lenguajes más que no recuerdo). Se integra perfectamente con Mercurial, SVN y CVS. Nos permite refactorizar de forma muy cómoda el código, detecta errores automáticamente en tiempo de desarrollo, se puede integrar bién con entornos de Unit testing…
  • Mercurial: Un sistema de control de versiones descentralizado, crear y mezclar ramas es pan comido con éste gran sistema. Es parecido a Git (que también tiene implementaciones en Windows, pero más fácil de manejar, aunque no es tan veloz ni versátil, es más que suficiente). Necesita tener instalado Python en el sistema.
  • Python : Uno de mis lenguajes interpretados preferidos, la sintaxis es muy bonita y se puede mezclar código al estilo funcional con código imperativo. Si se instala en Windows es preferible instalar dos versiones simultáneamente, la de la rama 3 (que debe ir por la 3.1 ..), y la de la rama 2.5 (que debe ir por la 2.7), por cuestiones de compatibilidad, pues con la rama 3 rompieron compatibilidad hacia atrás para poder mejorar algunos aspectos del lenguaje.
  • MonoDevelop: Otro de mis IDEs preferidos, desgraciadamente, igual que Netbeans, está escrito en un lenguaje no nativo. Aunque éste en C# al contrario que Netbeans, que está escrito en Java. Aunque es un poco extraño requiere funcionar sobre la plataforma .Net y no sobre Mono (en el caso de Windows).
  • Qt Developer: Sin duda uno de los mejores IDEs que he visto nunca, todo perfectamete integrado, resaltado de sintaxis, detección de errores, editor de GUIs, integración con 4 o 5 sistemas de control de versiones (entre ellos Git y Mercurial). ¿La pega? Está especialmente diseñado para C/C++, pero sobretodo para C++ con Qt. Aun así, tengo que decir que trabajar con Qt es una gozada.
  • Notepad++ : Un editor de texto sumamente versátil, con resaltado de sintaxis para muchísimos lenguajes, con plugins para actuar a modo de visor hexadecimal, permite trabajar con multitud de codificaciones, y alternar entre los diversos modos de salto de línea existentes (UNIX, Windows… y creo que hay otro, que no recuerdo).

Administración web

  • FileZilla : ¿Quieres conectarte a un servidor FTP, SFTP o FTPS? Aquí tienes la solución.
  • WinSCP : Otra solución parecida a FileZilla, aunque añade el protocolo SCP.

Software científico

  • wxMaxima / Maxima : Un sistema de cálculo simbólico bastante completo, wxMaxima nos proporciona una interfaz gráfica para Maxima. Podremos trabajar con matrices, resolver ecuaciones diferenciales (o sistemas de ecuaciones diferenciales), cómo no, también lineales, cuadráticas, cúbicas y cuárticas, graficar resultados (en 2 o tres dimensiones), encontrar vectores y valores propios de aplicaciones lineales o matrices, calcular límites, integrar, diferenciar, etc.
  • Texmaker : En realidad no se trata de software científico, sino de creación de documentos con el lenguaje LaTeX (basado en TeX) , pero dado que es utilizado sobretodo por científicos y técnicos he decidido ponerlo aquí. Tiene una interfaz muy cuidada y bastante bien pensada, nos permite crear documentos desde diversas plantillas predefinidas, cuenta con multitud de símbolos accesibles por si no nos acordamos de sus respectivos códigos, nos permite previsualizar el documento, y obviamente generar el PDF correspondiente… Creo que es la mejor opción para trabajar con LaTeX sobre Windows.
  • Marble : Un programa para poder visualizar el globo terráqueo, no es científico propiamente dicho, pero sirve para obtener información sobre el mundo en el que vivimos… así que ¿por qué no ponerlo aquí? Actualmente la última versión disponible para Windows es la 0.8 , mientra que la última desarrollada es la 0.10, que ha incorporado muchísimas mejoras en las dos actualizaciones sucesivas desde la versión 0.8. Pero supongo que es normal que de vez en cuando haya desincronizaciones en las releases cuando estamos tratando con programas multiplataforma, y más cuando los recursos son escasos.

Bueno, aquí he puesto unos pocos, tampoco demasiados, de los programas libres existentes para Windows. Hay muy buenos recopilatorios, como cdlibre.org , aunque encuentro a faltar allí valoraciones sobre la calidad del software (ya sea en cuanto a calidad técnica, usabilidad o estética). Y sobre todo, esto debería considerarse como un paso intermedio si se quiere libertad de verdad, algo útil para habituar a los usuarios, para que no sufran con la transición.

Comparte y disfruta:
  • Print
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Bitacoras.com
  • Identi.ca
  • Meneame
  • StumbleUpon
  • Technorati
  • Twitter
Tags: , ,
Comentario

Creando un framework con PHP ( II ) : Introspección

Filed Under: desarrollo web, framework, internet, introspección, php, programación, reflexión by castarco — 1 comentario
agosto 11, 2010

A la hora de usar frameworks los programadores esperan cierta magia, que las cosas funcionen sin tener que preocuparse por ciertos detalles nimios, y eso en gran parte se consigue gracias a los métodos de introspección (o reflexión, aunque prefiero el primer término), que en este caso nos son brindados por PHP.

Se podría decir que en PHP hay dos caminos para usar la introspección, el uso de ciertas funciones que aparecieron a partir de la versión 4 de PHP (siguiendo el paradigma de la programación estructurada) , o bien el uso de ciertas clases (y sus respectivos objetos, obviamente) que hicieron su aparición estelar con PHP 5.

Por diversos motivos, en el framework que estoy desarrollando he escogido el segundo camino (en realidad un mix, pero predomina la segunda opción), pero aquí comentaré los dos.

Introspección al estilo de PHP 4

Los primeros métodos que deberíamos conocer son los que nos permiten saber qué clases hay declaradas, o si una determinada clase está cargada ya en el contexto en el que nos encontramos, tenemos estos métodos:

  • get_declared_classes () : retorna una lista que contiene los nombres de todas las clases declaradas.
  • class_exists ($nombre_clase) : retorna verdadero o falso en función de si la clase pasada como parametro ha sido declarada o no. Como parámetro podemos pasar una cadena, o la propia clase si ya la conocemos. Ejemplo: 
    class Prueba {
}
class_exists ('Prueba'); // Retorna verdadero
class_exists (Prueba);   // También retorna verdadero

Una vez sabemos qué clases hay declaradas, también podríamos querer cómo son éstas por dentro, tenemos los siguientes métodos (creo que esta lista no es exhaustiva):

  • get_class_methods ($nombre_clase) : Nos devuelve una lista con los nombres de todos los métodos de la clase
  • get_class_vars ($nombre_clase) : Nos devuelve una lista asociativa con los nombres de las propiedades como claves, y los respectivos valores de las propiedades como elementos de la lista.
  • property_exists ($nombre_clase, $nombre_propiedad) : Nos indica si la clase tiene la propiedad que buscamos
  • get_parent_class ($nombre_clase) : Nos devuelve el nombre de la clase padre (si no hay clase padre, entonces devuelve una cadena vacía). También podemos usar objetos en este caso, no solo clases.
  • is_subclass_of ($nombre_clase, $nombre_clase_padre) : Nos indica si la clase hereda de la clase padre, también podemos usar objetos en este caso, no solo clases.

Podemos hacer prácticamente lo mismo, pero con objetos:

  • get_object_vars ($objeto) : Se parece mucho a get_class_vars , pero se diferencia en que los valores de las propiedades de los objetos pueden variar en tiempo de ejecución, y además se pueden añadir propiedades también en tiempo de ejecución.
  • method_exists ($objeto, $nombre_metodo) : Nos indica si el objeto tiene o no un método concreto

Y aquí nos quedamos, más o menos eso es todo. Antes había ciertas funciones que completaban la parrilla y eran bastante útiles, que servían, básicamente, para hacer uso de callbacks o ejecutar métodos de forma “dinámica”, pero fueron marcadas como obsoletas a partir de la versión 4.1 de PHP, por lo que no las comentaré.  El hecho de que “falten” ciertas funciones nos podría obligar a agudizar el ingenio.. o a abusar de funciones como eval , pero por suerte, en PHP 5 se introdujo una nueva forma de trabajar.

Introspección al estilo de PHP 5 ( clase Reflection )

En PHP 5 se introdujeron diversas mejoras, entre otras el tratamiento de errores se ha orientado más hacia el manejo de excepciones con bloques try-catch , y se han creado más clases que permiten trabajar de una forma mucho más orientada al paradigma de Orientación a Objetos, aumentando en cierta medida la cohesión del código resultante.

Una de las clases que fueron introducidas en esta versión fue la clase Reflection (y algunas otras que derivan de ésta). Todas ellas, cuando se produce algún error, lo que hacen es lanzar una excepción, simplificando la gestión y evitando que tengamos que interpretar el significado de los valores de retorno. Estas son las clases de las que hablaremos (un poco por encima):

Para hacer introspección o reflexión lo que debemos es construir un objeto a partir de una de estas clases, usando como parámetro en el constructor aquello que queramos “ver por dentro”. Por ejemplo:

$metainformacion_clase = new ReflectionClass ("nombre_de_la_clase");

a partir de aquí contamos con un montón de métodos (muchos más que los que había disponibles en PHP 4) que nos servirán para conocer todo cuanto queramos sobre la susodicha clase. Podéis ver los métodos disponibles en los enlaces que he hecho para cada una de ellas. Es interesante comentar que, algunos métodos devuelven objetos que a su vez también sirven para aplicar introspección, como getMethod ($name) o getProperty ($name) , que devuelven sendos ReflectionMethod i ReflectionProperty.

Uno de los métodos más interesantes de ReflectionMethod es el método invoke ($object, $params) , al cual le podemos pasar un objeto para el que queremos que se ejecute el método reflejado con los parámetros indicados. Esto sería “equivalente” a hacer la llamada (atentos, el ==== no es código, lo uso para indicar una cierta equivalencia):

$metainformacion_metodo->invoke($object, $params); ====  $object->metodo_reflejado($params);

Con ésto no es que se pueda zanjar el asunto de la introspección o reflexión, pero hay poco más interesante por decir, casi todo lo demás es simplemente conocer los nombres de las funciones y aplicarlas, así pues, deberíamos pensar en cómo toda esta parafernalia nos puede resultar útil para crear un framework con PHP. Lo veremos en el siguiente artículo, que este ya es suficientemente largo.

Comparte y disfruta:
  • Print
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Bitacoras.com
  • Identi.ca
  • Meneame
  • StumbleUpon
  • Technorati
  • Twitter
Tags: , , , , , ,
Comentario

Creando un framework con PHP ( I )

Filed Under: desarrollo web, framework, internet, php by castarco — 2 comentarios
agosto 10, 2010

Tengo una serie de artículos sobre optimización web a medio terminar, pero creí conveniente parar y tratar un poco la creación de frameworks para introducir posteriormente en la serie de artículos sobre optimización algo sobre cache.

Por eso mismo he estado desarrollando un mini framework en php (con la intención de hacerlo más ligero que, por ejemplo, cakephp) , y voy a ir contando mis experiencias sobre el asunto.

Introducción

El framework que por ahora mejor conozco es cakephp y ha influenciado bastante en mis decisiones a la hora de escoger un diseño u otro (tanto a la hora de escoger qué quería que tuviera, como a la hora de decidir qué me parece poco importante).

Sobretodo voy a listar qué es lo que no quiero para el framework que estoy haciendo (pues por querer, quiero demasiadas cosas y es una tontería escribirlas cuando ni tan siquiera sé si llegaré a implementarlas):

  • La excesiva “magia” que acababa implicando convenciones demasiado fuertes en cuanto a la nomenclatura, y una penalización en cuanto a rendimiento.
  • El acoplamiento excesivo entre modelos, controladores y vistas.
  • Que funcione sobre cualquier versión de PHP : utilizaré las características más novedosas que encuentre y no me preocuparé por la compatibilidad.
  • La forma en que está estructurado CakePHP provoca que no se puedan aprovechar correctamente las características del modelo de orientación a objetos.
  • Quiero evitar el abuso que se hace de los helpers, a veces me asusto cuando leo ciertos mensajes en la lista de correo de CakePHP española pidiendo ayuda sobre como crear simples enlaces o_o .

Pondré algunos detalles que sí quiero implementar, pero pocos:

  • Un mejor modelo de seguridad.
  • Un mejor modelo de control de errores.
  • Facilitar el unit testing.

Pasando a la acción

Todos los que hemos usado algún tipo de framework sabemos ya que éstos nos pueden llegar a facilitar mucho la vida a la hora de programar, pero lo que no todos saben es cuanta complejidad hay detrás de esas maravillas que nos simplifican el trabajo.

Empezemos por la parte “facil”, la creación de rutas bonitas para las subsecciones de nuestra página. Esta parte solo funcionará sobre Apache o servidores que utilicen ficheros de configuración compatibles, y que tengan el módulo mod_rewrite activado. Escribimos las siguientes líneas en el fichero .htaccess :

<IfModule mod_rewrite.c>


RewriteEngine On


RewriteCond %{REQUEST_FILENAME} !-d


RewriteCond %{REQUEST_FILENAME} !-f


RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]


</IfModule>

Lo que hacen estas líneas es redireccionar cualquier petición de la forma http://www.tuweb.com/seccion/subseccion/blabla a una petición de la forma http://www.tuweb.com/index.php?url=seccion/subseccion/blabla . Esto nos servirá para poder crear código que nos lleve a una sección u otra dependiendo del valor de la variable url, encapsulando en diferentes archivos el código necesario para gestionar cada sección.

Si queremos realizar una redirección similar en el servidor Cherokee debemos hacerlo desde el panel de administración (desgraciadamente Cherokee, aun siendo mucho más ligero que Apache y con un modo de configuración sorprendentemente fácil, no permite gestionar tan fácilmente las configuraciones en hostings compartidos).

En el siguiente artículo trataré el asunto de la introspección (o reflexión). Para los curiosos, podéis descargar e ir mirando el código del framework que estoy escribiendo en http://gitorious.org/pajarillo/ .

Comparte y disfruta:
  • Print
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Bitacoras.com
  • Identi.ca
  • Meneame
  • StumbleUpon
  • Technorati
  • Twitter
Tags: , , ,
Comentario

Optimización web ( IV ) : Caches ( I )

Filed Under: desarrollo web, diseño web, internet by castarco — 1 comentario
julio 20, 2010

Para los que quieran leer los capítulos anteriores:

  1. Optimización web ( I )
  2. Optimización web ( II ) : CSS Sprites
  3. Optimización web ( III ) : Minimizando archivos

A lo largo de los capítulos anteriores hemos repasado ciertas técnicas para reducir el peso de nuestras páginas, y en alguna medida, para reducir el número de peticiones HTTP. También explicamos brevemente algún que otro truco para reducir el tiempo de renderizado de la página que no estaba íntimamente ligado con su tamaño o el número de peticiones HTTP. A algunos podría parecerles suficiente (espero que a pocos, dentro del mundo de la informática deberíamos ser siempre poco conformistas), pero el abanico de técnicas no se acaba aquí.

Hoy empezamos una subserie de artículos dedicados a los mecanismos de cache a diferentes niveles (dentro del contexto de la creación de páginas web). La palabra cache se usa dentro de muchos contextos y con significados muy diversos, pero todos ligados por una definición algo vaga y generalista, que es la siguiente (sacada de Wikipedia): “Una cache es un conjunto de datos duplicados de otros originales, con la propiedad de que los datos originales son costosos de acceder (comparativamente con el coste de acceder a la copia del dato en cache)“.

¿Y en qué contextos usaremos nosotros las caches? Pues en diversos:

  1. Para no tener que solicitar ciertos recursos al servidor cada vez que recarguemos la página (imágenes, archivos CSS, archivos JS, algunas páginas estáticas… (cache del lado del cliente, o de proxies intermedios)
  2. Para no tener que hacer tantas peticiones a las bases de datos de la página cuando un dato es accedido muchas veces en modo lectura y no acostumbra a ser modificado… (cache del lado del servidor)
  3. Para no tener que generar ciertas páginas dinámicamente (con PHP, ASP, Java, Python, etc) cuando éstas cambien muy pocas veces a lo largo del tiempo… (cache del lado del servidor)

Empezaremos con las caches del lado del cliente. Antes de continuar debo indicar que, desgraciadamente, lo que explicaré a partir de ahora no es para nada universal, dependiendo de las tecnologías que uséis os resultará útil o no. Los conceptos generales sí que son válidos para cualquier opción que escojáis, pero las implementaciones no.

Después de asustar a unos pocos debo decir también que lo que sigue será útil para la mayoría (en el capítulo de hoy), trabajaremos con el servidor web Apache y PHP.

Para evitar volver a descargar ciertas imágenes y otros ficheros cada vez que recargamos la página hoy en día podemos encontrar como mínimo dos mecanismos con cierta importancia: las marcas de tiempo y las ETags (entity tags).

Vistas por encima, las marcas de tiempo vienen a ser ciertos datos adjuntos en las cabeceras de los mensajes HTTP que indican cuanto tiempo se podrá guardar un recurso concreto descargado sin tener que volver a solicitarlo. Por ejemplo, si adjuntamos una marca de tiempo que indique que cierta imagen será válida durante un día entero, ésta no volverá a ser descargada durante un día cada vez que se recargue la página.

El problema de las marcas de tiempo es que son algo inflexibles, si por alguna razón queremos modificar un recurso concreto puede darse el caso de que muchos navegantes sigan trabajando con una copia antigua de éste durante un tiempo. Pero tenemos el otro recurso que he mencionado anteriormente, las ETags. Éstas son tambien metainformación adjunta en las cabeceras de los mensajes HTTP que sirven para indicar si un recurso ha sido modificado o no. ¿Cómo se hace? Pues bien, se le adjunta un identificador largo a cada recurso de forma que, si este es modificado, el identificador cambie también. Si el navegador ha obtenido ya un recurso con una ETag, cuando quiera volver a recargar la página no enviará una petición GET (que sirve para pedir un recurso), sino una petición HEAD (que es casi como GET, pero que sirve solo para obtener la metainformación y no el recurso completo). Como respuesta a la petición HEAD le llegará la cabecera HTTP con la metainformación deseada, que nos indicará si el identificador del recurso ha cambiado o no, de manera que en caso de permanecer invariante no tendremos que malgastar recursos de red.

Ahora, habiéndoos explicado la mecánica general, os explicaré una implementación concreta del mecanismo de marcas de tiempo. ¿Cómo, por qué? ¡Pero si las ETags molan mucho más! Sí, pero también son algo más complicadas y creo que se merecen un capítulo a parte.

Para conseguir que nuestro servidor adjunte las marcas de tiempo podemos hacerlo mediante los ficheros .htaccess (recordad, estoy hablando de Httpd Apache y de PHP), la verdad es que es bastante sencillo, aquí os dejo un ejemplo y pasamos a comentarlo:

ExpiresActive On
ExpiresDefault A0


<FilesMatch ".(gif|jpg|jpeg|png|swf|ico)$">
ExpiresDefault A2764800
Header append Cache-Control "public"
</FilesMatch>


<FilesMatch ".(js|css)$">
ExpiresDefault A2764800
Header append Cache-Control "private"
</FilesMatch>

Estas líneas deberían añadirse al fichero .htaccess que tengamos en la carpeta raíz de nuestra página web. La primera línea nos indica que activamos el mecanismo de las marcas de tiempo. La segunda línea nos sirve para decir que los ficheros expirarán a los 0 segundos (notad el 0 del final), es decir, que por lo general no deberían guardarse en la cache del navegador.

Seguidamente nos encotnramos con un bloque algo más compacto, que es muy parecido al que le sigue. En la primera línea indicamos las extensiones de archivo para las cuales estamos definiendo una configuración concreta. En la segunda línea indicamos el número de segundos que deberían mantenerse los ficheros con esa extensión en la cache del navegador antes de solicitar una nueva copia, en nuestro caso concreto ese número de segundos equivale a 32 días. La tercera línea es muy importante, sirve para indicar si los datos pueden ser cacheados por proxies intermedios o solo en nuestro navegador, si utilizamos la directiva “public” los servidores proxy de nuestro ISP podrían guardar una copia del recurso para servirlo más rápidamente a otros clientes, si utilizamos la directiva “private” solo nuestro navegador guardará copia.

Aquí debo hacer una pequeña digresión: Los ISP pueden vulnerar dichas políticas si quieren (otra cosa es que sea legal o no, y es depende de las legislaciones locales), aunque por lo general acostumbran a respetar lo que se indica en las cabeceras (dentro de lo posible). Es sabido por casi todos que actualmente nuestros proveedores de acceso a Internet están casi obligados a espiarnos, guardando datos sobre nuestra navegación durante más de medio año (en Europa), pero eso no hace que esos datos puedan ser enviados a otros clientes como si estuvieran dentro de una cache.

Extra ( Compresión )

Hubiera sido interesante añadir esto en los capítulos dedicados a reducir el “peso” de las páginas web, pero he esperado porque era importante introducir el concepto de cache antes. Utilizamos imágenes comprimidas, reducimos el tamaño de nuestras páginas web.. pero ¿por qué no las comprimimos directamente antes de enviarlas? Bien, es una buena pregunta. De hecho sí que se acostumbra a hacer. Los ficheros de texto tienen la propiedad de ser altamente redundantes, lo que implica que se pueden comprimir muchísimo de forma sencilla, así pues, os explicaré un pequeño truco para enviar ciertas partes de vuestra web comprimidas para salvar ancho de banda y reducir los tiempos de transmisión (aunque con el pequeño coste de tener que comprimir y descomprimir).

Os dejo otro trozo de fichero .htaccess junto con un fichero .php que juntos sirven para conseguir ese objetivo.

.htaccess

# Activa la compresion en el servidor
php_flag zlib.output_compression On
# Indica el nivel de compresion de 1 a 9 (de menor a mayor compresion)
php_value zlib.output_compression_level 5
# Indica sobre que extensiones se aplica la compresion
AddHandler application/x-httpd-php .css .js

php_value auto_prepend_file /ruta/contentHeader.php

Éste trozo de código ya está casi comentado del todo, a excepción de la última línea. Lo que hacen estas líneas es activar la compresión (de nivel 5 en este caso) para los ficheros con extensión CSS y JS, aquí aparecen dos problemas:

  1. Se debe indicar en las cabeceras el MIMETYPE de los ficheros enviados ya que al comprimirlos el navegador puede confundirse.
  2. Al añadir un manejador específico para los ficheros CSS y JS después de las líneas dedicadas a las marcas de tiempo, éstas quedan invalidadas para estas dos extensiones.

Por todo estos puntos utilizamos la línea auto_prepend_file /ruta/contentHeader.php, que nos servirá para añadir al principio del fichero que enviamos la salida generada por contentHeader.php, siendo la salida las cabeceras específicas que necesitamos. Vamos entonces a escribir ese fichero:


<?php
$pi=pathinfo($_SERVER['PHP_SELF']);
$ext=$pi['extension'];
if($ext=='css')header("Content-type: text/css");
elseif($ext=='js')header("Content-type: text/javascript");
header('ExpiresDefault "access plus 31 days"');
?>

Este script identifica la extensión del archivo, y en función de esto añade una cabecera u otra indicando el MIMETYPE correspondiente, finalmente añade una cabecera con una marca de tiempo.

Espero que os haya resultado útil, hasta la próxima.

Comparte y disfruta:
  • Print
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Bitacoras.com
  • Identi.ca
  • Meneame
  • StumbleUpon
  • Technorati
  • Twitter
Tags: , ,
Comentario

Optimización web ( III ) : Minimizando archivos

Filed Under: desarrollo web, internet by castarco — 1 comentario
julio 16, 2010

Para los que queráis ver los artículos anteriores de ésta serie:

En este capítulo no apuntaremos muy alto, pero introduciremos una “nueva” herramienta (para los que no la conozcáis, claro está) y seguiremos en la misma línea de intentar reducir el peso de la página. En capítulos posteriores introduciremos otras técnicas complementarias que ya no consistirán en “aligerar” la página.

Texto plano : CSS y JavaScript

A medida que hacemos que nuestra página web sea más y más dinámica y vayamos refinando su estilo los archivos JS y CSS de nuestro sitio crecerán hasta llegar a alcanzar tamaños considerables para tratarse de simples archivos de texto plano. Podéis ver por ejemplo el tamaño de jQuery o Prototype, las dos librerías son bastante pesadas en cuanto a tamaño.

Ciertos programadores de Yahoo decidieron entonces crear una herramienta, el YUI Compressor . Podéis obtenerla desde su página oficial o bien, si estáis usando Debian o Ubuntu (supongo que también estará disponible en Fedora y otras distros) podéis instalarla mediante el instalador apt:

apt-get install yui-compressor

Esta herramienta nos servirá para eliminar todo aquello cuanto sea innecesario en nuestras hojas de estilo y ficheros de script. El problema es que lo hará eliminando espacios, puntos y coma donde pueda, saltos de línea… incluso a veces modificando los nombres de algunas variables internas en funciones para acortarlos. No hará lo mismo con los nombres de las funciones ya que si lo hiciera el fichero de script se tornaría inútil ¡Ni una de las llamadas realizadas desde la página funcionaría!

La forma de hacerlo funcionar (funciona sobre la línea de comandos) es bien sencilla:

yui-compressor fichero_que_quiero_minimizar.css -o nombre_de_nuevo_fichero_minimizado.css

Lo mismo se aplica a los ficheros con extensión .js , aunque yui-compressor dispone de algunas opciones específicas más para esta extensión. Si queréis conocer las opciones de yui-compressor solo tenéis que llamarlo con la opción –help .

Importante: YUI-Compressor no se lleva bien con el CSS no estándar, es decir, si os da por probar características aun experimentales como los gradientes de Firefox, Chrome, Safari u Opera entonces tendréis que ir con más cuidado para evitar que YUI-Compressor os estropee vuestros CSS .

Quiero destacar que, dado que probablemente vayáis a estar desarrollando la web al mismo tiempo que ésta ya esté online y siendo visitada por surferos de la red, el tener código ofuscado por esta herramienta os pueda parecer sumamente molesto aunque os permita reducir el tiempo de envío de los ficheros. Lo que recomiendo en estos casos es no subir directamente lo que tengáis en vuestro directorio de trabajo al servidor sino que tengáis un directorio intermedio donde haya las versiones optimizadas de dichos archivos. Una opción para hacer llevadero este sistema es que os hagáis un script que os sincronice los dos directorios (en una sola dirección, claro) a la vez que os comprime las hojas de estilo y los ficheros de script con yui-compressor de forma automatizada. Al principio puede parecer un rollo hacerse el script, pero a la larga simplifica muchísimo el trabajo y ahorra más tiempo aun.

Imágenes: paletas indexadas

En el capítulo anterior ya hice algunas referencias a las imágenes con paletas indexadas ¿pero qué son exactamente? Intentaré no extenderme con la explicación mucho porque esto es más propio del estudio de gráficos por computador que del diseño de páginas web. Para los que ya sepáis a qué me refiero podéis saltar directamente a la parte práctica, donde comento el caso práctico con GIMP.

Los ordenadores actuales acostumbran a representar internamente los colores mediante tres números (generalmente enteros), uno para cada color luz “básico”. Éstos colores luz básicos son el rojo, el verde y el azul, y por eso llamamos al esquema de representación mencionado RGB (Red Green Blue). Combinando dichos colores podemos obtener “todos” los demás ( en realidad es falso, pero a nivel perceptivo podríamos decir que es cierto ). Normalmente se usan números del 0 al 255, siendo el 0 el número que indica intensidad mínima y el 255 la máxima. Así el color blanco estaría representado por la terna (255, 255, 255). Cada uno de estos números cabe en un byte, por lo que para representar el color de un solo píxel necesitamos 3 bytes.

El sistema mencionado conlleva un problema: las imágenes acaban pesando demasiado. Por eso mismo se inventaron formatos de imágen en los que se aplican ciertas técnicas de compresión, como JPEG, GIF o PNG. JPEG aplica compresión “con pérdida”, lo que significa que se pierden ciertos detalles poco importantes de la imagen a cambio de una reducción drástica en su tamaño, mientras que en otros formatos se usa compresión “sin pérdida”. No “perderé el tiempo” explicándoos como funcionan los sistemas de compresión (en general) porque necesitaría introducir la Teoría de la información y entonces no acabaríamos nunca.

Pero sí os explicaré un sistema de compresión de imágenes muy básico y fácil de entender, el indexado de colores. En el caso de tener una imagen con una cantidad relativamente pequeña de colores nos podemos plantear una forma sencilla para reducir su tamaño: hacer una lista de colores de forma que para cada uno haya un número determinado por su posición en la lista. Si la lista tiene 255 o menos colores podremos representar cada pixel con un solo byte en vez de con 3, pues sólo tendremos que usar un número y no 3 para indicar su color. Si tuviéramos 16535 (256×256-1) o menos colores en nuestra lista, podríamos usar 2 bytes en vez de 3 para representar cada píxel, la reducción no es tanta en este caso, pero sigue siendo considerable. ¿Y solo se puede reducir en un factor de 3 el tamaño de la imagen? No, de hecho podemos reducir aun más el tamaño de la imagen, pero en este caso la lista de colores debería ser más pequeña. Por ejemplo, si tuvieramos 127 o menos colores podríamos reducir en un factor de 6 el tamaño de la imagen (descontando el pequeño añadido en tamaño debido a la lista de colores), si tuvieramos 63 o menos colores podríamos reducir en un factor de 12 el tamaño de la imágen, y así. Supongo que podéis ver fácilmente el patrón.

Práctica

Es interesante saber como reducir el tamaño de nuestras imágenes sin perder demasiada calidad. Una forma sería guardar nuestras imágenes en formato JPEG con una calidad inferior o igual al 85%. En cualquier editor gráfico que se precie podréis seleccionar la calidad de salida del fichero JPEG si hacéis “Guardar como…” o “Exportar”.

El problema de la opción JPEG es que sirve más para imágenes grandes o fotografías que para elementos de la web, en los que probablemente querremos más nitidez. Por suerte, aunque queramos más nitidez también se dará el caso de que usamos menos colores y las imágenes serán más pequeñas, en este caso es aconsejable usar imágenes con paletas indexadas. Indicaré como hacerlo en GIMP, hace tiempo que no toco Photoshop y no sabría deciros qué pasos exactos deberéis seguir los que lo uséis, pero seguramente será también bastante intuitivo.

En primer lugar debéis acceder al menú de Imagen e ir a seleccionar un modo:

Seleccionando modo de imagen

Una vez ahí podréis seleccionar cuantos colores queréis que haya en la paleta. A veces se dará el caso de que la imagen tenga más de 255 colores (en este caso las paletas pueden tener solo 255 colores, aunque en la teoría se pudieran tener paletas más grandes), en dicho caso podéis optar por perder algo de calidad eliminando algunos colores (el editor intentará aproximarlos lo mejor posible con los colores de la paleta) o renunciar al indexado de colores.

Conversión paleta

Después solo tendréis que guardar la imágen (recomiendo el formato PNG por encima de GIF), si usáis las nuevas versiones de Gimp tendréis que usar la opción Exportar y no Guardar, pues ésta se ha dejado solo para el formato nativo de Gimp, XCF .

Consejo final (fuera de contexto)

Lo que escribiré ahora debería haber estado en capítulos anteriores, pero me despisté. Aunque sea recomendable reducir la cantidad de ficheros que deben ser cargados para visualizar la página, hay algunas excepciones que vale la pena mencionar. Tal es el caso de las imágenes redimensionadas, no conviene redimensionar una imagen en tiempo de renderizado dentro de la web, es decir, no es conveniente ajustas las medidas de una imagen a otras que no sean las suyas. El tiempo que tarda el ordenador del visitante en redimensionar hace que su experiencia pueda verse mermada, es preferible tener distintas versiones de la imagen adaptadas a los tamaños pertinentes. Es usual que las redimensiones se den cuando se quieren hacer thumbnails, y también es usual que cuando se está visualizando el thumbnail no se esté visualizando simultáneamente la imagen a tamaño real, por lo que (generalmente) no supondrá un problema en cuanto aumento de peticiones HTTP tener versiones específicas de la imagen para cada tamaño.

Espero que os haya resultado útil, un saludo :) .

Comparte y disfruta:
  • Print
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Bitacoras.com
  • Identi.ca
  • Meneame
  • StumbleUpon
  • Technorati
  • Twitter
Tags: ,
Comentario

Optimización web ( II ) : CSS Sprites

Filed Under: desarrollo web, internet by castarco — 4 comentarios
julio 15, 2010

Continuamos la serie sobre optimización web empezada en el artículo “Optimización web ( I )“ .

En este capítulo trataremos una técnica que viene siendo usada desde mucho antes de la aparición de la web dentro del mundo de la programación, en concreto dentro del mundo de los videojuegos, y en algunas ocasiones en la creación de interfaces gráficas. Los que ya sepáis algo sobre eso y hayáis leído el título, como buenos lectores que sois, ya debéis saber a qué me refiero, para los que el título no les diga mucho os daré una breve explicación.

La técnica de trabajar con sprites está relacionada con la presentación de imágenes por pantalla, por lo general pequeñas. Usualmente, tanto en webs como en videojuegos, acabamos teniendo conjuntos enormes de imágenes. Cada una de estas imágenes acostumbra a tener un fichero asociado (siempre y cuando no estemos usando ya la técnica de los sprites) y eso tiene bastantes implicaciones (negativas) en el rendimiento de nuestra página o videojuego.

En el caso de los videojuegos las desventajas son varias:

  • Por cada imagen se tiene que hacer una lectura de disco, además, el hecho de que estén en ficheros separados puede implicar fácilmente que las imágenes estén alejadas unas de otras (físicamente) sobre el disco. No es que se trate de fragmentación, pero a efectos prácticos conlleva casi los mismos problemas de lentitud.
  • Normalmente, siempre y cuando el programador o grafista no tenga problemas neuronales o de visión, las paletas de colores de cada imagen serán muy parecidas entre ellas (habrá paleta si y solo si usamos un esquema de colores indexados, lo que se hace para reducir el tamaño final de la imágen, aunque implica que podamos usar menos colores que usando directamente el esquema RGB). El hecho de que no se compartan esas paletas implica que se carga información redundante en memoria por cada imágen que leemos desde el disco (lo que implica un mayor consumo de memoria).

En el caso de las páginas web, los problemas pueden llegar a ser incluso peores:

  • A parte de que el servidor tiene que hacer bastantes lecturas de disco por cada página web cargada (sí, ya sé que muchos los cargará en alguna caché en memoria y todo eso, pero si el sitio web es mínimamente grande los contenidos de la cache irán rotando, y si el sitio está alojado en un hosting compartido la cosa será más complicada aun) también tendrá que hacer más envíos al navegador del visitante para que éste pueda visualizar la página web por completo. Y ahí es donde está el gran problema, los tiempos de lectura de disco son casi despreciables si los comparamos con los tiempos de envío a través de la red, pues no se envía solo la imágen, sino que además también se envían sus respectivas cabeceras HTTP, lo que incrementa la cantidad de información a enviar.
  • Como antes, el navegador consumirá más memoria para mantener esas imágenes, esto ahora mismo no supone un gran problema porque los ordenadores personales cada vez tienen más memoria principal, pero también es importante decir que los usuarios se están acostumbrando a abrir cada vez más pestañas en sus navegadores… y aquí el consumo de memoria se dispara y su importancia (aunque sigue siendo poca) crece algo más.
  • Si se tienen elementos mínimamente dinámicos, como botones pulsables que cambian su imagen de fondo cuando se pasa el ratón por encima o cuando se hace click sobre ellos puede aparecer un problema estético muy importante, resulta que dado que la página no debía cargar la imagen en el primer momento de renderizado… casi en todos los navegadores se da el hecho de que ésta no se descarga hasta el momento de ser necesitada. Esto implica que en el momento de pasar el ratón por encima del susodicho botoncito nos encontraremos con que la imágen no cambia inmediatamente (la primera vez que lo hagamos), habrá un retraso perceptible bastante antiestético y que puede llegar incluso a confundir al visitante, pues puede tener la sensación de que el elemento está bloqueado o algo por el estilo.

El primer punto junto con el tercero son los que más motivan la técnica de los CSS Sprites, que paso a comentar seguidamente.

La técnica de los CSS Sprites consiste en combinar un conjunto de imágenes en una sola, formando una especie de mosaico, para luego mostrar solo las partes que nos interesen de ella en ciertos elementos de la web. Cargar una sola imagen nos ayudará a reducir la cantidad de peticiones HTTP, eliminará el problema del retraso comentado anteriormente, y en muchas ocasiones también nos servirá para reducir el tamaño total de las imágenes (porque, en el caso de tener una paleta de colores indexada es probable que compartan una gran parte de ésta). Tengo que decir que, aunque en la mayoría de casos podamos conseguir el beneficio extra de reducir el tamaño total de las imagenes, esto no siempre es así y a veces puede pasar incluso lo contrario, aun así los beneficios de reducir la cantidad de peticiones HTTP compensarían esta penalización.

Si nos fijamos, la mayoría de páginas web ultrarápidas que nos puedan pasar por la cabeza usan ésta técnica, el ejemplo paradigmático de página web ligera es la del buscador de Google. Os muestro una de las imágenes que usan para aplicar la técnica:

sprites de google

Y ahora viene la parte interesante, he hablado mucho pero todavía no he explicado como hacer esto. ¿Como se hace pues? Pues no hay una fórmula exacta, pero intentaré sentar las bases para que cada uno pueda aplicar las variaciones que considere pertinentes.

Para facilitar las cosas empezaremos con elementos de tamaño fijo, supongamos que tenemos un elemento div con tamaño 32×32, y tenemos en una imágen un set de iconos de 32×32 .. no sé, unas ocho filas por ocho columnas de iconos, unos 64. Supongamos también que queremos que el fondo de dicho elemento div sea el icono situado en la fila 6 y columna 5. Lo que escribiremos en la hoja de estilos CSS es:

background:url(/ruta/a/la/imagen.png) no-repeat -160px -192px }

Analizemos este trozo de código. la primera parte background nos indica que vamos a definir los atributos del fondo del elemento. url(/ruta/a/la/imagen.png) nos indica la imagen donde buscaremos nuestro fondo. -160px es la cantidad de pixels que nos tendremos que desplazar horizontalmente sobre la imagen que contiene los sprites para encontrar el fondo que queremos (5×32, 5 columnas), -192px ídem, pero para las filas. El elemento no-repeat nos indica que no queremos que la imagen se repita a modo de mosaico.

Aquí es importante destacar que debemos definir el tamaño del elemento al que queremos poner fondo para que no aparezcan a continuación de la imagen que queríamos mostrar todas sus “compañeras de viaje”. Otro punto interesante es que el elemento no-repeat podría ser cambiado por repeat-x o por repeat-y en algunos casos, como cuando queremos dibujar fondos periódicos o dibujar los contornos de alguna caja con tamaño variable (dependiendo del contenido). En este caso la distribución de las imágenes dentro de la imagen contenedora es muy importante, pues si hacemos un repeat-x y tenemos otras imágenes a la izquierda o la derecha de la que queremos repetir, el efecto que queríamos conseguir será estropeado. Ídem con el caso de repeat-y.

Esta técnica puede ser usada para crear menus, para personalizar las “bolitas” de las listas, para dibujar los bordes y el fondo de cajas con tamaño variable, para mejorar el efecto de elementos pulsables, etc.

Un saludo, y hasta la próxima entrega.

Comparte y disfruta:
  • Print
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Bitacoras.com
  • Identi.ca
  • Meneame
  • StumbleUpon
  • Technorati
  • Twitter
Tags: ,
Comentario

Optimización web ( I )

Filed Under: desarrollo web, internet by castarco — 6 comentarios
julio 13, 2010

Hace muchísimo que no escribo ningún artículo técnico por aquí, y más aun que no escribo ninguna reflexión. Pero se acabó lo que se daba, a partir de ahora intentaré actualizar más frecuentemente el blog y hoy voy a empezar una pequeña serie de (también pequeños) artículos sobre optimización de páginas web.

Introducción

Cuando desarrollamos páginas web nos encontramos con decenas sino cientos de problemas a medida que avanzamos. Los que acostumbran a ser más usuales son los relacionados con la maquetación y el tan temido Microsoft Internet Explorer, otras veces tenemos problemas con el lenguaje de scripting en el lado del servidor, y otras con la base de datos… pero de lo que casi nunca nos salvamos (y pocas veces nos damos cuenta, al menos cuando somos aprendices) es de los problemas relacionados con el tiempo de carga y renderizado de la página.

Los tiempos de carga excesivos no son tan vistos como un problema debido a que no afectan al buen funcionamiento de las páginas y en parte también a nuestra experiencia con líneas de baja velocidad antes de la irrupción de ADSL y otras tecnologías de banda ancha, vamos, que estamos acostumbrados a sufrir y no lo notamos tanto. Aun así, y aunque los visitantes toleren bastante la lentitud, deberíamos encontrar la causa del ralentizamiento para atajarla.

Motivación

  • Los visitantes se sienten más satisfechos cuando nuestro sitio carga rápida y fluidamente, lo que, en gran cantidad de contextos, nos puede reportar una mayor cantidad de beneficios económicos.
  • Por lo general, hacer páginas rápidas y fluidas sirve también para consumir una menor cantidad de recusos del servidor por visita, lo que nos puede ahorrar costes económicos o bien permitirnos atender a más visitantes.
  • Parece ser que la velocidad de carga de los sitios será un factor más a tener en cuenta por parte de algunos buscadores para el posicionamiento de las webs.
  • Y el que nos debería importar más a los geeks: Hacer páginas web fluidas es síntoma de saber hacer bien las cosas, de un buen nivel técnico, y cuando todavía no se sabe como conseguirlo, supone un reto interesante.

Primeros pasos

Empezaremos con consejos aplicables a prácticamente cualquier tipo de página, servidor, framework de desarrollo, lenguaje de scripting en el lado del servidor… vamos, que iniciaremos la lista de consejos con algunos bastante universales y, siento decirlo, algo aburridillos (tranquilos, no faltarán consejos interesantes de verdad más adelante).

  1. Intentad hacer vuestras páginas lo más pequeñas que os sea posible. Con esto no me refiero a que hagáis que las letras sean pequeñas, como supongo que habréis entendido, sino a que el tamaño del documento que envía el servidor web debería ser pequeño para que éste tarde el mínimo tiempo posible en enviarlo.
  2. Para conseguir el punto anterior es muy importante que vuestro código sea limpio y conforme a los estándares, en particular: evitad usar tablas para tabular los elementos de vuestras páginas, para eso están los elementos div y span, y como no, las hojas de estilo en cascada (CSS).
  3. Es interesante unificar todos los estilos de la página en un único archivo css, que podrá ser compartido entre diferentes secciones de ésta, de forma que solo se tendrá que descargar una vez la información de estilos y se podrá reutilizar para varias páginas de vuestro sitio.
  4. Reducid la cantidad de ficheros a descargar para visualizar vuestra página, es decir, usad cuantos menos ficheros de imagen mejor, cuantas menos hojas de estilo, mejor, y cuantos menos ficheros de script, mejor también. Esto es muy importante debido a que cada petición HTTP implica una sobrecarga importante en el envío de información. La sobrecarga es debida a que, además de los ficheros en sí, se tienen que enviar también cabeceras con cierta metainformación, por lo que se pierde mucho tiempo enviando información “inútil”. Otro problema asociado es que las descargas son, en cierta medida, bloqueantes. El protocolo HTTP impone un límite de descargas simultáneas por página, por lo que éstas no se pueden paralelizar y se tienen que hacer una detrás de otra, provocando el retraso en la carga.
  5. Ahora uno de los más extraños (por ser el menos evidente): Intentad situar el código JavaScript cuanto más cerca del final del documento, mejor. Esto es importante debido a que los navegadores pierden tiempo interpretando y ejecutando el código cuando lo encuentran, siendo esta tarea también bloqueante. Así pues, si situáis el código JavaScript al final de vuestras páginas conseguiréis que sean renderizadas antes, mejorando la experiencia del usuario.

Herramientas

Aunque todavía tengo que explicar muchas cosas en esta serie de artículos, creo que puede ser conveniente para los que queráis ir más rápidos una lista de herramientas muy útiles que os ayudarán a encontrar más puntos a mejorar en vuestros sitios web.

  • Speed Tracer: es una extensión para el navegador Chrome / Chromium creada por Google , nos permite ver el tiempo de carga del sitio web desglosado elemento por elemento para identificar algunos cuellos de botella de nuestro sitio. También da algunos pequeños consejos para mejorar la web cuando detecta fallos.
  • YSlow: es una extensión para el navegador Firefox creada por Yahoo que, a mi parecer, junto con Speed Tracer forma un tandem perfecto. Se necesite instalar la extensión Firebug antes que ésta. Asigna una nota a la página que evaluamos mediante una media ponderada de puntuaciones sobre ciertos aspectos de ésta. No solo da puntuaciones, también es una herramienta a la que parece encantarle dar consejos, y muy buenos por cierto, aprendí bastante de ella xD, fue algo así como mi profesora. Los gráficos que genera ni son tan bonitos ni útiles como los de Speed Tracer, pero a cambio la información realmente útil se muestra mucho más digerida y apta para ser utilizada directamente.
  • Page Speed: otra extensión creada por Google, pero esta vez para Firefox, que parece ser una mezcla entre YSlow y Speed Tracer, ésta muestra directamente una lista de consejos que deberíamos seguir, y los marca en rojo, amarillo o verde segun considere si ya lo estamos haciendo o no.

Hay muchas más herramientas  que podrían resultar útiles, pero estas son las más remarcables dentro del panorama actual… y ciñéndonos a las herramientas que nos dan información o consejos. Hay otras herramientas que comentaré en los siguientes artículos y que no listo aquí porque prefiero presentarlas dentro de un contexto más adecuado.

Espero que os haya resultado útil y/o interesante, un saludo :) .

Comparte y disfruta:
  • Print
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Bitacoras.com
  • Identi.ca
  • Meneame
  • StumbleUpon
  • Technorati
  • Twitter
Tags: ,
Comentario

Natureza, un nuevo negocio de venta online

Filed Under: desarrollo web, natureza by castarco — 2 comentarios
junio 19, 2010

Por fin, después de más de 4 meses, escribo algo por aquí. A lo largo de este tiempo he estado desarrollando un sitio web para un negocio llamado Natureza, es la primera web comercial que desarrollo y he aprendido mucho por el camino.

En estos momentos estoy loco por escribir cientos de artículos técnicos sobre desarrollo web y otras historias, pero todavía no es el momento, sigo teniendo mucho trabajo pendiente y eso es lo prioritario ahora mismo.

En todo caso, después de todo el trabajo que ha habido (y del que queda), no puedo dejar de mencionar la página en sí. Podéis verla vosotros mismos en http://www.natureza.es . Todavía es mejorable en muchos aspectos (y en ello estoy), pero ya os podéis registrar como socios y hacer compras.

La página en sí es para un negocio de venta de productos cosméticos desarrollados de forma natural. La empresa fue creada por Maria Beatriz Spaltro, una mujer muy emprendedora, con muchas ganas de trabajar y con una cabeza rebosante de ideas. Pero hay una cualidad más que no puedo olvidar: su gran paciencia, pues un servidor ha incumplido plazos de entrega unas cuantas veces (no por que sea vago, si no porque voy un poco apretado todo sea dicho), y aun así ha sido muy comprensiva.

Bueno, os dejo que tengo mucho trabajo, un saludo!

Comparte y disfruta:
  • Print
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Bitacoras.com
  • Identi.ca
  • Meneame
  • StumbleUpon
  • Technorati
  • Twitter
Tags: ,
Comentario

Cómo instalar Cantor en Ubuntu Karmic

Filed Under: matematicas, software libre by castarco — 1 comentario
febrero 8, 2010

Cantor és una aplicación científica/educativa creada para el escritorio KDE (aunque puede funcionar fuera de éste). Su objetivo es aglutinar y simplificar el uso de otro software matemático, como Sage, Maxima o KAlgebra. El principal problema para usar Cantor ahora mismo es que casi ninguna distribución de Linux actual lo ha incorporado en sus repositorios oficiales ya que es muy nuevo (será lanzado dentro de la versión 4.4 del escritorio KDE).

Por suerte han creado un repositorio PPA en Launchpad, así que “solo” tendremos que añadir el repositorio a la lista de repositorios e instalar cantor. Ahí van los comandos:

sudo add-apt-repository ppa:kubuntu-ppa/beta
sudo aptitude update
#Este paso no es estrictamente necerario, pero lo recomiendo: aptitude safe-upgrade
sudo aptitude install cantor

Cuando he dicho “solo” ha sido porque aparecerán algunos problemas. Resulta que cantor depende de muchos paquetes de KDE4.4, del que solo hemos visto sus versiones RC hasta el momento, y que tampoco ha sido incorporado en ningún repositorio oficial de ninguna distribución. Ésto conlleva que al instalar Cantor, deberemos actualizar multitud de paquetes y en algun momento aparecerán conflictos por resolver (bueno, solo si tenéis alguna aplicación de KDE instalada previamente claro). No puedo dar una explicación estandar para resolver esos problemas, pues cada uno se encontrará con problemas de dependencias diferentes en función al software que tenga o no tenga instalado en su sistema, en todo caso creo que el problema no es demasiado grave (al menos para los experimentados):

Saludos!

Comparte y disfruta:
  • Print
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Bitacoras.com
  • Identi.ca
  • Meneame
  • StumbleUpon
  • Technorati
  • Twitter
Tags: ,
Comentario

Jugando con jQuery

Filed Under: desarrollo web, internet, jquery, programación by castarco — 1 comentario
febrero 8, 2010

Por motivos varios estoy aprendiendo a manejar la librería jQuery, que sirve para dar dinamismo a páginas y aplicaciones web con una buena mezcla de Javascript, AJAX y CSS, y a modo de guinda, nos abstrae de las incompatibilidades entre navegadores. No voy a escribir una introducción a jQuery aquí porque todavía me falta bastante por aprender, pero sí os dejaré un enlace a una página repleta de “chuletas” sobre jQuery y librerías similares, como Prototype, Scriptaculous o MooTools.

http://www.scottklarr.com/topic/95/javascriptajax-cheat-sheets/

Personalmente la que más me gusta a mí es la de colorines xD, tengo muco de niño pequeño todavía. Saludos!

Comparte y disfruta:
  • Print
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Bitacoras.com
  • Identi.ca
  • Meneame
  • StumbleUpon
  • Technorati
  • Twitter
Tags: , , ,
Comentario
Powered by WordPress | Theme: Motion by 85ideas.