Web de juegos

Si te aburres haz click aquí

Acabo de leer el último artículo de Joel Spolsky (debo confesar que soy un fiel seguidor de su web desde hace años).

Aunque no viene demasiado al caso, al final del artículo comenta los problemas de soporte que debe afrontar debido a que su software se ejecuta en distintas plataformas. Y claro, cada plataforma tiene sus programas, y a veces, surgen incompatibilidades entre estos y su software.

Según comenta, los servidores en Windows no suelen dar demasiados problemas, todo el mundo tiene configuraciones de equipos similares, los dolores de cabeza vienen por los sistemas *nix.

Esto me ha recordado lo extraordinariamente fácil que se instala Perforce en un ordenador Linux.

Realmente, la primera vez que lo instalé me quedé asustado. Bajar y ejecutar. Nada de dependencias de librerias. Nada de tengo Red Hat pero los paquetes son de Debian, ni viceversa, los paquetes son de Red Hat pero yo tengo Debian/Ubuntu. Nada de: ahora hay que bajarse el paquete tal, que a su vez depende del paquete cual.

La solución a este problema de incompatibilidades y problemas de instalación entre plataformas,es a la vez sencilla y genial. Lincado estático de código.

De cara al usuario es superfácil: solo debes bajarte el ejecutable correspondiente a la versión del kernel de linux que tengas instalada (la versión la puedes obtener con el comando: uname -a).

Perforce es un sistema de control de versiones extremadamente eficiente (recomiendo la lectura de los artículos de Eric Sink acerca del control de versiones). Pues bien, a parte de tratarse de una herramienta fundamental en el desarrollo de software, debo decir que es uno de esos programas sobresalientes. Su facilidad de instalación y su facilidad de uso desbancan a todas las demás soluciones con las que he trabajado (que recuerde ahora mismo: CVS, Subversion y MKS). Desde mi punto de vista, es la mejor solución que existe para el control de versiones, pero también la mas cara. El que quiera asustarse puede consultar su lista de precios.

Conclusión: Siempre existen soluciones sencillas incluso para los problemas más complejos ;)

