Si nos dedicásemos a enroscar tapones de botellas probablemente podríamos medir nuestra productividad en términos del número de botellas cerradas por hora. Si cargásemos sacos en un muelle, quizás en kilos transportados por jornada... Hay muchos trabajos en los que es relativamente sencillo establecer una medida para conocer el grado de productividad con el que desempeñamos nuestras obligaciones.

Lamentablemente, esto no es así en la industria del software, que durante años ha ido dando tumbos, probando y descartando sucesivamente diversas métricas para intentar medir la productividad de los desarrolladores, como el cómputo de líneas de código por día, puntos función, puntos de historia o el grado de completitud de sprints, pero siempre sin éxito. En el desarrollo de software todo es demasiado etéreo: dado que no creamos ni manipulamos productos tangibles, no hay nada que poder pesar o contar, salvo las horas pegados a nuestra silla.

Sin embargo, todos tenemos una idea intuitiva de lo que es un desarrollador productivo, e incluso se ha hablado bastante de los desarrolladores 10x: programadores que son al menos diez veces más productivos que los que se encuentran en el lado opuesto del espectro. Esta idea parte de estudios científicos contrastados, y algunos destacados gurús incluso suben la apuesta llegando a estimar que determinados desarrolladores pueden producir entre diez y veintiocho veces más que sus compañeros. Casi nada.

Sin duda, un desarrollador 10x es todo un lujazo para las empresas, que lucharán para atraerlos, normalmente a base de ofrecer unas condiciones espectaculares, porque es mucho más rentable ofrecer a un desarrollador 10x el triple de sueldo que tener a diez desarrolladores para conseguir el mismo resultado.

Nuestro objetivo profesional, por tanto, debería ser dar el salto y convertirnos en uno de ellos.

Un reciente estudio de la consultora Garner indica que durante el desarrollo de una aplicación dedicamos más del 80% de nuestro tiempo a implementar controles de posibles fallos.

Además, este otro informe de StackOverflow obtenido tras analizar el código fuente de miles de proyectos open source, el control y tratamiento de excepciones y problemas supone más del 60% de nuestra base de código y, por tanto, aporta gran parte de la complejidad interna de las aplicaciones.

Pero, adicionalmente, estos estudios ponen al descubierto otros tres aspectos bastante interesantes:

• Primero, que la mayoría de errores que intentamos controlar no se van a producir nunca. Son posibles a nivel de flujo de código, pero en la operativa de la aplicación no ocurrirán, por lo que podríamos decir que son problemas creados artificialmente durante el proceso de desarrollo.
   
• Segundo, las líneas de control de errores no están exentas de problemas, por lo que muy a menudo encontraremos en ellas nuevo código de control (¿quién no ha visto try/catch anidados a varios niveles?), por lo que la bola de nieve no para nunca de crecer: código de tratamiento de errores que a su vez contiene código de tratamiento de errores, y así hasta el infinito.
   
• Y por último, también nos encontramos con que en muchas ocasiones el código de control no hace nada. Por ejemplo, se cuentan por millones las líneas de código detectadas en Github cuyo tratamiento de excepciones consiste simplemente en la aplicación a rajatabla del Swallow Design Pattern, por ejemplo, implementando bloques catch() vacíos.

Y conociendo estos datos, ¿por qué dedicamos tanto tiempo a la gestión de errores en nuestro código? Pues básicamente porque hemos sido educados para eso. Exceptuando cuando se nos cala el coche, no hay nada que suponga un golpe al ego tan importante como cuando una de nuestras aplicaciones falla, y por eso no escatimamos recursos a la hora de evitarlo.

¿No estaría bien poder ignorar esos problemas y centrar nuestro código en aportar valor a nuestros clientes?

Desde que apareció Roslyn, C# ha ido evolucionando a pasos agigantados. Tanto es así que es frecuente encontrar desarrolladores que, aunque lo usan a diario, desconocen todo su potencial porque la velocidad de introducción de cambios en el lenguaje es mayor que la de asimilación de novedades por parte de los profesionales que nos dedicamos a esto.

Por ejemplo, en las consultorías técnicas que realizo en empresas es frecuente encontrar equipos de trabajo en los que aún no está generalizado el uso de construcciones tan útiles como el null coalescing operator (fullName ?? "Anonymous"), safe navigation operator (person?.Address?.Street), el at object operator (Address@person), o características tan potentes como las funciones locales, interpolación de cadenas, tuplas o muchas otras.

Sin embargo, creo que el rey de los desconocidos es el operador virgulilla "~" de C#. Introducido con C#7 es probablemente uno de los operadores menos utilizados y, sin embargo, de los más potentes ofrecidos por el lenguaje.

Nota de traducción: el nombre original del operador es "tilde operator", y como he encontrado poca literatura al respecto en nuestro idioma, me he tomado la libertad de traducirlo como operador virgulilla (¡sí, esa palabra existe!). También, en entornos más informales lo encontraréis con el nombre "wormy operator" (operador gusanillo) o como "soft similarity operator" (que podríamos traducir como operador de similitud relajada).

Aunque por aquellos tiempos ya llevaba bastante tiempo enganchado al desarrollo de software, fue en el año 1992 cuando empecé mi andadura profesional en este mundillo, y he de decir que estos más de veinticinco años han dado para mucho. Poco más o menos, creo que he pasado por todos los roles existentes en el mundo del software, en todas las modalidades laborales posibles: programador, analista, consultor, formador, coordinador de equipos de desarrollo, CTO, empleado, empresario, freelance…

Aparte de muchas alegrías y algún que otro disgusto, lo que tengo claro es que esta trayectoria me ha dado una visión bastante amplia de cómo funciona el mundo del desarrollo de software y las personas que trabajamos en él.

