Archivo de la categoría: Técnico

Cucharete.com finalista de los Premios de Internet 2009

La Asociación de Usuarios de Internet organiza la XI edición de sus Premios de Internet y menuda sorpresa nos hemos llevado al ver entre los diez finalisdas de la caterogía C1-Mejor Web a Cucharete, la mejor web de restaurantes de Madrid.

cucharete

Sin duda alguna esta candidatura es premio al trabajo y al esfuerzo que están realizando tanto Marcos como su equipo para sacar adelante este bonito y suculento proyecto.

Mi más sincera enhorabuena.

Actualizado a las 16:00

Ahora mismo quedan sólo tres finalistas, Cucharete entre ellos. Increíble.

Cómo desmontar una unidad ocupada bajo Linux

Esto es algo que siempre me pasa y nunca me acuerdo de cómo solucionarlo. Hoy he recibido una alerta de uno de mis servidores, MySQL se había parado y no podía reiniciarse. Al entrar a la máquina para hacerlo manualmente, en efecto, me decía que no podía, que los archivos eran de sólo lectura 😐 . Después de hacer alguna comprobación más me doy cuenta de que la unidad entera se había quedado en algún estado extraño de sólo lectura a pesar de que el mount indicaba lo contrario.

[osus@servidor ~]# mount
/dev/hdb1 on /mnt/unidad type ext3 (rw)

Decido entonces desmontar la unidad y volver a montarla, pero…

[osus@servidor ~]# umount /mnt/unidad
umount: /mnt/unidad: device is busy

Y aquí viene el problema. Había parado, en teoría, todos los servicios que utilizaban esa unidad, pero aún así me daba este error. Podría haber forzado el umount con:

umount -l /dev/hdX

Pero prefiero saber qué es lo que está ocupando la unidad antes de forzarlo, cuestión de precaución sólo. Necesitamos saber, entonces, qué procesos están haciendo uso de la unidad que queremos desmontar, y esto es lo importante de este artículo.

[osus@servidor ~]# fuser -vm /dev/hdb1

                     USER        PID ACCESS COMMAND
/dev/hdb1:           named       456 ..c.. named
                     mysql       587 F.c.. mysqld
                     apache     1113 F.... httpd
                     root       1925 ..c.. screen
                     root       1926 ..c.. bash
                     apache     8009 F.... httpd
                     apache     9267 F.... httpd

Con este sencillo comando de fuser ya sabemos quién accede a la unidad en cuestión. En mi caso era un proceso bash de un screen que estaba abierto y un rsync. Los paré y ya pude desmontar la unidad correctamente. Al volver a montarla todo comenzó a funcionar correctamente.

¿La causa? Ni idea, no había nada raro en los logs, pero me da que el rsync había hecho algo extraño…

WordPress Mobile Pack, plugin para movilizar tu WordPress

Menuda sorpresa me he llevado hoy al leer esta noticia.

Ha habido otros intentos de hacer algo similar pero ninguno llegaba a la perfección que roza este nuevo plugin ya que lo ajusta todo al terminal del cliente, desde las imágenes hasta la paginación de artículos. En el link de presentación tenéis toda la información. No podía ser menos viniendo del organismo “oficial” de la web móbil, dotMobi.

Entre las características que me parecen importantes y fundamentales en un producto de este tipo y que hasta ahora otros habían obviado limitándose a presentar un blog menos recargado:

  • Detecta el móvil del cliente y consulta la base de datos de DeviceAtlas para obtener sus características (tamaño de pantalla, colores…).
  • Puedes hacer que cualquier petición a un dominio sea automáticamente móvil independientemente del dispositivo que acceda (m.tudominio.com).
  • Selección de temas concretos para la versión móvil independiente del web. No tienes que empezar de cero.
  • Versión móvil del panel de administración para publicar directamente desde tu dispositivo.
  • Paginación de artículos. En otros productos se mostraban en una sóla página y no todo el mundo escribe artículos pequeños 😛 .

