Conferencia deSymfony 2012

Como muchos ya sabreis, otros posiblemente no, durante las fechas del 15 y 16 de junio, se realiza en Castellón una de las citas más importantes en el panorama de las TI.

La comunidad de Symfony española, vuelve a organizar la conferencia "deSymfony", esta vez de una duración de dos días y en la que el propio Fabien Potencier, creador del Framework Symfony acudirá en persona para hacer una ponencia.

Aunque las ponencias están basadas en el framework que le da nombre (Symfony2), se hablarán de todo tipo de consejos, trucos, tutoriales sobre como manejar los complementos que lo componen, así como de buenas técnicas de uso y de como optimizar al máximo su rendimiento.

Se tratarán temas como el uso de Twig, Varnish, el uso de MongoDB como sistema de base de datos, internacionalición y otros componentes y servicios.

Entre los ponentes, podremos contar con la presencia de Javier Eguiluz, administrador de la comunidad española de Symfony (www.symfony.es), Nacho Martín, que ya fué ponente en el 2011 (al que tengo que agradecerle personalmente que me ayudara con la configuración de VIM) y como ya se ha mencionado, el propio Fabien Potencier.

La lista entera de ponentes la podreis encontrar en la web del evento http://desymfony.com/.

La entrada se compra a través de esa misma web a un precio de 55€ que incluye las comidas (no las cenas) de los 2 días de ponencia.

Me gustaría hacer un incapié especial a la oferta de tren para los que asistan al evento. Descargándo una cédula de viaje desde esta web: http://desymfony.com/noticias/grandes-descuentos-asistentes-viajan-tren, los asistentes que viajen en tren disfrutarán de un 30% de descuento.

Poco más puedo extenderme, ya que sería repetir información que podreis encontrar en la web oficial, os invito a que la visiteis. Un saludo, nos vemos en Castellón.

Fuente oficial: http://desymfony.com/

CakePHP: Pros y contras (según mi opinión)

Actualmente llevo ya más de 2 años trabajando con el Framework de CakePHP 1.2. No elegí yo trabajar con este framework, pero se me impuso en su día y al principio tengo que reconocer que me pareció una buena idea. Hasta ahora, que lo conozco bien y conozco sus mayores defectos (y seguro el de la mayoría de frameworks), por lo que en el futuro procuraré evitar cometer los mismos errores.

Voy a comentar mi punto de vista sobre el Framework, aunque tampoco me extenderé mucho. Empezaré por las ventajas.

PROS

1. Fácil de aprender: Hay que reconocer que desarrollar con CakePHP es fácil y sencillo una vez te has documentado un poco y conoces la estructura de ficheros. Sin conocerlo de nada, en 2 días ya estaba creando mis primeras pantallas con el.
2. Implementación rápida: Gracias a su estructura y los métodos propios del framework, desarrollar una aplicación puede realizarse en poco tiempo, eso si, en relación a si hubiera que hacerlo de 0, o si la aplicación no necesita modificaciones personalizadas.
3. Migración entre entornos: Instalar una aplicación desarrollada con CakePHP es muy fácil, ya que  si tienes bien configurado el servidor en el nuevo entorno, bastará con copiar y pegar el código en el nuevo entorno. No necesita muchas librerías especiales, pero repito, depende de la aplicacuón y los componentes o plugins que se le añadan.
4. Plugins: Mencionados en el punto anterior, se pueden encontrar por internet plugins que realizan una tarea específica sin tener que programar nada. Basta con bajarse el código y añadirlo a la carpeta de plugins de CakePHP. Lo mismo pasa con algunos "componentes" y "helpers".

Hasta aquí las ventajas más significativas que voy a comentar de CakePHP. Ahora pasaré a lo que para mi, es motivo suficiente como para no volver a utilizarlo en futuros proyectos:

CONTRAS

1. Malos hábitos: En su documentación oficial, en algunos puntos te motivan a realizar algunos malos hábitos que deberían evitarse al trabajar con cualquier tipo de Framework MVC. Por ejemplo, con el método "find" de los modelos. Realizas la llamada desde el controlador, construyendo allí mismo la consulta, pero con el formato de CakePHP, enviando arrays. En mi opinión, todas las consultas find deben hacerse en el propio modelo, creando métodos allí que son los que realmente deben llamarse desde el controlador. Solo me pareció ver una referencia a esta forma de trabajar en la documentación de CakePHP, en uno de los últimos puntos de "recomendaciones", aunque ahora mismo tengo dudas. Además, con este sistema es mucho más sencillo poder cachear las consultas y queda el código mucho más limpio y ordenado. Ejemplo de llamada desde el controlador:

   $specificallyThisOne = $this->Article->find(
       'first', 
       array(
           'conditions' => array('Article.id' => 1)
       )
   );
   

