Nexus 7 2012, una tableta traviesa…

Nunca he sido demasiado amante de las tablets, bastante que me costó dar el paso a tener un Smartphone, sin embargo, he de decir que tuve la oportunidad de comprar un Nexus 7 del 2012 cuando vivía en Londres a un precio ridículo.

La tableta ha ido de maravilla desde que la compré, sin embargo hace no demasiado (finales de 2014), llegó una «dichosa» actualización que me ha llevado de cabeza hasta el fin de semana pasado: Android 5.0. Cuando apareció en la pantalla el mensajito de que podía actualizar a dicha versión fácilmente, y teniendo en cuenta que Google esta detrás de los dispositivos Nexus, confié casi con los ojos cerrados en que valía la pena actualizar. Ya había leído en algunas páginas lo que traería la nueva versión y la verdad, todo parecía que eran más ventajas que inconvenientes. ¡Ay pobre de mí que incumplí la máxima de todo informático!! Si funciona bien, ¿para que lo tocas? En fin, tras dicha actualización todo era mas bonito, mas vistoso, pero por otro lado todo iba muuuuuuuuuuuuuuy lento, extremadamente lento, casi que me recordaba al mismo problema que tuve con el iPhone 4 cuando se me ocurrió actualizarlo a 7.0 sin esperar la posterior version «arreglatodo». Las transiciones de pantalla iban a trompicones, abrir el Chrome era como ir a hacer la cola del supermercado.. vamos, un desastre.

Tras pillar un cabreo monumental, como no, tocó «googlear» a ver que demonios estaba pasando y, para mi sorpresa vi bastantes posts de gente quejándose de lo mismo. ¡Bieeen! ¡¡No estoy solo!! Pero, ¿hay solución? En teoría la había, a medias. Lei de todo, que si borrar la partición de la caché de la tableta, desactivar «no se qué», y así un larguísimo etcétera que a final de cuentas nunca llego a cuajar del todo. A los pocos días Google salio a la palestra afirmando que efectivamente había un fallo, y que, como no, se corregiría lo antes posible, y cierto fue que sacaron una versión prácticamente a las pocas semanas que, rápidamente me aventure a instalar, para ver si corregía «el fallito» de las narices. Mis primeras impresiones fueron que la tableta iba mejor, pero a años luz de lo que era cuando usaba KitKat, mas conocido como Android 4.4.. ¡ay! ¡cómo echaba yo de menos mi antigua versión! Viendo lo visto dejé casi de usar la tableta, porque me tocaba en gran medida las narices que para cualquier cosa que tuviera que hacer tuviera que aguantar parones y un sinfín de etcéteras de esos que a un usuario normal de este tipo de dispositivos no les gusta lo mas mínimo.

Un día como otro cualquiera se me ocurrió encender de nuevo la tableta y… ¡¡oh sorpresa!! ¿¿otra actualización?? Yo pensaba para mi mismo, ¿tendrá esta el puñetero fallo arreglado? Por probar no iba a perder nada, total, la tableta era ya casi inservible. Para mi sorpresa el rendimiento general mejoró.. ¡y mucho! ¡¡pero mucho!! Guau, ahora sí que esto empieza a ser usable, y digo empieza porque no llegaba ni en pintura a ser como en la versión anterior, pero por lo menos podía ya de nuevo llevarme mi cacharrito al tren para hacer mi viaje diario lo mas ameno posible.

