Otro de mis pequeños proyectos

Etiqueta: git

Mi configuraciones de vim (y II)

Como segunda parte del primer post sobre configuraciones de vim, voy a describir qué tengo ahora mismo en mi ~/.vimrc y plugins que uso. Esta configuración «está viva» y la cambio de vez en cuando. ¿Por qué? Pues porque tus gustos varí­an de vez en cuando y porque siempre descubres cosas nuevas que vas añadiendo o mejorando.

He colgado en github mi configuración al completo basandome en lo explicado en el anterior post. Puedes verlo aquí­: https://github.com/tatai/vim

Como acabo de comentar, es posible que lo que haya ahora, es diferente de lo que explique aquí­.

~/.vimrc

Vayamos por partes y poco a poco. Pese a que todas las lí­neas están comentadas, añadiré lo que crea que puede aclarar tras cada trozo de código.

Aclarar que estas opciones son personales y que espero que sean una guí­a para decidir cómo es tú configuración. Sólo probando encontrarás la combinación perfecta.

Muchas de las opciones se dehabilitan poniendo «no» delante de la opción o se habilitan quitando ese mismo «no», como por ejemplo se puede ver en la primera de las lí­neas, con «set nocompatible» que indica que no sea compatible y con «set compatible» se hace que sea compatible.

set nocompatible

Obligatorio, debes tenerla como tu primera opción en .vimrc puesto que el funcionamiento de interno de vim y de muchos plugins varí­a. Se obliga a que vim no sea compatible con el antiguo «vi».

" Pathogen
call pathogen#runtime_append_all_bundles()
call pathogen#helptags()

Llamadas para inicializar Pathogen (ver el primer post)

" UTF-8 by default
set fileencoding=utf-8

Forzamos que la codificación del documento sea utf-8

" Background will always be black
set background=dark

Me encanta la consola negra y así­ seguirá siendo 🙂

" Show ruler
set ruler

" Show current combination of keystrokes
set showcmd

Información sobre la posición, columna y posición del cursor en la página. Además, mostrar la combinación de teclas que estemos realizando.

" I like wrapping lines in vim
set wrap

Activamos que el texto no continúe más allá del borde derecho de la ventana (o split) en el que esté.

" 1 tab = 4 spaces
set tabstop=4

" Same for autoindenting
set shiftwidth=4

" Use tabs, not spaces for indenting
set noexpandtab

" Indenting
set autoindent
set smartindent
set copyindent

" Insert tabs on the start of a line according to shiftwidth, not tabstop
set smarttab

" Use multiple of shiftwidth when indenting with '<' and '>'
set shiftround

Uso de tabs en vez de espacios y definir que el espacio de un tab equivale a 4 espacios. Además, que la indentación sea «inteligente» y cuando por ejemplo usamos {, se indente automáticamente y al hacer escribir }, haga lo contrario.

" Show matching parenthesis
set showmatch

Ayuda a ver los bloques en códigos complicados. Además, pulsando % cuando estamos sobre uno de ellos, automáticamente salta al otro 😉

" Do not show line numbers (hate them)
set nonumber

No mostrar los números a la izquierda, en el lateral. Estoy muy acostumbrado a mirar al ruler y usar :n para ir a una lí­nea. Además, es más cómo cuando copias seleccionando con el ratón y pegas en otro sitio.

" I like case-sensitive searching, but this is the best of both worlds:
" search is case-insensitive but it is not when using at least one capital
set ignorecase
set smartcase

Me gusta buscar y que distinga mayúsculas y minúsculas, pero activando estas dos opciones, por defecto busca sin distinguir, pero si cualquiera de las letras es mayúscula, entonces sí­ que hace distinción.

" Do not highlight searchs
set nohlsearch

Cuando buscas algo, no marcar los resultados. Me marea mucho que cuando busco algo, empiece a marcar toda la pantalla. En caso de necesitarlo, lo activo momentáneamente, pero me gusta desactivado.

" Commands to be rememebered
set history=500

Vim y su potencia de historial de comandos. Prefiero una lista más larga que los 20 por defecto, que no ocupa nada en disco.

" Undo levels
set undolevels=1000

Deshacer en un fichero «casi» infinito 😉

