Raging Bits

Easy systems, raging bits

Edición De PDF

| Comments

A la hora de lidiar con burocracia y rellenar formularios, lo ideal es escribir directamente sobre el fichero, de manera que al imprimirlo sea perfecto y no tengamos siquiera un machón de bolígrafo. Es mucho más cómodo, ya que de esta manera pueden editarse en caso de error y volver a imprimir tranquilamente, evitando correcciones y tachones poco estéticos.

Cuando el formulario está en un formato editable (.doc, .odt) no hay problema alguno, pero si está en PDF la cosa se complica. Lo que hacía antes era tomar capturas del PDF como imágenes, editarlas con GIMP y después imprimirlas. Sin embargo el procedimiento es primitivo, lento, dificultoso y debes guardar ficheros aparte de GIMP si necesitas corregir cualquier error. Lo ideal es escribir directamente en el PDF y generar uno nuevo que puedes editar otra vez y transportar cómodamente.

Todo el software que comento aquí está cómodamente disponible en los repositorios de Debian. De manera que con un sudo apt-get install lo tendremos funcionando rápidamente.

Herramientas de edición PDF

pdfedit

pdfedit es una herramienta grande y compleja que permite editar muchos aspectos de un PDF, incluyendo el añadir texto nuevo que es lo que buscamos.
Sin embargo su interfaz es un desastre, es complicado y sobre todo tan lento que es inusable. Cada operación podía tardar cerca de 10 segundos, y cuanto más lo usaba, iba a peor. El formulario de mi Erasmus lo rellené con este programa y tardé cerca de una hora. No lo dejaba porque ya iba por la mitad y había invertido demasiado tiempo como para tirarlo a la basura. Muy frustrante.

![Usando pdfedit][] Usando pdfedit con mi formulario. La interfaz es demasiado… ‘ingenieril’.

Scribus

Realmente no he probado Scribus * ya que no llegó a abrir los PDF que quería editar. Se supone que el programa acepta como entrada el formato pdf y permite editarlos y exportarlos de nuevo, sin embargo no le gustó los que tenía y el muy señorito se negó a abrirlos aduciendo que se encontraban en un formato inaceptable. Aún así,su interfaz tenía muy buena pinta**, de manera que quizás sea una opción para más adelante con otros ficheros.

![Error al iniciar scribus][] Error al iniciar Scribus con el pdf que quería editar

flpsed

Con flpsed tenemos un ganador. Es exactamente lo que buscaba, un editor de PDF/PostScript muy ligero, ágil y sencillo. Solo permite abrir PS/PDF y añadir/editar texto, pero es que es precisamente lo que buscaba. Solo permite cambiar el tamaño y el color de la letra, de manera que para muchos puede quedarse corto si pretenden realizar algo complejo o visual, pero para el uso para el que busco un editor de PDFs es sencillamente perfecto. En menos de 5 minutos tenía todos mis datos puestos sobre las casillas que se dejan para escribir en el formulario. Después, permite exportar tanto a PS o a PDF.

![flpsed en acción][] “Editando un formulario PDF con flpsed”

Otra opción interesante de flpsed es que también exporta a PS, de manera que podemos exportar nuestro PDF a PS, abrirlo con GIMP, editar algún campo si necesita tachaduras o algún tipo de grafismo más complejo (¿Estampar una firma?), guardarlo en PS y volverlo a abrir con flpsed para terminar la edición y volverlo a pasar a PDF.
Este post me ayudó mucho a la hora de orientarme y probar estos programas.

Android Screencast

| Comments

![image][]

Estas navidades para una asignatura, “Mobile Technology” desarrollé un pequeño videojuego de prueba para Android. Desde hace unos días vengo buscando la manera de grabar un vídeo del juego sin necesidad de emplear una cámara externa (cutre y baja calidad) o grabar el emulador (el cual va lentísimo). Aún no lo he conseguido, pero sin embargo he tenido una aproximación interesante mediante la aplicación Android Screencast con la cual he podido grabar un video pero que es insuficiente para las necesidades de un videojuego, que funciona a un framerate alto.

La aplicación Android Screencast sirve para manejar el teléfono desde el ordenador. Permite navegación de archivos, manejo de teclado y ratón (solo root), screenshots y grabación de video. Los pasos para utilizarlo son: Tener el sdk de android instalado Tener Java SDK 6 instalado Tener conectado el teléfono y reconocido por el server del sdk Ejecutar el archivo jnlp del programa

El programa automáticamente intenta 6 conexiones al teléfono conectado y tras eso desiste. Mis pasos para instalarlo fueron:

arl@lap$ cd android-sdk/platform-tools
arl@lap$ ./adb stop-server
arl@lap$ sudo ./adb start-server
arl@lap$ ./adb devices
List of devices attached
HT066P800146    device

Con la secuencia de comandos anterior conecto mi Nexus One al pc. Tengo que iniciar el demonio como root o de otra manera no me coge el teléfono. Un día de estos debería escribir una regla para que se monte solo con los permisos adecuados para el sdk.

Una vez conectado, ejecutamos AndroidScreencast:

gnome-open androidscreencast.jnlp

Y debería abrirse y detectar el teléfono solo, mostrando la siguiente pantalla en mi escritorio:

![image][1] Escritorio mostrado en pantalla

Ahí podemos ver todo lo que sucede en la pantalla del teléfono en ‘tiempo real’, tenemos acceso al arbol de fichero y un par de cosas más. Sin embargo no va fluido. Probablemente porque se basa en la toma de screenshots, que es horriblemente lenta. Para tomar una screen de la pantalla, el teléfono se toma su tiempo, tardando varios milisegundos. El refresco de la pantalla es mucho más rápido, de manera que todas las animaciones que se muestren en el teléfono saldrán cortadas o no saldrán en la pantalla.

En la parte superior izquierda podemos ver el botón Grabar que al pulsar nos preguntará donde queremos guardar el vídeo y comenzará el vídeo, quedando el boton pulsado. Para parar la grabación simplemente pulsar de nuevo sobre el botón y parará.

![image][2] Captura del juego

