Cursos de Delphi y Silverlight para Junio 2011

En Metacode acabamos de programar un par de cursos que estamos seguros que es lo estas buscando para actualizarte o aprender herramientas y recursos nuevos. Puedes verlo en el sitio de Metacode en Proximos cursos.

Por el lado de Delphi, creamos un curso de actalización a Delphi XE que incluye además técnicas de colaboración para equipos de desarrollo. estas tecnicas las hemos ido puliendo por años, y ahora creamos una capacitación que incluye conceptos como Control de Versiones efectivo, control del proyecto y colaboración. Y esto,  apoyados con herramientas de software libre por supuesto.

En el lado de aplicaciones web, cada día nos convencemos mas que Microsoft Silverlight es la solución para muchos escenarios, especialmente para las aplicaciones impresionantes de negocios que esperan nuestros clientes y empresas. Por lo tanto, planeamos un curso en el que el objetivo es que cualquier desarrollador que sepa .Net (si no es asi, sigue leyendo) salga del curso con conocimientos para hacer aplicaciones ricas de Internet con Silverlight 4.

Si quieres aprender .Net por cierto, tenemos un curso totalmente practico de una semana de duración, llamado Fastrack de C# 4.0 que incluye todo lo necesario. La información se puede descargar de aquí:
http://metacode.mx/MC_Silverlight4.pdf

Los cursos son para junio del 2011 en Guadalajara, México. En la pagina de Metacode se encuentra el vinculo para solicitar información de temarios, costos y como apartar lugares.

Si buscan cursos en linea o capacitación en tu sitio, también los tenemos cocinados! haznoslo saber en la misma forma de solicitud de información.

Saludos a todos.

La evolución del control de versiones, tercera parte: Mercurial

Estoy escribiendo una serie de artículos para mostrar los nuevos Sistemas de Control de Versiones (SCV). Esta es el tercero en la serie y los demás están aquí:

• Parte 1: Introducción
• Parte 2: Distribuido vs. Centralizado

Comenzando con Mercurial

Mercurial esta hecho totalmente en Python. Se puede bajar de http://mercurial.selenic.com/

Si se usa Windows, lo mejor es bajar TortoiseHG, que hace las veces de cliente y servidor de Mercurial. Es una extensión del shell de Windows (como TortoiseSVN) que pone todo el control de versiones en el menú de clic-derecho del explorador de archivos.

Por supuesto, existen plugins para los ambientes principales de desarrollo con la excepción de Delphi desgraciadamente (habrá que escribir uno ;-)

Para Visual Studio, pueden usar VisualHG, que de todos modos requiere y depende de que tengan instalado TortoiseHG. Para Eclipse la opción se llama extrañamente Mercurial Eclipse.

Mi repositorio

Con Mercurial lo mas importante es que tenemos un repositorio en la misma carpeta que tenemos nuestra copia de trabajo. Dentro de nuestra carpeta de proyecto tendremos una carpeta llamada .hg en donde esta todo el soporte de control de versiones, y nuestro propio repositorio.

Guía rápida a mercurial

Esta es una guía de conceptos/comandos para el uso de Mercurial:

Concepto	Descripción
Init	Crea un repositorio nuevo, con su respectiva copia de trabajo. Ejecutamos Init sobre la carpeta en donde tenemos nuestro proyecto y se genera una carpeta .hg donde esta nuestro repositorio, y la carpeta se convierte en una copia de trabajo.
Add	Marca los archivos de la copia de trabajo que no están versionados como listos para ser controlados. Se “copiaran” al repositorio en el siguiente commit.
Commit	Toma todos los cambios en la copia de trabajo y los copia al repositorio. Los cambios pueden ser: nuevos archivos, modificaciones en los archivos, borrado de archivos, nuevas configuraciones del repositorio (archivos ignorados, conexión a dependencias, etc.) Un conjunto de cambios se le llama changeset, y debe de ir acompañado de un mensaje, que en un mundo bueno debemos usar para describir que incluyen nuestros cambios.
Revert	Regresar los archivos al estado en que estaban cuando hicimos el ultimo commit, como quien dice, tirando a la basura nuestros últimos cambios. Esto sirve cuando la regamos y no hay forma mas sencilla de arreglarlo.
Log	Obtenemos una bitácora de changesets que incluye: fecha del commit, usuario que lo realizo, mensaje descriptivo que incluimos en el commit, listado de archivos modificados, añadidos, borrados, etc.
Push	Subimos nuestros cambios a un repositorio ligado al nuestro, por ejemplo, un repositorio común. Lo que se sube al repositorio son los changeset que dicho repositorio no tenga, en el orden cronologico. Esto no sube cambios de nuestra copia de trabajo, para eso es el commit.
Pull	Bajamos de un repositorio ligado hacia nuestro repositorio, los changesets hechos por otros desarrolladores o subidos desde otros repositorios. Pull solo actualiza nuestro repositorio local, no nuestra copia de trabajo. Para eso, usamos update.
Update	Actualiza nuestra copia de trabajo, aplicando changesets que tenemos en nuestro repositorio local. Podemos ”actualizar” los archivos de nuestra copia a cualquier changeset que queramos.
Status	Lista los cambios en nuestra copia de trabajo.
Clone	Crea un repositorio clon, o ligado, a partir de otro repositorio Mercurial.
Heads	Una “punta” es el ultimo changeset en un repositorio. Podemos tener mas una punta ¿Como!? Fácil. -> Juanito y Maruja actualizan su código hasta el changeset 5 -> Luego cada uno hace diferentes cambios y hacen un commit. Los dos tendrán un changeset 6 en su repositorio local. -> Después Juanito sube su changeset al repositorio central. -> En seguida, Maruja baja los últimos cambios antes de subir los suyos y se da cuenta que Juanito ya subió otros. -> Cuando maruja haga commit, su repositorio local tiene dos “puntas” o heads: el changeset 6 de Juanito, mas el changeset 7, con sus cambios. Para poder subir sus cambios, Maruja tendría que hacer algo, por ejemplo Mezclar (Merge) las dos puntas.
Merge	Mezcla los cambios de dos “puntas” del repositorio. Lo que hace Mercurial, usa algoritmos para identificar que líneas se modificaron en uno y en otro, mezclando efectivamente un archivo con todos los cambios. En caso de un conflicto en donde se hayan editado la misma sección o líneas de un archivo por parte de ambos changesets, se podría abrir una utilería de sincronización que nos ayudara a editar el archivo resultante de forma interactiva, comparando todos los cambios.

Espero esta guía sea de utilidad para comenzar con Mercurial.

A la Apple

Mercurial y Git son dos sistemas de control de versiones distribuidos(SCVD) y entres si son prácticamente hermanos gemelos.

Ambos proyectos open source y gratuitos nacieron de hecho casi al mismo tiempo y por las mismas causas. Pero como todos los gemelos, se parecen tanto que sus diferencias se ven mucho mas grandes cada vez.

Digámoslo así: Si comparamos los SCV con sistemas operativos, Subversion es Windows 98, Mercurial es Mac OS X y Git es Linux (la distribución que se les antoje).

Depende de lo que se trate, uno u otro tiene ventajas sutiles sobre el otro.

Hay diversos detalles adicionales que tomar en cuenta, por ejemplo, configurar nuestros proyectos para ignorar ciertos archivos inútiles o temporales, que de otra manera, estarían haciendo conflictos innecesarios.

Cuando me sea posible, expondré algunos detalles adicionales, además de mostrar las diferencias de uso con Git.

Por cierto! aprovecho este post para promocionar los nuevos cursos de Silverlight y Delphi que tenemos programados en Metacode para Enero y Febrero 2011. Si no tenemos programados algunos, pidan información con toda confianza ;-)

La evolución del control de versiones, segunda parte: Distribuido vs. Centralizado.

(ver Parte 1)
Estoy escribiendo una serie de artículos sobre los nuevos Sistemas de Control de Versiones (SCV), que buscan (y tiene éxito en) ser mejores soluciones que lo que Subversion hace ya de por si muy bien.

Distribuido contra Centralizado

Esta es la principal diferencia entre la anterior generación y la nueva generación de SCVs.

En un SCV centralizado (como Subversion, Perforce, etc.), un proyecto vive en un repositorio y cada desarrollador obtiene una copia de trabajo del repositorio. Sobre sus copias de trabajo el desarrollador hará cambios, los subirá de vuelta al repositorio central y actualizara constantemente.