Como guardarme estos conocimientos me parecía demasiado egoísta, he decidido compartir con todos vosotros los que considero que son los diecisiete consejos definitivos que debéis seguir si queréis triunfar en el mundo del desarrollo de software.

Por lo que he ido aprendiendo estos años, seguir estas reglas os llevará a conservar indefinidamente vuestros empleos o clientes, aumentaréis vuestro valor en el mercado, mejoraréis salarios y vuestro grado de felicidad y satisfacción personal crecerá hasta límites insospechados.

He de decir que, antes de compartirlos con todos vosotros, varias personas ya los han seguido y sus vidas profesionales han mejorado considerablemente. Por ejemplo, Juan M. R. trabajaba como programador junior en una conocida cárnica hace 6 meses y hoy dirige el equipo técnico en una startup en San Francisco. También, Nacho G. L. pudo firmar hace poco el contrato fijo con el que soñaba, incluso con un aumento de sueldo. Rafael P. G. era un programador del montón y ahora es un reputado project manager por el que se pelean las mejores empresas del mundo.

“Sin los grandes consejos de José María,
mi vida como desarrollador seguiría siendo un infierno”
– Ricardo M. C., 2017

Podéis ser los próximos en dar el salto, sólo depende de vosotros.

Sin duda, el equipo de marketing de Microsoft es conocido por su gran habilidad y creatividad a la hora de nombrar los nuevos productos que la fábrica de Redmond va lanzando al mercado. Pero no sólo eso, también son realmente buenos sabiendo cuándo hay que hacerlo para conseguir captar la atención y elevar el hype.

Ya lo demostraron meses atrás con el renombrado de toda nueva pila de tecnologías relacionadas .NET, cuando decidieron cambiar de ASP.NET 5 a ASP.NET Core, una idea que sirvió para centrar las expectativas del producto y entusiasmó a los autores de contenidos (blogs, podcasts, libros, cursos, presentaciones, etc.), sobre todo por lo oportuno de tan estratégico movimiento.

Y el renombrado de la suite de desarrollo por excelencia ya se estaba haciendo de esperar, aunque esta vez no nos ha pillado desprevenidos. De hecho, más o menos era un secreto a voces e incluso había algún leak donde se había adelantado la noticia: Visual Studio 2017 se llamará finalmente Visual Studio Core 1.0, rompiendo así con la tradición de versionarlos según el año de aparición, como se lleva haciendo desde el año 2003.

Ayer mismo se publicó la Release Candidate 2, en la que ya figura el nuevo nombre del producto. También es posible descargar ya las actualizaciones de componentes y herramientas de terceros (como JetBrains, Telerik, Component One, DevExpress y otros) con adaptaciones a estos cambios, así como acceder a documentación y materiales actualizados.

Como consecuencia de este cambio, y dado que existe un parecido razonable del nuevo nombre con el popular Visual Studio Code, éste último pasará a denominarse Code Studio Visual, eliminando así toda posibilidad de confusión entre ambos productos, pero manteniendo al mismo tiempo el "aire" de familia entre ellos.

La nueva versión disponible a día de hoy, versionada como 2.0, ya hace efectivo este cambio, como podéis ver en la captura de pantalla adjunta.

Pero la oleada de renombrados en la organización no queda aquí, pues lo mismo ocurre con los servicios para desarrolladores en la nube. Con objeto de hacer más sencilla la adopción de la nueva nomenclatura, los servicios conocidos como Visual Studio Online, que luego pasaron a denominarse Visual Studio Team Services, pasarán ahora a llamarse Visual Studio Core Team Online Services, dejando así más patente su relación con la familia de productos y su enfoque de plataforma completamente online.

Aunque algo más adelante, también se verán afectados los servicios generales en la nube, lo que hasta ahora conocíamos como Microsoft Azure, que pasarán a denominarse Microsoft Cloud Core Services. Sin duda, todo un acierto el eliminar la palabra "Azure", que al fin y al cabo no dice nada, y comunicar más claramente dónde se encuentra la aportación de valor del producto, como ya hacen otros proveedores como Amazon, IBM o Google.

Según Patrick Iñuelas, product manager de Microsoft Naming Core Team (la división de marketing encargada de poner en marcha estos cambios) están ahora trabajando en el próximo paso, que es renombrar Xamarin a Silverlight Core, en palabras textuales, "porque tenemos el nombre de dominio disponible".

¿Y mi opinión respecto a todos estos cambios? Pues, por supuesto, absolutamente favorable. Los nombres anteriores sonaban ya algo añejos y a los jóvenes desarrolladores les sonaba a algo “legacy”; es lógico que cada cierto tiempo haya que hacer un reboot para poner los contadores a cero y comenzar de nuevo. En cuanto a los nombres elegidos, creo que son totalmente acertados porque son fáciles de recordar, tienen gancho, y se alinean correctamente con la tendencia "Core" de los últimos tiempos, dando una imagen mucho más fresca y moderna de los productos.



Publicado en Variable not found.

Como seguro sabréis, uno de los problemas abiertos más importantes del mundo de la informática era el problema de la parada. En el año 1936, el gran Alan Turing demostró de forma teórica que no existía ni podía existir un algoritmo mediante el cual una máquina de Turing pudiera determinar de forma automática si un programa cualquiera finalizaría su ejecución ante unos determinados datos de entrada, o bien si quedaría sumergido para siempre en un bucle o ciclo infinito.

Pues bien, tras algunos días de investigación, Aitor Agirreazkuenaga, paisano de Bilbao, ha encontrado una solución al problema, contradiciendo así a los teóricos más sesudos y haciéndose merecedor del millón de dólares que ofrecía el Clay Mathematics Institute para los científicos capaces de solucionar alguno de los problemas del milenio.

