Vim tiene varios comandos de autocompletado, personalmente suelo usar omni completion y el comando que busca palabras del fichero actual pero hay otros que conviene conocerlos y habituarse a usarlos.

Estos comandos son llamados desde el modo de inserción con la combinación de teclas CTRL-X y luego CTRL-<modo de autocompletado>. Cuando empiezas a escribir una palabra invocas el comando, se abrirá un popup con las coincidencias de la palabra que hay justo delante del cursor y para moverte entre ellas CTRL-N para saltar a la siguiente(Next) y CTRL-P para volver a la previa (Previous).

Ahora que sabemos como manejarlo vamos a ver algunos de los diferentes modos:

Omni completion

Para invocarlo CTRL-X_CTRL-O , este comando es “inteligente”(en cierta medida y según la configuración) porque las coincidencias que te ofrecerá estarán relacionadas con el contexto.

Si abrimos un fichero con un script en Ruby, escribimos  ”5.” (cinco punto) y seguido pulsamos CTRL-X_CTRL-O nos mostrará todos los operadores y métodos de la clase Integer. Por esto digo que tiene algo de inteligente.

Ocurre algo por el estilo si usamos este modo con un fichero CSS:

Simplemente invoqué el comando y me mostró las coincidencias

Autocompletado con palabras del fichero actual:

Para invocarlo CTRL-X_CTRL-N. Este comando no es inteligente, simplemente autocompleta la palabra buscándola entre las palabras claves de fichero actual.

Imaginad que tenemos el siguiente texto y tenemos que desarrollar una tesis sobre ello:

“El músculo esternocleidomastoideo (Sternocleidomastoideus) es un músculo de la cara lateral del cuello, en la región anterolateral; largo, robusto, constituido en su tramo torácico por dos manojos o cabezas: la esternal, cilíndrica, y laclavicular, aplanada. Entre ambas dejan el triángulo de Sédillot, que permite un acceso a la vena yugular interna para establecer una vía.” – Texto sacado de la wikipedia.

Escribir la palabra esternocle… es largo y tortuoso, con este comando será menos tortuoso.

Autocompletado con palabras del fichero actual y los incluidos:

Para invocarlo CTRL-X_CTRL-I. Este comando funciona exactamente igual al anterior pero además de buscar en el fichero local busca las palabras clave en los ficheros incluidos.

Este comando según como tengas configurado ‘complete’ funciona prácticamente igual que CTRL-N , personalmente uso este último porque es mas fácil de recordar y configurable.

Autocompletado de una línea entera:

Para invocarlo CTRL-X_CTRL-L. Este comando no acostumbro a usarlo porque intento ser DRY, si lo usas mucho programando eres poco DRY

Un ejemplo gráfico con un fichero CSS:

Empecé a escribir la propiedad “font” e invoqué el comando.

Autocompletado de tags:

Para invocarlo CTRL-X_CTRL-]. Este comando autocompleta el texto delante del cursor buscando la coincidencia en la lista de tags.

La lista de tags hay que generarla previamente. En proyectos Rails usando  rails.vim tenemos el comando :Rtags o lo puedes hacer a mano con Exuberant Ctags. Este es un autocompletado que no uso así que no me viene a la cabeza un caso de uso concreto pero he pensado que podía ser útil a otras personas.

Autocompletado de ficheros:

Para invocarlo CTRL-X_CTRL-F. Este comando autocompleta paths y ficheros desde el directorio en el que te encuentras actualmente. Funciona muy bien porque reconoce rutas relativas y absolutas.

Un ejemplo gráfico con un fichero HTML:

Invoqué autocompletado sin escribir nada

Hay otros comandos de autocompletado que no he nombrado(por ej. las sugerencias de ortografía o el autocompletado de definiciones y macros). Si los queréis ver todos o profundizar sobre el tema os recomiendo la ayuda de Vim :help ins-completion

¡Esto es todo por hoy!

Casualmente en el stand up meeting matinal de hoy uno de los chicos de Chile(Leo) tuvo el mismo problema y las soluciones han sido similares. Aquí os las dejo por si os ocurre lo mismo.

La versión para cucumber:

Y la solución para RSpec de Leo:

Si no usas selenium(el tag @javascript en cucumber) y usas la emulación de javascript de capybara(tag  @emulate_rails_javascript) la pulsación del botón aceptar en el diálogo de confirmación es automágica y no necesitas nada mas.

Saludos y que os vaya bonito.

Recomiendan instalar prawn (y prawn-labels) como submódulo y eso por suerte está contemplado en los despliegues con Capistrano, al menos parcialmente, añadiendo la siguiente variable a nuestro deploy.rb:

set :git_enable_submodules, true