El caso es que ayer, en ese mismo viaje matutino con la tableta me doy cuenta que cuando abro el Chrome, otra vez empieza a ir todo lento, de hecho en una de estas un cuelgue del Chrome provocó que la tableta se reiniciara completamente. ¿Pero que demonios? Hasta aquí hemos llegado, me dije para mi mismo. Esta misma noche hago un «downgrade» y vuelvo a poner la versión anterior. Cuando llegue a casa, ni corto ni perezoso, me dispongo a buscar la imagen de la version 4.4 en la pagina de desarrollo de Google, junto con las aplicaciones necesarias para «hablar» con la tableta desde el ordenador y poder reinstalar todo a mi gusto, sin embargo en ese momento algo se me paso por la cabeza: «¿De verdad que Google va a cometer el mismo error que Apple con los iPhone? Me parecía todo demasiado raro, porque, si realmente no fuera bien con este modelo, ¿para que iba a dejarme actualizar?». En ese momento pensé, total, un ultimo intento solo me costará una media hora de pruebas. Lo que hice fue, por un lado, borrar la partición de caché, tal y como hice en su día, pero lo siguiente fue poner la tableta en modo por defecto: vamos, lo que viene a ser en modo de fabrica, pero usando la imagen que tenia ya instalada: Android 5.1. Tras la correspondiente media horita más o menos de trasteo poniendo todo de nuevo…. ¡¡¡oooh sorpresa!!! Pero, ¿¿de verdad es mi tablet?? Todo, todo, todo absolutamente todo suave. Chrome ya no se cuelga, aplicaciones que antes daban trompicones ahora se mueven suavemente cuando desplazo los contenidos.

Llegados a este punto, de momento, tengo la siguiente impresión: Si tienes una Nexus 7 2012 y quieres actualizar a Android 5.1 (ni se te ocurra actualizar a 5.0!!!), puedes hacerlo, pero tras ello, mejor borra todo y ponlo todo en estado de fabrica. La experiencia de usuario sera como tenia que ser desde el principio.

 

Rememorando Amiga Dreams

NOTA: Estoy escribiendo este articulo en un teclado Suizo, por lo tanto es posible que falten acentos, etc etc… juro no dejar en el tintero ninguna EÑE.

 

Hace exactamente 20 años mi querido amigo Javier Jiménez (Entonces conocido como Cyco-Ozzy) y yo nos pegamos un veranito en Malaga haciendo lo que hasta la fecha creo que ha sido la creacion, informaticamente hablando, que mas tiempo, dedicacion y cariño he puesto nunca. Eran tiempos muy diferentes a los de hoy en dia. Internet no existia, los modems eran para «pijos» que podian costearse las barbaridades que costaban las llamadas de datos de aquel entonces, y la manera mas efectiva de comunicarse para conseguir cosas era usando «la carta de toda la vida». En esos años quedaron mis experiencias dentro de algo que fue, y que incluso hoy en dia sigue siendo, muy, pero muy grande: LA ESCENA.

La verdad es que no tengo demasiado tiempo de escribir que fue LA ESCENA (asi, en MAYUSCULAS), pero basicamente era una comunidad, bastante «underground», en las que el objetivo basico era ser el mejor y deleitar al resto de la comunidad con tus creaciones. Habian grupos impresionantes, con producciones alucinantes que exprimian al maximo la tecnologia de la epoca y que dejarian a la altura de la …. ejem…. a muchas producciones de hoy en dia en cuanto a dedicacion y forma de trabajar. En fin, en aquellos años el Señor Jimenez y yo fundamos un grupo llamado «Suicidal Tendencies», en honor al mismo grupo de musica heavy. Bajo ese sello editamos una «revista digital» que venia en formato de diskette para ordenadores Amiga, si si.. esos que Commodore saco a finales de los años 80 y que en España fueron un autentico BOOM durante los años 1990 a 1993. Javier, que era un autentico maquina del diseño ya en esa epoca se dedico a trabajar toda la parte visual, mientras un servidor se encargo de programar todo el engendro. Conseguimos meterlo todo en dos diskettes tras un mes de trabajo en Malaga durante el verano del 95 y la cosa no quedo ahi, ya que conseguimos editar unos cuantos numeros mas.

Curiosamente el motivo de este articulo no es en si explicar lo que fue Amiga Dreams, la revista en cuestion, sino como conseguir verla de nuevo en los ordenadores de nuestros dias de una forma facil y muy muy sencilla. Por que digo esto? Facil, porque los emuladores de Amiga a veces son bastante complicadillos de utilizar, sin embargo, la opcion que propongo unicamente requiere que tengais un navegador Google Chrome instalado en vuestro ordenador y haber descargado unos pocos archivos. En fin, no se hable mas… los pasos a seguir son:

