Vuelvo de mi voluntario retiro bloguero para la segunda parte y continuación  de  Habilitar el escritorio remoto multiusuario y multisesión en Windows7.

Toda la explicación está en el artículo original. El procedimiento es exactamente el mismo pero con el nuevo archivo.

El funcionamiento es muy sencillo, se descomprime el fichero y se ejecuta el archivo install.cmd con privilegios de administrador. Para logarlo ya sabéis, botón derecho sobre el mismo y “Ejecutar como administrador”.

Si todo va bien cambiará la dll correspondiente por la parcheada y reiniciará el servicio de Escritorio Remoto con las opciones por defecto, es decir, permitir múltiples usuarios simultáneos.

Más información en el artículo original de Windows7.

Descarga aquí el archivo.

Como ya sabéis, RIM me regaló a principios de año una tableta Blackberry Playbook para la que he hecho algunas aplicaciones.

Hace ya tiempo que anunciaron que en una actualización futura podrían ejecutarse aplicaciones Android sobre el Playbook, lo que sin duda abriría la puerta a una enorme cantidad de nuevas aplicaciones de las que carece el sistema actualmente.

Tras hacerse de rogar, a mediados de octubre publicaron finalmente Playbook OS 2.0 como una beta para desarrolladores con la esperada compatibilidad de Android. El comunicado inicial era que en noviembre se publicaría la versión final estable y todos los Playbook se actualizarían, pero tristemente han pospuesto el lanzamiento hasta febrero, una pena porque, en teoría, además de las aplicaciones Android, vendría con una aplicación nativa para correo electrónico pop/imap/exchange, algo de lo que carece hoy en día a no ser que la conectes con un smartphone Blackberry. Es decir, hoy por hoy, no se puede ver el correo en el Playbook a no ser que lo enlaces con un teléfono. Todo esto podría hacer de Playbook un aparato mucho más competitivo de cara a la campaña de Navidad y así podría vender muchos más PlayEpubs .

Hablando de Android puramente, lo que han hecho en realidad es embeber una máquina virtual Android que es la encargada de ejecutar las aplicaciones. Aquí podéis ver el “escritorio” de Android corriendo sobre Playbook.

La primera impresión, tras instalar algunas aplicaciones, fue tremenda ya que funciona relativamente bien. No puedo decir que sea 100% fluido ni estable, pero considero que vale la pena solo por la oportunidad de tener aplicaciones que hasta ahora no era posible, como un simple cliente SSH.

Pero no todo iba a ser tan bonito. No se pueden instalar directamente los .apk de aplicaciones, lo han “capado” y hay que instalarla como aplicaciones Playbook normales, si intentas instalar un .apk te indica que no es posible. Para ello han creado un sistema de reempaquetamiento de .apks en .bar. Una vez en el formato nativo ya se pueden instalar y aparecen tanto en el menú de la Playbook como en el menú de aplicaciones de Android.

Los teléfonos Android suelen tener tres botones que se han conseguido de distintos modos al trasladarlos a un Playbook sin botones físicos:

• El botón “menú” de Android se convierte en el gesto “swipe down” de Playbook, con lo que la integración está bastante lograda.
• El botón “back” se crea con la barra inferior que aparece en la imagen, es el peor logrado ya que implica añadir esa barra a la pantalla.
• El botón “home” que lleva al escritorio se consigue con un gesto de 45º desde la parte inferior central de la pantalla, aceptable en cuanto le pillas el truco

Aquí cabe puntualizar que el “launcher” que trae por defecto el Blackberry Runtime for Android no permite acceder a las funciones básicas de Android (escritorio, menú de aplicaciones, etc), pero esto lo podemos solucionar instalando cualquier aplicación “launcher” (LauncherPro en mi caso) y tendremos a nuestra disposición un Android casi completo y, entre otras cosas, tendremos el cliente de email de Android, aunque podemos instalar cualquier otro . Cabe decir que es poco probable que cuando se lance oficialmente RIM deje instalar otros “launchers” que no sean el suyo propio, con lo que habrá que seguir instalándolo igual que se hace en la beta.