Los que estaban cerca de Aitor, que es también bastante conocido por su afición al Harrijasotzea, o levantamiento de piedras, dicen que realizó su descubrimiento al grito de “Verás tú si se para, ostias…”

Están por ver las repercusiones que su descubrimiento tendrá en el mundo del desarrollo, pero sin duda se trata de una gran aportación a la calidad del software, pues por fin podremos saber, antes de ejecutarlas, si nuestras aplicaciones son computacionalmente finitas y seguras.

De momento se sabe que Microsoft ya ha reaccionado al respecto, y los descubrimientos de Aitor estarán presentes en el próximo Visual Studio, alias "Codewalker", donde la estrella será un asistente inteligente de última generación que nos ayudará en todo momento durante el proceso de desarrollo, y cuya imagen ha trascendido recientemente en el blog oficial de la empresa.

Seguiremos informando, porque esto promete…

Publicado en Variable not found.

Por mi trabajo, suelo “husmear” en el código de muchas aplicaciones creadas por equipos de trabajo en empresas de todo tipo y nacionalidad, y os puedo asegurar que existe un denominador común en todas ellas y que seguro reconoceréis en vuestro propio código: los desarrolladores escribimos como nos viene en gana.

No es poco frecuente ver aplicaciones con faltas de ortografía que un niño de primaria calificaría como graves. Y notad que no hablo sólo de las etiquetas, mensajes y otros elementos visuales que van a parar a los atónitos ojos de nuestros usuarios, sino también de lo que hay por detrás, en el código fuente.

A nivel de código, las denominaciones internas en clases, métodos o variables, textos en comentarios o incluso los mensajes en check-ins en el control de código fuente, son habitualmente terribles. Claro, sabemos que eso no lo va a leer nadie, o al menos nadie de fuera de nuestro entorno, y bajamos la guardia hasta límites que rozan la ilegalidad. Mezclamos idiomas sin ningún criterio (¿quién no ha escrito alguna vez un método GetFacturas(), obtenerResources () o una variable lineasCount en su base de código?), cometemos atropellos ortográficos, gramaticales y otros tipos de aberración de forma impune, escudados en que no hay que prestar atención a esos detalles porque es sólo código.

Y lo peor es que esta actitud de desidia es contagiosa. Cuando entras en un proyecto donde todo está escrito sin ningún tipo de miramiento, lo normal es que continúes en esa línea, haciendo que la barbarie sea cada vez mayor y, a su vez, más contagiosa en el futuro. Y cuando comiences otro proyecto, llevarás la costumbre de hacerlo así y continuarás extendiendo esta práctica ad eternum.

Pero, ah, amigos artesanos del código, esto se va a acabar.

Las próximas versiones de Visual Studio corregirán drásticamente esta tendencia, incluyendo la revisión ortográfica como parte del proceso de compilación. Además, como comentó S. Somasegar en una reciente entrevista,

“esta característica no podrá ser deshabilitada; en caso contrario ya sabemos lo que ocurriría, y va en contra de la firme apuesta de Microsoft hacia un mundo que se comunique mejor”

Y la cosa va muy en serio. Para dar mayor formalidad a esta necesaria iniciativa, Microsoft ha firmado un acuerdo con distintas academias responsables de definir y actualizar la mayoría de idiomas del mundo, como la National Commission on Language and Script Work (国家语言文字工作委员会) de China, la Real Academia Española (RAE), Academy of the Arabic Language (مجمع اللغة العربية),  la Royal Galician Academy, o Council for German Orthography (Rat für deutsche Rechtschreibung) por citar sólo algunas. De estas instituciones obtendrá los diccionarios actualizados que serán utilizados por las herramientas del gigante de Redmond para comprobar que estamos escribiendo como debemos. En el caso del inglés es distinto porque no existe un organismo regulador, pero se atenderán a las guías oficiales publicadas por los países donde es la lengua oficial.

Para su aplicación práctica en las herramientas de desarrollo de la casa, ha sido necesario retocar tanto las propias herramientas como algunos aspectos de los compiladores de los lenguajes estrella, C#, VB, F# y DuoLang.

En Visual Studio tendremos disponibles propiedades a nivel de proyecto y de cada archivo (de código, recursos, diseñadores, etc.) en el que indicaremos el idioma en el que debe realizarse la comprobación.

Por supuesto, también ha sido actualizado intellisense para alternativas a las palabras que vayamos escribiendo e incluso un menú de sinónimos, de la misma forma que Microsoft Word:



Para los casos en que el idioma pueda cambiar dentro del propio archivo o incluso en distintas secciones de éste, se han añadido directivas #pragma que pueden usarse en cualquier punto. Por ejemplo, en el siguiente código se han detectado dos errores de compilación para la porción escrita en español, en un comentario y en el nombre de un método:



Por supuesto, las comprobaciones atienden al camel casing, es decir el nombre del método ObtenerFactura() se entenderá correcto, mientras que Obtenerfactura() no lo será. Otra ventaja colateral de esta característica es que dejaremos de utilizar nombres de variable sin sentido como “s”, “xyz”, tendiendo a que realmente se refleje su intencionalidad como “saldo” o “coordenadasTridimensionales”. Se está estimando, sin embargo, excluir las variables de tipo índice obvias como la típica “i” en un bucle for por razones históricas.

Las mismas directivas y propiedades se aplicarán en las comprobaciones de cadenas de texto, recursos (.resx) y diseñadores de la aplicación. De esta forma, podremos estar seguros de que los textos que lanzamos a los usuarios habrán superado un nivel mínimo de calidad, que falta hace en muchas aplicaciones:



En fin, creo que es una iniciativa absolutamente necesaria para mejorar la calidad interna de nuestro código y, como extensión, de nuestras aplicaciones, y me gustaría felicitar a Microsoft por haber tomado esta controvertida decisión. Seguro que traerá mucha polémica, pero estoy convencido de que es por el bien de la humanidad.

