Blog dedicado a la distribución GNU/Linux que uso habitualmente, Arch Linux, a mis andanzas alrededor del software libre, la programación y a otros temas relacionados con la tecnología y la informática.
Uno de los defectos que tienen los móviles android es que los fabricantes y las operadores si ofrecen actualizaciones a nuevas versiones de android lo hacen tarde y en algunos casos ni eso con lo que al cabo de una año ya no tienes la última versión de andoid en un móvil que por hardware sería perfectamente capaz. Esto causa uno de los problemas en android, fragmentación en el ecosistema, dificultando el desarrollo de las aplicaciones y obligando a soportar un mayor número de versiones andoid en vez de unas pocas.
A raiz de este problema han ido surgiendo varias roms como CyanogenMod o MIUI que proporcionan versiones de android más actualizadas y modificadas partiendo del código original proporcionado por google. CyanogenMod es una de las roms más longevas, que soporta mayor número de dispositivos y de las más estables. Además del motivo anterior de tener una versión más actualizada de android, CyanogenMod puede solucionar algunos defectos que tiene el android original del teléfono. En mi caso el teléfono venía con froyo (2.2) y CyanogenMod me ha permitido disponer de gingerbread (2.3) además de corregir algunos problemas como poder desactivar la respuesta háptica (vibración) de los botones y de los bloqueos que se producían en algunas ocasiones al activar y desactivar la radio. Además CyanogenMod tiene muchas más opciones de personalización que las originales de android.
Los pasos a seguir para realizar la instalación de CyanogenMod son básicamente dos:
Rootear el teléfono lo que nos permitirá instalar bootloader y flashear CyanogenMod
Flashear CyanogenMod y las aplicaciones de Google.
Importante: rootear el teléfono puede acabar con la garantía y si no se hace de forma correcta el teléfono puede quedar tal útil como un ladrillo («bricked»). Por tanto, es conveniente saber que es lo que se esta haciendo y cuales son los pasos a seguir. No me hago responsable de los ladrillos creados por esta guía.
Por tanto para evitar problemas es conveniente realizar la operación con la batería del móvil completamente cargada ,conectado al ordenador ya que uno de los motivos del los móviles brickeados es apagar el móvil cuando se está en el proceso de flasheo de la rom y realizando previamente una copia de seguridad de toda la información del teléfono ya que se perderá en el proceso.
Una vez informados de que es lo que hay que hacer y de las advertencias estamos listo para instalar CyanogenMod. El proceso explicado en la propia página de CyanogenMod para conseguir permisos de root a mi no me funcionó de tal forma que lo realicé con el programa SuperOneClickRoot, que lo realiza pulsando un botón. Además necesitaremos la rom adecuada para nuestro móvil, buscaremos entre los soportados y descargaremos la última versión estable. También necesitaremos las aplicaciones de google y por último el SDK de android con las platform-tools instaladas.
La última versión estable y las aplicaciones de google hay que copiarlas en la carpeta raíz de la tarjeta SD. Conectamos el móvil con el cable USB al ordenador y activamos la depuracion USB en Ajustes > Aplicaciones > Desarrollo > Depuración USB. Iniciamos SuperOnClickRoot y pulsamos el botón Root, tal vez se reinicie el teléfono varias veces y se nos preguntará si queremos instalar busy box, le damos que sí. Si todo hay ido bien ya tenemos rootedo el teléfono. Para comprobarlo abriremos una consola y con el comando adb shell de las platform-tools del SDK android deberemos ver en el prompt el caracter #, si el caracter es un $ el rooteo no funcionó. A partir de aquí los pasos son los mismos que los explicados en las secciones de las guías de cyanogenmod, «Installing bootmenu & the ClockworkMod Recovery» y «Flashing CyanogenMod». Deberemos instalar el bootloader para poder realizar el flasheo, reinicia el telefono y entrar en el bootloader, limpiar el teléfono con las operaciones wipe e instalar el zip con la rom de cyanogenmod y el zip con las aplicaciones de google desde el bootloader.
Estas son algunas capturas de como se ve CyanogenMod en su versión 7.1
Después de una charla a la que asistí y se explicó las posibilidades que ofrecen algunos aparatos como la Pandaboard, SheevaPlug u otros que estaban por llegar como la Raspberry Pi me entraron las ganas de hacerme con uno. En mi caso lo principal ha sido el poder tener un aparato dedicado a las descargas en vez del portátil y que su consumo de electricidad es muy reducido, entre 2 y 9 vatios (si usas un ordenador de escritorio para dejarlo descargando que tiene un consumo de entre 100w y 200w merece la pena usar un aparato de este tipo ya que su precio se amortiza en unos pocos meses) además de poder aprender algunas cosas. Aunque tiene unos recursos más reducidos que por ejemplo la Pandaboard me decanté por una Raspberry Pi por su precio, por la amplia comunidad que se ha formado alrededor de ella, lo que garantiza el soporte, y porque Arch Linux tiene una versión orientada a procesadores ARM ofreciendo entre otras soporte para la Raspberry.
¿Que es una Raspberry Pi? En esencia es un computador completo con el tamaño de de una tarjeta de crédito y con un coste muy reducido ¡27€! originalmente pensado para la enseñanza de programación. Posee un procesador de un núcleo ARM funcionando a 700 Mhz, 256 MiB de memoria, un lector de tarjetas de memoria SD de hasta 32 GB utilizada para cargar el sistema operativo, salida de video HDMI, un puerto ethernet 10/100, dos puertos USB 2.0, salida de video RCA para la televisión y un jack 3.5 mm como salida de sonido entre las cosas a destacar que le falta es WIFI. La placa se alimenta a taves de un puerto miniUSB con lo que un cargador de móvil USB nos puede servir perfectamente para alimentarlo. Desde luego no podrá ejecutar el último juego o un entorno gráfico de ventanas cono GNOME o KDE, ni sustituirá nuestro ordenador habitual con el que trabajemos pero eso no quiere decir que no sea útil. Pensándolo bien 256 MiB de memoria es lo que llevaban los ordenadores de escritorio allá por el 2004 y era lo recomendable para Windows XP y 700 Mhz es la velocidad a la que funcionaban los procesadores intel o amd hasta hace también bien poco, el HDMI es reciente y los puertos USB son omnipresentes. Todas estas características son proporcionadas por el SoC (System on a Chip) de Broadcom BCM2835 que incluye la CPU, la memoria y una GPU capaz de reproducir video a 1080p30, es un chip más capaz que el del iPhone 4 en el apartado gráfico. En la wikipedia hay más detalles.
Después de un par de meses esperando a que me llegase la Raspberry Pi a través de Farnell al final cancelé el pedido y lo hice a través de RS components. La verdad es que la experiencia ha sido mucho mejor con esta última que con la primera. Farnell abrió la preventa allá por el 29 de febrero desde un primer momento, como la demanda fue desmesurada para la cantidad disponible de placas por aquel entonces muchos hemos estado esperando varias semanas y sin ni siquiera con una fecha estimada de entrega. Por el contrario RS components hasta el momento solo ha permitido dejar los datos para ser avisado en el momento que tengan disponibilidad para satisfacer el pedido. Y ha sido esta semana cuando he recibido un correo de RS componentes mediante el cual podía realizar el pedido y en un plazo de 7 días laborales decían que realizaban el envío. Así que disgustado con la poca información ofrecida por Farnell y viendo que RS components tenía disponibilidad y me enviaba una en 7 días cancelé el pedido con Farnell y lo realicé con RS components. Al final no han sido 7 días lo que ha tardado en llegar sino solo 3. Por otra parte, al realizar el pedido con RS components se podía solicitar el envío de los cables que necesitemos (HDMI, cable ethernet, salida de video y jack 3.5 a rca para conectarla a la televisión, cargador usb y tarjeta de memoria), por si esto no fuera poco, en cuanto a precio ha sido mejor la oferta de RS Components, con gastos de envío inlcuidos y varios cables (HDMI, ethernet, jack 3.5 a rca) el precio final ha sido 48.06 € contra 46,02 € y sin cables por parte de Farnell. Hay que decir que de momento las Raspberry Pi se están enviando sin caja, en un futuro existe la intención de ponerlas a la venta con caja para un uso más cómodo.
Mis planes para la Raspberry Pi son utilizarla como servidor de descargas para tenerlo descargando en vez del portátil, repositorio git para los proyectos personales que no quiera tener en GitHub de este modo no tendré que hacer tan a menudo copias de seguridad, tal vez un pequeño servidor para compartir archivos con ownCloud y si me es posible como reproductor de películas para conectarlo a la televisión. Con estos objetivos tendre que aprender como hacer una serie de cosas como conectarme mediante ssh de tal forma que no necesite un monitor para usarla, tendré que mirar como enviarle los torrents que quiero descargar, como instalar y configurar el servidor git y otra serie de cosas que vayan surgiendo de forma que pueda darle más uso. A medida que vaya aprendiendo lo iré plasmando en entradas en este blog.
Aún me falta hacerme con un par de tarjetas de memoria y un teclado usb que en cuanto tenga empezaré a cacharrear. De momento tengo solo un trozo de metal pero si queréis verlo aquí tenéis el mejor desempaquetado/unboxing de la Raspberry enviada por RS components que la cámara de mi móvil me ha dejado hacer. Si te ha parecido interensate el tema puedes continuar leyendo la Guía instalación Raspberry Pi con Arch Linux ARM (Parte I, instalación base).
El sistema de control de versiones Git tiene varias ventajas sobre los tradicionales herrramientas de control de versiones como puede ser Subversion y en está época muchos servicios están ya ofreciéndose a través de internet, las herramientas de control de versiones también. GitHub es un repositorio para hospedar proyectos de software que se basa en Git como herramienta de control de versiones todo ello a través de internet. A parte del repositorio Git para el código fuente otras características que ofrece son un gestor de peticiones, wikis y revisión de código. Además de poder trabajar de forma colaborativa haciendo forks de los proyectos de otras personas y enviándoles peticiones pull para los cambios que hagamos en sus proyectos.
Los pasos para poder crear nuestros propios repositorios en GitHub son varios pero nada complicados y están bien explicados en la documentación de GitHub. Primeramente deberemos crear una cuenta en GitHub eligiendo uno de los planes que nos ofrecen. Si los repositorios que vamos a crear van a contener código abierto y van a ser públicos podremos usar el plan gratuito.
Una vez que tenemos nuestra cuenta deberemos configurar git para poder trabajar. Primeramente instalaremos el correspondiente paquete de git en nuestro sistema. Posteriormente deberemos crear un par de claves de SSH para poder hacer commits y trabajar en nuestros repositorios de forma segura.
ssh-keygen -b 8192 -t rsa -C "[email]"
Una vez generadas las claves tendremos que copiar el contenido de la clave pública en las preferencias de nuestra cuenta de GitHub en la sección de claves SSH. Podemos comprobar que hemos configurado la clave correctamente con:
$ ssh -T git@github.com -i "[clave privada]"
Ahora deberemos crear un repositorio de Git en GitHub, también en nuestro equipo en la carpeta donde lo guardemos y configurar algunas propiedades:
Si queremos podemos crear un archivo README utilizando alguno de los lenguajes de marcas disponibles para que los usuarios que llegue a la página del proyecto en GitHub sepan de que trata y cualquier otra información que creamos pueda serles de ayuda.
Ya solo nos queda hacer los primeros commits y enviarlos a GitHub con las siguientes comandos respectivamente:
Obtener la clave con la que está protegida una red WIFI con seguridad WEP no es excesivamente complicado para una persona que tiene unos pocos conocimientos sobre informática, sabe buscar, leer y no le da miedo el terminal. Aún así hay que tener en cuenta que acceder a una red WIFI que no conocemos y que no sabemos de quien es no es recomendable ya que podemos ser victimas de que accedan a los datos que transmitimos.
Si aún sabiendo esto queremos acceder a una, para obtener la clave de las redes WIFI con seguridad WEP necesitamos una serie de programas que en la mayoría de distribuciones Linux son muy fáciles de instalar a través de sus gestoresde paquetes, necesitaremos aircrack-ng y macchanger. En el momento que probé a hacerlo con Arch Linux, parece que el el aircrack-ng tenía un problema con los canales de las WIFI asi que tuve que optar por usar BackTrack. La distribución de Linux BackTrack ya los trae instalados asi que solo tendriamos que desgargar una vesión de esta, grabarla en un CD y iniciar el equipo con ella.
Los pasos para obtener la clave de una red WIFI con seguridad WEP son:
Ponemos la tarjeta en modo promíscuo para escuchar todos los paquetes que circulen por la red:
$ sudo airmon-ng start wlan0
Cambiamos la dirección MAC de nuestra tarjeta de red inalámbrica para evitar trabajar con la nuestra y que nos identifiquen:
$ sudo ifconfig mon0 down
$ sudo macchanger -m 00:11:22:33:44:55 mon0
$ sudo ifconfig mon0 up
Escaneamos las redes que están cerca nuestro, buscamos una con cifrado WEP:
$ sudo airodump-ng mon0
Empezamos a volcar el tráfico de la red para que aircrack pueda averiguar la clave (este paso y los dos siguientes se realizan de forma simultanea en terminales diferentes):
Ponemos a aircrack a trabajar para descifrar la clave:
$ sudo aircrack-ng -z [ESSID]*.cap
Ya solo nos queda esperar un rato hasta que aircrack capture los paquetes suficientes y nos proporcione la clave en forma de 5 pares de caracteres.
Asi que no tengas una falsa sensación de seguridad por tener una red WIFI protegida con una seguridad WEP, incluso las redes WIFI con seguridad WPA/PSK que son un poco más seguras obtener la clave de estas también es posible. Dado que tener una red WIFI WEP o WPA/PSK no nos evita estar a salvo de intrusos algunas acciones que podemos tomar son: no usar WEP y al menos usar WPA/PSK (que tampoco es segura pero es mejor que WEP), cambiar la clave cada unas semanas (tampoco nos evita estar a salvo pero le será una molestia para quien intente acceder a nuestra WIFI), apagar la red WIFI si no la utilizamos y no dejarla siempre encendida (esto hará que alguien que este buscando una red WIFI a la que conectarse opte por otra que no sea la nuestra por no tener WIFI siempre que quiera), activa el filtrado MAC del router WIFI (así solo nuestros equipos podrán conectarse a eĺ) y ocultar la red no difundiendo el nombre, SSDI, de nuestra red (para alguien con pocos conocimientos optará primero por las redes que vea en vez de las redes WIFI ocultas).
Algunos motivos para evitar tener intrusos en nuestra red son disponer de todo el ancho de banda por el que pagamos, evitar que alguien utilice nuestra red para realizar acciones ilegales o acciones delictivas a través de ella, evitar que accedan a nuestros equipos y a nuestros documentos, claves de los servicios que utilizamos o datos de nuestras tarjetas bancarias o cuentas. Lo principal será prevenir estos poco frecuentes pero posibles problemas.
Prácticamente toda aplicación incluye un sistema para emitir trazas con información relevate de lo que está realizando a un fichero o a la salida estándar. Dependiendo de la información y detalle de la misma esta puede ser muy útil para determinar la causa de un posible fallo o algún mal funcionamiento de la aplicación ya que el log es un registro no solo de la excepción producida sino también de su contexto con las acciones anteriores realizadas. También puede servir para monitorizar en tiempo real las acciones que está llevando a cabo el sistema que de otra forma no podríamos realizar o sería utilizando herramientas más complejas.
Generar trazas en una aplicación es muy barato y simple comparado con la información que puede proporcionar, su utilidad y tiempo que puede ahorrar a la hora de descubrir problemas. Básicamente, las trazas que queremos generar las insertamos dentro del propio código de la aplicación que están compuestas del mensaje que queremos emitir, el nivel de la traza y la categoría a la misma. El mensaje puede ser cualquier cadena que queramos que creamos que nos puede ser útil pudiendo contener datos procedentes de variables o cualquier otra cosa de la que pueda disponer el programa. Los niveles de las trazas en muchos sistemas son las siguientes por orden de relevancia de mayor a menor: fatal, error, warn, info, debug. Estos niveles de las trazas nos pemitirán utilizalos posteriormente para en tiempo de ejecución y mendiante la configuración del sistema de logging filtrar las mismas por el nivel que queramos pudiendo obtener únicamente las trazas de nivel warn o superior. Las categorías representan la pieza dentro de nuestro sistema que emite la traza que también podremos utilizar para filtrar los mensajes que queramos. Por supuesto, podremos utilizar las combinaciones de nivel y categoría que queramos teniendo en nuestras manos un sistema muy flexible para obtener la información que queramos y que genere la aplicación.
Veamos un pequeño programa para hacernos una idea de que es todo esto:
package es.com.blogspot.elblogdepicodev.slf4j;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class HelloWorld {
public static void main(String[] args) {
// logger es un referncia a la categoria
Logger logger = LoggerFactory.getLogger(getClass().getName());
// debug es el nivel de la traza
// Hello world! es el mensaje que se emite
logger.debug("Hello world!");
}
}
Como normalmente ocurre en el mundo del software libre y de código abierto y muchas veces en java hay más de una librería a nuestra disposición para cada funcionalidad que queramos incorporar en una aplicción. En el caso del sistema de trazas por supuesto esto no es menos. Dos de las más conocidas son log4j y la propia que incorpora el JDK de Java, java.util.logging. Aunque ambas librerías/api son prácticamente iguales salvo por llamar de forma diferente a los mismos conceptos normalmete la elección se decanta por log4j por ser más flexible y poseer algunas más opciones más (log4j vs java.util.logging). Salvo que no queramos o no podamos añadir una nueva dependencia a nuestro proyecto posiblemente elijamos log4j u otra como logback.
Logback es otra librería para logging denominandose a si misma la sucesora de log4j y siendo sus autores los mismos, con lo que han plasmado en esta nueva librería la experiencia aprendida en log4j. Hay varias razones por las que podríamos querer usar logback en vez de log4j, entre ellas es más rápido (según dicen ellos unas 10 veces más rápido), configuración usando Groovy, recarga automática de la configuración, compresión y eliminación automática de archivos históricos y trazas con información de empaquetado entre otras.
El ejemplo de código anterior hace uso de otra librería llamada slf4j que permite abstraernos de la libreria que decidamos utilizar ya sea lof4j, java.util.logging o logback. Usando slf4j si posteriormente queremos cambiar de una librería a otra será tan fácil como realizar un nuevo archivo de configuración y sustituir su jar por el de la otra librería, no tendremos que tocar ninguna linea de nuestro código. Por tanto podemos tener las siguientes combinaciones:
slf4j + log4j
slf4j + java.util.logging
slf4j + logback
Posibles bindings para slf4j
Como se puede ver en la imagen logback no necesita un adaptador que penaliza el rendimiento como en el caso de log4j o java.util.logging.
Configuración programática (sin archivos de configuración)
Mejor rendimiento incluso por encima de logback
Varargs y placeholders en los métodos de logging
Sin reserva de memoria y por tanto sin sobrecarga para el garbage collector
Soporta colores para la consola
Los loggers son enumerados
Tenemos a nuestra disposición varias posibilidades y si tenemos la posibilidad de elegir quizás una opción recomendable sea la combinación slf4j + logback, ya que con ella siempre podremos pasar a utilizar cualquiera de log4j, java.util.logging o logback de forma sencilla y sin ningún cambio en el código. Y aunque MentaLog parece que no tiene todas las opciones de la anterior combinación si cumple con nuestras necesidades tambien sea otra opción a considerar por sus características.
En la actualizad los procesadores están aumentando su capacidad de proceso principalmente a base de añadir más núcleos, a medida que la tecnología progrese la programación concurrente tomará más importancia para aumentar el rendimiento y para poder soportar más usuarios en las aplicaciones en el caso de la web. Hay ciertas tareas de las aplicaciones que se prestan a ello y que pueden ejecutarse de manera concurrente, por ejemplo, dos tareas que podrían ser son el envío de correos electrónicos y el precalculado de ciertos datos de una base de datos para mejorar los tiempos de acceso en posteriores consultas.
Dependiendo de la aplicación estas dos tareas probablemente no hace falta que sean inmediatas y es interesante que se produzcan fuera del thread que procesa la petición del usuario, más si se trata de una aplicación web. Hay que tener en cuenta que el enviar un correo electrónico, precalcular datos u otras tareas pueden ser algo que lleve una cantidad de tiempo notable, a partir de unos cientos de milisegundos a más de unos segundos. Si tenemos muchos usuarios en la aplicación y realizamos tareas como estas en el mismo thread de la petición el tiempo de respuesta percibido por el usuario será bajo, el número de usuarios concurrentes posibles será menor y escalar en número de usuarios será más dificil. Vamos a ver como solucionar tareas como estas utilizando la programación concurrente que ofrece Java desde la versión 1.5 y aplicando el patrón de diseño Command, patrón que se presta muy bien a ello.
Java en la versión 1.5 añadió el paquete java.util.concurrent para mejorar el soporte que ofrecía java para la programación concurrente con los Threads. La forma más sencilla de empezar a aprovecharlo es a través de la clase Executors que nos permite obtener referencias a objetos ExecutorService que será el que utilicemos para encolar las tareas. La clase Executors tiene varíos métodos que podemos aprovechar, entre ellos:
newFixedThreadPool nos permite obtener un pool de threads de tamaño fijo al que enviar tareas para ejecutarse. Si se envían más tareas que threads hay disponibles en el pool la tarea se encola esperando a que se libere algún thread del pool. newScheduledThreadPool permite programar la ejecución de las tareas a intervalos regulares, es una versión simple de lo que puede ofrecer Quartz ya que no soporta expresiones cron. Si necesitamos que las tareas se ejecuten de forma serializada y no de forma concurrente pero en otro momento de donde se crean podemos usar el ExecutorService devuelto por newSingleThreadExecutor.
Las tareas que se envían a los ExecutorService son clases que implementan la interfaz Runnable o Callable, esta última tiene la ventaja de que puede devolver un resultado y que puede lanzar una excepción. La interfaz Callable tiene un único método, call, y básicamente es una interfaz que sigue el patrón de diseño Command. El patrón Command encapsula los datos de una operación a realizar y desacopla el que crea el objeto del que realmente lo ejecuta.
Dicho todo esto la idea es crear tantas clases que implementen la interfaz Callable como tareas queramos ejecutar fuera del lugar de donde se crean y de forma concurrente, también necesitaremos un ExecutorService que en los siguientes ejemplos está en la clase CallableServiceImpl.
Esta podría ser la interfaz de un servicio que se encarga de ejecutar las tareas que se le envían a través de los métodos submit:
Esta implementación del servicio se encarga de ejecutar de forma concurrente las tareas según el número de threads de un ExecutorService:
El Callable para las tareas que envían correos electrónicos:
La clase mensaje de utilidad que contiene los datos para poder enviar el correo electrónico en EnviarEmailCallable:
La clase Callable que precalcula una serie de datos:
Y utilizando una factoría podemos evitar tener una dependencia sobre estas clases Callable en el código que las usen:
Finalmente el servicio y la implementación del servicio que hace uso de la factoria CallableFactory y el servicio CallableService:
Después de ver que es la herramienta de construcción Gradle, cuales son sus características y que ventajas nos puede aportar en comparación sobre ant o maven en esta entrada vamos a ver como usarla en los proyectos de la forma más sencilla posible y sin necesidad de instalar manualmente sus binarios en nuestra máquina.
El no tener que instalar los binarios antes de poder hacer uso de gradle facilita el trabajo a una nueva persona que vaya a comenzar a colaborar en el proyecto ya que únicamente necesitará obtener el código fuente del mismo. También nos será útil si no tenemos control sobre el entorno donde lo vayamos a ejecutar como podría ser un entorno de integración continua. Para ello existe la herramienta gradle wrapper que una vez instalado en el proyecto nos permite usarlo sin necesidad de que descarguemos manualmente sus binarios, los descomprimamos en alguna carpeta de nuestro sistema y creemos una variable de entorno, de ello se encargará el envoltorio de gradle descargando todas las cosas necesarias a través de internet.
Pero antes de usar gradle wrapper hay que añadir su soporte en el proyecto, para ello añadiremos la siguiente tarea «wrapper» y la ejecutaremos (esta tarea hace uso de gradle con lo que al inicio de proyecto al menos una persona deberá instalar manualmente gradle). Esto añadirá el soporte al proyecto para usar gradle wrapper creando una serie de archivos, entre ellos están los archivos de lotes que usaremos a partir de este momento, gradlew para entorno linux y gradlew.bat para windows, también se añadirá una carpeta gradle/wrapper con una librería y un archivo de configuración.