Ahora me toca personalizar el tema, pero aquí tenéis mi blog en un Nokia N95.

Cerebro en la Sombra para móviles

Os recomiendo que le echéis un ojo ya que es muy interesante y hace todo el proceso de movilización de tu blog extremadamente sencillo.

Motivar y desmotivar en la gestión de personal

Estas vacaciones de Semana Santa que he pasado en Túnez (pronto contaré la experiencia como siempre 😛 ) me han servido para terminar de leer un libro (en realidad dos) que se me había atragantado un poco, El mito de la motivación, como escapar de un callejón sin salida, de Reinhard K. Sprenge. Lo empecé en diciembre pero hacia la mitad se me hizo un poco pesado, algo que después cambia y se hace mucho más llevadero pues el libro es realmente  interesante y de recomendable lectura a cualquiera que tenga gente a su cargo.

Reinhard, a partir de su experiencia en multitud de empresas, diferencia claramente entre motivación y manipulación,  desmitificando cualquier tipo de sistema de incentivos, léase por objetivos, pagas de beneficios, comisiones… Para él cualquiera de estos sistemas son la respuesta a la acción desmotivadora de algún directivo que no sabe cómo reconducir a su gente después de haber provocado, sin saberlo, la situación que viven.

En un momento del libro, Reinhard dice algo así,

Si nuestros colaboradores son gente adulta, con hipotecas, niños a los que criar y educar, parejas por las que luchar… ¿Por qué hemos de pensar  que en su vida  profesional alguien tiene que tratarlos como críos diciéndoles en cada momento lo que deben hacer y cortando su iniciativa?

Nuestros colaboradores son gente con conociemientos, preparación y experiencia y no quieren un trabajo de marionetas, quieren retos, afrontar problemas y tomar decisiones, pero si alguien se hace responsable permanentemente de las decisiones sin permitir que los demás tomen la inciativa y demuestren su valía nos plantamos en eso que se conoce como “desmotivación”. ¿Quién es el culpable entonces?

Intentar motivar es absurdo e imposible una vez se ha caído en la desmotivación. Por muchos intentos que se hagan por conseguirlo, normalmente a base de incentivos económicos, su éxito será sólamente efímero puesto que el dinero se valora y disfruta en un primer momento, cayendo en el olvido o en la costumbre en los siguientes.

La verdad es que en el libro no se cuenta nada que, desde la perspectiva de los que estamos por debajo, no hayamos visto siempre como “de cajón“, pero parece que hay mucha gente que nunca ha tenido este punto de vista y hay que mostrárselo.

Un libro que todos los directivos y managers deberían leer para entender muchas de las cosas que ocurren a su alrededor.

RETD, la primera red de conmutación de paquetes mundial fue española

Leyendo hoy un artículo de la serie de El Cedazo Historias de un viejo informático de Macluskey me entero de algo que es prácticamente desconocido para la mayoría de informáticos actuales. Resulta que allá por el año 1971 se inauguró en España la primera red de transmisión de datos mundial que utilizaba la conmutación de paquetes (igual que hoy en día hace Internet): RETD (Red Especial de Transmisión de Datos), que a la larga sería IBERPAC. En este otro enlace podéis encontrar la historia de de este hito de las telecomunicaciones en nuestro país, de lectura más que recomendable. No sería hasta 1978 cuando aparece otra red similar, la conocida Transpac francesa.

La historia es realmente emocionante.

Macluskey cuenta que por aquellos años (finales de los 60) se comenzaron a implantar los primeros sistemas online en la banca española, los más interesados en aquellos años en toda la informática y comunicaciones en general y que fueron los que comenzaron a utilizar las primeras redes para conectas las sucursales con las centrales. Banesto fue el primer banco en disponer de sistemas conectados entre todas sus oficinas.