Aunque en principio esta nueva característica sólo estará disponible para Visual Studio 2015, no se descarta la creación de extensiones para todas las versiones de Visual Studio, comenzando en la 2005. Está previsto incluso su introducción en el proyecto Omnisharp para poder aplicarlo en entornos de desarrollo más allá de Visual Studio, lo que abriría su uso a otras plataformas como Mac o Linux, y de la posibilidad de desarrollar plugins oficiales para Git, Mercurial, Subversion, TFS y sistemas de integración continua que permitan automatizar estas comprobaciones.

Se avecina un año maravilloso donde los sistemas de control de código fuente podrán rechazar un commit o check-in por tener faltas de ortografía, o en el que en nuestra mesa, junto a clásicos como C Programming language  o Code Complete , podremos encontrar el diccionario de la real academia de la lengua española.

¡Feliz escritura de código!



Publicado en Variable not found.

Los GUID (Globally Unique Identifier) son una serie de 16 bytes generados pseudoaleatoriamente que se suelen utilizar para identificar de forma única objetos, dispositivos, componentes, o prácticamente cualquier cosa. Y, a diferencia de otros tipos de identificadores, el “única” debe ser interpretado de forma global, es decir, es virtualmente imposible que un GUID utilizado para un elemento se repita en otro equipo, lugar o sistema.

No hay magia negra en esto, es pura matemática. El número de combinaciones posibles es 2¹²⁸; dicho así no parecen demasiadas, pero para que os hagáis una idea de las magnitudes, serían algo así como 3.400.000.000.000.000.000.000.000.000.000.000.000.000 valores distintos, número arriba o número abajo ;-). Si os parece difícil que os toque la lotería, supongo que podréis intuir lo poco probable que es que existan colisiones si decidimos seleccionar un GUID, por ejemplo, como campo clave en filas de una base de datos, o como nombres de fichero que queremos asegurar que sean únicos. Y así lo hemos hecho durante años.

Y todos los que los usamos seguiríamos tan felices si no fuera por ese pequeño matiz que he deslizado al comienzo del post: la pseudoaleatoriedad del algoritmo de generación utilizado, que va a provocar un colapso el próximo 11 de febrero debido al efecto denominado GUID Colliding Sequence.

Indudablemente, hoy en día llevamos en el bolsillo ordenadores en miniatura mucho más potentes de lo que eran los equipos de escritorio hace unos años. Cualquier smartphone razonablemente actualizado es capaz de funcionar a más de 1Ghz y cuenta con varios gigabytes de memoria RAM, y, sin embargo, toda esta potencia está infrautilizada la mayor parte del tiempo.

Por otro lado, tampoco se puede dudar ya de la entrada de la nube en nuestras vidas. Cada vez desplazamos más capacidad de almacenamiento y proceso a infraestructuras fiables y escalables como las ofrecidas por proveedores como Microsoft, Amazon, Google, Oracle y otros, con un coste más que razonable. Esto, sin embargo, presenta un reto a medio y largo plazo: ¿serán las infraestructuras de estos proveedores suficientes como para soportar el crecimiento exponencial en servicios demandados por los usuarios?

Microsoft es una compañía que nos tiene acostumbrados a giros extraños en sus políticas de comercialización y distribución de productos, y está claro que la nube no iba a permanecer ajena a ellos.

Hace un par de días, ante el asombro de los presentes, Fred Swarm (cloud manager para la región EMEA) anunció la próxima apertura de Adzure, la edición gratuita del servicio Windows Azure soportada por publicidad.

Los desarrolladores, antes o después, acabamos sufriendo problemas físicos debido a nuestro trabajo. El hecho de estar sentados todo el día aporreando teclas como posesos lleva asociado una serie de males de espalda, manos, muñecas, brazos, hombros, cervicales… vaya, que a veces parece que sería mejor estar cargando bultos en el muelle ;-)

Esto han debido pensar  los equipos de trabajo de Kinect y Visual Studio en Microsoft, en conjunción con laboratorios MS Research, que se han unido para brindarnos lo que será la próxima revolución en el mundo del desarrollo de software, y que han decidido llamar “Gesvelopment” (Gestual Development, o tecnología GDM).

Visual Studio Kinect Edition es el primer producto de la casa que incorporará este nuevo paradigma. Básicamente, consiste en un sensor Kinect unido al PC de trabajo, en el que se instalará un Visual Studio tuneado con complementos capaces de interpretar movimientos y voz del desarrollador y trasladarlos a acciones en el editor y el propio entorno.

La tecnología GDM permitirá programar mediante movimientos, voz, posiciones y gestos del cuerpo, es decir, sin necesidad de tocar una tecla o el ratón para nada. Esto irá combinado con una serie de ayudas específicas permitirán aumentar nuestra productividad y, al mismo tiempo, mantenernos en una forma física envidiable.

