Desarrollo de PHP con Vim: configuración y plugins

27 de enero, 2011 - por | 6 comentarios | Desarrollo, Linux, Tips

Última actualización: 24 de enero de 2012

Voy incorporando las sugerencias y tips que encuentro más interesantes. Así que si echas algo en falta, no dejes de comentarlo.

El tema de los editores/IDEs para trabajar con código sigue siendo algo que levanta discusiones en muchos ambientes de desarrolladores. Hay bastantes ideas preestablecidas al respecto, y nunca dejará de sorprenderme la cantidad de gente que no tiene un gusto formado al respecto, y se contentan con repetir prejuicios manoseados. :(

Mi gusto se apoya en las siguientes cosas (en este orden):

  • no quiero esperar para poder tirar código
  • no quiero utilizar algo que sea exigente con la máquina
  • quiero utilizar casi exclusivamente el teclado
  • quiero poder utilizarlo en distintos entornos y máquinas
  • mi medio natural es la consola de linux

Durante mucho tiempo estuve utilizando Emacs y Vim indistintamente para diferentes cosas. Según he ido desarrollando cada vez más en PHP, me he decantado del lado de Vim, porque he encontrado más cosas listas para utilizar y una comunidad mucho más viva que en Emacs. Las siguientes son las cosas que hasta el momento he encontrado realmente útiles cuando tiro código en PHP sobre Vim:

Mapeo para correr el fichero que estoy editando a través del intérprete de PHP

Para ésto en el fichero .vimrc tengo lo siguiente:


    :autocmd FileType php noremap  :w!:!/usr/bin/php %

Mapeo para parsear la sintaxis del fichero que estoy editando a través del intérprete de PHP en modo lint

En el fichero .vimrc:


    autocmd FileType php noremap  :!/usr/bin/php -l %

Autocompletar para sintaxis PHP

En el fichero .vimrc:


    autocmd FileType php set omnifunc=phpcomplete#CompletePHP

ManPageView plugin para consultar documentación de PHP en Vim

Un plugin que siempre he encontrado muy útil; te abre un nuevo buffer con la información de lo que hayas consultado. Igual te vale para PHP que para Perl y Python, y su uso es bien sencillo. Por ejemplo, imagina que quieres consultar la documentación para la función explode:


    :Man explode

Sólo tienes que descargarte el plugin, colocarlo en tu directorio de plugins de vim, y tener instalado links (que sueles tener disponible en cualquier repositorio de una distribución de Linux).

FindFile plugin para encontrar nombres de ficheros

Te permite abrir rápidamente un fichero tecleando su nombre. Lo autocompleta y te sugiere las coincidencias. Sólo tienes que descargarte el plugin, colocarlo en tu directorio de plugins de vim, y empezar a trabajar. Lo más cómodo es situarte en el path donde se encuentre tu código y cachear el sistema de ficheros desde ahí para abajo de forma recursiva:


    :FindFileCache .

A partir de ahí puedes invocar el principal comando:


    :FindFile

y empezar a teclear el nombre del fichero. Un nuevo buffer te ofrecerá las coincidencias. Como siempre en vim, puedes organizarte la disposición de los buffers con split y temas similares.

un buen fichero de configuración con indentación, wrap de líneas, mapeos, etc.

Cosas que yo siempre tengo en mi .vimrc:


    " vim as vim
    set nocompatible
    " always syntax on, for an easier life :)
    syntax on
    " load filetype plugins/indent settings
    filetype plugin indent on
    " status line always visible
    set laststatus=2
    " show current position along the bottom
    set ruler
    " highlights things found with the search
    set hlsearch
    " 8 is the magic number, sorry for pythonists :)
    set tabstop=8
    " shows what you are typing as command
    set showcmd
    " incremental search
    set incsearch
    " path for :find
    set path=$PWD/**
    " watch for file changes
    set autoread
    " navigation tabs
    :nmap  :tabnew
    :nmap  :tabclose

Cuando trabajo con Python también lo hago con Vim, aunque Emacs para Python está en una situación bastante mejor que para PHP. Así que en otro post comentaré cómo suelo trabajar con Python sobre Vim.

Actualización del 25 de agosto de 2011: sintaxis correcta para el plugin ManPageView

En los comentarios José Ignacio me recordó que la sintaxis correcta para utilizar el plugin ManPageView es la siguiente.


:Man explode.php

Es decir, añadiendo la extensión del lenguaje para el que realizas la búsqueda. Aunque la sintaxis corta que yo utilizo, también funciona, la oficial te permite buscar un mismo nombre de función en distintos lenguajes.

Actualización del 24 de enero de 2012: utilizando el manual de PHP como páginas man de UNIX

Una forma más cómoda de acceder a las funciones y métodos de PHP consiste en utilizar el manual de PHP como páginas man de UNIX. Ésto lo tenemos gracias al equipo de documentación de PHP. Mil gracias. :).

Para instalarlas lo más cómodo es:


$ pear install doc.php.net/pman

Después seteas en tu .vimrc la configuración:


set keywordprg=pman

Con ponerte sobre una función y pulsar ‘K’ tendrás la documentación correspondiente.

Encontré la info por el blog de bjori. Gracias. :)

Desarrollo con Git basado en branches

26 de enero, 2011 - por | | Calidad, Desarrollo, Linux, Proyectos

Cuando trabajas con código y manejas un sistema de control de versiones para gestionar los cambios del primero, pronto te ves tomando decisiones que tienen que ver en definitiva con cómo se va a trabajar a diario. Ésto es especialmente importante en entornos de trabajo con numerosos desarrolladores, y cobra aún más importancia cuando se tiene que manejar un ciclo de vida completo (desde la fase de desarrollo hasta la fase de release/producción).

En Grosshat utilizamos Git de una forma bastante flexible, con la intención de que nos sirva para distintos proyectos, pues hemos ido aprendiendo que realmente un proyecto siempre son varios en cuanto que lo dejas evolucionar un poco. :)

Nuestras dos reglas básicas: 1) no desarrollar en la branch master; 2) no utilizar la branch master más que para mover cambios entre el repositorio externo y las branches locales. En definitiva, mantener la branch master limpia con el fin de evitar futuros conflictos y disgustos.

¿Cómo funcionamos con esas dos reglas? Veamos un ejemplo. Imaginemos que vamos a añadir una función a un repositorio de código basado en WordPress. Esta función va a consistir en evaluar si una página es subpágina de otra (algo muy útil cuando le das uso a WordPress en plan CMS). Utilizaremos el fichero de funciones globales de WordPress para que así podamos utilizarla cómodamente desde cualquiera de los templates. Al lío.

Empezamos desde 0


    $ git checkout master
    $ git pull

Creamos una nueva branch sobre la que trabajar


    $ git checkout -b function_check_child_page

Hacemos todos los commits que hagan falta

En este caso vamos a suponer que tiramos todo el código necesario para la función (no más de 10 líneas) en un mismo commit. Posteriores commits podrían incluir mejoras, limpiezas de código, etc.


    $ git commit -am "Global function is_subpage: returns boolean value
    for checkin if the current page is child of a parent page"

Hacemos merge con la branch master

Podemos empezar por revisar todas las diferencias antes de hacer el merge, de ese modo tenemos otra oportunidad de revisar posibles errores, marcas de debug, etc.


    $ git diff master

Si todo está como queremos, vamos con el merge.


    $ git checkout master
    $ git pull
    $ git checkout function_check_child_page
    $ git rebase master

Esta forma de hacer el merge, mediante rebase, permite mantener una historia continua de cambios.

Push

Una vez que hemos integrado la branch master con nuestra branch de desarrollo, podemos volver a la primera, obtener la segunda y enviar al repositorio externo.


    $ git checkout master
    $ git merge function_check_child_page
    $ git push

Limpiamos la branch


    $ git branch -d function_check_child_page

Todo este flujo de trabajo respeta las 2 reglas que mencionamos al principio, pero también supone algunas otras cosas como las siguientes:

  • pequeño mejor que grande (para commits y para merges)
  • muchos mejor que pocos (para merges)
  • pronto mejor que tarde (para merges)

La principal pega que se le suele plantear a este procedimiento es que da un poco de pereza, y que en entornos pequeños puede resultar algo barroco. Sin duda requiere maś pasos que trabajar directamente sobre la branch master, pero siempre se puede adoptar cuando se juzgue necesario -entran nuevos desarrolladores, hay trabajo a distancia, etc.-, y mientras tanto seguir con la master para todo.

Autenticación en Django a través de Facebook, Gmail, Twitter, Yahoo y OpenID

26 de enero, 2011 - por | 2 comentarios | Análisis, Desarrollo

Cuando uno está montando un nuevo sitio en forma de directorio, suele partir de una base de contenidos a los que espera sumar otros procedentes de los usuarios. Esta acción por parte de los usuarios siempre es algo difícil de conseguir, porque en definitiva se trata de su tiempo y su esfuerzo. Y los procesos de registro/login no suelen ayudar a corregir ese esfuerzo, sino que con frecuencia lo agrandan.

Esto se hace particularmente grave en sitios que consideran que el índice de regreso de sus usuarios es muy bajo. En estos casos se suelen aceptar contenidos, al menos en una fase inicial, sin necesidad de registro. La contrapartida es que los contenidos quedan huérfanos y tienen menos credibilidad. El sitio en definitiva puede llegar a tener más contenidos, pero de menos calidad.

Yo suelo tener una opinión contraria a este tipo de planteamientos, porque: 1) nunca sabes completamente el tipo de usuario que vas a tener (tu índice de regreso no es algo infalible ni está distribuido de forma homogénea en el 100% de tus usuarios, por lo que puedes llegar a perder porcentajes pequeños pero significativos desde el punto de vista de su actividad); y 2) porque acabas aplazando al medio plazo la decisión inicial, y entonces te encuentras con la difícil de decisión de mezclar contenidos (unos huérfanos, los otros ya con autores), o de dejarlos para siempre tal como están. Creo que hay soluciones intermedias.

Una de las más populares es ofrecer el registro a través de terceros, es decir, de alguna herramienta que ya esté utilizando el usuario. La más popular es, sin duda, Facebook, pero podría ser Gmail, Twitter, Yahoo, o cualquier otro servicio en el que sepas que tus usuarios ya tienen una cuenta. De esa forma les evitas el tedioso proceso de crearse una cuenta (otra más) y al mismo tiempo no sacrificas la calidad de los contenidos desde el momento 0.

Si trabajas con Django, cuentas con Django-Socialauth, que ofrece login a través de los servicios mencionados y alguno más, menos frecuente eso sí, como OpenID. Además, permite importar contactos y ver cuáles están ya como usuarios del sitio.Y, por supuesto, junto a ésto siempre puedes ofrecer un registro clásico. No hay necesidad de sacrificar nada. :)

Efecto bokeh para home y landing pages

10 de marzo, 2010 - por | | Diseño, Tips

Poco a poco el efecto bokeh se ha ido convirtiendo en uno de los recursos más frecuentes para conseguir gráficos atractivos. Con frecuencia, se utiliza sobre imágenes de fondo posicionadas en la cabecera o en el body de las home y de las landing pages, es decir, de aquellos espacios que esperan no sólo el mayor número de visitas sino también rebajar el porcentaje de rebotes.

Con ocasión de un proyecto reciente que hemos estado preparando para la gente de noalamonotonia.com, hemos tenido la oportunidad de probar distintas técnicas sobre distintas suites gráficas para conseguir ese efecto. Hemos visto también que la comunidad ha generado un montón de buenos tutoriales, ejemplos y patrones de texturas listos para usar. Así que hemos seleccionado varios de los recursos que más nos han gustado. A ver qué te parecen.

FOSDEM 2010: más open source, más diversión :)

21 de febrero, 2010 - por | | Open Source

En 2009 Grosshat estuvo en el FOSDEM y lo disfrutó mucho. Como comentamos entonces, Fin de semana en el FOSDEM, el ambiente de esta reunión europea de desarrolladores y simpatizantes del open source es realmente positivo y divertido, y su visita siempre te reporta un montón de información y te da un poco el tono de por dónde están yendo las cosas en líneas generales.

En 2009 nos parecía que lo más preponderante había sido todo el tema de dispositivos embebidos, para los cuales distintas distribuciones populares y otras tantas menos conocidas tenían ya preparados un montón de recursos tanto en forma de software como de hardware. Por su parte, en 2010 hemos vuelto con una impresión bastante fuerte de que las alternativas a los motores SQL son ya una realidad, y que los temas de escalabilidad en la web ya están convirtiéndose en un tema frecuente a raíz de la aparición y consolidación de portales (ala Facebook) que han llevado las cifras de visitas y uso a cotas difícilmente pensables hace unos años.

El reparto de charlas ha reflejado muy bien el peso de esos 2 temas principales; por un lado, dentro de los llamados “Main Tracks” se creo uno dedicado completamente a la escalabilidad; por otro lado, en las “Developer Rooms” se organizaron más de una docena de charlas sobre el tema NoSQL. Al mismo tiempo, hubo bastantes referencias cruzadas entre ambos espacios, lo que reforzó aún más la intuición de que algunos de sus problemas tienen al menos un origen común. Ésto se vio perfectamente en la magnífica charla que dio la gente de Facebook, donde los temas de escalabilidad y las soluciones NoSQL fueron las alusiones más habituales.

Un año más ha sido una experiencia genial y una oportunidad perfecta para conocer Bruselas y disfrutar de la ciudad, con todos los encantos que tiene, incluidad la cerveza. ;)

Si no has podido ir, pero piensas que podrías animarte a ir el próximo año, échale un vistazo a los siguientes enlaces, donde recopilamos fotos, videos y presentaciones de todo el fin de semana.

Mi maquinita tatuada con Facebook

máquina de iñigo con la pegatina de facebook

Colecciones de fotos

Colecciones de vídeos

Presentaciones

  • en slideshare se han reunido muchas de las charlas

Plugins para GIMP

20 de febrero, 2010 - por | | Diseño, Tips

En Grosshat utilizamos GIMP para las tareas habituales de manejo de gráficos. En proyectos con clientes muchas veces se nos cae, bien porque no es el programa habitual en esos otros entornos, bien porque no incorpora las capacidades vectoriales que otros programas combinan con las netamente gráficas. En este sentido, Fireworks de Adobe sigue siendo una especie de navaja suiza realmente productiva.

Bueno, el caso es que si como nosotros eres de los que tiran de GIMP de forma habitual, manejar plugins se convierte con el tiempo en algo inevitable; de hecho, el programa está pensado como un core alrededor del cual la comunidad genera utilidades en forma de plugin. Así que profundiza, una vez más, en la exitosa forma de funcionar de la tradición open source: módulos sencillos que se interconectan fácilmente a partir de una base común.

Algunos plugins que seguro te van a ayudar un montón:

  • Image subdivide te permite dividir un gráfico en n filas y n columnas, y salvar cada celda de la matriz
  • Liquid Rescale trae a GIMP el escalado típico de Photoshop que posibilita redimensionar un gráfico de forma no uniforme pero sin distorsión
  • Save for Web es imprescindible si quieres manejar unos pesos razonables en gráficos para la web
  • Pencil drawing from Photo te proporciona un hermoso efecto de lápiz sobre un gráfico, muy bueno para diseño de sitios livianos y muy lineales
  • Layer Effects te suministra operaciones típicas de shadow, glow, bevel, overlay, etc.
  • Quick sketch ofrece un precioso efecto de esbozo sobre el gráfico que le proporciones; combina muy bien con el de Pencil que comentábamos más arriba

La instalación de algún script puede en ocasiones resultar un poco pesada, pero en general es algo sencillo y rápido. Y con la ventaja de cuentas con el código fuente y puedes modificar cosas triviales o profundas a tu gusto.

Más allá de estos plugins que destacamos aquí, apúntate como sitio de referencia el GIMP Plugin Registry.