Archivo de la categoría: General

Fin de semana en Alcoceber, Peñíscola y el Castillo de Xivert

Hace unas semanas aprovechamos un fin de semana para acercarnos a Alcoceber (Alcossebre en valenciano), en la costa castellonense para, desde allí, hacer algunas excursioncitas. Había estado por esa zona allá por el año 2000 o 2001 y guardaba un grato recuerdo de ella, mucho menos saturada que la mayoría de la costa mediterránea, y no me defraudó.

Alcoceber es un encantador pueblo costero víctima del turismo como la mayoría de la costa, aunque en menor medida que los demás. Se aprecia el desarrollo urbanístico pero bastante comedido para lo que se suele ver por aquí.

La mañana del sábado la pasamos paseando por la costa y por el pueblo, hacía un día bastante insípido, nublado por momentos y soleado en otros, pero la playa estaba sencillamente preciosa con el mar un poco picado.

Alcoceber

Alcoceber

Alcoceber

Alcoceber

Al atardecer dedicimos acercarnos a cenar a la vecina localidad de Peñíscola (apenas 30km) pero la lluvia deslució nuestra velada. Me encanta este sitio (fuera de la temporada estival, claro). Estuve hace 4 ó 5 años visitando el castillo y me pareció fantástico en aquel momento. Esta vez no pudimos entrar ya que se había hecho muy tarde y estaba cerrado 🙁 , pero aprovechamos para pasear por el casco antiguo del pueblo, tomar unas cañas, y, como no, hacer algunas fotos de las dos bahías, ya que Peñíscola es casi una isla amurallada (bueno, una península 😛 ).

Peñíscola

Me encanta como me quedaron estas fotos de noche, con paciencia, y eso que estaba lloviendo y tenía que sujetar el paraguas 😛 . Fijáos en la apariencia de manto que tienen las aguas.

El casco antiguo se presenta imponente de noche, con sus estrechas, empedradas  y empinadas callejuelas, todas bien  iluminadas para realzar el conjunto amurallado.

Peñíscola

PeñíscolaPeñíscolaPeñíscola

El castillo se conoce como del Papa Luna por  Benedicto XIII, nombrado Papa en 1394 a la muerte de Clemente VII. Francia se opuso a su nombramiento pese a haber sido elegido por 20 de 21 votos ya que no podrían influenciar en él, además de que era súbdito de la Corona de Aragón, llegándose al Cisma de Occidente, donde llegó a haber tres Papas simultáneamente y que terminó con el Concilio de Constanza, dónde fueron depuestos los tres y elegido Martin V, que llegó incluso a intentar el envenenamiento del Papa Luna. Benedicto XIII siempre defendió su papado al ser nombrado cardenal antes del Cisma, pero finalmente las decisiones conciliares fueron superiores a sus ideas.

A su muerte se eligió en el mismo Castillo de Peñíscola a Clemente VIII, que terminaría abdicando por cuestiones políticas en favor de Martin V en San Mateu, cerquita de  Morella.

La historia del Papa Luna está repleta de hechos e historias milagrosas. Una de las más conocidas es la que asegura que con su manto y su báculo podía ir caminando sobre las aguas del Mediterráneo desde su castillo hasta Roma. ¿Teletransportación medieval? 😛

Peñíscola

PeñíscolaPeñíscola

PeñíscolaPeñíscola

La lluvia nos aguó la fiesta en Peñíscola, así que decidimos regresar a Alcoceber a la hora de cenar y acostarnos pronto para aprovechar la mañana del domingo (si el tiempo lo permitía).

De regreso a nuestro punto de partida buscamos dónde cenar y nos llamó la atención algo parecido a un asador vasco, en la zona de bares y restaurantes del puerto deportivo de Alcoceber, en la parte interior, el primero subiendo desde el sur. Lo siento, no recuerdo el nombre. Restaurante Asador Guetaria.

La cena fue increíble, en el segundo plato entenderéis porque. Ya sé que algunos echábais ya de menos fotos de comida en mis artículos 😛 .

Pedimos de primero revuelto de gulas con gambas. Para mi exquisito, mi acompañante no pudo disfrutar de este plato ya que no le gusta nada que lleve o huela a cebolla… más me toca 🙂 .

img_4345.JPG

Aquí viene lo verdaderamente importante de la cena. Con la emoción me olvidé de la foto de rigor, así que la tuve que hacer después de acabarlo, aún así creo que se aprecia perfectamente la magnitud del chuletón de buey que nos metimos entre pecho y espalda. Nada más y nada menos que 1,4kg de uno de los mejores chuletones que he comido en mi vida, bien servido en una bandeja que mantiene el calor, si no a mitad de chuletón estaría ya congelado. Y es que por mucho que presuma de que me encantan los pescados y los arroces, soy carnívoro por naturalez, aquí ha quedado demostrado.

img_4346.JPG

Después de semejante cena no pudimos más que acostarnos y dormir, aunque eso es un decir. Tremendo temporal que hizo ese día por la noche, parecía que el hotel iba a salir volando. Cual sería nuestra sorpresa, sin embargo, cuando al levantarnos el domingo nos topamos con un bonito día soleado, o lo más parecido a eso que se podía tener en aquellas condiciones.

El temporal había dejado la playa totalmente encharcada, las olas debieron de ser gigantestas, pero ahora el mar se presentaba antes nosotros en toda la brabura que puede dar el Mediterráneo.

Alcoceber

Alcoceber

Después de desayunar y dar un paseíto por la playa nos acercamos hacia otro de mis destinos pendientes (siempre digo lo mismo, ¿no?), el Castillo de Xivert.

Tomando la carretera nacional en dirección a Peñíscola y justo tras dejar a mano izquierda una gasolinera y a mano derecha el desvío a Alcalá de Xivert, se encuentra un pequeño y mal señalizado (y recalco lo de pequeño) desvío a mano derecha que conduce al castillo. Tras unos minutos de pista asfaltada donde comenzamos a divisar el edificio, habrá que tomar una pista de tierra a mano izquierda. Me habían avisado que la pista sería intransitable con un turismo, pero nada más lejos de la realidad, aún a pesar de la tormenta de la noche anterior, la pista estaba perfecta para el coche. Tras unos 7km de pista llegamos a una especie de merendero, ahí dejamos el coche y seguimos las indicaciones que, tras 100 ó 200m de sendero a pie por el bosque, nos deja a los pies del castillo.

Castillo de Xibert