Los interfaces de usuario podremos crearlos utilizando una herramienta al más puro estilo Minority Report: arrastrando virtualmente los elementos sobre la pantalla, redimensionándolos, abriendo sus propiedades, etc., siempre mediante movimientos de brazos, manos y piernas perfectamente sincronizados con lo que aparece en pantalla.
El código lo editaremos mediante un conjunto de movimientos y gestos preestablecidos, similares a los usados en el lenguaje de signos. Esto no implica, sin embargo, la aparición de un nuevo lenguaje para .NET. GDM monta una capa de abstracción sobre los lenguajes usados (C#, VB.NET, HTML, etc.), de forma que el mismo movimiento puede ser transformado a instrucciones del lenguaje activo, sea cual sea éste, siempre que se disponga de los drivers oportunos.

Así, por ejemplo, en lenguajes de programación clásicos, un movimiento circular con el brazo será interpretado como bucle, y será introducido en el código traducido al lenguaje actual, o un salto del programador será convertido en un jump, goto, o la estructura más cercana. O por ejemplo, en HTML podremos enfatizar texto (<em>) inclinándonos hacia la derecha (véase la imagen lateral), mientras que cerrar el puño con fuerza será útil para formatear en negrita (<strong>). La variedad de gestos y movimientos permitidos es enorme.

GDM también incluye un sistema de reconocimiento de voz con el que se podrán matizar y definir, por ejemplo, nombres de variables o instrucciones cuyos movimientos serían difíciles de ejecutar.

Las operaciones con el entorno (compilar, ejecutar, copiar, pegar, etc.) las realizaremos también con movimientos corporales explícitos. En el ejemplo de la derecha, podemos ver el gesto mediante el cual podemos cortar y enviar al portapapeles el texto seleccionado; podemos compilar apretando una mano contra otra, o ejecutar aplicaciones haciendo un gesto de decapitación con la mano derecha sobre nuestro cuello. Esto último denota algo de humor negro, sin duda, por parte de los desarrolladores del invento.

Otro aspecto realmente curioso e interesante es que dado que algunos dispositivos como Kinect son capaces de detectar y seguir los movimientos de más de una persona al mismo tiempo, será posible trabajar de forma colaborativa (pair programming), como se aprecia en la fotografía de la derecha, donde aparecen dos desarrolladores trabajando sobre una vista MVC.

Los afortunados poseedores del sensor Kinect podrán probar una edición limitada de GDM al instalar Visual Studio 2010 Beta 2, aunque el producto será distribuido oficialmente con Visual Studio 2012 (codename NutCracker), en una edición especial del producto.

Sin embargo, Microsoft no se ha centrado exclusivamente en sus tecnologías, jugando con abstracciones que hacen posible independizarse del dispositivo de detección de movimientos y reconocimiento de voz, e incluso del entorno de desarrollo. Así, aunque algo más tarde, también será posible desarrollar aplicaciones utilizando el mando de la Wii, y Move, el sensor de las consolas Playstation. También se están ya implementando drivers para todo tipo de entornos de desarrollo profesionales como Eclipse, Netbeans, o el block de notas.

Esto es posible gracias a su arquitectura modular, en la que se han previsto componentes que aíslan el software del hardware, y éstos a su vez del IDE y lenguaje utilizado:



Está claro que antes de que se implante de forma generalizada deberán cambiar algunos aspectos en nuestro entorno y cultura empresarial, como:

• el espacio de trabajo deberá ampliarse para cada desarrollador. Será necesario un espacio de al menos tres metros cuadrados diáfanos por desarrollador para poder ejercitar su trabajo de forma eficiente y sin interferir con el compañero.
• las instalaciones deberá adecuarse. Las empresas deberán instalar zonas de duchas, e incorporar fisioterapeutas o médicos deportivos a sus plantillas.
• la ropa de trabajo deberá ser cómoda y apropiada para una actividad física, quizás chándal y zapatos deportivos puedan ser una buena opción.
• el tamaño de los monitores deberá ampliarse al menos a 50 pulgadas, para que el desarrollador pueda leer textos a cierta distancia, y mientras está en movimiento.
• habrá que cambiar ciertos hábitos: menos café y más Gatorade, dietas altas en proteína para desayunos y almuerzos, etc.

En fin, aunque es una idea realmente atractiva, habrá que ver si las empresas son capaces de evolucionar hacia esta nueva organización, en la que las salas de desarrollo parecerán más bien de aerobic. No será fácil cambiar una mentalidad tan arraigada, donde los desarrolladores somos seres inertes, estáticos, y casi parte del mobiliario, pero sin duda aquellas que lo consigan se habrán puesto radicalmente por delante de su competencia en muchos aspectos.

Ya sabéis, id calentando, que GDM está cerca…

Publicado en: Variable not found.

Seguro que muchas veces te has preguntado qué es el “programa para la mejora de experiencia de usuario”, esa pantalla que nos aparece desde hace muchos años tras instalar Visual Studio (y otros productos de Microsoft), sugiriéndonos sutilmente que ayudemos a recopilar información del uso que damos a sus servicios y software.

En el encuentro de desarrolladores DevConn4 del pasado diciembre ya se oían rumores sobre el uso que estaban dando a esta información los chicos del laboratorio, y concretamente los investigadores del grupo Information retrieval and management, pero nada que pudiera ser tomado en serio en aquél momento.

El pasado uno de Abril, Dough Seven, Senior Product Manager de Visual Studio Team System en Microsoft, en el marco de las DSL’s Developers Conference, ya dejó caer que en la próxima versión de Visual Studio (la 2010) se introducirían “tecnologías que revolucionarían la forma en la que desarrollamos software e incrementarían la productividad de forma nunca vista”. Ahora, con el tiempo, se entiende que no se refería a nuevas plantillas, componentes o mecanismos de refactorización, se trataba de una pequeña pista de lo que se estaba cociendo en Redmon.

Y por fin, cuando ya va quedando menos para lanzamiento oficial de Visual Studio 2010 (estaba previsto para el próximo mes de marzo, aunque ha sido retrasado), es el mismísimo S. Somasegar Vicepresidente Senior de la División de Desarrollo, el que ha desvelado el gran secreto: la tecnología PremoniSense™.

Tras este enigmático nombre se encuentra el resultado de recopilar pautas de comportamiento de decenas de miles de desarrolladores de todo tipo durante más de diez años y procesarlas mediante complejos mecanismos estadísticos e inteligencia artificial. Esto ha permitido desarrollar un motor de inferencia, alojado en la nube, capaz de analizar en tiempo real el uso que hacemos del entorno de desarrollo y adelantarse a nuestras acciones, automatizando gran parte de las tareas habituales de los programadores.

Cómo funciona

El modus operandi es el siguiente: cuando PremoniSense™ detecta un comportamiento conocido, aparece un cuadro describiéndonos cuál es el siguiente paso que vamos a dar en función de lo que hemos hecho hasta el momento; la base de conocimiento de la que obtiene esta información es tan amplia que estadísticamente se estima que el índice de error de sus predicciones el 0,1%, es decir, un fallo de cada 1000 acciones. Pero lo más interesante sin duda es que, dado que conoce perfectamente nuestras intenciones, nos ofrece la posibilidad de hacer el trabajo por nosotros automáticamente.

Áreas de interacción

De momento, esto que veremos en Visual Studio 2010 será únicamente un adelanto, por lo que sólo será posible disfrutar de él en tres áreas de actividad en el proceso de desarrollo de software: la arquitectura de aplicaciones, el desarrollo o implementación, y la calidad del software.

Se prevé que Visual Studio 2012 ya incluirá soporte de PremoniSense™ completo para otras áreas, como la ingeniería de requisitos, el despliegue o el soporte postventa.

Pero bueno, centrándonos en el presente, a continuación describo las áreas en las que esta tecnología estará presente en VS2010, con algunas capturas de pantalla de ejemplo que demuestran la increíble potencia de esta tecnología, que a veces sólo se puede describir con la palabra “magia”.

• Arquitectura (Architectural PremoniSense™) 
  El motor de inferencia será capaz de detectar, en función del tipo de aplicación que estemos desarrollando, la arquitectura más apropiada a utilizar en cada momento, refactorizando el proyecto para adaptarse a la misma.
  
  Por ejemplo, si estamos creando una aplicación MVC con servicios de uso genérico será capaz de crear un proyecto independiente WCF capaz de permitir accesos securizados desde el exterior. Si observa que utilizamos procesos basados en flujos de trabajo, será capaz de mover el código a un proyecto independiente implementando dichos procedimientos con Workflow Foundation. Si detecta acceso a datos desde capas no permitidas (p.e., desde controladores en MVC), los trasladará a un proyecto independiente (el típico DAL, o capa de acceso a datos), actualizando las referencias automáticamente.
  
  Asimismo, será capaz de detectar funcionalidades duplicadas transversales al sistema (por ejemplo, acceso a logs, seguridad, gestión transaccional), extraer sus implementaciones e inyectarlas de nuevo utilizando técnicas propias de la programación orientada a aspectos (AOP), todo de forma automática.
  
  En teoría, el sistema soporta arquitecturas de hasta 7 capas, con posibilidad de entender y plantear soluciones integrando tecnologías tanto de Microsoft (como Sharepoint, Office, Exchange, WWF, EF, WCF, JASP, WPF, MVC, MVP o HTML) como open source (Rails, PHP, NHibernate, MySQL, Oracle, EJB, FSB, UPNP, ó MRW).
  
• Desarrollo (PremoniSense™ for Code)
  El funcionamiento de PremoniSense™ en esta área es conceptualmente muy similar a las ayudas del IDE e incluso al soporte ofrecido desde herramientas externas como Resharper, el objetivo es ayudarnos a codificar más rápidamente y sin errores, pero llevado al extremo. Por citar unos ejemplos, ahí van los que más me han llamado la atención (podéis ver la lista completa en la documentación oficial):
  
  
  • Autogeneración de funcionalidades CRUD. Es decir, el sistema detectará cuándo estamos realizando un mantenimiento típico (altas, bajas, modificaciones y consulta) y lo implementará por nosotros. Para ello, analizará la estructura de la base de datos y creará el código más apropiado y correcto según su experiencia acumulada en el tipo de sistema de que se trate.
    
  • Autoasignación de propiedades. PremoniSense detectará cuándo estamos poblando las propiedades de un objeto y las establecerá por nosotros, determinando de forma automática el origen de la información. Por ejemplo, si estamos ante el clásico bloque de código para traspasar datos desde los campos de un formulario a una entidad, lo detectará y generará el código por nosotros; o en la implementación de un constructor con parámetros, asignará automáticamente los miembros internos coincidan con éstos.
    
  • PremoniStence, el nombre interno que han dado a lo que vendría a ser un “EF++”, que mantiene sincronizado el mecanismo de persistencia (¡sea cual sea!) con el resto de capas de la aplicación. Esto es realmente espectacular: por ejemplo, si ampliamos el tamaño de un campo de la base de datos, ya no hay que preocuparse por modificar los formularios, pues las propiedades de los controles visuales detectados por el motor se actualizarán de forma automática; o si cambiamos el nombre de una propiedad en una entidad, se actualizará el nombre del campo en la base de datos, e incluso las etiquetas de descripción a nivel de interfaz de usuario. Pero ojo, que no se trata de un mecanismo de binding o mapeo como los existentes en la actualidad, sino de un proceso totalmente automático que nos vigilará continuamente e irá realizando estas tareas de forma silenciosa.
    
  • Autoimplementación de métodos, que utiliza la gigantesca base de conocimiento acumulado durante años para implementar métodos de forma automática, basándose únicamente en su nombre y signatura (parámetros de entrada y tipo de retorno). Por ejemplo, ya no será necesario implementar más el clásico método “long factorial(long n) ”: él lo hará por nosotros :-))
    
    Como puedes comprobar, PremoniSense™ además nos regala la reaparición estelar de nuestro viejo amigo Clippo, esta vez disfrazado de adivino. Al parecer se trata de un guiño de los desarrolladores de Visual Studio al equipo de Office… humor friki, supongo ;-D
    
  • Simplificación de algoritmos, un mecanismo capaz de replantear el código de métodos complejos, reescribiéndolos de forma más simple y mantenible de forma automática, basándose en los parámetros de entrada, los resultados de salida y el análisis semántico del procedimiento implementado. Internamente se conoce como PremoniKiss, por las iniciales de KISS, el famoso principio para el desarrollo de software que aboga por la simplicidad de las creaciones.
    
  • En la misma línea, PremoniYagni, un detector prematuro de funcionalidades y características inútiles, que nos alertarán cuando estemos comenzando a introducir en nuestras aplicaciones características que estadísticamente se conoce que no son utilizadas por los usuarios, o estemos entrando en el pantanoso terreno de la sobreingeniería. YAGNI son las iniciales de You ain’t gonna need it (“no vas a necesitarlo”).
    
  • Detección automática de dominios de aplicación, personalizando su comportamiento para hacer la experiencia de desarrollo más liviana. Así, una vez inferido el dominio del sistema, será capaz de generar automáticamente las entidades de datos, gestores, e incluso lógica de negocio más apropiada, y adaptar sus deducciones, consejos y acciones a dicho dominio.
  
  
  Algo realmente interesante de PremoniSense™ for Code es que el código que genera es dinámico, es decir, que es capaz de seguirle el rastro y modificarlo de forma automática cuando se produce algún cambio en las premisas de las que partió en el momento de inferir su generación, manteniéndolo siempre actualizado y correcto.