Según la documentación, no todas las aplicaciones Android funcionarán, entre otras funcionalidades que no estarán disponibles están:

• Widgets
• Todo lo que tiene que ver con el teléfono propiamente dicho, llamadas, SMS, MMS, obvio ya que no tiene opciones de teléfono.
• Bluetooth
• Camara
• NFC
• VoIP
• Apps that utilize native code bundled into their APK file
• Linux virtual file systems (/proc and /sys will not be supported at the app level)
• Add on libraries (all libraries defined by the tag in the app’s manifest other than “android.test.runner” are unsupported)
• The following Java software packages:
  • Vending (In App Payments): com.android.vending
  • Cloud To Device Messaging (Push): com.google.android.c2dm
  • Google Maps: com.google.android.maps
  • Text to Speech: com.google.tts

Aunque dicen que no funcionará Google Maps, doy fé de que sí funciona. Eso sí, no es del todo estable, aunque creo que eso es problema del runtime en general.

Esto quiere decir que habrá muchas aplicaciones que no funcionarán, ya se ha encargado la gente de RIM de que no se instalen aplicaciones que puedan hacerles competencia. Por ejemplo, si intentamos acceder al menú de cuentas para configurar tu cuenta de Google, RIM amablemente nos indica que no se puede, con lo que no podremos sincronizar nuestros datos.

El nuevo sistema está disponible, por el momento, como beta para desarrolladores. Pero claro, al no poder instalar .apks directamente, seguimos sin tener aplicaciones para probar. Aquí es donde llega el efecto comunidad y se comienzan a liberar aplicaciones Android reempaquetadas, en playbookbars.com tenemos un listado completo de aplicaciones listas para instalar.

Hay que puntualizar que para instalar las aplicaciones hay que hacerlo desde el SDK de desarrollo o usando BBHTool que lo hace todo mucho más sencillo. Como ya he comentado, imagino que seguirá siendo la manera de instalar muchas de las aplicaciones que RIM no querrá que nos instalemos, comenzando por el launcher.

Mi opinión personal. Sin duda la compatibilidad con Android abre un mundo de posibilidades a la Playbook, ahora estoy mucho más satisfecho con él, sigue teniendo carencias, pero ahora menos, eso sí, el sistema NO es estable en general, el runtime de Android debería ir bien sobre el hardware de la Playbook teniendo en cuenta además que el S.O. es QNX, pero aún así tiene cierto aletargamiento que hace que la experiencia en juegos no sea optima. Angry Birds, por ejemplo, funciona correctamente, pero no es lo fluido que un juego como este requiere.

He puesto muchas de las capturas minimizadas para que se vea que debajo está la Playbook, sino podríais pensar que es un tablet Android .

Yo, de momento, no vuelvo al OS 1.7 .

Ah!, que no os lo había contado, os tengo algo abandonados últimamente, pero es que he estado bastante liado, nuevo proyecto en la oficina y nuevo proyecto en casa . Research in Motion (más conocido como Blackberry) me ha regalado su nuevo tablet, el Playbook. ¿Adivináis por qué? ¡Sí! Por publicar Valenbisi para Playbook .

No lo voy a negar, nunca me habría comprado un tablet si no me lo hubiesen regalado , y después de dos meses con él en casa, me confirmo, no le veo 500 euros de utilidad . El aparato en cuestión me parece muy buen cacharro, micro de doble núcleo a 1ghz, 1G de ram, salida HDMI y lo más sorprendente, sistema operativo QNX, un nuevo player en el mercado. RIM compró QNX, un sistema operativo en tiempo real, hace unos años y ahora ha aprovechado para incluirlo en su tablet. El rendimiento es espectacular, reproduciendo una película en HD, navegando y jugando simultáneamente sin notar ni un ápice de deterioro. Pero claro, todo tiene sus pegas . Desde mi punto de vista la mayor es la falta de aplicaciones. Aunque RIM anunció a bombo y platillo hace unos meses que se podrían ejecutar aplicaciones Android, lo cierto es que por el momento no, nos limitamos a las aplicaciones nativas. ¿Y cómo se desarrollan estas aplicaciones nativas? Pues más sorprendente aún, en Adobe AIR, por mi encantado , pero reconozco que tiene muchas limitaciones a la hora de poder hacer ciertas cosas, por ejemplo un cliente ssh. Aún así es más que suficiente para la mayoría de aplicaciones de usuario.

