Archive for category ecosistema

Repositorio remoto con git

Para que no se me olvide si tengo que volver a hacerlo (y por si alguno de vosotros no lo sabía ya). Está basado en este artículo pero adaptado a mi uso particular.

$ cd miproyecto
$ git init
$ vi notas.txt
$ git add .
$ git commit -m "Primer commit"
$ cd ..
$ git clone --bare miproyecto miproyecto.git
$ scp -r miproyecto.git usuario@servidor:repos
$ cd miproyecto
$ git remote add origin usuario@servidor:repos/miproyecto.git

Hasta aquí tenemos en nuestro espacio de trabajo un repositorio sincronizado con el remoto “origin”. A partir de ahí ya podemos tener a más compañeros trabajando con nuestro repositorio haciendo:

$ git clone "url hasta miproyecto.git en servidor"

Si con ssh accedemos al sistema de archivos en el servidor remoto veremos que hay una carpeta llamada “repos/miproyecto.git”, pero si queremos replicar el contenido podemos hacer:

$ git clone "trayectoria hasta repos/miproyecto.git"
$ git pull

Tengo que ver cómo simplificar muchas de estas tareas y cómo usar ramas, en este sentido tengo aún pendiente leerme este artículo.

Tags:

Autotest con sonidos

Para celebrar mi cumpleaños pretendía estar un día con un par de ex-edenitas ( y @despo), pero apenas me dió tiempo a responder a un puñado de tweets que inundaron mi timeline de buena mañana (gracias a Enrique “Community Manager” Comba). Me llamaron de la guardería porque niño2 había comenzado a presentar unas manchas en la piel. Así que tocó ir de visita a la pediatra para que me dijera (traducido del klingon, en su dialecto hipocrático, al castellano):

“No tenemos ni idea de qué se trata, así que no lo lleves a la guardería en un par de días”.

Al menos he tenido un ratico a la hora de la siesta para jugar un poco. Lo cierto es que mi objetivo era otro, empezar a preparar una codekata para presentarla como agilismo.es en la próxima XGN. Pero un comentario de esta mañana con Enrique me hizo buscar en Google: “autotest sounds”. Y la liamos. :-)

El resultado: encontré en un viejo blog un plugin de autotest que permitía emitir un sonido para cada evento. Funciona. Pero yo ya tenía otro plugin para que, usando libnotify, me mostrara un mensaje emergente. Y aparentemente no son compatibles. Mmmm. Charlando con le dije que “add_hook” (el nombre del método) parece indicar una semántica en la que se contemplan más de un “hook”, porque insinúa que se añaden a una lista que luego (internamente) el componente recorrerá. Así que no me conformé.

Hasta que leí en el enlace que me pasó (el código fuente del propio Autotest):

If a hook returns a true value, it signals to autotest that the hook was handled and should not continue executing hooks.

Y entonces se me encendió la bombilla. Al final de cada uno de los métodos Autotest.add_hook escribí “false”, con lo que me aseguraba que se procesarían todos los métodos de todos los plugins para ese evento. Fácil. :-)

Eso sí, lo de tener el autotest con los sonidos es divertido las dos primeras veces, sobre todo si estás mucho tiempo en rojo. ;-)

LA FOTO: Una tarta de cumpleaños hecha por mi madre. Excelente repostera y otras muchas cosas más. :-)

Por cierto, muchas gracias a todos los que habéis tuiteado para felicitarme. Os agradezco mucho esos segundos que habéis empleado en acordaros de mi. Un abrazo a todos (y todas).

Tags: ,

Empezando con RSpec

Los que me conocen de cerca saben que siempre estoy intentando aprender cosas nuevas. Es la única manera que conozco para no quedar desactualizado en un sector tan exigente como el nuestro, sobre todo si quieres seguir viviendo de él hasta los 67 o más allá. Y la juventud viene con mucha fuerza. Empieza a dar un poco de respeto ver a gente como , , los y otros muchos. Programan en lenguajes que me son completamente desconocidos y están constantemente aprendiendo cosas nuevas. Pero lo peor de todo es que ¡¡tienen mucho tiempo libre!! ;-) Así que no tengo más remedio que ponerme las pilas si no quiero quedar definitivamente arrinconado junto a los libros de “Aprende Java en 15 días” o, peor aún, junto a los de “Guía Práctica de dBase III” (todos enmohecidos y arrugados por el paso de los años). ¡Qué demonios! Hace mucho (muuuuucho) yo programaba en BASIC, en C, en C++, en COBOL, en LISP… así que simplemente porque mi lenguaje para programar en los últimos ¿diez? años haya sido prácticamente sólo uno (Java) no quiere decir que no pueda aprender cualquier otro. Así que vamos a ello. Vamos a aprender otra cosa: por ejemplo, Ruby.