• Calidad (PremoniSense™ for Quality)
  PremoniSense™ también está preparado para utilizar su enorme base de conocimiento con objeto de incrementar exponencialmente la calidad de nuestras aplicaciones en varios ámbitos. Por citar algunos:
  
  
  • Generador de pruebas unitarias, que utilizará la base de conocimiento para generar por cada clase un set de pruebas de unidad  lo suficientemente extenso como para asegurar que son mayormente correctas. Basado inicialmente en el proyecto Pex de Microsoft Research, incrementa la calidad del código hasta niveles nunca vistos anteriormente, puesto que las pruebas serán generadas teniendo en cuenta el dominio de la aplicación y los fallos que se suelen producir en cada uno.
    
  • Autodocumentador de diseño, aunque sólo disponible para los poseedores de la próxima suite Office 2010, que creará partiendo de plantillas prediseñadas todo el juego de documentación de diseño de la aplicación, siguiendo los estándares definidos por diversas metodologías (entre las que se encuentra, curiosamente, Métrica 3).
    
  • Como una extensión del punto anterior, pero que vale la pena destacar de forma independiente, PremoniSense™ será capaz de generar un borrador de manual de usuario del sistema, basándose principalmente en tres factores: el conocimiento del comportamiento de los usuarios acumulado durante años, el interfaz que se haya creado y las funcionalidades implementadas. Obviamente, no nos dará todo el trabajo hecho, pero lo que hasta ahora se trataba de una ardua tarea de redacción se reducirá a un simple repaso y retoque de los textos.
    
  • Detección de procesos no finitos, que se acerca a la solución del clásico problema de la parada para máquinas de Turing, utilizando el motor estadístico de PremoniSense™ para determinar cuándo los algoritmos empleados en un sistema presentan incorrecciones que le harán entrar en un bucle infinito, antes de que esto se produzca. 
    
    
  • Detección de publicación prematura, se trata de un mecanismo de control sobre la base de código capaz de determinar cuándo un producto está suficientemente maduro para ser publicado (o desplegado a un servidor en producción) en función de su complejidad, número de pruebas funcionales y unitarias realizadas, y la extensa base de experiencias anteriores.
    

