Archivos "Pitufo" atacan mi SVN

Hace unos días quería subir un cambio al repositorio de código SVN, para añadir información extra de depuración a un Servlet para monitorear un extraño bug. Intentar enviar el cambio resultaba en un error en mi plugin de SVN (SubEclipse), que al principio confundí con un atributo "Lock" sobre el (archivo). Acepto que no leí en detalle el error y me deje ir por la primera impresión. Más después de unos momentos, comencé a notar varias irregularidades en los archivos "base"...

Dos ideas vienen a la mente cuando uno ve una imagen como la anterior:

1. El archivo en el servidor esta corrupto.
2. Mi copia local esta corrupta.

Respalde aceleradamente mis archivos con cambios a un lugar seguro, y procedo a hacer un "Override and Update". La irregularidad se mantiene.
Accedo al servidor SVN por su interfaz web, con la esperanza de encontrar el problema en el servidor... ¡¡¡pero no el fregado archivo esta bien!!!.

Bien, parece que el problema es local... así que me dispongo a ver las infames carpetas ".svn", y a medida que me adentro en la jerarquia de subcarpetas del proyecto, comienzo a verlo atestado de "pequeños pitufitos archivitos azules", y cuando ingreso a la carpeta "text-base" (en .svn de la carpeta que aloja mis archivos modificados) me encuentro nuevamente con los infelices:

Leyendo más a detalle el error del SubEclipse este describe un "mismatch" de
la firma de los archivos. Ah, ahora entiendo el problema.
Windows XP tiene una característica que consiste en comprimir los "archivos antiguos" (que no cambian en 60 dias) para ahorrar espacio

El explorador de archivos de Windows, "colorea" de azul los archivos que fueron comprimidos de esta forma. Ciertamente la caracteristica es util para ahorrar espacio, y transparente para muchisimos programas, pero no es bien recibido por los clientes de SVN.

Los clientes de SVN (SubEclipse, Tortoise, etc) mantienen un registro de firmas (hash) de los archivos base (los originales que se obtienen desde el servidor). Pero como Windows XP comprimió los archivos, la firma de archivos modificados cambió, y el SubEclipse protesto mucho por el "mismatch" de la firma de los archivos afectados, por esa simple razón no se podía enviar el cambio a fin de cuentas.

¿Qué hacer en este caso?
Lo primero que se nos viene a la mente es hacer un CheckOut del proyecto, y no es una mala idea, pero si tienes varios proyectos (ocho por ejemplo) afectados por los "archivos azules", antes de ponerte a insultar la cuenta de @BillGates usando Twitter, puedes usar el comando "compact" con los siguientes argumentos:

compact /u /s /a /q /i

Empleas el comando sobre la carpeta afectada (la opcion "/s" indica que se recorran los subdirectorios), de esta forma le indicas a compact que descomprima los "archivos azules" y los regrese a su estado normal.

Yo ejecute el comando sobre mi carpeta de proyectos, me funciono a la perfección, y como pueden ver, me salvó de perder mucho tiempo haciendo CheckOuts y configurando mil cosas extra...

Bien, ese fue un tip que salva de dolores de cabeza, espero que les sirva, cuidado con los pitufos de windows, ¡Saludos!

Nota: La solución se realizo en una maquina con Windows XP Pro + SP3, el autor NO da garantías de que esta funcione en otras versiones del SO utilizado.

Archivos "Pitufo" atacan mi SVN

Hace unos días quería subir un cambio al repositorio de código SVN, para añadir información extra de depuración a un Servlet para monitorear un extraño bug. Intentar enviar el cambio resultaba en un error en mi plugin de SVN (SubEclipse), que al principio confundí con un atributo "Lock" sobre el (archivo). Acepto que no leí en detalle el error y me deje ir por la primera impresión. Más después de unos momentos, comencé a notar varias irregularidades en los archivos "base"...

Dos ideas vienen a la mente cuando uno ve una imagen como la anterior:

1. El archivo en el servidor esta corrupto.
2. Mi copia local esta corrupta.

Respalde aceleradamente mis archivos con cambios a un lugar seguro, y procedo a hacer un "Override and Update". La irregularidad se mantiene.
Accedo al servidor SVN por su interfaz web, con la esperanza de encontrar el problema en el servidor... ¡¡¡pero no el fregado archivo esta bien!!!.

Bien, parece que el problema es local... así que me dispongo a ver las infames carpetas ".svn", y a medida que me adentro en la jerarquia de subcarpetas del proyecto, comienzo a verlo atestado de "pequeños pitufitos archivitos azules", y cuando ingreso a la carpeta "text-base" (en .svn de la carpeta que aloja mis archivos modificados) me encuentro nuevamente con los infelices:

Leyendo más a detalle el error del SubEclipse este describe un "mismatch" de
la firma de los archivos. Ah, ahora entiendo el problema.
Windows XP tiene una característica que consiste en comprimir los "archivos antiguos" (que no cambian en 60 dias) para ahorrar espacio

El explorador de archivos de Windows, "colorea" de azul los archivos que fueron comprimidos de esta forma. Ciertamente la caracteristica es util para ahorrar espacio, y transparente para muchisimos programas, pero no es bien recibido por los clientes de SVN.

Los clientes de SVN (SubEclipse, Tortoise, etc) mantienen un registro de firmas (hash) de los archivos base (los originales que se obtienen desde el servidor). Pero como Windows XP comprimió los archivos, la firma de archivos modificados cambió, y el SubEclipse protesto mucho por el "mismatch" de la firma de los archivos afectados, por esa simple razón no se podía enviar el cambio a fin de cuentas.

¿Qué hacer en este caso?
Lo primero que se nos viene a la mente es hacer un CheckOut del proyecto, y no es una mala idea, pero si tienes varios proyectos (ocho por ejemplo) afectados por los "archivos azules", antes de ponerte a insultar la cuenta de @BillGates usando Twitter, puedes usar el comando "compact" con los siguientes argumentos:

compact /u /s /a /q /i

Empleas el comando sobre la carpeta afectada (la opcion "/s" indica que se recorran los subdirectorios), de esta forma le indicas a compact que descomprima los "archivos azules" y los regrese a su estado normal.

Yo ejecute el comando sobre mi carpeta de proyectos, me funciono a la perfección, y como pueden ver, me salvó de perder mucho tiempo haciendo CheckOuts y configurando mil cosas extra...

