code-to-git

Migrando de mercurial a git (y GitHub)

Ayer pasé todo el día migrando el código de eAdventure de Google Code a GitHub, y aunque los pasos parecían muy sencillos, he tenido que pelearme con unos cuantos imprevistos. A continuación, detallo los pasos necesarios para convertir un repositorio mercurial en un repositorio git, para  finalmente subirlo a GitHub.

ADVERTENCIA: No uses Windows. Se debe poder hacer. No lo pongo en duda, pero tras varios intentos fallidos, he tenido que hacerlo todo desde Ubuntu. Si no lo tienes instalado, lo más recomendable es que uses un software para máquinas virtuales como Oracle VM VirtualBox e crees una máquina con la última distribución de Ubuntu. Ten en cuenta que necesitarás tener el código del repositorio mercurial en esa máquina. Puedes bajarlo desde tu repositorio actual, o copiarlo de una carpeta compartida con Windows.

1. Revisando los e-mails de los autores de los commits

¿Sabías que cada commit que realizas (ya sea en mercurial o en git) tiene asociado el nombre de usuario y el e-mail que tengas configurado para el repositorio? Sí, yo algo intuía. Puse un usuario en el TortoiseHg el día que lo instalé… El e-mail no. Luego no sirve para nada… ERROR. Ese e-mail es justo es el que va a utilizar GitHub para asociar los commits a tu usuario.

Así que, antes de empezar la migración, debes asegurarte de que los commits están realizados con el usuario y e-mail correctos.

Si en su día configuraste mercurial como debías, no debes preocuparte. Pero si no, puedes utilizar el siguiente comando para ver los nombres de usuario utilizados en los commits:

hg log --template '{author|person}\n' | sort | uniq

Si, como yo, no realizaste una configuración correcta, podrías encontrarte cosas como las que me encontré yo:

anserran@somepc
anserran@localhost.somepc
...

Si fuera el caso, no te preocupes: en los siguientes pasos además de migrar a git podrás solucionar este problema. Apunta todos estos usuarios y e-emails incorrectos para después.

2. De mercurial a git

Para la migración vamos a utilizar hg-fast-export. Pra hacer correr la utilidad es necesario tener instalado el paquete python mercurial. Puedes descargarlo de los repositorios de Selenic. IMPORTANTE: a fecha de hoy, hg-fast-export NO FUNCIONA con la versión más reciente del paquete mercurial, la 2.3. Yo he utilizado la 2.2 y no he tenido ningún problema.

Si como yo, no tienes ni puñetera idea de python, para instalar el paquete debes descargarlo, descomprimirlo, y desde un terminal, ir al directorio de descompresión y ejecutar:

python setup.py install

Ahora debes descargar hg-fast-export:

mkdir /path/to/hg-fast-export
cd /path/to/hg-fast-export
git clone https://github.com/barak/hg-fast-export.git

¿Recuerdas los datos del paso 1? Si hubieras encontrado algún error, ahora es el momento de arreglarlo. hg-fast-export permite corregir o actualizar los autores de los commits con un archivo de configuración.

Imaginemos que uno de los commits en mercurial está asociado a anserran@somepc. Para corregirlo, preparamos el siguiente archivo:

anserran@somepc=miusuariocorrecto

donde miusuariocorrecto y miemailcorrecto@email.com son tu usuario y e-mail para el commit a git. A la izquierda los datos de mercurial, a la derecha la traducción a git. Lo más recomendable es que utilices tu usuario y e-mail de GitHub.

Es necesario que el e-mail del commit sea el utilizado en GitHub, para que la cronología se muestre de manera correcta. Además de corregir errores, también puedes utilizar este archivo para hacer actualizaciones de usuarios:

anserran@somepc=mycorrectuser
usuario=usuario

Guardamos el archivo como autores.txt, y continuamos.

Ha llegado el momento de la conversión. Supongamos que tu repositorio está en /repositories/mercurial/myproject. Para la conversión a git, necesitamos un directorio de destino. En nuestro caso utilizaremos /repositories/git/myproject. Una vez creado este directorio, los pasos a seguir son:

# hg-fast-export utiliza como destino el directorio actual
cd /repositories/git/myproject
# Iniciamos el repositorio git
git init
# Realizamos la migración con el directorio de origen y el archivo de autores.
# Si no vas a realizar cambios en los autores, puedes eliminar "-A autores.txt"
/path/to/hg-fast-export/hg-fast-export.sh -r repositories/mercurial/myproject -A autores.txt
# Es necesario un checkout para copiar los archivos del repositorio
git checkout master

