El dia de ayer se hizo una junta en el corporativo, que tratò sobre todo de que esta funcionando bien el proyecto que empezó en julio, y que quieren un nuevo sistema. Hay trabajo para rato, y avisè que me tardarè un mes mas o menos en diseñar especificaciones funcionales, ya que será para control de RH.

Sin embargo, llama la atención como dicen tan sencillo, crear un sistema de RH, falta definir a que llaman módulo de RH, porque aunque piensan en la impresión de recibos de nómina, no es claro si consideran módulos de capacitación, reclutamiento, evaluación, etc…

El dia de mañana se realiza la primera implementación de este sistema para clientes In House. El problema al momento, son los requisitos cambiantes y lista de prioridades cambiantes. Por lo visto sera una semana de locos.

Un dato interesante es que el único bug que encontramos fue el viernes pasado que G-P encontro que una rutina de envio de correo que habia hecho SAEM no estaba enviando nada. Estoy casi seguro que le problema fue o la clase que le pasó Alejandro, o la implementación de la misma por SAEM. Mas adelante vimos que parte del problema era un envío usando un from igual al to, o sea, spam seguro. Ya se corrigió y si no queda espero que usen la rutina que les prepare sin usar esa clase intermedia.

Debido a tener lejos mi USB con código de proyectos anteriores, tuve que hacer sobre la marcha una funcion simple que creara el respaldo, y después lo enviara por correo desde el servidor, como un adjunto mostrando texto HTML.

Incluyendo contraseñas, son menos de 60 lineas de código…. que son ejemplo de como mandar un HTML en php desde mail, incluyendo adjunto base64.

La semana pasada uno de mis programadores perdió como cuatro horas de código por un archivo php que se daño en pspad. El problema parece ser que nuestra conexión a internet, inalámbrica, esta sufriendo de los problemas típicos de infinitums inalámbricos, y mas ahora que se esta preparando Telmex a doblar el ancho de banda global.

Cuando sucedió eso yo tenía en los pendientes instalar subversion, justamante porque ese programador ya tiene conocimiento de turtoise. Sin embargo, lo pospuse. Hoy me tomé el tiempo para actualizar la tarea de revisar el estado de repositorios públicos, y me di cuenta de un problema fuerte con el «open source» en cuanto a control de proyectos. Basicamente que la opción de perdurabilidad del repositorio no es opcional.

En pocas palabras, no tiene sentido que para un código de «experimento» se tenga que dejar para siempre jamás. Vamos a poner un ejemplo :

Alguien se equivoca y sube por error un archivo .php con contraseñas :

< ?php define (Z_SERVER,'localhost'); define (Z_DATABASE,'bdproyectox'); define (Z_USER,'usuariox'); define (Z_PWD,'passwordx'); ? >

Este archivo no podria borrarse facilmente de repositorios publicos.

Afortunadamente quedan cuatro opciones extras:
1 ) Instalar el sistema de server bajo windows en windows ( lo cual depende que la pc este encendida y presente todo el tiempo )
2 ) Instalar un SVN bajo shared. El costo es de unos 9USD mensuales y no es facil encontrar uno fiable.
3 ) Instalar los datos bajo yum en un server propio (lo cual ya hice)

Pero la 4 me parece mejor.

Crear un control de versiones desde cero.

Si el objetivo es via web, para controles via web, basicamente necesitamos un control de hash, de md5, de recursividad, y una estructura de permisos.

Me tomé la libertad de que donde estoy, puse como requisito que el software de la empresa/grupo de empresas es código cerrado no distribuible, pero que el código de utilerías de desarrollo siempre puede hacerse OPCIONALMENTE bajo GPL.

Entre que son peras o son manzanas, sería conveniente soltar ese proyecto bajo algun repositorio publico, precisamente como prueba y capacitación para los otros dos programadores que no han usado Turtoise.

Lo empezaré a hacer el viernes.