Varias versiones php en tu servidor

Esto de las versiones del php me ha traído de cabeza desde que decidieron que algunas versiones iban a ser incompatibles con otras… Tan traumático fue el cambio a php5 que la comunidad ha tardado muchos años en decidirse a utilizar otra versión, tanto que se han saltado un número y ahora vivimos con la versión 7.x. En este caso os dejo la receta para poder cambiar de una versión a otra de php en un servidor ubuntu y así poder probar si algo funciona con la versión más nueva o hay que seguir “pegado a la versión anterior”.

Yo me he creado dos archivos para hacerlo: 

switchTo5.6.sh

!/bin/bash
a2dismod php7.2
a2enmod php5.6
update-alternatives --set php /usr/bin/php5.6
update-alternatives --set phar /usr/bin/phar5.6
update-alternatives --set phar.phar /usr/bin/phar.phar5.6 
update-alternatives --set phpize /usr/bin/phpize5.6
update-alternatives --set php-config /usr/bin/php-config5.6
service apache2 restart

switchTo7.2.sh

#!/bin/bash
a2dismod php5.6
a2enmod php7.2
update-alternatives --set php /usr/bin/php7.2
update-alternatives --set phar /usr/bin/phar7.2
update-alternatives --set phar.phar /usr/bin/phar.phar7.2 
update-alternatives --set phpize /usr/bin/phpize7.2
update-alternatives --set php-config /usr/bin/php-config7.2
service apache2 restart

Recordad que para que todo funcione habéis tenido que incluir los repositorios que tengan las distintas versiones de php. En mi caso incluí este:

sudo add-apt-repository ppa:ondrej/php

Y que tenéis que instalar todas las dependencias del proyecto en cuestión. En mi caso fueron estas (es un proyecto LAMP):

sudo apt-get install -y apache2 libapache2-mpm-itksudo apt-get install php php-mysql php-curl php-gd php-intl php-pear php-imagick php-imap php-memcache php-pspell php-recode php-tidy php-xmlrpc php7.2-xml  php-mbstring libapache2-mod-php

No es la solución ideal pero permite cambiar a una versión más “segura” en cualquier momento y asegurar que los proyectos siguen funcionando al margen de la versión actual de php.

En cualquier caso, seguro que surgen más problemas con el versionado de las librerías, ahí ya no queda más que rezar y esperar que todo siga funcionando “más o menos” como antes.

Los errores SI se pagan

Tengo un jefe que dice que su empresa no paga errores y que las tareas dedicadas a depurar y corregir errores deben hacerse en el tiempo libre.

human-error-in-finance-640x324A mi, que no soy muy dado a cometer errores y que tampoco dispongo de mucho tiempo libre eso me parece simplemente una barbaridad, y no solo porque estemos hablando de ingeniería del software, sino porque estamos hablando, en general, de trabajo hecho por humanos. Es completamente imposible asegurar que el 100% de un trabajo realizado por un ser humano está exento de errores, enmiendas u omisiones. Decir que solo se paga por el trabajo “perfecto” es como decir que te están pagando solo una fracción del tiempo que dedicas. Y eso, simplemente, es explotación.

Según Frederik P. Brooks, Jr. El autor, entre otros, del conocidísimo libro “The mythical Man-month” y autoridad donde las haya en el campo de la ingeniería del sofware, el 50% del tiempo total de un proyecto software debe dedicarse a pruebas, depuración y corrección de errores. ¡Un 50%! más tiempo que el dedicado a programar o a cualquier actividad de gestión. ¿Eso significa que si se hubiese aplicado la política de “yo no pago errores” el software habría salido por la mitad de precio? No, significa que los errores en el software son inevitables y que el buen software no es el que se construye sin cometer errores sino el que se hace teniendo siempre presente que los errores están ahí y hay que corregirlos antes de sacar nada al mercado.

Escudarse en la excusa de que un programador experimentado es el que no comete errores, es una falacia completa. El programador experimentado es aquel que ya ha cometido más errores y, por tanto, tiende a no volver a cometerlos o, al menos, a reconocer los errores cuando los encuentra más rápidamente que otro programador que no ha tenido esa experiencia. Además, muchos “errores” no son más que malas interpretaciones de requisitos o malas integraciones de sistemas distintos que no se habrían podido evitar sin cambiar las políticas de comunicación de la empresa (¿alguien recuerda el pufo de las distintas unidades de medida en la Mars Climate?).

Por más controles que se pongan, por mejores herramientas que se utilicen, por más que estemos concentrados en lo que hacemos el 100%, es imposible evitar la introducción de errores en el código que se produce. Las tareas de pruebas y depuración son muy importantes y determinantes a la hora de medir la calidad del resultado final. Intentar no pagar por esas horas es como invitar a alguien a comer y decir que los entremeses y el postre lo tiene que pagar él. ¿Qué invitación es esa?

Espero que vosotros no os encontréis esta situación que, por otra parte, no debería darse entre gestores formados y experimentados en el campo de la ingeniería del software. Hora que trabajas, hora que se paga. Si eres malo en lo que haces te pagarán menos por cada hora y terminarás en la calle, pero si eres bueno, igualmente cometerás errores (y los corregirás) en horas pagadas acorde a tus habilidades. El resto son milongas.

Integrando Java y Windows

Recientemente hemos tenido que integrar un sistema diseñado exclusivamente para Windows y Visual Basic a una aplicación web desarrollada completamente en Java (con un framework nuestro)… Aunque la teoría del uso de JNI es bastante sencilla hay cosas que no se explican en ningún sitio y que nos hizo perder muchas horas… Os dejo aqui un resumen de cómo hacer las integraciones y cuales son los problemas más importantes que nos podemos encontrar…

El problema: una aplicación desarrollada por terceros en Visual Basic, en la forma de un par de dlls que se deben registrar y que son llamadas como objetos OLE desde las aplicaciones tenía que ser invocada remotamente por una aplicación web en java corriendo en una máquina Linux…
Sigue leyendo