Nuestro CMS lo utilizan ya cerca de 40 personas, algunos de los cuales ni siquiera están en España y sólo tenemos contacto con ellos por mail... ¡con algunos ni siquiera he hablado nunca!

Ahora que viene siendo frecuente la integración de APIs desarrolladas por terceros en nuestras aplicaciones, se nos plantean nuevos retos a la hora de gestionar errores y asegurar disponibilidad.

Desde hace tiempo intentamos que cuando programamos una web las extensiones de los ficheros y la estructura de directorios no nos condicionen en el futuro.

Es decir, en el interior de la carpeta coches existe un fichero que puede llamarse default.asp, default.html, default.aspx, default.php... y eso da igual ya que tanto nuestros usuarios como los buscadores sólo conocerán la URL que utilicemos en los enlaces, en este caso la de la carpeta.

De esta manera llegado el momento podremos cambiar de lenguaje de programación sin miedo a perdidas de tráfico. 

Desde mi punto de vista el lenguaje de programación que utilicemos no es un dato que interese al usuario por lo que no debemos abofetearle con él cada vez que entre en nuestra web.

Si la URL necesita parámetros para generarse, por ejemplo una lista de productos extensa que requiere paginación tenemos que tener cuidado y no ser torpes. En lugar de enlazar a:
 

Hay que tener en cuenta que para los buscadores con que sólo una letra pase de mayúsculas a minúsculas, ya considerará la URL completamente distinta. Por eso nosotros nos fijamos como norma nunca utilizar mayúsculas en los enlaces internos, además depuramos los espacios convirtiéndolos en guiones medios y transformamos algunos caracteres en otros más compatibles (ñ-n, á-a). 

Son pequeños detalles, a veces casi artesanales, que sumados a otros muchos van marcando la diferencia. Observar este tipo de cosas cuando visitamos una web puede ayudarnos a hacernos una idea de si el equipo que hay detrás es cuidadoso o si no ha prestado ninguna atención al SEO de la web.

No obstante nuestro CMS tiene un defecto: los artículos del blog son de las pocas URL que no siguen este patrón y revelan la extensión del fichero y teniendo en cuenta que en todos los blogs se publican más de 500 artículos al mes, ahora es un problema bastante laborioso de solucionar...

Esta semana vamos a importar un nuevo blog desde Blogger a nuestro CMS y se nos ha ocurrido lo siguiente: conservaremos las URL con la extensión .html que utiliza Blogger (lo cual nos permitiría por ejemplo el día de mañana exportar ese mismo blog a Wordpress). 

Para ello sólo hay que conseguir que los archivos con extensión .html se procesen como si fueran páginas ASP para lo que hay que agregar una nueva asignación de extensión en IIS:

 

Todos los que nos dedicamos a realizar aplicaciones informáticas nos vemos enfrentados antes o después a la decisión de apostar por un nuevo lenguaje de programación.

• Genviajero, red social para viajeros montada con Google App Engine - Nueva red social programada en Python y que se aloja en los servidores de Google... y que puede echar mano de las cuentas de Google para gestionar el login.

• Triple salto mortal con tirabuzón - Sobre el cambio de plataforma de Festuc, que ha pasado de PHP a Django (Python) lo que ha supuesto el desarrollo desde cero de toda la aplicación.

• La popularidad de los lenguajes de programación (oct 08)  - En el que aNieto2k recoge este gráfico donde se puede ver como casi 3/4 de la tarta se lo reparten C, C++, VB y Java.

 

Ventajas e inconvenientes de emprender un desarrollo propio cuando existen alternativas de buena calidad en el mercado o soluciones open source.

En otras ocasiones hemos hablado aquí sobre esa tendencia nuestra de re-inventar la rueda, ya sea programando nuestro propio CMS a partir de Blogger (haya por junio de 2005)... o en otras muchas otras cosas. 

Dare Obasanjo hace no mucho resumía en este párrafo:

I'm often surprised by how common it is for developers to prefer reinventing the wheel to using off-the-shelf libraries when solving problems tasks. This practice isn't limited to newbies who don't know any better but also to experienced developers who should. Experienced developers often make excuses about not wanting to take unnecessary dependencies or not trusting the code of others when justifying reinventing the wheel.

Los informáticos tienen el síndrome de NIH (no invented here) con frecuencia, si no lo han hecho ellos, no les gusta. (...) Coger e instalar un Wordpress son 5 minutos, adaptarlo, quizá una semana. Desarrollar tu propio CMS… no tiene precio. Pero en tiempo (oportunidad) y coste… no hay comparación.