Cuando cayó en mis manos, lo primero que eché en falta fue un lector de ebooks que me permitiese abrir los epub que ya tenía y que suelo leer en el móvil o convertir a mobi para pasarlos al Kindle. Ni corto ni perezoso me dije, ¿por qué no hacerlo yo mismo? De eso hace dos meses y hoy os confirmo que ya está a la venta .

La verdad es que inicialmente pensé que sería mucho más sencillo, de hecho, tras estudiar el formato epub y tener el sistema de descompresión y lectura preparado, creía que lo tenía prácticamente hecho, ¡cuanto me equivocaba!. La parte de paginación tipo libro, es decir, click para página siguiente, click para página anterior, se me complicó muchísimo. Rehice el sistema cuatro veces desde cero ya que no encontraba la forma correcta de que todo funcionase como debía. Finalmente di con algo que funcionaba, me limitaba para hacer otras cosas, pero al menos la navegación y lectura eran fluidas y usables .

La última semana de desarrollo  fue la más satisfactoria a nivel personal ya que, una vez superados los problemas de la paginación (mes y medio solo para eso), me dediqué a añadirle funcionalidades más vistosas y llamativas de cara al usuario, aumentar el tamaño de fuente, modo noche que hace el fondo negro y la fuente blanca, reducir y aumentar el brillo de pantalla, añadir marcadores para volver rápidamente a ciertas páginas, porcentaje de lectura…

Creo que me quedó muy aparente . En la imagen de abajo podéis ver la interactividad de la pantalla de lectura con 4 zonas sensibles para hacer click, cada una con una función distinta. Pero eso no es todo, si se hace un click largo, es decir, se pulsa con el dejo y de deja pulsado sin levantarlo más de un segundo, sale la opción para añadir marcadores (o eliminarlo si esa página ya lo tenía).

He de decir que la finalidad de la aplicación no es hacer negocio, la hice para leer mis libros, pero si entra algo… . Los primeros tres días a la venta generó casi 200 descargas a 2$. Tampoco me puedo quejar.

Y como siempre llego tarde a todas partes he de decir que me pasé estos dos meses de desarrollo controlando en la tienda de aplicaciones que no saliese otro lector de epubs. Pues bien, el mismo sábado que subí la mía apareció otra publicada. Encima tardaron una semana en validármela, con lo que la otra tuvo tiempo de copar el mercado, una lástima, pero como siempre, tarde a todas partes .

Más información en PlayEpub.

Nokia ha cumplido la promesa que hizo justo después de anunciar que usará Windows Phone 7 en sus teléfonos de gama Alta, regalar un flamante Nokia E7 a todos los miembros del foro de desarrolladores, yo entre ellos . El mío me llegó hace unos días directamente desde Finlandia. Justo cuando ya tenía mi Nexus S. Y es que no quieren que dejemos apartada la plataforma Symbian desde ya mismo .El teléfono me ha sorprendido gratamente, tanto la enorme pantalla como el acabado son excepcionales, todo metálico. Eso sí, lo hace pesar un poco, pero la primera impresión es genial.

Como ya comenté anteriormente (y aquí me llamareis friki), soy un Nokia-Fan desde hace mucho tiempo. El Nexus ha reforzado mi idea de que los teléfonos Nokia son mucho más sencillos de utilizar para el público general sin mermar en prestaciones, a mis hermanas les costaría muchísimo adaptarse a un Android, mientras que Symbian mantiene la esencia de un teléfono normal pero con con más cosas y táctil.