En un SCV distribuido (como Mercurial, Git, Bazaar, etc.), cada desarrollador tiene un repositorio y obtiene su copia de trabajo de ahí. Puede estar interactuando cuanto quiera con su repositorio, subiendo cambios. Cuando quiera puede empujar los cambios en su repositorio hacia otro repositorio, que puede o no ser un repositorio central, el repositorio del proyecto de otro desarrollador, etc.

Ventajas del sistema distribuido

Puede parecer mas complejo pero en realidad es una gran idea el distribuir así el proyecto. Las razones son técnicas y sociales.

Técnicamente, es mas fácil llevar el trabajo y mantenerlo actualizado en mi propio repositorio y cuando sea necesario lo empujo hacia el repositorio compartido. También es posible mezclar mis cambios con los de un colega primero, verificar que funciona todo y después empujarlos todos hacia un repositorio compartido.

Socialmente, los desarrolladores tendrán mas confianza en estar subiendo de forma continua sus cambios a su repositorio personal sabiendo que, si su código tiene problemas aun, no se los pasaran a nadie mas.

Técnicamente además, al subir a nuestro propio repositorio continuamente nuestros cambios, cuando es hora de mezclar nuestro código con otros desarrolladores todo funciona como esperamos: un sistema distribuido tiene mas información y es mas eficiente al saber como mezclar el código, que cambio quien y a que hora. Mucho mas eficiente que Subversion por lo menos.

En el siguiente articulo comenzare a hablar de cada uno de los sistemas, empezando con Mercurial.

La evolución del control de versiones, primera parte.

Repito una vez mas, sin cansarme: quien no usa control de versiones es como quien no usa cinturón de seguridad, no compra seguro del auto, no trae llanta de refacción y habla por el celular mientras conduce: podrá llegar muchas veces a su destino pero no significa que no esta arriesgando mucho en el camino, aun cuando vaya solo.


Y eso que los sistemas de control de versiones existen desde hace tanto y han evolucionado increíblemente.

En el principio existió CVS: no manejaba muy bien los archivos binarios, pero la idea de que pueda bajar mi código como lo tenia ayer o hace un año, comparar las diferencias y además de tenerlo respaldado todo el tiempo, todo con unos sencillos comandos es innegablemente excelente.

Subversion fue el sistema que sustituyo a CVS, y que hace ver a su ancestro como juguete de bebés. Resuelve el problema de los binarios y hace que colaborar sea muy sencillo, y aun mas con un cliente como TortoiseSVN. Integra la idea de crear ramas de desarrollo que luego se pueden “remezclar” en el código principal, o marcar revisiones, corregir bugs sobre versiones viejas y luego integrar esa corrección en el desarrollo principal, etc.

Como todo, Subversion ahora no es suficiente. Hay nuevas necesidades en el desarrollo cada vez mas distribuido y hay pequeños y grandes detalles de Subversion que podrían ser mejores a la hora de colaborar.

Aquí es donde entran los nuevos reyes del control de versiones: Mercurial, Git y Bazaar.

Norberto Martínez y su servidor tenemos nuestras apuestas con Git y Mercurial, y hemos estado comparándolos, especialmente Norberto se dio a la tarea de investigar lo que ambos tienen que ofrecer en el web. Voy a escribir sobre ellos en los siguientes posts para que cada quien tome el camino que mas le lata.

Webinar de Delphi XE

El Jueves 24 de Septiembre a las 11 a.m. (hora de México) habrá un seminario web de presentación de Delphi XE y las nuevas funcionalidades a detalle.

Las nuevas tecnologías, funciones y productos de terceros que integra en el ambiente esta versión, no son lo que esperábamos y que nos habian anunciado (64 bits, compilar para Mac en nativo, bla, bla), pero desde mi punto de vista, son lo que Delphi necesita de verdad para los retos de ahora, que de hecho ya le dolían a Delphi.

Por ejemplo, muchos de los proyectos de hoy se hacen entre dos o mas programadores (eso es mucho mas común que hace apenas cinco años). Si XE integra control de versiones en el mismo IDE, con comparacion de versiones de los fuentes, ademas de un administrador de configuraciones de compilación e implementacion (deploy) automatizado con la posibilidad de obtener estadisticas de analisis del proyecto en una pagina web (estado de compilacion, metricas, auditorias, etc.) con un click, significa que un equipo de desarrollo puede instalar Delphi y comenzar a colaborar inmediatamente. ¡Lo que hubiera dado por tener todo esto integrado con Delphi hace un par de años! En fin. Ahora Delphi XE esta de verdad listo para competir en esa liga, sin comprar otros productos y mas fácil.