Castillo de Xibert

En plena Sierra de Irta se alza monumental este castillo de origen árabe reconquistado por Jaime I en 1234 (tras tomar precisamente Peñíscola) y entregado a la Orden del Temple. Las dos gigantescas torres circulares unidas entre sí que le dan la majestuosidad que tiene, fueron obra de los Templarios. Dicen que es uno de los más bellos y completos de toda la Comunidad Valenciana. Doy fé, me pareció increíble, sin restaurar apenas se mantiene imponente. Ahora mismo están realizando tareas de restauración, lástima, por lo poco que he visto creo que no me va a gustar lo que van a hacer…

Castillo de Xibert

Castillo de XibertCastillo de XibertCastillo de XibertCastillo de XibertCastillo de Xibert

En los alrrededores del castillo se encuentra el antiguo poblado, bien señalizado por el sendero del bosque que os comentaba anteriormente. Al llegar verás una gran puerta de hierro, abre el cerrojo, no está cerrado con llave 😛 . Este espacio, rodeado también de murallas, fue el resultado de la ampliación que realizaron los árabes para albergar a la población y al ganado y protegerlos de las amenazas.

Castillo de Xibert

Castillo de XibertCastillo de XibertCastillo de XibertCastillo de Xibert

Supongo que los que me seguís os habreis dado ya cuenta de que soy un apasionado de los castillos, hay muchas referencias a ellas en mi blog. Pues bien, éste es alucinante por que NO está restaurado, al menos no todavía,  y se conserva fantásticamente para tener más de 1000 años, sí, has leído bien. Si os gustan los castillos y el contacto con la naturaleza, os lo recomiendo encarecidamente, podéis incluso subir hasta el castillo por la ruta de senderismo que lleva directamente a él.

Usuarios de ftp virtuales con vsftpd y MySQL

Un problema que se me ha presentado más de una vez es dar acceso FTP a determinadas carpetas a usuarios que necesitan actualizar archivos en ellas. Por regla general habría que crear un usuario del sistema que tuviese su “home” en esa carpeta o un enlace simbólico desde otra, pero nunca me ha gustado la idea de crear usuarios a diestro y siniestro, aunque sean sin privilegios. Buscando un día, empecé a encontrar información sobre cómo crear usuarios “virtuales” en vsftpd y me gustó mucho la idea, combinando esto con la gestión de usuarios en MySQL podría tener un sistema bastante sencillo de dar acceso FTP a unos cuantos usuarios sin incrementar los del sistema y, por tanto, sin abrir agujeros de seguridad.

Lo primero será instalar los módulos necesarios, asumiendo que ya tienes el servidor MySQL funcionando. Nos hará falta el paquete vsftpd y el pam_mysql que permitirá hacer autentificaciones contra una base de datos de este tipo.

yum install pam_mysql vsftpd

Ahora configuramos el archivo /etc/pam.d/vsftpd para que quede así;

[osus@servidor vsftpd]# cat /etc/pam.d/vsftpd
auth required /lib/security/pam_mysql.so user=vsftpd passwd=clave host=localhost db=basedatos table=usuarios usercolumn=usuario passwdcolumn=pass crypt=0
account required /lib/security/pam_mysql.so user=vsftpd passwd=clave host=localhost db=basedatos table=usuarios usercolumn=usuario passwdcolumn=pass crypt=0
session required /lib/security/pam_mysql.so user=vsftpd passwd=clave host=localhost db=basedatos table=usuarios usercolumn=usuario passwdcolumn=pass crypt=0

Esto indica a vsftpd que debe autenticarse contra “basedatos” en “localhost” con el usuario “vsftpd” y la clave “clave” y que debe buscar en la tabla “usuarios” con las columnas  “usuario” y “pass“. Qué evidente es todo 😛 .

El último parámetro, “crypt“, indica el modo en que se guardarán las claves:

  • 0 para claves en texto plano sin encriptar
  • 1 para claves encriptadas con la función crypt()
  • 2 para claves generadas con la función PASSWORD() de MySQL
  • 3 para claves en md5

Escoge el sistema que prefieras. Dejaremos ahora el archivo de configuración principal de este modo:

[osus@servidor vsftpd]# cat /etc/vsftpd/vsftpd.conf
ftpd_banner= "Servidor FTP"
anonymous_enable=NO
chroot_local_user=YES
guest_enable=YES
guest_username=ftpoculto
hide_ids=YES
listen=yes
listen_address=192.168.3.254
listen_port=21
local_enable=YES
max_clients=100
max_per_ip=5
pam_service_name=vsftpd
use_localtime=YES
user_config_dir=/etc/vsftpd/usuarios
userlist_enable=YES
userlist_file=/etc/vsftpd/denied_users
virtual_use_local_privs=YES
xferlog_enable=YES
async_abor_enable=YES
connect_from_port_20=YES
dirlist_enable=NO
download_enable=NO
local_umask=000

Con esto le estamos diciendo que no permitiremos el acceso anónimo y que el usuario real que se utilizará será “ftpoculto“, los usuarios virtuales se comportarán como este usuario. Le indicamos, además, que busque los usuarios virtuales en /etc/vsftpd/usuarios y que no deje entrar a ningún usuario real, sólo a los virtuales. Para esto último haremos lo siguiente:

cat /etc/passwd | cut -d ":" -f 1 | sort > /etc/vsftpd/denied_users

Así añadimos a la lista de usuarios denegados a todos los usuarios del sistema, no hay que ponerlos a mano uno a uno 🙂 .

Ahora debemos configurar el acceso para cada usuario dentro de la carpeta “usuarios“. El nombre del archivo debe ser el mismo que el del usuario que se ha añadido a la base de datos, el que utilizará el cliente para conectarse. Yo, por ejemplo, suelo utilizar como nombres el dominio del cliente, así se quién es quién.

[osus@servidor usuarios]# cat tudominio.com
dirlist_enable=YES
download_enable=YES
local_root=/var/www/tudominio.com/
write_enable=YES
anon_world_readable_only=NO

Tendremos que configurar el directorio de este usuario para que pueda escribir en él. Para conseguirlo recordamos que vsftpd utilizaría el usuario real “ftpoculto“. Debemos, por tanto, dar permisos sobre los directorios de los usuarios virtuales a ese usuario:

chown -R ftpoculto.users /var/www/tudominio.com

Con esto, el usuario “tudominio.com” podrá moverse en /var/www/tudominio.com a sus anchas 🙂 .

