martes, 7 de mayo de 2013

El Maestro Programador gana el Juego del Software - Parte 1

Desde casi 400 años en el pasado, un Samurai nos enseña lecciones para tener éxito en el desarrollo de software y ser un maestro, ya sea como programador, analista, diseñador o arquitecto de software, e incluso aplica a cualquier arte/ciencia/técnica. 


Miyamoto Musashi escribió el libro Go Rin No Sho (El libro de los Cinco Anillos) en el siglo 17, después de ganar batallas toda su vida y llegar -completo- a los 70 años. Alistair Cockburn en su libro Agile Software Development (Adison-Wesley 2007) incluso dedica un apéndice a citar las lecciones del Samurai. 

Puede ser sorpresa o no, pero la forma de pensar descrita en el libro de los cinco anillos aplica directamente al desarrollo de software y las he practicado por un tiempo ya, en la medida en que son efectivas. Claro que en nuestro caso, no siempre es una cuestión de vida o muerte con con las técnicas de batalla Samurai, pero aplican a Ganar el juego también 

He aquí algunas lecciones de Musashi, y mi reflexión de como se relaciona a nosotros los Programadores y Desarrolladores de Software, en una serie de artículos que tengo tiempo pensando en escribir. 

Lección 1
El campo de las artes marciales está particularmente plagado de exhibicionismo extravagante, con la popularización comercial y especulación por parte tanto de los que enseñan la ciencia como de los que la estudian. El resultado de esto debe ser, como alguien dijo, que "las artes marciales de aficionados son una fuente de graves heridas"...-Miyamoto Musashi, Go Rin No Sho, Siglo XVII
Esta es una de las lecciones mas obvias, mas fáciles de relacionar con nuestro campo de la programación. sin embargo puede haber otros comentarios necesarios.

 La programación de sistemas es una actividad económica  y como tal, esta sujeta a la competencia y a la mercadotecnia (y lo sabemos, porque de eso vivimos). 

El problema es cuando muchos intentan vender a como de lugar, el argumento de ventas probablemente mas típico es el de la "Bala de plata": la herramienta de desarrollo que sirve para todo y todo lo resuelve de una manera sublime y sin problemas. La "espectacular" técnica, metodología o patrón que dice adaptarse a
cualquier problema para convertirlo en solución. Incluso el desarrollador que dice saberlo todo y que siempre esta en posición de ataque/defensa para que no quede duda, con un curriculum con paginas llenas de palabritas clave y acrónimos que alguna vez vio en sus proyectos(o en los de la empresa donde trabajó) y presume de dominarlas todas y cada una.

Para el novato o no-tan-experto programador, incluso para experimentados con tendencias al fanatismo y a la cultura de la lotería, esto suena como algo que debería tener, una idea con que casarse, hacer vida juntos y tener muchos proyectos-hijos. Pero ¡Cuidado! ya que esto, en opinión compartida por su servidor, es una de las principales razones de "Graves Heridas", es decir, Proyectos fallidos, fuera de presupuesto, grandes derroches de recursos en herramientas que se dejan de mantener, altísimos costos de mantenimiento de sistemas heredados, e inclusive, de desencuentros entre colegas, y de despidos y renuncias con animadversión por ambas partes. 

Por el contrario, el pragmatismo sigue siendo una buena filosofía: "La verdad es solo lo que funciona, y lo que funciona es la verdad. Cuando no aplique, entonces es solo una verdad a medias". Esto significa que las Herramientas, aplicaciones, metodologías  técnicas, colaboradores y soluciones deben ser juzgadas por su verdadera utilidad, y saber lo mas pronto posible cuales son sus fallos, y entonces decidir de entre las opciones a la mano, cual podría resultar mejor. 

Claro que no es fácil retirar el exhibicionismo y la espectacularidad del camino, sobre todo para quien le gusta creer en los reyes magos todavía o que le gusta hacerse la vida fácil, pero recuerda que estas son solo una herramienta para llegar a un fin, que es un proyecto de software exitoso. 

Después seguiré exponiendo algunas otras lecciones de Musashi para el programador. Arigato.

jueves, 3 de mayo de 2012

Andreano Lanusse se va de Embarcadero Technologies

Si hay alguien conozco que concuerda con la descripción de Guerrero Incansable es Andreano Lanusse.

Durante el tiempo que ha representado a Borland/CodeGear/Embarcadero, a Delphi en especial, ante toda la comunidad latinoamericana desde México hasta La patagonia, ha viajado, presentado, defendido y contribuido sin descanso, tomado decisiones difíciles, negociado con clientes grandes y pequeños, con una historia de socios de negocios, soportado las necesidades de una gran comunidad con características muy especiales como son el poder adquisitivo, la emergente y a veces insuficiente educación tecnológica y comercial, el creciente impulso de innovación y competitividad, y una gran comunidad del tamaño de una generación de desarrolladores con muchas ganas de avanzar.