– Descargar un Kickstart de Amiga. Para el Amiga 500 estandard vale cualquiera con version 1.3. Lo podeis descargar del siguiente enlace: KICKSTART 1.3

– Descargar los dos diskettes del numero 6 (el primero serio que sacamos) DISCO 1DISCO 2

– Ir a la siguiente pagina web, que contiene el emulador de Amiga para Chrome: https://pnacl-amiga-emulator.appspot.com/

Una vez en dicha pagina hay que hacer lo siguiente para emular el Amiga y poder ver la revista:

– Abajo a la derecha pinchad sobre «Advanced Options» y a continuacion pulsad sobre el boton «Choose File». Elegid el archivo del KICKSTART 1.3 que habeis descargado.

– Paso siguiente: A la izquierda justo al lado de DRIVE 0 pinchad sobre CHOOSE FILE y elegid el archivo DISCO 1 de la revista. Cuando la revista os pida el DISCO 2, tendreis que pulsar sobre este boton y elegir el otro archivo descargado.

Nada mas!!! Resetear el emulador con el Boton RESET AMIGA y a disfrutar de los viejos tiempos!

ad6

Securing Apache and PHP in Ubuntu

Many of us know that Linux is a very secure system and Ubuntu is nowadays one of the most chosen options by many system administrators, however, a basic installation is not always perfect and we need to «touch things» in order to make it as good as possible.

The problem in Linux, specially in version 12.04, is that a basic installation of Apache 2 and PHP leaves a lot of clues about what we are actually using, so the ideal scenario would be to hide such information to avoid as much as possible an external attack because we have provided, for example, the PHP version that the system is using. Image that, for some reason, tomorrow somebody discovers a lack of security in our PHP version and we are announcing widely in the server’s headers that this version is the one we use. This could potentially be used by hackers in order to attack our systems.

As an example of this just use the following command agains the IP address of a plan Ubuntu installation with just Apache and PHP:

curl -X https://direcciondelservidor

you would probably get something like this:

Date: Fri, 19 Sep 2014 13:09:20 GMT

Server: Apache/2.2.22 (Ubuntu)
X-Powered-By: PHP/5.3.10-1ubuntu3.11

Obviously we are giving «too much» information to any possible attacker so what we need to do is to remove it. To do that we need to do the following steps:

Edit the file /etc/php5/apache2/php.ini and add or modify the following lines:

disable_functions = exec,system,shell_exec,passthru
register_globals = Off
expose_php = Off
display_errors = Off
track_errors = Off
html_errors = Off
magic_quotes_gpc = Off

Following that edit the file /etc/php5/apache2/conf.d/security and do the same operation but with the following lines:

ServerTokens Prod
ServerSignature Off
TraceEnable Off
Header unset ETag
FileETag None

Finally we need to edit the Apache config file where you have defined your website. If you have not changed the default one then it should be /etc/apache2/sites-available/default, and as before we need to add/edit some lines. These ones need to go where you have defined your VirtualHost block:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} !^(GET|POST|HEAD)
RewriteRule .* – [R=405,L]

These lines require to have the Apache’s module mod_rewrite activated, so in order to make sure it is being used, execute the following command:

sudo a2enmod rewrite

And finally…

sudo service apache2 restart

If everything went fine we can execute again the curl command against our server and we will see something similar to this:

Date: Fri, 19 Sep 2014 13:17:29 GMT
Server: Apache
X-Frame-Options: SAMEORIGIN

Much better now, isn’t it?

 

Fixing Shellshock vulnerability in Ubuntu

These days we have heard about the Shellshock vulnerability that affects to many unix based OSs. Well, of course Linux is among them so it’s affected.

The first step is to check if you Linux (Ubuntu) version is affected, so in order to make a quick test open a terminal and run thefollowing commands (3 in total):

1)