Desde la Telefónica de aquellos años comenzaron a trabajar en un sistema que permitiese de un modo fiable, rápido y barato este tipo de conexiones y, sin saberlo, llegaron a la misma solución en que la gente del MIT estaba trabajando para lo que sería ARPANET, los inicios de Internet, pero como era un proyecto secreto del gobierno norteamericano no se sabía nada: la comutación de paquetes.

Vale la pena que os leáis la historia, a veces aquí también innovamos 😛 .

Igualmente recomiendo la serie completa de artículos “Historia de un viejo informático“, os dará un punto de vista que no tenemos los que nos dedicamos a esto hoy en día además de conocer la prehistoria de nuestra profesión desde un punto de vista más práctico que teórico.

Adobe AIR IX – firmar aplicaciones, una cuestión de confianza

Y otro más sobre AIR. A ver si ya es el final de la serie 😛 . Los últimos días me he estado peleando con la firma de aplicaciones AIR, no entendía mucho cómo funcionaba y me extrañaba que, a pesar de tener que firmar siempre una aplicación con un certificado SSL, al instalarla siempre me salía “Editor: DESCONOCIDO“, lo que da muy mala imagen. Ahora lo tengo claro, confundía los términos firmar y confiar. Si no quieres que salga el mensaje en cuestión tendrás que comprar un certificado de firma de software emitido por una entidad certificadora válida (Thawte), una firma de confianza.  Lo malo es que su precio ronda los 300 euros, nada más y nada menos. Personalmente creo que se han flipado un poco pero si no las firmas tus potenciales usuarios tendrán una sensación de inseguridad, tus aplicaciones estarán firmadas pero no se confiará en ellas.

Existe una segunda opción y es crear tu propia entidad certificadora (CA) y firmar tus aplicaciones tú mismo. El inconveniente de hacerlo así es que los usuarios tendrán que tener instalado el certificado de tu CA (los habituales vienen por defecto en el navegador). Como la aplicación en la que estoy trabajando se utilizará en un entorno concreto y definido, puedo utilizar este sistema y ahorrarme un dinero. Además, mis potenciales usuarios ya tienen instalado el certificado de nuestra CA ya que será la misma que utilizamos para generar certificados SSL cliente/servidor. Si firmo la aplicación AIR con la misma autoridad todo irá bien.

En aquel artículo vimos cómo generar tu propia autoridad de certificación, el método sigue siendo el mismo. Sólo necesitaremos OpenSSL:

openssl req -x509 -newkey rsa:2048 -days 3650 -keyout cakey.pem -out cacert.pem

Creamos un par de archivos para mantener la base de datos de certificados emitidos:

echo '100001' >serial
touch certindex.txt

Veamos ahora cómo generamos el certificado para la firma de software. No es fácil saber todas las opciones necesarias para que después funcione la firma, lo mejor es meterlas todas en un archivo de configuración, openssl.cnf:

dir                    = .

[ ca ]
default_ca                = CA_default

[ CA_default ]
serial                    = $dir/serial
database                = $dir/certindex.txt
new_certs_dir            = $dir/certs
certificate                = $dir/cacert.pem
private_key                = $dir/cakey.pem
nameopt                = default_ca
certopt                = default_ca
policy                    = mypolicy
default_days            = 365
default_md                = md5
preserve                = no
email_in_dn                = no

[ mypolicy ]
countryName            = match
stateOrProvinceName        = match
organizationName            = match
organizationalUnitName        = optional
commonName            = supplied
emailAddress            = optional

[ req ]
default_bits                = 1024
default_keyfile            = key.pem
default_md                = md5
string_mask                = nombstr
distinguished_name        = req_distinguished_name
req_extensions            = v3_req

[ req_distinguished_name ]
0.organizationName            = Organization Name (company)
organizationalUnitName            = Organizational Unit Name (department, division)
emailAddress                = Email Address
emailAddress_max            = 40
localityName                = Locality Name (city, district)
stateOrProvinceName            = State or Province Name (full name)
countryName                = Country Name (2 letter code)
countryName_min                = 2
countryName_max            = 2
commonName                = Common Name (hostname, IP, or your name)
commonName_max            = 64

