miércoles, noviembre 19, 2008

PDC 08 en BA

Ayer, la gente de Microsoft ofreció un interesante evento en Buenos Aires para contarnos a los desarrolladores porteños las novedades anunciadas hace dos semanas en el Professional Developer's Conference, realizado en Los Ángeles.

Con una buena selección de speakers -la mayoría de los cuales habían asistido al PDC original- las sesiones fueron interesantes, y cubrieron muy bien el abanico de cosas que están preparando los Microsofties.

El tema que sobrevoló todo el encuentro es .... (fanfarrias)... computación en la nube o cloud computing. Quizás algunos de ustedes ya hayan escuchado algo sobre este tema que, como su nombre lo indica, está un poco difuso (si me disculpan la asociación obvia). La idea general de la nube es ofrecer una plataforma omnipresente para la ejecución de aplicaciones y almacenamiento de datos. Así, los desarrolladores no tienen que preocuparse de cuestiones de infraestructura de bajo nivel (servidores, memoria, almacenamiento) y pueden concentrarse en resolver problemas concretos a través de aplicaciones y servicios que serán hosteados en algún lugar de la nube. Por otro lado, los usuarios de esas aplicaciones pueden disponer de ellas en cualquier dispositivo, ya sea una PC, laptop o cualquier tipo de dispositivo móvil.

El puntapié inicial en esta tendencia lo dio Google, con sus ya clásicas Google Apps, Maps, Docs y demás. Pues bien, parece que el gigante de la gran M -si bien quizás no maneja el timón innovador de esta era- no está muerto y va a dar pelea compitiendo con sus propias soluciones y plataformas.

En este plan, Microsoft viene desenvolviendo su plataforma Windows Azure, que es, según definieron ayer, "un sistema operativo en la nube". La solución Cloud Computing de Microsoft está soportada por un gran datacenter (en realidad varios) interconectados que respaldará una plataforma de servicios online para hostear y administrar aplicaciones y datos. Todo esto desarrollado sobre Windows Server y .Net y muy bien integrado con herramientas de desarrollo como Visual Studio, lo cual es una buena noticia para los desarrolladores de la galaxia MS (entre los cuales me cuento). Con esta plataforma, una empresa puede tener sus sistemas corriendo en Azure sin preocuparse por el hardware, datos, backups, actualizaciones de software base, alimentación ininterrumpida, etc, confiando todo esto a los amigos de Redmond. Una de las ventajas que mencionaban allí es la escalabilidad instantánea de las soluciones. Por ejemplo, un pequeño negocio que tiene un sitio modesto con pocas visitas diarias quiere ofrecer una promoción masiva, que seguramente impactará en la disponibilidad de su sitio. Si la solución estuviese hosteada sobre un servidor propio, la gente de IT debería prever esto y escalarla poniendo más hardware, balanceadores de carga, etc. En Windows Azure, esto se realiza indicando en un archivo de configuración cuantas instancias de la aplicación se correrán. Obviamente Microsoft cobrará por eso de acuerdo al tiempo en que usemos las múltiples instancias, pero será mucho más barato que comprar un servidor nuevo. 

Se trata realmente de un cambio de mentalidad con respecto al software. Algo que nos tendremos que tomar el tiempo para digerir y ver como puede aplicarse a soluciones concretas. Lo cierto es que la tendencia parece venir bastante fuerte, vehiculizada por pesos pesados de la industria, como Google y Microsoft. Así es que mejor poner un ojo sobre estas tecnologías y estar preparados para lo que viene. 

Pensar que cuando eramos chicos nos decían que estar en las nubes era algo malo. Ahora, por esas ironías de la vida, los que nos dedicamos al desarrollo tendremos que empezar a estar en la nube y ver que se cuece por allí. Veremos como se va perfilando todo esto. Sin dudas, en el horizonte del desarrollo algo esta cambiando. 

Etiquetas:

martes, setiembre 23, 2008

Charla sobre diseño de interacción




Ayer, Diego Gonzalez de Lagash Systems y el MUG, ofrecieron un impecable seminario sobre un tema no muy difundido por estos pagos, el diseño de interfaces de usuario usables.

