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.