No solo eso, mientras tanto también contribuyó con investigación y desarrollo dentro de Borland/CodeGear/Embarcadero, estoy seguro que muchas ideas técnicas y comerciales del producto, por lo menos de Delphi, son de Andreano o cooperó en ellas. Un técnico destacado que hace su trabajo por gusto y con gusto, que ademas adquirió capacidades excepcionales de  mercadotecnia y capaz de administrar su tiempo como pocos.

Hace un par de días, Andreano aviso que deja Embarcadero http://www.andreanolanusse.com/en/bye-bye-embarcadero/

No se que esté sucediendo en este momento en California, pero lo que si sé es que Embarcadero, sus compañeros desde Borland/CodeGear, la comunidad latinoamericana de Delphi -hable español, inglés o portugués-, perdemos a un guerrero incansable.

Mucha suerte en tu camino, mi amigo. No dudo que seguiremos sabiendo de ti.



viernes, 10 de febrero de 2012

Gadget de Conexiones RDP hospedado por Metacode S.A.

El gadget de Conexiones RDP para Windows al fin esta arriba para descarga! Disculpen a quienes estuvieron esperandolo desde que la Windows Live Gallery fue cerrada.

Pueden descargarlo del sitio web de Metacode S.A. dando clic aqui.

sábado, 22 de octubre de 2011

El equipo de un desarrollador de estos dias

Parte de esta entrada se va a volver rápidamente obsoleta seguramente, pero para mí es una referencia del estado actual de las cosas. Obviamente las empresas esperan de un desarrollador de software muchas cosas: profesionalismo, todo el conocimiento del mundo, grandes capacidades analíticas, confidencialidad, compromiso, consistencia en sus resultados en general, y a veces un par de milagros al mes, si no al día. Eso es al día de hoy y, para bien o para mal, no va cambiar en un tiempo.

Lo que no es obvio para muchas empresas, es que no se le puede exigir a un soldado que gane batallas sin buenas armas, y por supuesto un buen desarrollador necesita el mejor equipo al que pueda tener acceso para sus tareas diarias.

El desarrollador de estos días debe tener instalada -y gran parte ejecutándose- una cantidad inmensa de herramientas para hacer su trabajo, y dichas herramientas son cada vez más hambrientas de recursos, despegándose cada vez mas de las necesidades del usuario común.

Y es que así es, un programador a principios de los 90s usaba ambientes que eran básicamente editores de texto con algunas capacidades específicas, mientras que un usuario abría Lotus 1-2-3, tal vez Windows 3.11 con Harvard Graphics 2.1, o WordPerfect 5 que eran aplicaciones que consumían los 2 Megabytes de RAM a los que se tenía acceso a los 30 segundos de ejecutarlos. El programador vivía en un editor de texto, y no requería tanto de estar switcheando a otras herramientas, si acaso volver a la línea de comandos a compilar.

A principios de siglo (XXI claro), ya todos sobre sistemas operativos gráficos, un programador solo necesitaba un Ambiente Integrado de Desarrollo (nuestros IDEs) que hacia todo, como Delphi, Visual Basic o Eclipse. Estas herramientas son, por si solas, tan pesadas como Adobe Photoshop o como tener Excel, Word, Outlook e Internet Explorer abiertos al mismo tiempo, como es muy común en un usuario típico de oficina. Las necesidades del desarrollador estaban mas o menos en el mismo rango del usuario diario o del power user cuando mucho.

Ahora en estos días, pasando la primera década de este siglo, hay muchas nuevas necesidades a cubrir, además que se desea que un desarrollador sea hiperproductivo. Un programador profesional debe tener, además del persistente IDE de la plataforma diaria (como Visual Studio o Delphi), otros IDEs de diferentes plataformas (por ejemplo Eclipse) ya que el mundo hoy es menos homogéneo, es decir, si usas Visual Studio o Delphi pero quieres programar para Android de forma nativa, además se necesita Eclipse o una de sus alternativas.

Por supuesto, ahí no para la cosa, también es posible que sea necesario tener un buen editor de HTML, una herramienta de desarrollo especializada en XML/XSD/XSLT/XPath/X...cetera, un buen editor de gráficos porque para que lo sepa todo el mundo, Paint no es suficiente cuando se trata de hacer iconos y no se diga gráficos para web, y por supuesto un administrador de bases de datos. Es necesario tener Outlook o Thunderbird si quieres que tus programadores te respondan los correos de vez en cuando, y no se diga Skype y similares, aunque esto vaya en detrimento de su concentración. Y para acabarla, es muy probable que sea imprescindible tener una o más máquinas virtuales corriendo en el mismo equipo, ya sea para pruebas en diferentes ambientes, pruebas de conexión remota o para ejecutar herramientas no compatibles con el sistema operativo principal de la máquina.

