domingo, 11 julio 2010

3
objeciones

Todo en menos de un segundo

por Fernando Plaza en ,

Esta semana parece que a casi todos los supervivientes de El Reto Blogger les ha dado por ponerse a hablar de `su libro´ y yo no voy a ser menos...

Nuestra lema esta semana ha sido `menos de un segundo o nada´, ha sido algo asi como un mantra que nos hemos repetido hasta la saciedad... y es que nos hemos propuesto que ninguna de las páginas de nuestras aplicaciones tarden en cargarse más de un segundo.

Lo primero con la ayuda de Google Analytics y analizando los logs del servidor hemos hecho una relación de las páginas más visitadas, para asi centrar nuestros esfuerzos en las páginas más importantes... y dosificar el arte del Maestro.

Después hemos troceado el código incluyendo contadores después de cada conexión a la base de datos. Cuando veiamos alguna conexión que tardaba mucho en completarse, mostrábamos la SQL en pantalla y aquí es donde empezaba lo realmente interesante.

Parece mentira como la misma sentencia `diseñada´ de distintas maneras puede obtener el mismo resultado pero muchisimo más rápido. Podemos ver un ejemplo aquí, intentamos contar los registros que hay en un año y mes concreto, en la primera SQL hacemos uso de la función month() y year()... en la segunda SQL hacemos los mismo pero en el WHERE de la SQL optamos por indicar una fecha de inicio y una fecha final.



No debería haber mucha diferencia entre una y otra, pero en la primera MySQL trabaja con 26.800 registros y en la segunda sólo con 95, la diferencia de tiempo es muy grande (bueno, son décimas de segundo pero que van sumando y sumando... y nos van alejando de nuestro objetivo de no superar el segundo).

Cuando se han retocado las SQL, se han revisado los índices y aun no se ha alcanzado la meta ya comienza a ponerse la cosa un poco más complicada y llega el momento de meter la tijera: ¿realmente ese listado tiene que verse en esa pantalla? a lo mejor es más conveniente ocultarlo y dejar que el usuario sea el que decida cuando quiere verlo, pulsando en icono de despliegue [+]

También cuando el volumen de registros va creciendo hay que optar por sustituir consultas on-line por procesos batch. Muchas veces esta decisión implica que vas a perder la `información on-line´ a favor de que una información un pelín desactualizada se muestre con fluidez y por tanto de manera más cómoda para el usuario. Dependiendo del tipo de información el cambio puede merecer sin duda la pena, a un nivel agregado poner 12.502 ó 12.504... da prácticamente lo mismo (al menos en nuestra situación, si fueran valores de cotización... otro gallo cantaría).

Asi que con esas estamos ahora, repasando cosas programadas hace años para que funcionen aun mejor. No se puede decir que sea divertido... pero si que es un poco adictivo porque estás muy centrado en sumar centésimas de segundo y mientras que haces eso... no piensas en otra cosas que te preocupan.

domingo, 27 junio 2010

3
objeciones

Todo cambia

por Fernando Plaza en ,

Sed fugit interea fugit irreparabile tempus

Virgilio

Esto de mantener un blog actualizado todas las semanas inevitablemente requiere tener algo que contar todas las semanas... en El Reto Blogger esta semana es de temática libre y la verdad es que tengo poco que contar, me he pasado la ultima semana trabajando a media jornada para el Gobierno de la Nación.

Primero ordenando todos los papeles de la Declaración de la Renta para cumplir con mis obligaciones tributarias... como todos los años, hasta ahí todo correcto. La otra mitad del tiempo he estado programando la adaptación del programa informático que usan en el Hospital Veterinario para el cambio de tipo de IVA... esto ya me ha irritado un poco más y a ZP le han debido de zumbar un poquito los oidos durante todo el proceso.

Mientras que iba repasando linea a linea el código que programé en el 2003, hace ya siete años... estuve reflexionando sobre lo poco adaptados que están la mayoría de los programas a cambios inesperados o simplemente que se preveen muy lejanos. Han pasado ya diez años desde el efecto 2000, pero no es ni mucho menos algo aislado... con el sistema de direcciones IP v4 pasó algo similar, en su momento se pensó que 4.294 millones de direcciones IP únicas serían suficientes, pero no lo ha sido.

Los mismo termina pasando antes o después con el IPC, el IVA, el IBEX, las retenciones, el tipo de interés, los ciclos económicos... todo termina cambiando y en la mayoría de las ocasiones no se tiene en cuenta a la hora no sólo de programar sino de planificar la vida en general... ¿quién cuando se compra una vivienda hace el cálculo de lo que le costaría su hipoteca si se triplicara el Euribor? ¿quién confecciona un plan B por si le despiden del trabajo en el que está contratado fijo?

