Archivo de la categoría: Proyectos

Primeros pasos con Flash Media Server, creando un chat

Hoy vamos a ver cómo crear una sencilla aplicación de chat con Flex. No debe tomarse este ejemplo como una aplicación completa sino simplemente como un método para comprender cómo funcionan los distintos elementos que intervienen. Tampoco debe compararse este proyecto con el cliente IRC que os presenté hace unos meses, aunque ámbos son aplicaciones de chat,  son sistemas distintos, como veréis más adelante.

Chat en Flex con FMS

Flash Media Server (FMS, antiguamente conocido Flash Communication Server) es el software de Adobe que permite crear aplicaciones multiusuario de una manera sencilla y bajo tecnología Flash. FMS permite no sólo intercambiar y sincronizar mensajes de texto entre los clientes sino tambien audio y vídeo. Si flv es el sistema de vídeo por excelencia en Internet, FMS es la tecnología para crear sistemas multimedia multiusuario. La principal pega de FMS es que es de pago, y no precisamente barato, sin embargo existe una licencia «developer» que te permite utilizar el 100% de las posibilidades del servidor, la única limitación es la cantidad de usuarios concurrentes que puedes tener, diez en este caso. Existe una alternativa Open Source a FMS, Red5, pero no lo he utilizado nunca así que no puedo opinar. La teoría con Red5 es exactamente la misma que con FMS, sólo cambia el medio (FMS se programa con ActionScript y Red5 con Java). Como ejemplo de aplicaciones que utilizan FMS está Yahoo Live, la aplicación de grabación directa desde tu webcam de Youtube o todos, absolutamente todos los videochats que puedes encontrar en Internet.

Como lo más probable es que no tengas una licencia de FMS, trabajaremos con la versión developer que hemos indicado ya que nos permitirá poner en práctica todos los conceptos necesarios.  Lo primero que debes hacer es, por tanto, descargar e instalar FMS, hay versiones para servidores Linux y Windows, escoge la que mejor te venga. La instalación no tiene ningún secreto así que lo dejaré en vuestras manos. En mi caso, como siempre, un CentOS5.

Los proyectos creados sobre FMS son sistemas cliente/servidor y necesitan dos aplicaciones para poder funcionar:

  1. Aplicación cliente, sería la parte Flash pura y dura, la que utilizarán los usuarios.
  2. Aplicación servidor, sería lo que corre bajo FMS y a lo que se conecta la aplicación cliente.

Digamos que FMS es la varita mágina del conjunto ya que hace completamente transparente al desarrollador la conexión entre usuarios y la inyección de mensajes entre ellos. Para entenderlo pensemos en un chat donde los usuarios se conectan al servidor y cada vez que uno de ellos escribe un mensaje éste se envía automáticamente a los demás usuarios. Imagina, además, que no sólo hablamos de texto sino que cuando un usuario enciende su webcam los demás usuarios pueden verla. Todo esto lo hace FMS por ti, sólo debes preocuparte de construir tu aplicación.

Programando una aplicación FMS

Empezaremos la parte práctica creando el código necesario en el servidor. Por defecto las aplicaciones FMS de instalan bajo /opt/adobe/fms/applications creando un nuevo directorio con el nombre de tu aplicación, en nuestro caso la llamaremos textchat.

Las aplicaciones se cargan y se mantienen en memoria una vez algún usuario accede por primera vez a la misma y, cuando pasado un tiempo prudencial no hay usuarios, se descarga para liberar recursos esperando a que otro usuario vuelva a acceder. Cada vez que se hacen cambios a la parte servidor de la aplicación hay que reiniciarla, pero no es necesario reiniciar el servidor FMS para reiniciar una aplicación, basta con descargar y volver a cargar esa aplicación desde la consola de administración como veremos más adelante. Desde esta misma consola podremos ver también la salida de los comandos trace que ocurran en el servidor y los objetos creados y su contenido, ayuda imprescindible mientras estás desarrollándola. Veremos también como activar la salida de estas opciones puesto que por defecto (por seguridad) vienen deshabilitadas.

Por defecto todas las aplicaciones deben tener un archivo main.asc con el código necesario.  Crea tu main.asc de esta manera:

load("netservices.asc");

application.onAppStart = function(){
  trace("inicia text chat");
  this.users_so = SharedObject.get("users_so", false);
  this.chat_so = SharedObject.get("chat_so", false);
  this.userList = {};
  this.uid = 1;
}

application.onConnect = function(client, nick, clave, sala){
  trace(nick+" "+clave+" "+sala);
  var valido=1;
  for( i in this.userList){
    if(String(this.userList[i].nick).toLowerCase()==String(nick).toLowerCase()){
      valido=0;
      break;
    }
  }
  if(valido==1){
    client.uid = this.uid;
    client.nick = nick;
    client.sala = sala;
    this.acceptConnection(client);
    this.userList[client.uid] = client;
    this.users_so.setProperty(client.uid, client);
    var msg = "<font color='#666666'><b>*** Entra " + client.nick + " ***</b></font><br>";
    this.chat_so.send("onMsgSend", msg);
    client.call("onUserid", null, client.uid, client.nick);
    this.uid++;
  }else{
    var err = new Object();
    err.message = "Ya hay un usuario con ese nick";
    trace(err.message);
    application.rejectConnection(client, err);
  }
}

application.onDisconnect = function(oldClient){
  if(oldClient.uid!=undefined){
    trace("Descontecta cliente. UID:  " +oldClient.uid);
    var msg = "<font color='#666666'><b>*** " + oldClient.nick + " sale ***</b></font><br>";
    this.chat_so.send("onMsgSend", msg);
    for( i in application.userList){
      if(Number(application.userList[i].uid)==Number(oldClient.uid)){
        application.userList[i]=undefined;
      }
      k++;
    }
    application.disconnect(oldClient);
    application.users_so.setProperty(oldClient.uid, null);
  }
}

El funcionamiento es muy sencillo. Nuestra aplicación maneja tres eventos:

  1. onAppStart: Se dispara cuando la aplicación se carga en memoria por primera vez.
  2. onConnect: Se lanza cuando un usuario se conecta a la aplicación.
  3. onDisconnect:Cuando un usuario se desconecta.

Veamos la teoría de un chat y comprenderemos rápidamente como funciona FMS en su lado servidor. En una aplicación chat típica, el servidor debe manejar una lista de los usuarios conectados actualmente (los nicks) y debe poder ser capaz de enviar mensajes a todos los usuarios. Por ejemplo, cuando un nuevo usuario se conecta y sin que éste escriba nada, el servidor tiene que poder enviar un mensaje tipo «Nick se ha conectado al chat» a todos los demás usuarios.  Para solucionar todo esto FMS tiene lo que se conocen como objetos compartidos (SharedObjects), objetos a los que todos los clientes pueden acceder.

Si analizas ahora el código de nuestro main.asc verás que el evento onAppStart crea las variables que se utilizarán en la aplicación:

  • userList: array que contendrá la lista de usuarios conectados al sistema.
  • uid:  identificador del último usuario conectado para poder localizar de manera inequívoca a un cliente.
  • users_so: objeto compartido de la lista de usuarios
  • chat_so: objeto compartido del chat propiamente dicho, a él se envíen los mensajes que escriben los usuarios.

Creo que sobran más explicaciones ya que es tan sencillo que se entiende sólo.

Veamos ahora la teoría de qué ocurre cuando se conecta un usuario, evento onConnect. Cada vez que un cliente accede a nuestro chat debemos comprobar, antes de nada, siya hay otro usuario con el mismo nick, en cuyo caso rechazamos su conexión. Si todo va bien y su nick es único debemos guardar al usuario en la lista de usuarios y avisar a todos los clientes ya conectados que hay un nuevo usuario en el chat.

Compara ahora la teoría con el código del evento. El parámetro cliente es automático y representa al cliente que se conecta. Es un objeto con distintos parámetros predefinidos. Los demás parámetros del evento se los pasaremos nosotros desde nuestro cliente flash. Para ver si un nick ya existe simplemente lo comparamos contra todos los demás del array userList que ya hemos visto que contiene a todos los usuarios conectados. El evento onConnect puede aceptar un cliente (acceptConnection) o rechazarlo (rejectConnection).

Si el usuario ha sido admitido, le damos el siguiente UID y tendremos entonces que avisar a los demás usuarios de que tenemos un usuario nuevo. Si recordamos las variables que teníamos, había un objeto compartido al que tienen acceso todos los clientes, users_so, solo tendremos que añadir nuestro nuevo cliente a este objeto:

this.users_so.setProperty(client.uid, client);

Cuando veamos la aplicación cliente veremos como detectamos los cambios en ese objeto, pero es sumamente sencillo.

Espera!. Nos falta enviar el mensaje de «Nick se ha conectado al chat». Tan sencillo como:

this.chat_so.send("onMsgSend", msg);

Magia!. Como chat_so era un objeto compartido, todos los clientes y el servidor tienen acceso al mismo y lo que uno escriba lo recibirán automáticamente todos los demás. Esta es la verdadera magia de FMS, no tienes que preocuparte de cómo enviar los mensajes a los usuarios uno a uno, se sincronizan sólos.

Como último detalle, cuando aceptamos la conexión de un cliente llamamos remotamente al método onUserid de la aplicación cliente. Si! has leído bien!, FMS llama a una función de tu SWF!. Más adelante veremos para qué, simplemente recuerda que cuando te conectas al chat el servidor llama a un método de la aplicación pasándole su propio UID.

Finalmente veamos el último evento del servidor, bastante obvio si has seguido lo explicado anteriormente y lo has entendido, la desconexión de un usuario.

Sin pensar mucho más entenderemos que habrá que eliminar al cliente de userList y de users_so. Pues eso mismo, no hay mucha más ciencia.

Ya tenemos la parte del servidor terminada. Sencillo ¿no?. Es posible que aún no entiendas algunas cosas. Tranquilo, cuando veamos el cliente lo entenderás todo y verás que realmente es muy sencillo crear aplicaciones de este tipo con FMS.

La consola de administración

Es una aplicación Flash desde la que podemos conectarnos como administradores al servidor FMS y realizar operaciones de mantenimiento, entre ellas cargar y descargar instancias de aplicación, ver el log del sistema (los trace), examinar objetos (en modo debug)…

Cuando instalaste FMS te pidió un usuario y una clave además de un puerto donde instalar esta consola de administración. No tienes más que conectarte a ella y comenzarás a ver estos datos.

Consola de administración de FMS

