Entradas con la etiqueta “unix”

Nginx como proxy de Apache para servir contenidos estáticos

28 de enero, 2011 - por | 3 comentarios | Linux, Sistemas

Si sueles utilizar Apache para tus sitios, estarás acostumbrado a la magnitud de sus procesos: son grandes, muy exigentes con la memoria, y relativamente lentos hasta que son lanzados. Evidentemente, ésto no tiene por qué ser cierto en todos los casos; se puede ajustar bastante para que tenga un comportamiento más liviano, y con el tiempo han ido surgiendo alternativas al modelo tradicional de procesamiento (MPM) que consiguen reducir mucho esos puntos negativos.

Ahora bien, en ocasiones uno quiere o necesita seguir manteniendo Apache en su modo tradicional, en una configuración típica con PHP o Python, por diferentes razones: te puede haber convencido su estabilidad; puede que no quieras sacrificar algunos módulos clásicos (como el mod_rewrite); no encuentras la misma actividad en las comunidades de los servidores alternativos, etc. Nosotros nos hemos visto en esa situación, y hemos encontrado una forma, ya bastante popular, de reducir los aspectos negativos de Apache sin renunciar a sus cosas buenas: utilizar Nginx para servir los contenidos estáticos y dejar Apache para todo lo demás.

Si te animas a probar esta solución (y hay un montón de información en la red para implementarla), te encontrarás con: 1) una reducción sustancial del uso de memoria; 2) un correspondiente aumento de capacidad de cacheo a nivel de disco; 3) mayor consistencia en la separación de las tareas del sistema; 4) un rendimiento más ágil y rápido en el servidor y, por lo tanto, en tu sitio. ¿Se puede pedir más? :)

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.

Lecciones de bazaares

13 de noviembre, 2009 - por | | Open Source

En el libro de Eric Raymond, The Cathedral & the Bazaar, hay una parte que me gusta especialmente: aquélla en la que el autor reconoce cómo de chocante les resultó, incluso a los mismos que se encontraban ya en los círculos del desarrollo abierto entre los 80 y los 90, la forma en que el por entonces emergente linux se organizaba. Es donde mejor se aprecian las diferencias entre los 2 mundos que dan título al libro: la catedral que ellos conocían como forma de trabajar, relacionarse y construir, frente al bazaar linuxero lleno de novedades más sociales que técnicas.

Algunas de las que más me gustan:

  • no hay barreras de entrada, la contribución puede llegar de cualquiera en cualquier momento
  • los usuarios se transforman en co-desarrolladores
  • no tiene sentido no beneficiarse de una base cuanto más grande mejor de beta-testers y co-desarrolladores que a la postre se acaban convirtiendo en otras partes del proyecto
  • las fronteras tradicionales entre los profesionales/especialistas y los “otros” se diluyen

Las sensaciones que debieron tener todos aquellos grupos de ingenieros altamente especializados, que habían conseguido hacerse con un espacio propio donde ellos ponían las reglas y marcaban las distancias respecto de todo lo “externo”, seguro que fueron muy mezcladas. Otra vez, las batas se diluían, como habían hecho ellos a su vez con la generación anterior, para dar paso a una nueva forma de hacer las cosas que encima se demostraba productiva.

La evolución otra vez: les llegaba el turno esta vez a los barbudos que un día jubilaron a los encorbatados. Es algo que aún hoy no se ha acabado de asimilar, y todas las modas de palabras sobre redes sociales, web 2.0, etc. dicen mucho al respecto.