La verdad es que me ha funcionado muy bien siempre. Si se combina con un sistema de acceso VPN sencillo, de manera que el puerto FTP no tenga que estar abierto púclibamente, queda todo muy robusto y seguro además de que es muy sencillo añadir nuevos usuarios, incluso lo puedes automatizar con un script ya que solamente hay que añadir un registro en la base de datos y crear el archivo de configuración en /etc/vsftpd/usuarios.

Es una buena idea en pequeños entornos ISP no dedicados o especializados, entornos donde los usuarios no van a necesitar habitualmente acceso FTP (cms, blogs, webs corporativas…).

Hay muchos más parámetros en vsftpd, desde limitar el ancho de banda por usuario hasta utilizar SSL en las conexiones, sólo hay que leer un poco la documentación 🙂 .

Otras utilidades para un servidor de correo

A veces un servidor de correo puede sernos de muchísima utilidad si sabemos cómo manejarlo correctamente. En el artículo de hoy veremos como utilizar nuestro MTA para ejecutar automáticamente acciones cuando se recibe un determinado email o con los parámetros que definamos. Una vez conozcamos la teoría plantearemos dos casos prácticos como ejemplo.

Para comenzar necesitaremos un servidor Linux con Qmail como MTA. Supongo que cualquier otro servidor de correo servirá (Sendmail, Postfix), yo lo personalizo en Qmail porque es el que conozco y utilizo, pero estoy seguro de que con los demás se puede hacer lo mismo.

La teoría

Para entender cómo funciona la idea debemos entender primero cómo Qmail realiza la entrega de mensajes en los buzones locales. Es un tema sobre el que hay bastante literatura buscando en Google pero que puede no quedar muy claro en una lectura rápida. Es el famoso lío de los archivos .qmail.

Cada vez que se crea un usuario del sistema se debe crear, si va a recibir emails, un archivo .qmail-default en su directorio de usuario.

[jiglesias@lerez ~]# cat /home/jiglesias/.qmail-default
./Maildir/

Normalmente este archivo se crea automáticamente ya que al instalar qmail se habrá creado una copia de este archivo en el esqueleto de creación de usuarios /etc/skel:

[jiglesias@lerez ~]# ls -la /etc/skel
total 56
drwxr-xr-x  4 root root  4096 Jul 29 18:29 .
drwxr-xr-x 97 root root 12288 Dec 30 04:08 ..
-rw-r--r--  1 root root    33 Feb  1  2008 .bash_logout
-rw-r--r--  1 root root   176 Feb  1  2008 .bash_profile
-rw-r--r--  1 root root   124 Feb  1  2008 .bashrc
drwx------  5 root root  4096 Aug 29  2007 Maildir
-rw-r--r--  1 root root    12 Jan  2  2008 .qmail-default
-rw-r--r--  1 root root   658 Sep 12  2006 .zshrc

Para el que no lo sepa, el esqueleto son los archivos que se copiarán al directorio de usuario (con los permisos de éste) cada vez que se crea uno nuevo. Si quieres que todos tus usuarios tengan algún archivo automáticamente, éste es tu sitio. En nuestro caso vemos que además del .qmail-default está el directorio Maildir, el de entrega por defecto del correo en qmail. Teniendo un usuario este archivo y este directorio, podrá recibir correo.

Vale vale, vas muy deprisa. Todavía no has explicado para que sirve el .qmail-default ese.  Cierto. Los archivos .qmail indican las reglas de entrega de los mensajes en base a dos parámetros:

  • El nombre del archivo .qmail-xx hace referencia a la cuenta de correo sobre la que actúa.
  • El contenido indica qué hacer con el correo.

Supongamos un usuario (jiglesias)  que recibe el correo de dos cuentas distintas (jiglesias@… y osus@…).

Por defecto todo su correo irá a su buzón ya que es lo que indica el archivo .qmail-default. Queremos ahora que el comportamiento sea distinto dependiendo de la cuenta a la que vaya dirigido, creamos entonces los archivos .qmail para las direcciones:

  • .qmail-jiglesias : controla el correo que vaya a jiglesias@…
  • .qmail-osus : controla el correo que vaya a osus@…

Podemos incluso ir un poco más lejos con un archivo .qmail-jiglesias-default, y controlaríamos el correo que vaya a cualquier dirección del tipo jiglesias-XXXX@…, es decir, cualquier dirección que comience por jiglesias- será controlada por este archivo .qmail.

En el caso básico, que es el que veíamos, la entrega se realiza al buzón de correo del usuario (el directorio Maildir) pero podríamos hacer otras cosas en función del contenido del archivo .qmail encargado de procesar la entrega del correo:

Reenvío a otra cuenta:

[jiglesias@lerez ~]# cat /home/jiglesias/.qmail-jiglesias
reenvio@osusnet.com

Reenvío a un programa/script:

[jiglesias@lerez ~]# cat /home/jiglesias/.qmail-osus
|preline /usr/bin/programa

Combinación de los anteriores

[jiglesias@lerez ~]# cat /home/jiglesias/.qmail-jiglesias
./Maildir/
reenvio@osusnet.com
|preline /usr/bin/programa

El caso que nos interesa es el segundo, es decir, pasar la entrega del email a un script que se encargará de analizar el email y tomar decisiones.

Te habrá llamado la atención el |preline del archivo .qmail. Es el sistema que prepara un email para ser procesado y entregado a otro script añadiendo algunas cabeceras. La salida del script que reciba el email es importante ya que de ella depende el resultado de la entrega final de email, en concreto es importante saber que si queremos rechazar un email habrá que terminar el script con un exit (100), esto indicará a qmail que debe rechazar ese mensaje. Veremos más adelante la utilidad de esta salida.

La práctica

Una vez sabemos cómo pasar el control de un email recibido a un script, veamos como tratarlo. Lo haremos con un script PHP. En nuestro archivo .qmail haremos algo como:

[jiglesias@lerez ~]# more .qmail-jiglesias
|preline /usr/bin/php /home/jiglesias/prueba.php

Con esto hemos terminado el trabajo en el servidor de correo. Veamos ahora como parsear el email desde PHP.

Lo primero que debemos hacer es recoger el contenido del email desde el script a través de la entrada estándar,  después ya podemos procesar el email como una cadena de texto.

<?php
$email=file("php://stdin");
$email=implode("", $email);
?>

