Cifrar una disco duro externo en Ubuntu

Posted: junio 10th, 2018 | Author: | Filed under: Sin categoría | Tags: , , , , , , | No Comments »

La sencillez con que se pueden hacer ciertas tareas en Ubuntu u otras distros GNU/Linux ha mejorado enormemente desde la última vez que escribí sobre esto como cifrar un disco duro.

A día de hoy en Ubuntu la mejor opción es usar el asistente gráfico. Llega con insertar el USB y desmontarlo. A continuación desplegamos el menú contextual del disco externo pulsando con el botón derecho sobre él en el navegador de archivos y seleccionamos Format.

En la ventana de opciones seleccionamos las que aparecen en la siguiente captura.

Y listo, ya tenemos un disco duro externo cifrado en formato ext4 ideal para hacer copias de seguridad.


Migrar a GitLab manteniendo mirrors en GitHub

Posted: junio 9th, 2018 | Author: | Filed under: Sin categoría | Tags: , , , , , , , , | No Comments »

En iCarto habíamos planificado hace un tiempo migrar nuestra infraestructura de desarrollo (repositorios de código principalmente) a GitLab. Estos días hemos terminado la migración y he aprovechado para escribir un artículo de como se pueden mantener mirrors de los repos de gitlab en github a través de la propia plataforma o con un servidor intermedio.


DIY: Reparar el mando a distancia con papel albal

Posted: septiembre 30th, 2016 | Author: | Filed under: Sin categoría | Tags: , , , , , | 1 Comment »

Cuando el mando a distancia de la televisión tiene cierto uso no es raro que ciertos botones dejen de funcionar. Repararlo es más sencillo de lo que podría parecer.

La mayoría de teclados funcionan por el mismo principio. Un circuito impreso con una membrana por encima para cada tecla. En las membranas hay un conductor que al pulsar cierra el circuito produciendo una señal eléctrica que acaba enviando un código al receptor. A veces se introduce suciedad o se desgasta el conductor que cierra el circuito impidiendo que el botón funcione.

Para repararlo llega con abrir el mando a distancia e intentar limpiarlo o en caso de que no funcione usar papel albal (papel de aluminio). El papel albal es conductor, por tanto poniendo un pedacito con cuidado recubriendo la membrana estaremos “mejorando” la conductividad producida al pulsar la tecla.

Hay que tener cierto cuidado al abrir el mando, es fácil que el teclado se desalinee con el circuito impreso y al poner el albal. Sólo debe hacer contacto al pulsar la tecla, por lo que se puede usar una gotita de pegamento para pegarlo a la membrana.

Olvidé tomar fotos del proceso y con estos mandos de plástico abrir y cerrar a menudo no es buena idea pero en internet hay muchos ejemplos del paso a paso.

Antes de tirarte de cabeza a comprar un nuevo objeto porque tenga poco coste, recuerda la regla de las cinco erres.


Usando GeoProcesos en gvSIG desde Java

Posted: septiembre 4th, 2016 | Author: | Filed under: Sin categoría | Tags: , , , , , , , , | No Comments »

La semana pasada había un correo en la lista de desarrollo de gvSIG preguntando como poder lanzar geoprocesos desde tu propio plugin mediante Java. Tras una pequeña investigación he escrito un código de ejemplo que espero que sea útil a quien tenga esta necesidad.

Descargar el código

A mi particularme me gusta descargar el código fuente de las partes de gvSIG con las que voy a trabajar. Esto simplifica el usar las herramientas del IDE para saber como usarlo, encontrar errores, y revisar los tests, en caso de haberlos, para tener pistas de como escribir mi propio código.

Para ello primero se mira la versión del plugin que se corresponda con la versión de gvSIG que estás usando. Creo que lo más fácil es descargar una versión portable de gvSIG. Entrar a la carpeta que contiene el plugin, en este caso org.gvsig.geoprocess.app.mainplugin y abrir el fichero package.info. En la property version está el tag del repo correspondiente a esa versión. Por ejemplo para la 2.3RC2 sería el 2.266. Por tanto para descargar el repo haremos:


svn checkout http://devel.gvsig.org/svn/gvsig-geoprocess/org.gvsig.geoprocess/tags/org.gvsig.geoprocess-2.2.66/