Y si todo va bien, tras unos segundos (o minutos, dependiendo del tamaño del historial) el repositorio está listo para ser subido a GitHub. Pero antes de hacerlo, si realizaste cambios en los autores con la opción -A, puedes comprobar los autores presentes en el repositorio git con

git log | grep 'Author: *' | sort | uniq -c

y cerciorarte de que coinciden con lo esperado. Si no fuera así, deberías borrar el contenido de /repositories/git/myproject, corregir el fichero autores.txt con los cambios adecuados y realizar de nuevo todo el proceso.

3. Subida a GitHub

Crea un nuevo repositorio en GitHub y asegúrate de que la opción “Initialize this repository with a READMEno está marcada.

Ahora, desde /repositories/git/myproject ejecuta:

git remote add origin https://github.com/turepositorio.git
git push -u origin master

Tras introducir tu usuario y contraseña, tu código es enviado a GitHub.

Como último paso, no olvides borrar el archivo .hgignore y añadir un .gitignore adecuado a tus necesidades.

Otras entradas que podrían interesarte

  • No sé encontró ninguna entrada.

Learning Analytics for Serious Games

He escrito una pequeña entrada en el blog del proyecto GALA (Games and Learning Alliance), en el que participo. Está en inglés. Bueno, en “inglés”. Comienza así:

So we found out—and then convinced everyone—that game based learning is great, that exploits the concept of learning-by-doing with lower costs in many cases, that is focused on problem solving, that improves students motivation. In summary, that game based learning has lots of advantages over more traditional approaches. But when we suggest teachers to use serious games to teach their students, the first question that it comes to their minds is: ‘Well, yeah, I like the idea, but… How do I assess this?’

Se puede leer completo aquí.

Otras entradas que podrían interesarte

2775389479_b7cbd6b45e

Nos espían

De siempre fui bien pensado. Y aún más en lo que a seguridad informática se refiere.

Cuando era un púber y veía Alias, uno de sus personajes, además de ser capaz de  inventar artefactos imposibles al estilo James Bond, podía hackear cualquier sistema informático enemigo en unos cinco segundos. Sólo enchufando un cable de red (y a veces ni eso) a su portátil. Y sin saber previamente qué tipo de sistema era ni nada. Se ve que antes los grupos terroristas usaban todos el firewall de Windows.

Por aquel entonces, yo ya sospechaba algo que confirmé después en la carrera: la informática no es magia, y uno no puede meter un pen en un servidor al azar y colapsar un satélite.

Esta idea fue haciendo poso en mi mente hasta el punto de llegar a recomendar a amigos que utilizaran antivirus gratuitos (yo uso avast!), puesto que, con un poco de cabeza, las posibilidades de que infecten tu ordenador suelen ser bastante bajas y dejarse la pasta en un antivirus de pago me parece innecesario. Ahora, con el auge de móviles Android, suele ser común preguntarse si deben utilizarse antivirus en móviles con este sistema, y de nuevo, con un poco de cabeza, no, no hace falta instalarse un antivirus.

Pero entonces WikiLeaks publicó The Spy Files: una serie de documentos y vídeos de productos, que ofrece la empresa Gamma, para espiar sistemas informáticos. Entre los más llamativos se encuentra software para intervenir BlackBerrys o escuchar conversaciones por Skype. En los vídeos siempre hablan de “agentes infiltrados” y les ponen un cartelito de POLICE en la espalda para dejarnos claro que, eh, sí, están interviniendo sistemas sin consentimiento de sus propietarios, pero que tranquilos, que son los buenos de la peli.

El problema es que la regulación en este tipo de negocio es poca o ninguna y esa POLICE, puede ser, por ejemplo, de Irán  (ese país dónde, según su líder, pero objetivamente hablando, no hay ni un sólo homosexual. Ni uno. Que oye, estadísticamente hablando, podría ser) o cualquier otro país dónde se vulneran sistemáticamente los derechos humanos. La empresa Blue Coat, que vende software de monitorización de redes, ya ha tenido algún lío relacionado, ayudando con su software a la represión siria.

