Annotations, esas desconocidas en PHP

He de reconocerlo, me encantan las annotations (attributes en .NET). Me parecen una de las herramientas mas útiles que nos puede proveer un lenguaje de programación y me pongo burro cuando las veo por algún sitio.

Ya me había acostumbrado a ellas en Java hace tiempo cuando comencé con Hibernate y más tarde seguí usándolas con .NET. Las annotations, en este caso, eran una manera de los más limpia para no tener que toquetear un xml cada vez que cambiaban los objetos de datos.

Creas tu objeto de datos y lo mapeas en dos patadas, tal que así:

@Entity
@Table( name = "EVENTS" )
public class Event {
   ...
}

Trabajo terminado.

Más o menos hace un año, mientras estaba RESTificando unga, que está programado, por ahora, con PHP, me surgieron una serie de dificultades:
- Necesitaba devolver los resultados en diferentes formatos (XML, JSON, HTML).
- PHP es un lenguaje de tipado débil y sólo en muy contadas ocasiones se puede especificar un tipo de datos.
- Con lo anterior tenía problemas para mapear números y cadenas, o incluso tipos de datos binarios sin mantener en algún sitio un objeto de conversión específico para cada tipo de datos. En Java/.NET/etc. es mucho más sencillo pues en cada momento se puede acceder al tipo de cada variable.

Cómo pasar, por ejemplo de ésto:

public class Cosa {
    public $DatoCadena = ‘pakito’;
    public $DatoFloat = 0.123;
    public $DatoEntero = 123;
    public $ArrayDeObjetos;
}

A ésto:

<?xml version="1.0" encoding="UTF-8" ?>
<Cosa>
    <DatoCadena>pakito</DatoCadena>
    <DatoFloat>0.123</DatoFloat>
    <DatoEntero>123</DatoEntero>

<ArrayDeObjetos>

    <Objeto....

    ...

</ArrayDeObjetos>
</Cosa>

O más difícil aún, ¿cómo hacerlo a la inversa? (de XML a objeto).

Recordemos: PHP es un lenguaje de tipado débil, de ahí el problema. Los Javeros, NETeros, C++eros y similares lo tienen algo más sencillo.

Hay muchas formas y podrían hacerse muchos tipos de parsers pero siempre vamos a encontrarnos con que esos parsers no van a ser genéricos y requerirán que, cada vez que se modifique una clase, se incluyan sus nuevas propiedades específicas (por ejemplo, DatoPatito, haciendo referencia a objetos de tipo Patito).

Podría delegarse la responsabilidad en cada objeto de datos, la cual fue mi primera opción, pero sería un coñazo, con el tiempo, tener que escribir las funciones de serializacion/deserialización cada vez que se crease un tipo de dato nuevo.

En mi afán de obtener grandes resultados con el mínimo esfuerzo se me ocurrió que quizás con annotations en PHP podría especificar el tipo de datos de cada propiedad y crear únicamente serializadores genéricos que no habrían de ser tocados cada vez que se crease una nueva clase.

La clase anterior bien podría quedar tal que así:

class Cosa {
    /* @type = ‘string’ */
    public $DatoCadena = ‘pakito’;
    /* @type = ‘float’ */
    public $DatoFloat = 0.123;
    /* @type = ‘integer’ */
    public $DatoEntero = 123;
    /* @type = ‘array’, @object_type=’Objeto’ */
    public $ArrayDeObjetos;
}

Limpio, claro y sin errores. Y además los componentes que tuviesen que tratar con esos objetos podrían tener especificados el tipo de datos con el que trabajarían y, si algún día hubiese que cambiarlo, sería modificar un simple parámetro. Por ejemplo:

/* @object_type = ‘Cosa’ */
public function HacerCosas {...}

Pues sí, aunque conozco a muchos desarrolladores que están en contra de estas cosas tan dinámicas, de construcción automática de código, de mapeos y de cosas así... no puedo evitarlo, a mí me gusta.