0.organizationName_default        = Xplota Soluciones
localityName_default            = Valencia
stateOrProvinceName_default        = Valencia
countryName_default            = ES
emailAddress_default            = [email protected]

[ v3_ca ]
basicConstraints                = CA:TRUE
subjectKeyIdentifier            = hash
authorityKeyIdentifier            = keyid:always,issuer:always
keyUsage                    = cRLSign, keyCertSign
nsCertType                         = sslCA, emailCA, objCA
subjectAltName                = email:copy
crlDistributionPoints            = URI:http://ca.xplota.com/cert/
nsCaPolicyUrl                = http://ca.xplota.com/policy.html

[ v3_req ]
basicConstraints                = CA:FALSE
subjectKeyIdentifier            = hash

[ air_cert ]
basicConstraints              = critical, CA:false
keyUsage                               = critical, digitalSignature
extendedKeyUsage               = critical, codeSigning
subjectKeyIdentifier            = hash
authorityKeyIdentifier            = keyid:always, issuer:always
subjectAltName                = email:copy
issuerAltName                = issuer:copy
crlDistributionPoints            = URI:http://ca.xplota.com/cert/

Quizás tengas que cambiar alguna ruta a los archivos de tu CA. Son muchas opciones, pero no hace falta que conozcas los detalles.  Generemos ahora nuestro certificado:

openssl req -new -nodes -out air_key-req.pem -keyout private/air_key-key.pem -days 3651 -config ./openssl.cnf -extensions air_cert

Cuando te pida los datos del certificado, muy importante: los relativos a nombre de la organización, localidad, provincia y país tienen que ser los mismos de la CA o no podrás generarlo, pon exactamente los mismos datos. En Common Name debes poner el nombre que quieres que aparezca en vez de aquél “DESCONOCIDO, puede ser el tuyo o el de tu empresa.

Si has llegado hasta aquí sólo nos queda firmar el certificado con la CA.

openssl ca -extensions air_cert -out air_key-cert.pem -days 3652 -config ./openssl.cnf -infiles air_key-req.pem

Cómo vimos con los certificados cliente, el certificado generado no nos sirve de mucho, debemos exportarlo a un formato más estándar:

openssl pkcs12 -export -out air_key.pfx -in air_key-cert.pem -inkey private/air_key-key.pem -name "My Code Key" -chain -CAfile cacert.pem

Hemos terminado. Copia el archivo air_key.pfx a tu estación de trabajo y exporta tu proyecto AIR con este certificado. Si no hay problemas extraños tendrás tu aplicación firmada. Vamos a probarla:

signed air app untrusted
Vaya, no funciona. ¿Qué ha pasado? Sencillo, lo que comentaba al principio, tu sistema no tiene instalado el certificado de la CA con lo cual no confía en tu aplicación. Instalarlo es muy sencillo. Se importa el archivo cacert.pem en la lista de “Entidades Emisoras de Confianza” de tu navegador web.

Veamos ahora qué ocurre si tratamos ahora de instalar la aplicación firmada con nuestro certificado:

air_trus¡Funciona!

Cómo mi entorno es limitado y ya tiene mi CA puedo fácilmente firmar yo mismo mis aplicaciones, en un entorno real más general no sería posible y habría que pagar por la confianza.

Un aspecto muy importante sobre la firma de aplicaciones AIR y a tener en cuenta es que debes firmarla siempre con el mismo certificado, cada nueva versión debe ir firmada con el mismo certificado que utilizaste la priemra vez o tus clientes no podrán actualizar de una versión a otra ya que el mecanismo de seguridad detecta que el certificado es distinto y puede ser una brecha de seguridad.