Los programadores debemos admitir que tenemos algunas falencias a la hora de diseñar una interfaz de usuario bella, querible, usable, o por lo menos, poco odiable. Lo nuestro es mas bien la a reusabilidad, modelos, componentes, poco acoplamiento, patrones; conceptos que no tienen nada que ver con la belleza o la estética, o por lo menos no al nivel que un usuario espera ver en su pantalla. Por otro lado, las interfaces perpetradas por diseñadores gráficos, son visualmente impactantes, utilizan metáforas fotorrealistas, con animaciones y fuegos artificiales. Pero para el devenir diario de una aplicación son poco usables, ya que todos estos bonitos chirimbolos consumen un tiempo precioso en la operación del usuario, y no le agregan nada a su objetivo (que es usar la aplicación para un determinado fin, no ver lo lindo que es su diseño). Entonces ¿Qué se espera de un buen diseño de interacción?

En esta charla Diego nos ofreció algunas puntas para ir pensando en esto. Habló de la ley de Fits, que sirve para predecir cuánto tardará un usuario en lograr un objetivo en función de la distancia que tiene que recorrer con el mouse y el tamaño del objeto a apuntar. Esta ley explica, por ejemplo, porqué es más mucho fácil darle al menú de Macintosh que al de Windows. Porque el menú de la manzanita es "infinito" hacia arriba; por lo tanto no tenemos que preocuparnos por la dimensión vertical, es decir que vamos hacia arriba hasta que nos chocamos con el extremo de la pantalla y luego apuntamos sobre el eje X a nuestro objetivo.

Otra ley interesante de la que se habló es la de Hick-Hyman, que trata sobre el tiempo que una persona tarda en elegir entre una cantidad de opciones. Cómo esta variable se incrementa en un orden logarítmico -es decir que se incrementa en 1 cada vez que se duplican la cantidad de opciones- la conclusión sería que es más fácil seleccionar entre 30 opciones que agrupar estas 20 en tres grupos de 10, ya que esta última opción costaría dos elecciones, que lleva más tiempo que optar entre muchos elementos.

Todos estos datos sirven para evaluar la usabilidad de una interfaz de usuario con la exactitud que nos da el cronómetro, cosa que en general no sucede y la discusión sobre una interfaz termina girando en torno de si me gusta o no me gusta.

Algunos tips para aplicar al momento de bocetar un diseño de interacción:

1) Pensar en los tiempos. Todas las acciones de un usuario sobre la interfaz lleva un tiempo, darle a una tecla, apuntar y hacer clic con un mouse, pasar de manejar mouse a teclado o viceversa. Tratar de minimizar la cantidad de entradas de un usuario sobre la interfaz para alcanzar un objetivo, esto es, pensar en la mínima cantidad de información que la aplicación necesita a cada paso para hacer cada cosa, y pedir solo eso. En este plan, también conviene simplificar la interfaz al máximo y diseñarla de manera que las cosas que el usuario más usa queden más cerca, como marcando un caminito.

2) Aplicar metáforas. Si se puede, trabajar con metáforas del mundo real que al usuario le permitan ubicarse en el contexto de la aplicación rápidamente. Por ejemplo, arrastrar y soltar es una metáfora mucho más poderosa que Ctrl+C y Ctrl+V. También se pueden utilizar metáforas visuales, por ejemplo, íconos que den la idea de lo que sucederá cuando se haga clic sobre él.

3) Diseñar la aplicación de manera que sea lo menos intrusiva posible. Esto significa que el usuario pueda trabajar concentrado en su objetivo, recibiendo la menor cantidad posible de interrupciones de parte de la aplicación (o de parte nuestra). Por ejemplo, un cuadro de alerta que nos avisa que el archivo se grabó correctamente está de más, se supone que es lo que debe pasar y nadie espera lo contrario. A esto se le llama comportamiento no modal, porque la aplicación no impone el orden en que el usuario debe usarla, sino que deja a este que maneje el flujo de trabajo.