El formato de salida es .mov y empleé Avidemux para editarlo. Debo rectificar una pequeña injusticia que cometí contra Avidemux en mi anterior entrada. No es tan limitado como me pareció la otra vez, soporta una buena serie de filtros que hacen que para ediciones menores sea mucho más que suficiente. En este caso lo único que quería era rotar la imagen y suavizarla ligeramente, para lo cual funcionó muy bien.

La única dificultad fué encontrar un encoder que me aceptase .mov como entrada para generar la salida. Menos mal que Avidemux soporta bastantes formatos y el MPEG4 (xvid) me sirvió.

![Editando el vídeo con Avidemux][] “Editando el video con Avidemux”

Finalmente, el vídeo quedó subido a Vimeo y podeis verlo aquí.

Android Screencast showing a tiny test videogame from Javier Santacruz on Vimeo.

Screencast De Aplicación 3D en Linux

| Comments

Tras realizar un trabajo para una asignatura en la que escribí una pequeña aplicación en 3D, quería hacer un pequeño video de demo de su funcionamiento. El objetivo era grabar la aplicación mientras corría y añadirle al video algún que otro diagrama explicativo conforme iban sucediéndose las imágenes, de forma que quedase claro que es lo que realmente realicé en el trabajo y cuales son sus objetivos.

Lo que acabé usando fue:
Xvidcap Para la grabación del escritorio. Avidemux y LiVe Para la edición del video.

Sin embargo por el camino probé algunas alternativas, ya que el campo de la edición de video parece estar bastante verde y no me resultó nada sencillo poder montar lo que quería.

Grabar la aplicación funcionando

Como herramienta de grabación de escritorio mi primera opción fué Istanbul, el cual es un programa de captura de video de escritorio muy sencillo e integrado con GNOME que puede encontrarse en los repositorios.
Prácticamente no tiene interfaz. Cuando se arranca se queda en la barra de tareas como un botón rojo. Si pulsas sobre él, comienza a grabar, y para al volver a pulsar.
Tenía muy buena pinta y probablemente haga muy bien su trabajo para grabar simplemente el escritorio, pero mi aplicación tiene gráficos en 3D que sencillamente no aparecían en el video resultante, de manera que lo descarté como opción.

El siguiente fué el que me salió bueno: Xvidcap. Muy sencillo también consiste en una pequeña barra y un cuadrado rojo que marca el área de la pantalla que va a ser grabada. En mi sistema tenía un bug importante que no me permitía abrir el panel de opciones, sin embargo, afortunadamente, las opciones por defecto me funcionaron bien. Tras grabar el video, me generó un mpg a 10fps suficientemente bueno como para evitar trompicones. La parte negativa es que grabar el escritorio es una operación terriblemente costosa que degrada el rendimiento del sistema hasta el punto en que la aplicación se notaba que renqueaba.

Editar el video grabado

A la hora de editar el video pensaba emplear el editor web que trae Youtube, que es razonablemente rápido y muy efectivo para poner textos simples. Ya lo usé antes en este video de mi Proyecto de Fin de Carrera idiginBPEL con buen resultado. Sin embargo, tenía ganas de probar la plataforma de Vimeo, que no trae tales cosas, de manera que comencé la búsqueda de mi herramienta de edición de video.

Avidemux

Primero probé Avidemux que funciona muy bien y se ve software bastante robusto, pero que no permite otra cosa salvo cortar, pegar, redimensionar y poco más. En realidad, que haga esto y lo haga bien, no es poco.

Petazos con Kino

Mi segunda opción fué Kino que tiene una buena interfaz y parece plagado de opciones avanzadas; Sin embargo fué un fracaso total, la aplicación me lanzaba excepciones con errores de coma flotante y se caia completamente cuando intentaba exportar video, fuese al formato que fuese. Esto es lo que yo llamaría una función vital para un programa de video, de manera que me obligó a descartarlo.

Funcionalidad con sufrimiento en LiVe

Mi tercera y última ha sido LiVe. LiVe tiene una interfaz horrorosa y completamente antiintuitiva, sin embargo tras unos minutos de horror intenso he aprendido a manejarlo y a hacer lo que pretendía con el. La interfaz, en serio, es un obstáculo. Menús en popups con barras de desplazamiento que incomodan, scrolls que no funcionan, inputs numéricos sin opciones de sincronización en los que hay que ir editando los valores uno a uno. También tiene una completa ausencia de interacción con el ratón a la hora de aplicar los efectos como mover una imagen.

A pesar de ser tan feo e inusable, parecía funcionar. Eso sí, no a la primera. Inicialmente el programa petaba cuando intentaba abrir los mpg generados con Xvidcap de manera que los convertí usando Avidemux a avi y eso si pareció gustarle.

Más lento que el caballo del malo

Una vez comencé a editar, me di cuenta con horror, que no soporta deshacer acciones más allá de la última realizada. Esto significa que tienes que ir realizando backups cada poco tiempo. Un backup significa copiar totalmente el vídeo realizado y en mi caso tardaba entre 2 o 3 minutos. Después, cada efecto aplicado es escrito en disco directamente y procesa el video completo, de manera que cualquier acción me tomaba también entre 40 segundos y 2 minutos. A ese ritmo, tardé unas 4 o 5 horas en cortar el video, incluir un par de imágenes que entrasen y saliesen animadamente con efectos de alpha. Es cierto que estaba haciendo otras cosas como escribiendo funciones recursivas a petición de compañeros y comiendo galletas, pero fué realmente desesperante.

Añadir imágenes

Los pasos que seguía con el programa para añadir las imágenes .png generadas con Inkscape era realizar una selección de frames y aplicar un efecto de tipo ‘image overlay’ en el cual se me permitía poner un tamaño, posición y alpha inicial y final, pudiendo dejar la imagen fija o animándola. A la hora de realizar animaciones de entrada-salida, me cabreó bastante que las posiciones para las imágenes no soportasen valores negativos. Esto hace que no puedas mover una imagen por el borde superior-izquierdo hasta hacerla desaparecer de la pantalla y me fastidió lo que tenía en mente. Para generar nuevos frames elegía ‘generate colour frames’ y añadía frames de color blanco que insertaba antes o después de la selección.