" Change terminal title
set title

Cambia el tí­tulo del terminal para que muestre el path y fichero que se está editando. Comodidad.

" Like beeping
set novisualbell
set noerrorbells

Ni avisos visuales ni sonoros ante errores.

" Swap file save my work many times :)
set swapfile

Crear el fichero de intercambio .[nombrefichero.ext].swp porque no es la primera vez que consigo recuperar mi trabajo gracias a él. A veces son molestos estos ficheros, pero podemos definir un directorio donde se crean todos, en vez de justo en el mismo sitio que el fichero.

" Disable folding
set nofoldenable

Prefiero ver el texto completo, sin recoger.

" Custom filetype configuration
filetype plugin indent on
autocmd filetype yaml set shiftwidth=2 tabstop=2 expandtab

Activamos indentaciones distintas según tipo de fichero y defino que los YAML tengan espacios en vez de tabs y con un tamaño de dos (así­ lo requiere el formato YAML)

" No syntax highlighting
syntax off

No me gusta el syntax highlighting. Y cuando te acostumbras a ello, luego todo te da igual y ves antes los errores (menos cuando te dejas un comentario sin cerrar, jeje)

" Use F2 when pasting to avoid applying indents
set pastetoggle=

Opción muy interesante cuando usamos indentación automática. Si pegamos texto (por ejemplo código), vim piensa que sabemos escribir muy muy rápido y si hemos definido, como efectivamente he hecho antes, que haga indentación automática, si el texto que estamos copiando también lo lleva, el efecto que provoca es bastante desagradable. Con esta opción, definimos que, pulsando la tecla de función F2 en modo INSERT, activamos el modo paste (pegar) de modo que deshabilita momentáneamente estos indentados. De esta forma, conseguimos que el texto se pegue como realmente queremos.

" When line wrapping is enabled this make that when pressing up or down goes
" the visual line up or down, not physical line
" I only enable it sometimes
"nnoremap j gj
"nnoremap k gk

Estas lí­neas no las tengo activadas, pero las guardo para acordarme. Vim considera que cuando le das hacia arriba, bien sea pulsando la k en modo comando o bien la tecla arriba si así­ lo tenemos mapeado, irá de lí­nea en lí­nea. Al estar activado «wrap lines», lí­neas muy largas ocuparán visualmente varias lí­neas, pero no fí­sicamente. Vim por defecto irá de lí­nea fí­sica en lí­nea fí­sica. Activando (descomentando) estas lineas, provocaremos un comportamiento más «natural» ya que al movernos entre lí­neas lo haremos entre las lí­neas visuales. No lo activo por costumbre ya que me parece más cómodo. Viene muy bien cuando editamos ficheros con pocos saltos de lí­nea (dumps de SQL, csv, etc)

" Easy change between splits
map  h
map  j
map  k
map  l

Mapeos de teclas que uso mucho. Usando splits, para moverme entre ellos uso Control+[h|j|k|l] en vez de Control+w + [h|j|k|l]

" When you forget to sudo
" http://forrst.com/posts/Use_w_to_sudo_write_a_file_with_Vim-uAN
cmap w!! w !sudo tee % >/dev/null

Si alguna vez olvidas hacer sudo editando un fichero, para que no tengas que salir y volver a hacerlo 😉

" Mappings for FindFile & config
nmap , :FindFileSplit
nmap ; :FindFileCache .
let g:FindFileIgnore = ['*.o', '*.pyc', '*/tmp/*', 'cache_*', '*.swp']

Mapeos y configuración de FindFile. La coma para buscar fichero, punto y coma para que indexe y añado que no indexe fichero que empiecen por cache_ ni terminen en .swp

Plugins

Algunos plugins de vim que considero bastante útiles. Iré añadiendo más en posteriores posts.

Pathogen

Creo que queda poco por añadir. Plugin que te permite organizar el resto de tus plugins de modo que cada plugin ocupa una carpeta distinta dentro de ~/.vim/bundle/ en vez de juntarlos todos en sus correspondientes carpetas en la carpeta raí­z ~/.vim/

De esta forma, añadir o quitar plugins consta simplemente de añadir o quitar toda una carpeta.