Hay, sin embargo, algunas particularidades de administración que conviene tener en cuenta. Para habilitar las opciones de debug de objetos habrá que modificar el fichero conf/_defaultRoot_/_defaultVHost_/Application.xml cambiando:

<AllowDebugDefault>false</AllowDebugDefault>

a true. Reinicias el servidor para que el cambio se active y verás algo como esto que te servirá para depurar tu aplicación.

Consola de administración de FMS

En la barra de opciones de aplicación (Live log, clients…) tienes dos pequeños botones que te permitirán recargar una instancia de la aplicación o descargarla por completo, las opciones que comentábamos antes que te ayudarán durante el desarrollo para no tener que reiniciar todo el servidor.

La aplicación cliente

Y llegamos al último punto. La aplicación, el chat, lo que ve el usuario.

Ya os he puesto una captura del resultado final. Veremos ahora los entresijos. Abajo de todo tenéis el código fuente de todo el proyecto de demostración.

Me meteré directamente al meollo de conectar con FMS y enviar y recibir datos, la interfaz de usuario y la pantalla inicial de login la dejo para vosotros. Como veréis hay una clase Chat.as que centraliza casi todo el proceso de comunicación con el servidor.

chat = new Chat();
chat.addEventListener(UserIDEvent.USER_ID, onUID);
chat.addEventListener(NCEvent.STATUS, onStatus);
chat.addEventListener(NCEvent.NONICK, onStatus);

salaSeleccionada=sala.selectedItem.toString();
chat.init("rtmp://"+host+"/textchat/"+salaSeleccionada, StringUtil.trim(nick.text), StringUtil.trim(clave.text), salaSeleccionada);

private function onUID( event:UserIDEvent ):void{
    miuid=event.userid;
    currentState = "chatState";
    msg.setFocus();
    CursorManager.removeBusyCursor();
    this.addEventListener(KeyboardEvent.KEY_UP,keyHandler);
    picker.addEventListener(DropdownEvent.CLOSE, pickerClose);   
}

private function onStatus( event:NCEvent ):void{
    CursorManager.removeBusyCursor();
    if (event.status == "closed"){
        status.text = "Desconexión completa.";
    }
    if (event.status == "nickexiste"){
        status.text = "Usuario o contraseña incorrectos.";
    }
    currentState = "";
}

Al crear la instancia de Chat haremos que se detecten un par de eventos que ejecutarán:

  •  onUID: se dispara cuando el servidor, como hemos visto antes, llama al método cliente onUserid. Nos sirve para cambiar el estado de la interfaz de usuario desde la ventana de login a la de chat ya que sólo si hemos conectado recibiremos el UID.
  • onStatus: nos ayudará adetectar conexiones rechazadas y tu propia desconexión.

Para conectar véis que llamamos al método init de Chat con cuatro parámetros, la url de la instancia de nuestra aplicación (definida como host+aplicacion+sala de chat), el nick, la clave (para un futuro) y la propia sala de chat. Si examinas este método verás qué sencillo es iniciar una conexión. El método más importante es

private function netStatus( event:NetStatusEvent ):void{
    var info:Object = event.info;
    switch(info.code)
    {
    	case "NetConnection.Connect.Success":
    	    users_so = SharedObject.getRemote("users_so", nc.uri, false);
    	    users_so.addEventListener(SyncEvent.SYNC, usersSync);
    	    users_so.addEventListener(NetStatusEvent.NET_STATUS, onSOnetStatus);
    	    users_so.addEventListener(SecurityErrorEvent.SECURITY_ERROR, onSOSecurityError);
    	    users_so.client = this;
    	    users_so.connect(nc);
    	    chat_so = SharedObject.getRemote("chat_so", nc.uri, false);
    	    chat_so.addEventListener(NetStatusEvent.NET_STATUS, onSOnetStatus);
    	    chat_so.addEventListener(SecurityErrorEvent.SECURITY_ERROR, onSOSecurityError);
    	    chat_so.client = this;
    	    chat_so.connect(nc);
    	    break;
    	case "NetConnection.Connect.Rejected":
    	    dispatchEvent( new NCEvent(NCEvent.NONICK, "nickexiste"));
    	    break;
    	case "NetConnection.Connect.Closed":
    	    dispatchEvent( new NCEvent(NCEvent.STATUS, "closed"));
    	    break;
    }
}

Es el que detecta el estado de la conexión, si el servidor nos acepta o nos rechaza tal como veíamos antes e incluso si nos desconecta. Fíjate que si somos aceptados estaremos conectándonos a los SharedObjects que creamos antes en el servidor 😉 . Ahora es Chat quien hará absolutamente todo el trabajo, la aplicacion mxml es la interface de usuario que transmite a Chat los comandos necesarios. Veamos por ejemplo como indicamos al chat que envíe a los demás usuarios un mensaje que hayamos escrito nosotros.

private function sendMsg():void{
    if ( msg.text.length > 0 ){
        chat.sendMsg(msg.text);
        msg.text = "";
    }
}

Vale sí, pero has hecho trampas, aquí estás dejando el meollo en manos de Chat 😛 . Bien, veamos qué ocurre en sendMsg.

public function sendMsg( color:String, msg:String ):void{    
    var outmsg:String = "";    
    outmsg = "<font color='#" + color + "'><b>" + this.username+":</b> " + msg + "</font><br>";
    chat_so.send("onMsgSend", outmsg);
}

¡ Sólo eso ! Como ya estamos conectados al SharedObject chat_so, le decimos a éste que llame al método onMsgSend de sus clientes y le pase el texto que hemos escrito.

De acuerdo, entonces ¿cómo leemos los mensajes que escriben los demás usuarios?. Te lo acabo de decir 😛 . Cuando un usuario escribe algo, llama (da igual cómo) a un método local de cada usuario que se encarga de escribir el texto en su ventana de chat.

public function onMsgSend( msg:String ):void{
    chatHistory += msg;        
    dispatchEvent(new Event("histChange"));
}

Obviamente este método tiene que ser público. Al despachar ese evento simplemente hace que se actualice el texto del textarea.

Hasta ahora creo que lo voy entendiendo, pero no has explicado como detectamos las entradas y salidas de usuarios. Cierto, veámoslo pues. Acabamos de ver que cuando entramos al chat y somos admitidos conectamos con los SharedObjects que creamos en el servidor. Si te has fijado (y si no hazlo ahora), al de usuarios le poníamos un listener distinto:

users_so.addEventListener(SyncEvent.SYNC, usersSync);

Esto significa que cada vez que haya un cambio en el objeto users_so todos los clientes serán notificados de ello. Por ejemplo, cada vez que entra o sale un usuario vimos que añadíamos o quitábamos un elemento de este objeto que representaba a ése usuario. Cada una de estas operaciones hará que nuestra aplicación cliente reciba una llamada a usersSync.

private function usersSync(event:SyncEvent):void{
    var results:Object = event.target.data;
    var usersArray:Array = new Array();
    var existe:Boolean=false;
    //debo actualiza solo los datos
    for( var i:String in results ){
        if(results[i].sala==this.sala){
            existe=false;
            for(var j:Number=0; j<dpUsers.length; j++){
                if(dpUsers[j].uid==results[i].uid){
                    existe=true;
                    break;
                }
            }

            if(existe){
                //por si se ha cambiado el nick
                dpUsers[j].nick=results[i].nick;
            }else{
                var clientObj:Object=new Object();   
                clientObj.nick = results[i].nick;
                clientObj.uid = results[i].uid;
                dpUsers.addItem(clientObj);
            }
        }
    }
    //ahora tengo que eliminar las bajas
    //elimino empezando por la ultima para no cambiar los indices
    for(j=dpUsers.length-1; j>=0; j--){
        existe=false;
        for(i in results ){
            if(dpUsers[j].uid==results[i].uid && results[i].sala==this.sala){
                existe=true;
            }
        }

        if(!existe){
            dpUsers.removeItemAt(j);
        }
    }
    //finalmente ordenamos los usuarios
    var sort:Sort = new Sort();
    sort.fields = [new SortField("nick",true)];
    dpUsers.sort = sort;
    dpUsers.refresh();
    dispatchEvent(new Event("dpChange"));           
}

Esta método repasará todos los usuarios del SharedObject comparándolos con los de la lista de usuarios del canal donde nos encontramos chateando y añadiendo los nuevos usuarios y eliminando los que hayan salido.  Quizás no sea el mejor método para manejar los usuarios y habría sido mucho más sencillo tener una pareja de métodos addUsuario y delUsuario que manejen todo automáticamente con llamadas remotas igual que con los mensajes, pero quería que viésemos el modo de recibir avisos de cambios en un SharedObject.

Conclusiones

Hemos visto cómo de una manera sencillísima podemos crear nuestro propio chat sin excesivas complicaciones. Piensa además que esto es, seguramente, lo más sencillo, el primer paso con FMS, las posibilidades reales son infinitas.

Quizás en otros artículos ampliemos las posibilidades de este pequeño ejemplo añadiendo vídeo y audio o, incluso, hagamos un pequeño sistema de grabación de vídeo con tu webcam similar al de Youtube.

Como siempre, aquí os dejo el código completo del proyecto. Recuerda que es un ejemplo de lo que se puede hacer, no debes usarlo tal cual sino aplicar lo que hemos explicado. Del mismo modo habrá cosas que no sean perfectas y se puedan hacer mejor, no lo dudo, mi intención era explicar los conceptos básicos de FMS y que se vea su potencial.

Cómo emitir webcams en vivo con un servidor Linux y en formato FLV

Hace un tiempo tuve un cliente que quería visualizar las cámaras que había instalado en su oficina desde su casa. En aquel momento eran cámaras IP cableadas. Este tipo de cámaras tienen un servidor web integrado desde donde puedes configurar su dirección IP además de ver el vídeo que transmiten. Por lo general estas cámaras transmiten en formato mjpeg, un flujo de imágenes JPG normales, aunque también podría ser que lo hiciesen directamente en mpeg. Firefox es capaz de reproducir este formato directamente, no así Internet Explorer que necesita de un applet Java para hacerlo.

El reto consistía, por tanto, en transmitir las cámaras en un formato que se pudiese reproducir fácilmente y que se pudiese integrar en una página web, sin programas de terceros para visualizarlas. Así llegamos a la solución que hoy os presento y que no es exclusiva de cámaras IP sino que puedes utilizar cualquier webcam USB que tengas por casa. El formato que hemos escogido para el flujo de vídeo será flv,  con lo que con una sencilla aplicación Flash podremos visualizar cada una de nuestras cámaras evitando, de paso, los applets Java.

