ALT.NET Hispano

Debemos dar estimados

Mario H. Cornejo — Tue, 29 Sep 2015 11:00:00 +0000

Unos de los aspectos importantes para decidir si un proyecto se aprueba o no es conocer lo que va a costar y cuánto tiempo va a tomar el desarrollo. Como programador me gustaría no tener que realizar estimaciones de cuanto me voy a tardar, me gustaría solo programar y ya. "Estará listo cuando esté listo" es una de las respuestas favoritas. Sin embargo como consumidor, cuando solicito un servicio, me gusta saber cuánto se van a tardar y cuánto me va a costar.

Por ejemplo cuando llevo el carro al taller mecánico, me gusta saber que le van a hacer, cuanto me va a costar y el tiempo. Aun sin saber de mecánica, debo saber si vale la pena arreglarlo o quizás mejor me conviene andar en taxi por un tiempo o incluso ver la opción de vender ese carro y comprar otro.

Lo mismo pasa cuando planeamos realizar trabajos de construcción, por ejemplo alguna ampliación en la casa. Antes de conocer los detalles me gustaría saber cómo cuánto cuesta para ver si estoy listo para tener esa inversión. No puedo simplemente crear historias de usuario para la nueva habitación, pedirle al equipo de construcción que empiece y que diario me vayan platicando que hicieron el día anterior, lo que harán hoy y los obstáculos que han encontrado. Y mientras yo pagar cada semana y esperar que me avisen cuando esté listo.

Si contrato a alguien que va empezando quizás no sepa cuanto se lleve terminar una construcción. Por su falta de experiencia no me hará las preguntas necesarias para poder hacer un análisis, crear un diseño para determinar el tiempo y costo. Si contrato a un profesional yo espero que sepa recabar toda la información necesaria para poder realizar el análisis, diseño y presentarme un proyecto con el tiempo y costo estimado.

Lo mismo esperan nuestros clientes si contratan a un profesional. Una vez que nos exponen su necesidad nosotros debemos de realizar las preguntas necesarias para poder realizar un análisis, crear un diseño y estimar el tiempo y costo del proyecto.

El profesional es el experto en el tema. Es la persona capacitada para tomar las mejores decisiones en el proyecto. Es por eso que es el profesional quien debe ser responsable de que el proyecto se termine en tiempo y dentro de presupuesto. No debemos dejar que el cliente, que no necesariamente conoce como se desarrolla el proyecto, corra el riesgo de nuestras decisiones profesionales. Tampoco debemos esperar que siga pagando retrasos de proyecto debido a nuestras malas decisiones.

A veces como programadores nos da miedo presentar un presupuesto a un cliente, preferimos cobrarle por hora para no correr riesgos; pero como profesionales debemos ser nosotros los responsables del proyecto.

Puede haber imprevistos, por eso se debe tomar un tiempo para "lo que pudiera pasar". Además se puede ir ajustando el estimado conforme allá cambios en los requerimientos. No por eso debemos evitar la responsabilidad y comprometernos a entregar algo en tiempo y forma.

Workshop ASP.NET Multiplataforma

Thu, 24 Sep 2015 01:18:13 +0000

Hoy estuve en el MUG dando un Workshop practico sobre .NET multiplataforma.

Desde aquí pueden descargar los ejemplos y la presentación en este mismo post.

¡Gracias a todos los que asistieron! :)

Filed under: General Tagged: software-development

¿Qué es un Programador Senior?

Mario H. Cornejo — Thu, 06 Aug 2015 13:37:00 +0000

Hace tiempo en una reunión con uno de nuestros clientes se hablaba de la posibilidad de asignar algunos programadores senior al proyecto que se estaba discutiendo. Una de las personas en la junta preguntó: “¿Cuáles son los criterios que usan para saber si un programador es senior?” La pregunta me puso a pensar en que realmente no tenemos una definición formal para clasificar a un programador como Senior; pero si podemos reconocerlo cuando lo vemos. Lo reconocemos por sus características.

Es autónomo y sabe trabajar en equipo. Con autónomo me refiero a que no necesita que alguien le esté ayudando constantemente para poder realizar su trabajo. Ya sea porque no tiene la experiencia o conocimiento en programación o porque no conoce el dominio del problema. Puede que la persona sea buena programando pero nunca ha trabajado en una industria en particular y por lo tanto quizás con frecuencia requiera ayuda para temas relacionados con la industria. En ese caso se le puede considerar JR al programador aunque tenga ya experiencia programando, por lo menos al principio mientras puede trabajar sin ayuda constante. También es necesario que sepa trabajar como parte de un equipo, para ello es necesario haber trabajado en otros equipos y así saber cómo aprovecharlo. Se sabe coordinar con sus compañeros de equipo.

Entiende como ayuda al negocio. Está es una característica que se sale un poco del aspecto técnico y a la vez está relacionado con el punto anterior. Un programador senior entiende que para la mayoría de los clientes la meta no es el software en sí. El software es una herramienta que ayudará al negocio a realizar mejor su trabajo. En este aspecto el programador junior solo se preocupa por que el software funcione. El programador senior aporta a la solución, no solo ejecuta.

Sabe medir el riesgo. Al ser independiente y entender como ayuda al negocio es capaz de tomar decisiones sobre el desarrollo de software tomando en cuenta el impacto que tendrán en costo y tiempo de entrega del proyecto. No se deja llevar por "el factor cool" o por ser lo nuevo. Sino que considera cual es la mejor opción para el proyecto.

Puede guiar a los demás. El programador senior puede enseñar a nuevos programadores, puede explicarles las necesidades del negocio, enseñar los aspectos técnicos de la plataforma o entorno de desarrollo y aportar ideas para establecer las reglas al momento de trabajar en equipo. Puede ser un mentor y guiar a programadores JR en su camino a convertirse en mejores programadores.

No hay umbral fijo para saber cuándo un programador es JR, Mid o Senior. Estos son aspectos que dependen de persona a persona.

Me gustaría conocer otras características u otras formas de definir a un programador Senior, envíame tus ideas a blog@developeando.com

¿Programar es arte?

Mario H. Cornejo — Tue, 28 Jul 2015 12:53:00 +0000

He escuchado varias veces que programar es un arte. Es cierto que el código tiene algo de la personalidad del programador; pero de eso a llamarlo arte…

Hay muchas definiciones de lo que es arte, algunas lo definen simplemente como algo bien hecho; pero muchas otras hablan del aspecto estético y de la expresión del artista a través de su trabajo. Creo que por eso es que se le ha llamado arte a la programación, de alguna forma nos expresamos usando un lenguaje de programación. Además puede haber varios estilos para resolver el mismo problema. Algunos son más elegantes que otros y muchas veces la elegancia se basa solo en aspectos subjetivos, al igual que la belleza del arte.

El objetivo de la programación es distinto al del arte. El arte busca la expresión del artista, transmitir sentimientos, lograr un placer estético en el observador. La programación, por otro lado, busca la solución a un problema y al mismo tiempo hacerlo de una manera simple, ocultando la complejidad para el fácil mantenimiento del programa. Esa es la razón por la que considero que programar no es arte, ya que no busca la expresión del programador, sino la solución a un problema determinado.

Hay quienes opinan que la programación es una artesanía, lo cual me parece un termino interesante. Hace tiempo platicamos sobre la artesanía de software en el Dev3Cast.

¿Tienes algún comentario? Mándame un correo a blog@developeando.com.

.NET Multiplataforma (Windows, Linux, OS X)

Fri, 03 Jul 2015 21:08:44 +0000

Hoy estuve en el MUG dando una charla sobre .NET multiplataforma.

El código de los ejemplos lo puede bajar desde aquí y la presentación en este mismo post.

¡Gracias a todos los que asistieron, nos vemos la próxima! :)

Filed under: .NET, ASP.NET, Conferences Tagged: software-development

Presentar en un grupo de usuarios

Mario H. Cornejo — Thu, 02 Jul 2015 11:27:00 +0000

Un grupo de usuarios es una comunidad de programadores (o similares) que se reúnen aproximadamente una vez al mes para hablar de tecnología. La mayoría de las veces hay un invitado que presenta ante los demás algún tema de interés para el grupo.

Las reuniones de los grupos de usuario son en persona porque, aunque hay presentaciones que pudieran atenderse en línea, estas son solo un pretexto para reunirnos.

Los grupos de usuario son un pasatiempo, aun así considero que hay ciertas ventajas al dar alguna presentación:

Conoces más del tema: cuando me preparo para presentar, aunque ya conozca el tema, tengo que revisar la documentación y buscar cómo resolver posibles preguntas que tendrían durante la presentación. Esto hace que me familiarice más con el tema y así, al presentar aprendo. A veces pasa que alguien de entre los asistentes tiene experiencia en el tema o en un escenario en particular, esto me ayuda a tener otra perspectiva sobre como resolver el problema u otra forma de usar la tecnología.
Conoces gente: he conocido a varias personas al asistir constantemente a las reuniones de los grupos de usuario, algunos se han convertido en buenos amigos, con los cuales (además de hablar de otros temas) puedo comentar cosas de tecnología sin sonar tan nerd. Al conocer gente, han surgidos oportunidades de empleo o de negocio, que aunque no se tratan de eso las reuniones, las oportunidades son reales.
La gente te conoce: este punto está relacionado con el anterior. Aquí la ventaja es que las personas te conocen a ti como un profesional en lo que haces. Vas creando algo de reputación. La gente te ve como una figura de autoridad sobre el tema o (por lo menos) que puedes dominarlo.
Aprendes a expresarte mejor: al tratar de explicar el tema a varias personas que quizás no todas tengan la misma perspectiva o experiencia que tú; tienes que tratar de explicarte con diferentes palabras. Si alguien no entiende de un modo no puedes repetir lo mismo y esperar que de repente lo entienda. Por lo que debes buscar otra forma de explicarlo. Esta habilidad de explicarte mejor no es algo que suceda al instante, requiere práctica. Presentar seguido ayuda a expresarte mejor.
Adquieres confianza: al estudiar un tema y compartirlo con los demás, sientes que realmente dominas un tema y esa confianza puede reflejarse en tu trabajo, incluso en cómo te diriges a los demás. En cierto modo, presentar valida para ti mismo que conoces del tema.