A continuación,e n caso de usar Eclipse, iremos a import -> Existing maven projects, e importaremos la raíz del nuevo plugin descargado.

Añadir las dependencias

Al desarrollar en gvSIG debemos tener en cuenta que las dependencias de nuestro plugin, por decirlo de algún modo, serán de dos tipos. En “Tiempo de desarrollo”, y en “Tiempo de ejecución”. Las dependencias en desarrollo se definen en el pom del proyecto permitiéndonos definir el classpath de desarrollo para trabajar con las clases que nos hagan falta.

En ejecución, cuando estamos probando o ejecutando gvSIG, el classpath se define de manera dinámica por decirlo de algún modo en el fichero de config.xml. gvSIG buscará entre las dependencias que hayamos definido en el config las clases que se pueden usar en nuestro plugin.

Para que quede claro, a nuestro pom se añadirán otros proyectos maven. A nuestro config se añadirán plugins de gvSIG.

Por ejemplo para el caso de usar los geoprocesos, añadiremos al pom:



org.gvsig
org.gvsig.geoprocess.lib.api
2.2.66


org.gvsig
org.gvsig.geoprocess.lib.sextante
2.2.66

y al config



Obtener el algoritmo que queremos

Esta una de las partes en las que tengo más dudas que esté correcta.

En general accederemos a las funcionalidades de gvSIG a través de un Locator que nos dará un Manager que nos dará la funcionalidad. En el caso de los geoprocesos sería:


String ALG_NAME = "gvSIG-intersection";
SextanteGeoProcessManager manager = (SextanteGeoProcessManager) GeoProcessLocator.getGeoProcessManager();
HashMap algs = manager.getAlgorithms();
GeoAlgorithm alg = algs.get(ALG_NAME);

Debemos castear a la implementación por defecto del manager SextanteGeoProcessManager porque la interfaz en sí no proporciona el método getAlgorithms. Esto diría que es un bug.

La forma de obtener ALG_NAME, no estoy seguro de cual es. En principio lo más fácil sería poner un breakpoint y mirar los valores de algs. Aunque en mi caso sólo salen los propios de gvSIG y no los de Sextante.

Seteando valores al algoritmo

Todos los algoritmos definen un método defineCharacteristics que nos indican los valores que recibe, tanto de entrada como de salida. Esta definición de valores se obtiene a través del método getParameters

En nuestro código debemos obtener cada uno de los parámetros necesarios y setear su valor real para nuestro caso. Por ejemplo:


private void setParams(GeoAlgorithm alg) throws WrongParameterIDException {
ParametersSet params = alg.getParameters();

FLyrVect interLyr = getLayer("inter");
FlyrVectIVectorLayer inter = new FlyrVectIVectorLayer();
inter.create(interLyr);

FLyrVect layerLyr = getLayer("layer");
FlyrVectIVectorLayer layer = new FlyrVectIVectorLayer();
layer.create(layerLyr);

params.getParameter(IntersectionAlgorithm.INTER).setParameterValue(
inter);
params.getParameter(IntersectionAlgorithm.LAYER).setParameterValue(
layer);
params.getParameter(IntersectionAlgorithm.SELECTGEOM_INPUT)
.setParameterValue(false);
params.getParameter(IntersectionAlgorithm.SELECTGEOM_OVERLAY)
.setParameterValue(false);
}

En este caso para no escribir a mano los idenfificadores de los parámetros uso las variables estáticas definidas en el propio algoritmo. Eso hace que haya que añadir al pom el algortimo:



org.gvsig
org.gvsig.geoprocess.algorithm.intersection
2.2.66

Para las capas de entrada al algoritmo hay que generar una FlyrVectIVectorLayer. Como se muestra en el código de ejemplo lo más sencillo es obtener un FLyrVect y construirla con el create.

Ejecutando el algoritmo

Los algoritmos se lanzan mediante el método execute que como indica la documentación admite hasta tres parámetros.

  • ITaskMonitor task. Que puede ser nulo y permite monitorizar el estado para por ejemplo poner una barra de progreso al usuario
  • HashMap outputMap. Que permite modificar los nombres que sextante asigna a los parámetros de salida (en general capas)
  • OutputFactory outputFactory. Define como se crearán los objetos de salida. Puede ser nuestra propia implementación o usar la factoría por defecto

Por tanto ejecutarlo sería simplemente:


alg.execute(null, new DefaultOutputFactory(), null);

Obteniendo los resultados

Con la factoría por defecto las capas se crean en un directorio temporal que en linux es /tmp/tmp-andami y les asigna nombres aleatorios (creo que basados en el timestamp). Supongo que habrá alguna utilidad que nos permite ejecutar una especie de FinalActions para añdirlos automáticamente a la vista. O implementando nuestra propia OutputFactory podríamos definir otras rutas. También diría que podemos prescindir del OutputFactory y lanzar el algoritmo mediante processAlgorithm si igual que hicimos con los parámetros de entrada seteamos adecuadamente los valores de salida, especialmente el OutputChannel de las capas.

En todo caso el método getOutputObjects nos devuelve los objetos de salida, así por ejemplo podríamos llegar el FlyrVectIVectorLayer de la capa de polígonos de salida con:


OutputObjectsSet outputSet = alg.getOutputObjects();
OutPut output = outputSet.getOutPut(IntersectionAlgorithm.RESULT_POL)
FlyrVectIVectorLayer result_pol = (FlyrVectIVectorLayer) output.getOutputObject();


Si el disco duro no para al arrancar ubuntu vacía la papelera

Posted: agosto 7th, 2016 | Author: | Filed under: Sin categoría | Tags: , , , , , , | No Comments »

Los discos duros (casi) infinitos actuales han hecho que en un año haya acumulado más de 4000 ficheros y casi 60GB en la papelera de Gnome. Nunca pensé que esto fuera un problema pero ultimamente el ordenador tardaba muchísimo en iniciarse y el disco duro incluso después de arrancar el escritorio estaba funcionando durante uno o dos minutos.

El comando iotop nos permite saber que procesos están consumiendo más acceso a disco, y al lanzarlo durante el arranque descubrí que el problema era el servicio gvfsd-trash, responsable de la gestión de la papelera. Hay un montón de bugs y comentarios en los foros quejándose de este problema [1], [2], [3].

A falta de una solución mejor simplemente vaciar la papelera funciona. Así que ya sabes, si la lucecita del disco duro no para durante el arranque vacia la papelera.


Un sistema como otro cualquiera para recuperar tus contactos en un Android con la pantalla rota

Posted: septiembre 23rd, 2015 | Author: | Filed under: Sin categoría | Tags: , , , , , | No Comments »

Uno de esos días cualquiera en que te llega alguien (a quien no puedes mandar a freír puñetas buscar en google) que una semana después de comprarse su primer móvil con Android se le ha caído al suelo, se le ha roto la pantalla y quiere recuperar sus contactos.

La primera respuesta es fácil. No hay problema, estarán en la memoria de la tarjeta, o sincronizados en la cuenta de google. Pero no, ni uno ni otro. Están en la memoria del teléfono.

Las primeras búsquedas en google se refieren a sistemas que necesitan que el teléfono esté rooteado para por ejemplo copiar la base de datos (sqlite) con los contactos. Teniendo el sqlite es fácil sacar un csv o al menos un listado que copiar a mano. Pero por supuesto el teléfono no está rooteado.

Bueno, la pantalla no está del todo muerta, la parte de arriba responde. Así que igual da para hacer pulsar en los sitios clave. El teléfono en sí no puede desbloquearse, pero si se puede llegar al botón de “Ajustes“, porque no tiene activado la protección por figura. Jugando con la rotación automática para modificar los sitios a pulsar, podemos llegar de “Ajustes” a “Aplicaciones“, de ahí a la pestaña de “Todas” y desplazarnos hasta “Contactos“. Muchas de las apps, como la “Contactos” tienen un botón “Lanzar” equivalente a como si las abrieras desde el Launcher.

Estando en la app de Contactos sólo hay que poder lanzar la opción de “Exportar“, pero en este teléfono ese menú se lanza desde la tecla de “Menu” que no responde. Teóricamente con el conector adecuado, podríamos conectar un ratón al teléfono para controlarlo, pero a falta de conector resulta que es posible enviar eventos (como pulsaciones de teclas) al móvil a través de adb.

“Pulsamos” la tecla de menú:


$ ./adb shell input keyevent 82

Y un par de veces KEYCODE_DPAD_DOWN que actúa como el curso hacia abajo