Para el proyecto de hoy necesitaremos:

  • Servidor Linux, imprescindible, en mi caso Centos5
  • Apache instalado en el servidor.
  • ffmpeg, para hacer la conversión de formatos
  • ffserver, parte del paquete ffmpeg, para transmitir elvídeo

Si no tienes el software necesario, el primer paso es instalarlo. En mi caso:

yum install ffmpeg apache

Comenzaremos configurando ffserver desde /etc/ffserver.conf:

Port 8090
BindAddress 0.0.0.0
MaxClients 1000
MaxBandwidth 10000            

<Feed feed1.ffm>
  File /tmp/feed1.ffm
  FileMaxSize 5M
</Feed>
<Feed feed2.ffm>
  File /tmp/feed2.ffm
  FileMaxSize 5M
</Feed>            

<Stream camara1.flv>
  Feed feed1.ffm
  Format flv
  VideoCodec flv
  VideoBitRate 128
  VideoBufferSize 500
  VideoFrameRate 5
  VideoSize 320x240
  NoAudio
  Preroll 5
</Stream>            

<Stream camara2.flv>
  Feed feed2.ffm
  Format flv
  VideoCodec flv
  VideoBitRate 128
  VideoBufferSize 500
  VideoFrameRate 5
  VideoSize 320x240
  NoAudio
  Preroll 5
</Stream>            

<Stream stat.html>
  Format status
</Stream>

ffserver funciona como un servidor, transmitiendo en el puerto que le indiquemos lo que recibe en los archivos que se indican en los feed’s. A continuación se indican los flujos de vídeos que vamos a utilizar (feed’s), en mi caso dos cámaras. Finalmente definimos los streams que será a lo que realmente nos conectaremos nosotros, un stream por cada feed en formato flv. Podríamos crear tantos streams de cada feed como creamos oportuno en distintos formatos, consulta la ayuda de ffserver y ffmpeg.  Finalmente creamos un stream especial, el de status, donde veremos información sobre el estado del servidor y clientes contectados.

Lanzamos el servidor ffserver tal cual.

ffserver

Con esta configuración tendremos acceso a dos flujos de vídeo en formato FLV en las direcciones:

http://localhost:8090/camara1.flv
http://localhost:8090/camara2.flv

Vale, sí, aún no hemos transmitido el vídeo, eso viene ahora. Debemos enlazar el flujo de vídeo de nuestras cámaras con ffserver para que éste haga la conversión de formato y lo emita por las urls indicadas. Para hacerlo recurrimos al inseparable compañero de ffserver, ffmpeg.

Si tus cámaras están conectadas al servidor bien sea por USB o por capturadoras de vídeo (debes tenerlas configuradas previamente):

ffmpeg -f video4linux -s 320x240 -r 5 -i /dev/video0 http://localhost:8090/feed1.ffm
ffmpeg -f video4linux -s 320x240 -r 5 -i /dev/video1 http://localhost:8090/feed2.ffm

Si tus cámaras fuesen IP habría que capturar primero el vídeo desde la cámara y pasárselo a ffmpeg, por ejemplo:

curl http://ip-de-tu-camara:8080 | ffmpeg -er 4 -y -v quiet -an -f mjpeg -r 4 -i - http://localhost:8090/feed1.ffm

Sea como sea el formato de tus cámaras, y si todo ha ido bien, tendrás a ffmpeg enviando el vídeo a ffserver para que lo convierta a FLV y lo publique en las URL’s anteriormente indicadas.

Debes tener cuidado con un detalle importante si conectas más de una cámara USB, debes enchufarlas a concentradores distintos de tu equipo para diversificar adecuadamente los flujos de vídeo y el ancho de banda que ocupan, si conectases dos cámaras al mismo concentrador no tendrían ancho de banda suficiente y se bloquearían entre ellas.

Veamos ahora como visualizar los flujos de vídeo. Necesitaremos el editor de Flash de toda la vida. Creamos un nuevo documento y arrastramos al escenario un objeto FLVPlayback. Como nombre de instancia le ponemos «video» y en sus propiedades ponemos isLive a true. En el primer frame añadimos el siguiente código:

video.contentPath=path_video;

De esta manera podremos indicar desde html la url del flujo de vídeo sin tener que tener un swf por cada cámara. Compila y publica el proyecto puesto que ya hemos terminado.

No me voy a preocupar ahora del código html generado, eso es cosa tuya. Dentro del archivo html que te genera el editor de flash tendrás algo como:

<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0" width="550" height="400" id="webcam1" align="middle">
<param name="allowScriptAccess" value="sameDomain" />
<param name="movie" value="webcam.swf" />
<param name="quality" value="high" />
<param name="bgcolor" value="#ffffff" />
<embed src="webcam.swf" mce_src="webcam.swf" quality="high" bgcolor="#ffffff" width="550" height="400" name="webcam1" align="middle" allowScriptAccess="sameDomain" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer" />
</object>

Vamos a convertirlo en esto:

<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0" width="550" height="400" id="webcam1" align="middle">
<param name="allowScriptAccess" value="sameDomain" />
<param name="movie" value="webcam.swf?path_video=http://192.168.90.1:8090/camara1.flv" />
<param name="quality" value="high" />
<param name="bgcolor" value="#ffffff" />
<embed src="webcam.swf?path_video=http://192.168.90.1:8090/camara1.flv" mce_src="webcam.swf?path_video=http://192.168.3.2:8090/camara1.flv" quality="high" bgcolor="#ffffff" width="550" height="400" name="webcam1" align="middle" allowScriptAccess="sameDomain" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer" />
</object>

Es decir, añadimos al parámetro de la película la variable path_video con la url del flujo tal y como lo hemos generado antes. Debe ser una URL a la que se pueda acceder externamente pues el swf se conectará a ella para recoger el flujo flv generado por ffserver, si tienes un router o un firewall de por medio, deberás abrir ese puerto. Copiaremos este código tantas veces como cámaras tengamos modificando la URL del flujo de vídeo.

Voila! esto es todo, ya tienes publicadas tus cámaras en un formato sencillo de visualizar como es el FLV.  Abre la página html que has creado y comenzarás a visualizar tus cámaras.

Pero… vayamos un paso más allá. Con lo que hemos visto hasta ahora tendremos que abrir el puerto 8090 de buestra máquina para permitir el acceso a los flujos de vídeo, pero nosotros no queremos hacer esto, ya tenemos el puerto 80 con Apache a la escucha. ¿Qué hacemos? Sencillo, mod_proxy viene a nuestro rescate. Asegúrate de tenerlo habilitado en la configuración de tu Apache. Después simplemente habrá que añadir las siguientes líneas a la configuración del virtual host en el que quieres publicar los streams:

ProxyPass /camara1.flv http://127.0.0.1:8090/camara1.flv
ProxyPassReverse /camara1.flv http://127.0.0.1:8090/camara1.flv        

ProxyPass /camara2.flv http://127.0.0.1:8090/camara2.flv
ProxyPassReverse /camara2.flv http://127.0.0.1:8090/camara2.flv

Con esto estaremos enviando automáticamente cada stream desde su url original en el puerto 8090 a una url de tu virtual host del tipo http://tudominio.com/camaraX.flv. Esa ruta no existe físicamente, es virtual y Apache sabe que debe redirigirla al stream del ffserver.

Finalmente queda un detalle importante. Hasta ahora habíamos incializado ffserver por un lado y los flujos de las cámaras por otro con ffmpeg. Esto es un rollo y no nos gusta, queremos que ffserver lo inicie todo automáticamente. Pues vale, añadamos una directiva Launch a cada feed de la configuración de ffserver con los parámetros que utilizábamos para llamarlo desde la línea de comandos. En el ejemplo de nuestra primera cámara quedaría:

<Feed feed1.ffm>
  File /tmp/feed1.ffm
  FileMaxSize 5M
  Launch  ffmpeg -f video4linux -s 320x240 -r 5 -i /dev/video0
</Feed>

A partir de ahora, cada vez que lancemos ffserver tecleando simplemente ese comando, se inciarán, además del propio servidor, los streams que hayamos definido.

Hasta aquí hemos llegado por hoy. De una manera extremadamente sencilla hemos publicado nuestras webcams. Es responsabilidad tuya y sólamente tuya el asegurar el acceso a los flujos y a la página de visualización que hemos creado. Otro día quizás veamos cómo montar un sistema de videovigilancia casero con detector de presencia 😉 .

Os dejo el código de la aplicación Flash de visualización de los streams.

Usando certificados SSL de cliente como sistema de autenticación web

A menudo creamos aplicaciones web con un backend de gestión que, por ser también web, exponemos públicamente a cualquiera que consiga averiguar la URL. Habitualmente estos sistemas son de acceso restringido, sólo un pequeño grupo de usuarios lo utiliza.

En escenarios donde tenemos un número de usuarios acotado y se necesita autentificación, se puede utilizar un mecanismo de certificados que aporten mayor seguridad al sistema, de esta manera solo aquellos usuarios que tengan el certificado en cuestión tendrán acceso a la máquina.

Hoy veremos como permitir el acceso a nuestra aplicación a aquellos usuarios que dispongan de un certificado que previamente les habremos enviado mientras que si no lo tienen no podrán acceder de ningún modo. Este método se puede combinar, además, con el tradicional usuario/clave para dar mayor seguridad. Podremos incluso verificar que el nombre de usuario que se intenta utilizar se corresponde con el certificado de usuario que le hemos enviado y no intenta autentificarse con otro.

Conceptos básicos sobre certificados SSL

El método que vamos a ver se basa en certificados SSL. Se utilizan para asegurar la información entre un cliente y el servidor y prevenir escuchas ya que la información viaja encriptada. Ésta es su función y la hace aunque no esté firmado por una autoridad certificadora (CA) oficial o, incluso, aunque esté caducado. Sigue asegurando las comunicaciones.

Los navegadores web reconocen, por defecto, una serie de autoridades certificadoras como Verisign o Thawte, aunque hay muchas más. Puedes verlas todas en las opciones de tu navegador. Pero, ¿qué es realmente lo que hace una Autoridad Certificadora? Firmar. Firma tu certificado SSL asegurando que os pertenece a ti y a tu dominio. Cuando un cliente accede a tu dominio y descarga el certificado SSL, busca dentro de sus certificados de CA‘s si hay alguno que lo haya firmado. Si lo encuentra, acepta tu certificado y no ocurre nada especial, pero si no encuentra la CA lanza un aviso indicando que no se reconoce la autoridad que lo firma. Esto no quiere decir que el certificado no sea válido, lo único que ocurre es que no sabe quien lo firma. Esto significa, por tanto, que tú mismo puedes ser tu propia autoridad certificadora y firmar tus certificados, funcionarán perfectamente y cumplirán su cometido de asegurar las comunicaciones cliente/servidor.