Aun y con estas ventajas, puede que (aunque tienes el conocimiento) no te animas a presentar en un grupo de usuarios. Algunas de las razones que he conocido:

Falta de interés para compartir o flojera: no a todos les gusta reunirse con otro programadores o hablar de programación y eso está bien. A otros solo les gusta escuchar o sienten que no tienen el tiempo de preparar una presentación. No se necesita de mucho para presentar, se trata simplemente de hablar de lo que haces en tu trabajo (si te dedicas a programar) o de lo que haces cuando programas. Si lo que tienes es flojera entonces no hay mucho que se pueda hacer.
Miedo a hablar en público: "todos" nos ponemos nerviosos al presentar, la mejor forma de quitarse ese miedo es simplemente presentando. Darte cuenta que el peor escenario no es tan malo, además de ser poco probable. Y si llegara a pasar, siempre puedes intentar presentar después y corregir lo que haya salido mal.
Sientes que no sabes lo suficiente: crees que al presentar se van a dar cuenta de que no eres tan bueno, que "eres un impostor o un fraude". Esto le puede pasar a todos, incluso si tu trabajo consiste en programar y recibes un sueldo por ello. Un grupo de usuarios no es una gran conferencia, tampoco un seminario o diplomado, la idea es solo platicar sobre tecnología. Te recomendaría que al presentar seas sincero y decir lo que sabes, los problemas que has solucionado y en lo que estas batallando. Los asistentes, por lo general, aprecian la sinceridad y tratan de ayudarte a mejorar.

Si estás trabajando en algún proyecto y has tenido que resolver problemas; entonces ya eres un buen candidato para presentar en un grupo de usuarios. Toma en cuenta que:

La idea es reunirse y compartir experiencias, no nos reunimos para evaluarte como presentador.
Como asistentes, sabemos que eres un programador, no un animador o comediante que tiene que divertirnos.
La gente no va con la idea de burlarse del presentador.
La mayoría de los asistentes están dispuestos a ayudarte si te atoras en la presentación o si falla el demo.
Si todo te sale muy mal, en el peor de los casos, no pasa nada. No tienes que preocuparte por tener que regresarles su dinero, no es como si hubieran pagado por un curso o seminario.

Mientras seas una buena persona, no veo como pueda ser mala idea que presentes. Si te gusta la tecnología y platicar del tema, acércate a un grupo de usuarios. Siempre estamos buscando presentadores.

Platiqué de este tema con Gabriel Flores en el podcast dev3cast. Escucha el episodio.

¿Te gustaría comentar? Envíame un correo a blog@developeando.com

Windows 10 Developer Readiness

Sat, 27 Jun 2015 14:08:14 +0000

Como parte de la preparación para el lanzamiento del Windows 10, el 8 de Junio dicte un Webcast sobre desarrollo de aplicaciones Universal Windows Platform.

El video ya esta publicado en Channel 9, lo pueden ver aquí, o en este mismo post.

Gracias a todos los que participaron, y en especial al programa MVP y a Erika Vilches por el apoyo para dar es Webcast :)

Filed under: Client App Dev, Webcast Tagged: software-development

SignalR 2 Workshop

Tue, 02 Jun 2015 12:23:39 +0000

La semana pasa dicte un workshop sobre SignalR les dejo la presentación y el código aquí.

Enjoy! :)

Filed under: ASP.NET, Conferences Tagged: software-development

Conferencia sobre ASP.NET 5

Fri, 10 Apr 2015 00:43:41 +0000

Hoy di una charla en el MUG sobre la nueva versión de ASP.NET, especialmente sobre su nueva arquitectura y runtime.

Pueden descargar el código desde aquí, y la presentación mas abajo.

¡Gracias a todos los que asistieron!

Filed under: ASP.NET, Conferences Tagged: software-development

Ultima charla de 2014, ¡bienvenido 2015!

Mon, 22 Dec 2014 22:02:01 +0000

Hoy junto mi compañero de Lagash, Mariano Sanchez dimos la ultima charla del año en el MUG. Estuvimos repasando las novedades del stack de desarrollo Microsoft con las que estaremos trabajando en 2015.

Pueden descargar el código desde aquí y aquí.

Gracias a todos los que asistieron, y ¡feliz año nuevo! :)

Filed under: .NET, ASP.NET, Conferences Tagged: software-development

El programador desarrolla software

Mario H. Cornejo — Mon, 01 Dec 2014 13:51:00 +0000

Cuando personas no técnicas me preguntan a qué me dedico y les contesto: "Desarrollador de software". Por lo general no entienden exactamente que hago en mi trabajo. Muchas veces termino diciendo que soy programador o que escribo programas para computadora. Últimamente ya solo digo "programador". Sé que para muchos el programador no es lo mismo que el desarrollador de software. Pero pensándolo bien… ¿Será algo que al resto del mundo no le importa? ¿Realmente hay una diferencia?

Leyendo blogs he encontrado diferencias entre ambos términos. Se dice que el programador es la persona que escribe el código (nomas) y el desarrollador hace algo más. Según el desarrollador de software tiene otras habilidades además de escribir código. Se involucra en todo el proceso, como análisis, diseño, evaluar marcos de trabajo (Frameworks), lenguajes, arquitectura, etcétera. ¿Acaso el programador no tiene esas habilidades?

Según la Real Academia de la lengua, el programador es la persona que elabora programas de ordenador. En español de México diría que elabora programas de computadora. Ahora la pregunta es ¿Cómo se elabora un programa de computadora?

Un programa se elabora en incrementos, es decir, un programa puede ir cambiando con el tiempo, agregándole características. No se construye de la misma forma en que se construye un edificio, por ejemplo. No se hace una casa pequeña y después se modifica para convertirla en un rascacielos. Pero un programa puede crearse para una necesidad pequeña y después modificarse para que haga una cosa más. Por eso no decimos construcción, sino desarrollo de software. No es por las habilidades de la persona que lo desarrolla. Es por la forma en que se elaboran los programas.

Según la RAE la palabra desarrollador ni existe. Por lo tanto el desarrollo de software es dirigido por el programador. Porque es el programador la persona encargada de elaborar el programa. Quizás la necesidad de llamarnos “desarrolladores” es para sentir que hacemos algo más que solo escribir código. Y es cierto que hacemos algo más. Lo hacemos porque somos programadores y elaborar un programa requiere de varias actividades.

Hay de programadores a programadores, los hay con mucha preparación, habilidades, profesionalismo y también los que leyeron un manual e hicieron unos programas para ellos mismos, los que solo copian y pegan código del internet. Algunos solo conocen un lenguaje de programación o un IDE. No por eso nos vamos a llamar de una manera diferente. Así como hay constructores que hacen rascacielos y otros que solo casas para mascotas. Si te dedicas a elaborar programas, eres un programador. Si no te gusta que te digan programador y prefieres que te llamen desarrollador (palabra que no existe), esta bien, yo también lo hacia; pero recuerda que un(a) programador(a) se dedica a desarrollar software.

Leer antes de escribir

Mario H. Cornejo — Mon, 24 Nov 2014 13:56:00 +0000

Es común que una persona que toma un proyecto iniciado por alguien más, critique la manera en como esta hecho. Pasa en muchas profesiones y/u oficios. Trato de no hacerlo (tanto); pero...algunas veces es sorprendente como la persona que escribió el código se complicó la existencia reinventando la rueda. Es decir, creando su propia solución para un problema común. Es aún más sorprendente cuando quien lo hace tiene varios años trabajando en proyectos. Trataré de explicar como evitar ser esa persona que complica el código. Antes, daré un ejemplo de situaciones de este tipo.

Al leer código de alguien más.

En las aplicaciones realizadas en .NET la configuración de la aplicación se guarda en un archivo llamado igual que el ejecutable añadiéndole la extensión ".config". Así si mi ejecutable se llama miAplicación.exe tendré un archivo llamado miAplicación.exe.config en el mismo directorio. En caso de ser una aplicación web, el archivo se llama web.config. El formato del archivo de configuración es estándar y existen librerías que facilitan la lectura de los valores de configuración.

He estado en proyectos donde la persona que lo inició creó su propio formato de configuración y su propia convención para nombrar los archivos. La aplicación funciona; pero esto hace que se requiera más tiempo para entender lo que hace el código fuente del programa, se tiene más código que mantener a cambio de prácticamente ningún beneficio. La decisión parece estar basada en que no se conocía la manera (.NET ) de hacer las cosas. También lo he visto al usar librerías de acceso a datos, donde el programador original creo una forma de ejecutar los scripts, en lugar de seguir la convención o utilizar las clases que da el marco de trabajo.