Espero haberos aclarado un poco el mundo de las firmas y confianzas en AIR.

Adobe AIR VIII – Información encriptada y persistente

Ya hemos visto como trabajar con bases de datos con AIR, sin embargo he deubierto un nuevo método para conservar datos que puede resultar especialmente útil para mantener información sensible, como claves de acceso a servicios, ya que se guarda encriptada. Hablamos de la clase EncryptedLocalStore.

Una de las peculiaridades de esta clase es que es persistente mientras la aplicación no borre sus contenidos, ya que aunque se desinstale los datos siguen ahí, lo que resulta especialmente útil si tus aplicaciones son de pago (guardar licencias) o tienen periodos de prueba (así no se podrá utilizar de nuevo al desinstalar y volver a instalarla).

Cada aplicación dispone de su propia EncryptedLocalStore con lo que los datos que se guarden en una no interferirán con los de otra.

EncryptedLocalStore tiene sólamente tres métodos estáticos (no es necesario instanciar la clase) que permiten guardar, leer y eliminar datos.

  • setItem(“nombre”, valor):  guarda un dato.
  • getItem(“nombre”):  lee el dato.
  • removeItem(“nombre”):  elimina los datos.

Para dar mayor versatilidad al sistema, los datos a guardar deben ser del tipo ByteArray, así que se podrá guardar cualquier dato que se pueda convertir a este tipo y no sólo cadenas de texto.

Veamos un ejemplo:

//guardar datos
var clave:String = "password";
var bytes:ByteArray = new ByteArray();
bytes.writeUTFBytes(str);
EncryptedLocalStore.setItem("clave", bytes);

//leer datos
var datos:ByteArray = EncryptedLocalStore.getItem("clave");
var miclave:String=datos.readUTFBytes(datos.length));

//eliminar datos
EncryptedLocalStore.removeItem("clave");

Extremadamente sencillo y útil, no se como no lo había visto antes, creo que pasa bastante desapercibida esta manera de guardar datos en la documentación.

De esta manera podemos guardar datos sin necesidad de bases de datos. Eso sí, al parecer no deben exceder los 10mb o comenzaremos a tener problemas de rendimiento. Recuerda lo que decía al principio, aunque el usuario desinstale la aplicación los datos de EncryptedLocalStore siguen en su sistema operativo.

Cómo modificar múltiples imágenes automáticamente con Gimp

Una de las peores tareas de escibir artículos sobre viajes o gastronómicos es cuando me toca seleccionar y escalar todas las imágenes que quiero poner en el post. Normalmente lo hago con The Gimp!, pero tardo muchísimo al tener que abrir, escalar y guardar cada imagen. Ya cansado de este proceso me puse a buscar algún plugin que permitiese a Gimp realizar conversiones automáticas de varias fotos simultáneamente. Al final lo encontré. Se trata de David’s Batch Processor, un plugin para Gimp que permite no sólo escalar sino también aplicar muchos otros filtros de manera automática.

Una vez tenemos el paquete descargado debemos copiar el archivo dbp.exe (en mi caso es Windows, en el tuyo el que resulta al compilarlo) a lib/gimp/2.0/plug-ins dentro de la carpeta de instalación de tu Gimp, C:Archivos de programaGIMP-2.0libgimp2.0plug-ins en mi caso.

Ahora simplemente arrancamos Gimp y veremos que en el menú Filtros aparece uno nuevo, “Batch Process…“.

batch1

Ya sólo deberemos utilizar las pestañas de los filtros que se quieren aplicar. Las obligatorias serán la primera (Input) y la última (Output) donde indicaremos las imágenes de entrada y el formato de salida. Desde Rename tendrás que indicar la carpeta de destino o los nombres con los que guardarás las nuevas, por lo que he podido ver no permite redimensionar y guardar la imagen sobre sí misma.

batch2Eso es todo, no hay mucho más. Me he quitado un buen trabajo de encima.