Bien, ese fue un tip que salva de dolores de cabeza, espero que les sirva, cuidado con los pitufos de windows, ¡Saludos!

Nota: La solución se realizo en una maquina con Windows XP Pro + SP3, el autor NO da garantías de que esta funcione en otras versiones del SO utilizado.

Los 5 recursos que me salvaron la vida en 2009

El 2009, fue un año difícil, pero no solo lo fue a nivel de "crisis económica global", o enfermedades, etc, fue un reto a nivel personal, un año de crecimiento... egresar, trabajar, cumplir con requerimientos, hacer y defender la tesis. Si bien, el apoyo de la familia y la fe en Dios te saca adelante, tampoco podemos negar la ayuda de ciertas herramientas digitales, que te facilitan la vida, y este articulo es sobre algunas de ellas...

Google Code:
Desde que aprendimos a usar "Code Versioning" (allá por el final de 2007), simplemente ya no dejar de usarlo, y cuando descubrimos Google Code... fue la panacea de todos nuestros males. Al menos siete proyectos Universitarios están alojados en Google Code, incluyendo la tesis y el documento de la misma. Y para nuestras necesidades, la quota de espacio que Google Code da, es más que suficiente para alojar los proyectos del estudiante promedio.
Puedo decir, sin temor a equivocarme, que un buen porcentaje de estudiantes de sistemas tienen acceso a Internet en casa (y por ende computadora personal), así, que si eres estudiante, y te gusta trabajar desde tu casa y no quieres complicarte la vida pegando código de tus compañeros, comienza a usar una herramienta de control de versiones gratuita, y un sitio que te ofrezca alojamiento para tu código como SourceForge, GitHub y Google Code, a nosotros, el ultimo nos ayudo muchísimo en la tesis. Acá les dejo una "Guia Visual para Control de Versiones" para los que quiera una explicación visual del tema de control de versiones.

IceFaces:
IceFaces es el Framework que hizo que dejara de preocuparme por la compatibilidad entre navegadores y de escribir código JavaScript. Es un framework que "simplemente funciona", lo usamos también en la tesis, y después de un par de días de aprender a usarlo, la combinación de este (de IceFaces) con Oracle TopLink, Tomcat 6 y MySQL es una "gloria digital".
Con IceFaces aprendimos a preocuparnos por la lógica del negocio, y por hacer las cosas lo mejor posible, y no preocuparnos porque la GUI no se muestra bien en Internet Explorer 7+. Es un framework que recomiendo mucho, que mejora constantemente, y que ya esta en su versión 2.0, y posee soporte para las empresas. Si lo usan, se darán cuenta de que si diseñan bien la logica de su software, hacer proyectos con IceFaces es un paseo por el campo. Quizás el único inconveniente reciente, es que no hay plugin de IceFaces para Netbeans 6.8, solo para la versión 6.7.5.

jQuery:

Si bien no me gustaba JavaScript, cuando conocí JQuery la cosa cambio, y cuando comencé a usarlo todos los días en el trabajo, se volvió el mejor amigo para no caer en la locura y demencia de estar en un proyecto que: no usa persistencia (JPA), ni patrones de diseño, ni MVC, ni framework alguno... es bastante traumatico, pero bien, gracias a Dios tengo trabajo ¿no? :)
Al menos, yo prefiero jQuery por cinco excelentes razones: Selectores, Atributos, Ajax, Documentación, y jQuery UI. Si no están usando un framework de JavaScript, háganse un favor y aprendan uno de tantos, yo recomiendo jQuery, pero también les puede interesar MooTools y Dojo (entre otros tantos más).

Delicious Bookmarks:
Muchos de ustedes cuando navegan en el trabajo, les filtran el contenido porque a alguien se le ocurrió poner un proxy... si, y yo también me uno a su sufrimiento hermanos y hermanas. Asi que en el trabajo no tengo libre acceso a Internet. Sumemos a eso la necesidad de moverme constantemente entre Santa Ana y San Salvador... así que al momento de navegar y "sincronizar" algo tan simple como "mis favoritos", necesito una herramienta que utilice protocolo "https", se integre perfectamente con FireFox y ademas no tenga un "limite aparente" o de espacio. Esta milagrosa herramienta la utilizo desde hace al menos dos años, y con casi 3,000 favoritos, es el recurso que más me ha permitido mantener sincronizados los favoritos entre los equipos que utilizo :) Otras alternativas son Xmarks (antes conocido como FoxMarks) y ... bueno, solo ese vale la pena... creo yo. Pero aun asi, yo les recomiendo que descarguen y usen Delicious: complemento de Delicious para FireFox.

Twitter + Google Reader + Gmail + FaceBook:
Trabajar, viajar y llevar la tesis, no es tarea fácil, es una locura que no se la recomiendo a nadie. El principal problema con ese ajetreo... es la vida social, que caduca poco a poco hasta hace un par de meses. Reactivarla, sin salir del trabajo, solo fue posible gracias a Twitter (porque tambien soportar también el protocolo https) para medio "platicar", a Gmail para concretar salidas y mantener la comunicación tradicional y FaceBook para recordarme de cumpleaños, eventos y salidas.

"La productividad de estos servicios digitales, esta a la orden de: como y para que los usas, simplemente no hay que olvidar que son "la herramienta o el medio", no el propósito"

Ah si, y Google Reader... es solo para mantenerme informado de los temas que más me interesan.


Como pueden ver, no es nada fuera de este mundo, son cosas sencillas y accesibles que creo que cualquier diseñador web, programador, administrador de sistemas o usuario común pueden llegar a utilizar.

Espero que esta lista de recursos que para mi fue indispensable, les ayude tanto como a mi. ¡Feliz 2010!

Los 5 recursos que me salvaron la vida en 2009

El 2009, fue un año difícil, pero no solo lo fue a nivel de "crisis económica global", o enfermedades, etc, fue un reto a nivel personal, un año de crecimiento... egresar, trabajar, cumplir con requerimientos, hacer y defender la tesis. Si bien, el apoyo de la familia y la fe en Dios te saca adelante, tampoco podemos negar la ayuda de ciertas herramientas digitales, que te facilitan la vida, y este articulo es sobre algunas de ellas...

