The little book of Flow @ FictionBook

23 de Junio de 2009

If you don’t understand spanish, just scroll down to the bottom.

Hace poco he encontrado un libro que en pocas palabras describe toda la filosofía que llevo siguiendo desde hace ya algún tiempo. Tanto me ha gustado que hasta me he tomado la molestía de pasarlo de HTML a FictionBook. Para los que no lo sepan FictionBook (ficheros con extensión fb2) es un formato para poder leer los libros sobre distintos dispositivos: iPhone, Papyre, casi todas las PDA’s, etc. Es un formato abierto y libre.

Este “libro” en realidad es un post que apareció en el blog de Nick Smith (allá en el 2006) y es una recopilación de las ideas que ha ido exponiendo a lo largo de un tiempo. Se titula The Little Book of Flow. Merece la pena leerlo, de verdad, el único inconveniente que os podeis encontrar es que esta en inglés.

Sin más preámbulos aquí os pongo el enlace.

Más sobre el tema: Formato FictionBook.

Now, for my english-spoken readers. I just converted Nick Smith’s The Little Book of Flow from HTML to FB2. I hope you know what this format is, if you don’t, RTFM.

Yo en twitter

22 de Junio de 2009

Por fin tengo configurado mi Twitter. Me gustaría conocer a gente interesante. Podeis encontrarme aquí.

Función replace() en mysql

14 de Junio de 2009

Un día de estos me encontré con un fallo en el código. El fallo era debido a que un famoso editor de texto hecho en Javascript rodeaba ciertas expresiones con comillas simples. Para que nos entendamos aparecía algo así como cadena 1, cadena 2, cadena 3 en vez de cadena 1, cadena 2, cadena 3. Estos valores luego se insertaban en una base de datos MySQL para ser mostrados en la página. Claro está, estas comillas simples generadas rompían toda la lógica y no se mostraba el texto.

La aplicación se corregió, pero quedó por corregir lo que ya estaba en la tabla. Teniendo en cuenta que el texto era bastante largo no se podía hacer SELECT – corregir – UPDATE. Había que corregirlo directamente en base de datos.

La solución ha sido la siguiente:

CREATE TEMPORARY TABLE guion_tmp LIKE guion;

INSERT INTO guion_tmp SELECT * FROM guion where guion_id=67;

UPDATE guion SET guion_contenido=(SELECT replace(guion_contenido, ‘\’Times New Roman\”,’Times’) FROM guion_tmp WHERE guion_id=67) WHERE guion_id=67;

La tabla temporal se eliminará nada más cerrar la conexión.

¿Será un fallo informático la causa de la caída de AF447?

10 de Junio de 2009

airbus-a330_1414139cEn los últimos días los expertos están diciendo que la causa más probable del accidente de Airbus A330 (vuelo AF447 cuyos restos están buscando ahora en las costas brasileñas) podría ser un fallo informático en el sistema de control del vuelo. A causa de esto surgieron las discrepancias entre los datos de los distintos indicadores.

Con todo esto hay que aclarar una cosa.

Los aviones comerciales modernos (entre ellos el Airbus A330) incorporan un sistema informático llamado Air Data Inertial Reference Unit (ADIRU). Este sistema se encarga de comunicar distintos parámetros (altura, velocidad, viento, etc) a los pilotos y también al piloto automático. Pero en esta ocasión los pilotos no tuvieron ni la más mínima oportunidad. Incluso al observar que el sistema se estaba volviendo loco no pudieron tomar el control en sus manos. En los aviones Airbus (a diferencia del Boeing) esta posibilidad está desactivada. En situaciones críticas los pilotos no pueden tomar el control.

Las distintas formas de ver el problema – ¿quién es el que tiene la prioridad si el humano o la computadora? – lo llaman “la diferencia filosófica entre Boeing y Airbus“. De momento la estadística de incidentes se mantiene igual para los dos fabricantes de forma que los constructores no pueden inclinarse ni por uno ni por otro. Sin embargo, los propios pilotos realmente odian los Airbus con todas sus almas, basta con leer algunos de sus foros para darse cuenta de ello.

¿Realmente quieres ser feliz?