Ver fichero: capistrano/lib/capistrano/recipes/deploy/scm/git.rb

De todos modos al hacer un nuevo despliegue la cosa seguía fallando. Siguiendo el proceso a mano resulta que Capistrano solo hace el init y update de los submódulos “raíz”. Quiero decir que si estos tienen mas submódulos no son tenidos en cuenta.

Finalmente dándome un paseo por Internet encontré la solución, se trata de la gema capistrano-deepmodules de morhekil. La cosa es muy simple:

1. Instalamos la gema “morhekil-capistrano-deepmodules”
2. Añadimos en nuestro deploy.rb: “require ‘capistrano/deepmodules’”
3. (Opcional) podemos quitar de nuestro deploy.rb: “set :git_enable_submodules, true”

That’s all folks!

Conectamos a nuestro servidor e iniciamos el repositorio con git:


$ ssh usuario@rafagarcia.net -p 333
$ mkdir foo.git
$ cd foo.git
$ git --bare init


Nota: Paso la opción “bare” para que en ese repositorio solo almacene los deltas y no los ficheros, si vas a navegar por los ficheros desde el servidor no la pongas.

Ahora para añadir ficheros desde nuestro repositorio local:


$ mkdir foo
$ cd foo
$ git init
$ touch README
$ git add README
$ git commit -m 'my first commit'
$ git remote add origin ssh://usuario@hostname:333/home/usuario/foo.git
$ git push origin master