Televigilancia con Motion y un servidor Linux

Hoy vamos con algo curioso 😛 . A veces pienso que su utilidad no está muy clara, me refiero a utilidad real 😉 , no sólo como juguete, pero seguro que cuando lo leáis se la encontráis.

Hoy veremos cómo montar un sistema de televigilancia con un servidor Linux y una webcam USB normal y corriente, de las baratitas.

Asumiré que ya tienes tu webcam funcionando bajo Linux, no entraré en detalles puesto que no es el objeto de este artículo y cada webcam tendrá una configuración distinta. Por suerte, hoy en día la mayoría de webcams USB funcionan perfectamente bajo Linux.

La base de este artículo cae sobre el software encargado de monitorizar la webcam en busca de actividad: motion. Lo utilicé por primera vez allá por 2001, hace ya tiempo, y desde luego puedo confirmar es una solución completa y robusta.

Motion funciona como la mayoría de programas de detección de movimiento basados en cámaras, no hay mucho misterio, simplemente comprueba la diferencia de píxeles entre fotogramas consecutivos capturados y si esta diferencia es superior a un umbral predefinido asume que hay movimiento. Este umbral debe ser bien estudiado para que un simple movimiento de cortina o el reflejo del sol que entra por la ventana no salten como un falso positivo. Una de las características que lo diferencian de otros programas similares es que permite monitorizar tantas cámaras como el ancho de banda de tus puertos USB pueda asumir, aunque no tienen porqué ser USB, recuerda que Linux trata igual cualquier flujo de vídeo, venga de donde venga, /dev/videoX. Veremos todo esto más adelante.

Instalación

En mi caso, como ya sabéis los que me seguís, utilizo un servidor con Centos5. No hay un rpm para esta distribución (o al menos yo no lo encontré en su día) y me gusta normalmente instalar las cosas con rpm por sencillez, así que vamos a construirlo desde el fuente, así que, descárgalo y descomprímelo.

Dentro de esta carpeta que has obtenido encontrarás un archivo motion.spec.in, edítalo y cambia las primeras líneas:

Name:           @PACKAGE_NAME@
Version:        @PACKAGE_VERSION@

por

Name:           motion
Version:        3.2.11

Guárdalo. Ahora copia el archivo original que descargaste antes, motion-3.2.11.tar.gz a /usr/src/redhat/SOURCES/. Ya está todo, ahora construímos el RPM.

[osus@servidor motion-3.2.11]# rpmbuild -bb motion.spec.in

Si todo va bien, cuando termine tendremos el RPM en /usr/src/redhat/RPMS/x86_64/motion-3.2.11-1.x86_64.rpm. Si usas una arquitectura de 32bits lo tendrás en una carpeta distinta a x86_64, mira en /usr/src/redhat/RPMS. Instala el rpm generado, rpm -ivh motion-3.2.11-1.x86_64.rpm. Primer paso completado.

Configuración

Motion no tiene interfaz gráfica propiamente dicha aunque sí una sencilla aplicación web para modificar los parámetros. Todas sus opciones se gestionan a través del archivo de configuración /etc/motion/motion.conf. Por defecto, viene bastante bien configurado. El parámetro más importante es:

videodevice=/dev/video1

Ahí debes indicar cuál es el dispositivo de tu cámara.

Con el resto de configuraciones puedes jugar desde la interfaz web, aquí dejo algunas importantes.

Primera opción chula. Activar una interfaz web para ver las capturas directamente desde la cámara, así tienes un sitio desde donde espiar. Obviamente debes tener acceso al puerto desde donde lo quieras ver, es decir, abrirlo en el router.

webcam_port 8001

Conéctate a http://ipdelservidor:8001/. Sorpresa!. Con firefox lo verás como si fuese un vídeo, aunque en realidad es un flujo de imágenes JPG. A Explorer no le gusta mucho ese formato y se suele utilizar un applet para convertirlo.