Con estas sencillas dos líneas de código tendremos en nuestro script el contenido del email. Ahora sólamente debemos procesarlo. Podemos hacerlo línea por línea por nuestra cuenta o apoyarnos en alguna librería. Yo utilizo Mail_mimeDecode de Pear. La ventaja de esta librería es que podemos obtener, además del texto del email, los archivos adjuntos.

<?php
$email=file("php://stdin");
$email=implode("", $email);
$params['include_bodies'] = true;
$params['decode_bodies'] = true;
$params['decode_headers'] = true;
$params['input'] = $email;
$structure = Mail_mimeDecode::decode($params);
$subject = trim($structure->headers['subject']);
$ddate = trim($structure->headers['date']);
$from = addslashes(trim($structure->headers['from']));
if(ereg("<(.*)>", $from, $p)) $from=$p[1];
if(ereg(""(.*)"", trim($structure->headers['from']), $pp))
    $nombre=$pp[1];
?>

Así podemos ya procesar el email y tomar las decisiones que consideremos oportunas. Podremos insertarlo en una base de datos, lanzar otros procesos automatizados, enviar avisos por SMS… lo que se nos ocurra.

Casos prácticos

La pregunta clave, después de ver la teoría, sería ¿para qué me sirve esto?.  Os propongo dos aplicaciones que yo he hecho.

Sistema de soporte