7 Responses to “Producir software de calidad no es fácil”

  1. maeghith

    ¿El cliente de p4 de linux lincado estático?, creía que linux usaba el cliente java (por eso parece que no tenga dependencias).

    Hay proyectos en linux que utilizan lincado estático, como el klik (http://klik.atekon.de/).

    Y el problema que se le achaca al lincado estático es el de falta de seguridad por desactualización: si se actualiza una biblioteca de la que dependen 20 paquetes, hay que actualizar los 20 paquetes por separado y puede que alguno no se actualice por el motivo que sea, mientras que si se usa un sistema de dependencias, al actualizar el la bibioteca en el sistema, se actualizan automáticamente todos los paquetes.

    Ahora, esto lleva el problema de las dependencias rotas, cíclicas y demás historias harto conocidas, aunque últimamente está bastante pulido el tema (creo yo).

    Conclusión: cada decisión acarrea sus inconvenientes, y cuando no se pueden corregir, hay que saber aceptarlos y convivir con ellos :)

    December 8th, 2007 | 1:44 pm
  2. Acabo de verificar que tanto “p4”, “p4d” y “p4v” son binarios de linux (con formato ELF). P4V no es una aplicación java, aunque yo no descartaría que hubieran metido directamente una maquina virtual java en el EXE, y tuvieran varias llamadas a funciones nativas, y por eso al ejecutar “nm p4v” salen tantas funciones.

    Sobre lincado estático, la ventaja que tiene para la empresa es que nadie va a romper compatibilidad con el binario. Se van a ahorrar muchas llamadas a soporte técnico. Imagina que usan lincado dinámico, y el cliente depende del paquete X. Ahora supon que los desarrolladores del paquete X deciden hacer un pequeño cambio que soluciona algún tipo de bug, pero que produce incompatibilidades.

    Sobre las dependencias, ahora la verdad es que están bastante pulidas, aunque sigo echando en falta la funcionalidad de deshacer la última instalación (superutil cuando algo falla después de actualizar).

    En cualquier caso, aun con las dependencias funcionando bien, ellos no tienen que preocuparse de definirlas en el instalador.

    Conclusión: el único incoveniente que le veo a esta solución es el tamaño de los ejecutables: ~530KB (p4), ~1.6MB (p4d), ~14MB (p4v).

    December 9th, 2007 | 11:24 am
  3. maeghith

    Sobre lincado estático, la ventaja que tiene para la empresa es que nadie va a romper compatibilidad con el binario. Se van a ahorrar muchas llamadas a soporte técnico. Imagina que usan lincado dinámico, y el cliente depende del paquete X. Ahora supon que los desarrolladores del paquete X deciden hacer un pequeño cambio que soluciona algún tipo de bug, pero que produce incompatibilidades.

    Si aparece un bug entonces la empresa tendrá que elegir:
    – cubrirse el culo y corregir el bug, arriesgandose a perder compatibilidad, pero asegurandose que está actualizado: toca llamar a soporte en caso de que se pierda compatibilidad;
    – o seguir trabajando sin corrergir el bug (por que han visto en el changelog que no les afecta), arriesgandose a que el bug le impida trabajar en algún momento futuro o que suponga un riesgo de seguridad que no pueden solucionar por otros medios (firewall, etc..): toca llamar a soporte en caso de que se queden con el culo al aire o de que el bug no les deje trabajar.

    A soporte se acaba llamando, antes o después, es inevitable XD

    December 11th, 2007 | 3:34 pm
  4. También existe otra opción en ese caso. Lo que comunmente viene llamandose: Plan B.

    En el caso de que aparece un bug o una compatibilidad en uno de los componentes, la empresa se calla la boca y se soluciona en el siguiente release.

    Si el bug es del propio programa te da igual hayas hecho enlace estático o dinámico, y en el otro caso, efectivamente te expones, pero por otra parte terceras personas no tienen porque saber que componentes utilizas.

    December 12th, 2007 | 3:28 pm
  5. Jose

    Mi voto por Subversion.

    No tienes que gastar dinero y para trabajar con varios “trunks” va de perlas.

    Muchos problemas de multiplataforma tienes que tener para justificar el gasto en Perforce.

    December 13th, 2007 | 7:46 am
  6. Jose el nombrar Perforce como ejemplo, no es para decir que es un sistema de control de versiones cojonudo, que lo es, (subversion tampoco está mal, no quiero entrar en polémicas), a lo que me refiero en el artículo es que realizar código multiplataforma que sea fácilmente instalable por los usuarios(expertos o inexpertos) y que evite problemas de compatibilidad, no es algo que muchas empresas consigan.

    Dar soporte de un software para distintas versiones de distintos sistemas operativos es un quebradero de cabeza. Y Perforce tiene soporte para Linux 2.4.x y 2.6.x en arquitecturas x86, x64 y IA64; para MS Windows en x86,x64 e IA64 también; para MAC OS X en PPC, x86 y x64; Solaris, FreeBSD, AIX… y ya paro de enumerar.

    El punto clave de este comentario y de este artículo no es que sea multiplataforma como muchas otras aplicaciones GNU (como por ejemplo subversion), el punto clave es que es superfácil instalarlo, y a mi de momento siempre me ha funcionado a la primera, ya sea en Windows o en Linux. Y me juego el cuello a que en MAC también va perfectamente.

    December 14th, 2007 | 12:23 am
  7. maeghith

    En el caso de que aparece un bug o una compatibilidad en uno de los componentes, la empresa se calla la boca y se soluciona en el siguiente release.

    Eso es el mejor de los casos, que es cuando el bug lo descubre la propia empresa desarrolladora. ¿Y si lo descubre alguien de fuera?.

    Y por otro lado, con el sistema de dependencias, tampoco el usuario necesita saber cual de los paquetes depende de cual otro, para eso están los sistemas de paquetes con gestión de dependencias. Y si la cosa es ocultar las dependencias, pues en realidad te da igual:
    – los usuarios que no se preocupan, no se van a poner a investigar ahora,
    – y un usuario de “los que sí se preocupan” lo hará, uses el sistema que uses.

    December 16th, 2007 | 5:45 pm

Leave a Reply