env X='() { :;}; echo' /bin/cat /etc/passwd; echo 'Welcome to he Simple ShellShock Tester By Svieg';echo 'Your infos are at risk';

2)

env x='() { :;}; echo Your system is vulnerable update ASAP' bash -c "echo Visit svieg.wordpress.com for update info"
3)

env X='() { (a)=>\' bash -c "echo date"

If for some reason any of the commands return the text saying that the computer is vulnerable or in the 3rd one you get the date instead of an error message, then your computer is in risk.

Ubuntu has fixed the problem the 25th of September, so expect fixing the problem with the typical:

sudo apt-get update; apt-get upgrade

Asegurando Apache y PHP en Ubuntu

Muchos en este mundillo sabemos que Linux es un sistema operativo muy seguro y que Ubuntu es cada vez más la opción elegida por muchísimos administradores de sistemas, sin embargo, como todo, una instalación básica no es siempre perfecta y hay que tocar «cosillas» para que sea lo más perfecta posible.

El problema que tiene Ubuntu, especialmente la versión 12.04, es que una instalación básica de Apache 2 y PHP deja bastante rastro de lo que estamos utilizando y lo ideal sería ocultar dicha información para evitar lo máximo que podamos un posible ataque externo. Como ejemplo de ello ejecutad el siguiente comando sobre cualquier servidor que hayáis montado:

curl -X https://direcciondelservidor

y seguramente obtendréis algo similar a esto:

Date: Fri, 19 Sep 2014 13:09:20 GMT
Server: Apache/2.2.22 (Ubuntu)
X-Powered-By: PHP/5.3.10-1ubuntu3.11

Evidentemente estamos dando «demasiada» información a cualquier posible atacante así que lo suyo es eliminarla, para ello hay que realizar lo siguiente:

Editar el archivo /etc/php5/apache2/php.ini y añadir o editar las siguientes lineas:

disable_functions = exec,system,shell_exec,passthru
register_globals = Off
expose_php = Off
display_errors = Off
track_errors = Off
html_errors = Off
magic_quotes_gpc = Off

A continuación editad el fichero /etc/php5/apache2/conf.d/security y realizad la misma operación pero con las siguientes líneas:

ServerTokens Prod
ServerSignature Off
TraceEnable Off
Header unset ETag
FileETag None

Finalmente hay que editar el archivo donde hayáis configurado vuestra página de apache. Si no habéis cambiado el archivo en cuestión debería de ser /etc/apache2/sites-available/default y añadir las siguientes líneas dentro del bloque

RewriteEngine On
RewriteCond %{REQUEST_METHOD} !^(GET|POST|HEAD)
RewriteRule .* – [R=405,L]

Estas lineas requieren del módulo mod_rewrite de Apache, así que hay que asegurarse que esté activado con el comando

sudo a2enmod rewrite

Y finalmente…

sudo service apache2 restart

Si todo ha ido bien y ejecutamos de nuevo el comando Curl sobre nuestro servidor veremos algo parecido a lo siguiente:

Date: Fri, 19 Sep 2014 13:17:29 GMT
Server: Apache
X-Frame-Options: SAMEORIGIN

Mucho mejor ahora, ¿verdad?

iPhone, MP4 y HTTPS … ¡dolor de cabeza!

En mi último proyecto en el que he estado colaborando he tenido que poner unos cuantos (¡¡muchos!!) videos en MP4 para ser reproducidos desde la web usando streaming. Después de muchas peleas, y ya sé que hay mejores opciones, me decanté por usar Video.js como reproductor ya que necesitaba que «algo» los reprodujera en cualquier navegador, incluso en los vetustos Internet Explorer 8 (Cosas del cliente!!) y no me quedó otro remedio..