$ ./adb shell input keyevent 20

Y enviamos el evento KEYCODE_DPAD_CENTER para hacer click / pulsar / tap sobre la opción seleccionada


$ ./adb shell input keyevent 23

Y ya tenemos lanzada la la aplicación de exportación. Siguiendo un proceso parecido de ver en que partes de la pantalla de puede pulsar y enviando eventos desde adb, seleccionamos como origen el smartphone, como destino la cuenta de gmail. Y listo. En un par de minutos tenemos los contactos en gmail, desde donde podemos exportarlos a csv, vcard o listos para ser usados desde otro teléfono android.

Espero que a alguien le sea de ayuda. Se admiten otros modos de hacerlo en los comentarios.


Video: Aplicaciones en tiempo real con python y postgres

Posted: agosto 25th, 2015 | Author: | Filed under: Sin categoría | Tags: , , , , , , , | No Comments »

Una charla de como montar aplicaciones en tiempo real con python y postgres. Tiempo real entendido como notificaciones de un chat, hacer algo cada vez que se actulice una tabla de la bd etc,…

El vídeo se hace un poco largo, seguramente con las transparencias llegaba para hacerse una idea general. Pero aún así se hace interesante por alguna de las técnicas que emplea:

  • Aboga por no usar frameworks en python. Con las librerías de hoy en día es sencillo montar una API Rest gestionando las llamadas de bajo nivel directamente
  • Usa las funciones de postgres de LISTEN y NOTIFY que combinadas con un trigger permiten que código cliente (psycopg2) sean notificados cuando algo pasa en la base de datos (se modifica una fila o lo que sea) y actuén en consecuencia (provocar un cambio en el navegador mediante websockets)
  • Para simplificar la API y el diseño de la bd, los datos se guardan como tipos nativos postgres (varchar, boolean,…), y se usa la función de postgres row_to_json para recuperarlos una cadena de texto con formato json.
  • Usa httpie para probar la API Rest. Si alguna vez usaste curl para esto enseguida verás que está bien conocer httpie.
  • A pesar de que la idea principal de la charla es montar una aplicación en tiempo real con el mínimo número de dependencias (complejidad) el proceso de build que monta no parece trivial. pip para dependencias en python, nodeenv (una especie de entorno virtual para node que se integra con el virtualenv de python), bower para las dependencias javascript de cliente,… Todo ello orquestrado por un Makefile.
  • No muestra como hacer la parte del frontend, pero en todo caso el código está en su repo

Compilando y depurando un plugin de ejemplo para gvSIG 2.1 desde Eclipse

Posted: enero 12th, 2015 | Author: | Filed under: Sin categoría | Tags: , , , , , , , | 1 Comment »

Joaquín del Cerro ha publicado un artículo explicando como compilar y depurar un plugin de ejemplo para gvSIG 2.1 con NeatBeans. He adaptado sus instrucciones para Eclipse que es mi IDE habitual. Este artículo no es tan detallado como el suyo así que seguramente tendrás que consultar los dos, especialmente los pasos previos que comenta Joaquín para que todo funcione.

Una vez que tenemos los “previos” realizados, creamos un nuevo workspace en eclipse, por ejemplo workspace-gvsig-landregistry.

Nos aseguramos de que tenemos instalados en eclipse:

Abrimos la perspectiva de eclipse de SVN Repository Exploring, desde Window -> Open perspective -> Other, o cualquier otro de los sitios desde los que se puede abrir.

Y añadimos el repositorio del plugin desde File -> New -> Repository Location o el icono correspondiente. Como URL usaremos:

http://devel.gvsig.org/svn/gvsig-plugintemplates/org.gvsig.landregistryviewer/trunk/org.gvsig.landregistryviewer/

Seleccionamos el repositorio que acabamos de añadir y en el menú contextual escogemos Check out as maven project

Si no tenemos el conector de maven-svn instalado, nos pedirá instalarlo. En la ventana previa al checkout nos aseguraremos de que la opción “All projects” está activada

Puede tardar un ratito en descargar, sobre todo si tiene que descargar muchas dependencias. Cuando acabe, pasamos a la perspectiva Java y ya tendremos los proyectos correspondientes al plugin configurados en el workspace.