¿Por qué alguien que tiene varios años programando no usa lo común? ¿Por qué no sigue la convención? Puede ser por la misma razón por la que algunas personas tienen faltas de ortografía. Por ejemplo yo. Hace tiempo al momento de escribir lo hacía con muchas faltas de ortografía, con el tiempo he aprendido a escribir mejor. Ahora es fácil notar (sin ayuda de un corrector ortográfico) cuando una palabra esta mal escrita. Esto no pasó solo por escribir varios años.

Empecé a notar que las palabras se veían raras, si estaban mal escritas, porque me acostumbré a verlas escritas correctamente al leer texto de otras personas, en libros, blogs, etcétera. El leer me ha ayudado a escribir mejor, a notar cuando algo no anda bien en lo que escribo. Aun sigo equivocándome; pero sé que entre más lea y escriba, reduciré mis faltas de ortografía.

Leyendo código. Foto de Gabriel Flores.

De igual forma leer código de otras personas ayuda a escribir mejor código. Siguiendo con el ejemplo anterior, si el programador hubiera leído el código de varias aplicaciones .NET se hubiera percatado de que la forma en que estaba guardando la configuración no era lo común. Hubiera sentido que su código se veía raro. O tal vez ni si quiera hubiera pensando en reinventar como realizar la configuración de la aplicación y hubiera usado directamente la convención del marco de trabajo.

Para escribir buen código además de tener práctica escribiéndolo, también hay que leer código de otras personas. El no hacerlo puede provocar que hagas algo distinto a la convención o "reinventes la rueda", que puede ser divertido (y servir para aprender) la primera vez; pero a la larga es algo a lo que pocos querrían darle mantenimiento. Si quieres escribir mejor código, práctica y lee código de otros.

Lo nuevo en ASP.NET 5

Fri, 21 Nov 2014 01:10:37 +0000

Hoy junto mis compañeros de Lagash, Mariano Sanchez, y Andres Vettori dimos unas charlas en el MUG. Mi charla fue sobre la nueva versión de ASP.NET (5).

Pueden descargar el código desde aquí, y las presentaciones mas abajo.

¡Gracias a todos los que asistieron!

Filed under: ASP.NET, Conferences Tagged: software-development

Desarrollando en la nube de nitrous

Mario H. Cornejo — Thu, 20 Nov 2014 09:05:00 +0000

Actualmente la maquina que uso para desarrollo es una laptop con un disco duro de 100 GB por lo que no tengo mucho espacio para instalar todo lo que quiera. Trato de instalar solo lo necesario para mi trabajo. Por eso no me gustó la idea, cuando en el proyecto que estaba trabajando necesité instalar Postgresql. Mi maquina actualmente ya tiene Firebird, Interbase, MS SQL Server, MySQL y el cliente de Oracle.

Recordé que hace tiempo había trabajado con nitrous.io por recomendación de un amigo. Así que creé una maquina nueva, la que había usado antes ya no la necesitaba (por ahora). Seleccioné el ambiente de nodejs e instalé Postgresql. Y así en unos minutos ya tenia una maquina con Linux, git, node y postgresql, gratis y lista para empezar a desarrollar.

Existen formas de usar tu editor local y sincronizar archivos; pero opté por usar el editor y la consola en línea. Es una ventana en el navegador donde esta un editor de texto con un árbol mostrando tus archivos y una ventana con la terminal. Con eso es suficiente para empezar a trabajar sin necesidad de tener archivos locales, ni software instalado localmente.

Después de un buen rato de estar trabajando en el proyecto, incluso olvidé que estaba trabajando en el navegador. El servicio es gratis si usas una maquina modesta. Puedo acumular "puntos" que llaman unidades de N2O y hacer mi maquina mejor, ya sea pagando o si alguien se registra usándome como referencia.

.NET Conf UY – Videos

Thu, 06 Nov 2014 23:58:56 +0000

Les dejo el video de mi charla sobre Roslyn en .NET Conf UY , y una entrevista que mi hicieron.

De nuevo gracias a los organizadores y a todos lo que asistieron a este gran evento.

¡Y que se repita el próximo año!.

Filed under: .NET, Conferences Tagged: software-development

.NET Conf UY

Sun, 05 Oct 2014 20:36:16 +0000

