Entradas con la etiqueta “código”

MVC en la web, la gran farsa de los arquitectos de software

En los entornos de desarrollo web es habitual referirse al patrón de diseño Modelo Vista Controlador (MVC) como la “forma correcta” de construir sitios/aplicaciones web. La realidad es que dicho patrón no se puede aplicar a la web tal y como se concibió, aunque su objetivo resulte útil y entronque con un principio general de diseño frecuente en distintos entornos de desarrollo de software: separar claramente las partes de un sistema. Así de sencillo. :)

Modelo-Vista-Controlador

El paradigma MVC, tal como se presentó originalmente, está pensado para aplicaciones estáticas como las que solemos manejar en un entorno de escritorio. Piensa por ejemplo en tu organizador de archivos (en Windows, en Mac o en Linux): te ofrece un buen número de botones, campos de entrada, controles de ventana, filtros, etc., que pueden ser presionados por ti en cualquier momento. Cuando lo haces, estás activando uno de los muchos “controladores”, su consecuente “modelo” para hacer lo que tiene que hacer, y finalmente actualizando una o más “vistas” que reflejarán el nuevo estado del “modelo”. En la implementación original la cosa quedaba descrita del siguiente modo:

The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).

Es decir, el problema original al que se enfrentaba este “paradigma” era la simultaneidad, en un entorno de múltiples puntos de entrada (en forma de “controladores”) y múltiples puntos de salida (en forma de “vistas”). Lo que nos obliga a preguntarnos: ¿la web es un entorno de ese tipo? Evidentemente no. En la web manejas un sólo punto de entrada (request) y un sólo punto de salida (response), por lo que para empezar te encuentras con un patrón para el cual no dispones de un problema real sobre el que aplicarlo. :(

Pero además te encuentras con que las aplicaciones ideales para MVC son básicamente monousuarias y el modelo se mantiene en memoria mientras la aplicación está siendo ejecutada. Segundo elemento que no encontramos en la web: entorno típicamente multiusuario, donde el modelo para el usuario se regenera en cada request.

Si uno profundiza en las características del paradigma original se irá encontrando con más diferencias, que básicamente son fruto de estas dos básicas que he señalado.

Separa, separa, separa

Si el patrón original no puede ser aplicado realmente a los problemas típicos con los que nos enfrentamos en un entorno web, ¿qué es lo que podemos extraer de él? Sin duda alguna, su vocación por mantener separadas las partes de un sistema: es decir, pon tu código de datos en un lado, tu código de aplicación en otro, y tu código de presentación en otro. No suena a nada del otro mundo, dicho así; parece sentido común, y es al mismo tiempo una forma tradicional de desarrollo de software que encaja muy bien con trabajo en equipo y especializado.

Por lo tanto, no tiene sentido apelar a este patrón como una solución-para-todo, e incluso puede resultar contraproducente, puesto que se van a estar forzando las cosas (las palabras, los conceptos, etc.) y por lo tanto perdiendo perspectiva. Eso en el mejor de los casos; en el peor, se llegará a construir un problema ajustado al patrón y no a la inversa. :(

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.