Aquí lo tenéis comparado con el Nexus S, como veis no tiene nada que envidiarle, todo lo contrario. La única pega es que la pantalla no es tan sensible como la del Nexus, pero eso sí, tengo que decir que el E7 aun tiene el plástico protector original, con lo que aún así el funcionamiento es adecuado incluso para jugar al Angry Birds.

Pero no todo iban a ser maravillas. En los pocos días que lo tenemos en casa lo hemos utilizado para cacharrear un poco y para jugar y se nos ha colgado y reiniciado varias veces. Ya veremos cuando mi pareja lo utilice habitualmente, miedo me da. Espero que lancen alguna actualización pronto ya que el teléfono me parece sencillamente genial.

A la interfaz le han dado un lavado de cara interesante, han mejorado el sistema de widgets y su gestión en el escritorio, han añadido escritorios virtuales que se desplazan lateralmente (a lo Android), en definitiva, un híbrido entre lo que era Nokia y esas cosas modernas .

Si a todo ello le sumamos el sistema de mapas Ovi, simplemente excepcional y el comedido consumo de batería tenemos un dispositivo a tener muy en cuenta, y es que aquí radica para mi una de las grandes ventajas de Symbian, con Bluetooth, gps y datos activados tienes teléfono para varios días. En Android, para unas horas. Esa es la gran diferencia.

Tras mucho tiempo consumiendo webservices de otros me ha tocado crear mi primer servidor SOAP en PHP y, la verdad, me ha parecido realmente sencillo e intuitivo. Creas una clase con los métodos que vas a exponer en el ws y se crea automáticamente el servicio sobre ellos, tan sencillo como eso.

Con esto se crea automáticamente nuestro webservice con los tres métodos públicos. Pero espera, falta algo, arriba de todo defines un “miclase.wsdl“. ¿Qué es eso? ¿De dónde sale?

En efecto, ese es el principal problema al crear un webservice SOAP con PHP, no se genera el WSDL automáticamente sino que hay que escribirlo ¡a mano!. Para solucionarlo tenemos la librería PHP WSDL Generator a la que únicamente debemos pasarle la clase de la que queremos extraer el WSDL y lo hace por nosotros . Para que todo funciona bien es necesario que los métodos de nuestra clase estén bien documentados tal y como aparecen en el ejemplo anterior, de esta manera WSDL Generator sabrá configurar los tipos de datos de los parámetros de entrada y salida de los métodos.

Veamos un ejemplo:

Este pequeño código nos generará el archivo WSDL de nuestro webservice. Como veis simplemente le indicamos el archivo con nuestra clase (el que escribimos anteriormente), la clase que queremos mapear con la URL del webservice (el endpoint) y, además, le indicamos que ignore el constructor de la clase ya que no será un método de nuestro webservice. Eso es todo.

Si ahora probamos el servicio web, por ejemplo desde el Web Service Explorer de Eclipse:

Tras darle la ruta del wsdl, http://ws.tudominio.com/miclase.php?wsdl, veremos los tres métodos que hemos expuesto y podremos probarlos y utilizarlos.

Nunca había tenido la necesidad de crear un servidor SOAP pero ha sido realmente sencillo. Ahora estoy buscando la manera de devolver tipos de datos complejos, pero eso será en el próximo capítulo .

Finalmente llegó el momento. Tras casi diez años de teléfonos Nokia casi ininterrumpidamente (salvo por un Siemens y un SonyEricsson), los últimos seis con terminales Symbian s60, ha llegado el momento de cambiar y, como no podía ser de otro modo, el destino es un flamante Android, el Google Nexus S fabricado por Samsung y con Android 2.3.

La transición no ha sido complicada, pero pasar todos los datos de tu teléfono anterior al nuevo tiene su miga si no quieres perder nada. Aquí os explico como conseguí tener mi nuevo Nexus al día en un par de horas.

Guía de contactos

Los contactos de un teléfono Android se sincronizan con los de la cuenta de Google asociada al teléfono, los que tengas en tu cuenta de Gmail, así que así es como pasaremos nuestra agenda, copiándola a Gmail.

