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?

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: 

http://www.elnuevoherald.com/2011/07/09/977982/andres-oppenheimer-el-desafio.html

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!

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

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.

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.

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.

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

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