Y, para colmo, hace poco un programador descubrió que el software de la empresa Carrier IQ estaba instalado en un gran número de dispositivos móviles, y que cada uno de los pasos de sus propietarios estaba siendo, sin ellos saber o consentir, grabado y enviado a sus empresas de telefonía.

Y entonces pienso en Marshall, y en cómo hackeaba sistemas en Alias sin ni tan siquiera pulsar el enter, y me digo: pues a lo mejor no era tan descabellado.

En 1984 (¡hala, ya salió la referencia apocalíptica a George Orwell!) había pantallas por todas partes que controlaban a los ciudadanos continuamente. Las pantallas, en principio, habían sido impuestas a los ciudadanos. En nuestro caso, no es sólo que quizá nos estén monitorizando sin nuestro consentimiento (que también), sino que, además nosotros estamos renunciando a nuestra privacidad casi voluntariamente.

Los twits geolocalizados me parecen el mayor despiporre en lo que a privacidad voluntariamente entregada se refiere. ¿Por qué ibas a poner la latitud y longitud exacta del lugar dónde te encuentras ahora mismo? ¿¡Por qué!? Esto lo inventan unos años antes y la ETA aún estaba funcionando.

Google sabe dónde estás. Físicamente, si tienes un móvil Android y la opción de localización activada; y digitalmente. Primero, porque utilizo Google Analytics para contabilizar el tráfico de esta página (aunque podría bloquearse con ayuda de AdBlocks), y segundo, si estáis logueados en vuestra cuenta de Google +, por el botón de +1 que hay al final de esta página. Por lo mismo, Facebook también lo sabe. No sólo saben que estás aquí, también saben quiénes son tus amigos, quizá tu familia, de tus gustos, de lo que buscas cuándo navegas. Lo saben. Y utilizan esa información. Una prueba sencilla: ve a la nueva versión de YouTube y fíjate en los vídeos de la derecha. ¿Por qué de pronto todos están relacionados con las cosas que sueles ver?

Y la pregunta que resta es: ¿importa que lo sepan?

Desde luego, importa en el caso de los software espía desplegados sin consentimiento de sus usuarios. Pero a Google o Facebook les estamos entregando  la información voluntariamente. Y, oficialmente, esa información es para ofrecernos un servicio más personalizado y, en teoría, mejor. Si no nos gusta, siempre podemos borrarnos la cuenta, y no utilizar sus servicios. Volver al Siemens A50 que utilizaba hace años, renunciando a consultar Twitter en el bus, o a poder buscar la boca más cercana de metro en una calle aleatoria de Madrid.

Todas estas inquietudes vienen porque, irónicamente, estoy a punto de empezar un proyecto en el que la información del usuario, previo aviso, será recolectada con fines educativos. Y hay veces en las que los informáticos tenemos que plantearnos cuestiones más importantes que qué es mejor, si Android o iOS (es Android).

Foto: nattydreadd

Otras entradas que podrían interesarte

  • No sé encontró ninguna entrada.
3104317041_4d701e287d

3 consejos para ahorrar tiempo programando

Programar consume mucho tiempo. Mucho. Enfrentarnos a la creación de un programa cualquiera suele tomar cuatro fases:

  1. Desarrollo inicial del programa.
  2. Corrección de errores, hasta que el programa funciona.
  3. Aceptar que tu código es basura.
  4. Empezar todo desde cero. O entregarlo tal cual.

Dependiendo del lenguaje de programación, del entorno y del programa, las maneras de ganar tiempo al deadline, son múltiples y variadas. Sin embargo, aquí os presento tres ideas que valen para todo tipo de programación, y que a mí me funcionan bastante bien. Para algunos serán obvias, pero para mí no lo eran tanto hasta hace poco.

Aprende mecanografía

Sí. Aprende mecanografía. Y eso no es saber dónde están las teclas y llegar a ellas en un tiempo razonable. No. Es saber los principios que la rigen, cómo hay que colocar las manos y con qué pulgar hay que pulsar el espacio, entre otras cosas.

Escribirás más rápido, así que programarás más rápido. De cajón.

Piensa que hubo una época, no tan lejana, en la que saber mecanografía era algo que podías poner en tu currículum, ¡y contaba como mérito!

