Cambios de paradigma 2011: La nube mal entendida

Predecir el futuro ya está muy gastado y no voy a intentar leerles mi bola de cristal para esta año 2011. Mas bien intento crear consciencia junto con todos los desarrolladores de cómo se esta moviendo el mercado de los sistemas rápida y constantemente de un lado a otro, en lo que yo creo podemos salir perdiendo o ganando, como en todo cambio, dependiendo que tanta energía e inteligencia le pongamos.

“La nube”, quiero decir el Cloud computing, sigue siendo siendo un concepto no entendido o mal explicado, casi como la programación orientada a objetos a principios de los 90s, y en muchos casos desgraciadamente hasta la fecha (que personalmente tardé en entender y practicar al 100% algo así como ocho años).

Gran parte de los que entienden el cómputo en la nube, tienen un concepto correcto pero solo ven una parte de todo este nuevo paradigma. Y es que resulta que todo software que usamos en nuestra red de casa u oficina pero que corre en servidores fuera de nuestra red, viene a ser cómputo en la nube.

Este concepto incluye, entre miles de otras cosas que usamos diario y hemos usado durante muchos años, los siguientes: Hotmail, Facebook, Twitter, Blogger (este blog esta un servicio en la nube!), todos los demás servicios de Google (el buscador, GMail, Calendario, Docs, Adwords, Analytics y toda la plataforma Google Apps), todos los servicios de hospedajes de páginas web tradicionales, los servicios de mensajería instantánea (no los programas cliente, pero si los servidores) como Live Messenger, el mismo caso con Skype, otros servicios más especializados como SalesForce, Microsoft Dynamics CRM services, etc. etc. etc.

Además, igual que en la venta de equipo de cómputo donde hay un Mayorista y un Revendedor que le compra a ese mayorista y tiene un ganancia al revender, también hay “Mayoristas” de la nube, que te dejan subir tus aplicaciones a sus servidores y te cobran por el uso de CPU, memoria, almacenamiento, etc. siendo los más destacados Amazon Web Services, Microsoft Azure, Google App Engine y Rackspace, pero no los únicos. Algunos ejemplos de “Mayoristas” mas pequeños son Xeround database o EP.IO de los que Domingo Aguilera y Norberto Martínez han hablado.

La tendencia parece ser la siguiente: Los fabricantes de hardware se dedican fervientemente a hacer servidores más grandes que soportan virtualización y a hacer clientes más pequeños (como las Netbooks, los cada vez más poderosos smartphones y las muy atractivas Tablets), y los grandes fabricantes de software hacen sistemas y servicios cada vez mas genéricos y cubren cada vez más necesidades con sus plataformas (como los que ya mencioné), o pequeños fabricantes tratan de hacerse millonarios con una aplicación que pongan en la nube como si trataran de pegarle al premio mayor de la lotería, aprovechando la globalización de estos servicios (pequeño esfuerzo y grandes ganancias, el sueño húmedo recargado).

Hay mucho que aprender e investigar para aprovechar el no tan nuevo paradigma de aplicaciones como servicios en la nube. En su forma más primitiva, hacer aplicaciones web o web services es suficiente, incluso saber usar Microsoft Terminal services para distribuir aplicaciones es una opción. Aplicaciones web “Ajaxificadas” o hechas con paradigmas RIA completos como Silverlight o Adobe Flex, junto a web services eficientes y generales parece ser lo ideal para subirse a la nube. Google apoya Python y Java, Microsoft obviamente ASP.NET (tradicional o MVC), Windows Communication Foundation (WFC) y Silverlight, Amazon y RackSpace tienen formas más abiertas, como rentar servidores virtuales completos y cada quien sabrá que les instala.

Yo no creo que “todo correrá en la nube algún día”, de hecho decir eso implicaría una mentira. Pero es una tendencia firme y arrolladora, y muchos profesionales van a quedar arrollados como en todo cambio (¿recuerdan MS-DOS a Windows? ¿16 a 32 bits? pues tal vez sea aún peor!). Hay que echarle ganas a entender el verdadero impacto del cómputo en la nube, porque es una realidad con la que vivimos desde hace tiempo.

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 ;-)

How Kool is Dhat? Kinect en Delphi