Si no tienes la opción de Build automatically activada, haz un build all. A continuación pon un punto de ruptura para comprobar que todo funciona correctamente en el punto que indica Joaquín (método createWindow de la clase LandRegistryViewerExtension).

Tras lanzar gvSIG en modo debug,


./gvSIG --debug --pause

configuramos el debugger. En Debug Configurations, añadiremos una nueva configuración del tipo Remote Java Application

En name pondremos lo que queramos, por ejemplo org.gvsig.landregistryviewer.app, en project org.gvsig.landregistryviewer.app.mainplugin y en port 8765. Si antes de crear la configuración de debug seleccionamos el proyecto org.gvsig.landregistryviewer.app.mainplugin en el package explorer nos rellenará automáticamente name y project.

Al darle a debug debería abrirse gvSIG y pararse la ejecución en el punto que hemos marcado.


Organizar los ficheros de routes en nodejs – expressjs

Posted: marzo 30th, 2014 | Author: | Filed under: Sin categoría | Tags: , , , , , , , , , | No Comments »

Una de las tecnologías que estamos probando en Cartolab para aplicaciones web es nodejs con express como framework. Hay un montón de tutoriales de como empezar a usarlos, pero a poco que escribas empiezas a preguntarte como organizar el código, y ahí empiezan los problemas. express es un framework no opinativo, es decir proporciona un montón de utilidades pero da liberar total al usuario sobre como mezclarlas, así que se van desarrollando distintos modos de hacerlo.

La primera pregunta en mi casa sobre organizar el código fue acerca de los ficheros bajo el directorio routes. Podemos entender las routes de express como el equivalente al controlador en ese patrón llamado MVC que cada framework implementa como quiere, o viéndolo de otro modo como el mapeo entre una url y una función.

Vamos a ver cuatro estrategias distintas, cada una con sus ventajas e incovenientes.

Todo en app.js

La versión que se suele emplear en los tutoriales de iniciación. Escribimos en un único fichero todo el código de la aplicación.

  • Poco código boilerplate
  • Añadir una nueva url implica tocar un sólo fichero
  • Nada reusable
  • Sólo válido para proyectos pequeños

Es tan sencillo como escribir el mapeo antes de crear el servidor y usar funciones anónimas para la lógica