En resumen, que en breve vamos a asistir a lo que será, en mi opinión,  el avance más significativo para los desarrolladores desde la invención del copiar y pegar. Los vídeos que aparecen en el sitio oficial son simplemente espectaculares, no te los pierdas; si quieres pasar unos buenos ratos en estos días de fiesta, puedes descargar este software en la web de Microsoft. Pero ojo, si puedes, ve aumentando tu RAM, que PremoniSense™ se adueñará de 2GB cuando esté en ejecución.


Publicado en: Variable not found.

Tras algunos días de intenso debate, ayer quedó constituida SVBNet, la plataforma pro-salvación de Visual Basic, como movimiento independiente de la comunidad de desarrolladores de habla hispana aupa.net, cuyo objetivo es apoyar la continuidad del lenguaje y hacer presión para forzar un replanteamiento de su estrategia comercial.

Para el que todavía no esté al tanto de la historia, durante la segunda semana de diciembre ha tenido lugar en Dallas el encuentro de desarrolladores DevConn4, en el que Matt Gretz, destacado miembro del equipo de VB.NET, hacía público el Roadmap que Microsoft tiene previsto para este producto, que no trae buenas noticias para la gran comunidad de desarrolladores en Visual Basic, y que provocó un revuelo impresionante tanto en la sala del evento como en la blogosfera y medios especializados.

Resumidamente, el Roadmap prevé la progresiva desaparición de Visual Basic, mediante un plan de migración que facilitará los desarrolladores pasar a C# en un plazo de tres años. A partir de 2012 no se publicarán nuevas versiones de VB, por lo que, dado que el lenguaje no evolucionará para reflejar los cambios que sean introducidos a nivel de framework, lo llevará irremediablemente a su desaparición en no más de cinco años.

En líneas generales, el contexto actual y el panorama que nos espera, si nadie lo impide, es el siguiente:

• Primero, durante años se han ido introduciendo mejoras en Visual Basic .NET hasta cubrir la mayoría de características del framework e igualarlo en potencia a C#, con objeto de hacer más suave el salto de un lenguaje a otro. Por ejemplo, la inclusión en el actual VB.NET 9 de tal cantidad de novedades y cambios respecto a versiones anteriores, responden claramente a estas necesidades.
  
  Hasta aquí, todo es correcto y aporta exclusivamente ventajas. El problema viene ahora.
   