El típico sistema de tickets de soporte. En el asunto del email se arrastra el identificador del ticket, por ejemplo [#123445]. Tendremos que analizar el asunto y comprobar si aparece el patrón predefinido. Si no existe estamos ante un nuevo ticket e insertamos los datos en nuestra base de datos, en caso contrario es una respuesta a una incidencia anterior y ahí tendremos el identificador. Sencillo ¿no?. Podemos incluso adjuntar a nuestras indicendias archivos que puedan llegar en el email.

Envío de archivos desde el movil

El segundo ejemplo sería semejante al anterior técnicamente pero distinto conceptualmente. La mayoría de los móviles (salvo los de gama alta) no pueden enviar archivos desde los formularios wap (<input type=”file”>). La alternativa es que el usuario envie un email o un MMS (la mayoría de operadoras permiten el envío a direcciones de email) con sus archivos. Nuestro script procesará el contenido del mail recibido, decodificará los archivos y los tratará como sea oportuno.

Son dos sencillos ejemplos de cómo utilizar el email para automatizar tareas, pero, como he comentado, podríamos hacer todo lo que se nos ocurra, desde enviar un SMS de aviso hasta incluso reiniciar nuestro servidor o lanzar cualquier otra tarea.

Conversión de vídeos a 3gpp bajo demanda en un entorno web

Hoy veremos como aplicar conversiones de vídeo en un entorno web donde los usuarios suben sus vídeos en cualquier formato. Sí, tienes razón, ni más ni menos que lo que hace YouTube, de hecho utilizaban un sistema muy similar a lo que veremos ahora y basado en el mismo software. En realidad el artículo se podría aplicar a prácticamente cualquier tipo de conversiones, incluso para iPod o PSP, sólo hay que utilizar los parámetros adecuados. Nosotros nos centraremos en la conversión a 3gp para después poder hacer streaming con ellos además de permitir su descarga.

Nuestro entorno se basará en un servidor con Linux (Centos5 en mi caso). Como software sólamente necesitaremos ffmpeg, herramienta imprescindible para cualquier aplicación (tanto web como de escritorio) bajo Linux.

¿Qué es ffmpeg?

Hace unas semanas veíamos cómo utilizar ffserver para convertir flujos de vídeo y hacer streaming. ffmpeg es la utilidad en la que se apoya ffserver para realizar las conversiones.

ffmpeg es una herramienta de software libre que permite realizar conversión entre la mayoría de formatos de vídeo más utilizados. Una inmensa mayoría de programas de conversión bajo Windows no son más que frontends gráficos para ffmpeg.

Normalmente los paquetes precompilados de ffmpeg no vienen con las extensiones adecuadas para las conversiones que necesitamos, así que deberemos compilar nuestra propia versión.

Necesitas instalar los siguientes paquetes, son más de los imprescindibles, pero así nos ahorraremos problemas futuros:

libmp4v2
libvorbis
libvorbis-devel
lame
lame-devel
faac
faac-devel
faad2
x264
x264-devel
xvidcore
xvidcore-devel

Debo decir que para mi Centos no están todos disponibles como rpm con lo cual habrá que compilar manualmente algunos de ellos. No deberías tener ningún problema para localizar cada librería.

Finalmente habrá instalar los siguientes paquetes:

http://ftp.penguin.cz/pub/users/utx/amr/amrnb-7.0.0.2.tar.bz2

http://ftp.penguin.cz/pub/users/utx/amr/amrwb-7.0.0.3.tar.bz2

Con esto tenemos ya todo preparado para compilar nuestro propio ffmpeg. Descarga el paquete desde la web oficial, descomprímelo y:

./configure --enable-libmp3lame --enable-libvorbis --enable-libogg --enable-libamr-nb --enable-libamr-wb --enable-libfaac --enable-gpl --enable-libxvid --enable-libx264 --enable-libfaad --enable-shared
make
make install

Si has seguido bien todos los pasos tendrás el software de conversión preparado.

Convirtiendo a 3gp

Para realizar las conversiones algo tan sencillo como:

ffmpeg -y  -i original.avi -s qcif -r 12 -b 30 -ac 1 -ar 8000 -ab 12200 video.3gp
/usr/local/bin/MP4Box -3gp -mtu 1450 -hint video.3gp

Cuando vimos cómo hacer streaming a móviles veíamos como utilizar la utilidad MP4Box para que nuestros vídeos 3gp se puediesen utilizar para emitir en vivo.

Para nuestro proyecto es probable que necesitemos algo más. Si queremos que también se puedan visualizar los vídeos desde una web necesitaremos convertirlos a flv:

ffmpeg -y -i original.avi -acodec libmp3lame -ac 2 -ar 22050 -r 12 -b 196 -s 176x144 video.flv
/usr/bin/flvtool2 u video.flv

Flvtool es una herramienta que inserta en los flv los metadata necesarios para que funcione bien en el reproductor flash.

Y necesitaremos capturar algún fotograma del vídeo para mostrar como demo:

ffmpeg -i original.avi -y -ss 00:00:01 -vframes 1 -an -sameq -s 160x120 -f image2 thumbnail.jpg

Ahora ya sabemos:

  • cómo crear nuestro vídeo 3gp que nos sirva tanto para descarga como para streaming.
  • cómo crear el vídeo flv que nos sirva para ver vía web.
  • cómo generar thumbnails de escenas del vídeo.

Creando el entorno web

Supongamos que queremos desarrollar una web al estilo Youtube donde el usuario sube vídeos desde un formulario y posteriormente se desea mostrarlos categorizados, con un buscador, una preview (flv), descarga para móviles, etc.

La parte de la web propiamente dicha resulta obvia, no vamos a entrar en detalles. Lo que nos ocupa aquí es como realizar la conversión según las instrucciones que hemos visto. Obviamente no podemos ejecutar la conversión cada vez que un usuario sube un vídeo, sería un proceso lento y pesado. La mejor manera es crear una cola de conversión. Cuando se sube un nuevo vídeo no esta disponible públicamente (no se ha convertido todavía). Podríamos definir tres estados diferentes para un video:

  1. Sin procesar (convertir).
  2. Procesando.
  3. Procesado.

Según esto sería sencillo tener en una tabla el estado de los vídeos. Sólo los procesados se listarían públicamente.

Por otro lado tendríamos una tarea encargada de buscar vídeos en estado “sin procesar” y realizar su conversión. Esta tarea podría ser o bien un demonio residente que está permanentemente buscando vídeos o bien, si el tráfico de nuevos vídeos no va a ser elevado, podría ejecutarse periódicamente para realizar las conversiones.

Si el tráfico fuese muy elevado podría incluso haber varias tareas en paralelo ya que una vez una de ellas encuentra un vídeo “no procesado” actualiza su estado a “procesando” de manera que la siguiente tarea ya no escogerá ese mismo vídeo.

La teoría es mucho más sencilla de lo que parece. La tarea que realiza la conversión creará los formatos que estimemos oportunos según ya hemos visto antes.

Convirtiendo a otros formatos

Con ffmpeg se pueden generar los vídeos para casi cualquier formato existente incluyendo PSP, iPod/iPhone/iTouch… Googleando un poco encontrarás los parámetros adecuados para cada formato.

Conclusiones

En este artículo he explicado cómo realizar conversiones de vídeos a distintos formatos y cómo aplicarlo a un entorno web dónde los usuarios suben sus propios vídeos. He dado los pasos básicos para entender el sistema, vosotros tendríais que adaptarlo a vuestras necesidades.

Oh-la-la, París ida y vuelta

Desayuné en Valencia, comí en París y cené en Valencia. Fin a una semana de estrés y tensión.

Hace un par de semanas, nos avisaron un viernes a mediodía de que teníamos que exponer oralmente (en inglés) la parte ténica de un proyecto al que nos habíamos presentado ante un comité de expertos de nuestro potencial cliente. La reunión sería el martes siguiente, así que tendríamos tres días, de los cuales dos eran fin de semana, para preparar nuestra presentación. Conseguimos posponerlo hasta el jueves, así que allí nos fuimos Guillermo y yo hacia París tras una semana trabajando como chinos (con todo el respeto al colectivo oriental).

Estas son nuestras caras a las seis de la mañana en el aeropuerto de Valencia, sin apenas haber dormido en los cinco días anteriores y con los nervios a flor de piel.

img_4571.JPGimg_4572.JPG

Impresionante la vista aérea de los Pirineos con ese manto de nieve…

Pirineos

Ya desde nuestra llegada a París el inglés se convirtió en nuestro idioma, no sólo con el cliente sino también con nuestros partners en Francia. Al final fueron cerca de 8 horas hablando y pensando exclusivamente en inglés.

La presentación consistía en tres partes:

  1. Arquitectura funcional
  2. Arquitectura técnica
  3. Calidad y SLA

Yo exponía la segunda. Habíamos preparado concienzudamente el contenido de nuestras presentaciones puesto que, además de comentar nuestra solución al proyecto, era más que probable que nos disparasen cañonazos de preguntas, como así fue.

Inicialmente estaban estipuladas dos horas de exposición, pero al final estuvimos cerca de dos horas y media vendiendo nuestra idea y nuestra solución. Mi exposición en particular se alargó más de una hora con constantes intervenciones de los asistentes por parte del cliente y al final se abrió un pequeño “ruegos y preguntas” aunque prácticamente se había contestado todo sobre la marcha.

Parece que les gustaron nuestras ideas y opiniones a los galos.

img_4582.JPGimg_4583.JPG

Al final, entre que se nos alargó la exposición más de la cuenta y que el tráfico en París es un caos, estuvimos a punto de perder el avión de vuelta.

La prueba de que, en efecto, era París 😛 .

Aeropuerto de Paris

Conclusiones

¿Qué he aprendido de esta experiencia?

  • Tenemos muy mal concepto de nosotros mismos al hablar en inglés, tal como nos decía uno de nuestros colaboradores en Francia, habláis claro y fluído, más que suficiente para mantener una conversación sin dificultades. Puede que gramaticalmente no sea perfecto, pero entendéis y se os entiende y se puede mantener una conversacion con vosotros sin ningún problema. Nos puso como ejemplo a los indios (de la India), que hablan un inglés gramaticalmente perfecto pero a los que no se les entiende absolutamente nada por el acento que tienen. He hecho muchas referencias al inglés porque, en realidad, era nuestro único problema. Ni hablar en público ni exponer tus conocimientos nos supone un problema, la parte técnica la tenemos ampliamente controlada, no en vano es nuestro trabajo. La barrera idiomática sí que es un hándicap, y salimos airosamente. Sólo decir que acabamos hablando de la crisis y de la burbuja inmobiliaria en España 😉 .
  • Otro de nuestros partners salía de la reunión asombrado de la manera en que habíamos sacado adelante la situación, en cómo habíamos jugado nuestras cartas ante la indiferencia inicial del cliente y su interés final.  Y todo esto “en inglés”. A veces las cosas son mucho más sencillas de lo que creemos. Si no vendes humo, si conoces el entorno y la materia sobre la que tienes que hablar, es difícil que te dejen quedar mal. Recuerda también que, igual que no hay que decir a todo sin razón,  NO hay que saberlo todo y no es malo decir “No lo sé, no dispongo de esa información, pero mañana podría enviarosla por email“.
  • A veces nos sentimos cohibidos a la hora de tratar con clientes como importantes y conocidas multinacionales, sin embargo, ten en cuenta que:
    • si buscan externalizar un servicio es porque necesitan a alguien como tú.
    • si te han llamado para que les cuentes de viva voz tu propuesta es porque algo en ella les ha gustado o llamado la atención
    • es difícil que alguien escoja un partner para un proyecto sin ver la cara de la gente que trabajará en él (no sólo técnica, también comercialmente), cuestión de confianza. Más aún si ellos son franceses y tu español.
    • es posible que lo que para ti es la mejor solución al problema, por obvia que parezca, no se le haya ocurrido antes a ninguno de los otros potenciales candidatos y el cliente se sorprenda de lo que le propones.
  • No lo había pensado antes pero es importante que el cliente participe y pregunte durante tu exposición, significa que le interesa lo que le estás contando. Si te pasases dos horas hablando sin que te interrumpiesen, probablemente estarían, además de dormidos, pensando en lo que van a hacer después de que termine “este pesado”, es decir, no le interesa tu propuesta. No tengas miedo a las preguntas, si hay preguntas es porque están atentos a tu exposición.

Y esto es todo. A pesar de la tensión de esta semana, es probable que nos haya venido muy bien como ejercicio práctico tanto de conversación en inglés como de exposición “colaborativa” de un proyecto. Despues de esto creo que nos va a tocar más veces repetir experiencia en otros países.

Ciudad romana de Segóbriga

A 250km de Valencia en dirección Madrid y desviándose apenas unos 5km de la autovía A3 (perfectamente señalizado), se encuentra la Ciudad Romana de Segóbriga, una gran desconocida. Reconozco que he pasado decenas de veces por delante del letrero y nunca se me había ocurrido parar… hasta hoy.

La verdad es que nos quedamos bastante impresionados ya que, entre otras cosas, tenía teatro, anfieatro (bien conservados) y circo (apenas los restos), lo que da una idea de lo que un día fue la ciudad. Un destino poco conocido dentro de la España Romana, quizás por eso es una sorpresa.

Ciudad Romana de segóbriga

Ciudad Romana de segóbrigaForo Romano de Segobriga

Es una de las ciudades romanas (entendida como el conjunto) mejor conservadas y el conjunto arqueológico más importante de la meseta. A partir del s.I se convirtió en un importante núcleo agrario y minero además de centro de comunicaciones. La conquista islámica supuso su declive, pero, por suerte, han llegado hasta nosotros las huellas de lo que llegó a ser.

Teatro

Teatro Romano de Segobriga

Ciudad Romana de segóbrigaCiudad Romana de segóbriga

El teatro, al igual que el anfiteatro, conserva el graderío y mantiene todavia la estructura original del 79d.c., cuando se construyó. Cabe señalar que, por aquel entonces, Segóbriga tenía nada más y nada menos que 5.500 habitantes.

Termas

Termas Romanas de Segóbriga

Circo

Esa forma oval que se observa en el centro de la foto era el impresionante circo. Lo reconozco, me habría gustado vivir aquella época sólo por ver una apasionante carrera de cuadrigas, quizás ya hubiese un Fernando Alonso en la antigua Roma 😛 .

Circo Romano de Segóbriga

Anfiteatro

Finalmente el precursor de nuestras plazas de toros. Con capacidad para 5.500 espectadores, flanqueaba junto al teatro la entrada a la ciudad y, como casi siempre, se construyó aprovechando una ladera natural del cerro. Increíble su acústica.

Anfiteatro Romano de Segóbriga

Anfiteatro Romano de SegóbrigaAnfiteatro Romano de SegóbrigaAnfiteatro Romano de Segóbriga

Hospedería Casas de Lujan

Lo siento, tengo el vicio de comer todos los días 😛 . Al llegar a Segóbriga era ya la hora de comer, así que nos dejamos guiar por un folleto que cojimos en la propia Ciudad Romana. A unos 8km de ésta llegamos a la Hospedería Casas de Luján, un gran descubrimiento que nos dejó con la boca abierta.

Hospedería Casas de Luján

Hospedería Casas de LujánHospedería Casas de LujánHospedería Casas de Luján

Enclavada en un maravilloso entorno rural se encuentra esta gran casa de labranza del s.XVII completamente rehabilitada y convertida en hotel, restaurante y salones de celebraciones. Pero Casas de Luján no es solo la casa, es todo el entorno, completamente  integrado, parece que te encuentres en un museo etnográfico y no en un establecimiento de hostelería. El río y los animales (pavos, gallinas, gallos, un burro…) no hacen sino reforzar la imagen encantadora que tiene el lugar.

Hospedería Casas de Luján

Hospedería Casas de LujánHospedería Casas de Luján

El interior es más de lo mismo, ambiente tradicional y rural, bien conservado y decorado con el gusto preciso para no caer en la soez. Esto es la carta del restaurante, muy original.

Carta en Hospedería Casas de Luján

Hospedería Casas de LujánHospedería Casas de LujánHospedería Casas de LujánHospedería Casas de Luján

Pero bueno, ya esta bien, vamos a lo importante ¿no?. Muy bonito, sí, pero ¿qué hay de la comida? Fantástica.

Migas de bacalao con gambas y piñones y Collage de foie de pato y oca con configura de naranja y frambuesa.

Hospedería Casas de LujánHospedería Casas de Luján

Chuletón de Ávila y Pierna de cordero lechal deshuesada.

 Hospedería Casas de LujánHospedería Casas de Luján

Tarta de tiramisú y Tarta de queso de cabra y membrillo.

Hospedería Casas de LujánHospedería Casas de Luján

Todo ello regado con una botella de la zona, Estola Reserva del ’98 D.O. La Mancha.

Nosotros salimos encantados y queremos volver un fin de semana para conocer más la zona (Belmonte, Lagunas de Ruidera, La Alcarria, El Toboso…)

Depurando condiciones Rewrite en Apache

Últimamente he tenido que utilizar bastante ModRewrite de Apache en distintos proyectos, algunos de migración y otros de Internet Móvil donde se necesitan ciertas URL’s para que las operadoras lancen sus sitemas de billing.

Con ModRewrite es muy fácil convertir URLs antiguas al formato nuevo en caso de migración (de manera que no pierdes el SEO que tengas). En el caso del billing de las operadoras móviles es todavía más sencillo puesto que simplemente lo usamos para simular una URL premium. Por ejemplo:

http://tudominio.com/premium.php?noticia=3

Se convierte en:

http://tudominio.com/index.php?noticia=3

De este modo no es necesario hacer scripts independientes y separados por operadora sino que todo queda integrado en nuestro framework.

El problema es que es bastante tedioso depurar lo que hace ModRewrite para ver si las condiciones que has escrito son correctas o si algún filtro no se está ejecutando correctamente. Para solucionarlo lo mejor que podemos hacer es decirle a Apache que “logee” todas las decisiones que va tomando sobre nuestros filtros. Tan fácil como esto:

RewriteEngine on
RewriteLog "/logs/rewrite.log"
RewriteLogLevel 4

RewriteCond %{REQUEST_URI} ^/premium.php$
RewriteRule ^/premium.php /index.php

Este sencillo ejemplo nos permite comprobar qué veremos en el log:

213.xxx.xxx.xxx - - [15/Nov/2008:00:48:23 +0000] [tudominio.com/sid#127d7b0][rid#16b8c20/initial] (3) applying pattern '^/premium.php' to uri '/premium.php'
213.xxx.xxx.xxx - - [15/Nov/2008:00:48:23 +0000] [tudominio.com/sid#127d7b0][rid#16b8c20/initial] (4) RewriteCond: input='/premium.php' pattern='^/premium.php$' => matched
213.xxx.xxx.xxx - - [15/Nov/2008:00:48:23 +0000] [tudominio.com/sid#127d7b0][rid#16b8c20/initial] (2) rewrite /premium.php -> /index.php
213.xxx.xxx.xxx - - [15/Nov/2008:00:48:23 +0000] [tudominio.com/sid#127d7b0][rid#16b8c20/initial] (2) local path result: /index.php
213.xxx.xxx.xxx - - [15/Nov/2008:00:48:23 +0000] [tudominio.com/sid#127d7b0][rid#16b8c20/initial] (2) prefixed with document_root to /var/www/tudominio.com/index.php
213.xxx.xxx.xxx - - [15/Nov/2008:00:48:23 +0000] [tudominio.com/sid#127d7b0][rid#16b8c20/initial] (1) go-ahead with /var/www/tudominio.com/index.php [OK]

Por cada URL que se solicita al servidor, Apache va comprobando las posibles condiciones que has escrito por si coincide con el patrón (matched) o no (not matched). Si la URL cumple los requisitos, la reescribe según se indica en la regla, en caso contrario la deja pasar tal cual. Con toda esta información podemos hacer un completo seguimiento de las reglas que queremos aplicar para comprobar si hay algún error o por qué determinada URL no hace lo que esperamos que haga.

El nivel del log indica la cantidad de información que se guardará, de 0 a 9. A  mayor valor, más información.

Algo muy sencillo pero que pasa desapercibido para la mayoría y acabamos perdiendo muchísimo tiempo probando reglas sin saber qué está ocurriendo en el interior de nuestro servidor web.

Primeros pasos con Flash Media Server (2), autentificando usuarios del chat

Hace unos días veíamos como crear un sencillo chat con FMS.

Hoy, a petición popular, vamos a añadir la primera mejora a nuestra aplicación. Por defecto habíamos diseñado un chat público, cualquiera podía conectarse. Sin embargo, puede que deseemos que sólo nuestros usuarios registrados puedan utilizarlo. Necesitamos entonces que nuestros clientes se puedan autentificar contra nuestra base de datos pero no podemos dejar esa responsabilidad en manos de la aplicación cliente, cualquiera podría hacer otra que se conecte a nuestro servidor sin requerir autentificación.

FMS no puede conectarse con ningún tipo de bases de datos, no es su función, aunque cada vez hay más gente solicitando esta funcionalidad y se espera que en la próxima versión (FMS4) haya alguna novedad al respecto. Sea como fuera, de momento no hay métodos nativos para acceder a bases de datos así que sólo se puede recurrir a lo que un día fue Flash Remoting y hoy son los servicios RPC bajo AMF, el método estándar de acceso a datos desde aplicaciones Flash (con el permiso de los webservices SOAP). Con el tiempo fueron apareciendo versiones en los distintos lenguajes para utilizar el protocolo AMF fuera del amparo de Macromedia (ahora Adobe), pero sin duda uno de los pioneros fue amfphp, el que nos permite comunicar aplicaciones Flash con el servidor a través de PHP.

AMF es un formato para serialización de datos e invocación de métodos remotos y es independiente al lenguaje con el que trabaja el servidor, simplemente debe cumplir las especificaciones. FMS, como no podía ser de otra forma, puede comunicarse con nuestro servidor gracias a este protocolo AMF y esto es precisamente lo que vamos a utilizar para autentificar a nuestros usuarios:

dibujo1.jpg

El proceso es mucho más sencillo de lo que parece.

Comenzaremos por descargar amfphp desde la web oficial.  Lo descomprimes y subes la carpeta “amfphp” a tu servidor en la ruta que desees. Ya tienes lo que es el cerebro del sistema listo, para comprobarlo prueba la URL:

http://tuservidor/amfphp/gateway.php

Si todo va bien, prueba ahora el navegador de servicios, herramienta imprescindible para probar tus métodos remotos:

http://tuservidor/amfphp/browser/

Si no has visto ningún error es que todo va bien. Veamos ahora como crear tu servicio de autentificación.

Dentro de la carpeta amfphp que has subido a tu servidor encontrarás la carpeta services. Crea dentro de ella un nuevo directorio con el nombre de tu aplicación, por ejemplo chat. Creamos ahora dentro de esa carpeta las clases y métodos que se necesiten para crear el servicio de autentificación. Por ejemplo, en mi caso creo Chat.php:

<?
class Chat{
    var $conn;    function Chat(){
      $this->conn=mysql_connect("host", "usuario", "clave");
      mysql_select_db('db', $this->conn);
    }
function login($nick, $pass){
        $rs=mysql_query("select * from usuarios where nick='$nick' AND pass='$pass'");
        if(mysql_num_rows($rs)>0)
          return 1;
        else
          return 0;
    }
}
?>

Sencillo ¿no?. Nuestra clase tiene un método login que nos dice si la pareja nick/clave existe en nuestra base de datos. Obviamente esto es sólo un ejemplo, en tu aplicación haz la clase con todos los métodos y la lógica que necesites.

Si ahora vas de nuevo al Service Browser verás que te aparece la nueva aplicación chat con la clase que has creado. Si accedes a ella puedes probar el método login pasándole los parámetros necesarios. Más sencillo imposible.

Ya tenemos la lógica de autentificación lista. ¿Cómo le decimos ahora a FMS que la utilice? Modificamos el archivo main.asc que habíamos hecho en el capítulo anterior para que antes de aceptar la conexión de un usuario la autentifique.

application.onConnect = function(client, 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){
        var myServer = NetServices.createGatewayConnection("http://tudominio/amfphp/gateway.php");
        var servicio = myServer.getService("chat.Chat", this);
        var callserver=servicio.login(email, clave);

        this.login_Result=function(result){
            //trace("RESULTADO LOGIN"+result);
            if(result>0){
                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 = "*** Entra " + client.nick + " ***";
                this.chat_so.send("onMsgSend", msg);
                client.call("onUserid", null, client.uid, client.nick);
                this.uid++;
            }else{
                var err = new Object();
                err.message = "Email o contraseña incorrectos";
                application.rejectConnection(client, err);
            }
        }
    }else{
        var err = new Object();
        err.message = "Ya hay un usuario con ese nick";
        trace(err.message);
        application.rejectConnection(client, err);
    }
}

Es tan simple como añadir la comprobación del usuario y clave de nuestro cliente. Indicamos la url de nuestro gateway (amfphp) y llamamos al método login con los datos correspondientes. Lo más importante es la forma en que obtenemos los datos que devuelve el metodo. La llamada es asíncrona, no se paraliza la actividad esperando por un resultado sino que se continua la actividad esperando a recibir la respuesta. Para eso se supone que debe haber definida una función nombremetodoremoto_Result, en nuestro caso login_Result ya que login es el método remoto al que llamamos. Cuando se llame a esta función sabremos si el usuario existe en nuestra base de datos, con lo que aceptamos su conexión al chat, o no existe y la rechazamos.

Como habéis visto, es muy sencillo llamar a métodos remotos desde FMS de manera que aumenten las posibilidades de tu aplicación ya que puedes hacer uso de bases de datos y de sistemas avanzados y siempre de manera muy simple.

Yo te he dado las pistas de cómo hacerlo, el resto queda a tu imaginación.

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.

Cancelan el SIMO, bueno ¿y que?

Creo que todos los que vivimos de esto (o en esto) lo veíamos venir.

La última vez que fui sería allá por 2002 o 2003 y, la verdad, no me quedaron muchas más ganas de vover los años siguientes en que el SIMO sufrió una decadencia progresiva sin que nadie dentro de la organización quisiera verlo, no hay más que ver los comentarios acerca de las últimas ediciones.

Hace 10 años era increíble el movimiento que suponía. Estaba en Teleco-Vigo y, acercándose las fechas del SIMO, sólo se hablaba de eso. La feria era como introducirte en Matrix o en Blade Runner, cientos y cientos de cosas nuevas, hardware y software por doquier que a saber cuando llegaría a este país. Había ordenadores con acceso gratuito a Internet (esto, hoy, puede sonar a coña, pero era un atractivo enorme de aquella). Todos los fabricantes esperaban a este evento para presentar productos nuevos. El SIMO no era la única feria tecnológica, había otras más pequeñas por todo el territorio nacional. Hoy todo esto se ha perdido. La globalización, los países emergentes e Internet han acelerado al máximo las presentaciones que, salvo contadas excepciones, ya no son por todo lo alto. Hoy se presenta un producto y mañana tienes un análisis completo en Internet, pasado lo puedes comprar en tiendas de Hong Kong y la semana que viene en el Media Markt.

El SIMO se había convertido en eso, un Corte Inglés o un Media Markt sin mayores pretensiones. Una feria donde lo más llamativo eran las azafatas (triste pero cierto) y donde la gente se dedicaba a llenarse de bolsas y bolígrafos, porque cosas interesantes, en realidad, ninguna.

Pero espera, si había una parte profesional, de hecho, salvo el último día, todo era profesional. Lancemos una tímida sonrisa. ¿Acaso ahora todo el mundo es profesional? ¡Claro!, las entradas e invitaciones circulaban por todas las esquinas.

No creo, pues, que a nadie le coja por sorpresa la decisión. Creo que una feria profesional del sector es necesaria en este país, pero no creo que la fórmula adecuada actualmente sea la del SIMO. Quizás ahora mismo estaban dando los primeros pasos correctos, pero han llegado tarde. Las grandes marcas han perdido el interés en la feria. Este año había sólo un 55% de los presentes el pasado y no creo que a gente como Telefónica o Microsoft les afecte la crisis o no puedan hacer frente a lo que cuesta tener presencia en el SIMO, una cifra ridícula al lado de sus presupuestos. Simplemente han visto que el sector ya no necesita ferias, tienen Internet.

Aprovechando la bajada de persiana (temporal) del SIMO, muchos han comparado esta feria con el Mobile World Congress (MWC), antiguo 3gsm, que se celebra en Barcelona desde hace unos años. He estado en el SIMO y en el MWC y, en serio, no hay color, no tienen nada que ver. La profesionalización del MWC es patente desde que llegas al recinto, y no lo digo por el coste de la entrada, lo digo por la gente que viene, los stands, los expositores… nada que ver con el SIMO. Posiblemente el MWC acabe igual que el SIMO, pero aún queda mucho tiempo para que llegue ese día, el movimiento profesional, los ciclos de conferencias y los workshops hacen del MWC algo distinto, algo hacia lo que debió comenzar a enforcarse el SIMO desde hace al menos cinco años. El público en general no tiene cabida en el MWC, apenas hay azafatas o regalos en los stands, sin el inglés estás incomunidado y lo peor de todo, la mayoría de cosas que se ven no son de consumo así que, por tanto, no interesan al público en general. En el MWC tampoco hay grandes lanzamientos ni presentaciones, pero genera una expectación inusitada.

Además, ¿por que no separar la parte mas lúdica de la feria y crear un SIMO dedicado al sector de juegos en exclusiva? Creo que tiene potencial y mercado suficiente y atraería a un público muy concreto y especializado. Aunque, por otro lado, si hoy en día eliminamos la parte de juegos y la de móviles (ya está el MWC) del SIMO, ¿quedaría algo realmente interesante?. Más aún, ¿debe una feria de este tipo ser interesante para el gran público o con que lo sea para el profesional es más que suficiente?. Quizás sea esta la pregunta fundamental ya que el SIMO se enfocó en sus últimos años al gran público, olvidándose del profesional al cual se suponía que ya interesaría de por sí.

Corren nuevos vientos para las ferias tecnológicas.