Nota: No olvidar poner el protocolo en la url (“ssh://”).

Esta información ha sido fusilada de los siguientes sitios(thanks!):

• http://blog.commonthread.com/2008/4/14/setting-up-a-git-server
• http://www.bramschoenmakers.nl/en/node/720

La ventaja de tener la home en una partición separada en estos casos tiene un gran valor.

Por otra parte los datos que quería conservar eran:

• Algunos ficheros de configuración (/etc)
• Mis bases de datos (/var/lib/mysql)
• Gemas, paquetes autogenerados, librerías ruby,… (/usr/local)

Antes de reinstalar saqué un listado de todos los paquetes que tenía instalados con el siguiente comando:

  $ sudo dpkg --get-selections > MY_PACKAGES

Ahora ya estaba preparado para reinstalar. Al reinstalar le dije que quería usar como home mi antigua partición, sin formatearla por supuesto

Una vez reinstalado el sistema, restauré los repositorios de paquetes y de pasó aproveché a hacer limpieza (quité ppas que no usaba), con copiar el directorio etc/apt de la copia valía.

Como solo tenía añadidos PPAs los añadí a mano con el siguiente comando:

  $ sudo add-apt-repository ppa:

Dejé que el sistema actualizara todos los paquetes y mientras copié el directorio /usr/local dentro del nuevo sistema. Aquí tengo todas las gemas y librerías de Ruby, además en /usr/local/src guardo los fuentes y paquetes generados por mi, así que solo tuve que instalarlos de nuevo.

Ahora ya podía reinstalar todos los paquetes, para ello usé el siguiente script:

  #!/bin/bash
  # Get MY_PACKAGES then reinstall every package
  # To generate MY_PACKAGES: sudo dpkg --get-selections > MY_PACKAGES
  for pkg in `cat MY_PACKAGES | egrep -v deinstall | awk '{print $1}' | egrep -v '(dpkg|apt|ruby|sphinx)'`;do
    aptitude -y install $pkg
  done

Notas:

• Le pongo el parámetro “-y” para que responda yes a todas las preguntas
• Hago install en vez de reinstall para instalar solo lo nuevo.
• El último “egrep” excluye los paquetes que me creé yo para que no me los pise con los de la distribución.

Al terminar la instalación de todos los paquetes solo me faltaba recuperar mis bases de datos. Para ello paré MySQL:

  $ sudo /etc/init.d/mysql stop

Copié todo directorio /var/lib/mysql al nuevo sistema y arranqué de nuevo mysql:

  $ sudo /etc/init.d/mysql start

Arrancó, pero me salía el error:

'Access denied for user 'debian-sys-maint'@'localhost'

Esto lo solucioné conectando con el cliente de MySQL y cambiándole el password a ese usuario:

$ mysql -u root

> GRANT ALL PRIVILEGES ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY PASSWORD '
' WITH GRANT OPTION

A veces toca hacer deployment de aplicaciones que no tienen nada que ver con rails, el caso mas claro unas páginas estáticas(solo subir ficheros, sin migration, ni restart).

Para eso Lee Hambley hizo la gema railsless-deploy, básicamente lo que hace es quitar las “railties” de Capistrano. Con esta gema y un pequeño cambio en tu fichero Capfile puedes “deployar” lo que quieras.

Por una vez no me voy a enrollar y a escribir paso a paso un ejemplo porque creo que con las explicaciones que hay en la página de la gema es suficiente.

“Solo puede deployar uno” – Los inmortales

Para entendernos, si el usuario iba a http://bar.com con su navegado en inglés debía redireccionarlo a http://en.foo.com pero sin cambiar la dirección del navegador.

Lo primero que probé fue el típico:

  RewriteCond %{HTTP:Accept-Language} ^en
  RewriteRule ^/$ http://en.foo.com [L]

  RewriteCond %{HTTP:Accept-Language} ^pt-BR
  RewriteRule ^/$ http://br.foo.com [L]

  RewriteCond %{HTTP:Accept-Language} ^pt
  RewriteRule ^/$ http://pt.foo.com [L]

  ...

  #Default Language
  RewriteRule ^/$ http://foo.com [L]

Esto hacía la redirección pero al ser a otro dominio la hacía como si le pasáramos el flag R (vamos que hacía: [R,L]). Mas info sobre esto aquí.

La solución vino del módulo mod_proxy, y lo que he hecho ha sido usar el parámetro P (force proxy). La cosa ha quedado así:

RewriteCond %{HTTP:Accept-Language} ^en
  RewriteRule ^/$ http://en.foo.com/ [P,L]

  RewriteCond %{HTTP:Accept-Language} ^pt-BR
  RewriteRule ^/$ http://br.foo.com [P,L]

  RewriteCond %{HTTP:Accept-Language} ^pt
  RewriteRule ^/$ http://pt.foo.com [P,L]

  ...

  #Default language
  RewriteRule ^/$ http://foo.com [P,L]

That’s all folks!

Un ejemplo de entorno multistage podría ser el siguiente:

• mi máquina de desarrollo
• un servidor de aceptación
• un servidor de producción

Supongamos que mi máquina de desarrollo la actualizo a mano y los otros dos stages los quiero hacer con Capistrano. Capistrano por defecto solo sabe “deployar” y no es capaz de diferenciar entre aceptación y producción. Para ayudarle a diferenciar entre los diferentes stages podemos seguir varias estrategias.

Vamos a empezar por el mas simple de los casos, supongamos que entre aceptación y producción lo único que cambian son los datos de los roles. Una solución muy simple podría ser añadir a nuestro deploy.rb lo siguiente:

  if ENV['DEPLOY'].upcase == 'PRODUCTION'
    puts "*** Deployando en producción"
    role :web, "www.production.com"
    role :app, "app.production.com"
    role :db,  "db.production.com", :primary => true
  else
    puts "*** Deployando en staging"
    role :web, "www.staging.com"
    role :app, "app.staging.com"
    role :db,  "db.staging.com", :primary => true
  end

El código añadido es bastante simple, si la variable de entorno DEPLOY tiene el string ‘PRODUCTION’ ejecutaremos el deploy en la máquina de producción, sino se irá a staging. La ejecución se haría de la siguiente manera:

  $ DEPLOY=production cap deploy

Para probarlo sin tener que subir toda una aplicación a nuestros servidores podemos crear una tarea simple y estúpida como esta:

  task :foo do
    run "uptime"
  end

Entonces ahora lo podemos probar de nuevo:

  $ DEPLOY=production cap foo
  *** Deployando en producción
  ...

  $ cap foo
  *** Deployando en staging
  ...

Vale, funciona pero me chirría un poco, ¿no sería mejor hacerlo en el idioma de Capistrano? -aquí es donde todos al unísono debéis decir: SÍIIIIIIII. Entonces vamos a hacer algo parecido encadenando las tareas.

Si recordáis el día del taller os expliqué que con Capistrano podíamos definir varias tareas y llamarlas una detrás de otra, eso es lo que vamos a hacer. Vamos a considerar la configuración de cada stage una tarea diferente:

  task :production do
    puts "*** Deployando en producción"
    role :web, "www.production.com"
    role :app, "app.production.com"
    role :db,  "db.production.com", :primary => true
  end

  task :staging do
    puts "*** Deployando en staging"
    role :web, "www.staging.com"
    role :app, "app.staging.com"
    role :db,  "db.staging.com", :primary => true
  end

Utilizando este método el deploy o la ejecución de tareas en un stage u otro se hace de manera mas natural(sin usar variables de entorno):

  $ cap staging foo
  * executing `staging'
*** Deployando en staging
  * executing `foo'
  * executing "uptime"
    servers: ["localhost"]
Password:
    [localhost] executing command
 ** [out :: localhost] 01:39:08 up  2:25,  5 users,  load average: 0.01, 0.07, 0.05
    command finished

Si nos fijamos en el log de Capistrano vemos que primero ejecuta la tarea “staging” y luego ejecuta la tarea “foo”, que es lo que comentaba del encadenamiento de tareas.

Esta estrategia a mi me parece muy útil cuando los cambios que se necesitan para desplegar en producción y staging son mínimos. Considerando un cambio mínimo el cambio de variables.

Sin embarbo, esta estrategia no me parece limpia si ya se cambian tareas,callbacks, etc. entre stages. En tal caso cambiaría la estrategía y usaría la gema/plugin capistrano-ext. Esta gema por dentro usa el mismo método que acabamos de utilizar pero llega un poco mas lejos.

Para usar este plugin solo hay que hacer 4 cosillas y una de ellas opcional

1. Hacer un require de capistrano-ext
2. Definir los stages que vamos a usar
3. Definir el stage por defecto **OPCIONAL**
4. Escribir nuestras recetas por cada stage dentro de config/deploy/<stage>.rb

Vamos a hacer el require y definir los stages, escribimos en el inicio de nuestro deploy.rb:

  require 'capistrano/ext/multistage'
  set :stages, %w(staging production)

No ha sido tan dificil ¿verdad?

Ahora siguiendo nuestro sencillo ejemplo vamos a escribir la receta de cada stage. En config/deploy/staging.rb escribimos:

  puts "*** Deployando en staging"
  role :web, "localhost"
  role :app, "localhost"
  role :db,  "localhost", :primary => true

Y en config/deploy/production.rb:

  puts "*** Deployando en producción"
  role :web, "localhost"
  role :app, "localhost"
  role :db,  "localhost", :primary => true

Lo probamos y vemos que funciona:

  $ cap production foo
  * executing `production'
*** Deployando en producción
    triggering start callbacks for `foo'
  * executing `multistage:ensure'
  * executing `foo'
  * executing "uptime"
    servers: ["localhost"]
Password:
    [localhost] executing command
 ** [out :: localhost] 02:22:19 up  3:08,  5 users,  load average: 0.11, 0.10, 0.07
    command finished

Si no le pongo stage falla miserablemente:

  $ cap foo
    triggering start callbacks for `foo'
  * executing `multistage:ensure'
No stage specified. Please specify one of: staging, production (e.g. `cap staging foo')

Para definir un stage por defecto entonces añadimos a nuestro deploy.rb:

  require 'capistrano/ext/multistage'
  set :stages, %w(staging production)
  set :default_stage, 'staging'

Y ahora comprobamos que usamos staging por defecto:

  $ cap foo
      triggering start callbacks for `foo'
    * executing `multistage:ensure'
  *** Defaulting to `staging'
    * executing `staging'
  *** Deployando en staging
    * executing `foo'
    * executing "uptime"
      servers: ["localhost"]
  Password:
      [localhost] executing command
   ** [out :: localhost] 02:29:17 up  3:15,  5 users,  load average: 0.03, 0.08, 0.08
      command finished

Esta última estrategia la recomiendo si hay demasiada diferencia a la hora de hacer un deploy entre los diferentes stages, por ej. si en staging tenéis montado el stack con mongrel y en producción con passenger. Otra situación podría ser cuando el deploy tiene muchas variables(además diferentes entre stages) y hace que se pierda la legibilidad de nuestro deploy.rb

Al usar esta estregia siempre procuro que las variables y tareas comunes se queden en el deploy.rb, y el resto vaya al fichero de configuración del stage. Si tuviésemos demasiadas tareas comunes las movería a otro fichero, todo sea por mantener la legibilidad. De todos modos cada cual lo puede hacer como le vaya bien

Nota: El deploy.rb que he usado para escribir este post solo contenía lo que os he ido indicado, para las pruebas que hemos hecho no es necesario definir la aplicación, el repositorio, tipo de scm,…

1. Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.
2. La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial -un organismo dependiente del ministerio de Cultura-, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.
3. La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.
4. La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.
5. Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.
6. Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.
7. Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.
8. Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.
9. Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.
10. En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.

Ahora que tenemos gemcutter el “awesome gem hosting” (tal como se describen ellos mismos) debemos hacer que nuestro origen principal de gemas sea este.

Esto lo hacemos de manera muy simple y en 3 pasos.

1. Actualizamos Rubygems a la última version:

$ sudo gem update –system

2. Instalamos la gema gemcutter:

$ sudo gem install gemcutter

3. Cambiamos el origen de las gemas con el comando:

$ sudo gem tumble

Esto es todo

Actualización:

Parece que eso no era todo.

Diego, un programador cualquiera , me ha recordado de que os avise que la orden para actualizar Rubygems(paso 1) se usan 2 guiones que WordPress se ha emperrado en poner como si fuese uno largo.