Texto sin anti-aliasing

Hacia el final del video pretendía introducir mi nombre y la dirección de mi blog. Sin embargo el texto que añade al vídeo va sin anti-aliasing de manera que mostraba bordes tan irregulares que me dio vergüenza y lo sustituí por una imagen (que no me encajaba y terminé descartando).

Fallos al exportar

A la hora de exportar, LiVe si que está bien equipado y soporta múltiples encoders y muchos formatos. Sin embargo, como en cada paso debe haber problemas, dolor y desconcierto, cada formato tiene sus restricciones en cuanto a framerate y resolución. Primero lo intenté con el formato libre OGG Theora codificándolo en un .ogv pero al visualizar el video codificado, mostraba problemas graves con las transparencias de algunas imágenes, que salían en amarillo. Fueron momentos muy frustrantes porque ya estaba realmente cansado, el video se reproducía bien en el programa de edición, pero al exportar mostraba cosas extrañas que no podía obviar porque eran demasiado llamativas.

Ahí comenzó mi búsqueda de un encoder y formato adecuados. Cada vez que quería probar un formato diferente, debía cambiar el framerate y la resolución. En uno de los cambios, cambiar la resolución llevó 20 minutos largos más el tiempo de codificación posterior que depende del formato destino pero que no baja de 5 minutos.

Finalmente probé con el encoder ‘multi_encoder’ que es el que viene preseleccionado por defecto y vídeo en MPEG a la más alta calidad posible. Tras 35 minutos de espera, el video por fin salió limpio.

Vimeo

La subida a Vimeo fué bastante sencilla y rápida y por una vez, no me falló el sistema de subida en flash, que normalmente no suele funcionar bien con Firefox en Linux. Lo cierto es que la página tiene un excelente diseño, es agradable de usar y va como un tiro. Todo bien sin ningún problema y el video quedó subido aquí.

Conclusión

Esta ha sido la primera ‘demo’ que he editado yo mismo sobre mi propio trabajo, y definitivamente necesito encontrar herramientas nuevas para la próxima vez. Xvidcap funciona bien, pero empleando LiVeS me sentí como si estuviese editando el video empleando un palo y piedras de silex afiladas.

Con respecto al video, si hubiese podido deshacer/rehacer con comodidad, podría haber pulido mucho mejor los efectos, reencuadrado el tamaño y haberlo tocado hasta que hubiese quedado bien, pero con lo trabajoso que era cada paso, cometí un par de errores pero así se han quedado.

A la hora de elegir herramientas para realizar la grabación y la edición estos dos posts me fueron de mucha ayuda:

Impresiones Sobre La Charla De Judi Spiers the Business of Making Games the Deal and Publishing Operations

| Comments

— title: Impresiones sobre la charla de Judi Spiers "The business of making games, the deal and publishing operations" date: 2010-11-18 15:47 category: dev

tags: gaming, industry

En la Universidad de Kingston realizan charlas destinadas a los alumnos que cursan asignaturas de desarrollo de videojuegos, invitando a trabajadores de La Industria a hablar sobre su experiencia en ella.

Hoy venía a hablar a Judi Spiers, desarrolladora que ha trabajado en títulos para PC, Xbox 360 y varias plataformas móviles. El motivo principal de la charla era dar las claves a la hora de enfrentar la presentación de una idea o de un juego a una empresa distribuidora de juegos, que es la que nos va a proveer de Marketing, Testers y recursos. Desde los primeros momentos de la presentación, me pareció que el proceso es muy parecido a la Televisión, en el que uno debe presentar su idea de manera que convenza y que haga que el estudio la compre y aporte recursos a ella, no tanto por sus cualidades artísticas o técnicas sino como producto que se producirá en un plazo determinado y con un coste reducido.

A la hora de presentar una idea, se nos dieron las claves para dejar tranquilos y contentos a la gente del estudio. La presentación de un juego es un documento y una presentación a la que denomina Game Proposal en el que deben tenerse muy en cuenta las fechas, el coste y el público objetivo del producto.
La presentación de la idea y los documentos asociados, deben describir el juego perfectamente y mostrar que su realización es no solo posible sino práctica. Fecha de salida Público objetivo Coste Presupuestos Estudio de Competidores Plataforma Plan de desarrollo Equipo de producción Argumento Historia Curva de aprendizaje Como se maneja a los principiantes Descripción del gameplay Controles Tecnologías usadas

Fecha de salida

Es un concepto muy importante, que debe ser tenido en cuenta ya que es una preocupación principal para los ejecutivos, que trabajan con presupuestos y fechas. El cuando estará disponible un juego puede marcar una gran diferencia y es de lo más influyente en las decisiones de los estudios. Siempre es muy difícil pillarse los dedos, pero hay que hacerlo.

Público objetivo

Al igual que en el cine o la televisión, los videojuegos suelen estar enfocados a un público muy concreto que tiene determinados patrones que los estudios manejan, de manera que será una pregunta obligatoria a la hora de presentar un juego y tratar de que apuesten por el.

Coste y Presupuestos

El coste total del proyecto es también algo que aunque sea muy difícil de calcular, debe darse, ya que es con lo que los ejecutivos van a empezar a trabajar y da una perspectiva más real del proyecto. Debe hacerse un presupuesto aunque sea aproximado para que la proposición esté bien clara y no sea algo vago que hay que concretar.

Estudio de competidores

Esto es algo realmente importante y consiste en simplemente mostrar en que manera tu juego es diferente a los que ya hay, que aporta nuevo a la escena y por que no es uno más. También se debe mirar con quien va a competir a la hora de salir al mercado y debes tratar de vender que tiene posibilidades de diferenciarse del resto y convertirse en un producto único.

Plataforma

Esto es algo que discrimina mucho a la hora de realizar un juego, de lo que depende el coste, el tiempo, presupuestos e incluso público y que es de capital importancia a la hora de calcular todo lo demás.

Plan de desarrollo y Equipo de Producción