Google Code:
Desde que aprendimos a usar "Code Versioning" (allá por el final de 2007), simplemente ya no dejar de usarlo, y cuando descubrimos Google Code... fue la panacea de todos nuestros males. Al menos siete proyectos Universitarios están alojados en Google Code, incluyendo la tesis y el documento de la misma. Y para nuestras necesidades, la quota de espacio que Google Code da, es más que suficiente para alojar los proyectos del estudiante promedio.
Puedo decir, sin temor a equivocarme, que un buen porcentaje de estudiantes de sistemas tienen acceso a Internet en casa (y por ende computadora personal), así, que si eres estudiante, y te gusta trabajar desde tu casa y no quieres complicarte la vida pegando código de tus compañeros, comienza a usar una herramienta de control de versiones gratuita, y un sitio que te ofrezca alojamiento para tu código como SourceForge, GitHub y Google Code, a nosotros, el ultimo nos ayudo muchísimo en la tesis. Acá les dejo una "Guia Visual para Control de Versiones" para los que quiera una explicación visual del tema de control de versiones.

IceFaces:
IceFaces es el Framework que hizo que dejara de preocuparme por la compatibilidad entre navegadores y de escribir código JavaScript. Es un framework que "simplemente funciona", lo usamos también en la tesis, y después de un par de días de aprender a usarlo, la combinación de este (de IceFaces) con Oracle TopLink, Tomcat 6 y MySQL es una "gloria digital".
Con IceFaces aprendimos a preocuparnos por la lógica del negocio, y por hacer las cosas lo mejor posible, y no preocuparnos porque la GUI no se muestra bien en Internet Explorer 7+. Es un framework que recomiendo mucho, que mejora constantemente, y que ya esta en su versión 2.0, y posee soporte para las empresas. Si lo usan, se darán cuenta de que si diseñan bien la logica de su software, hacer proyectos con IceFaces es un paseo por el campo. Quizás el único inconveniente reciente, es que no hay plugin de IceFaces para Netbeans 6.8, solo para la versión 6.7.5.

jQuery:

Si bien no me gustaba JavaScript, cuando conocí JQuery la cosa cambio, y cuando comencé a usarlo todos los días en el trabajo, se volvió el mejor amigo para no caer en la locura y demencia de estar en un proyecto que: no usa persistencia (JPA), ni patrones de diseño, ni MVC, ni framework alguno... es bastante traumatico, pero bien, gracias a Dios tengo trabajo ¿no? :)
Al menos, yo prefiero jQuery por cinco excelentes razones: Selectores, Atributos, Ajax, Documentación, y jQuery UI. Si no están usando un framework de JavaScript, háganse un favor y aprendan uno de tantos, yo recomiendo jQuery, pero también les puede interesar MooTools y Dojo (entre otros tantos más).

Delicious Bookmarks:
Muchos de ustedes cuando navegan en el trabajo, les filtran el contenido porque a alguien se le ocurrió poner un proxy... si, y yo también me uno a su sufrimiento hermanos y hermanas. Asi que en el trabajo no tengo libre acceso a Internet. Sumemos a eso la necesidad de moverme constantemente entre Santa Ana y San Salvador... así que al momento de navegar y "sincronizar" algo tan simple como "mis favoritos", necesito una herramienta que utilice protocolo "https", se integre perfectamente con FireFox y ademas no tenga un "limite aparente" o de espacio. Esta milagrosa herramienta la utilizo desde hace al menos dos años, y con casi 3,000 favoritos, es el recurso que más me ha permitido mantener sincronizados los favoritos entre los equipos que utilizo :) Otras alternativas son Xmarks (antes conocido como FoxMarks) y ... bueno, solo ese vale la pena... creo yo. Pero aun asi, yo les recomiendo que descarguen y usen Delicious: complemento de Delicious para FireFox.

Twitter + Google Reader + Gmail + FaceBook:
Trabajar, viajar y llevar la tesis, no es tarea fácil, es una locura que no se la recomiendo a nadie. El principal problema con ese ajetreo... es la vida social, que caduca poco a poco hasta hace un par de meses. Reactivarla, sin salir del trabajo, solo fue posible gracias a Twitter (porque tambien soportar también el protocolo https) para medio "platicar", a Gmail para concretar salidas y mantener la comunicación tradicional y FaceBook para recordarme de cumpleaños, eventos y salidas.

"La productividad de estos servicios digitales, esta a la orden de: como y para que los usas, simplemente no hay que olvidar que son "la herramienta o el medio", no el propósito"

Ah si, y Google Reader... es solo para mantenerme informado de los temas que más me interesan.


Como pueden ver, no es nada fuera de este mundo, son cosas sencillas y accesibles que creo que cualquier diseñador web, programador, administrador de sistemas o usuario común pueden llegar a utilizar.

Espero que esta lista de recursos que para mi fue indispensable, les ayude tanto como a mi. ¡Feliz 2010!

Anécdotas de virtualización ...

La semana pasada, el servidor de Source Control (Subversion) en donde se encuentran alojados todos los proyectos informáticos de la empresa comienzo a presentar problemas SERIOS de rendimientos. Con problemas serios me refiero a tardar 2 o 3 minutos para realizar un commit de 13 Kbs...


Todo esto comenzó a suceder justo en el momento en el que tres de los proyectos principales se estaban convirtiendo a TAGS ("Estable") y se comenzó a realizar un control mas minucioso de los commits realizados (se realizo lock en el main branch de los mismos). Así que la cosa se puso bastante seria cuando de un momento a otro, el rendimiento de este servidor, que se ha mantenido estable y confiable disminuyo, y en un momento, hasta se pensó que había "tronado", justo como trono el servidor CVS que le antecedía.

Como nunca había visto el dichoso servidor, pues me decidí a buscar en donde se encontraba, así como buscar al responsable del mantenimiento del mismo, o al menos al que había configurado el SubVersion ahí, y realizar la típica sesión de preguntas de novato curioso (de buena intención, pero molestas), y de paso como ya había leido de un problema similar en el servidor SVN del código de KDE, que es al menos, unas 10 veces mayor que el de la empresa, sabia "mas o menos" que decir/mencionar/sugerir para la mejora del problema.
Resulta que el administrador mas inmediato de la maquina es un amigo (RobMV), así que le comente la situación, y mas o menos la conversación se dio similar a esto:

- Mira, el SVN esta lento, podes revisar que sucede?
- Ok veamos... hmmmm, la máquina esta lenta. (Despues de un rato) Ah! tiene menos memoria RAM asignada
- Asignada? - pregunte.
- Si, asignada, es una máquina virtual.
- Ah! Nice! (me brillan los ojos cuando dicen virtual).

Resulta que el servidor REAL (Sun Blade Server con 16 GB, y dos procesadores Intel Xeon de 3 GHz c/u) había pasado recientemente por una "reasignación de recursos" para TODAS (al menos 13) las máquinas virtuales que en el se ejecutan, para mejorar asi el rendimiento de otras máquinas virtuales...


El "Blade", posee 3 niveles de prioridades en las que resuelve o "cede" el uso del procesador para cada máquina virtual. El servidor SVN estaba en la prioridad más baja. Ademas, la memoria RAM del servidor SVN se redujo de 1 GB a 512 MB. Y para colmo el servidor SVN se ejecuta en nada mas y nada menos que Windows 2003 Server.... Ah!!!! con razón esta lento.

La solución inmediata, fue reasignar la prioridad al servidor, a un nivel de prioridad "alto" (nivel de producción), y santo remedio... No digo que no funciono, pero creo que si alguien tiene algun problema similar, existen más opciones para solventar el problema. Creo firmemente, que ese mismo servidor SVN puede ejecutarse perfectamente en esas condiciones, y con mejores resultados que como lo hacia antes.

Mi solución, radical y simple:

quitar Windows 2003 Server y usar un SO especifico para maquinas virtuales.

Si bien Windows 2003 Server, es bastante estable, cualquier experto puede concordar conmigo con que este no es un Sistema Operativo optimizado para ejecutarse como una máquina virtual, ¿entonces para que molestarse en tenerlo instalado en una, y gastar además en su licencia?

Para las máquinas virtuales, siempre hay que usar una regla de oro:

Usa un sistema operativo OPTIMIZADO para máquinas virtuales.

Un PERFECTO ejemplo de esto: Ubuntu Server Edition JeOS (que se pronuncia como jugo en Ingles: "Juice"). Beneficios inmediatos de usar JeOS son:

• Mejor rendimiento en el mismo "hardware" comparado a un sistema operativo completo no optimizado.
• Menos espacio en disco
• Menor cantidad de actualizaciones (mas consolidadas y de mas importancia), lo que reduce la cantidad de mantenimiento del mismo.

Sistemas operativos como Ubuntu Jeos están afinados, de manera que aprovechen el máximo rendimiento de productos como VMware y KVM, lo que se traduce en mas eficiencia para escenarios de virtualización mayores.

"JeOS = núcleo de SO {Kernel, Drives, Login} + Mínimo Mantenimiento + Mínimo "user space tools""

Si la idea es "sacarle" el jugo a los equipos actuales, y mejorar el rendimiento sin incurrir en gastos por la "crisis", entonces hay que hacer conciencia sobre soluciones que usen Software Libre, y ofrecerlo como una opción REALISTA a los problemas informáticos empresariales.

¿En tu trabajo, usan virtualización?

ubuntu jeos ubuntu jeos virtualizacion virtual vmware linux svn subversion

Anécdotas de virtualización ...

La semana pasada, el servidor de Source Control (Subversion) en donde se encuentran alojados todos los proyectos informáticos de la empresa comienzo a presentar problemas SERIOS de rendimientos. Con problemas serios me refiero a tardar 2 o 3 minutos para realizar un commit de 13 Kbs...


Todo esto comenzó a suceder justo en el momento en el que tres de los proyectos principales se estaban convirtiendo a TAGS ("Estable") y se comenzó a realizar un control mas minucioso de los commits realizados (se realizo lock en el main branch de los mismos). Así que la cosa se puso bastante seria cuando de un momento a otro, el rendimiento de este servidor, que se ha mantenido estable y confiable disminuyo, y en un momento, hasta se pensó que había "tronado", justo como trono el servidor CVS que le antecedía.

Como nunca había visto el dichoso servidor, pues me decidí a buscar en donde se encontraba, así como buscar al responsable del mantenimiento del mismo, o al menos al que había configurado el SubVersion ahí, y realizar la típica sesión de preguntas de novato curioso (de buena intención, pero molestas), y de paso como ya había leido de un problema similar en el servidor SVN del código de KDE, que es al menos, unas 10 veces mayor que el de la empresa, sabia "mas o menos" que decir/mencionar/sugerir para la mejora del problema.
Resulta que el administrador mas inmediato de la maquina es un amigo (RobMV), así que le comente la situación, y mas o menos la conversación se dio similar a esto:

- Mira, el SVN esta lento, podes revisar que sucede?
- Ok veamos... hmmmm, la máquina esta lenta. (Despues de un rato) Ah! tiene menos memoria RAM asignada
- Asignada? - pregunte.
- Si, asignada, es una máquina virtual.
- Ah! Nice! (me brillan los ojos cuando dicen virtual).

Resulta que el servidor REAL (Sun Blade Server con 16 GB, y dos procesadores Intel Xeon de 3 GHz c/u) había pasado recientemente por una "reasignación de recursos" para TODAS (al menos 13) las máquinas virtuales que en el se ejecutan, para mejorar asi el rendimiento de otras máquinas virtuales...


El "Blade", posee 3 niveles de prioridades en las que resuelve o "cede" el uso del procesador para cada máquina virtual. El servidor SVN estaba en la prioridad más baja. Ademas, la memoria RAM del servidor SVN se redujo de 1 GB a 512 MB. Y para colmo el servidor SVN se ejecuta en nada mas y nada menos que Windows 2003 Server.... Ah!!!! con razón esta lento.

La solución inmediata, fue reasignar la prioridad al servidor, a un nivel de prioridad "alto" (nivel de producción), y santo remedio... No digo que no funciono, pero creo que si alguien tiene algun problema similar, existen más opciones para solventar el problema. Creo firmemente, que ese mismo servidor SVN puede ejecutarse perfectamente en esas condiciones, y con mejores resultados que como lo hacia antes.

Mi solución, radical y simple:

quitar Windows 2003 Server y usar un SO especifico para maquinas virtuales.