En fin, que llegó la hora de lanzar el proyecto, todos tan contentos y de repente comprobamos que algunos videos no funcionan bien en móviles.. en fin, cosas del formato. Tras recodificar los videos que fallaban y ver que todo iba a la perfección alguien grita de forma casi agónica diciendo «No funciona en mi iphone!!!». En ese momento se te queda la típica cara de imbécil y miras al «amigo» como si fuera el aguafiestas del siglo y lo primero que se te pasa por la cabeza es que o ha puesto mal la dirección o que algo mal está haciendo. Pues no, por una vez en la vida el «amigo» estaba accediendo a la dirección correcta, el video estaba bien codificado y el puñetero iPhone de las narices se negaba a reproducir el video, sacando una bonita X en medio de la ventana del reproductor.

Tras pegarme una mañana entera peleándome con el dichoso video y viendo que no iba «ni pa tras» se me ocurre la genial idea de probar los videos en otra máquina y acceder desde el móvil a ella y …. ¡oh sorpresa! ¡Funciona! Pero… pero… ¿qué diferencia hay? Pues, sencillo, nuestra máquina en producción usaba HTTPS (conexión segura) y la de prueba no. Pues sí, ese era el problema, tan sencillo como eso.

La historia es que el certificado que nos habían suministrado no contenía el «bundle» del proveedor o agente registrador. En teoría esto no es necesario para hacer funcionar un sitio web con https, pero se ve que al amigo «iphone» no le gusta la idea. Tras «investigar» un poco consigo ponerme en contacto con el proveedor que había generado el certificado y me mandan su bundle, lo instalo en nuestro servidor y,….. siiiiii…. funcionan… bueno a medias… Funcionan bien, solo que mi «pequeño» iPhone 4 no abre ningún video que esté a más resolución de 640 pixels de ancho, pero eso ya, obviamente, es otra historia.

 

Digan lo que digan, GIT es el mejor

Para los que se hayan dedicado desde hace mucho al desarrollo, conocerán, casi que seguro algún sistema de control de código fuente (Source Code Version System) y seguramente habrán preferencias al respecto, sin embargo desde hace cosa de un par de añitos vemos que poco a poco GIT se va imponiendo entre el tipo de repositorios de código fuente más habituales. Páginas como GitHub o Bitbucket hacen casi uso exclusivo de este tipo de repositorios para distribuir código fuente, amén de los fuentes de Linux que también lo usan, pero ¿por qué?…

Echemos una ojeada a la historia de GIT. Git fue creado por nada menos que el mismísimo Linus Torvalds, papaito del sistema operativo Linux. Al parecer, Linus estaba bastante harto de cómo funcionaban los repositorios que tenía que utilizar, por ejemplo SVN (proyecto libre de Apache Foundation) y decidió hacer uno por su cuenta, pero con ligeros detalles que lo harían diferente del resto.

  • Los repositorios sin distribuídos. Esto significa que en teoría no hace falta tener un servidor centralizado para distribuir los repositorios, aunque se puede, de hecho uno mismo puede crearse uno en su ordenador y no tener que distribuirlo, pero que de cualquier manera, se puede usar para controlar las versiones de un proyecto.
  • Acepta muchos tipos de conexión para distribuir las versiones, como SSH, HTTP, etc. por lo tanto es muy adaptable.
  • Está pensado en ser muy rápido por lo que es ideal para trabajar con muchos ficheros (doy fe!!!).
  • Si alguien necesita trabajar con SVN pero quiere seguir usando GIT puede usar git-svn para ello.

Y todo esto muy bien pero, ¿por qué está siendo muy popular? Entre otras cosas la culpa lo tiene el fuerte apoyo de la comunidad de usuarios Linux. Al adoptar este tipo de repositorio ha incrementado la popularidad de git y el interés general sobre él. La facilidad de uso, fácil integración en cualquier entorno y la cantidad de clientes para añadir una interfaz de usuario usando ventanas (GUI) hacen que se adapte a cualquier entorno o sistema operativo, aunque siempre quedarán los puristas, como un servidor, que adoran el uso de la línea de comandos.

En resumen, si sois desarrolladores, tenéis acceso al servidor donde almacenáis los repositorios y estáis un poco hartos de SVN o similares, echad una ojeada a GIT. No os defraudará.

 