• Aprendimos - Y no es tan sencillo aprender porque el día a día te aboca a repetir una y otra vez tareas que ya dominas... y no es tan frecuente enfrentarte a nuevos retos que te obligan a estudiar en profundidad un tema.
• Tranquilidad - Si surge un problema lo podemos resolver, puede que nos tengamos que quedar un par de noches sin dormir... pero al final lo resolveremos: I Know because I wrote it.
• No todo lo hicimos nosotros - Lo único que hemos programado es el core del CMS y si bien es la segunda aplicación más grande que hemos programado... el hecho es que lo más dificil lo realizan componentes como Aspjpeg, FCKeditor, CKFinder...
• Seguridad - Los problemas de seguridad de Wordpress son bien conocidos, no quiero decir que nuestro CMS sea un bunker: es probable que tenga más de una vulnerabilidad y alguna que otra grave: pero que alguien dedique su precioso tiempo en buscarlas es como entrar en La Casa Blanca para robarle la hucha-cerdito a la hija del presidente.
• Adaptación - Integración de los post con nuestra guía, la pasarela con 11870, el mashup de APIs, las thumbs a medida, las capturas de webs para obtener logotipos...

En definitiva, la lección del Gafapasta que hemos aprendido es que como en todo siempre hay un lado positivo... 

Tranquilos que no soy tan zote, sé que AJAX y los iframes no tienen nada que ver... pero con este título hiperbólico intento transmitiros una idea importante: no mates moscas a cañonazos.

Estamos migrando el charset de todos nuestro CMS a UTF-8 y con ello el de todos los blogs que gestionamos con él.

• Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) de Joel Spolsky.
• Survival guide to i18n de Sam Ruby

Set fso = CreateObject("Scripting.FileSystemObject")
Set myFile = fso.CreateTextFile(ruta_archivos & FOLDER_ATOMXML & "" & post_uri & ".xml", True)
myFile.Write(entry_v)
myFile.Close

Set fsT = CreateObject("ADODB.Stream")
fsT.Type = 2   'Specify stream type - we want To save text/string data.
fsT.CharSet = "utf-8" 
fsT.Open
fsT.writetext entry_v
fsT.SaveToFile ruta_archivos & FOLDER_ATOMXML & "" & post_uri & ".xml", 2
fsT.close
set fsT= Nothing

Gracias al API de bluga.net se pueden obtener pantallazos de cualquier web, incluidas las desarrolladas en Flash, a partir de las cuales obtener con facilidad los logos de los establecimientos.

El otro día repasando un artículo antiguo de febrero de 2006 me asustó comprobar que ayer terminamos un desarrollo que ya teníamos en mente en esa fecha.

La idea es muy sencilla, en TopMadrid y DolceCity disponemos de una guía con las direcciones de los sitios de los que hablamos en el blog organizadas por categorías, por ejemplo: centros comerciales en Madrid

Como se puede ver en la imagen los sitios van acompañados de una pequeña imagen de 50 x 50 pixels con el logo de la empresa referenciada: ¿cómo se hacían esos logos? A manija, es decir, vas a la web del sitio, capturas pantalla, la pegas en tu editor de imagenes, recortas, guardar las imagen, la subes por FTP al servidor y actualizas el registro como que "ya tiene imagen". 

El proceso realizado por mi a toda prisa podía llevar unos 5 minutos por imagen y por alguien con menos soltura de 5 a 10 minutos, vamos de 2 ó 3 euros por imagen sin contar el daño emocional de ver que llevas cinco y te quedan 3000.

Era un rollazo interminable y tedioso que no superó la prueba de escalabilidad a la que se sometieron todos los procesos cuando ampliamos el concepto de TopMadrid a nuevas ciudades con DolceCity. Lo tuvimos que interrumpir, pero claro, el atractivo de la página se resiente, asi que había que buscar una manera de hacer lo mismo mucho más rápido y lo hemos conseguido gracias al API de bluga.net webthumb y a un par de días de programación.

pulsa para ver más grande

Volvemos al tema de ahorro de tiempo: ahora conseguimos hacer entre 3 y 4 imágenes por minuto, lo cual reduce el coste de cada foto a unos cuantos céntimos de euro... y lo mejor de todo, es divertido (casi diría adictivo).

El proceso de captura viene a tardar cerca de un minuto entre que solicitas el pantallazo, bluga.net obtiene la captura, te hace un ping para avisarte de que ya la tiene y nuestro sistema descarga la foto en el servidor.

Dentro de nuestro programa los sitios que no tienen foto se colocan en una lista de espera, mientras que tú estás recortando un logotipo el sistema a través del API está solicitando la pantalla de los siguientes sitios, de tal manera que cuando avanzas ya todo esta listo para que puedas seguir trabajando sin interrupciones.