Si bien Windows 2003 Server, es bastante estable, cualquier experto puede concordar conmigo con que este no es un Sistema Operativo optimizado para ejecutarse como una máquina virtual, ¿entonces para que molestarse en tenerlo instalado en una, y gastar además en su licencia?

Para las máquinas virtuales, siempre hay que usar una regla de oro:

Usa un sistema operativo OPTIMIZADO para máquinas virtuales.

Un PERFECTO ejemplo de esto: Ubuntu Server Edition JeOS (que se pronuncia como jugo en Ingles: "Juice"). Beneficios inmediatos de usar JeOS son:

• Mejor rendimiento en el mismo "hardware" comparado a un sistema operativo completo no optimizado.
• Menos espacio en disco
• Menor cantidad de actualizaciones (mas consolidadas y de mas importancia), lo que reduce la cantidad de mantenimiento del mismo.

Sistemas operativos como Ubuntu Jeos están afinados, de manera que aprovechen el máximo rendimiento de productos como VMware y KVM, lo que se traduce en mas eficiencia para escenarios de virtualización mayores.

"JeOS = núcleo de SO {Kernel, Drives, Login} + Mínimo Mantenimiento + Mínimo "user space tools""

Si la idea es "sacarle" el jugo a los equipos actuales, y mejorar el rendimiento sin incurrir en gastos por la "crisis", entonces hay que hacer conciencia sobre soluciones que usen Software Libre, y ofrecerlo como una opción REALISTA a los problemas informáticos empresariales.

¿En tu trabajo, usan virtualización?

ubuntu jeos ubuntu jeos virtualizacion virtual vmware linux svn subversion

¿Esta versionada tu Base de Datos?

Atencion: esta entrada es para programadores... y geeks en general.

Como mencionaba Robertux en una entrada anterior:

"""¿Les ha pasado alguna vez que cuando están programando se dan cuenta que las líneas de código que acaban de agregar arruinaron el sistema y desean volver a como lo tenían el día de ayer ya que en ese entonces todavía compilaba, pero ya no se acuerdan qué fue lo último que agregaron para así poder revertirlo?

¿Les ha ocurrido que cada cierto tiempo crean una copia de la carpeta del proyecto en el que trabajan para guardarla como backup y además de que cada copia les abarca más de 10 o 20 MB de espacio en disco, al final no saben si la última versión está en la carpeta "ProyectoUltimo", "ProyectoFinal" o "ProyectoBueno" y les toca comparar las fechas de cada una?

¿Será que cuando trabajan en grupos, cada quién con su copia del proyecto y modificando los archivos que a cada quién le corresponden, al final no saben ni por dónde empezar para unir todos los archivos correctos en un único proyecto para tener la versión final y funcional?

Todas estas situaciones pasan porque no se están utilizando herramientas para el trabajo en grupo y específicamente, para el control de versiones."""

Y lo mismo podríamos decir de las Bases de Datos. Así que, developers, con esta idea en mente les pregunto:

¿Esta tu base de datos bajo control de version (cvs ó svn)?

...la respuesta a esta pregunta debería de ser (en los casos que lo amerite) SI.
¿Por que? simplemente por que:

¡la base de datos es una de las partes más criticas de cualquier aplicación! (la base de datos es tan parte de la aplicación, como el código y los modelos dentro del software)

y en la etapa de desarrollo, con varias personas trabajando en un proyecto, es muy probable que se cometan errores como los que mencionábamos al principio... o peores.
¿Y como versiono una base de datos?, bien, aquí hay un pequeño ejemplo:

Escenario de trabajo:

Gestor de Base de Datos: MySQL.
Repositorio SVN: Google Code.
Herramientas a usar (multiplataforma): SVN y MySQL (dump).

Para versionar una base de datos en mysql, basta con versionar el dump de la base de datos. Y el proceso de versionado ("Commit" y "Update" de cambios) y restauración de la BD se realiza con dos sencillos script (estos scripts pueden estar en una carpeta que se llame SQL y ser parte del proyecto que contenga esos scripts), uno script sera para realizar el "Commit" y otro para el "Update".

La logica del script de "Commit" es la siguiente:
1. Despues de realizar cambios significativos en la base de datos...
2. Llama a "mysqldump", y realiza un respaldo de la base de datos (con su contenido) en un archivo sql, por ejemplo:

mysqldump --single-transaction -hlocalhost -uROOT -pTOOR BASEDEDATOS > basededatos.sql

3. Luego realiza un "Commit" del archivo, asi:

svn commit -m "Dump de base de datos versionado" basededatos.sql

La logica del script de "Update" es la siguiente:
1. Realiza un "Update" invocando a svn...

svn update

2. Restauramos el dump actualizado obtenido a mysql:

mysql.exe -uROOT -pTOOR BASEDEDATOS < basededatos.sql

No hay que preocuparse por la información de Login para el svn, ya que si la carpeta en la que se invoca el script de commit o update esta agregada al repositorio, svn crea una carpeta llamada ".svn" que contiene la información de login (y otras cosas).
Como les mencione, esa es la lógica, si yo hago un cambio a la base de datos, hago el commit, y si hay cambios (o antes de una sesión de trabajo) hago el update.

Si esta entrada te pareció útil, aquí hay algunas reglas para trabajar con bases de datos que deberías de leer.

Espero que esto les sirva para facilitar su trabajo de desarrollo de software, ¡Saludos!

svn source control version software desarrollo herramientas
mysql bases+de+datos

¿Esta versionada tu Base de Datos?

Atencion: esta entrada es para programadores... y geeks en general.

Como mencionaba Robertux en una entrada anterior:

"""¿Les ha pasado alguna vez que cuando están programando se dan cuenta que las líneas de código que acaban de agregar arruinaron el sistema y desean volver a como lo tenían el día de ayer ya que en ese entonces todavía compilaba, pero ya no se acuerdan qué fue lo último que agregaron para así poder revertirlo?

¿Les ha ocurrido que cada cierto tiempo crean una copia de la carpeta del proyecto en el que trabajan para guardarla como backup y además de que cada copia les abarca más de 10 o 20 MB de espacio en disco, al final no saben si la última versión está en la carpeta "ProyectoUltimo", "ProyectoFinal" o "ProyectoBueno" y les toca comparar las fechas de cada una?

¿Será que cuando trabajan en grupos, cada quién con su copia del proyecto y modificando los archivos que a cada quién le corresponden, al final no saben ni por dónde empezar para unir todos los archivos correctos en un único proyecto para tener la versión final y funcional?

Todas estas situaciones pasan porque no se están utilizando herramientas para el trabajo en grupo y específicamente, para el control de versiones."""