Si pueden dense una vuelta por el webinar y chequenlo.

Realmente me sorprende aun hoy, que alguien pregunte enfrente de mas de cuarenta desarrolladores de Delphi "¿Quien de aqui usa control de versiones?" y solo 4 levanten la mano. ¡Subversion es gratis por favor!

Animo.

Luchando contra 500 años de Cultura del comerciante

Generalmente en México (me parece que en gran parte de América Latina) los dueños, jefes o "patrones" de empresas (incluso de empresas de tecnología) de la anterior generación tienen una cultura de negocios MUY ARRAIGADA en la que muestran una grave falta de interés por la inversión: les gustan los negocios fáciles, el dinero rápido, la fuerza del impulso antes de la inteligencia de la organización. Sus ideas nacen de la prioridad de ahorrar todos los centavos que puedan, para terminar gastando muchos pesos en la consecuencia de ese ahorro. ¿A quién le suena familiar?

En lo personal, he estado encontrando una infinidad de trabas en investigacion e innovacion en una empresa para la que trabajo como consultor y desarrollador, dicha empresa tiene un potencial enorme, pero simplemente parece no interesar a su dirección, tal vez por pensar que mientras mas grande menos podrá controlar. Y es que al parecer, eso es otro rasgo de la mencionada cultura: el control obsesivo e invasivo.

Y es que, si buscas gente inteligente para que trabaje contigo y para ti, esperas que usen esa inteligencia en resolver sus tareas de la mejor manera (en su justa medida y en su justo ámbito de responsabilidad) conscientes de los objetivos en común, o no? La dirección sirve de eso mismo: dirección de los esfuerzos. No contratas a gente con cerebro (la mayoría de los que trabajan para dicha empresa) para que sea solo una extremidad del cerebro de la dirección, o eso supongo yo.

Es probablemente un reflejo de algún complejo de superioridad/inferioridad del jefe, pensando que él y solo él debe saberlo todo, y que todos deben hacer todo exactamente como él lo haría, sino de seguro no está bien hecho. Pero al mismo tiempo, la misma dirección no les proporciona la información necesaria para que tomen las decisiones correctas, porque la desconfianza no se los permite, ni siquiera cuando están seguros que es GENTE PROFESIONAL y comprometida con los objetivos de la empresa.

En fin, hay tanto que hacer en nuestro país, tanto potencial de crecimiento, y tanta gente que entendemos ese potencial, que tenemos más conciencia de lo que es ser profesional y buscamos serlo día tras día y cada vez mejor, que lo tenemos tatuado en los huesos, junto con la pasión que sentimos por aquello que hacemos. Es una lástima que a pesar de que tratemos de cambiar las cosas visiblemente para crecer, hay quien busca administrar una empresa de desarrollo de software igual que administraria un abarrote pequeño, en el que puede ver, oír y controlar hasta su ultima decisión, y al mismo tiempo explotarlo como si fuera la gallina de los huevos de oro.

Pero eso no debe detener el crecimiento de nuestros países y la explosión de nuevas y mejores oportunidades de desempeño profesional.

Solo como muestra de lo que van a ser las cosas: Hay muchas empresas de tecnología que están cambiando, innovando, aprovechando (si bien de manera aun escueta) su potencial. Por ejemplo Sistemas GH, una empresa de desarrollo basada en Morelia, Michoacán, que con inteligencia privilegia la inteligencia y autonomía de la gente sobre la ambición desmedida, su mentor (y fundador del grupo Programadores Delphi México) Al Gonzalez, sabe que un desarrollador profesional es alguien que sabe lo que hace y que vale la confianza que se deposite en el (o ella). Digo, al fin y al cabo es un negocio: el principal objetivo son las ganancias, pero es una forma más inteligente, más consciente, responsable, duradera y sostenible de lograrlas, te encuentras con la lealtad y la motivación intrínseca de las personas que trabajan a tu alrededor, es decir, los demás hacen bien y cada vez mejor las cosas, por el simple hecho que querer ser buenos en lo que hacen y cada vez mejores, y de lograr los objetivos en común.