Tal vez pensamos que si no se planifica el cambio, este no ocurrirá... una negación de la realidad a nuestro antojo. Tal vez pensamos que para cuando ocurra el cambio seremos mucho más listos, contaremos con más recursos y sobre todo con más tiempo para `arreglar el marrón´... pero normalmente suele ocurrir lo contrario. También puede ser que a veces pensemos... ¡ya lo arreglará el que venga! pero en la PYME ese `otro alguien´ normalmente sigues siendo tú asi que no puedes escapar de tu propia torpeza o corta visión.

Mi recomendación por tanto sería: intenta hacerlo bien a la primera (o al menos lo mejor que puedas).

domingo, 30 mayo 2010

6
objeciones

Yo pa' ser feliz quiero un camión

por Fernando Plaza en , ,

Hoy estuve conduciendo por Madrid una Mercedes Sprinter y ha sido una de las cosas más divertidas que he hecho en mucho tiempo.

Creo que la versión que me han dejado conducir era la compacta que tiene unos 7,5 m³ de capacidad de carga, aunque ahora que reviso la web para buscar la foto de este post... puede que fuera las Standard, algo más larga y que se va a los 9 m³... el caso es que alguien como yo, con un modesto carnet de conducir tipo B, es capaz de ponerse al volante de un bicharraco como este y conducirlo sin mayores problemas.

¡Qué éxito de usabilidad! Al final todo estaba donde esperabas que estuviera: el freno de mano, las luces, la palanca de cambios... asi que no tienes que perder el tiempo aprendiendo cosas nuevas y puedes centrar toda tu atención en lo realmente importante: hacerte con el cambio de tamaño del vehículo y adaptarte a conducir a más altura.