Los planes de desarrollo incluyen cuantos desarrolladores, disñadores y artistas se necesitarán, durante cuanto tiempo y los recursos que empleará el proyecto durante su producción.

Argumento e Historia

Como si realmente fuese un proyecto de cine, los juegos suelen presentarse junto con un High Level Concept Document, que es un documento breve que describe el argumento y la historia del juego; normalmente consta de no más de 2 páginas.

Curva de aprendizaje y principiantes

Todos los juegos tienen una curva de aprendizaje, que naturalmente debe empezar desde un nivel muy bajo y luego evolucionar. Debe preveerse la curva del juego, mostrarla y explicarla, ya que de esa manera es como se determina que clase de jugador objetivo se busca. También debe especificarse como se maneja a los jugadores principiantes que no leen el manual sino que directamente tratan de jugar. Eso es bastante importante ya que un juego con una mala curva (muy frustrante al inicio) o demasiado complicado de aprender sobre la marcha sin leer el manual está condenado al fracaso.

Descripción del gameplay

Hasta ahora realmente no hemos descrito el juego en si, es hora de que se explique como es una partida típica, como se juega y en que consiste realmente el juego y que características (features) lleva.

Controles

Esto es una parte que me sorprendió y sobre la que se hizo énfasis. Los controles del juego son de lo más importante a la hora de jugar y deben ser explicados durante el Game Proposal, especialmente si se utiliza algún tipo de periférico adicional.

Tecnologías usadas

Por lo general es necesario comentar la tecnología que se va a usar a la hora del desarrollo del juego ya que muchas de las preguntas irán dirigidas a esa materia.
Además, y se nos insistió mucho en ese punto, a la hora de presentar una idea, debemos hacer que todo el mundo en la sala firme un NDA es decir un “No Discretionary Agreement” por anticipado, en el cual se estipule que no puedan reutilizar la idea tal cual está sin vosotros. Toda la sala significa toda incluyendo las limpiadoras que pasaban por allí.

En la parte de lo que debemos preguntar están asuntos como la localización de idiomas del juego y el reparto de royalties, que es básicamente lo que vamos a cobrar y es muy importante negociarlo adecuadamente.

Si nuestro Game Proposal es lo suficientemente bueno y no solo eso, sino que es aceptado y tenemos la oportunidad de empezar a trabajar, se nos pedirá una demo del juego tras cierto plazo para demostrar que el proyecto va por buen camino y apostar definitivamente por él.

Para mostrar una Demo nos comentó las siguientes premisas: Videos de alta resolución que impreisonen (efecto ‘wow’ literalmente). Mostrar una demo jugable en el que se muestren las 3C’s: Controles, Cámara y Personaje (Character). Mostrar el potencial del juego y artwork relacionado para mostrar por donde va a evolucionar. Hacer la demo escalable ‘por si las moscas’. Luego podemos ir cortos de tiempo.

El efecto general que debe hacer una demo es el de asombrar a los que están viéndola y generar expectación ante el producto completo.

Las 3 Ces que mencioné antes son un aspecto fundamental en el diseño de un juego: que controles se van a emplear para manejar el juego, donde se va a colocar la cámara, lo cual es muy problemático, y como es y funciona el personaje principal.
Como la demo obviamente no es el juego completo, pero debe ofrecerse una visión lo más completa posible de por donde va a seguir el desarrollo y que más va a conseguirse.

Pero no todo es trabajo y exigencias para nosotros, debemos esperar de las compañias distribuidoras que nos provean de una campaña de Marketing y Testing aunque bien nos avisaron que no podemos hacer nada si deciden dar a nuestro producto una distribución y un márketing de pena bien porque no les guste o porque piensen que no les merece la pena.

Durante la charla contó un par de anécdotas sobre las típicas preguntas que los ejecutivos pueden hacer durante una presentación, y salió a colación Bing Gordon socio fundador de EA Games el cual, contaba la ponente, le preguntó durante una exposición, que que coche conducía. Cuando ella respondió que conducía un Honda Civic, la sala entera se partió la caja. Al parecer esperaban que respondiese un Ferrari.

También parece típico para los alumnos de desarrollo de videojuegos el trabajar durante el verano en la industria de videojuegos como Tester y se estuvieron comentando algunas empresas de la zona que trabajan con testers y que emplean a personas jóvenes para probar los videojuegos. Cuando un alumno preguntó que si se podía trabajar de tester para EA, Judi respondió que lamentablemente no, que EA había movido todo su sistema y equipos de testeo de videojuegos Europeos a España :–)

Y bueno, esto es todo lo que he podido sacar de mis notas de la charla que duró unos 45 minutos.

Establecer Entorno De Desarrollo JAVA ME en Linux

| Comments

Ahora que estoy metiéndome poco a poco en el mundo Java, estoy aprendiendo a programar para plataformas móviles usando Java Mobile Edition con la versión 2.5 (la 3.0 no es compatible con Linux).
Aunque es muy sencillote, me ha costado un poco encontrar información completa y clara sobre como establecer el entorno de desarrollo, tanto usando un IDE como para programar a pelo. Estos son los pasos que yo he seguido:

Tenemos dos opciones: Instalar solo el SDK y usar nuestro propio editor (vim). Instalar un IDE con todo integrado (NetBeans).

Inicialmente opino que merece mucho la pena usar NetBeans ya que la ayuda es tremenda a la hora de empezar, con los esqueletos, diferentes apis, chequeo de tipos etc… pero el editor de texto del NetBeans me pone de los nervios, de manera que se que en algún momento, en cuanto adquiera cierto control sobre lo que estoy haciendo, me pasaré a vim, así que cubriré las dos opciones a la hora de realizar el tutorial.

Ambas partes tienen en común que se necesita la maquina virtual Java de Sun de 32 bits de manera que si el sistema es de 64 tienes que instalarla e indicar donde se encuentra.

Instalar Sun Java SE (Standar Edition) 32 bits (i586)

Descargar la versión de Java SE de 32 bits de la página de Sun Descomprimir el bin:

chmod +x jdk-6u22-linux-i586.bin  ./jdk-6u22-linux-i586.bin