Desde la guía seleccionamos Opciones->Marcar->Marcar todos y después Opciones->Backup->A la tarjeta de memoria.

Esto nos creará en la tarjeta de memoria la ruta Others/Contacts con los .vcf de todos nuestros contactos. Conectamos ahora el teléfono por usb al ordenador y copiamos esta carpeta en, por ejemplo, c:\. Desde la línea de comandos vamos a c:\Contacts y ejecutamos:

cd c:\contacts
copy /B *.vcf contactos.vcf

Con esto tendremos todos los contactos en un solo archivo y podremos importarlos directamente en Gmail desde Contactos->Más acciones->Importar. Escogemos este archivo “contactos.vcf” y nuestros contactos se añadirán a nuestra cuenta de Gmail y se sincronizarán automáticamente con nuestro teléfono.

Citas y eventos

Para las citas y eventos del calendario, debemos sincronizarlos con Google Calendar. Para ello primero, desde Ovi Suite sincronizamos la agenda con nuestro Outlook y posteriormente nos descargamos Google Calendar Syn que nos permitirá sincronizar nuestro calendario de Google con el de Outlook. Tendremos que introducir nuestra cuenta de Google y el sentido de sincronización que más os convenga.

Automáticamente aparecerá la lista de tareas y eventos en vuestro teléfono. Puedes dejar el programa de sincronización corriendo en tu ordenador y tendrás siempre sincronizados los calendarios de tu teléfono y de Outlook.

Mensajes

Esta parte es un poco más complicada. Yo seguí este procedimiento y me funcionó todo correctamente, en unos minutos tenía mis 800 mensajes en el teléfono nuevo.

Archivos de fotos y vídeos

Esta es la parte más fácil, las fotos, vídeos, música, etc. que tenías en tu teléfono Symbian los copias por USB del viejo al nuevo, no hay más truco.

Tono de llamada

Soy un poco tiquismiquis y llevo en el móvil el mismo tono de llamada desde hace muchos años, Narcotic de Liquido, me gusta porque empieza suave y a los 25 segundos mete caña . Tras copiar el mp3 al nuevo teléfono me di cuenta de que no hay una opción para configurar el tono en las opciones del teléfono, lo que hay que hacer es reproducir el mp3 desde el reproductor de música y en ese momento dar al botón de opciones y escoger Utilizar como tono.

Tono de alarma

Los tonos de alarma se configuran para cada alarma que creemos, no es genérico. El problema está en que por defecto no nos deja escoger más que entre los tonos de alarma que trae predefinidos y aquellos que hemos seleccionado previamente como tono de llamada, así que, la forma más rápida de poner el tono de alarma que queremos es ponerlo primero como tono de llamada desde el reproductor de música tal y como veíamos en el paso anterior, de este modo ya podremos seleccionarlo como tono de alarma.

Tras un par de horas mi nuevo teléfono estaba preparado para utilizar sin echar de menos nada de lo que tenía en el viejo. Eso sí, ahora vienen horas y horas de perder el tiempo toqueteando y jugueteando .

Finalmente ya está disponible la aplicación para Blackberry de mi proyecto Valenbisi para móviles en la tienda oficial, la Blackberry App World. Lo último que os había comentado es que no iba a ser posible ya que RIM exigía un documento firmado ante notario dando fé de que tú, el futuro vendedor, eras quien decías ser y, como os imaginareis, no estaba yo dispuesto a ese gasto , así que la estaba distribuyendo yo mismo directamente a aquellos que entraban desde el navegador de su dispositivo. Se han hecho cerca de cien instalaciones de la aplicación de esta manera lo que me parece que no está nada mal teniendo en cuenta que es el usuario el que te encuentra a tí.

Ahora, sin embargo, todo ha cambiado. RIM ha rectificado su política de autenticidad notarial, me imagino que muchas solicitudes se habrán quedado a mitad de camino sin completar el último paso. El viernes pasado recibí un email donde me indicaban que tenía pendiente completar el último paso pero que ahora ya no era necesario un documento notarial sino que con una copia de un documento oficial, por ejemplo el DNI, sería suficiente. Dicho y hecho, 4 días es lo que costó finalizar el proceso: subir la aplicación, pasar los controles de calidad y que la publiquen. Desde hoy mismo está online. Podéis verla aquí.