Comercialmente o en sistemas de acceso público en general, no se recomiendan certificados autofirmados ya que el aviso de autoridad de certificación no reconocida generará desconfianza entre tus usuarios, pero en entorno intranet o de paneles de adminsitración es un método ideal.

El servidor puede requerir, además, otro certificado al cliente, de manera que ámbos extremos autentifiquen la comunicación. Esto es precisamente lo que vamos a hacer hoy en este artículo.

Según lo que hemos explicado, los certificados autofirmados son igual de seguros que los firmados por una autoridad certificadora. Como en el ejemplo que estamos viendo estamos asegurando el acceso a nuestra aplicación para un grupo reducido de usuarios, no hay ningún problema en utilizar un certificado firmado por nosotros mismos ya que nuestros usuarios sabrán que no hay ningún problema. Pero esto no es todo, por esta misma razón podemos decir a los usuarios que se instalen el certificado público de nuestra CA, tal y como hacen las CA oficiales, y automáticamente el navegador comenzará a confiar en nuestros certificados ya que, ahora sí, tiene un certificado de una CA que firma los certificados SSL.

Como resumen, nuestro trabjo consistirá en:

  • Crear nuestra autoridad certificadora y su certificado.
  • Crear el certificado SSL para nuestro servidor web firmado por nuestra CA.
  • Crear los certificados de cliente para nuestros usuarios.
  • Habilitar la lectura de los datos SSL desde PHP.

Servidor web SSL

Utilizaremos el paquete Openssl para generar los certificados. Si aún no lo tienes instalado en tu servidor, es el momento. Explicaré de manera rápida como crear crear certificados SSL para asegurar las comunicaciones ya que es el primer paso necesario para añadir certificados de cliente, sin embargo no es el objeto principal de este artículo y hay mucha documentación, googlea un poco 😉 .

Primero creamos el certificado y la clave privada de nuestra autoridad de certificación:

openssl req -x509 -newkey rsa:2048 -days 3650 -keyout CAXplotaKey.pem -out CAXplotacert.pem

Lo más importante de este comando es el parámetro days, ya que no queremos que dentro de un año nos caduque el certificado de nuestra propia entidad. Yo le pongo 10 años. Este comando genera dos archivos, la clave privada con la que firmaremos nuestros futuros certificados y el certificado con la clave pública que instalaremos, si queremos no recibir avisos, en el navegador. Este comando te pedirá algunos datos (nombre de empresa, país…) y, sobre todo, una contraseña. Deberás recordarla cada vez que vayas a firmar un certificado SSL, así que no la olvides. Ya tenemos nuestra CA creada.

Creamos ahora el certificado SSL para nuestro dominio:

openssl genrsa -des3 -out claveprivada.pem 2048
openssl req -new -key claveprivada.pem -out certificado.pem

El primer comando crea la clave privada de nuestro certificado. Te pedirá otra contraseña, esta vez para la clave privada. Recuérdala también.

El segundo comando genera la petición de certificado sobre la clave privada anterior. Te pedirá la contraseña de la clave privada anterior.

En este punto tenemos cuatro archivos, la clave y el certificado de tu CA y la clave y la solicitud de tu certificado SSL. Sólo queda firmar el certificado con nuestra CA y ya podremos utilizarlo.

Para poder firmarlo debemos generar primero un fichero de texto con algunos parámetros de configuración:

cat configservidor.cnf

basicConstraints = critical,CA:FALSE
extendedKeyUsage = serverAuth

Y firmamos el certificado.

openssl x509 -CA CAXplotacert.pem -CAkey CAXplotaKey.pem -req -extfile configservidor.cnf -in certificado.pem -days 3650 -CAcreateserial -sha1 -out certificado-servidor.pem

Ya tenemos un certificado SSL preparado para utilizar en nuestro servidor web. En nuestro caso es certificado-servidor.pem. Vamos a configurar Apache para que lo utilice.

Habrá que editar httpd.conf y añadir

LoadModule ssl_module modules/mod_ssl.so
Listen 443

Es probable que, si no has compilado tu propio Apache y has instalado un paquete precompilado, tengas ya algún ssl.conf. Activándolo tendrás este paso preparado. En mi caso, un CentOS5, sólo hay que incluir /etc/httpd/conf.d/ssl.conf.

Finalmente hay que indicar en el virtual host que quieres asegurar que use nuestro nuevo certificado. Para hacerlo añadimos un nuevo virtual que escuche en el puerto 443 y añadimos las siguientes líneas:

SSLEngine on
SSLCertificateFile /ruta/a/certificado-servidor.pem
SSLCertificateKeyFile /ruta/a/claveprivada.pem

Si ahora reinicias Apache y accedes a tu dominio con https verás que en tu navegador aparece el candado indicando que la información es segura. Verás también que te aparece un aviso de que no se confía en la autoridad certificadora. Veremos más adelante como solucionarlo.

Añadiendo certificados de cliente

Ahora que ya tenemos nuestro servidor web seguro con nuestros certificado autofirmado llega el momento de crear certificados para nuestros clientes de manera que si alguien intenta acceder a nuestra aplicación sin uno de ellos se le prohíba el paso.

Crearemos primero un archivo de configuración con los parámetros que necesitaremos.

cat configcliente.cnf

basicConstraints = critical,CA:FALSE
extendedKeyUsage = clientAuth

Con esto daremos instrucciones de que es un certificado cliente a la hora de firmar el certificado.

Creamos ahora, igual que hacíamos antes, la clave privada y la solicitud de certificado.

openssl genrsa -des3 -out clave-cliente.pem 2048
openssl req -new -key clave-cliente.pem  -out certificado-cliente-req.pem

Como antes, al generar la clave te pedirá una contraseña que deberás introducir después, al hacer la solicitud de certificado. Los datos que te pide esta solicitud, como ocurría antes, los podrás leer posteriormente para comprobar datos o lo que estimes oportuno, así que es importante que prestes atención.

Firmamos ahora el certificado con nuestra CA:

openssl x509 -CA CAXplotacert.pem -CAkey CAXplotaKey.pem -req -in certificado-cliente-req.pem -days 3650 -extfile configcliente.cnf  -CAcreateserial -sha1 -out certificado-cliente.pem

Como véis, el proceso es el mismo para generar el certificado de servidor, pero cambiamos el contenido del archivo de configuración que le indica que es un certificado cliente, no servidor.

Vale, bien, pero ¿no quedamos que es el cliente el que debe instalar el certificado? Sí, ahí vamos ahora. El certificado que acabamos de generar lo debes instalar en tu navegador web, no en el servidor, así que habrá que convertirlo a algún formato que puedan entender. Para esto hacemos lo siguiente:

openssl pkcs12 -export -in certificado-cliente.pem -inkey clave-cliente.pem -certfile CAXplotacert.pem -out cliente.p12

Nos pedirá la contraseña de la clave privada del certificado y nos solicitará otra para el que va a generar. Es importante poner contraseña al certificado final ya que es el que vas a enviar a tus usuarios y pretendes que sólo estos puedan utilizarlo, así que poner una contraseña nunca está demás.

Ya tienes tu certificado cliente.p12. Puedes probarlo tu mismo. Ah no, espera, que no hemos configurado el servidor web para que solicite sí o sí un certificado al cliente. Añade a la configuración SSL de tu virtual host de Apache:

SSLCACertificateFile /path/a/CAXplotacert.pem
SSLVerifyClient require

Y reinicia tu servidor web. Si ahora intentas acceder a tu dominio verás como salta una ventana solicitando un certificado que no tienes. Desde las opciones de tu navegador, busca la sección de certificados SSL y añade un nuevo certificado. Selecciona tu cliente.p12. Te pedirá la contraseña que pusiste al convertirlo a pk12. Ya está. Accede ahora y verás como te aparece el certificado en la ventana de certificiados disponibles y, si lo seleccionas, te deja acceder a tu aplicación.

Revocar certificados

A veces puede ser necesario prohibir el paso con determinados certificados, bien porque el usuario ya no colabora o trabaja contigo, bien porque hay posibilidades de que el certificado haya sido robado, etc. Una opción es, a la hora de crear el certificado, y si sabes de antemano que el usuario lo necesitará pocos días (cuenta de prueba, usuario esporádico o cualquier razón similar), generarlo con una validez limitada (10 días, un mes, etc.), de modo que pasado este tiempo el certificado caduca y el usuario no puede entrar. El problema más importante lo tendrás cuando necesites prohibir el acceso a usuarios con certificados a largo plazo. Para hacerlo debemos crear una lista de revocación de certificados.

En mi caso (CentOS5 y RHEL5) tuve algunos problemas de configuración. Openssl debería de mantener una lista de los certificados que emite y sus números de serie sin embargo tal como hemos generado nuestros certificados no lo hace. Para solucionarlo, creamos a mano la lista.

touch /etc/pki/CA/index.txt

Ahora debemos editar el archivo de configuración de Openssl para reflejar algunos parámetros. Por defecto indica una ruta relativa hacia los directorios donde dejará los certificados, pero no me funcionó bien hasta que no le puse rutas absolutas. Modificamos pues la ruta al directorio y le indicamos donde están la clave privada y el certificado de nuestra CA.

Editar /etc/pki/tls/openssl.cnf

dir             = /etc/pki/CA              # Where everything is kept
certificate     = /path/a/CAXplotacert.pem    # The CA certificate
private_key     = /path/a/CAXplotaKey.pem # The private key

Ahora sí, podemos revocar un certificado de manera tan sencilla como:

openssl ca -revoke certificado-cliente.pem

A partir de la lista con el estado de los certificados debemos crear una lista de revocación que usaremos para indicar al servidor web los certificados que no debe permitir.

openssl ca -gencrl -out recovados.crl

Es posible que al lanzar este comando te apareza otro error relacionado con crlnumber. Esto viene relacionado con lo que os indicaba antes y es simplemente que no existe el archivo de números de serie. Para solucionarlo, simplemente lo creamos:

echo "01" > /etc/pki/CA/crlnumber

Y volvemos a generar la lista de revocación. Cada vez que revoques un certificado deberás repetir esta operación para tener la nueva lista.

Ya sólo falta indicarle a Apache qué certificados no debe permitir. Añadimos a la configuración de nuestro virtual host, en el mismo sitio donde configuramos anteriormente el certificado SSL, la siguiente línea:

SSLCARevocationFile path/a/revocados.crl

Eso es todo, ya tenemos nuestro servido SSL funcionando, nuestra aplicación protegida con certificados de cliente y la opción para revocar certificados.

Comprobando los certificados con PHP

Queremos ir un poco más allá. Queremos que, desde nuestra aplicación, podamos leer el certificado SSL del cliente y comprobar quién es. Seguro que a ti se te ocurren mejores cosas que hacer con estos datos 😉 . Lo primero que tendremos que hacer será configurar Apache para que pase los datos del certificado. En la configuración de tu virtual host añades:

<Files ~ ".(cgi|shtml|phtml|php?)$">
 SSLOptions +StdEnvVars +ExportCertData
</Files>

Ya está. Si ahora haces un print_r($_SERVER) en la aplicación donde tienes instalado tu certificado SSL de cliente verás entre todos los datos algo como:

[SSL_CLIENT_S_DN] => /C=ES/ST=Valencia/L=Valencia/O=Osusnet/CN=blog.osusnet.com/emailAddress=osusENosusnet.com
[SSL_CLIENT_S_DN_C] => ES
[SSL_CLIENT_S_DN_ST] => Valencia
[SSL_CLIENT_S_DN_L] => Valencia
[SSL_CLIENT_S_DN_O] => Osusnet
[SSL_CLIENT_S_DN_CN] => blog.osusnet.com
[SSL_CLIENT_S_DN_Email] => osusENosusnet.com

Tienes toda la información que necesitas, son los datos que se solicitaban al crear la solicitud de certificado. Generando estos parámetros de manera adecuada podrás saber quién entra a tu aplicación a partir del certificado cliente que usa.

Eso es todo por hoy. De una manera muy sencilla hemos añadido un poco más de seguridad a una aplicación web de acceso privado y con un número de usuarios acotado. También hemos aprendido y poco más sobre certificados SSL y hemos visto cómo firmar nuestros propios certificados, igual de fiables que los comerciales. Espero que os sirva de algo 😛 .

Haciendo streaming de vídeos a móviles

Antes de comenzar este artículo, y para que nadie se haga ilusiones, aclararé que no es posible hacer streaming por tu cuenta a través de las conexiones de datos de las operadoras tradicionales. Tienen esos puertos bloqueados para que sólo ellas o quien ellas quieran pueda ofrecer este servicio, de ahí la exclusividad de los canales de televisión en el móvil que tanto promocionan y que no son más que servicios de streaming. Si cualquiera pudiese hacerlo se les terminaría el chollo, aunque siempre queda el asunto del tráfico de datos, a ti te lo cobrarían íntegramente mientras que en sus canales no, ya pagas la suscripción mensual.

No lo he probado con las nuevas operadoras virtuales ni con Yoigo, aunque es posible que con éstas sí que funcione. De todos modos, con la proliferación de terminales con wifi se abre un nuevo mundo de posibilidades sin límite, entre ellos el streaming.

En esta ocasión utilizaremos un servidor Linux (Centos5.2) y como servidor de streaming, Darwin Stream Server.

Darwin es la versión Open Source del QuickTime Streaming Server de Apple, sí, habéis oído bien, Apple, la del iPod y la del iPhone, y permite enviar streamings a través de los protocolos estandar RTP y RTSP. Pero lo que hace más interesante a Darwin sobre otros servidores de streaming es que maneja perfectamente archivos MPEG4 y 3gpp, algo imprescindible si queremos enviarlos a dispositivos móviles

Puedes descargar aquí el archivo de instalación para Linux. Una vez lo descomprimes, la instalación es extramadamente sencilla, sólo debes ejecutar el archivo Install y un asistente te guiará. Cuando haya terminado tendrás tu servidor de streaming funcionando. Vamos a probarlo

La instalación deja todos los archivos de configuración en /etc/streaming y algunos vídeos de ejemplo en /usr/local/movies, ruta por defecto para los archivos. Puedes modificar esta ruta en el archivo /etc/streaming/streamingserver.xml buscando el parámetro de nombre «movie_folder». Lo dejaremos como viene por defecto.

Si no has iniciado todavía tu servidor, hazlo con el siguiente comando:

/usr/bin/perl /usr/local/sbin/streamingadminserver.pl

Si todo ha ido bien puedes probar los vídeos de ejemplo. Abre tu Quicktime Player y abre la url:

rtsp://tuip/sample_h264_300kbit.mp4

Si has seguido bien los pasos verás un vídeo de muestra de QuickTime. Tu servidor de streaming ya está funcionando.

Prueba ahora alguno de tus vídeos 3gpp. Copialos a la ruta correspondiente de tu servidor, /usr/local/movies y llámalos con la url anterior cambiando el nombre del archivo:

rtsp://tuip/nombre.3gp

Deberías ver tu vídeo en el Quicktime Player. Prueba ahora desde tu móvil. Abre el Real Player (o el software que traiga para visualizar vídeos por streaming) e introduce esa dirección.

Cierto, no funciona 😛 . No podía ser tan simple 🙂 …

Preparando los archivos para visualizar en el móvil

Para visualizar los vídeos 3gpp y mp4 en el móvil a través de Darwin han de someterse a un proceso denominado hint.

Necesitaremos una nueva herramienta que haga este proceso, en este caso será el paquete gpac. Descargamos e instalamos el software y tendremos el programa que necesitamos, MP4Box. Ahora simplemente debemos ejecutar la siguiente instrucción en todos nuestros vídeos:

/usr/local/bin/MP4Box -3gp -mtu 1450 -hint video.3gpp

Ya está. Si vuelves a intentar ver el vídeo en tu móvil comprobarás como ahora sí que se visualiza.

Creando gráficas del servidor Darwin en Cacti

Hace algunos meses os conté como monitorizar tu servidor con Cacti. Vamos pues a añadir gráficas de nuestro servidor de streaming para poder monitorizar la actividad del mismo.

Graficas Cacti Darwin Stream Server

Lo primero que debemos hacer será habilitar el acceso remoto desde la IP de nuestro monitor Cacti a la consola de administración del servidor, el «remote admin». Para ello editamos /etc/streaming/streamingserver.xml, localizamos el módulo QTSSAdminModule y en el parámetro IPAccessList introducimos la IP correspondiente, ponemos a false LocalAccessOnlyenable_remote_admin y a true. Habrá que reiniciar el servidor. Quedaría tal que así.

<MODULE NAME="QTSSAdminModule" >
<PREF NAME="IPAccessList" >XXX.XXX.XXX.XXX</PREF>
<PREF NAME="Authenticate" TYPE="Bool16" >true</PREF>
<PREF NAME="LocalAccessOnly" TYPE="Bool16" >false</PREF>
<PREF NAME="RequestTimeIntervalMilli" TYPE="UInt32" >50</PREF>
<PREF NAME="enable_remote_admin" TYPE="Bool16" >true</PREF>
<PREF NAME="AdministratorGroup" >admin</PREF>
</MODULE>

Ya tenemos el servidor de streaming listo, ahora tocaremos en el servidor Cacti. Aquí está todo explicado, pero lo repasaremos. Creo recordar que no me funcionaban tal cual las plantillas, así que os dejo las que tengo en funcionamiento. En el archivo encontrarás dos scripts python y dos plantillas. Los scripts debes copiarlos a la carpeta «scripts» de tu instalación Cacti. Los «templates» debes importarlos desde «Import templates» de la inferfaz web.

Con esto  ya sólo tendremos que añadir las gráficas correspondientes a la máquina que vamos a monitorizar, DSS Current Bandwidth  y DSS – Current Connection Count. Nos solicitará rellenar algunos datos:

  • Servidor: ip de la máquina con el Darwin.
  • Puerto: si no has cambiado nada, el 554.
  • Usuario: usuario de administración del servidor Darwin que hayas configurado al instalarlo.
  • Clave: la contraseña del usuario anterior.

Tendremos dos gráficas, número de conexiones y ancho de banda consumido.

No me hago responsable del gasto  en tráfico de datos con tu operadora que te suponga probar lo expuesto en este artículo 😛 . Otro día veremos como generar vídeos 3gpp bajo demanda a partir de casi cualquier otro formato.

Actualización del cliente IRC online flash, versión 1.0

Hace unos meses anunciábamos el lanzamiento de un cliente IRC realizado en Flash (Flex para ser más exactos) en colaboración con Irc-Hispano. Bien, pues no nos hemos quedado ahí. Durante los últimos meses hemos estado haciendo ajustes y mejoras en la aplicación. Se han solucionado algunos errores que fueron apareciendo y añadido algunas funcionalidades nuevas y llamativas.

El sistema lleva ahora mismo cuatro meses online. En julio hubo 4.500 usuarios únicos diarios de media mientras que en agosto se sobrepasaron los 5.000. Ahora mismo estamos por encima de esa cifra, creo que es un dato más que excelente y más si se compara con los que había antes de su implantación.

Coincidiendo con esta actualización hemos decidido etiquetarla como v.1.0 pues ya es completa, funcional y estable. Hasta ahora estábamos en R.C., hasta tres R.C. pasaron por las manos de los usuarios.

Han sido muchos meses de duro trabajo, no sólo de desarrollo puro y duro, sino además de documentación y planificación. EL RFC del protocolo del IRC ha sido nuestra principal compañía durante mucho tiempo.

Irc Online con fotos

Pero sin duda lo más revolucionario que se ha hecho es permitir a los usuarios poner fotos instantáneas al más puro estilo Messenger. Desde ahora los usuarios ya no tienen que salir del IRC para mostrarse fotos entre ellos. Las fotos, para respetar la intimidad y privacidad de los usuarios, son independientes entre distintas conversaciones, puedes mostrar tu foto a un usuario y no a los demás e incluso tener cada usuario con una foto distinta. Nunca entendimos que a nadie se le haya ocurrido antes permitir a los usuarios verse, a fin de cuentas todos sabemos que es la finalidad de un chat. ¿Qué será lo siguiente? ¿Quizás vídeo? 😉 .

El único inconveniente que tiene el sistema de fotos online es que, por el momento,  solamente lo pueden utilizar aquellos usuarios del webchat y, aunque cada día son más, no cabe duda que el grueso de la gente que chatea utiliza software especializado como mirc y el IRcap.

¿Alguien se atreve con un plugin para mirc para las fotos instantáneas?

[ERROR] /usr/libexec/mysqld: Incorrect key file for table

O cómo cargarte un servidor de bases de datos por tocar un parámetro de configuracion 😛 .