Alguien con tiempo libre de sobra se aventó un componente de Delphi para utilizar el controlador Kinect del XBox 360 de Microsoft en cualquier programa.

El componente, llamado TKinect por supuesto, es libre (abierto y gratuito). Se lo pueden descargar de la pagina del autor (Simon J Stuart), y quien tenga un hijo que haya recibido el Kinect esta navidad por sabia sugerencia y guía de su papá puede conectar el sensor al puerto USB de la compu y hacer sus propios experimentos.

Además del sensor Kinect y el componente TKinect existen otros requisitos (los drivers gratuitos y una relativamente buena tarjeta de gráficos también). Todo esta listado ahí en el articulo del autor.

Si hacen algo interesante, avisen! muchas utilerías hechas en Delphi podrían beneficiarse de una interfaz touchless.

Cursos de Delphi y Silverlight para diciembre 2010

Acabamos de publicar la oferta de cursos de Delphi y Microsoft Silverlight para este mes de diciembre 2010 en MetaCode.

Pueden consultarlo en el sitio de MetaCode en http://metacode.mx/es/cursos-diciembre-2010.

Los cursos son virtuales, lo que permite que el horario sea mas adaptable y no tengan que invertir en viáticos para participar, así estaremos como instructores y haremos como siempre, cursos prácticos y personalizados.

Se trata de una ronda que incluye el curso principal de Delphi además de varios módulos como Programación Orientada a Objetos, DataSnap, reportes con FastReports (desde mi punto de vista, la mejor opción en reportes en Delphi), y un mini-modulo de 4 horas enfocado en cuestiones relativamente recientes del lenguaje en Delphi, como son Genéricos y Métodos Anónimos.

Por el lado de Microsoft Silverlight, se ofrece el curso de Fundamentos y Aplicaciones Silverlight, que es el curso introductorio a la tecnología. Aunque es el curso básico, es necesario tener fundamentos de C# y en general de .Net

Esperamos que la selección sea de su agrado, son los que mas nos han pedido últimamente, y forman un paquete integral, mezcla de temas intermedios y especializados en Delphi.

En el caso de Silverlight estamos proyectando programar la capacitación avanzada para Enero del próximo año.

Si requieren información pueden contactar un agente en el correo “capacitacion” de metacode.mx  o solicitar información en la pagina.

Nuevas luces en la blogosfera

Haciendo una pequeña pausa en la serie de artículos sobre control de versiones:

Un par de excelentes consultores y amigos, ambos con ideas de la nueva generación de Tecnologías de Información, tienen ya su espacio de expresión en el web.

Estoy seguro que serán una fuente de información invaluable y una referencia en lo que respecta a sus campos de acción. Sobre todo contribuir a guiar el camino de nuestra industria mexicana de sistemas.

El primero es mas bien un regreso. Se trata de Norberto Martínez, reconocido desde hace años en la comunidad Delphi, que ahora dirige el blog oficial de MetaCode. Tiene grandes ideas para el blog y estará contribuyendo con su experiencia en Delphi, Firebird, Python, control de versiones y muchas tecnologías de apoyo con su visión invaluable y pragmática. El blog se encuentra en http://metacode.mx/blog

Y el siguiente es una grata sorpresa para su servidor. SourceCode, un profesional que también admiro mucho como persona y como consultor de TI, y que contribuye en su blog en otra faceta en la que tiene mucho que aportar: como gerente corporativo de sistemas.

El blog de SourceCode se puede encontrar en http://elparadigmasiguiente.blogspot.com. El tiene experiencia y opinión valiosa en una cantidad de cosas, desde programación Delphi, infraestructura de sistemas, matemáticas, liderazgo y administración, gadgets y tecnología en general, hasta cosas como OpenSim. Veremos que sorpresas nos da.

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.

Silverlight es todo, menos zombie

Silverlight es una tecnología increíble, tal vez la mejor que Microsoft ha dado a luz. Solo espero que siga con su estrategia multiplataforma.

En la reciente convención PDC, la mas grande conferencia de desarrolladores de tecnologías Microsoft del año, se dio enfoque a que la compañía pondría muchos de sus huevos en la canasta de HTML 5 con su nuevo Internet Explorer 9.