Y lo mismo podríamos decir de las Bases de Datos. Así que, developers, con esta idea en mente les pregunto:

¿Esta tu base de datos bajo control de version (cvs ó svn)?

...la respuesta a esta pregunta debería de ser (en los casos que lo amerite) SI.
¿Por que? simplemente por que:

¡la base de datos es una de las partes más criticas de cualquier aplicación! (la base de datos es tan parte de la aplicación, como el código y los modelos dentro del software)

y en la etapa de desarrollo, con varias personas trabajando en un proyecto, es muy probable que se cometan errores como los que mencionábamos al principio... o peores.
¿Y como versiono una base de datos?, bien, aquí hay un pequeño ejemplo:

Escenario de trabajo:

Gestor de Base de Datos: MySQL.
Repositorio SVN: Google Code.
Herramientas a usar (multiplataforma): SVN y MySQL (dump).

Para versionar una base de datos en mysql, basta con versionar el dump de la base de datos. Y el proceso de versionado ("Commit" y "Update" de cambios) y restauración de la BD se realiza con dos sencillos script (estos scripts pueden estar en una carpeta que se llame SQL y ser parte del proyecto que contenga esos scripts), uno script sera para realizar el "Commit" y otro para el "Update".

La logica del script de "Commit" es la siguiente:
1. Despues de realizar cambios significativos en la base de datos...
2. Llama a "mysqldump", y realiza un respaldo de la base de datos (con su contenido) en un archivo sql, por ejemplo:

mysqldump --single-transaction -hlocalhost -uROOT -pTOOR BASEDEDATOS > basededatos.sql

3. Luego realiza un "Commit" del archivo, asi:

svn commit -m "Dump de base de datos versionado" basededatos.sql

La logica del script de "Update" es la siguiente:
1. Realiza un "Update" invocando a svn...

svn update

2. Restauramos el dump actualizado obtenido a mysql:

mysql.exe -uROOT -pTOOR BASEDEDATOS < basededatos.sql

No hay que preocuparse por la información de Login para el svn, ya que si la carpeta en la que se invoca el script de commit o update esta agregada al repositorio, svn crea una carpeta llamada ".svn" que contiene la información de login (y otras cosas).
Como les mencione, esa es la lógica, si yo hago un cambio a la base de datos, hago el commit, y si hay cambios (o antes de una sesión de trabajo) hago el update.

Si esta entrada te pareció útil, aquí hay algunas reglas para trabajar con bases de datos que deberías de leer.

Espero que esto les sirva para facilitar su trabajo de desarrollo de software, ¡Saludos!

svn source control version software desarrollo herramientas
mysql bases+de+datos

Resumen de Cómo Trabajar con Subversion

"Logo Oficial de TortoiseSVN"

Como montar un servidor de Subversion requiere algo de información sobre servidores y requiere tener acceso a uno también, es mejor utilizar un hosting gratuito como Sourceforge o Google Code. Les recomiendo Google Code por su simplicidad y facilidad de uso. Luego de esto, descargan el cliente adecuado para su sistema operativo, cabe mencionar que Subversion ni sus clientes no están sujetos a un lenguaje de programación en específico. Mas aún, además de código fuente, es posible almacenar en el repositorio archivos de cualquier tipo, tomando en cuenta que los que mejor se administran son los archivos derivados del texto plano, como lo son los archivos de código fuente debido a su facilidad y universalidad de edición y manipulación.

1. Creen un proyecto en algún servidor como los mencionados anteriormente o monten el suyo propio.
2. Creen una carpeta o seleccionen la carpeta donde se encuentra su proyecto. Desde TortoiseSvn, clic derecho y seleccionar la opción Import. Con esto subirán al repositorio la primera revisión (versión) de su proyecto.
3. Creen una carpeta aparte donde descargar y almacenar la copia de trabajo. Con Tortoise, Clic derecho a la carpeta y seleccionar Checkout. Aunque esto es exactamente lo que tenían en la carpeta original del proyecto, esta nueva copia denominada copia de trabajo o working copy ya está controlada para poder guardar en el repositorio sus posibles versiones. Cada miembro del grupo realizará este paso para obtener su propia copia de trabajo y modificarla localmente poniéndose de acuerdo sobre qué archivos modificará cada uno.
4. Cuando cada miembro del grupo haya hecho modificaciones relevantes al proyecto, este puede guardar la nueva revisión dando clic derecho a la carpeta que almacena la copia de trabajo y seleccionando Commit. De esta manera se crea una nueva versión (revisión) del proyecto con los cambios que este realizó y siempre será posible volver a una revisión anterior por si fuera necesario. Es posible también solo hacer commit a un grupo seleccionado de archivos en lugar de todo el proyecto.
   
5. Hay que avisar a los demás miembros que se han realizado cambios de manera que ellos se actualicen a la nueva revisión, dando clic derecho sobre la carpeta (o algunos archivos seletos) y seleccionando la opción Update. Esto no significa que perderán los cambios que cada uno haya realizado en su copia local. Si los archivos modificados en la nueva versión no habían sido tocados en la copia local de cada uno, estos permanecerán intactos, de lo contrario se creará un conflicto y el cliente almacenará temporalmente una copia tanto de la versión actual en el repositorio como de su copia local para cada archivo en conflicto para que después se seleccionen los archivos (o parte de estos) que realmente formarán la última versión y de esta forma, resolver el conflicto.
6. Si se desea volver a una revisión anterior, clic derecho a la carpeta del proyecto y se selecciona Update to Revision donde se especifica a qué revisión se desea regresar. Cabe destacar que por cada revisión, el servidor le asigna un número correlativo y la fecha, además de un comentario o ChangeLog por parte del autor de los cambios, de manera que sea más facil a la hora de decidir a cuál revisión es necesario regresar.
7. Para volver a iniciar el proyecto desde una revisión anterior, es posible crear una rama partiendo desde una revisión específica, lo cual también ayuda a tener múltiples formas del proyecto sin perder las actualizaciones de las versiones de cada uno. Para ello, hay que hacer un checkout de una revisión en particular y con ella crear la rama dándole clic derecho a la carpeta y seleccionando la opción Branch/Tag.
   