Una vez descomprimido, yo lo coloqué en /opt/jdk1.6.0\_22-32bit pero ya es cosa tuya.

Recuerda donde lo instalas porque vas a necesitar usar la ruta más tarde.

Ahora describiré el proceso completo de instalación para cada modo.

Solo el SDK

Nos descargamos el Wireless Toolkit (WTK) de la página de Sun: Ejecutamos el script:

./sun_java_wireless_toolkit-2.5.2_01-linuxi486.bin.sh

Donde tendremos que aceptar la licencia y nos preguntará la ruta del entorno java que en mi caso como dije antes es /opt/jdk1.6.0\_22-32bit. Después nos preguntará la ruta a donde queremos instalarlo. Yo lo hice en /usr/local/WTK2.5.2 pero puedes tenerlo donde quieras.

Ya debería estar instalado el WTK. Para crear proyectos, compilarlos y ejecutarlos en el simulador se utiliza una aplicación gráfica en java que trae el WTK llamada ktoolbar cuyo ejecutable se encuentra en el directorio de instalación del WTK, en mi caso en /usr/local/WTK2.5.2/bin/ktoolbar.

Desde la aplicación se maneja ya todo. Solo tienes que crear un proyecto, editar los fuentes con tu editor favorito y ejecutarlo desde ahi. DONE.

NetBeans

Descarga la versión de NetBeans que incluye el WTK y trae soporte para desarrollo móvil desde la página. La descomprimimos e instalamos.

code-block::bash
chmod +x netbeans-6.9.1-ml-java-linux.sh  
./netbeans-6.9.1-ml-java-linux.sh

Por defecto yo lo instalé en mi directorio home. El emulador probablemente fallará al tratar de ejecutar lo que compiles, de manera que tienes que establecer la ruta del entorno java. En concreto se hace editando el script ~/netbeans-6.9.1/mobility/WTK2.5.2/bin/emulator y estableciendo la variable javapathtowtk con la ruta del entorno.

code-block::bash
#!/bin/sh
javapathtowtk=/opt/jdk1.6.0_22-32bit/bin/

Hay que tener especial cuidadito con que la ruta termine en (..)bin/. Y con esto ya deberíamos tener instalado NetBeans con soporte para móviles. Puedes crear un proyecto de ejemplo y probarlo convenientemente.

Espero que sirva :D
Otras referencias:

Solucionar error para 64b de NetBeans: http://forums.sun.com/thread.jspa?threadID=5447892
Establecer y usar ktoolbar: http://www.linux.com/archive/articles/122050

Mover El último Archivo…

| Comments

Una de las cosas tontas en las que perdía más tiempo era a la hora de rescatar un archivo descargado con el navegador. La situación típica era la de estar trabajando en consola, ver que ha terminado una descarga en la barra de tareas (usualmente música) y no poder mover el archivo fácilmente.

Usualmente lo que descargo se va a la carpeta \~/Downloads de manera que si me descargaba pongamos un comprimido, por ejemplo music.zip tenía que mirar en el directorio \~/Downloads el último archivo modificado (rebuscando porque siempre acaba lleno de basura) y traérmelo al directorio de trabajo.

ls -t ~/Descargas | head -n 1 
mv ~/Descargas/nombre_tecleado.zip .

Con el coñazo de que si hay un directorio, ls lo lista primero y ya me tenía que poner a mirar. Aunque os parezca poco para teclear, cuando se realiza repetidamente es simplemente demasiado. Intenté acortarlo poniendo un enlace simbólico, como hago con muchos otros directorios. Lo acorté a \~/dwn pero ni por esas, seguia siendo demasiado farragoso.

Friki como es uno, me hice un pequeño script para sh que movía al directorio de trabajo el último archivo modificado en el directorio de descargas. Le puse por defecto la ruta. \~/dwn

#!/bin/sh
# Francisco Javier Santacruz López-Cepero
# 3 - 12 - 2009 
# Move the most recent modified file from SOURCE DIR TO USR DIR
# If called without arguments SRC is /home/user/dwn y destination work
# directory
# mvlast [ SOURCE DIR ] [ DESTINATION DIR ]

SRC='/home/'$USER'/dwn'
DEST=$(pwd)