Ya me he hecho las RubyKoans (que, por cierto, las tengo que volver a hacer porque con una sóla vez no me es suficiente). También me he comprado el libro “Programming Ruby 1.9″ (pero sólo con comprarlo no es suficiente). Necesito practicar. Y para practicar necesito un mínimo ecosistema. No, no es una excusa: vamos a ver cómo lo voy aprendiendo y construyendo.

RSpec

Entorno: Ubuntu 10.10 + Ruby 1.9.2

Antes que nada he de reconocer que no sé bien qué hice para tener Ruby 1.9 en Ubuntu. El que viene por defecto es 1.8 y yo me lié bastante intentando poner “rvm”. Al final lo conseguí con la ayuda de , pero lo cierto es que no sé bien qué hice.

Pero si consigues instalar “rvm” el resto es mucho más fácil. Puedes instalar cualquier versión de Ruby y todo el entorno es mucho más controlado.

$ rvm install 1.9.2
$ rvm use 1.9.2
$ rvm gemset create tdd
$ rvm use gemset 1.9.2 --default

Para empezar con RSpec hay que instalar la gema “rspec”.

$ gem install rspec

En ~/.rspec tengo:

--colour
--format documentation

De esta forma se ve mucho mejor el resultado de la ejecución.

Autotest

Con esto ya podríamos empezar con RSpec, pero ya que hay una utilidad llamada autotest que nos permite evitar tener que ejecutar los tests cada vez y, dado que soy muuuuuuuuuuuuuuy vago (como buen programador) ;-)

Escribo un poco de memoria y echando mano de mi .bash_history, así que es posible que se me haya pasado algo.

$ gem install autotest
$ sudo apt-get install libnotify-bin
$ gem install test_notifier

En ~/.autotest tengo lo siguiente:

Autotest.options[:quiet] = true
require "test_notifier/runner/autotest"

De esta manera configuro las notificaciones para que aparezcan como una nota emergente, al estilo “growl”. Desgraciadamente no he conseguido en Ubuntu nada parecido a Growl (sólo en Mac) :-(

Hola Mundo

$ mkdir ejemplo ; cd ejemplo
$ mkdir spec
$ mkdir lib

En spec vamos a poner el test que escribiremos con RSpec

asdf
asp
fds
';document.write(content);
1
En lib vamos a poner el código que escribiremos en Ruby

Y además en ejemplo/autotest/ hay que incluir un fichero discover.rb que diga:

Autotest.add_discovery { "rspec2" }

De esta manera, autotest puede encontrar las specs y ejecutar rspec sin decirle nada explícitamente.

Arrancamos autotest para no tener que andar ejecutando rspec cada vez. Una notificación emergente me dice “1 example, 1 failed”. Bien. Está funcionando correctamente. En la consola donde se está ejecutando autotest veo:

Rspec Greeter
  should say 'Hello RSpec!' when it receives the greet() message (FAILED - 1)

Failures:

  1) Rspec Greeter should say 'Hello RSpec!' when it receives the greet() message
     Failure/Error: greeting = greeter.greet
     NoMethodError:
       undefined method `greet' for #<RSpecGreeter:0x00000001a48e80>
     # ./spec/greeter_spec.rb:6:in `block (2 levels) in <top (required)>'

Finished in 0.00042 seconds
1 example, 1 failure

Editamos greeter.rb para pasar el test.

asdf
asp
fds
';document.write(content);
1
Al guardar la modificación, autotest ejecutará rspec por nosotros y en la ventana donde se ejecuta autotest aparecerá el resultado de la ejecución y una notificación emergente aparecerá en verde indicando que hemos pasado “1 example”, es decir, que se ha ejecutado 1 test correctamente.

Rspec Greeter
  should say 'Hello RSpec!' when it receives the greet() message

Finished in 0.00038 seconds
1 example, 0 failures

De momento sólo estoy conociendo la herramienta. Hay que conocer las herramientas, claro, pero no es lo principal. Tengo que aplicarme con la lectura de “The RSpec Book”, aprender bien cómo usar RSpec y Cucumber y, sobre todo, practicar mucho para escribir buenas especificaciones ejecutables. Ése es mi objetivo. En eso quiero destacar y ser lo mejor que pueda.

Por supuesto, si veis alguna incorrección o tenéis cualquier sugerencia o comentario, estoy deseando leer vuestros comentarios.

FOTO: La imagen que ilustra este artículo es de Enrique Comba y representa el respeto que me dan esos chavales que vienen por detrás pisando fuerte y que, afortunadamente, me estimulan a no relajarme. <ironic_mode>El personaje fotografiado he de reconocer que, afortunadamente, no me suena de nada. Seguro que a tampoco.</ironic_mode>

 

ACTUALIZACIÓN:

La verdad es que ni me acordaba de dónde había sacado la mayoría de la ayuda para configurar. Creía que había sido de Enrique, pero Alberto Rodríguez me lo acaba de recordar. La mayor parte de la culpa de esta configuración tan chula es suya. Lo dicho, ¡¡esta gente dan verdadero miedo!! :-D