La siguiente es interesante ya que en vez de mostrar las imágenes muestra los píxeles distintos entre ellas, útil para preparar el sistema y comprobar cómo funciona motion.

setup_mode off

Ahora activamos la gestión web para configurar el sistema y hacer más “cositas“.

control_port 8000
control_localhost off
control_authentication tuusuario:tucontraseña

Pasa lo mismo con el puerto, no olvides abrirlo.

Conéctate a http://ipdelservidor:8001/ y juega con las opciones. Todo lo que toques desde ahí se aplicará en tiempo real sin necesidad de reiniciar motion. Muy útil para la puesta a punto. Recuerda sin embargo que debes guardar los cambios para que se mantengan la próxima vez que reinicies el servidor.

motion

La siguiente nos permite decidir cuántos fotogramas deben cambiar para disparar la alerta. Por defecto viene a 1 y esto nos provocará bastantes avisos falsos, si entra alguien en casa se cambiarán muchos fotogramas 😛 .

minimum_motion_frames 1

Con ésta otra podemos generar automáticamente un frame cada X segundos. Por defecto está desactivado (0), si le das un valor se creará la imagen por cada intervalo, podremos utilizarla para poner una webcam en web “semi-real” 😛 . Cuando estaba en la universidad teníamos una cámara enfocando al comedor que actualizaba una imagen periódicamente y nos servía para controlar la cola del comedor y bajar cuando había poca 😛 .

snapshot_interval X

Motion tiene muchísimas opciones más como para comentarlas todas, en la documentación de la web oficial puedes enterarte de para qué sirven y qué hacen todas ellas.

Comprobando el funcionamiento

Ya tenemos todo listo, hemos configurado todo bien, ¿funcionará?.

Veamos qué ocurre cuando lanzamos el servicio (service motion start). Me muevo un rato delante de la cámara y ocurre esto:

snaps

Sí, motion comienza a grabar imágenes de lo que está ocurriendo. Pero eso no es todo. Cada vez que se detecta movimiento motion graba un vídeo del momento, sonríe ladrón, te están grabando 🙂 :

Enviando alertas

Hay una serie de eventos que puedes utilizar para hacer otras acciones no definidas, como enviarte alertas por email, SMS, etc…

on_event_start value
on_event_end value
on_picture_save value
on_motion_detected value
on_movie_start value
on_movie_end value

Simplemente debes añadir el comando completo que quieres utilizar. Con %f accedes al nombre del fichero generado en los eventos de imagen y vídeo. Por ejemplo, voy a utilizarla para convertir el vídeo generado a 3gp y enviarlo por email para verlo en el móvil.

on_movie_end ffmpeg -i %f -s qcif /ruta/publica/web/video.3gp && echo "puedes verlo aqui http://tuservidor.com/video.3gp" | mail -s "Alertas de movimiento" [email protected]

Incríble pero cierto 😛 . Ahora tendría una tarea que recoge los emails de ese buzón y me los envía por SMS. También podríamos haber enviado el SMS directamente como vimos aquí.

¿Puedo usar más cámaras?

Para lanzar una segunda cámara (o más) añadiríamos al final del archivo de configuración tantas líneas como cámaras quieres poner:

thread /etc/motion/cam2.conf

Donde cam2.conf es un archivo de configuracion como motion.conf donde cambias, además de todos los parámetros que necesites, el videodevice. Recuerda que los puertos de gestión y visualización deben ser diferentes en cada cámara.

Quiero ver mi cámara desde fuera sin abrir ningún puerto más

¡Qué complicado me lo estás poniendo!

Apache viene al rescate. Configuramos los puertos del streaming jpeg y/o la interfaz de administración para que se vean a través de Apache:

ProxyPass /camara.cgi http://127.0.0.1:8001
ProxyPassReverse /camara.cgi http://127.0.0.1:8001
ProxyPass /admincamara.cgi http://127.0.0.1:8000
ProxyPassReverse /admincamara.cgi http://127.0.0.1:8000