Como mucha gente percibe a HTML 5 como una tecnología que podría cubrir las necesidades que Silverlight nació para solucionar, muchos reporteros amarillistas que viven de hacer escándalos (hasta en nuestro medio sucede eso, es increíble) comenzaron a sugerir cosas estilo “Silverlight esta muerto” y “Microsoft abandona a Silverlight por HTML 5”, y otros encabezados mas llamativos para que los lean mas y vender mas.

Por supuesto esas noticias se va corriendo como pólvora, incluso Marco Cantú ya lo menciono en su blog.

Con todo el respeto que me merece Marco y su forma muy sensata de exponer las ideas, quien crea que algo tan útil y redituable para todos (empezando por Microsoft) como Silverlight “morirá” no pueden estar mas equivocados.

La historia lo dice todo: Microsoft deja lo que no pega, o si inventa (copia) una tecnología nueva que le va a redituar mas. Pero el caso es muy diferente:

• Silverlight es propietario y multiplataforma, mientras que HTML es un estándar con el que es mas difícil competir. Todos los navegadores lo soportaran tarde o temprano, y Safari o Google Chrome van muy adelante.
• La estrategia con IE9 es recuperar el mercado que Google Chrome y Firefox han ido tomando. Ahorita dice Microsoft algo, y luego cuando liberen Silverlight 5, dirán otra cosa.
• Toda la lógica de HTML 5 es Javascript, ¿han intentado hacer grandes aplicaciones en JavaScript, incluso usando jQuery o Dojo? Yo no lo vuelvo a hacer, gracias a Silverlight.
• Para hacer una RIA, Silverlight tiene total integración entre la capa intermedia de servicios y la Interfaz del cliente, incluso ayuda con la conexión a BD.
• Con Silverlight puedo instalar las aplicaciones en mi escritorio (en modo Out-of-Browser) y solicitar permisos elevados. HTML 5 puede soñar con eso, por que nunca va a poder hacerlo.
• En modo Out-of-browser con permisos puedo instanciar Excel u Outlook y cualquier otra cosa COM, Leer y escribir archivos del usuario, usar el API de Windows, etc.
• Silverlight sigue siendo la plataforma de desarrollo para los Windows Phone 7 que vienen en grande.
• Las animaciones y efectos en Silverlight son sencillos de hacer con Expression Blend.
• Para la lógica de Silverlight puedo usar C#, JavaScript, Visual Basic, F#, y mas adelante IronPython, IronRuby, Delphi Prism, etc. Así solo tengo que aprender un lenguaje para el backend y el frontend.
• Una sola aplicación de Silverlight en una pagina web puede manipular todo el JavaScript, HTML DOM y CSS de la pagina.

Para su servidor, es obvio que Silverlight esta mas vivo que nunca desde que se libero Silverlight 4 en marzo de este año, como también es obvio que Microsoft va por todo, como siempre, sin importar si atropella a dos que tres (mil) en el camino. Ayer por Silverlight 4, ahora por Internet Explorer 9 mañana por Silverlight 5, etc, etc.

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.

¿Problemas con Delphi (o cualquier otra cosa) con el registro en Windows de 64bits?

Para habilitar la compatibilidad de aplicaciones de 32 bits en sistemas Windows de 64 bits, Microsoft realizo algunos ajustes al registro. Esto ha permeado en varias aplicaciones antiguas o compiladas con compiladores antiguos, por ejemplo Delphi 7. Por ejemplo, al intentar borrar una llave del registro con un TRegistry es posible que simplemente no lo haga y no de ninguna retroalimentación del error.
En el blog oficial de Delphi-JEDI describen el problema principal, y alguna posibilidad de darle la vuelta, conectando con el registro mediante la API de Windows, pero previamente determinando la versión de Windows en donde se corre el sistema para saber que función del API de debería invocar. La versión actual Delphi 2010 lo arregla por supuesto.
Esto es independiente de si Delphi compila a 64 bits, lo cual no hace, ni hará en esta versión XE. Según Allen Bauer, Jefe Científico de Embarcadero, este es el objetivo de la próxima versión hasta el 2011 (si no se cambia el roadmap otra vez, espero que no).
Por cierto, el segundo video vista previa de Delphi XE esta al aire, tanto en el sitio de Embarcadero como en YouTube.