Siempre que veo la cantidad de gente que es capaz de conducir un coche me maravilla lo que ha sido capaz de conseguir la industria de la automoción, han logrado hacer accesible algo complejo. Piénsalo, cualquiera es capaz de sentarse en un coche y conducir ¡a más de 100 km/hora!... ¿en cuánto tiempo ha sido posible este prodigio? Apenas han pasado 125 años desde que Karl Benz invetará el primer automóvil (1886) y cien años desde que Henry Ford pusiera en marcha la primera cadena de montaje de fabricación de vehículos `en masa´

Pienso en esa centena de años y luego como la cabra que tira el monte, miro hacia las páginas webs... veo lo que hemos recorrido y pienso en todo lo que nos queda por conseguir hasta que cualquier persona sea capaz de navegar por Internet, instalar un escáner, un procesador de texto o configurar su ADSL sin tantísimos problemas como en la actualidad.

Desde mi punto de vista el AJAX y próximanente HTML5 suponen un enorme avance ya que consiguen tender un puente de unión entre las Aplicaciones Web y las Aplicaciones de Escritorio... y eso más allá de florituras varias supone hacer ahorrar tiempo de aprendizaje al usuario, que en teoría si maneja ya un Word, un Excel o algo similar, debería de ser capaz de utilizar todas las funcionalidades básicas de casi cualquier aplicación web... y si no lo consigue, es que la aplicación está mal hecha.

Es el programador o diseñador de la aplicación el que debe cuestionarse la calidad de su trabajo y no echar la culpa al usuario pretendiendo que evolucione, porque por mucho que nos pese: el usuario casi siempre tiene la razón.

Luego, claro está, existen otras muchas circunstancias... a veces programar una aplicación como `debería hacerse´ supondría invertir en ella un número de horas que el cliente no está dispuesto a pagar. A veces una parte de la aplicación va a ser utilizada por tan pocas personas (Mantenimiento, Administración, Paramertrización...) que te resulta más rentable formarlas para que sean capaces de entender `esa complejidad´ que invertir en horas de programación para conseguir soterrarla.

En definitiva: el mundo idílico que podíamos ser capaces de conseguir a través de la informática a veces simplemente no se puede realizar porque no es rentable. Otras veces no es problema de presupuesto, es simplemente una combinación de soberbia, ineptitud y desidia... y eso si que es triste, hacer chapuzas cuando hay dinero para hacer las cosas bien. Líbreme Dios de todo ello... y deme tiempo para poder fabricar algún días la Mercedes Sprinter de las aplicaciones web.

domingo, 10 enero 2010

1
objetor

Cómo se crea una Galeria en nuestro CMS

por Fernando Plaza en , ,

Por fin ya hemos habilitado la posibilidad de crear Galerias en nuestro CMS nos hemos esforzado para que sea una tarea muy sencilla y rápida para que los escritores se animen a usarlas.

El sistema es bastante rápido teniendo en cuenta que todas las imágenes asi como sus thumbs primero se suben a nuestro servidor pero luego quedan almacenadas en Amazon S3. Toda la parte Ajax se ha programado con JQuery que se encarga de lo más dificil: subir multiples fotos, actualizar sin refrescar...

Aquí se puede ver una demostración de cómo se ha creado la galería de este post:

Por el momento hemos permitido que se puedan subir fotos de hasta 750 k, diez veces el tamaño máximo que permitimos en las fotos en los posts (75k). En cualquier caso cualquier foto que se sube se adapta en tamaño y peso, de manera que en la web al final queda colgada una versión optimizada (la versión original de mayor calidad se almacena también por si acaso):
  • El tamaño máximo permitido es de 950 pixels de ancho y 600 de alto, cualquier foto que se suba de mayor tamaño se reduce en la versión para publicar de manera transparente para el usuario.
  • Utilizamos el formato jpeg a 90 de calidad, normalmente usamos 80 pero preferimos no ser tan tacaños y que capturas que hubieran quedado mejor publicadas en formato gif o png conserven una buena nitidez pese a estar en jpeg.



PD - En el video se me ha olvidado mostrar que se puede cambiar el orden de las imágenes, para ello sólo es necesario pulsar sobre la imagen y arrastrarla hacia su nueva posición. Para el que le interese el tutorial ha sido grabado con la versión gratuita de Jing.



Ver Galería: 19 imágenes »

domingo, 3 enero 2010

AFR - ratio anual de fallo

por Fernando Plaza en ,



...volumes that operate with 20 GB or less of modified data since their most recent Amazon EBS snapshot can expect an annual failure rate (AFR) of between 0.1% – 0.5%, where failure refers to a complete loss of the volume. This compares with commodity hard disks that will typically fail with an AFR of around 4%, making EBS volumes 10 times more reliable than typical commodity disk drives

Amazon Elastic Block Storage (EBS)

En FernandoPlaza.com: Amazon S3

sabado, 17 octubre 2009

2
objeciones

Moviendo todas nuestras fotos a Amazon S3

por Fernando Plaza en , ,

Este esquema muestra como hemos hecho para pasar todas las fotos de nuestros blogs a Amazon S3.



Siento una enorme admiración por el proyecto AWS (Amazon Web Services)... ¿quién podía pensar que Amazon, el mayor retailer online, de repente se iba a convertir en proveedor tecnológico y buque insignia del cloud computing?

Aunque utilizo S3 desde el año pasado, cuando empezamos a volcar ahí nuestras copias de seguridad, hasta la fecha nunca nos habíamos planteado usarlo como hosting de imágenes... pero ha llegado un momento en el que las imágenes de más de cinco años de publicación en todos nuestros blogs nos han desbordado y no tiene sentido que la mayoría de los recursos del servidor se desaprovechen sirviendo archivos en lugar de sirviendo webs de manera más eficaz (al fin y al cabo como su propio nombre indica un webserver es un servidor de webs).

Para mover todas las imágenes ha habido que reprogramar varios componentes de nuestro CMS para conseguir que las imágenes se carguen en Amazon S3 en lugar de en topmadrid.com, dolcecity.com...

Me centraré en cómo ha quedado ahora el proceso:

1 - La imagen es cargada por el escritor en el CMS con CKFinder, cada escritor tiene una carpetas con sus imágenes que ellos gestionan, todo ello en enzo.es que es donde está instalado nuestro CMS.

2 - Cuando se publica el post, se realiza una copia de cada imagen en otra carpeta que hemos llamado "cache" y desde ahí se sube a Amazon S3 (utilizando el API REST de Amazon S3 y todo programado en el arcaico vbscritp... que tiene mérito)

3 - Una vez todas las imágenes están subidas se inicia el asintente para crear las thumbs para este proceso necesitamos tener la foto en el servidor donde está instalado el componente con el que las hacemos ASPjpeg, por eso el CMS revisa la carpeta de caché para ver si sigue ahí la foto y sólo en el caso de no encontrarla se la descarga de vuelta desde S3 (esto es necesario porque la carpeta caché se vacía cada noche y a veces quieres rehacer una thumb de un post que colgaste hace tiempo por lo que la foto original ya no está en la carpeta cache y hay que traerla de S3).

4 - Las thumbs se guardan en enzo.es durante el tiempo suficiente para poderlas pasar también a Amazon S3, después se borrán.

A diferencia de antes ya ninguna foto pasa a los blogs de destino, todo está o temporalmente en enzo.es o en su emplazamiento defitivo en Amazon S3 quedando todos los archivos de cada blog organizados en buckets independientes:



Aprovechando que teníamos que hacer este cambio hemos solucionado un problema que habíamos heredado de blogger:

- Las imágenes de los posts en lugar de colocarlas todas en la carpeta /uploaded_images/ ahora van clasificadas por años y mes, igual que los posts.

- Por su parte las thumbs, para no tenerlas todas juntas como antes en la carpeta /img_thumbs/ se van distribuyendo de manera automática en carpetas de 100 en 100, con lo que evitamos los problemas de la situación anterior: tener carpetas con más de 30.000 imágenes y creciendo que sólo para conseguir listar sus archivos ya era todo un reto.

Sólo nos falta un último empujón para que las galerías entren en el nuevo circuito de S3 y con eso la "migración" estará completa. Los beneficios del cambio son claros, como se puede leer en este post de Amit Agarwal mover todas tus imágenes a Amazon S3 descarga enormemente de trabajo a tu servidor:


En servidores donde corremos aplicaciones hemos comprobado que algunos procesos se ejecutan ahora muchísimo más rápido, tenemos por ejemplo un cron que llama a una página a las 20:00 y que solía terminar cerca de las 22:20... ahora el mismo proceso termina a las 21:45 lo que supone más de media hora de diferencia.

En FernandoPlaza.com: Amazon S3

lunes, 28 septiembre 2009

you’re here to ship products!

por Fernando Plaza en ,

At the end of the day, ship the fucking thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.

Jamie Zawinski leido Joel on Software

domingo, 26 abril 2009

1
objetor

Sobre sistemas de seguridad...

por Fernando Plaza en ,

The present need for security products far exceeds the number of individuals capable of designing secure systems. Consequently, industry has resorted to employing folks and purchasing "solutions" from vendors that shouldn't be let near a project involving securing a system.

Lucky Green

lunes, 23 marzo 2009

4
objeciones

Listado de IPs de bots, crawlers, spiders y demás...

por Fernando Plaza en , ,

Lista actualizada de direcciones IP de los robots que indexan nuestras webs habitualmente.

En mi post Programando un contador de impresiones que excluya a los bots me recomendaba Alberto en los comentarios que compartiera mi listado de IPs de bots, crawlers, spiders y demás...

Para quien le pueda interesar un volcado de este listado de IP se actualizará regularmente en la siguiente dirección:

http://www.fernandoplaza.com/apps/bots/iplist.txt

Los casi 800 bots que tenemos ya fichados están ordenados por el UserAgent para que el listado sea más sencillo de revisar. La estructura del txt no os costará averiguarla por si queréis importar su contenido con cierta frecuencia (para que el fichero no pese mucho el UserAgent está limitado a 100 caracteres).

Espero que os resulte útil.

martes, 17 marzo 2009

6
objeciones

Programando un contador de impresiones que excluya a los bots

por Fernando Plaza en , ,

El tráfico generado por robots, crawlers, spiders y demás que navegan por la red es casi tan grande como el de los humanos. Si queremos programar un contador fiable debemos excluir todas esas visitas.

If our logs are any indication, few bots actually bring enough human traffic to make up for their crawls, so there's alot of free-loading bots out there.

Bots vs Browsers

Programar un contador de impresiones no es nada del otro mundo, básicamente es un código que se ejecuta una vez se carga la página y que realiza una inserción en la base de datos.

Yo lo he puesto en mis plantillas al final del todo y precedido de un Response.flush para que en caso de que algo falle el usuario reciba la página solicitada sin demoras, además sólo hago una inserción en la base de datos y el recuento de las totalizaciones se realiza por las noches en un proceso batch... de esta manera aun siendo un código que se ejecuta en todas y cada una de las páginas es mucho más ligero que si primero tuviera que buscar el número de impresiones del día (select) y luego actualizarlo (update).

Lo complicado empieza cuando te das cuenta de que más de un 50% de tus impresiones proceden de robots, spiders, crawlers... y que necesitas filtrar todas esas entradas para que el dato se asemeje lo máximo posible a lo que te devolvería un Google Analytics.

¿Cómo hacemos para filtrar toda esta moralla? Pues yo no sé cómo lo harán los sistemas estadístico pero yo lo hago por IPs o analizando el UserAgent del navegador que visita la página.

En iplist.com (IP Addresses of Search Engine Spiders) puedes encontrar un buen listado de IPs de bots para excluir, son unas 3.500 direcciones aunque después de importarme todas ellas cuando intente cruzarlas con mis datos no hubo muchas coincidencias...

Así que opté por re-invetar la rueda (one more time) y crearme mi propia lista con un poco de ayuda de Bots vs Browsers. Básicamente lo que hago es en el proceso batch buscar dentro del UserAgent palabras como bot, crawl, spider, mediapartners, slurp... y almacenar todas esas IP para excluir sus impresiones (ya tengo almacenadas unas 400 y subiendo... que aun siendo menos de las 3.500 de iplists.com me funcionan mucho mejor). Por el momento el sistema funciona bastante bien y el número de impresiones que recibo se acerca muchísimo al que me dan mis estadísticas.

Llevaba tiempo necesitando un contador de este tipo, lo he estado retrasando porque sé que el API de Analytics está al caer pero yo no podía esperar más... cuando lancen el API ya veré la manera de integrar también esos datos para corroborar los mios.
siguiente página »