Desde una BlackBerry podéis acceder desde el icono de la App World buscando “valenbisi“:

Y este es el resultado:

A ver si tiene un éxito parecido al de la versión Android que lleva ya ¡más de mil descargas!.

Puede parecer sencillo, pero si intentas actualizar siguiendo el procedimiento oficial verás que no funciona. La documentación indica que sólo es necesario añadir el nuevo sitio de Helios, pero no, no es suficiente, surgen errores de dependencias no resueltas.

Solucionarlo es sencillo si sabes cómo. Desde Window->Preferences seleccionamos Install/Update->Available Software Sites y a la derecha veremos la lista de repositorios de software de nuestra instalación. Además de añadir el nuevo de Helios (http://download.eclipse.org/releases/helios) debemos añadir también el sitio de actualización de la nueva versión modificando “3.5″ por “3.6″ en el repositorio de “update” de Galileo. La siguiente imagen aclarará un poco más el cambio.

Con esos dos cambios pude actualizar correctamente dos instalaciones distintas de Eclipse, solo tuve un problema. En una de ellas tuve que desinstalar primero los plugins de BlackBerry ya que decía que no eran compatibles con Helios y tampoco me los actualizaba a la nueva versión. Una vez actualizado Eclipse los instalé de nuevo sin problemas.

Espero que os sirva de ayuda…

Es la moda , y con este comentario no quiero decir que no sea una buena idea.

La explicación es sencilla. Solemos utilizar Apache para servir cualquier tipo de contenido a través de una petición HTTP, pero en Apache cargamos habitualmente muchos módulos necesarios para que nuestras aplicaciones funcionen correctamente, empezando por el mismísimo PHP, pero que no necesitamos para servir contenidos estáticos (imágenes, archivos css o javascript, archivos comprimidos…). Si pudiésemos separar de una manera sencilla las peticiones de estáticos de las de dinámicos podríamos redirigirlas a distintos servicios y conseguiríamos que las estáticas consumiesen muchos menos recursos ya que las podríamos hacer con un servidor mucho más ligero que Apache. ¡Podemos!

Este sería el escenario tradicional de un servidor web:

Las solicitudes HTTP llegan al servidor web desde Internet y éste lee los archivos en disco necesarios para servirla. Nada nuevo.

Este es el escenario al que queremos migrar:

Todas las peticiones HTTP son recibidas en el puerto 80 por un servidor mucho más ligero que Apache (nginx, lighttpd) que se encarga de servir directamente los contenidos estáticos desde el disco y de redirigir las solicitudes dinámicas al Apache de siempre que ahora escucha en el puerto 8080, es decir, el servidor ligero actúa como proxy para las peticiones de contenidos dinámicos.

Para el caso que nos ocupa, el servidor a migrar tiene varios virtual hosts definidos de distintos sites y se pretendía dejar los que tienen poco tráfico tal y como están ahora, es decir, que Apache lo sirva todo, y cambiar sólo aquellos donde el tráfico es elevado para que Nginx sirva los estáticos.

El primer paso es, por tanto, instalar y configurar Nginx para que actúe como proxy completo. Deberemos modificar también Apache para que deje de escuchar en el puerto 80. Empecemos por esto último.

Tendremos que cambiar el fichero de configuración httpd.conf para que escuche en el nuevo puerto, en mi caso el 8080. Cambiaremos la línea correspondiente para que quede así:

Listen 8080

Pero esto no es todo. Tenemos que modificar también los virtual hosts definidos para que escuchen en el nuevo puerto. Al final del mismo archivo cambiaremos la línea correspondiente por esta (la tuya será similar, quizás en vez del asterisco tenga la ip de tu máquina):

NameVirtualHost *:8080

En mi Centos5 la configuración de los virtual hosts se guarda en /etc/httpd/httpd.d. Desde ahí lanzamos este comando que nos los actualizará todos de un tirón:

for i in `dir .`; do sed -i s/*:80/*:8080/g $i; echo  $i; done

Menos mal, sino habría que cambiarlos a mano uno por uno .

Ahora instalamos nginx:

yum install nginx

y hacemos la primera configuración que nos permitirá, de momento, que sea proxy completo de Apache, es decir, que lo redirija todo a Apache.

Creamos el archivo /etc/nginx/proxy.conf

resolver 127.0.0.1;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 128m;
client_body_buffer_size 256k;
proxy_connect_timeout 60;
proxy_send_timeout 60;
proxy_read_timeout 60;
proxy_buffer_size 32k;
proxy_buffers 32 256k;
proxy_busy_buffers_size 512k;
proxy_temp_file_write_size 512k;

La primera línea será la ip del servidor DNS.

Ahora añadiremos a la configuración de nginx lo siguiente dentro del “server” por defecto.

/etc/nginx/nginx.conf

server{
	listen       80;
	location / {
		proxy_pass http://$host:8080;
		include /etc/nginx/proxy.conf;
}

El primer paso debería estar terminado. Levantamos los servicios de Apache y nginx y probamos a navegar por los virtual hosts del servidor. Si todo ha ido bien debería funcionar correctamente, pero si analizamos las cabeceras que se reciben en la respuesta, por ejemplo con el plugin livehttpheaders de Firefox, veremos como añade la siguiente línea a todas las solicitudes:

Server: nginx/0.8.53

Prueba 1 superada. Vamos ahora a configurar determinados virtual hosts para que el contenido estático lo sirva nginx.

/etc/nginx/conf.d/virtual.conf

server {
	listen  80;
	server_name www.tudominio.com;
	location ~* ^.+\.(jpg|js|jpeg|png|ico|gif|txt|js|css|swf|zip|rar|avi|exe|mpg|mp3|wav|mpeg|asf|wmv|flv)$ {
		root /var/httpd/www.tudominio.com;
		expires 30d;
	}
	location / {
		proxy_pass http://www.tudominio.com:8080;
		include /etc/nginx/proxy.conf;
	}
}

Con esto le decimos que todos los archivos estáticos los sirva nginx directamente y que las demás peticiones las redirija a Apache. Debemos crear un “server” por cada virtual host que queramos configurar de esta manera. Básicamente lo que hacemos es configurar la misma ruta en disco para los archivos estáticos que la que teníamos en Apache, de esta manera no tendremos que cambiar absolutamente nada. En muchos sitios proponen crear un host static.tudominio.com, pero esto implicaría modificar físicamente todas tus aplicaciones web, y eso no es lo que se pretende .

Sólo nos queda reiniciar nginx. ¿Cómo sabemos si funciona? Sencillo, revisando los logs de Apache y nginx. Si lo hacemos veremos cómo este último sirve los archivos estáticos y Apache todos los demás .

Finalmente tendremos un pequeño problema. Desde Apache se verán todas las solicitudes HTTP como si vinieran de la propia máquina ya que, en efecto, vienen de nosotros mismos a través del proxy. Esto puede ser un problema para analizadores de tráfico pero también si tienes algún sistema que controla las ip’s de los usuarios. Para solucionarlo tenemos mod_rpaf para Apache (reverse proxy add forward module) que nos reemplazará las cabeceras adecuadamente de manera que la IP remota que veamos sea la de nuestro cliente. Lo descargamos, lo instalamos y lo configuramos:

/etc/httpd/conf.d/rpaf.conf

LoadModule rpaf_module modules/mod_rpaf-2.0.so
RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1
RPAFheader X-Forwarded-For

Con esto conseguiremos que se reemplace la IP del cliente que se recibe en Apache con la que viene en la cabecera “X-Forwarded-For” que es donde nginx nos deja la original.

Eso es todo. Si reiniciamos el servidor Apache veremos que en los logs comenzará a verse la IP real del usuario y no la de nuestra máquina local.

Como siempre, un último detalle. Integremos nginx con Cacti para hacer un seguimiento .

Las plantillas están aquí, pero a mi no me funcionaron bien, las cambié un poco por estas otras.

Añadimos en la configuración inicial de nginx las siguientes líneas:

location /nginx_status {
	stub_status on;
	access_log   off;
	allow IP_DE_TU_SERVIDOR_CACTI;
	deny all;
}

Con esto podrás acceder al estado del servidor nginx desde http://IP_DE_TU_SERVIDOR/nginx_status.

Dentro del zip hay cuatro archivos, dos scripts perl que debes copiar en el directorio scripts de tu instalación de cacti y dos xml que debes importar desde la propia herramienta. Ya está todo preparado. Desde la configuración de cacti del servidor donde has instalado nginx añades las nueves fuentes de datos y los gráficos. Al configurarlo te pedirá la url de acceso que veíamos hace un momento.

Y hasta aquí hemos llegado. En muy poco tiempo hemos conseguido modificar toda la estructura de nuestro sistema web sin pérdida de disponibilidad y, lo mejor de todo, hemos creado un sistema mucho más eficiente y robusto. En condiciones de tráfico medio no notarás mucha diferencia de rendimiento, pero tendrás un sistema mucho más preparado para hacer frente a picos y efectos “barrapunto” .

Finalizo con éste la serie de artículos sobre el último miniproyecto en el que me embarqué hace ahora un mes, Valenbisi para dispositivos móviles.

Tras un par de semanas con las aplicaciones para los principales sistemas operativos para smartphones a pleno rendimiento (excepto iOS), parece que hay mucha más gente con buenos cacharros de lo que yo esperaba, teniendo en cuenta además que es una aplicación enfocada a una zona geográfica muy concreta.

Os comento además que, aprovechando la infraestructura que ya tenia montada y viendo que el proveedor del servicio es el mismo, decidí replicar el sistema para las bicis urbanas de Sevilla, información del estado de las estaciones de Sevici, acompañado también de su aplicación para Android.

Aquí van las estadísticas de descarga de las aplicaciones desde Android Market:

No está nada mal, sobre todo teniendo en cuenta que la de Sevici no la anuncié en ningún sitio . Los números de la de Valencia me parecen espectaculares, desde luego ya hay mucha gente por ahí con un Android.

Y aquí las estadísticas para la aplicación para Symbian desde Ovi Store:

Éstas son, sin duda, más complicadas, parece que en la India se usa mucho Symbian . Aún así se nota que hay descargas.

Finalmente nos queda Blackberry. Tengo aplicaciones para OS4 y OS5, pero esta vez sin presencia en App World ya que me solicitaban firmas de notario, así que directamente pasé de ellos , la distribuyo directamente desde Valenbisi.mobi y que se la descargue quien quiera. De hecho, cada vez que entras, si tu terminal es compatible con alguna de las aplicaciones disponibles, te ofrece la posibilidad de descargar la aplicación. Se han hecho aproximadamente unas 20 descargas de la aplicación para BlackBerry, teniendo en cuenta que la visibilidad así es mucho menor que desde la tienda de aplicaciones, me parece un buen número .

Finalmente tenemos las estadísticas globales de visitas al sitio web, contando tanto los que entran desde aplicaciones como los que entran directamente.

Me parecen muy buenos datos para una aplicación completamente local. Llama la atención el pico de visitas del 8 de diciembre, pero tiene sentido ya que, además de día festivo, hizo un día espectacular con 23º de temperatura, importante para ir en bici . Seguro que a medida que vaya mejorando el tiempo se notará el incremento de uso. Pese a que sólo oímos hablar de iPhone’s y Android’s, fijaos en la sorprendente relación de sistemas más utilizados. Aunque Android pega fuerte, Nokia sigue siendo lo más utilizado, un dato importante a tener en cuenta en cualquier aplicación para móviles que desarrollemos.

Con esto abandono el desarrollo . La aplicación está terminada, funciona bien y parece ser por los comentarios que es fiable. Espero no tener que hacer mucho mantenimiento , me aburre bastante .