Hace un par de semanas tuvimos una incidencia con el MySQL de uno de nuestros servidores. Algunas tablas comenzaron a devolver errores extraños referentes a /tmp y al archivo de índices de algunas tablas. Lo siento, no tengo el mensaje concreto. El caso es que la base de datos estaba inutilizada. Tras investigar un poco por Google comencé a probar algunos cambios de parametrización en /etc/my.cnf. Me pareció muy extraño puesto que la configuración que utilizamos lleva muchos años dando buen resultado, de hecho no es ni por asomo hoy por hoy el momento de mayor actividad que hemos tenido.

Tras hacer un poco el tonto caí en la cuenta, ríanse de mi, de que la máquina se había quedado sin espacio en disco 😛 . Era esto lo que provocaba que no se pudieran regenerar los índices de las tablas y demás errores asociados.

Una vez solucionado el error todo comenzó a funcionar con normalidad y parecía que todo iba bien. Craso error.

Hace unos días nos dimos cuenta que el log de MySQL se estaba llenando de mensajes de error como éste sin aparente explicación:

080902  0:51:42 [ERROR] /usr/libexec/mysqld: Incorrect key file for table ‘./basededatos/tabla.MYI’; try to repair it

Lanzando un repair table tabla se solucionaba el error, pero era algo temporal, pronto volvía a aparecer, sino era con esa tabla era con otras. Incluso tablas de bases de datos sin apenas uso.

Googleando de nuevo, el primer resultado me dió la clave. , era uno de los parámetros que había modificado el día que me había quedado sin espacio en disco y no lo había restaurado.

key_cache_block_size=1024

Había leído que aumentando este parámetro se solucionaría el error, así que ni corto ni perezoso lo puse a 10024 y así se quedó aunque el problema no se solucionó 😛 .

Al parecer este parámetro debe tener un valor que sea potencia 2 de 512, sino aparecerán los errores aleatorios en los archivos de índices que nos estaban ocurriendo a nosotros.

Restauramos el valor a 1024, reiniciamos el servidor de bases de datos y, por arte de magia, los problemas desaparecieron.

Como conclusión sacamos que el parámetro más absurdo puede hacernos perder días de investigación y problemas, en mi caso a las cuatro de la madrugada 😛 . Esta vez tuvimos suerte. Para la próxima, pensaré en apuntar cada cambio que haga, por si acaso…

Regala lotería y personaliza tus participaciones y décimos

¿Regalas lotería de Navidad?
¿Cansado de no saber cómo ser original a la hora de enviar el número?

Coincidiendo con las semanas previas al Sorteo Extraordinario de Navidad del año pasado lanzamos TusDecimos.com, algo tarde pero a tiempo para que se enviasen varios miles de décimos personalizados.

Después de numerosas peticiones hoy mismo hemos cambiado el diseño del décimo por el de este año, con lo que ya puedes enviar tus participaciones a tus amigos y familiares. Ya se sabe que en vacaciones se suele comprar lotería y la gente está ansiosa por regalarla. Los décimos generados puedes descargarlos, enviarlos por email o incluso al móvil del destinatario, con lo que lo tendrá bien guardado y no lo perderá, además de resultar un modo muy original de enviar el número.

TusDecimos.com

La idea surgió ni más ni menos que porque todos los años teníamos el mismo problema que la mayoría al regalar lotería, ¿cómo hacerlo distinto?. Te tocaba escanear el décimo, retocarlo a mano modificando la cantidad que regalabas… Ahora todo es mucho más sencillo.

Detalles técnicos

Ya que esto es un blog de corte técnico (aunque también publique de vez en cuando temas personales :P ), explicaré como hicimos el generador de décimos automático.

Lo principal, obviamente, es comprar un décimo :P y escanearlo, mejor a 300ppp puesto que así lo tenemos a muy buena resolución. Después debes retocarlo un poco, ajustar bien los bordes y, sobre todo, eliminar las rayas cruzadas que aparecen en la zona de los números. Nosotros vamos recortando porciones del dibujo de fondo y pegándolas sobre los números hasta que todo el dibujo queda limpio. Hay que repetir el mismo paso en las zonas de la derecha de fracción, seríe y precio del décimo. Así tendremos un billete limpio para personalizar a nuestro gusto.

 Decimo de loteria de navidad personalizado

Ahora debes obtener, a través de tu programa de dibujo como Gimp, las coordenadas que vas a necesitar:

  • Posición izquierda superior del cuadro imaginario donde iría el número del décimo.
  • Posición izquierda superior del cuadro imaginario donde iría la serie.
  • Ancho máximo del cuadro imaginario donde va la serie.
  • Posición izquierda superior del cuadro imaginario donde iría la fracción.
  • Ancho máximo del cuadro imaginario donde va la fracción.
  • Posición izquierda superior del cuadro imaginario donde iría la cantidad que regalas.
  • Ancho máximo del cuadro imaginario donde va la  cantidad que regalas.

A la hora de generar los números valoramos distintos modos de hacerlo, pero el resultado nunca era del todo satisfactorio. Lo primero en lo que piensas es en utilizar las librerías GD para insertar el texto del número, pero si lo pruebas verás que el resultado es muy pobre además de muy complicado de ajustar al espacio que ocupan, principalmente porque no tienes la fuente original que utiliza el Organismo de Loterías y Apuestas del Estado.

Finalmente optamos por un modo algo más artesano. Se hicieron los 10 dígitos básicos a mano, de manera que se ajusta perfectamente el tamaño de cada dígito y puedes hacer unos números bastante parecidos a los originales.  La serie, fracción y cantidad que juegas se hacen con una fuente normal con la función imagettftext, simplemente escoge la que más te guste. Para centrar el texto en la zona donde va utiliza la función imagettfbbox, te devolverá el tamaño del texto al pintarlo en el décimo, simplemente desplaza la posición de inicio la mitad del espacio sobrante. Nuestro script es un poco más elabordado puesto que juega, además, con el tamaño de la fuente de manera que se ajuste siempre perfectamente al espacio disponible. En líneas generales seria algo como:

$size=73;//tamaño de la fuente
$fuente="tufuente.ttf"; //fuente para los numeros de serie y fraccion
$serie="3"; //serie que vas a ponerle
$anchoespacio=135; //tamaño maximo del cuadro imaginario del espacio para la serie
$xinicio=1060; //posicion izquierda del cuadro imaginario de la serie
$yinicio=235; //posicion superior del cuadro imaginario de la serie
$bbox = imagettfbbox($size, 0, $fuente, $serie."ª");
$tw = ($anchoespacio-($bbox[2] - $bbox[0]))/2;
imagettftext($src_img, $size, 0, $xinicio+$tw, $yinicio, $tc, $fuente, $serie."ª");

Esto lo repetiríamos para serie, fracción y cantidad.

Para los dígitos del décimo, mucho más simple.

$decimo="23456";
$len=strlen($decimo);
$numero=array();
for($i=0; $i<$len; $i++)
    $numero[]=$decimo[$i];

for($i=0; $i<count($numero); $i++){
    $number = imagecreatefromgif ("numeros/".$numero[$i].".gif");
    imagecopymerge($src_img, $number, 450+($i*110), 105, 0, 0, 110, 133, 100);
}

Vamos copiando cada dígito sobre la posición del décimo donde iría. Sencillo. Ya tienes tu décimo personalizado. Si quieres puedes escalarlo o hacer lo que prefieras con él.

Con esto y teniendo cuidado de que los décimos te coincidan cada año en el mismo punto al escanearlos, tienes la aplicación resuelta para siempre.

Recuerda, si vas a regalar lotería, hazlo desde TusDecimos.com.

¿Programando a los 50? No, por favor

Los que me conocen saben que uno de mis blogs habituales es Navegapolis, de Juan Palacio. Es un tío muy coherente y con mucha experiencia en el ámbito de la gestión de proyectos de software, pero lo mejor de todo es que habla desde el punto de vista de un técnico, no de un «director de», y de los problemas que se encuentran los desarrolladores por culpa de la mala gestión de los equipos. Este artículo hace referencias a algunos de sus posts de los últimos meses:

Como referencia a uno de ellos, muy interesante también Circuitos de pérdida de talento, por José Medina.

El viernes pasado, cenando con un alto cargo de RRHH de una multinacional, surgió el tema de los equipos y las selecciones de personal en IT.  Esta persona, antes de su actual puesto, desempeñó puestos similares en consultoras y telecos, con lo que algo sabe del tema. Me sorprendieron, sin embargo, algunas de sus opiniones. Este artículo es la mía.

Desde mi punto de vista y basándome en mi experiencia, un equipo de desarrollo es más que un grupo de gente. Salvo excepciones, son personas con una elevada formación y muy especializada, acostumbradas a pensar, a crear, a diseñar, a las que les apasiona su trabajo, construir, hacer cosas que otros van a utilizar. Esto no se puede entender de otro modo, nadie en su sano juicio se metería en este sector si no le gustase, los salarios son ridículos y el trabajo estresante.

Para entender la mentalidad de un desarrollador debemos comenzar por entender la estructura de un equipo de desarrollo.

Los últimos de la cadena son ellos, los programadores, los que construyen el trabajo, los que afrontan los problemas, los buscan, los solucionan, los preveen, cumplen los plazos… y sólo son los últimos eslabones de la cadena. A continuación tendríamos al responsable del equipo, la pieza clave, el encargado de motivarlos, de valorarlos, de mimarlos. Es el Luis Aragonés de un equipo de desarrollo. Un buen responsable debería preocuparse por la situación personal de su gente,  si tienen problemas (hipotecas, parejas, divorcios, niños…) no rendirán como se espera de ellos. La solución no es pegarles el puro y que se espabilen, es la solución fácil pero la menos buena. Si una persona tiene problemas no necesita que tu le crees más. Es una persona, no un recurso, cuanto antes lo entiendas antes conseguirás formar un equipo.

Encima del equipo y su responsable están toda una maraña de jefecillos y directores de, en general preocupados exclusivamente por su culo y su nómina a final de mes. Gente que hace años pudo ser programador pero se dió cuenta que no tenian un buen futuro y ahora son jefes. Gente para la que su trabajo es cumplir ocho horas e irse a sus casas. No les gusta especialmente su trabajo ni sienten pasión por él, es necesario para llegar a final de mes y punto.

Finalmente están los departamentos comerciales, los encargados de preguntarte plazos y recortarlos a su antojo. Los encargados de decir que sí a todo lo que los clientes solicitan, independientemente de que sea o no viable, ya habrá algún programador que lo solucione, y si no, a trabajar 12 horas diarias y fines de semana para cumplir los plazos.