Por último, quisiera dejarles algunos links y recursos interesantes para los que quieran profundizar en este campo, que a decir verdad, ha sido poco explorado por nosotros, los desarrolladores:
  • El inventor de las metáforas aplicadas al diseño de objetos es Donald Norman, que las expone magistralmente en "La psicología de los objetos cotidianos". Verdaderamente este libro es un must read para todos los diseñadores de interacción y también para los iniciados en la disciplina del diseño industrial.
  • Por supuesto, el sitio del inefable Jacob Nielsen, UseIt.
  • Otro recurso interesante para mí es un librito muy entretenido del genial Joel Spolsky, llamado "Diseño de interfaz de usuario para programadores". Hay una versión reducida online en su sitio, y traducida al castellano aquí.
  • Otro libro, "Presos de la tecnología" (una desafortunada traducción de "The Inmates are running the assylum") del creador del Visual Basic, don Alan Cooper, plantea los problemas graves que puede traer un diseño de interacción poco usable. 
  • Y por último, el libro fundacional de la disciplina: "Diseño de Sistemas Interactivos", de Jef Raskin, el padre de la interfaz gráfica de Macintosh. Un poco denso quizás, pero ahí está la ciencia...
Los saludo y espero que les haya resultado tan interesante como a mí.

Etiquetas: ,

viernes, setiembre 12, 2008

¿Qué es una Fábrica de Software?

Fábrica de relojes (circa 1912)

A veces, la repetición de un término produce una sensación de familiaridad con la expresión, aunque no sepamos exactamente qué significa. Algo así sucede actualmente con el concepto de “Fábricas de Software” o “Software Factories” (SF en adelante). Hoy estas empresas son omnipresentes; en Google se encuentran de a cientos de miles. Las hay de todos los tamaños, con 4 empleados o 5000, locales o globales, para clientes corporativos o pequeñas empresas. Lo que muchas veces uno no termina de entender es ¿Qué define a una factoría de software? O mejor dicho ¿Qué la diferencia de una empresa productora de software? ¿Existe tal diferencia, o, como ha sucedido con tantos viejos términos, viene a desbancar el anticuado “empresa de software”, como “verdum” reemplaza a ensalada?

En una primera aproximación, la diferencia entre un “taller de software” o “software shop” y una SF suena sutil, pero veremos que no lo es. El taller de software es una empresa (grande o chica, no importa) dedicada a la construcción de software en forma “artesanal” ¿Porqué decimos artesanal? El término Fábrica de Software remite directamente a la forma de producción que propone la revolución industrial. Hagamos un poco de historia. En el siglo XVIII se produce un movimiento histórico llamado revolución industrial que consistió básicamente en un cambio de los métodos de producción. Antes de esta revolución existían grandes talleres, donde trabajaban maestros artesanos que poseían el saber para construir un objeto -por ejemplo una silla- de principio a fin. El artesano cortaba la madera, le daba forma, la ensamblaba, ponía el tapizado, etcétera, hasta que la silla estaba terminada. Este manufactura, como podrán imaginarse, era lenta y cara; por eso casi todos los objetos previos a la revolución industrial son objetos de lujo, que sólo podían ser adquiridos por miembros de la nobleza (¿les suena algo en relación al software artesanal?). Hilando mas fino, el proceso que tiene lugar durante la revolución industrial es el estudio del saber a los artesanos, su sistematización y su aplicación a los mecanismos de producción disponibles en la época (líneas de producción, máquinas a vapor). Este proceso permite que las sillas puedan construirse en masa y así abaratar costos y garantizar un proceso repetible ¿Cómo se aplica esta idea a la construcción de software? Básicamente, se trata del mismo concepto: un taller de software produce aplicaciones en forma única, ensamblándolas de principio a fin. Las aplicaciones pueden estar hechas a medida (específicas para un cliente) o en forma de productos, lo distintivo es que entre los productos existe un alto nivel de aislamiento, no existe la “línea de producción”. Si bien los equipos que trabajan en cada proyecto pueden compartir gente, prácticas y hasta algunos componentes, ésta metodología no se encuentra institucionalizada. Así, las iniciativas de reutilización reducen a esfuerzos individuales que casi no influyen en la producción como un todo. En general, este tipo de proyectos dependen de la pericia y la buena voluntad de la gente que los componen, de la misma manera, en el artesanado, una buena silla dependía del individuo que la había construido. Un buen equipo garantiza que el proyecto estará dentro de ciertos estándares de calidad, incluso sin una estructura que los respalde. En el taller se trabaja “ad-hoc”, es decir, para cada proyecto particular. El nivel de reutilización, en el mejor de los casos, es bajo y depende de que la gente del equipo conozca y adapte componentes usados con anterioridad. Entonces surge nuevamente la pregunta ¿Qué es y cómo se construye una fábrica de software?