XBMC, ¡por fin un Media Center que funciona!

Si hay algo que definitivamente llevo años y años buscando es un media center para ordenador que me permitiera coger «una maquinita cualquiera», enchufarla a la tele y tener todo lo uno realmente quiere tener en una TV sin tenerse que mover de su sofá. Cuando digo «TODO» me refiero a, todas las películas que tengas en tu disco duro (amén de series!!), posibilidad de reproducir DVDs/BluRays y como no, acceso total a Internet incluyendo canales y streamings online…

Pues sí, existe y se llama XBMC (https://xbmc.org/).

Esta «pequeña» maravilla es un proyecto OpenSource, vamos, más gratis y libre imposible. Lo puedes descargar, e incluso modificar a tu antojo si tus conocimientos son lo suficientemente avanzados para ello (Te hará falta saber algo de Python), pero lo que le hace sobretodo potente es que al ser OpenSource hay cientos de plugins que hace que se pueda ver o hacer prácticamente de todo en el MediaCenter, desde ver canales «online» tipo TVE, Tele5, Antena 3, etc… hasta incluso gente que se curra sus propios repositorios de canales que se actualizan online y que permiten ver TV de cualquier parte del mundo.

Ya la gota que ha colmado el vaso de mi expectación ha sido cuando he descargado la aplicación para móviles (iOS o Android) que permite convertir tu móvil en un mando a distancia!!!! Resulta que si ambos media center y móvil están en la misma red es posible controlar el media center desde tu móvil sin moverte del sofá.

De todos es sabido que vivo en Londres y gracias a esta pequeña obra maestra vuelvo a ser capaz de hacer «Zapping» de canales españoles sin moverme del sofá! ¿Merece o no merece la pena? Lo único que necesitareis es un ordenador y a ser posible que se pueda conectar a una TV para disfrutar de todo su esplendor, el resto y los contenidos los ponéis vosotros.

Ya hago hasta apps para móviles

Pues si faltaban cosas por hacer en mi vida ahora tengo otra nueva diversión, hacer aplicaciones para móviles.

Toda esta historia empezó cuando en mis primeros meses de trabajo en Hogarth Worldwide descubrí casi por accidente el entorno de desarrollo para apps móviles Phonegap. PhoneGap aseguraba que mediante únicamente código HTML, CSS y JavaScript era posible crear una app móvil que era capaz de funcionar en cualquier teléfono del mercado, ya fuera iOS, Android, Blackberry, etc; es decir, no hacía falta aprender Objective-C para iOS o Java para Android. Le estuve echando una ojeada con el fin de que en un futuro, medianamente próximo pudiera hacer algo en concreto ya que por aquel entonces tenía tiempo de sobra y no iba demasiado estresado en el trabajo. Pobre de mí, pensaba que ese nivel de «poco estrés» iba a durar poco y por motivos de falta de tiempo olvidé Phonegap por unos meses.

Unos cuantos meses más tarde tuvimos que hacer una especie de webapp para una empresa de reconocido prestigio (lo siento, esto es un blog, no puedo dar nombres) y a alguien se le ocurrió la genial idea de decir: «¡sería la caña que pudiéramos convertir esto en una app para móviles con su icono y que no se viera el navegador!» y en seguida recordé aquello que había visto hace unos meses… PhoneGap!! Dicho y hecho procedí a intentar descargar la última versión y…¿qué ha pasado? me encuentro que el proyecto PhoneGap es ahora de Adobe. Que en teoria funciona todo igual, pero hay que pasar por el aro de Adobe para algunas cosas. Yo, como chico amante del software libre, recordaba que el primer phonegap que vi era totalmente libre y opensource. Cual fue mi sorpresa enorme cuando descubro que al margen de PhoneGap existe «Cordova». Cordova… ¿con V? Pues sí, a mi me pareció de lo más insólito, aunque investigando he descubierto que hay un lugar llamado así en Filipinas, a saber si le han puesto el nombre en honor a dicho lugar. Volviendo a Cordova; es lo mismo que phonegap, pero, desarrollado de manera OpenSource por Apache Foundation. A partir de Cordova se realiza Phonegap por parte de Adobe, lo cual no deja claro si PhoneGap es un fork comercial de Cordova o es simplemente una versión que pagando se puede obtener soporte. En fin, que a fin de cuentas ambos son completamente compatibles, por lo que queda a gusto del consumidor elegir cuál es la más apropiada. Yo como ya he dicho antes, me he decantado por Cordova para evitar tener que pasar por el aro de cualquier empresa.

Mis primeros pinitos con Cordova no estuvieron mal. Conseguí compilar la webapp que habíamos hecho en la oficina e instalarla en un iPad. ¡¡Impresionante!! Teníamos un bonito icono y una webapp hecha a partir de código HTML y JavaScript. Pero… ¿esto es lícito? ¿Cómo es posible que funcione? Pues sí, sí que funcionaba. Pero PhoneGap/Cordova no solo se limita a hackear de alguna manera el teléfono para hacer una app desde una página web, te permite, mediante un API propio acceder a cosas internas del teléfono como la cámara, contactos, gps, etc, y es ahí donde entra la potencia de utilizar este framework. Con esta API se podría llamar a Google Maps y posicionarnos en una App de búsqueda, por ejemplo de restaurantes, donde el código es puro HTML+JavaScript, portarla a 3 sistemas y andando. Brutal, ¿verdad?

Con todo este nivel de emoción en mi cuerpo no dudé que tenía que desarrollar algo, pero, ¿el qué? Tenía que ser algo que fuera útil y que me permitiera aprender mucho en poco tiempo y mi querido ex compañero de trabajo James Miller (@jimhunty) me dio la idea. Estaba desarrollando apps móviles para equipos de divisiones inferiores de la liga inglesa de fútbol. Les eché una ojeada pero no me terminaban de convencer para la liga española así que me dije a mi mismo: «Voy a hacer una app para la UD Almería pero a mi manera», y así empezó el proyecto. El problema de todo esto ha sido que se ha demorado por más de 9 meses, ¡¡¡ni que hubiera sido un embarazo!!! ya que tenía muy poco tiempo libre para dedicarle a la app.

En navidad aproximadamente tenía una beta medio funcionando tras 3 o 4 versiones completamente diferentes, en las que había cambiado prácticamente todo. Desde la forma de mostrar y recibir noticias a la apariencia visual. Recordemos que yo en el fondo soy sysadmin y de diseño sé bien poco, pero bueno, poco a poco y sin prisa.

Con todo esto llegamos hasta abril, semana de Easter (Semana Santa en España) y me encuentro que tengo tiempo más que suficiente para acabar la app y dicho y hecho. Tras dos días prácticamente enteros volcados en la App consigo acabarla, y tras probarla intensivamente en dos teléfonos y una tableta que tengo en casa decido que debe ver la luz. Pago religiosamente las cuotas de Google y Apple y me propongo subirlas a las tiendas de apps de las dos respectivas marcas, eso sí, sin saber el quebradero de cabeza que ello conlleva. Lo primero de todo es soltar pasta para algo que teóricamente iba a ser gratis. Google te pide $25, lo cual no está mal porque lo pagas una vez y ya está. Para mí eso son £16, lo cual es poca cosa, pero el problema es de los señores de Apple. £60 ($99) de golpe y encima anual, por no hablar de lo complicadisimo que es mandar una App a la AppleStore. Hay que pasar por mil cosas, rellenar formularios, pasar hasta por un proceso similar al fiscal, poco más que diciéndote que si haces algo ilegal vas derecho a la cárcel, en fin, una paranoya que no ocurrió para nada a la hora de subir la app a PlayStore de Google. En PlayStore solo tuve que darme de alta, pagar, preparar la App, firmarla digitalmente y subirla. Me costó un poco, pero vamos, en cuestión de dos horas la app estaba subida. En el caso de Apple, paga, pero paga hasta para probar la App en un teléfono; si no, es imposible, por no hablar del lío de certificados que hay que instalar, mandar, volver a descargar, etc y que hace falta un Mac sí o sí para desarrollar para iOS. En resumen, después de 4 horas (¡¡¡Si si!! 4 horas) de dar vueltas consigo mandar la App y primer problema, me sueltan que no tengo suficientes «screenshots» y que por favor suba las de un iPad. ¡¡¡Pero si no tengo un iPad!!! pero sin embargo, bendito emulador del Xcode que permite hacer screenshots.

En fin, que tras la odisea tengo las apps mandadas. La de Android está desde ayer publicada y se puede descargar sin problemas. La de iOS estoy esperando que Apple la apruebe, proceso que según he leído puede durar hasta 15 días, así que tengo los dedos cruzados para que todo vaya bien. Solo faltaba que después de pagar me dijeran que no la publican.

Si queréis más información podéis ver PhoneGap en este link o Cordova en éste.

Para descargar la App de la UD Almería que he realizado lo podéis hacer en los siguientes links. Recordad que la de iOS aún no está publicada, por lo que el enlace es provisional y entiendo que funcionará en un futuro no muy lejano.

Android: https://play.google.com/store/apps/details?id=es.khaos.udalmeria

iOS: https://itunes.apple.com/us/app/ud-almeria/id866761824?ls=1&mt=8

Yahoo Query Language – ¡¡Estoy sorprendido!!

Hace poco tuve que empezar un proyecto en el que básicamente tenía que conseguir coger contenido de páginas externas (con el consiguiente permiso, claro), tratarlo y volverlo a poner en otro lugar. Había mirado mil formas de hacerlo, desde scripts basados en jQuery hasta auténticas «hackadas» usando versiones modificadas de llamadas usando JSON mediante Ajax para emular un GET de HTTP para parsear todo el contenido de la web… en fin, nada realmente limpio que me convenciera, hasta que ayer, y por pura casualidad encontré YQL (https://developer.yahoo.com/yql), más conocido como Yahoo Query Language y ¡¡Vaya cosa!!

Pero, ¿qué hace YQL? Pues básicamente, y usando un pseudolenguage basado en SQL, es decir, usando SELECTs y similares podemos hacer búsquedas de lo que queramos en una URL determinada. Para colmo YQL tiene una consola donde podemos hacer todos los tests habidos y por haber que queramos probar antes de implementar nuestro código. Una vez contentos con el resultado lo que hacemos es implementar una llamada AJAX mediante JavaScript a la URL generada por YQL y ¡¡Tachán!! obtenemos un bonito XML, o JSON con el contenido.

La cosa es más potente de lo que imaginamos… por poneros ejemplos:

  • Obtener los titulares de los RSS de Yahoo news:
    • select title from rss where url=»https://rss.news.yahoo.com/rss/topstories»
  • Obtener los lugares del mundo que se llamen Madrid (os sorprendería ver los resultados):
    • select * from geo.places where text=»madrid»

Por ejemplo, para la primera consulta, y si queremos el resultado en un JSON tendríamos que hacer una llamada AJAX a la siguiente URL:

https://query.yahooapis.com/v1/public/yql?q=select%20title%20from%20rss%20where%20url%3D%22http%3A%2F%2Frss.news.yahoo.com%2Frss%2Ftopstories%22&format=json&diagnostics=true&callback=

No voy a entrar en detalle de cómo crear una llamada AJAX, pero en caso de usar algo como jQuery podría ser algo así:

$.getJSON( "https://query.yahooapis.com/v1/public/yql?q=select%20title%20from%20rss%20where%20url%3D%22http%3A%2F%2Frss.news.yahoo.com%2Frss%2Ftopstories%22&format=json&diagnostics=true&callback=", function( json ) {
console.log( "JSON Data: " + json );
});
La verdad es que no tengo ni idea de si la gran competencia (Google) tiene algo parecido. A mí me ha venido de perlas y funciona a la perfección con lo que necesito.