Bajo esta estructura es fácil adivinar que muy pocos programadores (o ninguno) sienten, con 30 años, que quieren seguir siendo programadores a los 50, picacódigos que decimos. Todos aspiramos a ser responsables o, a poder ser, directores de algo y que otros hagan el trabajo. Triste pero cierto. Hay comerciales, gente de marketing, rrhh… con salarios de 50 a 70.000 euros al año pero nunca habrá un programador, ni siquiera un analista, que llegue a esas cifras. ¿Por qué?. Ellos hacen un trabajo imprescindible, fabrican, piensan, se echan a la espalda un duro trabajo. Un trabajo para el que, en muchos casos, se han pasado años y años en la facultad estudiando, soportando asignaturas y profesores duros (¿ingenierías vs. ADE, derecho, psicología…?). ¿Todo para qué? ¿Para empezar con 800 euros al mes y con suerte, en un par de años, llegar a los 1.000?

Esta persona con la que hablaba me comentaba que, para ella, un equipo eran un par de buenos programadores y el resto picacódigos. Imagino que la estructura que pasaba por su cabeza hablaba más de analistas que de programadores. Aún así es un grave error pensar así. Es como pensar que un equipo de fútbol son dos galácticos y 9 jugadores de relleno que se encargan de dar balones a las estrellas. Qué queréis que os diga, yo prefiero un equipo bien formado de 11 jugadores donde la integración del conjunto cree una estructura sólida y eficaz, un equipo del que ninguno de sus componenes quiere salir pero tampoco necesite destacar, que se sientan valorados y que sientan que participan en algo importante. Alguien diría, claro, ese es el trabajo del responsable del equipo, motivarlo. Y yo le contestaría, entre basura no se puede motivar a nadie. No le puedes hablar de motivación a alguien que cobra 15.000 euros anuales. Su motivación es buscar quien le de 16.500 y cambiar de trabajo. La motivación comienza por el salario y las políticas de mejoras. Si un empleado no puede pagarse un piso, irse de vacaciones unos días o salir a tomar unas copas… ¿cómo vas a motivarle? ¿le vas a contar milongas de que lo que hace es importantísimo? ¿que aquí va a aprender mucho? Yo, sinceramente, me reiría de ti en tu cara.

No vas a ganar la Eurocopa si no tienes equipo. No necesitas a los mejores, pero sí a unos cuantos válidos, compenetrados y motivados. Empieza por un sueldo decente. Trátalos como si fuesen personas, no como animales (de hecho a los animales se les trata muchas veces mejor que a los empleados). Preocúpate por sus vidas y que se sientan valorados. Esa es la motivación que te toca, que sientan que hacen algo útil y que su opinión cuenta, no son simples machacas, es gente que piensa y le gusta encontrar mejores soluciones. Si consigues una maquinaria bien engrasada y trabajando en equipo, sin competencias internas, sin que nadie busque medallitas, con lealtad, con capacidad para reconocer el error de uno y solucionarlo entre todos, amigo, tu trabajo así será mucho más sencillo y productivo.

Cuando un responsable de equipo consigue formar un buen grupo de gente intentará por todos los medios llevárselo con él allá donde vaya, es su garantía de trabajo y confía plenamente en ese equipo, los valora por encima de todo, sabe que su trabajo, si no tiene debajo un buen equipo, será casi imposible.

Siempre se dice que nadie es indispensable, y es cierto, nadie lo es, pero el hecho de que una persona abandone el equipo y entre una nueva puede llevar a tu equipo al fracaso. Puede desestabilizarlo, crear competencias que no existían por el simple hecho de buscar las conocidas medallitas… ¿En serio vale la pena dejar marchar a un buen trabajador sólo por no negociar con él? ¡Qué fácil es pensar que dónde había ese hay más! De un modo o de otro, tu equipo se resentirá y tu serás el primero en sufrir las consecuencias, tu planificación se irá por la borda y los plazos comenzarán a agobiarte.

Hablemos también de los de más arriba, de los directores de. Sí, esos con tan poca autoestima que en cuanto aparece alguien que intenta hacer bien las cosas hacen todo lo posible para cargárselos creyendo que así salvan su puesto de trabajo cuando en realidad están destruyéndolo lentamente. Como argumenta José Medina:

los números uno se rodean de números uno, y los doses, de treses y cuatros

Sobran más comentarios. Más aún en esta conocida cultura que hace jefes a los que ayer eran machacas, la cultura del peloteo, sí. El machaca convertido en jefe será siempre un número tres o cuatro que intentará que un número uno no se le suba a las barbas.

Un programador es una persona que se tiene que reciclar contínuamente, cada año su trabajo cambia, cambian las tecnologías, los lenguajes, las máquinas… y él está ahí al pié del cañón. ¿Os imagináis la experiencia que debe tener un tío de 50 años que lleve 25 programando? Impresionante. Pero nadie lo va a valorar. No. Más bien al contrario. Pensarán, vaya, menudo paquete tiene que ser este para ser un simple programador a su edad… En efecto, esta es la realidad.

Que nadie olvide que, por mucho director de que haya, no estarías ahora utilizando un ordenador si no existiesen los programadores. Es un trabajo donde te acuestas pensando y te levantas buscando soluciones. Piénsalo la próxima vez que arranques tu ordenador.

Por todo esto, no, a los 50 prefiero ser el responsable de un buen equipo e intentar hacer lo que hoy no nos dejan y que los que vengan detrás crean que ser programador es un buen trabajo, digno, gratificante y que te permitirá jubilarte.

Alguien que conozco me llamará ahora idealista 😉 , que todo esto está muy bien pero la realidad es bien distinta. En efecto, así es, pero a mi también me queda algo de idealismo aún. Esperemos que dure.

Sé que se me han quedado algunas cosas que quería decir en el tintero, pero ya está bien de aburriros, me ha quedado más largo de lo que esperaba. Hasta la próxima 🙂 .

Insertar imágenes en RichTextEditor de Flex

Esta semana, a raíz de un mensaje en la lista de correo de Made in Flex, recordé una de las primeras aplicaciones que hice en Flex hace ya dos años con lo cual me lancé a recuperar aquél código, limpiarlo de cosas supérfluas y publicarlo. Os dejo también el enlace a un post mio en la lista Flexcoders donde explicaba como hacerlo, de hecho ha sido mucha la gente que, a partir de ese post, me ha escrito preguntando detalles.

Para los puristas, os aviso de antemano que puede haber cosas que no funcionen bien, código extraño y mil historias más, es un código que tiene dos años, si hacéis cuentas veréis que justo estos días Flex2 cumple dos años. Sí, lo comencé con las primeras betas de aquella versión. Lo único que he hecho ha sido crearlo en Flex3 y dejar la aplicación limpia para que se vea el funcionamiento. Si me váis a dejar un comentario diciendo que tal o cual cosa no funciona bien, podéis ahorrárosla.

Como una imagen vale más que mil palabras, aquí tienes el ejemplo y el código fuente de todo el proyecto.

Todos a los que en algún momento se nos ocurrió utilizar Flex para crear un gestor de contenidos nos hemos dado con un grave problema en la frente: el componente ideal para escribir y actualizar contenidos, RichTextEditor, NO permite, por defecto, insertar imágenes, con lo cual pierde prácticamente su utilidad. Escarbando en la ayuda, sin embargo, te das cuenta de que entre los tag HTML soportados por el componente Textarea se encuentra <IMG>, con lo que, a priori, nada impediría insertar una imagen. En efecto así es y en eso se basa todo este artículo/proyecto. Un detalle importante es que la utilización de imágenes no está bien conseguida en el propio Flash Player, con lo que si comenzamos a añadir y quitar imágenes llegará un momento en el que todo el Textarea será inestable y hará cosas extrañas.

El proyecto se basa en dos componentes, nuestro editor de texto y un explorador de archivos. Desde el editor tendremos un botón Insertar imagen que abrirá un explorador al más puro estilo del escritorio del sistema operativo donde nos mostrará los archivos que tenemos en el servidor, pudiendo subir y eliminar. La lógica del explorador con el servidor la he eliminado al máximo, dejando sólamente unos XML estáticos que listan las carpetas e imágenes disponibles. Para hacerlo bien haríais un script con salida similar a esta pero que liste lo que en realidad hubiese en una ruta de tu servidor.

Nuestro editor de texto

Intentaré explicar como hice todo el proceso, pero fue hace bastante tiempo así que es posible que se me olvide algún detalle.

La idea era hacer un editor avanzado, con las caracteristicas que le faltaban al RichTextEditor original:

  • Insertar imágenes.
  • Posibilidad de añadir datos tabulados (que no tablas como tales).
  • Cambiar el color de fondo del editor para, por ejemplo, crear texto en color blanco.
  • Eliminar todo el texto (e imágenes).
  • Editor avanzado de links.
  • Botón guardar texto (lo insertaría en tu base de datos)

Partimos para ello de un RichTextEditor al que le quitamos el botón predefinido de Añadir link y añadimos nuestros nuevos botones. Siguiendo el código entenderás lo que hacen, por lo que nos centraremos en el de imágenes que es el objeto del artículo. Primero os explico en qué consiste el botón de tabular datos. Es muy sencillo. Si quisiésemos, en el RichTextEditor, crear una tabla de valores con el tabulador, no podríamos, ya que al presionar tabulador saldría el foco del Textarea de escribir  y se iría, por defecto, al selector de fuente. Para solucionarlo añadimos un botón que lo único que hace es añadir un carácter de tabulación (t) en el texto, con lo que comprobaréis que ya puedes tabular datos perfectamente. Muy útil el truco.

Pasemos pues al botón de insertar imágenes. El botón, tal y como expliqué anteriormente, abre el popup del explorador de archivos, con lo que esta parte la veremos en la siguiente sección. Cuando en el explorador seleccionamos la imagen a insertar se devuelve el control al editor y es éste el que añade la imagen. Para añadir la imagen inserta en la posición del cursor el tag <IMG> con los parámetros necesarios. Aparentemente no tiene más truco, pero al empezar a probar cosas nos damos cuenta que sí que lo tiene.