9 de Junio de 2009

Hace poco he leído en Boston Globe un artículo muy interesante sobre nuestro nivel de vida en contexto de distintos sucesos que pueden pasar a todo ser humano. Los científicos han pedido a un grupo de gente valorar de vez en cuando su nivel emocional después de lo cual han analizado el nivel de “felicidad” medio. A la gente que no participaba en el experimento también les han pedido hacer una lista de sucesos que deberían de pasar para “sumar” o “restar” la felicidad.

Estas son las cosas que según nosotros mejoraría sustancialmente nuestra calidad de vida pero que en realidad no tienen ningún efecto:

  • El hecho de casarse.
  • Ganar la lotería.
  • Aumento de sueldo.
  • Mudanza a una nueva casa.

Sucesos que creemos que empeorarían la calidad de vida pero que realmente no tienen efecto alguno:

  • Pérdida de visión.
  • Minusvalía.
  • Algún suceso trágico.

Cosas que realmente empeoran nuestras vidas aunque pensamos muy poco en ello:

  • Dolor de espalda crónico.
  • Esquizofrenia.
  • Ruído.

Cosas que realmente mejoran la calidad de vida aunque para la mayoría no son cosas prioritarias:

  • Una hora adicional de sueño al día.
  • Los amigos.

Personalmente estoy de acuerdo con los puntos tres y cuatro del primer grupo. Me han subido numerosas veces el sueldo (aunque últimamente soy yo el encargado de subírmelo) y he cambiado un sinfin de casas. La verdad es que no he notado cambio alguno después de que sucedía esto. Nunca me he casado ni he ganado a la lotería, así que aquí no puedo opinar.

En cuanto a segundo grupo yo de momento estoy bien, espero que por muchos años, pero si he perdido algún amigo y algún familiar por causas bastante trágicas. Siento decirlo, para la vida sigue igual y hay que seguir con ella, con el tiempo el mal trago se olvida.

Al tercer grupo yo añadiría el dolor de muelas, pero claro, es una cosa que se puede arreglar.

Y por último, los amigos lo son todo. Aunque yo añadiría también el hecho de estar bien físicamente, no me refiero a ser un modelito publicitario, pero estar dentro de la normalidad también ayuda bastante.

¿Y vosotros que opinais?

Iconos gratuítos para desarrollo web

9 de Junio de 2009

Navegando por allí he encontrado estos iconos. Espero que a alguien le sean útiles.

Icónos desarrollo web

Google cambia el mecanismo de cálculo de PR

8 de Junio de 2009

En una de las ponencias de la conferencia SMX Advanced que terminó el día 3 de junio Matt Cutts comunicó el hecho de que Google va a calcular de una nueva forma el PR de las páginas con nofollow. Anteriormente si un webmaster ponía “nofollow” como atríbuto de un enlace el peso total de todos los links seguía siendo el mismo y se distribuía entre los enlaces sin nofollow.

Explicándolo con un ejemplo: si todos los links (10) tenían un peso de 1000 unidades relativas y el webmaster cerraba dos con nofollow el peso de 1000 enlaces se distribuía igualmente entre los ocho restantes que lo pasaban a las páginas enlazadas.

A partir de ahora, si el rumor oído fuese cierto (y tiene toda la pinta de serlo) si el SEO pone nofollow en algunos de los links que tenemos en la página, este peso se restará de los enlaces que quedan. Volviendo a nuestro ejemplo, si tenemos 10 links con un peso total de 1000 y cerramos dos de ellos el peso que se distriburá entre los 8 restantes será de 800. “El resto de peso simplemente se evaporará” — dijo Matt Cutts. Es decir que lo único que conseguirá el webmaster es que no pasará el peso a la página enlazada con nofollow.

Normalmente, los enlaces nofollow los ponían los webmasters sobre aquellas páginas que no atraen muchos visitantes. De esta forma no se gastaba el peso para las páginas inútiles pasando un mayor trozo de pastel a las páginas que si atraían una afluencia de visitas.

Despliegue de aplicaciones en Tomcat

7 de Junio de 2009