• La segunda gran acción podremos verla con el próximo Visual Studio 2010 y .Net 4.0, de los cuales ya es posible descargar previews. Para entonces, Visual Basic aparecerá con el nombre comercial VB# (VB Sharp), dando a entender que se trata de una versión de transición a C#, y en el que podremos encontrar el giro hacia una sintaxis más cercana a este lenguaje, como el uso de llaves en bloques (if, blucles while y for, etc.), estructuras compactas (como la sintaxis lambda o declaraciones menos verbosas), comentarios tipo C "/*", y otras lindezas que seguro que dejarán nuestro código VB bastante diferente al actual. Eso sí, para facilitarnos la vida, será el propio IDE el que nos ayude a acostumbrarnos a las particularidades sintácticas, sustituyendo sobre la marcha el código VB.NET tradicional por VB#.
  
  En esta fase también encontraremos los cambios que se van a producir en C# para dotarlo de algunas de las ventajas de Visual Basic, como los parámetros opcionales, con objeto de lograr una mayor confluencia y hacer más fácil la adopción del lenguaje por esta comunidad de desarrolladores.
   


• La última parte del plan se llevará a cabo en 2012 con Visual Studio (codename Moonwalker), que se distribuirá con .NET framework 5.0 (aka Greengarden) y no vendrá acompañado de una nueva versión de Visual Basic, sino de un asistente de migración a C#. Para esas fechas, además, se prevé que la mayoría de desarrolladores de Visual Basic haya adoptado VB#, por lo que el salto será, en palabras de Matt, "no traumático".

Finalmente, comentar que también hemos acordado el emblema de la plataforma pro-salvación de Visual Basic que podemos ir utilizando en nuestras páginas para dar difusión al movimiento hasta que tengamos lista la web oficial, que se prevé finalizada para primeros de año.

Si eres simpatizante de la causa, programas o has programado en alguna versión de Visual Basic, y tienes blog o una página relacionada con el desarrollo, descárgate esta imagen (¡por favor, no hagas hotlinking!) y colócala en un lugar visible apuntando al futuro sitio web de la plataforma. Si el diseño no encaja en tu web, no te preocupes: en breve tendremos a nuestra disposición nuevos botones en tamaños menores (125 y 250 píxeles de ancho) y con ciertas variaciones estéticas y nuevos colores, e incluso versiones en Flash y Silverlight, según Raúl Mondo, el diseñador que está realizando este excelente trabajo.

Y no olvides que cuanto más difundamos esta iniciativa, más fuerza tendremos ante la multinacional para hacer que se replantee su estrategia.

¡Larga vida a VB.NET!



Publicado en: www.variablenotfound.com.

Aunque hace varias semanas que el rumor saltó a la blogosfera, hoy han confirmado la noticia en una rueda de prensa conjunta: a partir del próximo 1 de enero Stallman formará parte de la plantilla de Microsoft en Redmond.

La nota de prensa publicada por Microsoft recoge, textualmente, los siguientes párrafos:

"Microsoft siempre apuesta por el talento, y Richard Stallman es uno de los más reputados ideólogos del mundo del desarrollo del software."
[...]
"Sin duda, se trata de una de las incorporaciones más importantes a la compañía de los últimos años, por lo que no hemos escatimado en recursos. Las negociaciones las han llevado a cabo directamente Gates y Ballmer, los dos máximos directivos, lo que demuestra la magnitud de la apuesta estratégica que se está llevando a cabo"

Por su parte, Richard Stallman, que nunca ha destacado por su aprecio a la multinacional, justifica la decisión en su blog:

"En realidad nuestras posturas nunca han estado muy alejadas, aunque veíamos las cosas desde perspectivas diferentes. Microsoft, al igual que GNU y el conjunto del movimiento Open Source, pretende hacer llegar el software a todo el mundo y hacer que sea un bien universal."
[...]
"Hay más puntos en común que diferencias, sólo era cuestión de sentarnos y dialogar sobre hacia dónde podíamos caminar juntos"

En principio Stallman encabezará una nueva división en Microsoft destinada al análisis y evaluación de soluciones de software libre para el segmento SOHO (Small Office, Home Office) y grandes corporaciones, así como a dirigir la adaptación de ciertos componentes del microkernel de Linux a Windows Server 2012 (codename "MindBreaker"), que se lanzará al mercado en unos años y del que ya están disponibles vía MSDN algunos whitepapers y documentos muy muy preliminares.

Este movimiento forma parte de la estrategia de acercamiento de Microsoft al mundo del software libre, como se lleva viendo algún tiempo. Los acuerdos entre Microsft y Novell, la publicación del código fuente de .NET Framework y la gran cantidad de líneas de actuación que están promoviendo así lo demuestran.

Y por cierto, se dice que el próximo en la lista de Most Wanted People de Microsoft y con el que hay conversaciones bastante avanzadas (de nuevo, pues ya las hubo hace tiempo) es Miguel de Icaza, líder del proyecto Mono, aunque él todavía no ha declarado nada al respecto. Otros en la lista son el mismísimo Linus Torvalds, creador del primer núcleo de Linux, firme candidato a liderar el área de arquitectura de servidores y servicios, y Vinton Cerf, considerado el padre de internet, para el puesto de Technical Chief Developer de la línea de productos Internet Explorer.

Habrá que esperar para ver a qué conduce esta reorientación en la estrategia que se viene observando desde hace unos meses, y sobre todo en qué se traduce la fiebre por los fichajes de figuras del mundillo. El tiempo lo dirá.



Publicado en: www.variablenotfound.com.