FindFile

Este plugin permite recopilar todos los ficheros y poder abrir ficheros usando autocompletado. A partir del directorio donde nos encontramos, le decimos a FindFile (usando :FC) que rastree todos los ficheros y que guarde una relación de todos ellos con el lugar exacto donde se encuentran. Entonces, usando :FS o :FF (dependiendo si queremos que el fichero lo abra en un nuevo split horizontal o no) podremos ir escribiendo el nombre del fichero y automáticamente nos dará todas las posibilidades.

Lo primero que tenemos que tener en cuenta es estar en el directorio adecuado. Para ello, nos ayudaremos de unos comandos cuya funcionalidad es igual a la de la consola:

  • :pwd nos dice el directorio en el que nos encontramos
  • :cd para cambiar de directorio. Tenemos que indicar el directorio al que queremos ir. El autocompletado mediante tab ayudará mucho

Yo tengo mapeada la tecla ; (punto y coma) a :FC y , (coma) a :FS para trabajar con más rapidez.

Este plugin tiene un par de limitaciones que me parecen bastante importantes y hay que tener en cuenta.

La primera es que el autocompletado funciona letra a letra desde el principio del nombre del fichero. No valen comodines. No es muy crí­tica, pero algunas veces viene muy bien poder hacerlo.

La segunda es que no guarda el resultado de :FC en ningún sitio y hay que ejecutarlo cada vez que usamos vim. Esto es un engorro si hay muchos ficheros ya que estaremos varios segundos hasta que podamos empezar a trabajar.

NERDTree

Si te gusta el sistema de ficheros, tanto directorios como ficheros con forma de árbol, este es tu plugin. Tecleando :NERDTree abrirá un split vertical a la izquierda a todo lo alto mostrando los directorios y ficheros al estilo :Sex, pero con la diferencia de poder abrir y cerrar los directorios en vez de entrar a navegar por ellos. Usando la tecla o sobre cualquier fichero, lo abrirá en la ventana que tení­amos activa antes de abrir NERDTree y si usamos la i, lo hará en un split horizontal distinto, de modo que la antigua ventana siga disponible.

En cualquier momento podemos cerrar este árbol y volverlo a abrir. Además, puede sustituir a :Sex sin ningún problema y es realmente cómodo.

snipmate

Para poder insertar snippets en vim. Tan sencillo como escribir una palabra clave y al pulsar tab, insertará el snippet. Flexible y potente. Además, se definen zonas de modo que, tras insertar el snippet, usando el tab podemos ir de uno a otro y así­ completar toda la información. Cada zona tiene un texto por defecto.

El ví­deo demo os aclarará completamente su funcionamiento.

Gracias a que el plugin se encuentra en github, en vez de usar directamente este plugin, lo que he hecho ha sido hacer un fork del proyecto en mi cuenta y usar este como plugin. Esto me permite cambiar y añadir snippets manteniendo siempre el repositorio original como referencia. Realizando un simple merge, puedo actualizar todos los cambios del plugin original. Esto evidentemente añade un paso más a todo el proceso explicado en el post anterior ya que primero tengo que actualizar mi fork con el repo oficial y segundo, actualizar el submodule, pero a cambio obtengo independencia total y compatible a cambios con el repo original.

sparkup

Este plugin me ha parecido muy curioso y potente, pese a que no escribo mucho HTML. Para explicarlo, es más fácil ver el ví­deo demo, pero rápidamente diré que permite definir con una sintaxis muy sencilla el código HTML a generar y él se encargará automáticamente.

Por ejemplo, escribiendo:

ul.menu > li*2 > a > span < < <

y pulsando Control+e, generará:

Y muchas más opciones. Además, podremos ir editando cada una de las zonas de forma sencilla usando tab.

  • Mis configuraciones de vim (I)

    Hace ya algún tiempo que quiero recopilar todas las configuraciones de vim que tengo repartidas en un montón de cuentas con la intención de centralizarlas de alguna forma y hacerlo todo mantenible que pudiese y ha llegado el momento. Era una de esas cosas que procastinaba constantemente pese al uso bastante intensivo que hago de vim. Y lo peor es que no habí­a pensado completamente en la forma de hacerlo. Tení­a claro que querí­a usar versionado y git tení­a muchas papeletas en vista de todo lo que he visto, aprendido y gozado con este DSCM, pero poco más.

    La solución ha llegado tras ver este post en vimcasts.com (recomiendo encarecidamente ver el screencast) que me ha parecido tan sencillo y tan potente. En este primer post voy a explicar este método y en el siguiente contaré cuál es mi configuración actual (aunque irá evolucionando, pero bueno, que sirva de ayuda).

    La idea es muy sencilla: crear un repositorio de git (que centralizaremos en github.com) que clonaremos en nuestro directorio ~/.vim y, gracias a un par de trucos, extenderlo a todas las cuentas que tengamos de forma sencilla. Nadie nos quita tener que actualizar cada una de nuestras cuentas, pero bueno, podemos tirar de un cron que lo haga automáticamente 🙂

    Usando pathogen

    Este plugin para vim es un must-have si usas muchos plugins o, aunque uses únicamente uno, para poder tener todo bien organizado. Cada plugin de vim, en función de sus necesidades, puede estar repartido en múltiples carpetas dentro del raí­z de nuestro ~/.vim. Es decir, un plugin nos puede obligar a esta estructura de directorios:

    • ~/.vim
      • doc/
        • plugin.txt
      • plugin/
        • plugin.vim
      • syntax/
        • plugin-syntax.vim

    Si multiplicamos esto por varios plugins, teniendo en cuenta que hay más directorios posibles, añadir o quitar plugins es un engorro. Gracias a pathogen, en vez de tener repartidos los ficheros de cada plugin, podremos tenerlos todos juntos, los del mismo plugin en una carpeta, algo que es tremendamente cómodo ya que añadir o quitar un plugin es cuestión de añadir o quitar una carpeta. Muy sencillo.

    Con el ejemplo anterior, nos quedarí­a:

    • ~/.vim
      • bundle/
        • nombre-plugin/
          • doc/
            • plugin.txt
          • plugin/
            • plugin.vim
          • syntax/
            • plugin-syntax.vim

    Lo único que tenemos que hacer es descargarnos pathogen.vim y colocarlo en la carpeta ~/.vim/autoload/ (comprobar lo que dice el autor, es posible que esto cambie en el futuro) y añadir estas dos lí­neas en nuestro ~/.vimrc:

    call pathogen#runtime_append_all_bundles()
    call pathogen#helptags()

    Enlazar ~/.vimrc

    Como he explicado al principio, la principal idea es versionar el directorio ~/.vim/. Entonces, ¿qué pasa con ~/.vimrc? Efectivamente, este fichero (y ~/.gvimrc si usas gvim) se quedarí­an fuera y no los podrí­amos versionar, teniendo el gran inconveniente de que no podrí­amos guardar toda nuestra configuración.

    Para solucionar este problema, lo que se propone en vimcasts.com es renombrar este fichero a ~/.vim/vimrc (atentos que no se llamarí­a .vimrc sino vimrc y, por lo tanto, serí­a visible) y crear un enlace simbólico. Es decir:

    mv ~/.vimrc ~/.vim/vimrc
    ln -s ~/.vim/vimrc ~/.vimrc

    Esto nos permite versionar también este fichero con el punto extra añadido que volvemos al fichero visible y más cómodo de localizar.

    Submodules en git

    Por último, y no menos importante, trabajar con submodules de git en un repositorio. Partiendo de un repositorio de git ya creado, con los submodules podemos indicar a ese repositorio que los datos de un directorio se extraen de un repositorio git externo a ese. En subversion, serí­a el hermano mayor de svn:external.

    Muchos de los plugins de vim se han ido migrando a git y no sólo eso, sino que también los repositorios mantienen la estructura necesaria del plugin dentro de la carpeta ~/.vim y, por lo tanto como he explicado, gracias a pathogen podremos agrupar ese plugin en una carpeta muy fácilmente.

    Vamos a dividir en dos partes. La primera en la que le decimos a nuestro repositorio cuál es el plugin externo (ví­a submodule) y hacemos el commit & push y la segunda en la que clonamos nuestro repositorio en otra máquina e inicializamos y actualizamos los submodules.

    Definiendo el repositorio externo

    Supongamos que queremos instalar NerdTree que se encuentra git://github.com/scrooloose/nerdtree.git y ponerlo en bundle/nerdtree

    git submodule add git://github.com/scrooloose/nerdtree.git bundle/nerdtree
    git add .
    git commit -m "Install NerdTree.vim as submodule."
    git push origin master 

    Notar que tendremos que estar en el directorio donde se encuentra el directorio .git/ y que la configuración del submodule se guarda en .gitmodules (al mismo nivel que .git/)

    Clonando y actualizando

    Suponiendo que nuestro repositorio se encuentra en git://github.com/tatai/vim.git, lo que haremos primero será clonar el repositorio en nuestra carpeta ~/.vim y posteriormente inicializar y actualizar los submodules:

    cd ~
    git clone git://github.com/tatai/vim.git ~/.vim
    cd ~/.vim
    git submodule init
    git submodule update

    Si todo ha ido bien, si entramos en vim tendremos disponible toda nuestra configuración y plugins que hallamos subido.

    A partir de este momento, si queremos actualizar uno de los submodules, tendremos que ir a su directorio y usar git pull. Por ejemplo, usando el ejemplo anterior de nerdtree:

    cd ~/.vim/bundle/nerdtree
    git pull

    Ventaja de usar git

    Una de las ventajas añadidas que tiene usar git es que, en cualquier momento, puedes crear tu propia versión de un plugin sin perder de vista el código original ni que nuestras configuraciones pierdan sincronización.

    Voy a poner un ejemplo concreto con snipmate del que hablaré en el siguiente post más tranquilamente. Resumiendo, este plugin permite que, en función de ciertas palabras clave, definir snippets. Es una gran utilidad y todas las plantillas se encuentran en la misma carpeta del plugin.

    ¿Qué ocurrirí­a si queremos añadir más snippets o cambiar el formato de alguno de ellos, por ejemplo porque no se adapta a nuestro estilo de programar? Evidentemente, si usamos el código original del autor sólo podremos enviarle un patch-request que aceptará si quieres o no.

    Lo que podemos hacer en estos casos es hacer un fork, como por ejemplo he hecho yo en http://github.com/tatai/snipmate.vim. Un fork nos permite tener una versión propia del repositorio de otro usuario, considerándola como una fuente más de nuestro código, lo que nos permite no sólo reportar errores o mejoras al autor, sino también añadir lo que nosotros creamos más conveniente.

    Así­ pues, a la hora de añadir el submodule, en vez de usar el repositorio original del autor:

    git submodule add git://github.com/msanders/snipmate.vim bundle/snipmate

    Usaremos como origen el nuestro propio:

    git submodule add git://github.com/tatai/snipmate.vim bundle/snipmate

    Esto claramente nos añade un paso más, ya que no bastará con actualizar los nuestros directorios ~/.vim sino también mantener este otro repositorio.

    PHP Conference 2010. Dí­a 1

    Tras terminar el primer dí­a, voy a dar un pequeño repaso de las charlas en las que he estado. De entre todas las charlas disponibles, yo he elegido estas:

    • Doctrine 2.0 by Juozas Kaziukenas
    • Distributed Source Code Management by Hugh Gilmour
    • Varnish in action by Thijs Feryn
    • PHP in the Enterprise: Develop and Deploy Mission Critical Applications by Kuassi Mensah
    • Desarrollo de aplicaciones para Facebook en PHP by Victor Castell
    • Architecture and testability by Giorgio Sironi
    • Comet: by pushing server data, we push the web forward by Philip Ross

    De primeras, con lo que he visto y he podido leer en twitter, tengo que decir que parece que he cogido las más «divulgativas» y yo he venido con bastantes ganas de ver cosas nuevas o por lo menos ver código y aplicaciones.

    Ahora, un breve resumen de cada una de ellas.

    Doctrine 2.0 by Juozas Kaziukenas

    Un repaso por lo que va a ser Doctrine 2.0, tanto por las nuevas caracterí­sticas que tendrá como por comparación con Doctrine 1.x. La versión actual de Doctrine, pese a ser lento, tener un alto uso de memoria (principalmente por un uso cí­clico de referencias), su «magia» y otros problemas como la dificultad de ejecutar «raw» SQL, sigue siendo el mejor ORM para PHP hoy en dí­a y por ello Doctrine 2 tendrá esas funcionalidades (y más) aunque cambiará la forma de hacerlo.

    Reescrito completamente para PHP 5,3, con una nueva API simplificada y muchas mejoras de rendimiento es la tarjeta de visita de esta nueva versión.

    Además, se divide en 4 módulos: Common, DBAL (DB Abstraction Layer), ORM y ODM (Object Document Layer). Este último permitirá trabajar con motores NoSQL, otra de las nuevas caracterí­sticas.

    Una interesante charla de introducción a lo que va a ser Doctrine 2.

    Distributed Source Code Management by Hugh Gilmour

    La charla tuvo dos partes diferenciadas, la primera fue una revisión del distinto software usado a lo largo del tiempo para realizar control de código y la segunda fue una comparación entre git, bazaar y mercurial.

    Desde mi punto de vista, la parte más interesante fue la segunda, aunque fue algo particular ya que no se basaba únicamente en compararlos desde el punto de vista de cómo se realizan las revisiones, o las caracterí­sticas de los branches y merges, sino también dio las herramientas que se usan para todos ellos, soporte de IDEs e incluso bugtrackers e integración contí­nua. Muy interesante para analizar estas diferencias que en más de un caso, pueden ser muy importantes.

    De todas formas, me quedo con perlas dichas por Hugh como «Simplest option is always the best» y «Work at the level of the least technical person in the project». La primera porque es una máxima que creo que hay que seguir siempre, sobre todo en el desarrollo de software como buen principio y la segunda porque a la hora de elegir cualquier opción, el factor humano y profesional debe tenerse en cuenta, que no quiere decir que haya que poner lo más simple (que no sencillo), sino lo que se adapte mejor, hay que buscar lo mejor.

    Varnish in action by Thijs Feryn

    Presentación que muestra las posibilidades de Varnish, aunque sin profundizar demasiado en el producto. Se muestran muchas de los comandos y configuraciones que nos permiten configurar la aplicación considerando que la principal aplicación de Varnish es la de caching.

    Creo que aunque se intentaba mostrar toda la potencia del servicio, que realmente parece muy potente, a la vista de cómo es la configuración, principalmente mediante comandos y subrutinas en ficheros, realmente esconde un entorno bastante complicado de configurar.

    Una charla muy rápida (casi 100 transparencias en 50 minutos) a nivel visual fue difí­cil de seguir debido al ritmo tan trepidante impuesto por Thijs que aclaró desde un primer momento que no tení­a perfil técnico, algo que se echó de menos en algunos momentos.

    PHP in the Enterprise: Develop and Deploy Mission Critical Applications by Kuassi Mensah

    Charla muy marcada por la presencia de Oracle (recordemos que el Platinum partner) en la que se mostraba algunas de las caracterí­sticas que provee Oracle como base de datos en los cambios entre entornos, facilitando distintas aplicaciones y el cambio.

    Desarrollo de aplicaciones para Facebook en PHP by Victor Castell

    Esta charla/taller estaba dividida en dos (algo que no estaba muy claro en el programa ya que tan sólo estaba en dos sesiones separadas por uno de los descansos largos) y sólo pude asistir a la primera parte.

    La idea era buena puesto que se querí­a mostrar cómo realizar una aplicación en PHP para Facebook y de hecho, para avanzar en el proceso y hacerlo más sencillo, creo que la forma de realizarla no estuvo nada organizada, lo que provocó que en los 50 minutos que estuve en la charla, apenas se dieron los conceptos básicos, haciendo principal hincapié en las condiciones de uso de Facebook, los problemas que tiene el desarrollo en Facebook (latencias, caí­das, cambios en la API, etc) y en que hay que buscar la aplicación que se interesante para el cliente. Pero el tiempo empleado por ejemplo en dar de alta la aplicación en Facebook (pudieron ser tranquilamente 3o minutos) me pareció excesiva y poco fructí­fera ya que, exceptuando un par de conceptos que sí­ que es necesario explicar y aclarar, el resto se podí­a suponer de una forma bastante clara.

    Si a todo esto unimos que la sala estaba realmente hasta arriba y era la pequeña pequeña (estarí­amos unas 60 personas de pie), pues no pude probar nada y esperaré a que cuelguen el enlace y la presentación para poder trastear algo. Algo más de organización hubiese venido muy bien y al menos salvaron los problemas técnicos que no tuvieron que ver con ellos de forma magistral.

    Architecture and testability by Giorgio Sironi

    Interesante conferencia a manos de Giorgio sobre la importancia del buen código y del testeo. Se centró en estos cuatro puntos principalmente: «Do dependency injection», «Avoid static methods», «Law of Demeter» y «Singleton vs. Factory».

    Aunque creo que se extendió demasiado para explicar algunos conceptos que se veí­a que controlaba y haber dado más ejemplos creo que le hubiese ayudado más.

    Sin lugar a dudas, me quedo con estas dos perlas: «Easy to test means easy to maintain» y «When tests are difficult to write, change the design to ease testing (listen to your tests)»

    Comet: by pushing server data, we push the web forward by Philip Ross

    Excelente presentación de la gente de NOLOH sobre las ventajas de comet, aunque desde un punto de vista muy superficial. Me ha gustado bastante la parte en la que han hecho especial énfasis en la historia de la tecnologí­a y su futuro por ejemplo con WebSockets, aunque los navegadores pondrán muchas trabas a no ser que mejore el asunto.

    Debido a problemas técnicos iniciales y a la saturación de la conexión a internet, la charla fue más corta de lo esperado y sin ejemplos prácticos que se echaron en falta.

    Finalmente mostraron algo de NOLOH Framework aunque nos quedamos con las ganas de ver más cosas interesantes.

    Update: continúa leyendo el dí­a 2

    Cambiar el nombre y el email en el log de git

    Seguro que no es la primera vez que, usando git, inicializas el repositorio, haces unos cuantos commit y para cuando te das cuenta, ya tienes varios Usuario en el log de cambios. Evidentemente, usas git config para cambiar el user.name y el user.email pero el texto sigue ahí­ cuando pones git log.

    Antes de ponerlo en un repositorio público como por ejemplo github, hay que cambiar esto y lo haremos de una forma muy sencilla usando git filter-branch. Este comando nos permite hacer multitud de diferentes cambios sobre todas las ramas en el proyecto y, entre otras cosas, cambiar estos dos datos que nos hacen falta.

    Supongamos que los datos que queremos poner son:

    • Usuario: Tatai
    • E-mail: tatai@example.com

    Entonces, el comando que tenemos que usar es:

    git filter-branch --env-filter 'export GIT_AUTHOR_NAME="Tatai";GIT_AUTHOR_EMAIL="tatai@example.com"'

    Tras ejecutar el comando, veremos como se reescriben todos los commits.

    En caso de querer cambiar únicamente ciertos commits y no todos, podemos añadir al final del comando el intervalo, por ejemplo, para los 10 últimos commits: HEAD~10..HEAD

    Creando un «export» con git

    Si estás trabajando con git, seguro que alguna vez has querido hacer un «export» (usando terminologí­a de subversion: un svn export), es decir, obtener todos los ficheros sin los datos de #git. La opción más fácil serí­a copiar todos los datos y borrar la carpeta .git, pero si quieres evitarte crear el script, aquí­ tienes una sencilla solución, usar checkout-index. El comando serí­a más o menos así­:

    git checkout-index -a -f --prefix=/path/export/

    Importante: no olvides la última barra (slash).

    Y ahora la breve explicación. checkout-index crea una copia de los fichero en el index a donde le indiques, pero sin sobreescribir, algo que evitaremos con la opción -f. Con la opción -a le indicamos que copie todos los ficheros en el index y con –prefix indicamos un prefijo que queremos que añada a todos los ficheros que extraiga (es decir, poniendo un path, es un truco para decirle que lo extraiga en otro lugar y con el mismo nombre, de aquí­ que tengamos que poner la última barra).

    Es una forma sencilla y necesitas de tu copia local en el mismo servidor, algo que me gustarí­a evitar, pero de momento, tiraremos con esta opción.