Hay otras herramientas que muy probablemente serán necesarias son por ejemplo, la utilería del control de versiones, algún profiler o analizador de código, servidores web o de aplicaciones (Apache y IIS, juntos en ocasiones), el explorador web sin lugar a dudas, y algunas herramientas de colaboración. Sin descartar además Excel y Word.

Sabiendo esto, es el colmo tener a buenos programadores haciendo su trabajo en una laptop con 1 GB de RAM con 80 GB de disco duro, heredada del gerente que la heredo del director. Pero... estoy seguro que esto no sucede tanto, ¿verdad? :)

Afortunadamente tengo un equipo decente, y siempre trato de estar actualizado. Me he topado con fiascos, como una HP Pavillion que creí muy buena, y que no me duro ni el periodo de garantía. Pero en general no me puedo quejar, en lo personal claro, pero he visto esto suceder a mí alrededor una cantidad increíble de veces, y sigue sucediendo.

Un buen equipo para hoy en día, sin exagerar y centrándose únicamente en cubrir las necesidades diarias comunes, depende de cada quien, pero podría ser algo como esto, y no menos que esto:
  • Procesador Intel Core i5 o AMD Opteron Quad-core. Un Intel Core i7 sería un gran plus.
  • Al menos 4GB en RAM, pero 8GB seguramente son una buena inversión para la productividad
  • 250 GB de disco duro por lo menos. 500 es un buen numero.
  • Dos pantallas. IMPORTANTE: Cada centímetro cuadrado más de despliegue hace más productivo al desarrollador. Codificar, depurar, leer documentos de diseño y requerimientos, instalar, dar soporte y mantener la comunicación, todo en una pantalla de 15", es un abuso y nada menos que un abuso. Si es una laptop, una pantalla extra es suficiente, todas las laptops desde hace 8 años tienen salida para la pantalla adicional y pueden extender el escritorio, no hay pretextos.
  • En caso de una laptop, una base que levante el monitor, un cómodo teclado y un mouse.
Es lo menos, así es. NO, no. No hay regateo ni se fía nada. Esto es lo que se llama UNA INVERSIÓN SEÑORES, se las presento.

Y cualquier programador que enorgullezca de serlo un poco, estará de acuerdo, ¿o no?

domingo, 10 de julio de 2011

La competencia en la que estamos aunque no lo entendamos

A muchísima gente sigue sin caerle el veinte: Esto es una competencia mundial.
Es muy simple, si México (o cualquier país) compra muchos productos y servicios a otros países, y al mismo tiempo vende muy pocos, se va quedando pobre y eventualmente lo resentimos todos nosotros.

No se trata del gobierno, solo tenemos el gobierno que nos merecemos. No se trata de los otros países, ellos solo están haciendo su deber: preservar lo mejor para ellos. En un partido de fútbol, ¿Quien puede culpar al equipo oponente por tratar de ganar o por defenderse?

En este momento, nuestros países latinoamericanos tienen mas oportunidades que nunca, yo creo que en México incluso tenemos mas oportunidades que las que tuvimos a principios del siglo XX cuando se expropio el petroleo. Y no hay que ser científico para saber que hacer: echarle TODAS las ganas con TODA la inteligencia posible, educarnos, leer, copiar lo que otros hacen, mejorarlo, especializarnos como profesionales, hacer lo que sea necesario, pero por el camino correcto, para ganar la competencia. 

No es un reto que resolveremos de hoy para mañana, puede tardar 10 años, puede tardar una generación, pero no va a pasar solo señores, solo hay que ver el tamaño del reto, ver lo que nuestra competencia esta haciendo. Y para muestra basta un botón: 


Tenemos un gran cliente y socio natural con un gran poder adquisitivo que es Estados Unidos de America, ademas de las grandes potencias de la Unión Europa, y ¡entre nosotros mismos incluso!

martes, 28 de junio de 2011

Buscando talento

Un buen proyecto es hecho por la gente que lo integra. Por ahí hay un excelente proyecto, de esos que no se dan muy a menudo, que necesita de buenos programadores. Si a alguien le interesa ser parte del equipo mandenme su curriculum a salvadorhgr (en) gmail.com