En esta entrada voy a hablar sobre el despliegue de aplicaciones web en Apache Tomcat. Partimos de la situación cuando tenemos que desplegar una aplicación web en Tomcat que está detrás de un front-end que puede ser Apache, nginx o cualquier otro. Se supone que en el caso de Apache se usa mod_proxy.

Objetivos:

  1. Queremos usar la aplicación Deployer que viene junto a Tomcat y que nos permite desplegar/replegar/parar/arrancar/reiniciar aplicaciones directamente desde un navegador web.
  2. La gestión de hosts virtuales lo dejamos para el front-end en vez de poner múltiples Alias en server.xml.

Existen muchos inconvenientes si dejamos a Tomcat tratar todas las peticiones HTTP. En primer lugar cada petición HTTP va a ocupar bastante más memoria y gastar más tiempo CPU si se trata con Tomcat en vez de con un servidor apropiado, como puede ser Apache o nginx. En segundo lugar, si la petición se procesa mediante Tomcat en primer lugar no se podrá hacer uso de todos los módulos disponibles para Apache. Por último, cada aplicación está hecha para su cosa y para atender peticiónes HTTP están los Apache y nginx y para hacer uso de servlets está el Tomcat.

Primero vamos a configurar el servidor de aplicaciones. Para la explicación de todas las directrices para la configuración de Tomcat se puede echar un ojo a la documentación oficial. Tenemos que conseguir que haya solamente un Engine y un sólo Host que va a ser el que trate las peticiones por defecto. Dentro del Host definiremos un Context que contendrá la aplicación Manager.

La configuración que tengo yo en producción es la siguiente:

<Service name="Catalina">
  <Connector protocol="org.apache.coyote.http11.Http11NioProtocol" URIEncoding="UTF-8" maxThreads="100" port="8080" emptySessionPath="true" />
  <Engine name="Catalina" defaultHost="localhost">
  <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
  <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">
    <Context path="/manager" debug="0" privileged="true" docBase="/path/webapps/manager">
    </Context>
  </Host>
  </Engine>
</Service>

Ahora tenemos que conseguir que el front-end redireccione las peticiones del navegador a http://localhost:8080/manager. Yo lo hago con un dominio de tercer nivel y mod_rewrite. Con mod_rewrite vamos a redireccionar todos los dominios, pero de momento resolvemos el tema de Manager.

En primer lugar he creado un nuevo dominio de tercer nivel apuntando a la máquina. Pongamos por ejemplo http://manager.dominio.com. Luego lo he configurado en Apache para que mediante mod_rewrite se transforme en http://localhost:8080/manager. Las directrices son las siguientes:

<VirtualHost *:80>
ServerName    manager.dominio.com
RewriteRule      (.*)                                /manager/$1 [NS,PT,L]
ProxyPreserveHost       On
ProxyPass               /manager   http://localhost:8080/manager
ProxyPassReverse        /manager   http://localhost:8080/manager
</VirtualHost>

Con esto lo que conseguimos es que si apuntamos el navegador web a http://manager.dominio.com Apache va a pasar la petición a http://localhost:8080/manager, el Tomcat la ejecutará y devolverá la respuesta a Apache y este a su vez la devolverá al navegador. Realmente es un mal ejemplo, porque lo que tenemos que conseguir es que Tomcat procese únicamente los servlets, sin embargo aquí le decimos (con (.*)) que procese todo. Es decir, que si el navegador pide una imagen, esta también será devuelta por Tomcat. Es un mal ejemplo, pero por algo tenemos que empezar.

Una vez que tengamos acceso a la aplicación manager ya podemos desplegar otras. Tan sólo tenemos que generar un fichero war y hacer uso del cuadro WAR file to deploy, el resto lo hará el Tomcat, descomprimirá el fichero war dentro del directorio webapp y hará disponible la aplicación en el contexto http://localhost:8080/NombreFicheroWAR.

Ahora tenemos que configurar Apache para que trate las peticiones. Defineremos lo siguiente:

  1. Que todas las peticiones de servlets las procese el Tomcat.
  2. Que todas las demás peticiones las procese el front-end.