# Take arguments 
if [ $# -gt 0 ] 
then
    SRC=$1
    if [ $# -eq 2 ] 
    then
        DEST=$2
    else
        echo "mvlast [ SOURCE DIR ] [ DESTINATION DIR ]"
    fi
fi

FILE=$(ls -t1 $SRC | head -n 1)
/bin/mv "$SRC/$FILE"  "$DEST" && echo "$SRC/$FILE"

Lo situé en mi home como \~/.mvlast.sh y creé un alias. (No veía muy bien meterlo en \~/usr/bin/mvlast):

alias mvlast='~/./.mvlast.py'

El script tenía varios inconvenientes:

No sabía lo que iba a mover hasta haberlo hecho. Si por error mueves un archivo .part, te cargas una descarga. Cuando descargaba varios ficheros, tenía que repetir el comando. A veces no quería exactamente la última descarga, sino otra en concreto.

Sin embargo el otro día, mientras me bajaba una .iso muy pesada, descargué también unos apuntes, tra lo cual raudo y veloz ejecuté mvlast lo que me trajo el .part de la iso, deteniendo la descarga y dejándome absorto un rato durante el cual miraba la consola extrañado con cara de imbécil.

En ese momento me replanteé reescribir el script… y ya de paso lo hice en python.
Le añadí algunas cosillas que me hacen la vida mucho más fácil:

Listado de ficheros a mover (opción -l) Mover más de un fichero (opción -n) No mover .part salvo explícitamente. Mover solo ficheros que cumplan un patrón (por ejemplo el último *.pdf)

Aquí el script. No me he parado mucho a comentarlo ni a mirar las burradas. De hecho durante el uso supongo que algo tendré que depurar ya que no está tan probado como el otro, que llevaba conmigo casi un año.

Son pequeñas cositas que vamos usando en el día a día. Supongo que habrá otro método para listar las cosas y MUY probablemente el mio no sea el más óptimo. De hecho, me animo a postear esto en busca de comentarios. Si teneis pegas decidlo :-D

Problema Con Guake en Ubuntu Maverick 10.10

| Comments

![image][]

Ayer me fijé que mi consola de Guake no estaba igual que siempre, sino que fallaba al ejecutar ciertas aplicaciones y la pantalla se desdibujaba cuando empleaba el comando man. En concreto recibía el siguiente error:

WARNING: terminal is not fully functional

Trasteando, comparé la variable de entorno TERM de la consola de guake con la de la gnome-console normal, que funcionaba bien, y en efecto la consola de Guake mostraba una terminal diferente

En Guake:
echo $TERM dumb

En gnome-terminal:
echo $TERM xterm

El error se podía solucionar temporalmente simplemente cambiando el valor de la variable TERM a xterm
export TERM=xterm
de manera que inicialmente puse esa línea en mi .bashrc y listo.

Sin embargo, buscando más información sobre el problema, encontré el track del bug en launchpad, donde se daba una solución alternativa que me gusta más.

Guake es un programa en python que se lanza mediante un script que está en /usr/bin/guake de manera que lo único que hay que hacer es modificar ese último script y añadir el export ahí.

code-block::bash
GUAKEPATH="/usr/lib/guake"  
PYTHONPATH="$PYTHONPATH:$GUAKEPATH"  
PYTHON="/usr/bin/python"  
export TERM=xterm    
exec -a guake $PYTHON -OO $GUAKEPATH/guake.py "$@"

Y santas pascuas.

Problemas Con Syslinux Y Usb-creator-gtk

| Comments

![El causante de mis penas][] El causante de mis penas

Hoy decidí liarme la manta a la cabeza e instalar la beta de ubuntu 10.10, y para ello intenté hacer un usb autoarrancable empleando usb-creator-gtk, con el que es muy sencillo crear uno a partir de una imagen .iso de una distribución.

Una vez que terminaba el proceso de crear el pendrive autoarrancable, reiniciaba y me encontraba con el siguiente error:

Unknown keyword in configuration file

Y no arrancaba.

Tras leer un poco parece ser que es un error debido a una versión antigua de syslinux, así que me lancé a buscar los deb de una versión más nueva que funcionase.

Desinstalé syslinux (también desinstala syslinux-common, usb-creator-gtk y usb-creator-common)
sudo apt-get remove syslinux

Instalé a partir de los deb más nuevos de syslinux y syslinux-common

Y por último volví a instalar usb-creator-gtk

sudo apt-get install usb-creator-gtk

Y ahora si, ya funcionó el arranque convenientemente.

Todo esto me trajo un buen rato de cabeza, pues antes comprobé el hash de la imagen para saber que no estaba corrupta, cambié de usb, lo formateé, miré la bios de mi portátil y además cada vez que se genera un usb autoarrancable a partir de una iso el proceso tarda media vida. Si a ello le unimos una conexión a internet muy deficiente, el proceso completo me cabreó lo que no hay escrito y me llevó 4 horas.

Backups en Imágenes Simuladas Mediante El Uso De Enlaces Duros

| Comments

![Disco Duro][]

Enfrentado una vez a la situación de tener que hacer backups de una aplicación con muchos gigas en datos importantes, acabé adoptando una manera interesante pero no excesivamente conocida de backup. Antes de meterme a ello, para comprender mejor el problema que resuelve y las ventajas que aporta, haré un repaso a las formas más comunes de hacer backup en entornos unix y las herramientas que usaremos en los ejemplos: tar y rsync. Que son viejos conocidos de este entorno y sencillos de utilizar o de automatizar desde scripts para poner en el cron.

Herramientas

Tar:

(De Tape Archiver): Programa antediluviano originalmente pensado para realizar copias de seguridad en cinta magnética. Crea un solo archivo a partir de una jerarquia de directorios, adicionalmente usando compresión.

Rsync:

Simplemente transmite ficheros. Es como un cp muy mejorado. Se basa en un algoritmo que le permite calcular las diferencias entre dos ficheros y mandar solo eso lo cual lo hace ideal para transmitir backups por red.

A continuación haremos un breve repaso de los tipos de backup más empleados.

1. Imagen o Snapshot

El sistema más sencillo probablemente fuese hacer un paquete (comprimido o no) con cp,  zip o tar del directorio del que deseamos hacer backup.
Por ejemplo:

$ tar -cvf dir-fecha.tar dir  
$ cp -r dir dir-fecha  
$ zip dir-fecha.zip dir

Así se obtiene una imagen del directorio… que ocupa lo mismo que el contenido directorio (según compresión). Muchas veces no es una opción. Por ejemplo, si el directorio dir ocupa 1 Terabyte y son datos críticos que necesitan copias varias veces al día, no es abordable guardar tantos Terabytes de información CADA DÍA, y quizá durante MUCHO TIEMPO. Alguno dirá: “Podemos simplemente borrar las imágenes más antiguas”. Pero… ¿Y si necesitamos esas imágenes, y si necesitamos garantizar datos durante tanto tiempo que nos quedemos sin espacio?. Tenemos un problema. El método no nos sirve.

2. Diferenciales

Lo normal es que cuando se tienen grandes volúmenes de datos, solo cambien unos pocos ficheros de un día a otro. Si se piensa, resulta ridículo copiarlo todo cada vez, replicando un montón de ficheros iguales. Tiene mucho más sentido copiar solo ESA pequeña parte que cambia, porque lo demás permanece inalterado, ya lo tenemos.
Estamos hablando de un backup diferencial, en el que cada día se calcula la diferencia (△) con respecto al backup anterior y se copia solo eso.
Por ejemplo:

Día1: dir —> dir.copia  # Primer día se copia todo.
Día2: dir —> △dir-dia2 # Siguientes días, se copia solo lo que ha cambiado.
Día3: dir —> △dir2-dia3

Después, para recuperar tal y como estaba dir en un día determinado, deberíamos empezar con la copia completa del día 1, e ir añadiendo diferencias siguiendo la cadena hasta el día deseado. Descompriendo dir.copia y aplicándole encima las △ de cada día una tras otra hasta el 3.

Esto podríamos hacerlo empleando tar o aún mejor, rsync

Usando tar

Por ejemplo con tar podríamos usar un listado list.txt que nos sirva para saber que ficheros cambian de una vez a otra. La primera vez lo copiará todo:

# A realizar cada día.  
$ tar --listed-incremental list.txt -cvf dir-$DIA dir

Con esto conseguiríamos ficheros diferenciales con lo que cambia de cada día:

dir-1.tar
dir-2.tar
dir-3.tar

Siendo el primero el que sirve de base y contiene una imagen completa. Para rescatarlas, tendríamos que descomprimir primero la base y luego el resto encima por orden:

# Descomprime dir-1, luego dir-2, luego dir-3 uno encima de otro.  
for i in dir-*; do  
  tar -xvf $i  
done

Usando rsync

Con rsync podríamos tener un directorio destino con una copia de lo que hay en dir y emplear las opciones combinadas —backup y —backup-dir=dir-$DIA para crear los △ diferenciales. De esta forma tendríamos la última versión de dir en el directorio destino, y un directorio △ dir-$DIA con los ficheros que cambiaron en cada copia.

# Copia dir en dest, poniendo las diferencias en dir-$DIA  
$ rsync --backup --backup-dir dir-$DIA dir dest 

Para recuperarla, deberíamos ir copiando y sobreescribiendo los ficheros por orden en un directorio aparte recup.

# Copia machacando en recup el contenido de los dir dia-1, dia-2 ...
for i in dia-*; do  
    cp -R $i recup  
done

Tras hacer esto, en recup tendremos el estado del directorio dir en el último día del que hayamos descomprimido.

Aunque parezca bonito, este sistema conlleva dos problemas fundamentales:

  1. Es costoso acceder a los datos tal y como estaban un día determinado.
    Los datos no están disponibles para que el administrador entre y los vea directamente, sino que hay que procesarlos aparte y puede llevar mucho tiempo.
  2. Es un sistema extremadamente peligroso… ¿Que ocurre si se corrompe la △ de un solo día intermedio? Pues que TODOS los datos posteriores son irrecuperables.
    Repito, si se corrompe dia-2, desde dia-3 a dia-10000 serán irrecuperables. Por lo general, se hace una imagen completa cada cierto tiempo, de manera que la cadena de diferencias no sea demasiado larga (y se multipliquen las probabilidades de hecatombe) pero de nuevo estamos hablando de grandes imágenes que ocupan mucho, que es de lo que veníamos huyendo. Demasiado peligroso.

3. Imágenes “diferenciales”

Y por fin, mi solución favorita.

Viendo que los diferenciales son más peligrosos que un sudo rm -rf, volvamos a la idea de las imágenes. Era una idea bonita. Un día, un paquetito completo con todo. Sencillo, directo. ¿El problema? El horrible consumo de espacio debido a la replicación de ficheros.

En ese punto, enfrentado a mis backups de 40Gigas diarios con discos por alrededor de 150G, un día pensé… ¿No podrían compartir los ficheros que no cambian los mismos datos, es decir, ser enlaces duros unos de otros? Y comencé a buscar documentación animado por esa idea.

¿Enlace duro? Se hace necesario presentar algún concepto de los sistemas de ficheros.

Ficheros y Enlaces Duros

Es solo un fichero normal...

Tiene sus distintas partes:

Descriptor: Mantiene el nombre del fichero, los permisos, fecha de creación… y guarda la dirección donde se encuentran los inodes y datos. datos: Los datos se encuentran divididos en bloques de cierto tamaño en el disco duro, enlazados en cadena osea cada uno cogido de la mano del siguiente y del anterior. inode: El inode es bloque cabecera que hace de índice de estos bloques de datos y permite acceder a ellos así como guardar información de más bajo nivel sobre el fichero. Quedamos entonces en que un fichero tiene un descriptor con información sobre el y por otra parte sus bloques de datos, indizados por el inode. El descriptor es lo que “vemos” del fichero, lo que se lista en los directorios etc…
Entonces, espera. ¿Un fichero tiene un descriptor de fichero o… …o uno o más?. En efecto, puede darse que un solo fichero tenga varios descriptores apuntando por debajo a los mismos datos, a la manera de un animal con muchas cabezas y un solo cuerpo.

image

A esto lo llamamos un enlace duro, desde “fuera” vemos lo que parecen dos ficheros, pero que por debajo es uno solo; En “la superficie” no nos enteramos de mucho y a nivel conceptual manejaremos ficheros que están ligados entre si:

Si accedemos y modificamos los datos empleando cualquiera de los descriptores, los modificamos para todos los demás. Si movemos uno de sitio, el resto no es afectado (dentro de la misma partición). Si se borra uno, los datos no se borran hasta que no desaparezca el último enlace duro. Es muy fácil cargarse datos sin querer sobreescribiendo a traves de un enlace duro, hay aplicaciones (como rsync) que lo que hacen por defecto al sobreescribir un archivo que es un enlace duro es “romper” el enlace, esto es eliminar el enlace duro y crear un archivo nuevo para no sobreescribir el anterior que es referenciado desde otra parte y que probablemente nos sea problemático si cambia.
Este comportamiento de rsync y otros programas es importante y será utilizado en el backup.

Bien, volvamos a la copia de seguridad.

La idea era hacer backups que pareciesen completos, pero en los que los ficheros que no cambian se comparten, de manera que evitásemos el horrible consumo de espacio de las imágenes y a la vez la dispersión de tener archivos diferenciales y tener que tratar con ellos.

El procedimiento es:

  1. Copiar los ficheros que cambian a un directorio llamado Actual
  2. Crear un directorio para ese dia en concreto llamado dir.$DIA De esta manera, tenemos una carpeta para cada día con la imagen exacta del estado del directorio dir en ese momento. La copia en el directorio Actual la haremos mediante rsync de manera que cuando vaya a sobreescribir un fichero, rompa el enlace y no modifique la información de los antiguos, que la queríamos tal y como está.

Un ejemplo práctico para mejor comprensión:

  1. Sincronizamos todos los datos del directorio dir al directorio Actual.

Sincronizar ficheros a un directorio

    $ rsync --delete dir Actual
  1. Creamos una carpeta específica para el día y enlazamos todos los contenidos.

Aprovechando espacio...

    $ cp -rl Actual dir-$DIA

¡Lo hemos conseguido! Tenemos lo que parece son imágenes completas de dir, cuando en realidad no ocupamos más espacio que con una sola imagen.

Ha sido un poco simple, de manera que veamos que ocurre cuando lanzamos el backup al día siguiente, tras realizarse cambios en los ficheros a guardar.

  1. Sincronizamos de nuevo con los cambios del día siguiente.

Esta vez, rsync trae un fichero nuevo llamado File3 y modifica File2 que ha sufrido cambios. Fijaos en cómo rsync rompe los enlaces duros que había entre los ficheros a sobreescribir mediante la creación de uno nuevo con un inode diferente.

image

    $ rysnc --delete dir Actual
  1. Creamos otra carpeta específica para el día y enlazamos los contenidos cambiados.

Ahora volvemos a crear otra carpeta que hará la ilusión de ser una imagen completa de dir.

Aprovechando espacio... siguiente día

    $ cp -rl Actual dir-$DIA

¡Así funciona! Cada vez que se sincroniza Actual, creamos una carpeta nueva y enlazamos los contenidos. Al final, el espacio ocupado es el tamaño de la imagen inicial más los incrementos (exactamente igual que en el backup diferencial) pero manteniendo un fácil acceso a los datos y la apariencia de imágenes completas (como en el backup mediante imágenes).

A aquella aplicación que pesaba tanto, al menos para los medios de los que disponía, se le hacían dos copias externamente desde dos sitios distintos mediante este sistema, empleando rsync a través ssh, resultando en una imagen de unos \~50Gb en cada sitio, por un total de \~100Gb. Respiré tranquilo :D

Existe información en este post, referida sobre todo a la estructura del sistema de ficheros y a las órdenes de consola puestas como ejemplo que no son del todo exactas o bien están incompletas (las órdenes acaban siendo más complejas a medida que se les añade flags y datos). Si alguien detecta errores de concepto, que no dude en hablar y señalarlo.

Cosas Que Nadie Te Cuenta Del Nexus One

| Comments

Nexus One

HTC Nexus One

Hace un par de meses, decidí darme un regalazo y obtuve a buen precio un HTC Nexus One en una portabilidad a Vodafone. Es un teléfono muy potente (Procesador 1ghz) corriendo el sistema operativo Android en su última versión Froyo 2.2.

Cuando lo elegí no pensaba en cambiar de teléfono sino en empezar a tener un pequeño ordenador en el bolsillo y lo cierto es que lo uso tanto que no me separo de el.

Este post no es una queja o crítica, solo que existen algunas cosas de las que he tenido que darme cuenta por mi mismo y que no he leido antes junto a la información relativa al teléfono, y eso que ha dado muchísimo que hablar.

Allá vamos con las pequeñas reservas del Nexus, todo junto, bueno y malo.

Nexus One Horizontal

“Hay que procurar no tapar la antena, situada en la parte superior.”

La carne de burro no es transparente

Si cubres con la mano la parte superior del teléfono, lo cual es habitual al sostenerlo en horizontal, la cobertura se reduce drásticamente tanto wifi como 3G.

Resulta evidente donde está situada la antena, y lo cierto es que se hace algo pesado tener que sujetarlo con dos dedos por esa parte so pena de bajar hasta dos o tres rayitas (unidad estandar de medida de cobertura) la recepción.

Así es, al menos mi terminal, comprado en Junio de 2010, es libre de emplear tarjetas SIM de cualquier otra compañía.

De esto me di cuenta al… tratar desesperadamente de liberarlo. Existen multitud de páginas web, a cual más patética y con peores intenciones, que ofertan servicios de liberación para el Nexus, y los resultados de Google se encuentran completamente copados por ellos, de manera que no es fácil dar con que… no tienes que hacerlo.

El Market oficial de Android…

![Android Market][] “No tendrían que trabajar mucho para mejorar el Market de Android…”

… es bastante malo. No por motivos técnicos complejos, seguridad o falta de variedad, sino por una carencia tan necesaria y sorprendente (viniendo de Google) como es la categorización y la búsqueda.

Podríamos perdonar una categorización demasiado general y en ocasiones errónea debido a que es un Market donde uno sube su aplicación donde le parece y las revisiones se hacen a posteriori.

Pero lo de la búsqueda si que es un fallo determinante. No se pueden filtrar aplicaciones por valoración, tiempo, popularidad, nº de comentarios… nada; los resultados además, son imprecisos y responden muy mal a las variaciones en las peticiones de búsqueda.

Mal, mal… a pesar de ello en el market hay muchas cosas y se encuentra lo que se quiere, pero no es precisamente un sitio fácil para buscar aplicaciones o encontrar otras nuevas.

Por último, y quizás para evitar dejar mal sabor de boca al terminar:

Tethering… ¡Wifi! Comparte internet sin cables

![Tethering][]

La nueva versión de Android, Froyo 2.2 trae de serie el Tethering via Wifi. Lo que hace el sistema es crear un Punto de Acceso Ad-Hoc sorprendentemente configurable (Wep, WPA, filtros…) al cual se puede uno conectar como si fuese el router de su casa… pero en medio de la sierra.

El Tethering ya lo probé por cable empleando la aplicación EasyTether y lo cierto es que me salvó de un aburrido y largo viaje en coche, donde tuve acceso al correo, svn, ssh desde el portátil y pude estar como en mi casa.

Como nota de aviso, se supone que al menos Vodafone se reserva el derecho a detectar que haces Tethering y subir automáticamente la cuota de tu tarifa si lo haces, aunque en mi caso no me han pillado.

Conclusión

Cuando hago pequeños comentarios sobre estas cosas, mucha gente se sorprende para bien y mal. A mi me hubiese gustado ser consciente de estos detalles desde el principio. Espero que a alguien le sirva de ayuda.