Además, para algunos puestos, como los de funcionario, sigue habiendo pruebas de mecanografía. No es necesario que te apuntes a una academia (sí, aún existen), hay cantidad de software con el que puedes aprender, incluso herramientas online. Cuándo hayas aprendido, puedes probar Z-Type, un juego de naves espaciales en el que cuánto más rápido escribas palabras, más puntos conseguirás.

Usa un monitor de apoyo

Conozco gente que discreparía, pero tener un monitor extra programando para mí es una gozada.

En el monitor principal despliego el entorno de programación. Y en el monitor adicional, el navegador, dónde consulto APIs o busco solución a problemas que surjan programando. En fase de depuración, es el lugar perfecto para colocar la aplicación desarrollada en ejecución, evitando así que oculte el código que estás tratando de arreglar.

También realiza muy bien su función si eres fan de los tutoriales. En el monitor extra tienes la web (o el vídeo) del tutorial desplegado, y en tu monitor principal vas siguiendo los pasos.

El tiempo que ahorrarás por no tener que estar pulsando continuamente Alt + TAB es importante.

Aprende a usar librerías y úsalas

Una librería es código que otro programó y empaquetó para que fuera reutilizado. El orgasmo de la Programación Orientada a Objectos.

Aprendí la potencia de las bibliotecas hace relativamente poco. ¿Por qué? Básicamente, cuándo uno se inicia en el uso de librerías externas por primera vez resulta un infierno. No conoces los pasos y das frustrantes palos de ciego. Por eso, es importante que sepas cómo añadir librerías externas desde tu IDE (o desde consola, si eres un valiente).

En informática está todo inventado. Y si se te ocurre algo nuevo, Google tendrá algo mejor y más eficiente un par de semanas antes de que tú hayas esbozado un ridículo UML. Así que no reinventes la rueda. Antes de resolver un problema concreto, busca si alguien lo resolvió ya antes. Google es tu amigo. Google Code y SourceForge más. Ahorrarás horas, días y semanas. Sólo reinventa la rueda si tu rueda va ser más rápida y/o va a hacer más y mejores cosas que otras.

¿Alguna otra idea para ahorrar tiempo programando?

Otras entradas que podrían interesarte

  • No sé encontró ninguna entrada.
e-learning

Reflexiones de cinco años de carrera (y quince de educación elemental)

Aplica el algoritmo visto en clase

Escrito como coletilla en un enunciado cualquiera, “Aplica el algoritmo visto en clase“, es, seguramente, la mayor muestra de soberbia docente que me he encontrado en cinco años de carrera informática.

Por dos motivos: el primero, por no dar el nombre del algoritmo y, con ello, añadir como requerimiento de la asignatura, no el saber aplicar un algoritmo concreto, sino haber asistido a clase el día que se explicó el algoritmo; y segundo, dar por hecho que “el algoritmo visto en clase” es la mejor solución y que, por lo tanto, no caben soluciones distintas.

Este “aplica el algoritmo visto en clase” ejemplifica la concepción que muchos de los profesores actuales (universitarios o no) tienen de la educación: un espacio cuadrado, dónde un señor o señora enumera una serie de conceptos de una disciplina, o una serie de pasos de una técnica, a unos receptores en su mayoría estáticos y aburridos que serán evaluados de manera uniforme con un examen escrito o, Dios no lo quiera, tipo test. Y, ¡ay del que falte a clase!

Consecuencia: aprender es aburrido y monótono. Hemos llegado a un punto en el que hablar de educación, es hablar de algo con tintes negativos. No sólo por los resultados, sino por el proceso educativo en sí, que resulta frustrante tanto para alumnos como para maestros.

Sobre todo este modelo de educación, hay un vídeo genial de una conferencia de Ken Robinson, animado por RSA, y que os recomiendo ver tranquilamente (está en inglés, pero con los dibujos se entiende bastante bien).

Pero esto… ¿para qué me sirve?

Cuándo terminé la Ingeniería Técnica en Informática de Sistemas, una de las chanzas que hice en mi discurso de graduación decía algo así:

Después, comienza el primer curso en el que básicamente repasas matemáticas de bachillerato y aprendes Pascal. Los profesores al final del año totalmente desconcertados: estos chicos quieren aprender informática, les ponemos un montón de matemáticas y suspenden… No se explica.

(…)