Si a la supuesta sobrecarga de la “interpretación” de PHP (medio desmentido aquí: http://www.phpclasses.org/blog/post/155-Top-10-Wrong-Ideas-About-PHP-That-You-Should-Get-Right.html ) le añades que antes ha de examinar (reflexión) las clases de datos y decodificarlas la aplicación se morirá de asco.

Yo no he notado disminución de rendimiento apreciable y sólo por la comodidad que me ofrece vale la pena la posible “pérdida” que pudiese acarrear. Hay que tener en cuenta que en los entornos de desarrollo yo no uso op-code caches ni optimizaciones de ningún tipo (memcache, caché de páginas, etc.).

Para “escoger” qué solución de Annotations era la más adecuada, en mi caso, me guié por las opciones presentadas aquí: declarative development using annotations in php. Al final me decidí por Addendum  porque no todos los hosting tienen la posibilidad de instalar PEAR y porque además podría modificarla a gusto si lo necesitase.

En unga todos los DTOs están “anotados” y me resulta muy sencillo realizar clases de serialización. Por ahora serializa para XML y JSON pero hay un futuro brillante esperando porque la era móvil me está obligando a pensarme ciertas cosas sobre la presentación.

Así que sí, PHP tiene Annotations. Y decían que no era un lenguaje serio...

Salut!

To REST or not to REST

Hay veces en las que no puedo evitar maravillarme por la raza humana. Somos capaces de crear unas herramientas increíbles y extremadamente versátiles, estudiarlas, justificarlas científicamente y analizando los pros (muchos) y los contras(escasos) de su uso... y acto seguido enviarlas a la mierda y condenarlas al ostracismo.

REST me parece uno de esos casos.

¿Qué es REST? Pues algo similar a ésto, en su forma más pura: REST en la wikipedia.

No es muy largo de leer pero por si acaso lo resumo:
- La mayor parte de las operaciones que realiza una aplicación es crear, actualizar, consultar y leer tipos de datos (clientes, productos, tweets, mensajitos de facebook, etc.) o “recursos” en la jerga. Lo que se llama CRUD.
- Si estás trabajando en la web, con el protocolo HTTP, puedes especificar la operación a realizar: get, post, put y delete (entre otras). Eso es el request method.
- Sé listo y simplifica tus aplicaciones web, que casi todas son CRUD, y no llenes de mierda las urls. Usa los “request method” http y sé limpio.

Pues no hay manera oye. Raro es el servicio web que usa “bien” REST. La gran mayoría te obligan a hacer verdaderas salvajadas del tipo:
http://servicio.com/uno/dos/tres/nombredeserviciototalmenteimposibledememorizar?op=1&papepipopu=asdf&pongaaquisusdatosinutiles

Como mucho se usa POST para enviar datos y GET para leerlos pero el resto de métodos se los han olvidado. Pero ¡ay de ti como se te olvidase la tabla de operaciones del parámetro “op”! (¿borrar era 1 o 4?)

Comprendo que quizás hace 5 o 10 años fuese difícil de hacer que un navegador enviase una petición DELETE, pero hace tiempo que estamos en la era AJAX y hacer las cosas bien y claritas no habría de ser tan complicado... ¿o será vagancia?

Sea como sea yo me he erigido a título personal en defensor del RESTarismo, soy un RESTafari de pro, y quizás fundamentalista. Desde hace ya tiempo no soporto ver código que no siga las especificaciones REST: si vas a hacer CRUD, hazlo bien, ¡carajo!.

Comprendo que hay recursos o servicios que son imposibles o dificilmente expresables usando REST, por ejemplo un servicio de login, pero para todo lo demás, teniendo en cuenta que la mayor parte de lo que hacemos es actualizar objetos : si pretendes que yo use tus APIs, facilítame el trabajo.


Al llegar a este punto voy a darme algo de autobombo con unga, mi mimadito framework PHP, está preparado para REST “puro”: implementar servicios CRUD es tan sencillo como crear un controlador y hacerlo heredar de REST_Controller (sí, mala elección de nombre, ya lo cambiaré).

Ese REST_Controller se va ocupar de recoger los parámetros de la url, recoger los datos de la petición (si los hubiese) y redirigir a la función correspondiente (create, retrieve, update, delete) según el “request method”.

Lo he hecho tan sencillo, además, que incluso no habrá que teclear ni una línea de código para llevarlo hasta la base de datos: crea una clase Model, indícale su nombre al Controlador y éste se encargará de hacerlo todo.

Es similar al scaffolding que te da Ruby on Rails pero un poco más elaborado y, sobre todo, fácilmente modificable.

¿Qué quieres obtener un dato? GET a http://servidor/servicio/objeto/id/xxxx
¿Que quieres borrar? DELETE hacia http://servidor/servicio/objeto/id/xxxx
¿Que quieres crear uno nuevo? POST a http://servidor/servicio/objeto

Más fácil, imposible. Y si además unimos que se puede filtrar por cualquier campo (id, name, product_name, manzanas, peras...), que admite filtros avanzados (<, >, like...) y que trabaja indistintamente con JSON o XML (con sus restricciones)... Es que cada vez que lo veo me beso a mí mismo.

Lástima que no esté todo lo estable que yo desearía, pero todo llegará.

En resumen, una buena parte de los servicios que pululan por internet, emulando a algunas pancartas del 15-M “lo llaman REST y no lo es”. Eso es lo que quería dejar claro: en muchos casos estamos infrautilizando la tecnología o arrastrando errores año tras año, por cabezonería (y yo el primero).

La próxima vez que tengas que hacer un CRUD: piensa en REST.

Salut!


Más información:
REST Web Services
Introducción a REST
Más REST
Presentación sobre REST

Entorno de Desarrollo (III) - Eclipse y xdebug

Tras instalar un entorno donde ejecutar PHP el siguiente paso lógico, tras probar que funciona, sería decidir cómo editar los ficheros (o páginas) que vamos a utilizar.

Como ya he dicho hay gente que todavía usa el bloc de notas (o sus equivalentes en Linux, incluyendo vi o Emacs) y algún “avanzado” ha descubierto Notepad++ o Ultraedit (probablemente crackeado, que todavía no conozco a nadie que haya pagado por él).

Yo soy algo más pijo y prefiero un entorno “integrado” donde poder ver todo a primera vista, tener arbolitos con mis objetos categorizados y poder navegar con comodidad entre los, habitualmente, cientos de objetos con los que suelo trabajar. Y lo más importante, necesito, o mejor, me es imprescindible el poder depurar el código, porque no siempre un fichero de log te da todo lo que necesitas.

Yo para todo esto uso Eclipse PDT, que es una especialización de Eclipse para trabajar con PHP. Es lo que YO uso y lo que yo recomiendo a quien me pregunta. Este entorno cubre por completo mis necesidades y además, para los que hemos trabajado con Java, es un entorno casi “de facto” por la cantidad de plugins útiles que tiene para nuestro trabajo diario.

Si a alguien le interesan otros entornos, como Zend Studio o similares, no voy a hablar de ellos aquí.

Instalar Eclipse no tiene demasiado secreto:

• En Windows es bajarse un fichero y descomprimirlo (doy por supuesto que se tiene la máquina virtual de Java).
• En Linux suele estar en los repositorios de programas y si no, habrá que buscar ayuda en la web de eclipse o preguntando a papá Google.

Como ya advertí la información que ofrezco no es para muñones, así que habrá que acostumbrarse a leer, que yo solo soy el padre de mis hijos, no de todo el mundo.

Si ya se tiene un Eclipse instalado podría actualizarse para que maneje PHP. En la web de Eclipse nos lo explican de manera bastante sencilla: http://wiki.eclipse.org/PDT/Installation

Cuando hayamos acabado ya podremos acceder a nuestra nueva instalación de Eclipse y editar ficheros como tontos.

Entorno Eclipse

xdebug - depurador y más

xdebug es una pequeña maravilla para PHP que nos va a permitir (entre otras cosas):
- Depurar código PHP (depuración remota).
- Realizar profiling del código ejecutado.
- Realizar Code coverage del código, muy útil para el test unitario.

Instalar xdebug es relativamente sencillo y en este enlace de Zend lo explican paso a paso: http://devzone.zend.com/article/2803-Introducing-xdebug.

Para Linux la manera más sencilla es instalando a través de PECL que es algo así como un macro repositorio de cosas útiles.

Para instalar PECL en ubuntu y similares se han de tener instaladas PEAR y las herramientas de desarrollo de php, tal como explican en este enlace: how to install PECL extensions.

Realmente debería instalarse con los comandos:

sudo apt-get install php-pear
sudo apt-get install php5-dev
sudo pecl install xdebug

En Windows hay que tener cuidado ya que se ha de saber con qué versión de Visual C++ ha sido compilada nuestra versión de PHP y si tenemos o no una versión Thread Safe. Para evitarnos problemas en esta página se puede pegar lo que nos devuelve phpInfo y sabremos qué versión descargar: Find xdebug binary

Tras instalarlo habría que activarlo y configurarlo y para ello hay que editar el fichero php.ini. Su ubicación depende del sistema operativo y el servidor LAMP/WAMP usado.

• Si se usa Wampserver en Windows se puede acceder a él a través del panel de control.
• En Linux suele estar en el directorio /etc/php5/apache2 o alguno similar y si no siempre se puede localizar utilizando estos comandos:

sudo updatedb
sudo locate php.ini

Una vez editado el fichero php.ini habrá que agregar una línea similar a la siguiente (cambiar las rutas por las que correspondan a la ubicación de la librería xdebug):

Windows:

zend_extension_ts="c:\php\ext\php_xdebug-2.0.1-5.2.1.dll"

Linux:

zend_extension="/usr/lib/apache2/modules/xdebug.so"

Yo suelo ubicarla al final de la definición de las extensiones porque justo después agrego la configuración de xdebug.

Existen varios parámetros que se pueden configurar (agregar las líneas indicadas en el php.ini, tras las anteriores), aunque yo, personalmente, sólo suelo incluir los siguientes en una instalación básica:

[xdebug]
xdebug.remote_enable=On
xdebug.remote_host="localhost"
xdebug.remote_port=9000
xdebug.remote_handler="dbgp"

Esto nos permite depuración remota desde localhost para el puerto 9000. Todas las opciones de configuración están explicadas en la documentación de xdebug así que sólo me pararé cuando alguna me parezca importante.

En mi caso, dado que uso ciertos servicios que trabajan en el puerto 9000 suelo tener que cambiar el parámetro xdebug.remote_port a otro puerto.

Ahora ya deberíamos tneer preparado el entorno para depurar y para ello reiniciamos Apache:

Linux

sudo service apache2 restart (o su equivalente en otras distribuciones)

Windows

Desde el panel de control de WampServer o el que sea.

Al ejecutar http://localhost/info.php (que espero que no se haya borrado) se deberá obtener algo similar a lo mostrado en la figura:

phpInfo + xdebug

 This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
   with Xdebug v2.0.5, Copyright (c) 2002-2008, by Derick Rethans
Y deberá existir una sección xdebug donde se podrán ver todos los parámetros de configuración de la extensión.

Si el servidor no arrancase habría que examinar los logs de Apache y PHP para averiguar qué extensión está fallando y buscar ayuda en internet. Los errores que me he encontrado yo han sido, casi siempre, librerías de versiones erróneas.

Depurando con Eclipse

Llegamos a la parte útil y donde comenzaremos a ver la potencia de xdebug: depurando.

En este artículo podemos ver los pormenores de configuración del entorno de depuración, que no es que sea nada del otro mundo: Debugging PHP Applications with xdebug

La secuencia de pasos está bastante clara y, conociendo un poco Eclipse, se puede averiguar dónde cambiar ciertas opciones de configuración.

Por ejemplo, podemos cambiar el depurador o cambiar sus opciones (en el caso de que se cambie el puerto, por ejemplo). O eliminar el check que viene marcado por defecto siempre de “Break at first line” que con proyectos grandes puede hacerse pesado.

Todo eso puede hacerse desde la opción PHP de la ventana de preferencias de Eclipse:

Para averiguar qué efecto causa cada cosa se puede recurrir al clásico “trastear”. No estoy yo para hacer manuales pormenorizados de todo. Si hubiese problemas, internet es una gran fuente de información y casi seguro que los errores que tenemos le han sucedido a alguien ya.

El caso es que ya deberíamos haber acabado de configurar Eclipse para que pueda depurar remotamente así que vamos a crear un fichero de prueba llamado simple.php y rellenarlo con este código:

<?php

class Pakito {
    public function show($message) {
       $result = 'Este es el mensaje: '.$message;
       echo $result;
    }
}

$clase = new Pakito(); // Agregar punto de parada aquí
$clase->show('Chorrada de prueba');

?>

Odio hacer programas de ejemplo así que me he lucido bastante poco con éste. Tampoco es que la calidad vaya a variar mucho en el futuro por muchas críticas que reciba, así que en este caso toca aguantarse con lo que hay.

Primero deberíamos poner un punto de parada en la línea que he indicado y eso se hace desde dentro de Eclipse. Deberías saberlo ya: doble click en la zona sombreada del editor de ficheros.

El siguiente paso es lanzar la depuración en sí: botón derecho sobre el fichero (en el árbol de ficheros) y seleccionar la opción de “Debug as” y “PHP Web Page”.

Y si todo va bien (que debería) se abrirá la perspectiva de depuración PHP de Eclipse y el depurador se nos parará en el breakpoint indicado en nuestro chorriprograma (o en la primera línea si es que no hemos quitado el check).

Se puede ver que disponemos de las habituales herramientas de depuración de Eclipse, incluidas la pila de llamada y las variables. Como curiosidad se pueden acceder a las variables internas del servidor (por ejemplo $SERVER, $REQUEST o $COOKIES). ¡Semos todopoderosos!

Supongo que llegar a este punto no debería haber dado demasiados problemas. Lo que pudiera surgir probablemente sería alguna mala configuración de rutas (por ejemplo la ruta hacia el ejecutable de php) o de puertos. De todas formas: siempre nos quedará internet.

xdebug es una herramienta tremendamente potente de depuración y, aunque hablaré de ello en detalle más adelante, aquí van un par de enlaces, además de los presentes en la documentación oficial, para saborear sus posibilidades de Profiling (mucho cuidado porque se come el disco en un visto y no visto) y Code Coverage.

En unión con PHPUnit es una herramienta my efectiva para el TDD.

En futuros posts ampliaré la parte de Code Coverage con PHPUnit y Phing, el equivalente de ANT para PHP.


Salut!

Entorno de desarrollo LAMP (II) - Servidores web

En este artículo voy a mostrar cómo instalar un servidor LAMP/WAMP completo: Apache + PHP + MySQL.

Como no pretendo montar un supertutorial y repetir toda la información disponible por la red sólo voy a comentar los enlaces y dar ciertas indicaciones en casos especiales.

Tampoco, en este artículo, entraré en discusiones sobre si es mejor Apache como servidor web o debería usar Lighttpd porque es la bomba, o si MySQL, Oracle o PostgreSQL como motor de base de datos. Mi intención, ahora mismo es tener un entorno (de desarrollo, integración e incluso producción) funcionando. Si el desarrollo se realiza de forma correcta la migración a otros entornos no debería traer demasiados dolores de cabeza.

Empezaremos con el servidor LAMP/WAMP: Apache, PHP y MySQL. Las instrucciones las daré para Windows y Linux (en principio ubuntu y derivados)

Windows

Para Windows yo suelo utilizar WampServer, no porque sea mejor o peor sino porque es sencillo de instalar y estoy acostumbrado a su panel de control. A algunos les gusta más XAmpp pero yo sólo he usado éste para crear “demos” y llevármelas en un lápiz usb.

Como la página principal es muy explicativa y la instalación es sencillísima no voy a entrar en más detalles. Sólo hay que ir a http://www.wampserver.com/en/ y seguir las instrucciones.

Página web de WampServer

Tras hacer la instalación tendremos un icono nuevo, llamado WampServer, y al lanzarlo nos aparecerá un nuevo “applet” en la barra de herramientas desde donde podremos lanzar/apagar el servidor y realizar algunas tareas de configuración.

Icono WampServer y panel de control

A través de los menús podremos activar y desactivar módulos de Apache y PHP así como acceder al gestor de bases de datos PHPMyAdmin. Activar un módulo es tan simple como hacer click sobre él; WampServer se reiniciará y el módulo estará disponible al momento.

También se puede realizar lo mismo a través de los ficheros de configuración correspondientes (httpd.conf, php.ini, my.ini) a los que se puede acceder a través del panel de control de WampServer.

Editando httpd.conf

Para comprobar que está correctamente instalado (tanto el servidor web como PHP) simplemente se ha de crear un fichero con el nombre, por ejemplo, info.php con el siguiente contenido:

&lt;?phpphpInfo();
?&gt;

Este fichero ha de guardarse en el directorio “root” de apache. Si no se han tocado demasiado las rutas será algo como c:\wamp\www. Una vez allí sólo habrá que dirigirse a http://localhost/info.php y comprobar que se obtiene alguna pantalla similar a la mostrada.

phpInfo()

Otro paso es comprobar la base de datos y ésto se puede hacer con phpMyAdmin desde el panel de control de WampServer. Debería aparecer algo similar a la imagen de abajo.

phpMyAdmin

Si algo falla habrá que bucear en internet para descubrir qué es, a menos que uno sea adivino. Se pueden consultar los logs de cada aplicación desde el panel de control de Wamp. Muchas veces serán problemas de módulos de Apache/PHP mal configurados (por lo que recomiendo desactivarlos todos e ir activándolos uno a uno hasta llegar al culpable) o conflictos con puertos (por ejemplo tener instalado el IIS a la vez que el Wamp)

Apache error log

Linux

Como he dicho me voy a basar en Ubuntu y sus derivadas y presupondré que se saben instalar programas para este sistema operativo. Como no soy tan mala persona como parezco ahí va una pista: en esta página hay muchísima información sobre ubuntu y cómo trastear con él - Slice of Linux.

Normalmente al instalar Linux se pueden seleccionar los paquetes a agregar así que es probable que alguna parte de los componentes esté presente ya. Aunque se lance la reinstalación la mayoría de sistemas de empaquetado de Linux son lo bastante inteligentes como para comprobar antes si ya existe el programa.

Yo soy de los que prefiere comenzar con una instalación básica sin demasiada porquería e ir añadiendo a mano lo que necesite. Como buena parte de lo que hago va a estar en servidores y abierto a internet me parece muy peligroso meter toda la mierda de golpe y dejarla descontrolada. Linux es seguro, sí, pero yo no pondría la mano en el fuego porque ningún programa no te vaya a abrir un puerto que no deseas o bajar una configuración que dé acceso a los “programas de hacking” que ejecutan los script kiddies por ahí.

Por otra parte rara será la empresa de hosting que te ofrezca un terminal remoto o un panel de control aceptable a precio razonable así que considero imprescindible, cuando instalo un entorno de integración o pre-producción, que sea lo más parecido al entorno real, sin aditivos innecesarios. Lo mejor es ver paso a paso cómo instalar un ubuntu server.

También es conveniente ver cómo instalar un sistema “AMP” paso a paso en Ubuntu 11.04 (vale también para otras versiones). Las diferencias con Debian u otras distribuciones que usan paquetes .deb son mínimas (quizás de versiones). Para el resto de distribuciones, pues habrá que buscar ayuda; yo hace años que no uso CentOS o Fedora. La culpa es vuestra por usarlas :-P

Es recomendable instalarse phpMyAdmin en Linux ya que, a diferencia de los “AMP” de Windows, no suele estar por defecto.

Prometo que, por ahora, Canonical no me paga nada para que haga publicidad de Ubuntu. Lo que pasa es que soy un poco muñón cuando toco cosas y si la cago prefiero tener dónde buscar soluciones... y los Ubuntus están hasta en la sopa. Lo fácil que es googlear “lamp ubuntu” y que te devuelva chorrocientos tutoriales y hacer lo mismo con Fedora y que se acaben en la página 1...

Bien lo importante de esta instalación es recordar que las páginas web deberán alojarse en el directorio “var/www” (o su equivalente que habrá que buscar convenientemente según la distribución usada).

En este punto tendremos un servidor Apache, con PHP y MySQL así que ya se puede empezar a trastear. Todavía no está “seguro” ya que, por ejemplo, la clave de root en MySQL es probable
que esté en blanco o que sea un verdadero coñazo ejecutar ciertos scripts desde phpMyAdmin.

Bonus - MySQL Workbench

Alguno, sobre todo los que provenimos del mundo Oracle, podría echar de menos el Toad, aunque existe una versión para MySQL. Pero, ¿para qué pagar cuando puedes tener una herramienta similar, o incluso mejor, de forma gratuita?

De las pocas cosas buenas que hizo Oracle cuando compró MySQL fue unificar todas las herramientas de cliente en una sola: MySQL Workbench. Entre las cosas malas que hicieron fue subir los precios, pero ya lo criticaré si lo veo conveniente.

Con esta herramienta se pueden ejecutar scripts, acceder a las base de datos y a sus objetos, diseñar visualmente el modelo de datos e incluso controlar los servidores (start, stop, backups...). Así que recomiendo encarecidamente que cualquiera que vaya a trastear con bases de datos se lo instale.

MySQL Workbench. Tomada de www.mysql.com

En Windows es fácil: descargarse el ejecutable y lanzarlo. En Linux o bien está el programa en la lista de “instalables” o habrá de hacerse a mano (ésto para ubuntu https://help.ubuntu.com/community/MySqlWorkBench). Lo malo es que es muy probable que después de que Oracle haya metido las zarpas ya no exista un versión Open Source que pueda incluirse en los repositorios.



Bonus II - Cambio password de root (mySQL)

Tal como suelen estar las instalaciones por defecto en mysql la verdad es que de seguridad, poca. En Linux es probable que sí haya solicitado una password pero con Windows, y con el WampServer, estoy casi seguro que la password será “en blanco” (no literalmente... password vacía).

Con phpMyAdmin se puede cambiar la password sin problemas desde la pestaña de Privilegios y editando el usuario afectado.

Tras cambiar la password, phpMyAdmin dejará de funcionar y habrá que editar el archivo config.inc.php para incluir las nuevas credenciales.


Bonus III - Panel de Control Web en Linux

Cuando trabajo con servidores Linux me resulta un engorro el tener que entrar por telnet para reiniciar servidores o editar ficheros, sobre todo para lo último. Si el ordenador está cerca y es accesible al 100% no hay problema ya que siempre se puede instalar un entorno gráfico y la cosas se facilita. Si el ordenador está a 3000 km en un hosting podemos morirnos con los tiempos de latencia: movemos el ratón y, tras un café o dos, responderá al otro lado (sí, exagero).

En estos casos “remotos”, si nuestro proveedor de hosting no nos provee de un panel “chachi” como cPanel (de pago) tenemos todavía una opción free: Webmin.

Con este panel de control podemos controlarlo todo de manera visual y usando un navegador. Usa applets Java (puaj!) para ciertos servicios, pero es un mal menor. No es que la línea de comandos no sea bonita pero si nos ponen las cosas algo más fáciles acabaremos antes.

Como ya otros han escrito sobre el tema me ahorro el hacerlo yo. Para instalar: http://sliceoflinux.com/2009/09/07/instalar-webmin-en-ubuntu-paso-a-paso/. ¡Ojo! hay que tener cuidado con las versiones de Wembin o de sus dependencias. Lo mejor es ir a la página y asegurarse de que estamos descargando la versión más reciente.

Bonus IV - Activar/desactivar módulos de Apache (y PHP)

Usando WampServer en Windows es tan sencillo como poner o quitar el check en el módulo afectado (poner es pulsar una vez, quitar, es pulsar otra vez, el servidor se reiniciará cada vez que se cambie).

Sucede lo mismo para activar o desactivar módulos de PHP (excepto algunos que se verán más adelante).

Con Linux (basadas en Debian) es similar, pero en vez de usar el ratón se usarán los comandos "a2enmod" (activar) y "a2dismod" (desactivar) seguidos del nombre del comando. Por ejemplo, para activar el módulo rewrite (mod_rewrite):

a2enmod rewrite

Si nuestro Linux no dispusiese de este comando habría que buscar una alternativa o editar el fichero httpd.conf (normalmente en /etc/apache2) y comentar o descomentar la línea del módulo afectado.

En el caso de los módulos PHP no recuerdo si existe algún comando similar así que lo que se suele hacer es editar el fichero php.ini (su ubicación cambia según la distribución) y comentar o descomentar “lo que sea”.




Tras seguir todos estos pasos ya disponemos de la base para ejecutar programas con PHP. Realmente dispondremos de un servidor que podríamos publicar hacia internet y al que se podría acceder (usar la opción “Put Online” o su equivalente en castellano del panel de control de WampServer) desde fuera.

Dando acceso al servidor para internet

Es más, como tenemos un servidor Apache hecho y derecho, nada nos impediría instalar otros módulos para otros lenguajes, por ejemplo Python o Ruby. En un futuro escribiré algo sobre cómo trastear con ello y cómo trastear con otros servidores web y bases de datos.

Si a alguien le apetece jugar que pruebe a instalar un gestor de contenidos (CMS), como por ejemplo Drupal. Funcionará seguro, aunque es probable que haya que activar algún módulo.

Por ahora lo dejo aquí. Espero no haber olvidado nada.

Salut!

Una tontería

Una gilipollez que me han pasado y me ha hecho gracia...


Y aquí el original



mooooooola

¿Sistemas o Desarrollo?

El post anterior ha hecho que vuelva a mi mente una pregunta que me hicieron hace años, allá por la prehistoria: ¿y tú qué eres? ¿sistemero o picateclas?

Cuando me la hicieron conteste como buenamente pude porque en esa época todavía había preguntas que me descolocaban. Mi respuesta fue algo así como “persona, soy persona, y tú eres un racista” (y me fui llorando... no estoy orgulloso de ello). En aquella época me negaba a aceptar que alguien que programaba no supiera batirse con la configuración de un servidor, o no supiese instalar, por ejemplo, algo tan simple como una base de datos.

He de decir que mi “background” es del mundo del metal. Aparte de que entre mis grupos de cabecera están Metallica, AC/DC y Van Halen mi “otra” parte de metal viene de que durante casi una década me dediqué a cacharrear en las tripas de las máquinas. Me daba igual meterme dentro de un cajero automático, toquetear un S/36 de IBM, untar un cable con vaselina para que pasase por un conducto atestado con otros cables (y algún ente vivo con dientes) o diseñar y configurar un dominio para 100 puestos de trabajo con Windows NT.

Lo del desarrollo empezó como un hobby y se fue profesionalizando cuando pude dar “el gran salto”. Hasta el momento saltamontes yo estaba más que acostumbrado a cacharrear, llevarme calambrazos por tocar donde no debía y a tratar de entender en qué coño estaba pensando el tío que diseñó esa manera tan extraña de configurar un programa.

Y como los que me rodeaban hacían más o menos lo mismo que yo llegué a creer que si te dedicabas a eso de la informática tenías que saber de todo porque cualquier día podía hacerte falta.

Pero he aquí que un día entré profesionalmente en el mundo del desarrollo de software y tenía un alma inocente y muchas ganas de aprender. O sea, era un pardillo.

Para mí los programadores eran una élite inalcanzable, con grandes cerebros (y muchas veces, cabezas), capaces de entender conceptos abstractos que al resto de los mortales se nos escapaban (hoy es el día en el que todavía tengo que pensar dos veces cómo hacer una función recursiva), todopoderosos, pues podían controlar y reprogramar cualquier aparato que cayese bajo sus narices. Los que se dedicaban a programar para mí eran “los putos amos”.

Esos analistas, hablando de cosas como singletons, multithreading y transacciones. Aquel jefe de arquitectura que se había currado un puente COM/Corba que todavía hoy sé que sigue en producción en algún sitio. Ese programador con años de experiencia, admirado y puesto como ejemplo de eficiencia por tus jefes, que te miraba con suficiencia cuando hacías una pregunta simple sobre JSPs (casi seguro que pensaba “ya viene a tocarme las mandangas el mierdecilla este... así no hay quien chatee a gusto”).

Para mí era como estar en Hollywood o en la NASA. Cuando me preguntaban “y tú en que trabajas?” se me llenaba la boca diciendo “soy desarrollador de software” (ahora digo que soy Analista, que parece que tiene más estilo). Las mujeres caían a mis pies, me abrían todas las puertas de las discotecas y andaba como si tuviera una escoba metida por el culo (hasta llevaba traje y tenía el pelo corto).

El día que me hicieron la pregunta de “sistemero o picateclas”, tras secarme las lágrimas y dejar de temblar, me puse a reflexionar y a observar a mi alrededor para ubicarme.

Todavía hoy me dura el disgusto.

A la mayor parte de los que me rodean (y rodeaban) les dices que te configuren un servidor, aunque sea uno como con el que están trabajando cada día, y les da un telele. Yo creo que sacarlos de picar código a cascoporro y ponerlos a resolver una incidencia sencillita de configuración los mataría. Me parece tristísimo, pero la distinción entre técnicos de sistemas y técnicos de desarrollo existe, y la zanja que los separa es lo suficientemente amplia para que se le quiten a uno las ganas de saltar.

Ojo que tampoco digo que eso sea malo, cada uno se especializa en lo que quiere o en lo que cree que le va a dar dinero. Hasta ahora ha sido Java y su ecosistema, que das una patada a un edificio y te caen 1000 programadores. Cuando yo empecé era Visual Basic y Clipper (y todavía estaba Cobol).

Está claro que no puedes saberlo todo. Si eres la bestia de los EJBs no tienes tiempo para dedicarlo a ser un master del universo en Oracle o un supercertified de la muerte en Windows Azure.

Pero aún así a mí me sigue pareciendo extraño que haya personas que usan cosas que no saben como funcionan; bueno no, la analogía no es buena, pues casi todos usamos el coche y no tenemos ni idea de cómo cambiar las bombillas. Es como si te dedicases a construir motores de coches sin tener ni idea de si el chasis va a soportarlo, de dónde va a ir anclado o de si la carrocería es lo suficientemente amplia para que quepa.

Hoy yo tengo claro qué respondería a la pregunta de “sistemero o picateclas”. Usaría la definición no oficial de “rol” que me pusieron años ha: soy un asterisco.

En mi caso me he negado a especializarme. Lo toco todo y no le tengo miedo a ninguno de los nuevos juguetes que esta profesión nos da (asco sí, miedo no). Quizás he tenido suerte y he caído en departamentos y/o proyectos que me han dejado expresarme como el aprendiz de todo y maestro de nada que soy (sí, y he sido responsable de la arquitectura de varios de ellos).

¿Disperso? Quizás. Pero tengo la tranquilidad de saber (por haberlo comprobado) que cuando algo falla yo sé arreglarlo.

Y todo este tocho me ha venido a la cabeza por culpa de una pregunta...

Salut!

Entorno de Desarrollo LAMP (I) - Introducción

El primer paso lógico para empezar a desarrollar lo que sea con lo que sea sería disponer de un entorno de desarrollo. Ese entorno debería ser cómodo de utilizar, debería permitir depurar (porque examinar logs NO es una buena opción mientras desarrollas) y ya si permite esas cosas para frikis de Test unitarios, ayuda a la documentación, compilación, despliegue... vamos, eso es para nota.

No es que sea imprescindible, claro. Durante una temporada yo estuve programando en C++ editando con el vi directamente en un host HP-UX y todavía sigo aquí. También he conducido coches sin dirección asistida, he tenido bicicletas sin frenos (me dejaba la suela de los zapatos en la rueda de atrás) y tele sin mando a distancia.

Conozco a algún programador que edita ficheros PHP con el bloc de notas de Windows; conozco a alguno que cuando le enseñé el Notepad++ casi tuvo un orgasmo mental al ver tantos colorines e incluso he visto los ojos de alguno saliéndose de las órbitas al ver cómo yo depuraba tan tranquilamente con xdebug mientras él sufría leyendo archivos de texto que no daban pistas.

Lo que quiero decir es que a día de hoy, en el año 2011, con todas las herramientas que tenemos a nuestro alcance los desarrolladores (la mayoría de ellas gratuitas), la potencia de nuestros ordenadores y toda la ayuda que se puede encontrar por internet hay que ser un pedazo de inútil, cenutrio y lerdo para trabajar de manera precaria. Además opino que gente así no debería tener derecho a tocar un ordenador, pero esa es otra historia.

Podría disculpar a aquel que tiene que aguantarse con las herramientas que su “jefe” le provee. Sí, hay muchos que se hacen llamar “jefes de proyecto” o “gestores” que son capaces de condenar a un equipo de desarrollo a malvivir y maltrabajar por ahorrarse unos euros (o más bien transferirlos a su bolsillo para su viaje a Costa Rica).

El asunto es que a mí me gusta trabajar a gusto, con las herramientas adecuadas y si puedo ahorrarme tiempo gracias a ello, mejor, porque así podré dedicarlo a mi gran afición: no hacer nada.

Como éste es el entorno de desarrollo que a MI me gusta voy a usar los siguientes componentes:

• Un servidor LAMP, WAMP o como quiera que se llame para Mac, a gusto del consumidor. No soy demasiado racista para los sistemas de escritorio. En el caso de Mac no daré ninguna indicación pues ni tengo ni quiero :-)
• Varios componentes extra de PHP: xdebug (depuración/caché), APC (caché de código), memcached (caché, porque yo lo valgo), PEAR (librerías extra)...
• Eclipse PDT como entorno de desarrollo. No es que me me disgusten los otros, es que o vienen limitados, o con pocos plugins o, simplemente, son de pago (y yo, pobre).
• Extensiones para Eclipse (test unitario, documentación, acceso a repositorios de código, etc.)

Como las cosas al pasarlas al entorno real suelen cascar bastante (me vienen a la cabeza problemas con mayúsculas y minúsculas al pasar de Windows a Linux) también comentaré algo sobre montar un entorno de “integración” usando máquinas virtuales. En este caso usaré VirtualBox, porque me parece bastante ligera y es la única que me ha permitido mantener 4 máquinas virtuales funcionando simultáneamente sin que el ordenador se me muriera de asco. Adiós VMWare.

Una advertencia: en principio no escribo para cenutrios. Presupongo unos conocimientos mínimos (saber mover el ratón sin tirones, por ejemplo) y espero que los links que voy proveyendo se vayan leyendo porque me niego a repetir cien veces lo que otros ya han explicado.

De todas formas si alguien necesita ayuda extra yo nunca me niego a trabajar si hay dinero por medio. Mi tiempo no es gratis y lo pierdo como a mí me da la gana.

El post se me ha quedado demasiado largo así que dejaremos la chicha útil para el siguiente. Eso sí, no prometo que no se me vaya a ir la olla otra vez y me ponga a contar batallitas.


Salut!



Pd - Lo que tengo se llama verborrea y está mezclado con dispersión. Es que empiezo a acordarme de cosas y o las pongo o las pongo.