Para empezar, si guardamos el htmltext de este RichTextEditor en la base de datos y posteriormente intentamos recuperarlo recibiremos un desagradable error de validación XML. Quiero aclarar antes de nada, que este error me ocurría en aquél entonces, quizás, ojalá, las ultimas versiones de Flex lo hayan solucionado, te ahorraría muchos problemas. La causa del error de validación era que internamente, aunque tu añadieses un tag <img … /> (o <img…></img>) válido, el editor te devolvía siempre <img .. > , es decir, el XML sin cerrar, con lo cual al cargarlo de nuevo saltaba error de validación. Para solucionar este problema creamos un método desProcesaTexto que lo que hace es convertir todos los tags <img..> no válidos a tag válidos, con lo que tenemos el primer problema resuelto. Utilizando expresiones regulares será extremadamente sencillo.

var pattern:RegExp = /<IMG([^>]*)>/gi;
texto=texto.replace(pattern, "<IMG $1 ></IMG>");

Segundo problema. Una vez insertamos una imagen, ¿cómo podemos quitarla o modificarla? Aquí viene parte del truco. La idea, básicamente, es añadir a cada imagen un link de manera que al hacer click en ella se nos abra un popup que nos permita eliminar la imagen o modificar sus atributos. Esto genera otro inconveniente. Cuando queremos recuperar el contenido del Textarea para guardarlo en la base de datos debemos eliminar estos links falsos añadidos para la interfaz de usuario, pero que no queremos que salgan cuando se muestre el texto. Por contra, cuando cargamos un texto desde la base de datos debemos procesar los atributos de imágenes para añadirles este link y podamos operar con ellos.

var temp:XML=XML("<texto>"+texto+"</texto>");
var allTags: XMLList;
var item:XML;
var tempitem:XML;allTags= temp..IMG;
for each(item in allTags) {
    var xlcParent:XMLListCollection = new XMLListCollection(item.parent().parent().children());
    tempitem=XML(xlcParent.toXMLString());
    xlcParent.setItemAt(item, 0);
}

Como se aprecia en el código, bucamos todos los tags <IMG> y, asumiendo que todos tendrán un tag <A> anterior, reemplazamos el nodo <A> completo por el <IMG> y todo solucionado, más sencillo de lo que parece una vez se entiende el procedimiento.

Para contemplar estas peculiaridades cada vez que asignamos el texto al componente o cada vez que lo recuperamos, tenemos los siguientes métodos:

public function getHtmlText():String{
    return desProcesaTexto(this.htmlText);
}

public function setHtmlText(texto:String):void{
    this.htmlText=procesaTexto(texto);
}

No hay mucho más que explicar. Como peculiaridad, veremos como procesaríamos los tags <IMG> cuando cargamos un texto nuevo en el componente. La idea, básicamente, es añadir el link que nos permita modificarla, pero este link necesita conocer los datos de la imagen (src, width, height..).

allTags= temp..IMG;
for each(item in allTags) {
    var xlcParent:XMLListCollection = new XMLListCollection(item.parent().children());
    var iIndex:int = xlcParent.getItemIndex(item);    idlink=Math.round((Math.random()*100000)*(Math.random()*100000));
    nuevoNodo="<A href="event:IMAGEN##||##"+item.@ID+"##||##"+item.@SRC+"##||##"+item.@WIDTH +
    "##||##"+item.@HEIGHT+"##||##"+item.@VSPACE+"##||##"+item.@HSPACE+"##||##"+item.@ALIGN +
    "##||##"+idlink.toString()+"" ID=""+idlink.toString()+"">"+xlcParent.toXMLString()+"</A>";

    xlcParent.setItemAt(XML(nuevoNodo), iIndex);
}

Sencillo.

El explorador de archivos

El explorador de archivos es un componente bastante resultón que, si lo trabajas un poco, te puede solucionar muchas tareas. Igual que el Explorador de Archivos de Windows, tienes a la izquierda un árbol de directorios y a la derecha los archivos de la carpeta seleccionada y sus detalles. Arriba tenemos botones para subir archivos nuevos y crear nuevas carpetas (la lógica de estos botones es cosa tuya) y, sobre todo, un combo para cambiar el modo de ver los archivos de manera que puedes ver la lista de los mismos o las miniaturas. Si, si listas imágenes verás un thumbnail de las mismas, perfecto para nuestro editor. No voy a enrollarme mucho más con el funcionamiento ya que en el código fuente tienes todo lo necesario. El evento interesante es el doble click sobre un archivo, que devuelve el control a una nueva ventana donde puede configurar los parametros de la imagen a insertar. Con el ejemplo lo entenderas.

En tu editor deberás crear los métodos adecuados en el servidor para listar las carpetas y archivos de tu directorio de uploads si quieres que todo sea dinámico y el usuario pueda organizarse por su cuenta los archivos.

Tal como había comentado, no he sido tan explícito como en otras ocasiones. Si tienes algún problema no dudéis en dejar un comentario e intentaré solucionarlo a la mayor brevedad posible.

Aquí tienes el ejemplo y el código fuente de todo el proyecto.

Sobre incendios, CPD’s y otros desastres naturales

Supongo que a estas alturas ya la mayoría os habréis enterado del incendio ocurrido en uno de los CPD’s (centro de proceso de datos) que The Planet tiene en Houston, Texas. Al parecer la causa del incendio fué la explosión de uno de los transformadores que dan servicio al CPD. Debido al incendio se tuvo que cortar completamente sl suministro eléctrico del centro provocando con ello el apagado de unos 9.000 servidores, entre ellos los DNS principales de la antigua EV1, había servicio de respaldo pero los bomberos obligaron al corte completo como medida de seguridad. Creo que han tardado algo más de 24h en restaurar completamente el servicio, desde el foro se pudo seguir la evolución de la incidencia.

El CPD en cuestión era uno de los que EV1 Servers tenía cuando fue adquirida por The Planet hace un par de años y el más antiguo de la compañía.

Pues bien, nosotros tenemos servidores en The Planet desde 2002, de hecho teníamos servidores en ese CPD de EV1 hasta agosto del año pasado cuando, gracias a unas buenas ofertas, los migramos a nuevas máquinas y con ello cambiamos de centro de datos, ahora estamos en Dallas, sino ahora mismo seríamos uno de los afectados.

He leído mucho estos días acerca de lo ocurrido. He llegado a leer si realmente vale la pena llevarte la infraestructura a USA cuando puede ocurrir esto que ha ocurrido. Y yo me pregunto, ¿acaso esto no podría ocurrir en España? Esto y mucho más 😉 , los problemas son independientes del lugar, si no es un transformador el que explota es una regleta que se quema, una fuente estropeada o un router colgado. También podría ser otra máquina con la que compartes RACK y/o router que ha sido atacada o mil historias más, ¿verdad Raúl?, pero problemas los hay en todas partes. ¿Acaso por tener tus máquinas en un CPD de Logroño estando tú en Valencia vas a resolver algo que no podrías resolver si están en USA? La respuesta es obvia a no ser que tengas enchufe y te vayan a tratar antes y mejor por ser tú, cosa poco probable para la mayoría. Lo que debes pensar es en tener gente detrás que vaya a solucionarte los problemas que tengas y que no puedas solucionar tú.

Nuestra experiencia, tanto en EV1 primero como en The Planet después, es inmejorable. Rápida respuesta a los pocos problemas que nos han dado, avisos con semanas de antelación de ventanas de actuaciones, soporte rápido y eficaz, etc. Cuando hemos tenido algún problema más grave han hecho las cosas con profesionalidad y siempre preguntando primero, reinicios manuales, fsck’s controlados, cambios de cables de discos defectuosos que estaban provocando problemas, etc. En una ocasión incluso se hizo el cambio de un disco defectuoso con dos parones de unos 5 minutos cada uno, el disco no había dejado de funcionar, simplemente lanzaba errores esporádicos de lectura/escritura. En una parada añadieron un disco duro para que lo preparásemos todo y en la siguiente reemplazaron el original por la copia. Todo funcionó a la perfección y en 24h se cambió un discon sin afectar al servicio. Reconozco que también puede ser que hayamos tenido algo de suerte 🙂 .

Profundizando un poco más en el asunto, el incendio de The Planet es sólo uno de los problemas que pueden ocurrir y ante los que apenas hay opciones de protección. Recordemos casos como el del Edificio Windsor de Madrid donde había ni más ni menos que un CPD de Colt Telecom, o las inundaciones en Louisiana tras el Katrina donde todo quedó arrasado y devastado. Nadie ni nada puede asegurar que sus servidores estarán seguros 100% y que nunca ocurrirá nada. Por contra, tú si que puedes asegurar que estarás protegido ante estas situaciones y así poder minimizar los efectos. En función del presupuesto de que dispongas podrás estar mejor o peor preparado, pero lo básico es muy barato y sencillo.

Si tu presupuesto lo permite, lo mejor es, sin duda, tener siempre un CPD de respaldo con toda tu infraestructura de producción duplicada, actualizada y preparada para entrar en producción cuando la principal se venga abajo. Obviamente esto es un gasto que casi nadie va a ser capaz de justificar ante sus superiores.

Si, como la mayoría, no puedes permitirte un CPD de respaldo, mantén una buena política de copias de seguridad y un plan de contingencia bien documentado y actualizado. Si lo haces bien, en apenas unas horas podrás tener levantado desde cero una máquina que haya fallado. NO, repito, NO confíes en los RAID1 (espejo) y ve con cautela con los RAID5, he visto muchos servidores completamente perdidos por culpa de la controladora RAID. ¿De qué sirve tener un RAID1 bien chulo si al petar la controladora se van los dos discos a paseo? A la hora de hacer tus backups ten en cuenta que no sólo necesitas los datos propiamente dichos, sé previsor y guarda todos los archivos de configuración y scripts que te has ido haciendo con los años y que sigues utilizando. Documenta en el plan de contingencia cada detalle que estimes oportuno para restaurar el servicio. Apunta cada cambio que haces en la configuración de cada servicio. ¿De qué te va a servir tener todos tus datos si no has guardado la configuración de Apache y ahora tienes que crear uno a uno todos los Virtual Hosts?

Finalmente, aunque parece evidente, llegado el momento muchos se olvidan. Distribuye tus copias de seguridad. NO tengas el backup en el mismo CPD y mucho menos en la misma máquina. A ser posible almacena los backups en varios sitios. A mi me gusta hacerlo en otro CPD bien alejado del de producción y en tus oficinas.

Como último consejo, pon en marcha el plan de contingencia al menos una vez al año. Coge una máquina limpia, tu plan de contingencia y mide el tiempo que tardas en tenerlo todo online y revisa los problemas que te van surgiendo. Alimenta con esta experiencia tu plan de contingencia para hacer frente a posibles imprevistos llegado el momento.

Eso es todo amigos, ojalá nunca tengáis que poner en práctica el plan de contingencia 😛 .