Las características de los desarrolladores deben ser:
  • Mínimo dos o tres años programando .Net, preferentemente con C#
  • Buena experiencia en Web services: XML web services, WCF, de preferencia alguna aplicación SOA.
  • Pasión por la programación, indispensable para hacer buen equipo.
  • De menos mantener una conversación en ingles. Algunas entrevistas y la capacitación serán en ingles.
  • Excelente si tienen Visa de E.U.A. vigentes, o que no tengan ningún impedimento para tramitarla.
Obviamente hay un buen sueldo y buenas condiciones de por medio. Por si les interesa, ya saben. 

DISCLAIMER: Yo no estoy cazando gente por ganarme una comisión (no es mi culpa que tenga buenos amigos que valgan mucho también como profesionales y que encuentren una buena oportunidad. Un abrazo Miguel!), mi interés en este caso es el proyecto y por supuesto, que la oportunidad le llegue a quien la merece (léase: quien cumple con los anteriores requisitos :)

martes, 24 de mayo de 2011

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.

miércoles, 4 de mayo de 2011

Buenos foros: DelphiAccess, StackOverflow y Area51

Primero que nada: El foro DelphiAcces va muy bien! Felicidades a los administradores y creadores de tan excelente idea! Moderno y digno sustituto del desaparecido y bien ponderado Programadores Delphi México, DelphiAccess es mi foro favorito de Delphi en español.

En segundo lugar: Casi seguro, al "googlear" en busca de respuestas de programación han caido en SatckOverflow, o aun mas seguro leyeron de este sitio en el blog de Jachguate (¡Saludos Juan Antonio!). Muy probablemente usan este excelente sitio, donde la participacion se traduce en una reputación por votos de otros sobre tus preguntas y tus respuestas, todas ellas etiquetadas y bien indexadas. Incluso hay quienes incluyen su reputacion de StackOverflow en su curriculum.

El motor con que esta hecho este sitio se ha propuesto para hacer otros foros especializados en cuestiones muy diversas, por ejemplo: Uso del idioma Español, Viajes, Jardineria y paisajismo, etc. Existe un sitio en el que se construyen estas propuestas y se van definiendo y refinando hasta salir a a luz: el sitio se llama Area51 y digamos que es como la fabrica de foros de preguntas y respuestas.

Hay algunas propuestas que me parecen muy interesantes y de las cuales me hice inmediatamente seguidor:
  • Software Development Process es la propuesta para un foro de metodologias de desarrollo (todas incluidas: Agil, RUP o Asshole-driven-development :)
  • Comic books porque no todo en la vida es software, y como buen geek tengo que aceptar que me gusta el medio de el comic, el arte y la creatividad en una buena historia. La idea del foro es poder hacer preguntas de todo lo relacionado a coleccionar, seguir y leer novelas graficas o webcomics, lo que sea de buena calidad.
Especialmente el de Software Development Process, cualquier interesado puede unirse a la causa para que este sitio salga al aire pronto. El contenido de ese foro sera algo que nos hace mucha falta en nuestras empresas latinoamericanas y que hace la diferencia para crecer a un mayor ritmo y tener mas proyectos mas exitosos.

jueves, 7 de abril de 2011

Pista en vídeo de Delphi 64bits (casual?)

No se si alguien notó que en el primer vídeo de Sneak Preview de Delphi 64 bits:

Cuando están mostrando como establecer la DLL de dbExpress para 64 bits en la nueva propiedad vendorlibwin64 (librería de Win64 del proveedor de base de datos) de la conexión dbExpress (min 8:25 aprox.), justo arriba de esa propiedad viene otra llamada vendorlibosx... !! (librería Mac OS X del proveedor.. etc.)

Claro que no creo que sea una filtración casual... pero ya lo veremos en los próximos vídeos de Sneak Preview del nuevo Delphi.

miércoles, 6 de abril de 2011

Delphi64

Seguro muchos ya saben (Salvador Jover lo anunció desde hace dos días): Delphi en 64 bits al fin. Oficial desde Embarcadero.

Aquí pueden ver el primer vídeo (y ahí mismo los que seguirán) http://www.embarcadero.com/products/delphi/64-bit

.... Mmmm... vendrá también la compilación a Mac...?

domingo, 27 de marzo de 2011

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.

martes, 18 de enero de 2011

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í:

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

jueves, 30 de diciembre de 2010

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á Guiño 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.

jueves, 25 de noviembre de 2010

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.

miércoles, 17 de noviembre de 2010

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.

lunes, 15 de noviembre de 2010

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.

viernes, 12 de noviembre de 2010

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.

jueves, 4 de noviembre de 2010

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.

jueves, 23 de septiembre de 2010

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.

martes, 17 de agosto de 2010

¿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.