Por supuesto, los grandes y excelsos usuarios de Linux, acostumbrados a lidiar con la consola y a leer los manuales de los comandos, no necesitan que se les dé una explicación paso a paso de lo que tienen que hacer así que lo único que les adelanto es:

1. apt-get install subversion subversion-tools
2. man subversion
3. man svn
   

Un usuario Linux sabrá como seguir desde acá.

herramienta programacion subversion svn

Resumen de Cómo Trabajar con Subversion

"Logo Oficial de TortoiseSVN"

Como montar un servidor de Subversion requiere algo de información sobre servidores y requiere tener acceso a uno también, es mejor utilizar un hosting gratuito como Sourceforge o Google Code. Les recomiendo Google Code por su simplicidad y facilidad de uso. Luego de esto, descargan el cliente adecuado para su sistema operativo, cabe mencionar que Subversion ni sus clientes no están sujetos a un lenguaje de programación en específico. Mas aún, además de código fuente, es posible almacenar en el repositorio archivos de cualquier tipo, tomando en cuenta que los que mejor se administran son los archivos derivados del texto plano, como lo son los archivos de código fuente debido a su facilidad y universalidad de edición y manipulación.

1. Creen un proyecto en algún servidor como los mencionados anteriormente o monten el suyo propio.
2. Creen una carpeta o seleccionen la carpeta donde se encuentra su proyecto. Desde TortoiseSvn, clic derecho y seleccionar la opción Import. Con esto subirán al repositorio la primera revisión (versión) de su proyecto.
3. Creen una carpeta aparte donde descargar y almacenar la copia de trabajo. Con Tortoise, Clic derecho a la carpeta y seleccionar Checkout. Aunque esto es exactamente lo que tenían en la carpeta original del proyecto, esta nueva copia denominada copia de trabajo o working copy ya está controlada para poder guardar en el repositorio sus posibles versiones. Cada miembro del grupo realizará este paso para obtener su propia copia de trabajo y modificarla localmente poniéndose de acuerdo sobre qué archivos modificará cada uno.
4. Cuando cada miembro del grupo haya hecho modificaciones relevantes al proyecto, este puede guardar la nueva revisión dando clic derecho a la carpeta que almacena la copia de trabajo y seleccionando Commit. De esta manera se crea una nueva versión (revisión) del proyecto con los cambios que este realizó y siempre será posible volver a una revisión anterior por si fuera necesario. Es posible también solo hacer commit a un grupo seleccionado de archivos en lugar de todo el proyecto.
   
5. Hay que avisar a los demás miembros que se han realizado cambios de manera que ellos se actualicen a la nueva revisión, dando clic derecho sobre la carpeta (o algunos archivos seletos) y seleccionando la opción Update. Esto no significa que perderán los cambios que cada uno haya realizado en su copia local. Si los archivos modificados en la nueva versión no habían sido tocados en la copia local de cada uno, estos permanecerán intactos, de lo contrario se creará un conflicto y el cliente almacenará temporalmente una copia tanto de la versión actual en el repositorio como de su copia local para cada archivo en conflicto para que después se seleccionen los archivos (o parte de estos) que realmente formarán la última versión y de esta forma, resolver el conflicto.
6. Si se desea volver a una revisión anterior, clic derecho a la carpeta del proyecto y se selecciona Update to Revision donde se especifica a qué revisión se desea regresar. Cabe destacar que por cada revisión, el servidor le asigna un número correlativo y la fecha, además de un comentario o ChangeLog por parte del autor de los cambios, de manera que sea más facil a la hora de decidir a cuál revisión es necesario regresar.
7. Para volver a iniciar el proyecto desde una revisión anterior, es posible crear una rama partiendo desde una revisión específica, lo cual también ayuda a tener múltiples formas del proyecto sin perder las actualizaciones de las versiones de cada uno. Para ello, hay que hacer un checkout de una revisión en particular y con ella crear la rama dándole clic derecho a la carpeta y seleccionando la opción Branch/Tag.
   

Por supuesto, los grandes y excelsos usuarios de Linux, acostumbrados a lidiar con la consola y a leer los manuales de los comandos, no necesitan que se les dé una explicación paso a paso de lo que tienen que hacer así que lo único que les adelanto es:

1. apt-get install subversion subversion-tools
2. man subversion
3. man svn
   

Un usuario Linux sabrá como seguir desde acá.

herramienta programacion subversion svn

Programemos Mejor: Subversion

"Logo Oficial de Subversion"

¿Les ha pasado alguna vez que cuando están programando se dan cuenta que las líneas de código que acaban de agregar arruinaron el sistema y desean volver a como lo tenían el día de ayer ya que en ese entonces todavía compilaba, pero ya no se acuerdan qué fue lo último que agregaron para así poder revertirlo?

¿Les ha ocurrido que cada cierto tiempo crean una copia de la carpeta del proyecto en el que trabajan para guardarla como backup y además de que cada copia les abarca más de 10 o 20 MB de espacio en disco, al final no saben si la última versión está en la carpeta "ProyectoUltimo", "ProyectoFinal" o "ProyectoBueno" y les toca comparar las fechas de cada una?

¿Será que cuando trabajan en grupos, cada quién con su copia del proyecto y modificando los archivos que a cada quién le corresponden, al final no saben ni por dónde empezar para unir todos los archivos correctos en un único proyecto para tener la versión final y funcional?

Todas estas situaciones pasan porque no se están utilizando herramientas para el trabajo en grupo y específicamente, para el control de versiones.

Los sistemas de control de versiones son muy populares, más que todo en el mundo del software libre, ya que bajo esta filosofía, los desarrolladores permiten a los demás tener acceso libre (no necesariamente gratuito) al código fuente además de los binarios o ejecutables. Por lo tanto, estos utilizan herramientas que les permiten controlar de una mejor manera el desarrollo y distribución del mismo y cómo este va cambiando a través del tiempo.

¿Qué son los Sistemas de Control de Versiones?