Esto produce dos cambios especialmente significativos en nuestras vidas: El primero es que pasamos a tener un némesis o archienemigo, efectivamente, el estudiante de informática de módulo. Que sí, sabréis más que nosotros pero nosotros vamos a cobrar más; además nosotros sabemos álgebra, integrales, y calcular la mediana de unos datos estadísticos, y la ley de Ohm. Que ya veréis cuándo esteis en una reunión de trabajo y salga a relucir la ley de Ohm. A ver qué cara se le queda entonces al del módulo.

Después de mi intervención (aunque no sé si a raíz de ella), el decano de la facultad explicó la importancia de las matemáticas y la física en la formación de cualquier ingeniero. Pero, me temo, que el paso de los años lo único que me ha venido a confirmar es que esa formación ingenieril le debe más al orgullo de mantener un nombre que a la práctica.

Me gustan las matemáticas. Las encuentro atractivas y útiles. En los dos primeros años de carrera “aprendí” muchas matemáticas. Álgebra, cálculo y estadística, principalmente. Entrecomillo aprendí porque la mayoría del temario ya lo había visto en Bachillerato.

En este preciso momento, no recuerdo casi nada de ello. No recuerdo cómo se integra por partes; no recuerdo cómo hacer el determinante de una matriz; no recuerdo qué es la varianza o para qué sirve. Y no lo recuerdo por una sencilla razón: no lo he usado.

Sin embargo sí que recuerdo la geometría de bachillerato. La he usado, principalmente, en aplicaciones gráficas y juegos. La clave está en que, la primera vez que tuve que utilizarla de verdad, y no en un problema de examen, consulté la Wikipedia durante, aproximadamente, una hora. Y me equivoqué, y lo corregí. Algo que no pude hacer en la P.A.A.U..

¿Y si en vez de invertir tantos créditos de carrera en cosas que quizá uses, se reduce el número y se intenta poner más peso en cosas que tendrán más probabilidades de ser usadas? ¿Y si empezamos a darnos cuenta de que nuestro campo tiene cada vez más ramas y ramas y que en nuestros estudios no pasamos ni de las raíces?

Aprender informática sin informática

De manera empírica, he extraído una ley aplicable a la mayoría de profesores que he tenido:

El número de bolígrafos gastados en la toma de apuntes en una asignatura es directamente proporcional a la edad del docente.

Hoy, tomar apuntes a mano es una completa pérdida de tiempo. Pierde tiempo el profesor, que tiene que transcribir el ya casi ilegible contenido de sus folios amarillentos a la pizarra, y pierden tiempo de atención los alumnos mientras copian.

Entiendo que un profesor de Filosofía, al que le queden, a lo sumo, diez años en la enseñanza, no le dé la gana jubilar sus apuntes y pasarse a las diapositivas (u otros métodos, que no todo en la vida son ppt y pdf), pero no entiendo que no lo haga un profesor de Informática, que, se supone, debe estar interesado en los avances que ofrece la tecnología.

Con la ley anterior, suele estar relacionada la frase:

Huy, ¿y tú quién eres? No te he visto por clase.

pronunciada generalmente en horas de tutoría y que avanza que la predisposición del profesor a ayudarte puede ser limitada.

La asistencia a clase pronto se convertirá en un absurdo. ¿Qué sentido tiene que un profesor repita en un aula, año tras año, la misma lección? ¿Acaso no podría grabarla en vídeo el primer año y colgarla en YouTube para que todos sus alumnos tuvieran acceso a ella, a cualquier hora y en cualquier momento? Podría dedicar el resto de las horas a una atención mas individualizada. A preparar más materiales para la asignatura.

¿Y como puede ser que, en la época en la que podemos conectarnos a cualquier lugar del mundo desde cualquier lugar del mundo, con el nuevo plan Bolonia, la asistencia a clase pase a ser un mérito? Estar en un sitio a una hora no debería ser un mérito académico. ¿Cómo? ¿Qué conocimiento demuestra? ¿Saber interpretar un reloj y un plano?

He estado pensándolo un rato, antes de afirmarlo a la ligera, pero: he aprendido más en Internet que en la carrera. Es más, a proporción, he aprendido más en Internet que en todos mis años de educación. Además en clase, yo, y otros muchos, es el lugar dónde más aburrido he estado a lo largo de mi vida. Y mira que fui a catequesis hasta la confirmación. Eso tiene que cambiar.

