Categoría: opinion

Visual Studio 2013, esas cosas tan típicas de Microsoft

La semana pasada empecé a trabajar en un nuevo proyecto. Algo en teoría simple, un sitio web de tipo «informativo», en el sentido que tiene mucha información y muy poca lógica de negocio. El líder técnico del cliente decidió que lo hicieramos con ASP.NET MVC 4, corriendo sobre .Net 4.5 y utilizando Visual Studio 2013 como entorno de desarrollo.

Cómo era de esperar a la hora de instalar Visual Studio 2013 me encontré con varias cuestiones que podrían resultar difíciles de creer para muchos desarrolladores, pero que no sorprenden a nadie que haya trabajado con tecnología Microsoft por un par de años.

La primera cuestión llamativa fue que apenas ejecuté el instalador, me encontré con un mensaje indicando que la aplicación a instalar (VS2013) no era compatible con mi sistema operativo (Windows 7). Me ví obligado a instalar el Service Pack 1 de Windows 7.

Una vez instalado el SP1, volví a ejecutar el instalador y me encontré con un mensaje que me indicaba que la instalación requeriría ~9 GB, si si, NUEVE GIGABYTES. Lo curioso es que yo estaba intentando instalar esta aplicación en una máquina virtual cuyo peso en ese momento era de unos 8 GB.
Como me costaba resignarme a que mi máquina virtual creciera tanto, hice una instalación personalizada en la que removí ciertos componentes que no eran de mi interés y logré bajar de 9 GB a 7 GB.

Continuando con la instalación, me encontré con otro mensaje que me indicaba que mi máquina no contaba con Internet Explorer 10 y que ello podría ocasionar que algunas funcionalidades de Visual Studio no estuvieran disponibles. Así que suspendí la instalación de Visual Studio e instalé la nueva versión de Internet Explorer.

Finalmente pude completar la instalación de Visual Studio 2013.

ASP.NET: WebForms and MVC Side by Side

This is the situation I am facing:

I have a WebForms application that has been running for years. It was initially built with VS2008 (net 3), then was updated to VS2010 (net 4) and was recently updated to VS2012 (net 4.5).

The client has decided to redesign the UI of some pages. He hired a group of designers that produced a very cool set of new pages based on HTML5 and CSS. Now I need to take that HTML and CSS and adjust the webforms application. As you can imagine this can be a really hard work, because among other things, the webforms application uses several non-standart asp.net webcontrols.

So, what I would like to do is to implement these new pages using ASP.NET MVC. I did some googling and it seems it is possible to have WebForms and MVC living side by side in the same application. But before going further I would like to hear some opinions.

Sobre herramientas de gestión: Pizarra vs. Software

Ayer tuve una interesante charla sobre este tema. Uno de los participantes se inclinaba fervientemente por el uso de herramientas físicas: pizarra y post-its. Yo en cambio me inclino más hacia el uso de herramientas de  software, tal vez sea porque no soy muy amigo del papel o tal vez sea que tengo algunos motivos más profundos y menos subjetivos como ser:

  • El uso de pizarra y post-its tiene como positivo que es un irradiador natural de información y con un simple vistazo uno puede ver el estado. Sin embargo, esto ya no es algo exclusivo de las pizarras. Hoy en día existen diversas herramientas de software que «emulan» una estética/experiencia similar a los post-its y que combinadas con un monitor grande dedicado (o directamente un televisor) permiten disfrutar de este beneficio de la irradiación de información. Personalmente he trabajado con herramientas de software como Trello, Mingle y Pivotal, con muy buenos resultados.
  • El uso de post-its hace más compleja la obtención de métricas, ya sea porque las mismas deben calcularse a mano o bien porque la información que está en post-its debe replicarse en alguna herramienta software para el cálculo de las métricas.
  • Si tu organización requiere algún tipo de trazabilidad o un historial de items es muy posible que ya estés obligado a usar una herramienta de software.
  • Finalmente está la cuestión de la distribución del equipo, hoy en día es cada vez más común tener gente distribuida físicamente, lo cual dificulta el uso de herramientas físicas. Ojo, no digo que no puedan usarse, sino que su uso en un contexto así puede llegar a requerir de trabajo adicional.

Claro que si tu equipo no está distribuido y no usas métricas en tu proyecto puede que resulte más práctico usar una pizarra.
Más allá de esto, debo reconocer que hay cierta «mística» o «ritual» en el uso de post-its, que en ciertos contextos puede resultar motivador para los equipos.

Un proyectito en PHP

En los inicios de mi carrera hice algunas cosillas con Php motivado por un curso de Php que había tomando en el Club de Programadores y cuyo instructor había sido el maestro AJ Lopez.

Hace un tiempo volví a poner mis manos en Php y me encontré con varios cambios, algunos de los cuales había escuchado pero no había tenido la oportunidad de experimentarlos.

Mi percepción es que el lenguaje ha evolucionado bastante, incorporando diversas construcciones y soporte para programación orientada a objetos.

Por otro lado veo un gran ecosistema de herramientas y frameworks que le han permitido mantenerse como uno de los principales jugadores en el ámbito del desarrollo web a pesar del gran avance de Ruby y Python.