Ayer termino .NET Conf UY donde tuve el placer de exponer sobre Roslyn (el nuevo compilador de Visual Basic y C#).

La conferencia fue genial, 4 días de Worshops y charlas, con oradores de primer nivel, un muy buen clima y muchos amigos.

Los ejemplos de mi charla se pueden descargar desde aquí, y la presentación la pueden ver en ese mismo post.

Quiero agradecer especialmente a los organizadores por el excelente nivel de la conferencia.

¡Que se repita el próximo año!.

Filed under: .NET, Conferences Tagged: software-development

Acceso directo al Package Manager Console

Mario H. Cornejo — Fri, 29 Aug 2014 17:26:00 +0000

Desde hace tiempo, al trabajar en proyectos .NET me es necesario tener a la mano la Package Manager Console abierta (también conocida como Nuget). Ya sea para instalar paquetes en el proyecto(s) o para correr comandos de los paquetes (sobre todo de Entity Framework, al trabajar con migraciones).
Procuro, como muchos desarrolladores, no usar el ratón al momento de programar. Al usar con Visual Studio, "todo" se puede hacer solo usando el teclado. Para abrir la consola de nuget no he encontrado un acceso directo por defecto. Si quiero ver la consola, debo navegar por los menús con el teclado.

Presionar ALT + T, N, O. ¡Son muchas teclas!

Una vez abierto puedo usar CTRL + TAB y con las flechas seleccionarlo, es tardado.

Afortunadamente VisualStudio nos permite crear nuestros propios accesos directos. Para la consola de nuget (Package Manager Console) agrego CTRL + ALT + N como acceso directo. Así rápidamente puedo correr los comandos de las migraciones al trabajar con Entity Framework.

Para agregar el acceso directo: en el menú Tools, abro Options. Selecciono Keyboard en el menú de la izquierda, busco PackageManagerConsole, lo selecciono y presiono el nuevo acceso directo en el cuadro de texto. OK y listo. Ya tengo un acceso directo a la consola de nuget.

Tener este shortcut mejora mi flujo de trabajo...

Se viene .NET Conf UY

Wed, 13 Aug 2014 02:42:46 +0000

El 3 y 4 de Octubre se llevara a cabo .NET Conf UY, en donde estaré dando un sesión sobre Roslyn y el futuro de C#.

.NET Conf UY será EL evento de tecnologías .NET del año en Suramérica, contara con la participación de destacados speakers, workshops, espacios de networking, y mas.

Lagash tiene el privilegio de ser uno de los patrocinadores y por ese motivo los organizadores nos dieron la posibilidad de regalar un descuento del 35% en el precio de la entrada (mas detalles en el Flyer).

¡Nos vemos en .NET Conf UY!

Filed under: .NET Tagged: lagash, software-development

Lo nuevo en la plataforma de desarrollo Microsoft

Sun, 29 Jun 2014 21:03:08 +0000

La semana pasada junto con Mariano Sanchez, y Marcos Torres dimos unas charlas sobre lo nuevo en la plataforma de desarrollo Microsoft durante una jornada que organizo el MUG.

Pueden descargar el código desde aquí y aquí, y las presentaciones mas abajo.

¡Gracias a todos los que asistieron!

Filed under: .NET, ASP.NET Tagged: ASP.NET, software-development

Mejor en persona

Mario H. Cornejo — Wed, 19 Mar 2014 11:15:00 +0000

En varias ocasiones al estar haciendo algo de difusión sobre las reuniones de los grupos de usuarios (en particular con tijuana.js). Me han sugerido que transmitamos o grabemos las presentaciones para poder verlas sin asistir a la reunión. He considerado esa opción aunque no le he dado seguimiento. Principalmente porque no lo veo como una prioridad para la organización del grupo. Incluso he llegado a pensar que tal vez no sea buena idea.

Para mí, la meta del grupo es ser un lugar donde personas con un interés común (JavaScript en el caso de tijuana.js) se reúnan para compartir conocimiento, ideas, experiencias, etcétera; es decir, donde se puede hablar de eso que tienen en común. También, es un espacio para conocer a "colegas" de la región.

Como parte de esa meta, uno de los objetivos del grupo es tener una presentación de calidad cada mes para que tanto asistentes como presentador puedan aprender, comentar, discutir y estar al tanto de los temas. Tomando esto en cuenta se podría pensar que al grabar las sesiones se beneficia al grupo porque podría lograr que el conocimiento se compartiera con más gente. Aunque se cumpliría con el objetivo quizás eso no contribuye a que se cumpla con la meta del grupo. Las presentaciones son un medio, no un fin, son para tener algo de que platicar en la reunión. Sin asistentes no habría razón para la existencia del grupo. En cuanto al material visto en las reuniones, si de verdad te es importante tenerlo, es fácil encontrarlo en línea. Puede ser en el blog del mismo presentador o en sitios similares.

En conclusión, no es prioridad grabar las presentaciones de los grupos porque considero que no ayuda a la meta: reunirnos, conocer “colegas” de la región, comer pizza, tomar sodas y hablar de tecnología cada mes.

Jornada sobre ASP.NET MVC Intermedio y Avanzado

Thu, 27 Feb 2014 16:12:39 +0000

Hoy con Mariano Sanchez para estuvimos dando en el MUG una jornada sobre temas de ASP.NET MVC intermedios y avanzados.

Aquí pueden descargar el material.

¡Gracias a todos los que asistieron, y al MUG por organizarlo!

Filed under: ASP.NET, Conferences Tagged: software-development

Trabajar desde casa - interrupciones

Mario H. Cornejo — Thu, 08 Aug 2013 11:48:00 +0000

Una de las ventajas de dedicarme al desarrollo de software es que se puede hacer (casi) desde donde sea y (en la mayoría de los casos) a cualquier hora. Lo único que se necesita es una computadora y motivación.

La mayor parte del tiempo que llevo como desarrollador lo he hecho desde casa y hasta el momento me ha funcionado bien. He escuchado comentarios de personas donde dicen que ellos no podrían trabajar desde casa. Una de las razones mencionadas son las constantes interrupciones. Si bien es cierto que en la oficina también ocurren, en casa pueden llegar a ser más estresantes. La diferencia al estar en casa es el tipo de interrupción, la persona que nos interrumpe y sobre todo nuestra actitud al atenderla o posponerla.

Cuando he trabajado desde la oficina de la empresa, la mayoría de las interrupciones eran por compañeros de trabajo, consultas de trabajo, preguntas del cliente, invitaciones a ir por un café o simplemente platicar. No se sienten como interrupciones, a menos que tenga algo urgente que entregar, se sienten más bien como actividades que forman parte del día laboral. Al estar en la oficina no siento la obligación de estar todas las horas de trabajo pegado en la computadora produciendo código, el simple hecho de estar presente en la oficina me hace sentir que estoy trabajando. Además mi mente sigue de alguna forma en el mismo contexto. Puedo estar platicando con mis compañeros de oficina de cosas relacionadas con el trabajo o con lo que ocurre en la oficina.

Al estar trabajando en casa las interrupciones son distintas. Hubo un tiempo en que mi esposa no trabajaba, y era sólo yo el que trabajaba desde casa (hoy ambos trabajamos desde casa). Toda mi comunicación con la oficina era a través de la computadora (chat, email, etc.). Cuando mi esposa me interrumpía, para preguntarme cualquier cosa relacionada con la casa, era algo estresante. Incluso pasaba con preguntas sencillas que no me tomaban más de unos segundos contestar. Ese “estrés” no ocurría cuando trabajaba desde la oficina de la empresa con las interrupciones ¿por qué?.

Creo que esto se debe a que las interrupciones en casa son distintas porque en lugar de ser un compañero de trabajo quien te habla, ahora es tu familia (hijo, esposa, pariente) quien te interrumpe y eso saca a tu mente del ambiente laboral. Al principio esto puede llegar a ser más estresante que las interrupciones en la oficina por el cambio de contexto. Dejas de pensar en lo que pasa en el trabajo para pensar en lo que pasa en la casa. Cambias de unos pendientes a otros y parece que tienes más cosas en que pensar (lo del trabajo y lo de la casa). Además al hablar de cosas de la casa, en la casa, sentía la urgencia de regresar al trabajo, sentía la necesidad de estar las ocho horas pegado al monitor escribiendo código.

Una forma de lograr una separación de contextos fue crear una “oficina” en casa. Utilizar un lugar en la casa donde la familia pueda ver que estas trabajando. Y por lo tanto saber que no estas disponible en ese momento, a menos que sea realmente necesario. También fue necesario un cambio de actitud de mi parte y darme tiempo para salir de ese cuarto de vez en cuando en horas de trabajo. Ya sea por agua o café y platicar un poco con la familia como lo haría con mis compañeros de oficina. No tenia que fingir que no estaba en casa para evitar interrupciones, al contrario, aprovechar que estaba en casa para estar en casa. Con esto la familia sabe que sí estas y que no tiene que interrumpirte en cuanto algo se ofrece porque seguramente no tardaras en salir y si no sales es porque estas muy ocupado. Para esto puede ayudar la técnica pomodoro.

Creo en conclusión que algo que ayuda a lidiar con las interrupciones, cuando se trabaja desde casa, es que en lugar de tratar de impedir las interrupciones en el día las incluyo como parte del día laboral. Cada cierto tiempo salgo de la “oficina”, mi mente se distrae del trabajo, atiendo las posibles interrupciones en ese momento cuando ya no estoy pensando en trabajo. Estas “interrupciones programadas" evitan el estrés por el cambio continuo de contextos. Al regresar a la computadora mi mente esta lista para empezar otro periodo de trabajo continuo, sin interrupciones sorpresa.

Reunión inter-comunidades Julio 2013

Mario H. Cornejo — Tue, 06 Aug 2013 10:09:00 +0000

El pasado sábado 27 de Julio las comunidades tecnológicas de Tijuana (grupos de usuario) realizaron su reunión mensual el mismo día como parte de un mismo evento. Cada grupo contó con una hora para realizar su presentación. Uno de los objetivos del evento fue, para quienes no pueden asistir a todos los grupos cada mes, en esta ocasión pudieran asistir a las presentaciones de los otros grupos. En mi caso, cada mes asisto a la reunión de tijuana.js y trato de asistir a la de Tijuana .Net. Quisiera asistir a las demás; pero no puedo dedicar tantos días al mes para vistas a user groups. El hecho de que todos se reunieran el mismo día hizo que pudiera reservar el día entero para dedicarlo a las comunidades y así fue que pude asistir a reuniones de grupos a los que no había podido asistir antes.

El evento se realizó en las instalaciones del bitcenter, el cual se a vuelto “el lugar de reunión de las comunidades” (gracias a Ricardo Rosales que nos ayuda con eso). Inició a las 8 de la mañana y a tijuana.js le tocó la primera presentación. Pensé que por ser los primeros (a las 8:30 am) iba a estar casi sin asistentes; pero la realidad fue que ya había gente, quizás más que en una reunión mensual por separado.

(Presentación "Plain old Vanilla JavaScript" por Yves Mancera)

El programa fue:

8:30 tijuana.js : "Plain old Vanilla JavaScript" por Yves Mancera
9:30 RubyTij : ¿Cómo pensar en BDD? por Javier Murillo
10:30 Google Developer Group Tijuana : Instalar Ubuntu en una Chromebook
11:30 gultij.org : Introducción a Vagrant
--- descanso de 12:30 a 14:30 ---
14:30 DefConGroup Tijuana : Intervención de llamadas VOIP
15:30 Comunidad .NET Tijuana : Xamarin (desarrollo multiplataforma con .NET)

Conforme pasó el tiempo fue llegando más gente (después de esa foto fuimos por 20 sillas más). Al final se cumplió uno de los objetivos. Que las personas pudieran conocer a los otros grupos a los que por lo general no pueden asistir. Eso fue algo que me gustó porque todos somos una sola comunidad tecnológica, sin importar las herramientas especificas que a veces utilizamos. Todos podemos aprender de todos.

Con este evento pude darme cuenta que hay más gente (además de quienes participan mes con mes) que les gustaría asistir a las reuniones de la comunidad; pero que por motivos de horario y/o distancia (había gente fuera de Tijuana) no logran asistir. Este tipo de eventos les da la posibilidad de participar en la comunidad. Algo a tomar en cuenta es que al ser un evento que reúne a varios grupos, es difícil tratar temas de nivel intermedio o avanzado. Por lo que se llegó a la conclusión de seguir con las reuniones mensuales por separado y una vez cada ciertos meses realizar la reunión en conjunto.

Aunque la mayoría de la promoción se realizó con el evento en Facebook, las fotos del evento se publicaron en Google+. Échenles un vistazo y nos vemos en el siguiente inter-comunidades Tijuana.

Sobre arquitectura en capas – parte 2

Mario H. Cornejo — Fri, 02 Aug 2013 13:33:00 +0000

Desde hace algún tiempo, cuando un proyecto necesita acceder a una base de datos relacional, lo común es utilizar un ORM. El ORM se encarga de realizar la conversión desde objetos/colecciones en el lenguaje de OOP a registros/tablas en el modelo relacional y viceversa. En otros proyectos se ha optado incluso por usar una base de datos no relacional (NoSQL), donde no es siquiera necesario el mapeo entre clases y tablas. El uso de estas herramientas (ya sea ORM o NoSQL) nos ayuda a trabajar en un nivel más alto de abstracción. Ya no vemos SQL directamente, ahora trabajamos con objetos (entidades) como nuestros datos.

Si seguimos con el ejemplo del artículo anterior, donde se nos pide que un usuario pueda ingresar a un sistema usando su nombre y contraseña. Al usar herramientas como EntityFramework (un ORM) podemos cambiar nuestra capa de acceso a datos.La cual pudiera usar EF para realizar las consultas y actualizaciones. De esta forma no necesitamos escribir SQL y seguimos con nuestra misma arquitectura en 3 capas. Quedando el código algo así:

public User FindByUsername(string username)
{
  var db = new MySampleAppContext();
  return db.Users.SingleOrDefault(user => user.Username == username);
}

Pero nuestro objetivo no es tener 3 capas, ese era solo un medio para un fin. Recordemos para qué tenemos nuestra capa de acceso a datos. La capa de acceso a datos existe para que la capa de reglas de negocios no tenga que ”pensar” en detalles de tablas, registros y SQL. Es la misma razón por la que existen los ORMs, para abstraer el acceso a datos. Entonces… nuestra capa de acceso a datos es una abstracción del ORM que a su vez es una abstracción del acceso a datos, una abstracción redundante. Debemos de limitar nuestras abstracciones por lo que podemos utilizar el ORM directamente en nuestra capa de negocio. De ese modo podemos aprovechar mejor las características de la herramienta y nos ahorramos el trabajo de mantener una capa ya innecesaria. Comparemos el código de la capa de negocios con y sin una capa de acceso a datos.

//con capa de acceso a datos
public bool ValidateUser(string username, string password)
{
    var userRepository =  new Dal.UserRepository();
    var user = userRepository.FindByUsername(username);
    if (user == null) return false;
    var cryptoService = new CryptoService();
    return cryptoService.ComputeHash(password) == username.Password;
}

//Usando ORM en la capa de negocios
public bool ValidateUser(string username, string password)
{
    var db =  new MySampleAppContext();
    var user = db.Users.SingleOrDefault(x => x.Username == username);
    if (user == null) return false;
    var cryptoService = new CryptoService();
    return cryptoService.ComputeHash(password) == username.Password;
}

Podemos ver que el código es muy similar; pero usando EF ya nos ahorramos una capa (un proyecto). Podemos hacer uso de características de EF desde nuestra capa de reglas de negocio (como lazy loading, entre otras) sin tener que tratar de replicarlas en nuestra capa de acceso a datos.

En conclusión podemos decir que ahora, con el uso de herramientas como ORM (o una base de datos no relacional), ya no es necesario crear una capa de acceso a datos porque las herramientas cumplen con el propósito que tenia esa capa. La capa de acceso a datos tenia sentido cuando escribíamos SQL directamente en nuestra aplicación; pero ya no.

Artículo relacionado: Sobre arquitectura en capas – parte 1

Octavo Super Happy Dev House Tijuana

Mario H. Cornejo — Tue, 30 Jul 2013 11:14:00 +0000

El pasado Sábado 27 de Abril asistí al octavo SHDHTJ en las instalaciones de MindHub. Inicio a las 9 am aunque hubo quienes llegaron desde antes. Después de que llegó algo de gente se hizo una presentación sencilla por parte de Gabriel Flores sobre de lo que se trata el evento. Hubo caras nuevas y algunas ya conocidas.

Una buena noticia que nos dieron al iniciar el evento fue que MindHub, por el gusto de haberlos elegido como sede del evento (sus palabras), nos quisieron regalar las pizzas para los asistentes. Lo cual fue un buen detalle que fue bien recibido. Además los asistentes cooperaron con sodas, cervezas, vino, queso y botanas. También Octavio Álvarez llegó con lo que había quedado del code retreat que había sido una semana antes.

En esta ocasión hubo menos interrupciones externas, por lo que tuvimos más oportunidad de trabajar en el proyecto que teníamos en mente. Trabajé haciendo pair programming con Gabo en lo que pretendemos será el nuevo sitio para la Comunidad .Net Tijuana. La idea es trabajar con algo nuevo y ligero como WebMatrix que es algo que no utilizo.

(Foto por Gabriel Flores)

Hubo buenas platicas en el transcurso del día y conocí a gente nueva. Al final no hubo presentación de proyectos como la edición pasada pero sí platicamos sobre ellos. Algo nuevo para mi en este tipos de eventos fue que, en lugar de programar con cerveza y papás fritas, ahora lo hicimos con vino tinto, queso, tomates secos y pitas (cortesía de Javier Aguilar). Ahora no podrá faltar el vino en los siguientes SHDHTJ.

Fue una experiencia muy agradable, al final del día había ganas de seguirle en un after party.

Sobre arquitectura en capas – Parte 1

Mario H. Cornejo — Fri, 26 Jul 2013 14:13:00 +0000

Aun veo proyectos que separan los componentes de la aplicación en capas, utilizando el viejo modelo de 3 capas, el cual siento que ya no es la mejor opción ya que la forma de desarrollar software ha cambiado. En esta serie de artículos pretendo explicar porque ya no es necesaria una separación en 3 capas al momento de desarrollar un nuevo proyecto de software.

Primero debo empezar por definir qué es es la arquitectura en capas para mi, así que esta primera parte trata sobre eso.

¿Qué es la arquitectura en capas?

La arquitectura en capas consiste en separar las responsabilidades de nuestra aplicación de una manera horizontal. Esto se hace con la intención de elevar el nivel de abstracción. Ocultar la plomería de la aplicación poniendo una capa de abstracciones sobre ella. Las típicas capas de esta arquitectura, iniciando de abajo hacia arriba, se describen a continuación.

Capa de acceso a datos (también conocida como DAL por sus siglas en ingles): Es donde se escribe el código que habla con la base de datos. Es en esta capa donde se definen las consultas a la base de datos (el SQL). No realiza validaciones entre entidades, sólo las validaciones que van hacia la base de datos. La intención de esta capa es que el resto de la aplicación no se preocupe de los detalles (en cierta medida) de la estructura de la base de datos y trabaje a un nivel de objetos. Es la encargada de la entrada y salida de datos hacia y desde la base de datos. Ya que no debe de preocuparse de las reglas de negocio el código de la capa debería de ser fácil de seguir y de mantener. Las capas construidas encima de esta (es decir que usen esta capa) deben de dejar de pensar en tablas y registros para pensar en objetos y colecciones.

Capa de reglas de negocio (BL): Una vez que tenemos la abstracción de la capa de acceso a datos, sobre ella se construye una capa. En esta capa es donde se escriben las reglas de negocio, validaciones que involucran varias entidades, validación de estados y condiciones definidas en los requerimientos. Usa a la capa de acceso a datos para realizar las consultas y actualizaciones a la base de datos. La capa de negocio no sabe cómo es presentada la información al usuario o de cómo fue capturada por él. Al no preocuparse de como se presenta la información (UI) o de como es que se almacena (DAL), en el código solo deben observarse que las reglas (de negocio) definidas en los requerimientos se cumplan.

Capa de presentación (UI): Lo que el usuario ve. Es la capa donde se crean los componentes de la interfaz de usuario. Esta capa utiliza a la capa de negocio para realizar la tarea que el usuario requiera. La capa de negocio validará y regresará el resultado o error y la capa de presentación los mostrará al usuario. Entonces el código en esta capa sólo se encarga de pasar valores a la capa de negocio y de desplegar información, en la interfaz de usuario, que viene de la capa de negocio.

Hagamos un ejemplo para entender mejor a que se refiere cada capa. Supongamos que se nos pide que en la aplicación que estamos desarrollando un usuario pueda ingresar al sistema con un nombre de usuario (username) y contraseña validos. Separando nuestra aplicación en capas como las definidas anteriormente tendríamos las siguientes clases (en C#).

Primero la capa de acceso a datos

namespace Dal
{
  public class UserRepository
  {
    public User FindByUsername(string username)
    {
      User user = null;
      var sql = "SELECT * FROM User WHERE Username = @Username";
      using(var connection = new SqlConnection(Config.ConnectionString)){
        var cmd = new SqlCommand(sql, connection);
        cmd.Parameters.AddWithValue("@Username", username);
        connection.Open();
        using(var reader = cmd.ExecuteReader())
        {          
              user = reader.read() ? 
                 new User(username, reader["password"]) : null;
        }
        return user;
      }
    }
  }
}

Ahora la capa de reglas de negocio:

namespace BL
{
  public class UsersService
  {
    public bool ValidateUser(string username, string password)
    {
      var userRepository =  new UserRepository();
      var user = userRepository.FindByUsername(username);
      if (user == null) return false;
      var cryptoService = new CryptoService();
      return cryptoService.ComputeHash(password) == username.Password;
    }
  }
}

Por último la capa de presentación:

...
void LoginButton_Click(object sender, EventArgs e)
{
   var usersService = new UsersService();
   if (usersService.ValidateUser(usernameTextbox.Text, passwordTextbox.Text))   
       MessageBox.Show("Bienvenido");
   else
       MessageBox.Show("Usuario o contraseña incorrectos");
}
...

Aquí puede verse la separación de la lógica en capas. En lugar de hacer la consulta a la base de datos directamente en el método de clic del botón, la capa de presentación delega la validación del usuario a la capa de negocio. La capa de negocio a su vez delega a la capa de acceso a datos la creación y ejecución de las consultas en SQL sobre la base de datos.

Así era como desarrollábamos una aplicación hace años; pero ya no.

Artículo relacionado: Sobre arquitectura en capas – parte 2

Un recorrido por la industria del software

Martín Salías — Wed, 03 Jul 2013 11:56:00 +0000

Durante el evento “Proyectos con menos riesgo y más compromiso” realizado junto a Universidad de Palermo el 27 de junio, estuvimos conversando acerca de proyectos ágiles (¡y otros no tanto!).

En ese marco tuvimos el privilegio de escuchar a nuestro amigo Esteban Di Tada, responsable de Investigación y Desarrollo+Innovación en UP, quien compartió con nosotros sus experiencias personales.

Esteban tuvo su primer contacto con una computadora a comienzos de la década del 60, cuando pasó de usar reglas de cálculo a computadoras con procesos batch.

Luego aparecieron las terminales y comenzó lo que se dio en llamar “la crisis del software”, hasta llegar al punto de detectarse que sólo un 2% de los proyectos generaban valor. Después en la década del 90 todo cambió muchísimo cuando los usuarios comenzaron a utilizar PCs en oficinas y desde sus casas, con un nivel de exigencia mucho más alto y sin conocimientos técnicos. Finalmente, llegamos al día de hoy donde es posible alquilar un auto o realizar transacciones bancarias desde nuestros teléfonos móviles.

Lo más destacable fueron los motivos por los cuales los proyectos muy grandes (“elefantiásicos”) dejan de tener sentido: velocidad e incertidumbre mayores, cambios rápidos en los requerimientos y la tecnología, concluyendo en la necesidad de que busquemos trabajar con los conceptos de Calidad Total y centrados en las Personas.

Así, en pocos minutos, Esteban nos hizo recorrer una vez más la historia de nuestra industria desde sus albores hasta nuestra actualizadas de computación ubicua, haciéndonos entender de paso la evolución de las metodologías y paradigmas.

¡Gracias, Esteban!

Rosario siempre estuvo cerca… de la arquitectura

Martín Salías — Sun, 23 Jun 2013 22:30:00 +0000

Desde que tengo memoria Rosario es una ciudad que me entusiasma. Estaba cerca de Pergamino, donde pasé gran parte de mi niñez, y por eso mucha gente cerca mío estudió allá, si no venía a Buenos Aires.

Y muchos años después seguí haciendo amigos por allá dentro de la industria del software, donde me muevo principalmente.

Notablemente también, Rosario es la ciudad de Argentina donde más actividades realicé relacionadas con Arquitectura de Software, desde algunas charlas (como la que compartimos con Johnny Halife años atrás) y participación en proyectos, hasta las Jornadas de Arquitectura de Software que iniciamos con el MUG, y que hasta ahora sólo se realizaron en Rosario dos veces y en Buenos Aires una sola (planeamos realizar la de este año en unos meses).

La segunda edición de la JAS del MUG fue casualmente hace un par de semanas en Rosario, y pude compartir el salón de la UTN con varios amigos:

Matías Toro y Andrés Joaquín hablaron sobre testing de performance en aplicaciones web
Sebastián Rocco, que habló sobre los Principios SOLID (su presentación aquí)
Pablo Gimenez Parera, que mostró algunos ejemplos de modelado y validación en Visual Studio, que pueden accederse en su carpeta pública de Dropbox.

Yo volví a presentar una versión actualizada de mi sesión "Arquitectura de Software en el ciclo de vida Agil", que dejo aquí abajo para quienes estén interesados. Al cierre fuimos con varios de los oradores y organizadores a disfrutar unas ricas pizzanesas rosarigasinas.

Los dos días siguientes estuve facilitando un workshop sobre esa misma temática, pero con mucha más práctica y profundidad, organizado por el Polo Tecnológico Rosario.

El temario puede verse en el folleto del Workshop, y pueden ver las fotos en el Album de Google+ que dejé al terminar.

¡Hasta pronto, Rosario!

Los grupos de usuarios son un pasatiempo

Mario H. Cornejo — Tue, 12 Feb 2013 22:48:00 +0000

Uno de los primeros grupos de usuarios que conocí de cerca fue el de la comunidad .net Tijuana. Antes había escuchado del grupo de usuarios de Linux; pero nunca me acerque a ellos. Recuerdo que sentí que era algo en lo que todo desarrollador profesional debería participar. Por eso mismo empecé a asistir a las reuniones mensuales a las que tenia oportunidad y sobre todo a los eventos grandes que la comunidad organizaba.

Por ese mismo tiempo comencé a suscribirme a varios blogs y sitios que trataban sobre el desarrollo de software. Noté que varios de los temas, que trataban en las reuniones de la comunidad, eran presentaciones que ya había conocido a través de esos sitios que seguía. Aun así me gustaba participar en las reuniones e invitaba a colegas a asistir. Me preocupaba que otros sintieran que no les aportaba algo nuevo una presentación que quizás podían ver en línea. Decidí participar dentro de la comunidad presentando, tratando de cambiar las presentaciones de PowerPoint por presentaciones con código. Por lo menos de esa forma verían un ejemplo practico, en código, del tema. Algo distinto a la presentación en línea que pudieran encontrar.

Organizando otros eventos trataba (y aun trato) de atraer a más desarrolladores profesionales para que formen parte de la comunidad. Noté que por más esfuerzos, la respuesta de los profesionales es la misma. Sí hay gente nueva; pero hay mucho profesional que no le importa pertenecer a un grupo de usuarios. Llegué a pensar que lo que necesitaban era conocer el beneficio que es ir a aprender de otros colegas y hacer mejor su trabajo. Una vez que lo vieran iban a asistir.

Me di cuenta que en lugar de buscar la razón por la cual alguien no participa en la comunidad, debía buscar la razón por la que las personas sí participan. Recordé que yo no necesito la comunidad para ser mejor desarrollador. Me gusta asistir aunque el tema ya lo conozca. No voy con la única intención de aprender más. Voy por el gusto de estar ahí conviviendo con personas que tienen el mismo interés por la tecnología.

Hace tiempo a la comunidad de Tijuana .Net Microsoft la apoyaba con regalos. Recuerdo que tenían rifas al final de cada reunión, había un tesorero y toda la cosa. Ahora que he estado más involucrado en la comunidad, noté y supe que Microsoft ya no apoyaba al grupo. Aun así en las reuniones sigue habiendo soda y galletas. Gabriel Flores los lleva, se toma la molestia de ir a comprar con su dinero sólo porque le gusta organizar las reuniones, le gusta la comunidad. No lo hace porque Microsoft le dará premios.

Hace meses inicié el grupo de usuarios de JavaScript y al ser el organizador tengo que pagar el dominio, crear el sitio y pues me toca comprar las sodas. Al principio sentía que no debería de pagarlas yo, que eran las empresas las que debían pagar por esos gastos ya que estábamos dando un servicio a los profesionales. Aunque no es mucho gasto, pensaba que estaba haciendo algo mal por tener que pagar las sodas de mi cartera.

Hasta que entendí que las comunidades son un pasatiempo y como todo pasatiempo cuesta, no se busca beneficio de un hobby, sólo se hace por el gusto de hacerlo. A veces es difícil darse cuenta, ya que se trata de lo mismo que hago en mi trabajo y por eso sentía que no tenia que pagar por hacerlo. Ahora que veo la organización de la comunidad como un pasatiempo (y no necesariamente como algo de beneficio para mi trabajo; aunque me ha ayudado) disfruto más de las reuniones. Los gastos no me pesan porque sé que son para el pasatiempo que disfruto. Entiendo por que algunos desarrolladores profesionales no asisten y nunca asistirán a las reuniones, simplemente es un pasatiempo que no compartimos.

El 2012

Mario H. Cornejo — Mon, 31 Dec 2012 10:02:00 +0000

Como ya va terminar el año, en lugar de escribir predicciones preferí hacer un resumen de las actividades y eventos en los que participé en este 2012.

Super Happy Dev House Tijuana
En Marzo participé en la organización del séptimo SHDH-TJ. Hubo buena asistencia, podríamos decir que el evento fue un éxito.

Hubo varios proyectos usando diferentes tecnologías; pero con algo en común. La mayoría (si no es que todos) eran Web así que tiempo después surgió tijuana.js

tijuana.js
En Abril publiqué el sitio tijuanajs.org. El grupo de usuario de javascript de Tijuana tuvo su primera reunión el último martes de Mayo y así cada ultimo martes de mes hasta Octubre, fueron 6 reuniones en este primer año. Esperamos seguir reuniéndonos en el 2013.

Tijuana.net
Participé como expositor en reuniones de la comunidad .net de Tijuana:

dev3cast
Fue un año más en que participé, junto con Gabriel Flores e invitados, en el dev3cast podcast. Los temas tratados en el 2012 fueron:

CafeScript
Como puede verse, en los primeros episodios del año del dev3cast, hubo varios relacionados con JavaScript. De ahí surgió la idea de crear un podcast dedicado a JavaScript. Se unió Iván González al proyecto y así inicio CafeScript. Los episodios del año fueron:

Google Developers Group (GDG) Tijuana
Fui invitado a participar con el GDG como expositor del tema “Extensiones para Google Chrome”. Fue agradable participar en otras comunidades.

Universidad
El 2012 fue el año en que regresé a la Universidad; pero esta vez no como alumno sino como profesor. Impartiendo 2 Materias (Programación Visual y Desarrollo Web). Me gustó la experiencia, tanto que el siguiente cuatrimestre impartiré una materia más.

Vista
Por último, ya para terminar el año mi vista se canso. Al parecer el pasar mucho tiempo con la vista fija en la laptop (trabajo, proyectos extras, blogs, etc.) fue la causa de que tuviera problemas con uno de mis ojos. Eso provocó que me convirtiera en un “programador 4 ojos”.

Estas fueron algunas de las actividades en las que participé este 2012.

El camino ágil hacia organizaciones más efectivas

Martín Salías — Wed, 10 Oct 2012 23:10:00 +0000

Con mis colegas de Kleer organizamos esta mañana este pequeño evento en la Universidad de Palermo, gracias como siempre al Decano de la Facultad de Ingeniería, Esteban Di Tada.

La idea era compartir algunas ideas y experiencias alrededor de organizaciones adoptando prácticas ágiles a diferente nivel de madurez, también con características diferentes, y charlar un poco sobre el camino que recorrieron.

Como introducción tuve a oportunidad de presentar una introducción a algunos principios teóricos de diferentes áreas, desde matemáticas y cibernética hasta management, que desde diferentes perspectivas soportan las ideas del agilismo,

Dejo para los asistentes las notas de la sesión como prometí, y debajo agrego una lista de bibliografía relacionada.

En Español

Complejidad y Caos, de Carlos Reynoso
Antropologia y Complejidad, de Rafael Perez Taylor
Sistemas Complejos : Perspectivas De Una Teoría General, Germán de la Reza
Modelos o Metáforas, de Carlos Reynoso
Las Cinco Disfunciones De Un Equipo, de Patrick Lencioni
Luchas Por El Poder Dentro De Las Empresas, de Patrick Lencioni

En inglés

Ants, de William Morton Wheeler
Cybernetics, Second Edition: or the Control and Communication in the Animal and the Machine, de Norbert Wienner
Theory of Games and Economic Behavior, de John Von Neumann y otros
Flesh and Machines: How Robots Will Change Us, de Rodney Brooks
The Evolution of Cooperation, de Robert Axelrod
Out of Control: The New Biology of Machines, Social Systems, & the Economic World, de Kevin Kelly
The Fifth Discipline: The Art & Practice of the Learning Organization, de Peter Senge
The Advantage: Why Organizational Health Trumps Everything Else In Business, de Patrick Lencioni
The Five Temptations of a CEO, de Patrick Lencioni

Podría seguir agregando libros, pero creo que estos son las principales fuentes al menos de esta charla en particular.

Les dejo también el video "promocional" que grabamos con Ricardo Colusso invitando al evento. No es la gran cosa, pero nos divertimos produciéndolo, como se imaginarán:

Run WebCamp 2011 en Buenos Aires

Martin Salias — Tue, 15 Mar 2011 19:34:00 +0000

Hoy participé en el Run WebCamp organizado por Microsoft de Argentina, en el barrio de Palermo, Buenos Aires.

Dentro de esta conferencia dedicada a desarrollo web en la plataforma Microsoft, me tocó presentar Entity Framework junto a mi viejo amigo Daniel Laco, con quien a pesar de los años que llevamos en la comunidad de desarrollo, nunca habíamos hecho un dueto.

La verdad es que más allá del resultado final, que el público juzgará, fue un placer dar una sesión con Dani y logramos completar todo el temario, que era bastante exigente, en 45 minutos exactos, con buen timing y sin pisarnos.

Como prometimos durante la charla, quedan aquí los links para descargar la presentación (recortada solo con el material importante y referencias), y los ejemplos, una solución completa con muchos ejemplos en detalle (cortesía de Dani), y una solución mínima mostrando lo básico de Code First (culpa mía).

Me siento halagado de haber participado con otros oradores muy buenos y muchos amigos, como Edu Mangarelli y Miguel Sáez, Phil Haack y Drew Robbins, Rodo Finochietti y Pablo Zaiden, y por supuesto, mis compañeros de ruta Johnny Halife y Mati Woloski.

El evento se emitió en vivo a través de UStream y espero que pronto quede disponible para verlo en video, idealmente con las charlas por separado.

MVP 2011 y objetivos para este año

Martin Salias — Tue, 04 Jan 2011 09:07:00 +0000

Otra vez, como desde hace años ya, arranco el año con la agradable noticia de que Microsoft me ha premiado como Most Valuable Professional. Siempre es un honor la distinción, aunque sigo sin saber muy bien qué es lo que consideran tan valioso en mi.

Nuevamente me premian en la categoría "C#", que por lo visto es algo así como un comodín para actividades mas bien ligadas a los lenguajes.

Como sea, es bueno sentirse reconocido, y un honor cuando uno queda cerca de la categoría de gente a la que admira. Y estas cosas refuerzan esta idea organizativa de fijarse objetivos para el año. Es cierto que es un plazo matemáticamente arbitrario, pero útil a nivel de planificación. Es como un relajado backlog personal que uno puede auto-imponerse para tratar de planificar después el corto plazo, semana tras semana o mes tras mes.

Pero hacer pública una lista de objetivos es una manera de dejar un compromiso más alto que simplemente proponerse algo. Uno sueña con un lector hipotético que algún día vendrá a reclamar si no se cumple nada de lo planeado.

Así, aquí van mis objetivos para el año, que iré atacando, por supuesto, de manera iterativa:

Lenguaje del año: como todos los años, en el 2011 trataré de aprender y comprender un lenguaje nuevo. Para mi comprender un lenguaje de programación significa conocer bastante su idiosincracia, el paradigma con el que está diseñado, sus puntos sobresalientes y problemáticos, y acercarme a la manera en que funciona la comunidad y el ecosistema detrás. Eso implica aprender, hacer katas, programar en ese lenguaje proyectos lo más reales posibles, y tratar de compartir todo lo posible lo aprendido, sobre todo haciendo algunas presentaciones en vivo o en video. Explicando a los demás, como dice el Maestro, es como más fácilmente nos "cae la ficha" y afianzamos nuestros conceptos.

El 2010 lo dediqué a Ruby (aunque personalmente no profundicé tanto como me hubiese gustado), después de zambullirme en F#, volver a Python (para quedarme -hoy lo uso cotidianamente e incluso tengo un shell de Python siempre a mano, dentro de Chrome), jugar con Boo, meterme en C# desde Generics hasta el IL generado, tratar de avanzar con Eiffel, debatirme entre Haskell y ML (sin lograr mucho con ellos por mis propias limitaciones).

A la hora de elegir un lenguaje para este año que inicia, prefiero terminar lo que empecé, y voy a dedicarme más a Ruby, pero esta vez específicamente a Rails y Sinatra, donde no hice tanto hincapié. Mi mayor avance con Ruby el año pasado fue entender el lenguaje mismo y usarlo para todas mis tareas principales de scripting y algunas aplicaciones desktop que necesitaba (si, es raro ver aplicaciones desktop en Ruby, pero se puede). Esta decisión tiene impacto directo en algunos de los siguientes objetivos, como se verá.
Me quedó pendiente, por varios motivos, dar un taller sobre Ruby, que quiero encarar este año. El principal problema fue que las veces que lo propuse lo hice junto a otras alternativas que sonaron más interesantes. Pero como es algo que personalmente quiero hacer, voy a ponerme en campaña por mi lado, y terminaré con alguna serie de videos en mi otro blog, Code & Beyond, y probablemente lo de presencialmente en el MUG o algun otro lado.
Hace tiempo tengo pendiente reconstruir mi sitio personal, que es una recopilación de servicios, links a trabajos, mis libros, películas, etc. Todo eso está armado con un antiquísimo script en Python que genera páginas estáticas ASP. En su momento no fueron HTML plano para poder incluir un par de cosas, pero en realidad son básicamente eso. No hay una base de datos detrás, nada dinámico. Los datos son fuentes diversas en mi máquina que se procesa(ba)n para generar las páginas. Y hace tiempo que no se refresca esa información, salvo lo que proviene de servicios como delicious.

Así que tengo un buen ejercicio a mano: rediseñar el sitio, pensándolo mejor (aunque el objetivo básico seguirá siendo tener consolidada una cantidad de información que está dispersa en la web) y usarlo como una práctica de Rails y también de actualizar mi conocimiento en HTML/CSS, que está algo vetusto.
Otro objetivo, a cumplir en el corto plazo, es actualizar mi hardware. Seguiré con una Mac, pero estoy cambiándola en breve por una de las nuevas MacBook Air, que ya tendrá su propia reseña.

Y en consecuencia con el cambio, también quiero aprender este año Applescript. Hasta ahora todas mis tareas en la Mac las automaticé entre un poco de bash y Ruby, pero hay muchas cosas en las que el scripting nativo de la Mac va ayudarme con seguridad. Además, la gente de Apress me regaló el libro "Learn AppleScript: The Comprehensive Guide to Scripting and Automation on Mac OS X, Third Edition", así que ¡no me quedan excusas!
Finalmente, como todos los años, sigo rumiando los bocetos de un libro (técnico), pero no quiero auto-imponerme una fecha límite para eso, porque todavía no tengo el temario final cerrado en mi cabeza. De alguna manera, Code & Beyond es una especie de lista de notas que me llevan en ese camino.

No es una lista tan grande. Espero llegar con todo terminado bastante antes de fin del año próximo, así que corto aquí y me pongo a trabajar.

Video: Virtual Alt.NET Meeting sobre Cloud Computing

Martin Salias — Wed, 01 Dec 2010 11:49:00 +0000

Hace unas semanas participé en otra reunión virtual de Alt.NET Hispano, hablando un poco sobre Cloud Computing.

Gracias como siempre a Jorge Gamba y el resto del equipo de voluntarios, ya está publicado el video, que dejo embebido aquí abajo, pero recuerden que pueden ver cualquiera de los videos de la reuniones anteriores.

Unable to display content. Adobe Flash is required.

Arquitectura de Software en el Ciclo de Vida Agil

Martin Salias — Mon, 08 Nov 2010 17:20:00 +0000

Durante el mes de octubre tuvimos nuevamente la oportunidad de facilitar nuestro auditorio en Southworks para otro desayuno de arquitectos de los que organiza Microsoft.

Esta vez, a diferencia de los últimos, en que sólo me tocó oficiar de anfitrión, Guada me pidió que presentara, ya que el tema elegido por el grupo tenía que ver con documentación y validación de arquitectura, algo sobre lo que vengo trabajando bastante fuerte, incluyendo el artículo que publicamos al respecto con Diego Fontdevila en el número 23 del Architecture Journal.

Casualmente, la sesión estuvo basada en la que presentamos con Diego en Agiles 2010, un par de semanas antes, en Lima, adaptada ligeramente a este público que tiene un perfil diferente.

Gracias a Julián Scopinaro, la sesión quedó capturada en video, que comparto aquí abajo.

Architects' Breakfast: Architecture in Agile Life Cycle - Part 1 from Southworks Showcase on Vimeo.

Architects' Breakfast: Architecture in Agile Life Cycle - Part 2 from Southworks Showcase on Vimeo.

ConfORMando NHibernate 3 (the day after)

Fabio Maulo — Wed, 03 Nov 2010 14:58:00 +0000

Fue un placer ayer mostrar lo que se puede llegar a hacer con NHibernate 3.0 y alguna otras “cajita feliz”. La verdad es que pensaba que fuese un poco mas desafiante especialmente por el hecho que la mayoría de los asistentes son actualmente usuarios de NHibernate. En dos horas no pudimos ver mucho porque me dejaron hablar demasiado… Tal vez, si lo piden al MUG, podamos hacer otra session del

Code & Beyond: hablando muchos lenguajes, pero en español

Martin Salias — Wed, 03 Nov 2010 11:09:00 +0000

Para quienes han sido fieles lectores de este blog algo abandonado, no podía dejar de invitarlos a seguir mi nueva iniciativa: Code & Beyond.

El objetivo de este blog (que pronto contará con videos además de noticias) es difundir contenido interesante sobre desarrollo de software en cualquier plataforma y lenguaje, inicialmente al menos, apuntando al mercado hispano-parlante.

La idea es algo que venía rondándome hace tiempo, y que se impulsó por una serie de posibilidades y también gracias al soporte y perseverancia de mi amigo Julián Scopinaro, con quien compartimos tareas de comunicación en Southworks.

Hay una breve introducción en el primer post, pero aprovecho este blog, más personal, para exponer porqué me parece importante cubrir el espectro "multi-plataforma":

Por un lado, buena parte de mi carrera la dediqué de una manera u otra a proyectos con problemática fuerte de interoperabilidad, y es una especialidad que me ha sido valiosa y me ha generado muchas oportunidades. Incluso a lo largo de 20 años de relación con Microsoft, ellos mismos me han elegido varias veces para ayudarlos en proyectos que involucraban piezas más allá de su plataforma, y a medida que pasa el tiempo, veo que es cada vez más raro que una solución se pueda diseñar para un entorno homogéneo.

Desde otro ángulo, creo que entender y apreciar otras plataformas nos hace más sólidos y aumenta nuestra capacidad de discernimiento sobre las que estamos usando principalmente en un momento u otro. Desde el punto de vista de la arquitectura de software, por definición no deberíamos permitirnos tomar decisiones con un sesgo específico. Por supuesto, esto no significa que al evaluar alternativas para una solución no consideremos el valor de una plataforma que está más afianzada en la organización, o el equipo domina más. El tema es evitar la decisión por temor o ignorancia (si es que no son al final la misma cosa).

Tal vez el ejercicio y la disciplina que me exige Code & Beyond me haga escribir más frecuentemente en éste y otros blogs. Éste en particular seguirá siendo un punto donde hablar desde una perspectiva más personal, o compartir material o contenido de actividades mías no relacionadas directamente con el otro.

ConfORMando NHibernate 3

Fabio Maulo — Fri, 15 Oct 2010 16:07:00 +0000

El dia 2 de Noviembre estaré presenciando una charla en el auditorium del MUG (Microsoft Users Group) de Buenos Aires, Rivadavia 1479 1º A. Ver mapa más grande La intencción es la de mostrar un uso “distinto” de NHibernate. Para asistir no se necesita ninguna experiencia previa con NHibernate y si nunca lo han usado verán cuan simple es su uso. Si ya están usando NHibernate, aunque sea

Presentando Southworks Professional Improvement Program

Martin Salias — Fri, 14 May 2010 16:54:00 +0000

Muchos de ustedes ya habrán leído sobre el proyecto Hogwarts en el blog del Maestro.

La motivación de este proyecto es aportar a la comunidad las prácticas de desarrollo de software que creemos fundamentales en Southworks, y que consistentemente vemos ignoradas o utilizadas parcialmente.

Esto cubre un abanico de metodologías, técnicas y espacios conceptuales bastante amplio, dentro de los cuales arrancamos con un primer curso cubriendo estos temas:

Test-Driven Development
Inversión de Control e Inyección de Dependencias
Mocking
Principios SOLID
Ejercicios generales utilizando todas la técnicas

Para cada uno de estos temas tenemos un conjunto de presentaciones, material de soporte para el instructor, proyectos de ejemplo con complejidad creciente y ejercicios de distinta dificultad incluyendo algunas soluciones de referencia.

También tenemos prevista la evaluación posterior a cada curso sobre los resultados de los ejercicios y una serie de preguntas para verificar los conceptos teóricos.

Nuestro plan inicial se enfocaba principalmente en generar todo este contenido para ejecutar clases presenciales, pero siempre pensamos en compartir en línea una buena parte para llegar a personas interesadas que no podemos alcanzar físicamente.

Sin embargo, la recepción que ha tenido lo que publicó Angel hasta ahora (por ejemplo el primer y segundo videos), nos impulsó a acelerar el avance de la faceta en línea del proyecto. El resultado es que estamos muy cerca de abrir a la comunidad el proyecto, basado en la plataforma de entrenamiento Moodle, funcionando por supuesto desde nuestra infraestructura en la nube.

Por supuesto, no descuidaremos la interacción cara a cara. La diferencia es que las sesiones presenciales serán complementarias al contenido en línea, para despejar dudas y realizar prácticas en conjunto. Y obviamente no sólo estarán a cargo y cerca nuestro. Esperamos que diversos grupos puedan replicarlas en forma local.

Interesados: permanecer atentos a este blog y el de Angel. La semana próxima deberíamos estar publicando el sitio final del proyecto. Hogwarts es el nombre de código del proyecto (otra práctica recomendable), pero el nombre oficial, que estamos presentando en sociedad es el del título:

Southworks Professional Improvement Program

CloudCamp Buenos Aires

Martin Salias — Wed, 12 May 2010 18:12:00 +0000

El 7 de mayo, la semana pasada, tuvimos la oportunidad de presentar en nuestras oficinas de Southworks el primer CloudCamp en Buenos Aires.

El evento salió muy bien, desde mi punto de vista y por el feedback de la gente, y esperamos compartir muy pronto algunos videos grabados durante el evento.

Tuvimos la presencia de uno de los fundadores del CloudCamp, Dave Nielsen.

Dave realizó la apertura del evento, explicando la estructura y la mecánica del evento, que contó con presentaciones relámpago (de 5 minutos) de cada uno de los sponsors: Microsoft, Southworks y Globant.

Luego de estas presentaciones pasamos al Unpanel (un anti-panel), con expertos que se propusieron como voluntarios en el momento mismo y contestaron a las preguntas de los asistentes.

El trío de expertos quedó conformado por:

Matías Bagini de JRapid (y organizador del Amazon User Group de Argentina)
Scott Densmore de Microsoft patterns & practices (en la foto junto a él, Eugenio Pace, también de p&p, haciendo de intérprete).
Johnny Halife de Southworks

A ellos se sumó parcialmente Dave en algunas respuestas del público, y de muchas de las preguntas se perfilaron los temas para las sesiones de los Open Spaces posteriores, a las que se sumaron algunas propuestas que el público votó en el momento.

Los temas que quedaron fueron:

Private clouds
Migrando aplicaciones a Windows Azure
NoSQL (y otros patrones de acceso a datos)
Seguridad en la nube
Google App Engine

En la foto aparecemos quienes quedamos a cargo de los temas, aunque en general se trató de discusiones participativas. De izquierda a derecha, Beto Ortega (Southworks), Scott Densmore (Microsoft), Fabio Maulo (NHibernate), yo (Southworks) y Pablo Francavilla (GetSense).

Quiero agradecer especialmente a Julián Scopinaro por su trabajo impecable coordinando todas la actividades necesarias para que el evento haya salido perfecto, a Mariano "Pocho" Szklanny por sus fotos (las de este post son apenas una muestra), y a nuestro cameraman exclusivo, Guido Maliandi, quien capturó en video la mayor parte del evento, para que pronto podamos compartirlo con el resto del mundo.

Video de mi VAN sobre Automatización

Martin Salias — Tue, 02 Feb 2010 13:44:00 +0000

Gracias nuevamente a los amigos de Alt.NET Hispano, y sobre todo a Fernando Claverino, quien se tomó el trabajo de redactar el resumen disponible en la Wiki del grupo, si quieren ahorrar una hora y media, que es lo que dura el video.

MVP otra vez

Martin Salias — Thu, 07 Jan 2010 13:34:00 +0000

Ya se me hizo costumbre, como sucede desde 2002, empezar el año con el mensaje de felicitación anunciando el premio MVP.

Como siempre, la sensación es de cierto orgullo y un poco de perplejidad porque no me parece que mi contribución sea tan grande, sobre todo comparándola con la de otros MVP alrededor del mundo a los que admiro.

Pero en fin, sigo en la musical categoría de C#, supongo que porque es el paraguas en el que agrupan a quienes estamos alrededor de otros lenguajes que no tienen aún su propia categoría (tal vez por ser aún más proyectos que productos completos).

Como todos los años, espero dedicarme principalmente a aprender más sobre otro lenguaje. La década pasada la dediqué con mayor o menor profundidad a Eiffel, C# mismo, ML, Boo (poco), Python (después de años de mis primeros contactos), el 2009 me concentré en F#, y este pienso dedicarlo seriamente a Ruby.

La decisión tiene que ver con dos hechos principales: uno es tener cerca un fanático de Ruby como Johnny Halife, y por otro lado el hecho de que la implementación de Ruby en .NET, IronRuby, haya llegado al RC1 (primer Release Candidate, lo que significa que está muy cerca de la versión final).

Por esto, sería de esperar (y aquí tomo un compromiso personal que espero poder cumplir) que este año publique unos cuantos post y de algunas charlas sobre Ruby (la versión multiplataforma, basada en C) y sobre IronRuby (la versión basada en el DLR), y la interoperabilidad entre ambas.