Ahora sí, todo perfecto. Aunque pensándolo bien, como comience a recibir alertas me voy a cagar de miedo :S , me estrán robando 😛 .

Adobe AIR VII – Detectar el modo de inicio de la aplicación

Bueno, pues antes de lo previsto tengo que hacer el primer añadido a la serie de Adobe Air que creía ya terminada 😛 .

La primera curiosidad de hoy se refiere a conseguir que nuestra aplicación se inicie automáticamente al identificarte en el sistema operativo. Muy sencillo:

try{
    NativeApplication.nativeApplication.startAtLogin=true;
}catch(e:Error){
    //el sistema operativo no soporta la opcion
}

Con esto conseguimos que se inicie sóla, pruébalo 😉 . Deberías dejar una opción en algún lado de tu aplicación para que el usuario desactive esta posibilidad, no a todo el mundo le gusta.

La nueva versión 1.5.1 de AIR trajo consigo una interesante funcionalidad para saber si nuestra aplicación ha sido iniciada a mano por el usuario o se ha iniciado automáticamente con el sistema operativo, pero para conseguir que funcione debemos seguir algunos pasos.

Primero debemos actualizar el sdk de AIR a la versión mas reciente desde aquí. Si el sdk de Flex es anterior al 3.3 deberías actualizarlo también desde aquí. El de Flex se descomprime en la carpeta “sdks” de tu instalacion de Flex Builder, el de AIR se descomprime dentro del sdk de Flex que has instalado antes o en el que ya tienes.

Ahora arrancamos Flex Builder y lo primero que haremos será añadir el nuevo SDK de Flex (si lo has instalado) a la lista de sdk’s disponibles. Desde tu proyecto, boton derecho, “Properties” y aquí vas a “Flex Compiler” y a “Configure Flex SDKs…“. Añades un nuevo sdk seleccionando la carpeta donde está instalado, aceptas y en la ventana anterior indicas que utilice este nuevo.

A continuación configuraremos la aplicación AIR donde queremos usar las nuevas funciones, para ello editamos el descriptor de la aplicación, el fichero xml donde se configuran las opciones, y arriba de todo dejaremos la segunda línea así:

<application xmlns="http://ns.adobe.com/air/application/1.5.1">

Es decir, que utiliza el namespace de la versión 1.5.1. Sólo eso.

Ya tenemos todo preparado. La nueva característica consiste en un método del evento InvokeEvent, reason, que nos indica precisamente eso, cómo fue iniciada la aplicación.

Simplemente debemos añadir a nuestra aplicación el detector adecuado y hacer lo que consideres oportuno dependiendo del tipo de iniciación.

<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" invoke="detecta(event)">
    <mx:Script>
        <![CDATA[
            private function detecta(a:InvokeEvent):void{
                if(a.reason=="LOGIN"){
                    //la aplicacion se lanza automaticamente al hacer login
                }else{
                    //STANDARD
                    //La aplicacion se ejecuta manualmente
                }
            }
        ]]>
    </mx:Script>
</mx:WindowedApplication>

¿Qué utilidad puede tener? Pues además de las que se te ocurran a ti mismo, puede servir para mostrar o no la ventana de la aplicación si ésta se ha lanzado a mano o “a máquina”.  Por ejemplo, si nuestra aplicación, como vimos en el primer capítulo de esta serie, es de ésas que se quedan residentes en la barra de tareas, puedes iniciarla de distinto modo si la lanza el usuario a mano o si se inicia con el sistema operativo. Normalmente cuando lanzamos nosotros una aplicación esperamos ver la ventana de ésta para utilizarla, mientras que si se lanza sóla preferimos no ver nada, cuando se necesite ya sabemos que está en la barra de tareas y que con un click se abrirá.

Eso es todo. Interesante ¿no? 🙂 .