Al mismo tiempo noto que a diferencia de lo que ocurre en Ruby y Java, la comunidad no estan del todo «alineada», hay cuestiones que no parecen estar estandarizadas y otras que a pesar de parecer estandarizadas son ignoradas por gran parte de los practicantes.

En mi caso particular resulta que desde comienzo de año venía trabajando en una organización en una iniciativa de Continuous Delivery y llegado un punto necesitamos de una herramienta para secuenciar los pedidos de despliegue a cada ambiente. Por diversas cuestiones esta organización decidió construir esta herramienta con Php usando el framework Silex. Luego de una primera versión, fue necesario realizar algunas modificaciones y agregar nuevas funcionalidades y por cuestiones de disponibilidad de tiempo, fui yo el encargado de estas cuestiones. Esta organización ha manifestado la intención de liberar está herramienta con licencia open source, por ello es posible que en breve les traiga más noticias.

Continuará…

Firefox, mi navegador de desarrollo

Desde hace ya años uso un navegador para hacer desarrollo y otro para todo lo demás.  Esto se debe a que en mi navegador de desarrollo suelo estar probando plugins de forma relativamente frecuente lo cual podría llegar a «romper» el navegador o a impactar negativamente en el comportamiento de una alguna aplicación web.

Como navegador de desarrollo uso FireFox, pues tiene una importante cantidad de plugins que me resultan muy útiles para el desarrollo web entre las cuales se cuentan SeleniumIDE, FireBug, YSlow, HttpFox y ScreenShooter.

Por otro lado, uso Chrome para todo lo demás que no es desarrollo pues me resulta muy cómoda la forma en que se integra con los servicios de Google que uso de forma cotidiana.

Un detalle adicional que no es menor, es el que hecho de que FireFox se mantiene en cierto modo «más limpio/neutro» que Chrome, ya que este último incluye cada vez más extensión particulares para integración con los servicios de Google, algo que puede ser útil para el usuario final, pero que como desarrollador comienza a hacerme un poco de ruido.

Un pizca de mundo real en la academia

Continuando con lo planteado en el post «La universidad me mintió» quiero compartir algunos casos de materias en las que se pone al alumno en situación bastante similares a las del mundo real.

Comienzo con algunos casos que me involucran.

Elementos de Ingeniería de Software, Universidad Nacional de Quilmes

Las últimas 5 semanas de la materia, los alumnos trabajan en equipos de dos personas en la construcción de un producto, organizados en iteraciones semanales y utilizando prácticas de Scrum y XP. En la cuarta iteración los hacemos rotar de manera que trabajen en el producto de equipo.

Algoritmos y programación 3, Universidad de Buenos Aires

El trabajo final de la materia suele ser la construcción de un video juego utilizando POO y Java. De cara a simplificar las complejidades de la construcción de la interface de usuario y el manejo de threads, hemos construido un mini-framework que se encarga de estas cuestiones y permite que los alumnos se enfoquen mejor en la construcción del modelo de objetos de dominio. Este mini-framework está intencionalmente incompleto y carece de cietos puntos de extensibilidad (también intencionalmente) lo cual en cierto modo obliga a los alumnos a leer el código del micro framework y modificarlo.

Taller de Programación 2, Universidad de Buenos Aires

Según comentó Dario en el post inicial, en la materia Taller de Programación 2, de la carrera de Ingeniería Informática de la Universidad de Buenos Aires, los alumnos deben trabajar sobre código heredado. Festejo esto, pues cuando yo cursé esa materia no dinámica no era esa, sino que trabajamos directamente sobre «código nuevo».

Práctica de desarrollo software, Universidad Nacional de Quilmes

Por otro lado Javí comentó que en la materia Práctica del Desarrollo de software, de la Licenciatura en Desarrollo de Software de la Universidad Nacional de Quilmes tiene la idea de trabajar sobre un producto/servicio a lo largo de los varios cuatrimestres.

Algunos otros

Más allá de estos 4 casos, he oído de algunas iniciativas en esta dirección en la Universidad Nacional de Tres de Febrero y en la Universidad Nacional de La Matanza, pero no tengo detalles suficientes como para compartir.

Impresiones de la RubyConfAR 2013

La semana pasada participé por primera vez de la RubyConf. Los comentarios que recibí de algunos colegas sobre las ediciones anteriores me entusiasmaron mucho y por ello decidí anotarme.

Para quienes nunca han asistido comienzo describiendo el formato de la conferencia. La conferencia en sí son 2 días a los que se le suma un preludio denominado «Ruby Fun Day» en el que se dictan charlas/talleres introductorios a Ruby. Lamentablemente no pude asistir al fun day, pero de todas formas no creo que me hubiera aportado mucho, ya que tengo bastante experiencia trabajando con Ruby. Adicionalmente también suele haber alguna actividad social fuera del horario de la conferencia.

La conferencia en sí es un track único con sesiones de 30 minutos organizadas en bloques, donde cada bloque es: sesión 1 + sesión 2 + coffee break. Al mismo tiempo las sesiones suelen ser en forma de exposición, a diferencia de los eventos de agile, donde hay sesiones tipo workshop o tipo debate. Creo que justamente por estar acostumbrado a las conferencias agile, este formato me resultó  un poco pesado.