2. Exceso de consultas: En proyectos en los que el número de tablas es muy elevado y hay muchas relaciones, el ORM de CakePHP puede llegar a realizar excesivas consultas. En proyectos pequeños con pocas tablas esto no suele suceder o no suele ser tan importante, pero cuando hay más de 10 tablas esto puede ser un gran problema. La facilidad de CakePHP se compensa con su mal rendimiento en proyectos grandes. En CakePHP 2.0 dicen haber mejorado bastante el rendimiento, pero aún así el sistema de consultas es idéntico y sigue existiendo este mismo problema.
3. Tamaño de ficheros: Algunos de los ficheros del propio Framework son demasiado pesados. Esto, añadiendo que hay demasiados ficheros del framework a los que se accede prácticamente en cada petición (request), conlleva a un elevado número de accesos al disco que penalizan el rendimiento del servidor, haciendo que el tiempo de carga de la web se eleve considerablemente. La única solución para esto utilizar un servidor que compile los ficheros PHP para agilizar esta tarea (Por ejemplo: Apache + APC).

Consejo

Antes de utilizar un framework para realizar una aplicación importante, de gran envergadura, documentate bien sobre los pros y los contras que tendrá ese Framework y si cumplirá tus expectativas a medio y largo plazo (a corto casi siempre lo hacen). Puedes verte obligado a tener que reescribir todo tu código si tomas una mala decisión o te pasas los pasos principales de todo desarrollo.

I+D, Análisis, desarrollo, guía de uso. Esto nunca debería faltar.

Reflexión personal.

¿Programadores?: Esto ya es un problema más general de la informática en general, pero que lo aplicaré a CakePHP en este caso. En este mundillo, hay mucha gente que ha trabajado duro para realizar algunas aplicaciones, frameworks, o cms para facilitar las tareas a los que no son informáticos. El problema de esto es que muchos usuarios finales que no saben más que utilizar estas "facilidades" empiezan a creerse gurús. Cuidado con este tipo de gente, son muy peligrosos y están sueltos.

Terminator - Consola multiventana

Hoy os traigo información sobre una herramienta que para mi es indispensable: Terminator.

Para mi que trabajo con varias máquinas a la vez (hasta 4 simultaneas, de momento), a veces es necesario tener abiertas varias terminales. Con Terminator tengo la posibilidad de tener 4 terminales en una misma ventana, al estilo de Konsole de KDE, pero con la particularidad añadida de que Terminator te permite crear grupos de terminales, con lo cual lo que escribas en una ventana del grupo puedes enviarlo a todas al mismo tiempo. Útil si tienes que realizar una misma tarea en varias máquinas, ya que escribiendo solo una vez la realizas en todas las máquinas a la vez.

Personalmente, desde que uso Terminator, trabajo más cómodo, espero que a mis lectores también os ayude.

Para instalarlo solo debeis instalarlo desde aptitude, si usais una distribución basada en Debian (Debian, Ubuntu...):

$ aptitude install terminator

¡Hasta la próxima!

Conectar a Wifi desde el terminal

Buenas, después de un tiempo sin escribir (por falta de tiempo), traigo un nuevo artículo, corto pero útil.

Si instalamos un servidor Linux, por poner un ejemplo, es posible que necesitemos conectarnos a través de wifi a nuestra red local. Hoy os pondré los pasos necesarios para hacerlo. Según vaya configurando mi portátil del trabajo, iré escribiendo documentos sobre la instalación y configuraciones más habituales y/o útiles para tener un buen entorno de desarrollo configurado.

Vayamos al lío,

1º Empezaremos buscando la información de la red WiFi a la que queremos conectar. Haremos iwconfig si no sabemos el nombre de la interfaz lo miraremos con "iwconfig". Suponemos que es wlan0:

$ iwlist wlan0 scanning

2º Buscaremos la información ESSID de la red y la dirección MAC del router y los configuramos en nuestra interfaz:

$ iwconfig wlan0 essid $_ESSID 
$ iwconfig wlan0 ap 40:4A:03:XX:XX:XX

3º Se configura la clave de la WiFi (suponiendo que tienes una especificada). Si es una clave ASCII (normalmente lo es), deberás añadir "s:" delante de la clave:

$ iwconfig wlan0 key $_KEY
$ iwconfig wlan0 key s:$_KEY

4º Se obtiene una ip desde el router. Antes de esto, podemos comprobar si hemos introducido bien los datos con "iwconfig"

$ dhclient wlan0

Cambiar nombre del equipo desde terminal

En algunas ocasiones, es posible que necesitemos cambiar el nombre de nuestro equipo (más posiblemente, un servidor remoto que hayamos adquirido de algún proveedor).

Para realizar este cambio deberemos realizar los siguientes pasos:

1.- Editaremos el fichero /etc/hosts y cambiaremos el nombre antiguo por el nuevo.
2.- Cambiaremos el nombre del equipo en el fichero /etc/hostname
3.- Lanzaremos el script /etc/init.d/hostname.sh para que se apliquen los cambios sin reiniciar.

sh /etc/init.d/hostname.sh

También podemos cambiar el nombre del equipo temporalmente ejecutando la sentencia:

/bin/hostname nuevo-nombre

Conectar a servidor SSH sin contraseña

Para los que trabajamos continuamente con varios servidores SSH, puede llegar a ser algo extresante tener que escribir siempre la contraseña. Y si además tienes que memorizar varias contraseñas de diferentes servicios, servidores, etc, como es mi caso, puede darse el caso de que cueste recordarlas.

En cualquier caso, por un motivo u otro, puede que cualquier programador o administrador de sistemas prefiera poder conectarse a su servidor SSH sin necesidad de escribir continuamente la contraseña, pero, ¿como hacer esto sin vulnerar la seguridad del servidor?.

La respuesta está en las claves RSA y el fichero authorized_keys de SSH. La cuestión es crear una clave rsa, que almacenaremos en el servidor al que deseamos conectar. A continuación explico los pasos para realizar el procedimiento.

1. Creamos la clave RSA
Para empezar, debemos crear en nuestro cliente la una clave rsa para identificar la máquina. Abriremos una ventana de terminal y ejecutaremos la siguiente sentencia:

ssh-keygen -t rsa

Nos pedirá una contraseña común, que podremos utilizar en caso de querer utilizar esta misma para conectar a diferentes servidores (en caso de que lo subamos a varias máquinas). Es una medida de seguridad más, aunque yo siempre dejo este campo vacío.

Una vez ejecutada la esta sentencia, se creará automáticamente en la carpeta .ssh de nuestro usuario ($HOME/.ssh) un fichero id_rsa.pub que utilizaremos para conectar a nuestros servidores.

2. Enviar la clave al servidor/es
El siguiente paso es enviar la clave al servidor. Con un sencillo comando que nos pedirá la contraseña, ya conseguiremos hacerlo:

ssh-copy-id -i ~/.ssh/id_rsa.pub $USER@$HOST

Donde $USER es el usuario con el que conectamos al servidor y $HOST la dirección. Con esto ya estaremos listos para conectar al servidor sin necesidad de introducir la contraseña.


CONFIGURACIÓN ADICIONAL
Para los más maniáticos, o aquellos que quieran añadir un nivel más de seguridad al servidor, se puede añadir la opción de que no se pueda conectar al servidor SSH si el equipo no está en el archivo authorized_keys del servidor. Es decir, que solo aquellos que han realizado el paso anterior puedan conectarse.

Para ello se debe editar el fichero /etc/ssh/ssh_config del servidor y añadir las siguientes lineas de configuración:

PasswordAuthentication no
RSAAuthentication yes
PubkeyAuthentication yes

Reiniciamos el servidor:

sudo /etc/init.d/ssh restart

Y probamos de conectaros mirando los mensajes de conexión (para comprobar que funciona correctamente):

ssh -v $USER@$HOST

Para realizar esta configuración en varios servidores, basta repetir solo el paso 2 en cada uno de los servidores, ya que la clave RSA será única para el cliente.

Evitar desconexión SSH

A muchos de vosotros os pasará que debeis conectar a un servidor mediante SSH y realizar varias tareas, pero entre estas puede pasar un cierto tiempo. Por defecto, la conexión SSH se desconecta automáticamente cuando el servidor lleva un rato sin recibir ninguna orden, por lo que se debe volver a reconectar al servidor (e incluso en algunos casos, bloquea la terminal y hay que cerrarla y volver a abrirla).

Esta mañana he encontrado la solución en un blog venezonalo de Fedora.

La mejor manera de mantener la sesión abierta, es hacer que el servidor SSH envíe peticiones cada cierto tiempo para comprobar el estado de la conexión. Esto hace que al haber actividad, la conexión no se cierre. Para hacerlo deberemos aplicar la siguiente configuración:

Cliente
Abriremos el fichero /etc/ssh/ssh_config con nuestro editor favorito y añadiremos las siguientes 2 líneas:

ServerAliveInterval 30
AliveCountMax 4

Servidor
En nuestro servidor SSH abriremos el mismo fichero /etc/ssh/ssh_config para añadir estas otras 2 líneas:

ClientAliveInterval 30
ClientAliveCountMax 4

Esta configuración hace que cada una de las máquinas haga consultas a la otra cada 30 segundos y en caso de recibir 4 errores NOK (errores de respuesta), la conexión se cerrará. De lo contrario se mantendrá abierta.

Disfrutad de una conexión SSH sin cortes.