Tags: , , ,

Eclipse en colores

Por si queréis probar con los colores en Eclipse. El leer mejor (más fácil) nuestro código nos puede ayudar a escribirlo mejor. :-)

Yo he cambiado el color de fondo y he resaltado algunos elementos sintácticos:

El color de fondo:
Window > Preferences > General > Editors > Text Editors > Appearance color options:

  • Background color = color personalizado R:217, G:217, B: 236 (un gris clarito para distinguir la ventana de edición del resto pero suficientemente clara para no tener que hacer muchos cambios en el resto de colores)

Colores “sintácticos”:
Window > Preferences > Java > Editor > Syntax Coloring > Java:

  • Inherited Method Invocations : Pink (R: 255, G: 0, B: 255). Esto hace que las llamadas a métodos heredados destaquen pero no demasiado.
  • Method Declarations: Orange (R: 255, G: 128, B: 0) y negrita. Esto hace que el inicio de un método destaque sobre el resto del código.
  • Methods: Dark green (R: 0, G: 128, B: 0) y negrita. Esto hace que los verbos destaquen frente a los sustantivos.

En fin, espero que os resulte útil. :-)

Tags: ,

Separando configuraciones en Eclipse

Últimamente no hago más que probar IDEs. Sí, seguramente es que me aburro mucho. Bueno, el caso es que mi IDE preferido es Eclipse. He probado muchos y no es que sean peores (me ha gustado mucho IntelliJ su versión de pago por su colección estupenda de plugins y por el estupendo soporte para Grails), pero es que llevo muchos (quizás demasiados) años usando Eclipse y me da pereza cambiar. He probado también NetBeans, pero sigo sin conseguir ver que sea suficientemente mejor como para justificar el cambio. También he probado el Aptana para Rails y tiene buena pinta, pero creo que aún no tengo criterio suficiente para decidirme sobre un IDE en este entorno.

Bueno, el caso es que probando, probando… me ha vuelto a surgir la necesidad de tener varias configuraciones de Eclipse. Llevo mucho tiempo sufriendo la degradación de mi IDE cuando pruebo plugins que no están del todo bien, o cuando va pasando el tiempo y pruebo a desarrollar con Android, y con Grails, y con …. y al final la configuración del IDE es tan grande que empieza a degradarse todo. Y recordé que hace mucho estuvimos buscando, en una empresa donde trabajé, una manera de tener las instalaciones de Eclipse distribuidas remotamente para que todos pudieramos sentarnos en cualquier puesto de trabajo de la oficina, sin tener que depender de instalaciones locales.

Podría optar por tener varias instalaciones completamente separadas, pero me parece un poco excesivo. Es una solución sencilla, rápida y funciona, pero me parece excesivo. Así que decidí complicarme la vida y buscar en la web de Eclipse sobre las opciones de arranque (recordaba algo, así que no fue difícil).

Mi última instalación está en C:\eclipse-java-helios-win32\eclipse (sí, mi portátil tiene Windows, ¿qué pasa? :-( ) Como veis, no me complico mucho la vida. Despliego el zip directamente en C: con el nombre del propio zip. Así que la estructura que tengo para esta configuración por defecto es:

  • configuration/
  • dropins/
  • features/
  • p2/
  • plugins/
  • readme/
  • .eclipseproduct
  • artifacts.xml
  • eclipse.exe
  • eclipse.ini
  • eclipsec.exe
  • epl-v10.html
  • notice.html

Así que decidí crear un acceso directo con el que llamar a eclipse.exe con el parámetro -configuration C:\eclipse-java-helios-win32\eclipse\configuration-alternativa

Arranqué y todo parecía ir bien porque cambié el workspace de inicio y, según la configuración que usara me proponía uno distinto para arrancar. Pero arranqué con la configuración alternativa, instalé “Google Plugin for Eclipse” desde el nuevo “Eclipse Marketplace” y al arrancar con la vieja configuración me encontré con que también se veía ahí el nuevo plugin. Claramente no había tenido éxito.

Así que eliminé el plugin para dejar la configuración como antes (creo que hay una opción para volver atrás, pero nunca he sabido cómo es y no me apetecía desenfocarme) y moví la carpeta configuration-alternativa a C:\Users\jmbeas\eclipseConfigurations\alternativa\configuration. Modifiqué el acceso directo para ejecutar Eclipse con esta configuración alternativa y vi cómo, al arrancar, se creaba un fichero artifacts.xml y varias carpetas justo en el mismo nivel que la carpeta configuration.

  • configuration/
  • features/
  • p2/
  • plugins/
  • artifacts.xml

Y ahora tengo mi configuración para empezar a jugar con el Google App Engine completamente separada de la que tengo para jugar con Java o de las que tendré para jugar con Android u otras cosillas que quiera ir poniendo.

Espero que os resulte útil.

Tags: , ,