El tamaño no importa

Para decirlo brevemente, una SF no se define por su tamaño pero sí por la escala a la que apunta cuando diseña sus productos. Así como una fábrica de autos, la SF basa su operación en líneas automatizadas de producción que le permiten ahorrar en términos de costo por producto ¿Cómo hace esto una SF? Una fábrica de software construye líneas de producción de software. Y éstas, a su vez, engendrarán varios sistemas que responderán a lo que esa línea fue diseñada para crear. Así, la apertura de un proyecto nuevo no implica cada vez empezar de cero, porque existe una cantidad de conocimiento que ya ha sido capturado en la línea y se puede volcar sistemáticamente a la resolución del problema. De esta manera, el team de desarrollo puede enfocarse estrictamente en la problemática particular de esa solución, ya que los aspectos genéricos (por ejemplo: la interfaz gráfica, cuestiones de autenticación y seguridad, persistencia de datos) ya fueron previstos y resueltos por la línea de producción. Imaginen, por ejemplo, que una empresa automotriz cada vez que proyecta un nuevo auto tenga que volver a desarrollar cada uno de sus componentes. De nuevo hacer un motor desde el plano, un carburador desde cero, paneles, vidrios, frenos, etc. Literalmente estaría reinventando la rueda en cada nuevo producto. Los autos tardarían años en ser desarrollados y tendrían innumerables fallas (probablemente más que ahora). Además, valdrían millones de dólares, ya que la inversión para desarrollar cada modelo desde la nada sería descomunal.

En la SF lo que cambia es el ámbito de la solución a la que se apunta. Esto implica que se diseñará, no una solución específica a un problema (por ejemplo, para manejar la contabilidad de la rotisería “El pollo bonito”) sino una solución más amplia, aplicable a un espectro de productos. Esto implica pensar en generalizaciones del tipo ¿Qué características pueden compartir todos los sistemas de gestión contable? Esto es una característica importante de una línea de producción, resolver problemas generales de un tipo de software, elevando así el nivel de abstracción de la solución. La otra característica fundamental, es establecer abundantes puntos de extensión en nuestra línea. Si bien la SF, efectivamente va a estar preparada para resolver problemas, también va a dejar “cabos sueltos”, es decir, mecanismos de personalización de la solución, ya que es muy probable que los productos necesiten modificar los comportamientos por defecto que la línea previó ¿Y esto como se hace? Un mecanismo muy utilizado es construir un potente framework extensible, un tema que fue tratado por un excelente artículo de Diego Dagum. Vayan, léanlo, yo los espero acá (…).

Para ir cerrando, armar una SF implica tomar una serie de decisiones sobre arquitecturas, modelos, prácticas y procesos a seguir con el objetivo de aplicarlos a la construcción, no de uno, sino de varios paquetes de software. Cuanto más mejor, así el retorno por la inversión se agranda. En este artículo quise reunir algunas reflexiones iniciáticas sobre las SF, para entender un poco más profundamente para qué sirven, cómo funcionan, y despejar un poco la niebla que los departamentos de marketing suelen echar sobre temas técnicos. En un próximo artículo comentaré algunas impresiones sobre la visión de Greenfield y Short (arquitectos de Microsoft), expuesta en su libro: Software Factories Assembling Applicacions with Patterns Models, Frameworks, and Tools. Estos muchachos van a fondo con esta visión y nos muestran la punta del ovillo para plasmar en resultados estos jóvenes conceptos.

Etiquetas: , , ,