Internet es La Fuente de Información. Y se está empezando a convertir, si no lo ha hecho ya, en el lugar dónde mas interacciones y relaciones mantenemos. Los profesores, y creo que en este caso los de Informática deberían ser los que abrieran camino, deben aprovecharse de las ventajas que este nuevo mundo tecnológico ofrece.  Impartir cursos enteros por Internet (como éste), montar tutorías on-line, fomentar el trabajo en equipo, utilizar elementos educativos, como juegos, que permitan el seguimiento individualizado…

Y sobre todo, echarle imaginación y pasión para que la educación deje de ser esa cosa aburrida que sufrimos durante un cuarto de siglo para conseguir trabajo.

Otras entradas que podrían interesarte

svgexample_svg

Dibujando SVG en Android

¿Qué es una fichero SVG (y por qué debería importarme)?

SVG son las siglas de Scalable Vector Graphics, es decir, gráficos vectoriales escalables (bien por el inglés).

Mientras las imágenes bitmaps (PNG, JPEG o GIF) se definen, simplificando mucho, en una matriz bidimensional en la que cada una de las posiciones guarda un color, las imágenes vectoriales están basadas en los pasos que se han de seguir para el dibujado de una imagen.

Por ejemplo: para definir un círculo rojo en un PNG, debemos rellenar de color rojo las posiciones necesarias de una matriz MxN, hasta crear la forma circular; para definirlo en un archivo SVG, debemos guardar la orden “dibuja un círculo con relleno rojo”.

Por supuesto, estas órdenes de dibujado SVG no están definidas con lenguaje natural, sino a través de ese lenguaje de marcado que siempre anda sacando de apuros a los informáticos: XML (Hey, ¿y si usamos XML?).

Por lo tanto, un archivo SVG es, a fin de cuentas, un XML. Texto. Tiene el siguiente aspecto:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1 Basic//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11-basic.dtd">
<svg version="1.1" baseProfile="basic" id="Layer_1"
	 xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" width="100px" height="100px"
	 viewBox="0 0 100 100" xml:space="preserve">
<linearGradient id="SVGID_1_" gradientUnits="userSpaceOnUse" x1="11.4727" y1="49.5879" x2="84.9736" y2="49.5879" gradientTransform="matrix(1.2603 0.0058 0.0058 1.2812 -11.7118 -14.1918)">
	<stop  offset="0" style="stop-color:#FF0000"/>
	<stop  offset="1" style="stop-color:#00FFFF"/>
</linearGradient>
<path fill="url(#SVGID_1_)" stroke="#000000" d="M92.189,83.321c-4.57-6.148-15.499-15.174-16.274-3.967
	c-9.521-13.716-14.235-17.953-16.272-3.964c2.037-13.989-4.004-1.625-12.318,11.351c-1.481-3.95-12.075,10.907-12.319,11.349
	C35.25,97.648,39,82.605,33.548,81.164c4.225-12.798,9.245-23.24-1.459-16.927c10.704-6.313-1.625-6.348-14.532-8.5
	c0.467-5.125-14.353-8.505-14.531-8.5c0.178-0.005,16.997-2.998,15.372-6.495c14.312-1.863,28.292-1.723,15.371-6.493
	c12.92,4.77,10.648-2.184,3.336-16.604c9.6,3.036,6.071-11.455,3.336-16.603c2.734,5.148,12.803,21.806,10.96,12.911
	c8.365,16.579,12.011,24.736,10.96,12.912c1.051,11.824,4.672,9.713,16.595-1.761c-4.377,10.673,6.851,5.054,16.593-1.763
	c-9.742,6.817-19.512,15.521-8.599,14.475c-14.709,7.438-18.141,9.899-8.6,14.474c-9.541-4.575-4.651,1.088,6.919,15.515
	C77.463,61.823,87.619,77.173,92.189,83.321z"/>
</svg>

Ventajas de SVG

La principal ventaja de los SVG respecto a otros formatos está, como su propio nombre indica, en que es escalable.

Como muestra la imagen, la calidad de la imagen mostrada en SVG no varía con el tamaño, mientras que la del PNG disminuye al aumentar el tamaño de la imagen original. ¿Por qué?