Respecto de las sesiones, me llamó la atención que más de una se enfocó en otros lenguajes (recuerdo una sesión sobre Go y otra sobre Erlang). Entre las sesiones que me resultaron más interesantes estuvieron:

  • La de @abecciu de Restorando sobre cómo resolvieron ciertas cuestiones de recolección de datos
  • La @runixo sobre IPython Notebook
  • La de @cristianrasch sobre Rack
  • La de @xymbol sobre Ruby & Unix
  • La de @kurko sobre orientación a objetos

Más allá de esto, hubo otras dos sesiones que más que interesantes yo las calificaría como muy entretenidas, en gran parte por el carisma de sus oradores. Esas sesiones fueron las de @ajlopez sobre su implementación de Ruby con C# y la de @janogonzalez sobre la bipolaridad de los programadores.

Cliente no es un buen término

Es común al trabajar en proyectos hablar de «el cliente» como un rol. Yo mismo lo hago todo el tiempo, pero no me parece apropiado y tengo algunos argumentos al respecto.

Desde el punto de vista humano me parece muy frió: «el cliente y el proveedor», siento que genera un división muy fuerte y que en cierto modo denota un conflicto de intereses. Personalmente me  gusta ver a mis clientes como socios, pues al fin y al cabo ambos sabemos que para lograr un proyecto realmente exitoso tenemos que lograr una situación ganar-ganar.

Desde el punto de vista técnico el término cliente me resulta ambiguo. ¿quien es el cliente? ¿es quien paga por el proyecto? ¿o es quien conoce los detalles de la problemática a resolver?  Para evitar este tipo de ambigüedades es que prefiero utilizar otros términos más específicos, sobre todo al comienzo de los proyecto para dejar bien en claro las responsabilidades de cada involucrado.

En primer lugar todo proyecto tiene un sponsor que es quien está pagando por el proyecto y que también suele representar la parte política del proyecto frente al resto de la organización.

Por otro lado tenemos al experto de negocio que es quien tiene el conocimiento de la problemática a resolver.

Finalmente tenemos al usuario que es quien utilizará la solución de software provista.

Puede que estos tres roles terminen ocupados por la misma persona o no, eso suele depender del contexto del proyecto. En mi experiencia, en organizaciones grandes es muy común que estos roles sean ocupados por distintas personas. Tomando como ejemplo el caso de la petrolera que compartí hace un tiempo, el gerente general ocupaba el rol de sponsor, el responsable de compras era el experto de negocio y los analistas del área de compras eran los usuarios.

La universidad me mintió

Durante toda la carrera me hicieron trabajar sobre «proyectos nuevos» en el sentido que siempre puse la primera línea de código. Al mismo tiempo, los proyectos terminaban cuando aprobaba la materia y el código nunca más era tocado por nadie más, más allá de mi y mis compañeros de grupo.

Estas situaciones llevadas al «mundo real» resultan ser ficticias, rara vez escribimos código para que nunca más sea tocado. Y al mismo tiempo muchas veces nos toca trabajar sobre código ya existen que ha sido desarrollado por alguien más, a quien tal vez nunca conozcamos y que podria incluso vivir al otro lado del globo.

Lo triste es que esto es moneda común en los ámbitos académicos. Son contados los casos en los que los alumnos tienen que trabajar sobre código existente. Ojo, no me refiero a trabajar con librerías, algo que sí es común, sino a trabajar sobre código fuente de un aplicación desarrollada por alguien más. También resulta poco común que el código escrito por un grupo de alumnos, tenga «vida» más allá de la aprobación del trabajo.

Pasando en limpio:

  • En la academia los alumnos trabajan sobre proyectos/productos empezando de cero.
    Pero en la industria muchas veces nos toca trabajar sobre proyectos/producto ya existentes.
  • En la academia los alumnos trabajan sobre productos durante un período «corto» de tiempo y una vez completado el alcance originalmente acordado no vuelven a tocarlo.
    Pero en la industria los productos evolucionan y luego de su versión inicial son modificados cientos/miles de veces a lo largo de su vida útil.

Con este planteo lo que quiero decir es que es necesario que la academia tome conciencia de esta situación y haga algo al respecto. Conozco algunas iniciativas que ya están trabajando en esta línea, pero eso será parte de otro artículo.

Continuará…

La satisfacción de la inquietud

La semana pasada en el contexto del trabajo final de Algo3 dimos la clase de MVC de cara a que los alumnos puedan empezar a trabajar en la parte de vista y controlador.  A los poco días recibí un mail de un alumno de uno de mis grupos con la siguiente consulta:

Queríamos consultarle si hay alguna forma apropiada de hacer testing para la parte de vista del proyecto, ya que desde que nos pusimos a trabajar con la misma la cobertura de código del proyecto bajó notablemente.

Sinceramente la consulta me sorprendió para bien y me causó una gran satisfacción ver que un alumno tenga este tipo de inquietudes ya desde los primeros años de la carrera.