app.get('/', function(){res.send('root page'});

Mapear en app y la lógica en ficheros distintos

Este es el segundo ejemplo más habitual. Las url se definen en el fichero principal y las funcionalidades se agrupan en distintos ficheros bajo el directorio routes.

  • Añadir una nueva url implica tocar como mínimo dos ficheros
  • Favorece la reutilización, pero siempre debemos colocar las url a mano
  • Implica escribir más código que en el anterior y perder legibilidad

A pesar de que es muy habitual ver esto no me gusta porque no ganamos demasiado, y tener que hacer cambios en dos ficheros acaba introduciendo errores.


// app.js
var routes = require('./routes');  // Coje el fichero ./routes/index.js por defecto
var user = require('./routes/user');

app.get('/', routes.index);
app.get('/users', user.list);


// routes/user.js
exports.list = function(req, res){
res.send("respond with a resource");
};


// routes/index.js
exports.index = function(req, res){
res.send("root page");
};

Hacer el objeto app global y derivar todo hacia los ficheros de routes

Evitamos declarar app como variable local, para poder usarla en el resto de ficheros sin tener que preocuparnos de pasar parámetros. El código queda muy limpio pero se dificulta el testing y se pueden introducir bugs difíciles de detectar.

A mi me gusta esta aproximación cuando tenemos poco código y queremos hacer algo rápido, pero hay que ser consciente de los problemas que tiene.

  • No es una muy buena práctica hacer app global, en el siguiente punto vemos una mejora. Pero al hacerlo así obtenemos código más legible
  • Es bastante modular (excepto por hacer app global)
  • Es bastante legible
  • Hay separación de conceptos, cada fichero se encarga de unas determinadas url y funcionalidades

Referencias

Veamos como quedaría la implementación


// app.js
app = express(); //IMPORTANT! define the global app variable prior to requiring routes!
require('./routes');


// routes/index.js
require('./main');
require('./users');


// routes/main.js
app.get('/', function(req, res) {
res.send("root page");
});


// routes/users.js. list() could be an anonymous function, this is only for showing it in another way.

function list(req, res) {
res.send("user list");
};

app.get("/users", list);

Inyectar app en los ficheros de routes

Es similar al ejemplo anterior, pero el objeto principal es inyectado en los controladores en lugar de usarlo como una variable global. Sacrificamos un poco de legibilidad (hay que meter bastante código “inútil”) pero a cambio ganamos en modularidad y testabilidad.

Veamos una posible implementación, teniendo en cuenta que este código no lo he visto en ningún sitio, lo he escrito a partir del artículo de dailyjs y podría tener algún otro problema.

A mi esta es la aproximación que más me gusta, cuando el código aumenta y no nos queremos ir a soluciones más complicadas.


// app.js
var app = express();
// ...
app.use(express.json());
require('./routes')(app); // Must be called after app.use(express.json()) and urlencoded;


// routes/index.js
module.exports = function(app) {
require('./main')(app);
require('./users')(app);
};


// routes/main.js
module.exports = function(app) {
function index(req, res) {
res.send("root page");
};
app.get('/', index);
};

Otras estrategias

Hay estrategias más complejas, que por ahora no me ha hecho falta probar.


Montar un firefox independiente para desarrollo web

Posted: marzo 13th, 2014 | Author: | Filed under: Sin categoría | Tags: , , , , , , | No Comments »

Firefox_ScreenshotEn Cartolab llevamos ya una temporada investigando en uso de tecnologías web en el ámbito de la ingeniería cvil.

Una de las cosas que me incomodaron durante los primeros experimentos, era no tener un entorno de desarrollo específico. Al margen del IDE, en desarrollo web son fundamentales las herramientas que proporciona el navegador que usas para el testeo. En este caso, me molesta el mezclar plugins de desarrollo, con plugins normales que uso para la navegación. Tengo la sensación que se me descontrola el entorno de trabajo.

La solución es configurar un navegador específico para desarrollo. Lo cual, al menos en el caso de firefox, es más sencillo de lo que parece:

  1. Le echamos un ojo a las instrucciones de mozilla de como instalar firefox a mano. En resumen: descargar y descomprimir. Yo lo descargue en /usr/local/development
  2. Si ahora simplemente ejecutamos el fichero binario firefox veremos que no hemos ganado nada, aún tendremos nuestros marcadores, plugins, etc… Esto es porque firefox, guarda esta información en perfiles y usa por defecto el perfil indicado en el fichero $HOME/.mozilla/firefox/profiles.ini
  3. Debemos por tanto crear un nuevo perfil, pero antes haremos una copia de profiles.ini
  4. Creamos el perfil como recomiendan desde mozilla, ejecutando firefox -P. Yo cree el perfil dentro de la propia carpeta del firefox descargado a mano, para poder tener un sistema autocontenido.
  5. El paso anterior habrá modificado el fichero profiles.ini, añadiendo el nuevo. Pero lo que nosotros queremos es tener el modo desarrollo lo más aislado posible así que restauramos la copia que hicimos anteriormente
  6. Creamos un miniscript en nuestro PATH o donde queramos que ejecute nuestro firefox de desarrollo y le pase el parámetro -profile y el path al perfil de desarrollo que creamos. Yo cree un script ffdev en /usr/local/bin con el siguiente contenido

    #!/bin/sh
    cd /usr/local/development/firefox
    ./firefox -profile development-profile

Los menos puristas habrán observado, que en realidad, no es necesario complicarse tanto la vida bajando un firefox aparte. Llegaría con:

Crear un perfil nuevo en la carpeta por defecto, marcar el antiguo perfil como el que hay que usar por defecto y crear un script que arranque el nuevo perfil firefox -P "Nombre del Nuevo Perfil"

Si hemos optado por la primera altenativa y finalmente decidimos pasar a la segunda, un sólo firefox en el sistema que se actualice al ritmo que marca nuestra distribución, el cambio es tan sencillo, como copiar la carpeta de perfil de desarrollo a una nueva ubicación (el
directorio por defecto de perfiles sería lo lógico) y modificar el script para indicarle la nueva ruta del perfil y que firefox tiene que
usar. Si quisieramos poder abrirlo desde el Gestor de Perfiles o con la opción -P en lugar de -profile deberemos añadirlo a profiles.ini

¿Creéis que es útil configurar un perfil para desarrollo o no hace falta? ¿Cual de los dos métodos preferís?