En el PNG, al agrandar las dimensiones de la imagen, expandimos la matriz contenedora de colores. Si antes teníamos una imagen de 50×50, teníamos 2.500 píxeles, cada uno de un color. Si ahora escalamos hasta tener una imagen de 100×100, tenemos que rellenar 10.000 píxeles. Y partimos de 2.500 píxeles. Los otros 7.500 hay que inventárselos, a través de un algoritmo, y de tal manera que el resultado siga representando la misma imagen. Por muy bueno que sea el algoritmo, el resultado dejará que desear.

En el SVG, sin embargo, tenemos guardados los trazos que debemos realizar para reconstruir la imagen, el gradiente que debemos utilizar para el rellenado, y el color del borde. Ahora, sólo debemos ajustar la escala de cada uno al tamaño que nos indiquen.

SVG es mucho más que un formato de imágenes. También puede definir animaciones y eventos, y es el “perfecto” sustituto para las composiciones animadas creadas con Adobe Flash. Sin embargo, lleva dando vueltas más de diez años y aún no tiene el calado que, en teoría, debería tener.

Desventajas de SVG

Por permitir la ejecución de scripts, SVG plantea problemas de seguridad, que, en principio, con buenas prácticas de programación, podrían ser evitados.

Aunque su principal desventaja, diría yo, es su falta de popularidad. Si en diez años y con sus posibilidades no ha sido capaz de tomar la web, ahora con la aparición de HTML5 y el Canvas, parece que el SVG embebido como alternativa a Flash nunca llegará.

Esto podría explicar por qué la mayoría de librerías que existen para usar SVG desde Java o Android sólo implementan la parte de dibujado, pero se olvidan de otros módulos importantes, como el de animación.

También podemos considerar una desventaja, aunque menor en los teratiempos que corren, su eficiencia: un bitmap siempre será más rápido en el dibujado que un gráfico vectorial, que requerirá una serie de cálculos adicionales.

Dibujando SVG en Android

Para el dibujado de SVG en Android, he utilizado la librería svg-android, utilizada en Androidify, una aplicación que permite crear pequeños androides con el aspecto que queramos.

La librería, tras probarla, parece estar desarrollada específicamente para cubrir las necesidades de Androidify, y apenas implementa los módulos básicos de SVG. Aún así, es suficiente para hacer un par de experimentos. Su uso es muy sencillo:

    SVG svg = SVGParser.getSVGFromResource(getResources(), R.raw.filename);
    PictureDrawable picture = svg.createPictureDrawable()

He creado una aplicación sencilla (puedes descargar el código y el apk al final de la entrada) con una intención doble: probar el dibujado de SVG en Android, y ver cómo escala Android los bitmaps de manera nativa, puesto que su primo Java (a través del Graphics2D de Java) lo hace fatal.

Bitmap y Picture

Android tiene dos clases que sirven para ejemplificar perfectamente las diferencias entre imágenes bitmaps e imágenes vectoriales. Mientras Bitmap representa una matriz bidimensional con información de colores (PNG o JPEG), Picture graba las llamadas de dibujado (dibuja línea, dibuja rectángulo, rellena de verde…) y luego es capaz de reproducirlas.

La clase Picture es perfecta para la representación de gráficos vectoriales, puesto que implementa la filosofía vectorial de guardar los pasos realizados en la construcción de una imagen. De hecho, svg-android utiliza esta clase para representar SVGs.

La aplicación

La aplicación no tiene gran misterio. Un RadioGroup para elegir la imagen a visualizar (un SVG o un PNG de 50×50), y una SeekBar para cambiar la escala de la imagen mostrada. Para resolver cualquier duda de la aplicación, puedes consultar el código adjuntado al final de la entrada.

Como puede comprobarse en las capturas (además de descubrir que svg-android no renderiza el borde negro de la figura), la distorsión del PNG es considerable en la escala máxima.

Conclusiones y archivos fuentes

A pesar de todo, los gráficos vectoriales pueden ser más efectivos en el desarrollo de aplicaciones que hacen uso intensivo de figuras 2D (como juegos), sobre todo en dispositivos Android, en dónde existen cada vez mayor número de resoluciones de pantalla.

El formato SVG es una buena alternativa para la definición de este tipo de gráficos. Existen algunas librerías interesantes, como Batik, para su procesamiento. Aunque no todas ofrezcan el procesamiento de módulos complejos, como el de animación, el renderizado escalable sigue siendo una funcionalidad muy interesante que no podremos conseguir con otros formatos.

Archivos de la aplicación

Otras entradas que podrían interesarte