Un sistema de control de versiones se encarga de almacenar de la manera más apropiada los cambios que ocurren sobre un conjunto de archivos en intervalos determinados y centralizados en un repositorio. Como ejemplo de estos sistemas se encuentran CVS (Concurrent Version Control), Visual Source Safe y por supuesto, Subversion. De acá en adelante, todo el contenido se basará específicamente en Subversion.

¿Cómo Funcionan los Sistemas de Control de Versiones?

Se posee un repositorio de svn montado en un servidor local o remoto en el cual se almacenan todas las versiones, desde la inicial. Cada cliente desde su computadora descarga las revisiones que necesite del repositorio y empieza a trabajar en ellas. Cuando ha hecho los cambios, este actualiza el repositorio. Por supuesto, debido a la concurrencia es posible que las versiones de los archivos entren en conflicto si ambos clientes han hecho cambios sobre los mismos archivos. Por ejemplo si dos personas descargan uno o varios archivos y los modifican simultáneamente, el primero en actualizar no tendrá problemas pero el segundo, si ha modificado los mismos archivos, tendrá ciertas dificultades cuando desee actualizar ya que la versión original que el poseía en su computadora ya no coincide con la del servidor.

Esto se resuelve mediante el bloqueo de los archivos por parte de un cliente para que los demás no puedan modificarlo o bien, llegando a un acuerdo entre los que modificaron simultáneamente el archivo para determinar cuál merece ser la última versión. Para ello, Subversion provee herramientas que examinan el contenido de un archivo y lo comparan con otras versiones para remarcar las líneas agregadas, modificadas y/o eliminadas por parte de todos los que han modificado el archivo de manera que sea mas sencillo reconocer los cambios y decidir cuáles deben permanecer.

Tan simple como eso.

Cabe mencionar que Subversion no almacena copias enteras de cada versión almacenada sino que evalúa los cambios realizados entre una versión y otra y solo almacena estos para ahorrar espacio en el repositorio.

Existen diversos clientes de Subversion para poder descargar versiones de un repositorio y actualizarlas en base a nuestros cambios. Para Linux existe la aplicación de línea de comandos llamada Subversion y para Windows existe una denominada TortoiseSvn, ambas de licencia libre y proporcionadas por los mismos creadores del Subversion: Tigris.

Para más información sobre Subversion, pueden leer de forma gratuita el documento on-line Control de Versiones con Subversion. El cual también esta disponible a la venta en Amazon.

herramienta programacion subversion svn

Programemos Mejor: Subversion

"Logo Oficial de Subversion"

¿Les ha pasado alguna vez que cuando están programando se dan cuenta que las líneas de código que acaban de agregar arruinaron el sistema y desean volver a como lo tenían el día de ayer ya que en ese entonces todavía compilaba, pero ya no se acuerdan qué fue lo último que agregaron para así poder revertirlo?

¿Les ha ocurrido que cada cierto tiempo crean una copia de la carpeta del proyecto en el que trabajan para guardarla como backup y además de que cada copia les abarca más de 10 o 20 MB de espacio en disco, al final no saben si la última versión está en la carpeta "ProyectoUltimo", "ProyectoFinal" o "ProyectoBueno" y les toca comparar las fechas de cada una?

¿Será que cuando trabajan en grupos, cada quién con su copia del proyecto y modificando los archivos que a cada quién le corresponden, al final no saben ni por dónde empezar para unir todos los archivos correctos en un único proyecto para tener la versión final y funcional?

Todas estas situaciones pasan porque no se están utilizando herramientas para el trabajo en grupo y específicamente, para el control de versiones.

Los sistemas de control de versiones son muy populares, más que todo en el mundo del software libre, ya que bajo esta filosofía, los desarrolladores permiten a los demás tener acceso libre (no necesariamente gratuito) al código fuente además de los binarios o ejecutables. Por lo tanto, estos utilizan herramientas que les permiten controlar de una mejor manera el desarrollo y distribución del mismo y cómo este va cambiando a través del tiempo.

¿Qué son los Sistemas de Control de Versiones?

Un sistema de control de versiones se encarga de almacenar de la manera más apropiada los cambios que ocurren sobre un conjunto de archivos en intervalos determinados y centralizados en un repositorio. Como ejemplo de estos sistemas se encuentran CVS (Concurrent Version Control), Visual Source Safe y por supuesto, Subversion. De acá en adelante, todo el contenido se basará específicamente en Subversion.

¿Cómo Funcionan los Sistemas de Control de Versiones?

Se posee un repositorio de svn montado en un servidor local o remoto en el cual se almacenan todas las versiones, desde la inicial. Cada cliente desde su computadora descarga las revisiones que necesite del repositorio y empieza a trabajar en ellas. Cuando ha hecho los cambios, este actualiza el repositorio. Por supuesto, debido a la concurrencia es posible que las versiones de los archivos entren en conflicto si ambos clientes han hecho cambios sobre los mismos archivos. Por ejemplo si dos personas descargan uno o varios archivos y los modifican simultáneamente, el primero en actualizar no tendrá problemas pero el segundo, si ha modificado los mismos archivos, tendrá ciertas dificultades cuando desee actualizar ya que la versión original que el poseía en su computadora ya no coincide con la del servidor.

Esto se resuelve mediante el bloqueo de los archivos por parte de un cliente para que los demás no puedan modificarlo o bien, llegando a un acuerdo entre los que modificaron simultáneamente el archivo para determinar cuál merece ser la última versión. Para ello, Subversion provee herramientas que examinan el contenido de un archivo y lo comparan con otras versiones para remarcar las líneas agregadas, modificadas y/o eliminadas por parte de todos los que han modificado el archivo de manera que sea mas sencillo reconocer los cambios y decidir cuáles deben permanecer.

Tan simple como eso.

Cabe mencionar que Subversion no almacena copias enteras de cada versión almacenada sino que evalúa los cambios realizados entre una versión y otra y solo almacena estos para ahorrar espacio en el repositorio.

Existen diversos clientes de Subversion para poder descargar versiones de un repositorio y actualizarlas en base a nuestros cambios. Para Linux existe la aplicación de línea de comandos llamada Subversion y para Windows existe una denominada TortoiseSvn, ambas de licencia libre y proporcionadas por los mismos creadores del Subversion: Tigris.

Para más información sobre Subversion, pueden leer de forma gratuita el documento on-line Control de Versiones con Subversion. El cual también esta disponible a la venta en Amazon.

herramienta programacion subversion svn