En cuanto al primer punto podemos hacerlo de dos formas. O bien definir un RewriteRule para cada servlet, o bien definir un patrón para los servlets y seguir este patrón a la hora de poner los url-pattern en el fichero web.xml. En cuanto al segundo es suficiente con poner como DocumentRoot la dirección donde va a descomprimir Tomcat el fichero. Hay una cosa superimportante que tenemos que recordar siempre, y es que tenemos que prohibir el acceso a todo el mundo a los directorios WEB-INF y META-INF. En Apache es sencillo:

<Location "/WEB-INF/*">
AllowOverride None
Deny from all
</Location>
<Location "/META-INF/*">
AllowOverride None
Deny from all
</Location>

Si no hacemos esto pondremos en peligro la seguridad de la aplicación entera ya que cualquiera podría descargar las clases compiladas, descompilarlas, etc.

Recursos relacionados:

Hello world!

29 de Septiembre de 2008

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!

CRM TuSala

15 de Marzo de 2008

TuSala es una solución CRM completa implementada desde cero para un cliente español. Se trata de una solución que abarca desde la captación de clientes hasta la puesta en marcha de distribuidores propios de la compañía. Actualmente, el sistema es utilizado por más de 100 distribuidores independientes. Se trata de un proyecto en contínuo desarrollo con el fin de adaptarse a las nuevas realidades del mercado. El concepto radica en que existe un proceso claramente definido que permite vender los productos de la compañía por personas sin conocimientos previos siguiendo simplemente a pie de la letra dicho proceso. El sistema realiza un control estricto sobre cada paso y permite desarrollar una eficiente relación con el cliente.

El proceso de negocio es desarrollado por profesionales con amplia experiencia en el campo de ventas, mientras que de toda la programación y mantenimiento me encargo yo con la colaboración ocasional de otros programadores y diseñadores gráficos.

Como ya se ha mencionado se trata de un sistema en contínuo crecimiento, pero podemos resaltar los siguientes módulos:

  • Captación de prospectos mediante páginas satélite. Cada usuario del sistema dispone de una página (con su propio dominio de segundo nivel) mediante la cual puede captar nuevos prospectos. Una vez que se realiza la captación el usuario puede llevar al prospecto paso a paso hasta convertirlo en cliente.
  • Captación de nuevos miembros para la distribución. Se realiza de la misma forma que en el punto anterior. Cambia un poco la dinámica de la captación y el proceso también es ligeramente distinto.
  • Campañas publicitarias. El objetivo de este módulo es distribuir la cantidad de prospectos entre los distintos usuarios del sistema en función de la cantidad de dinero aportado a la campaña.
  • Cuentas corrientes. Todos los pagos de los usuarios se realizan a nivel interno del sistema. Cada usuario tiene asignada una cuenta corriente virtual mediante la cual puede realizar operaciones.
  • TPV. El objetivo de este módulo es ofrecer la posibilidad de pagar con tarjetas de crédito los productos y servicios ofrecidos por la compañía tanto a los usuarios como a los clientes.
  • Estadísticas. Un extenso módulo de estadísticas permite controlar el rendimiento de cada uno de los distribuidores, realizar análisis y pronósticos.
  • Emailing. El sistema envía diariamente cientos de correos: confirmaciones, boletínes, noticias e información general. Para todo ello se ha desarrollado un potente gestor de correos electrónicos automatizados basado en el motor de templates Freemarker.
  • Generación de PDFs. Un proceso de venta genera muchos PDFs: facturas, cartas publicitarias, etc. El gestor se ha implementado utilizando el motor Apache FOP. El módulo se distingue por el hecho de que permite imprimir en los huecos. Es decir, un distribuidor puede imprimir sus cartas en una imprenta dejando los huecos para la información relevante y el módulo se encarga de rellenar dichos huecos encajando la carta de forma óptima. El objetivo es la reducción de costes.
  • Gestión de ficheros. También se permite la gestión de todo tipo de ficheros necesarios a los distribuidores para desarrollar sus labores diarios.

Números a día de hoy (15 de marzo del 2010):

  • Distribuidores (usuarios) del sistema: 250+
  • Prospectos registrados: 50 000+

Datos técnicos:

  • Lenguaje de programación: Java
  • Gestor de la base de datos: MySQL