En la imagen de la derecha se puede ver que la caputura de operad-arte.es se ha solicitado pero todavía no está lista por lo que no se ha podido descargar... sin embargo la captura de hatostyle.com ya esta lista y sólo falta recortarla.

Las capturas se reciben a 1024x768 en formato png sin perdida y vienen a pesar cerca de media mega cada una. Utilizando los mismos componentes que para las thumbs se selecciona la parte donde está el logotipo de la empresa y a partir de esas posiciones se generan toda una serie de imágenes en formato jpeg:

Algo importante es que las pautas de corte se almacenan en la base de datos, de esta manera si en algún momento necesitamos hacer una nueva thumb con otras medidas o deseamos cambiar de formato (por ejemplo pasar a png), podemos rehacer el procedimiento en toda las imágenes ya procesadas, sin tener que revisarlas de nuevo.

En fin ya se sabe que los desarrollos de los que estas orgullosos hoy te avergüenzan pasados unos años... pero por el momento estamos encantados con el nuevo jueguecito.

El espiritu de un desarrollo informático debe ser la busqueda del ahorro del tiempo del usuario, eliminando tareas monótonas y repetitivas: ¿puedes conseguir que el trabajo se convierta en un juego?

...existen muchos tipos de vacunas, algunas para perros otras para gatos, que algunas se administran trimestralmente, otras anualmente, que otros tratamientos son estacionales. También tienes que entender que a un mismo animal puede ser necesario administrarle varias vacunas el mismo mes y que un propietario puede tener más de una mascota... y que queda muy mal enviarles varias cartas en lugar de una sólo con toda la información resumida y ordenada. Llegados a un punto, también tienes que saber que muchos propietarios pasan por el hospital a vacunar a sus animales antes de que tú les envíes la carta y que a esos propietarios no se les debe notificar tratamientos que ya les han sido administrados...

Había algo de nuestro CMS que me llevaba asqueando desde hace bastante tiempo: la generación de thumbs... asi que hemos mejorado el sistema, aquí explico cómo funciona y cómo está programado.

Allá por febrero de 2006 programamos una mini-aplicación que capturaba la primera foto del posts y la dividía en pequeñas cuadrículas, entonces tu elegías el trozo que más te gustaba y esa era tu thumb. Todo lo espliqué en un post que titulé Las thumbnails más rápidas a este lado del Mississippi... en su momento estaba muy orgulloso.

Por desgracia la Ley de Murphy parece aplicarse con mucha frecuencia en esto de las thumbs y era bastante frecuente que el cuadrado no cayese en el mejor sitio: cortaba un trozo de cara, dejaba fuera una oreja... 

Así que hemos evolucionado, ahora -como se puede ver en la imagen- se captura la primera imagen del post y se muestra un recuadro sobre ella que mantiene las proporciones que tendrá la thumb final.

El recuadro se puede mover y cambiar de tamaño, una vez que tienes las coordenadas del corte puedes pulsar en "Probar" y te muestra el resultado y cuando estás convencido le das a "Guardar"... a partir del primer corte el programa te genera tres thumbs en distintos tamaños y pasa al siguiente post automáticamente.

Calculo que puedes hacer con facilidad unas 10 thumbs por minuto, por lo que el proceso de publicación no se ralentiza. Los nuevos tamaños de las thumbs son: 120 x 90 pixels (antes era 120 x 120 pixels), 70 x 53 pixels (nuevo), 50 x 38 pixels (antes 50 x 50 pixels)

Como se puede ver hemos aprovechado para cambiar la proporciones de las thumbs y hacerlas apaisadas, que quedan bastante más estéticas que cuando eran cuadradas.

Programación

Para poder hacer esto hemos utilizado el excelente script programado por Angus Turnbull DragResize 1.0. Básicamente es un js que te permite animar un DIV, cambiándolo de tamaño y posición, en principio la redimensión es totalmente libre y no puedes mantener un ratio de proporciones, pero en el foro encontramos una modificación del código que si te permite restringir las proporciones: algo esencial para las thumbs.

El div se deja transparente y se coloca una foto alineada con él desde el punto 0,0. De esa manera cuando mueves el DIV las coordenadas coinciden con las de la foto.

Con una función javascript recuperas los valores del DIV cada vez que dejas de moverlo, esas serán las pautas de corte que tendrás que aplicar a la foto. Para este último paso nosotros usamos AspJpeg, aunque supongo que habrá programas similares y gratuitos en PHP y demás.

Puedes ver como funciona aquí >>