Un caso de fracaso… o dos

Bueno, esta es otra de esas entradas nada técnicas y personalísimas, en la que voy a contar varias cosas, respoder a las inquietudes que asertus ha comentado en la entrada anterior.

Generalmente los casos de éxito se suelen airear a lo grande, a bombo y platillo, con grandes titulares, pero los fracasos se suelen ocultar debajo de la alfombra, y cuanto menos se sepa de ellos, mejor.

Pues bien, yo voy a contar aquí un proyecto que ha fracasado, o al menos lo ha hecho según el planteamiento original, y luego comentaré algo sobre Evernote 4 y su bajada de WPF…

Aparte del firmware, y a veces junto con él, suelo entregar una aplicación para PC que se encarga de lidiar con la electrónica que vendemos, o simplemente demuestra su funcionamiento, aunque las más de las veces sirve como herramienta de configuración y verificación.

Es un proyecto bastante complejo que ha arrancado y parado varias veces, ha mutado y vuelto a mutar, pero al final estuvo claro qué se quería, y cómo. Fue tiempo de ponerse a picar código como un loco. De eso hace unos meses, y más o menos el esfuerzo duró como dos meses hasta que nuevas y más urgentes tareas volvieron a pausarlo, pero esta vez no porque se llegara a un callejón sin salida (y no me refiero a técnico, sino comercial o de concepto), sino porque se vio que había tareas de mayor prioridad.

Se detuvo en un punto interesante: la parte del PC estaba casi terminada, por lo menos la primera fase, y ya iba a pasar al hardware, aunque estimé que necesitaría otra semana más para estar listo y empezar con la interoperabilidad entre el PC y la electrónica. Una siguiente iteración, cuando programa y placa se hablaran entre ellos, volvería al PC para finiquitarlo y dedicar el resto del tiempo al desarrollo embebido, cienes y cienes de variantes del firmware que el programa del PC debería ensamblar e insertar en la placa…

Esos dos meses fueron un poco como de pesadilla. Entusiasmado y emocionado, con mucha ilusión, comencé a hacerlo con el Feature Pack de Visual Studio 2008. Sí, ya sabéis, la Ribbon, las ventanas estilo Visual Studio y todo eso, la última versión de MFC. De esa pelea, porque pelea sin cuartel fue, tenéis las últimas entradas de mi sección MFC en el Guille. En concreto iba a aprovechar todo un esqueleto de Visual Studio incluyendo el control de propiedades igual que se trabaja con .NET. Es decir, el programa tendría un Editor de Propiedades y una “Paleta de Componentes” como las tiene el .NET. Pero relacionadas con mi firmware, y el usuario podría coger pedazos de firmware, echarlos sobre un contenedor y luego ir cambiando las propiedades. Finalmente, una opción enviaría dicho firmware a la placa.

Bonito, ¿no?

Bueno, pues fue un fracaso. No solo tuve que pelearme con todas y cada una de las cosas que iba añadiendo, sino que luego no funcionaban ni como estaban documentadas (en el caso de que lo estuvieran) ni como dicta la razón. Entre las cosas que me costó mucho hacer funcionar está el personalizar las barras de herramientas, hacer funcionar el editor de propiedades, y que el modelo Documento/Vista funcionara como yo quería…

No voy a contar ninguna pelea, ni voy a poner el grito en el cielo, ya no, ya me he cansado de predicar en el desierto. Básicamente me tuve que leer medio internet, y navegar hasta las profundidades del código fuente de MFC para, en primer lugar saber cómo funcionaba y por qué hacía lo que hacía, y en segundo para saber cómo heredar y cambiar el comportamiento y mirar por qué no funcionaba como se esperaba…

El summum de la desesperación vino cuando pasé el proyecto a Visual Studio 2010 y empezaron a aparecerme fugas de memoria que en la versión 2008 no había (o si las había no eran detectadas)… así que volví a la versión 2008SP1.

Pero ahí no terminan las cosas, las cosas terminan cuando, de repente, los diálogos dejaron de funcionar. Me explico. Tengo varias clases base heredadas de CDialogEx que usan una plantilla de diálogo y que implementan el contenido común. Luego heredo de ellas una jerarquía pero sin plantilla y con pocas líneas modifico el comportamiento. No son muchas, son cuatro clases base de las que heredan cuatro hijas de cada una de ellas, pero que creadas de esta forma ahorran muchos dolores de cabeza y concentran la funcionalidad siempre en un mismo sitio.

Pues bien, eso dejó de funcionar, de repente, sin tocar nada. No he investigado mucho, pero parece ser que la cadena de constructores se interrumpe cuando uno de ellos es incapaz de encontrar el recurso de diálogo en el ejecutable, diálogo que seguro existe, no tiene ningún problema y que puedo ver en el editor de Visual Studio. El constructor retorna a medio construir, y cuando se llama a ShowDialog() se dispara un ASSERT que pone un insulso mensaje en la ventana de Debug y ni se abre el diálogo, ni se genera una excepción, ni pasa nada de nada. Como el silencio administrativo pero en programa.

Ahí fue cuando decidí parar la vez anterior, o más bien llegó la fecha límite y tuve que cambiar a otra cosa. A últimos de la semana pasada retomé el proyecto, ví lo de los construtores y… lo mandé a tomar por culo.

Con esas misma palabras.

El martes empecé una versión limitada en funcionalidad, en Windows Forms y C#. Básicamente se abre un diálogo que deja elegir entre unos módulos, y luego, Form a Form, permite modificar el comportamiento. Y finalmente dándole a un botón envías el resultado. La aplicación se guarda a sí misma, la información está en ficheros INI de texto, y tiene casi toda la funcionalidad que la anterior, pero hecho de forma bastante más chapucera.

También me he encontrado con algún tropiezo, pero en su mayoría debido a mi propia torpeza. De todos modos estamos a jueves (han pasado tres días) y… ¡Ya estoy en la misma fase en la que acabé la otra vez! Es decir, he tardado 3 días a hacer en .NET lo que en MFC me llevó casi dos meses. Evidentemente no es la misma aplicación ni de lejos, ni tan bonita ni tan funcional como era la otra, y creo que no me atrevería a hacer algo de complejidad similar en C#. Ya no me fío después de cómo las he pasado con .NET…

No me malinterpretéis, con esto que os he contado no quiero decir que .NET sea la rehostia, que no lo es, de hecho ahora tengo un problema con un thread que me parece que es una limitación (que no un bug) de .NET…

Por otro lado, y es un consenso entre varios MVP de C++ y entre los programadores en general, que el Feature Pack es algo bloated, a-funcional y lleno de enormes torpezas. Complejo a conciencia, escasamente documentado, y la versión 2010 tiene fugas de memoria internas (Haced la prueba: construid una aplicación de cuadro de diálogo sin más, ejecutadla y cerradla. La ventana de depuración os dará fugas de memoria sin que el usuario haya añadido una sola línea de código).

Añadamos que nos genera ejecutables de más de 2 megas de tamaño… Ciertamente un fracaso, y no propio. Yo al menos me he sacado las castañas del fuego en tres días, a ver lo que tarda Microsoft.

***

Otra de las noticias que está corriendo como la pólvora es que Evernote 4 ha abandonado WPF en pro de C++ y del código nativo. Más o menos cuentan lo que yo ya dije hace mucho tiempo: .NET no vale para aplicaciones de sistema ni para nada medianamente complejo que no sea para lo que se ha pensado, que son aplicaciones verticales de bases de datos sin muchos Forms (ni muy complejos) y como competencia directa de Java (que todavía vale menos, IMHO).

Una prueba de ellos es que, a fecha de hoy, ninguna aplicación de Microsoft está enteramente hecha en .NET. No Office, ni partes interesantes de Windows, ni otras herramientas enterprise. Lo más cercano es el editor de Visual Studio 2010, que no está mal pero que funciona sensiblemente más lento que el del 2008, y cuando digo más lento es más lento. En mi caso, a veces ni siquiera me pilla un doble clic rápido. Además, como muestra un botón, ya que la gente que estaba haciendo el editor tuvo que ponerse seria con la que hacía WPF para que solucionaran serios problemas tanto de rendimiento como de funcionalidad, o al menos eso es lo que se deja entrever en algunas noticias y se comenta en los mentideros de la red.

Hay un tercer problema, y es que la supuesta unificación del API de .NET para deshacerse del de Win32 se está convirtiendo, con el tiempo, igual de disparejo, con las mismas inconsistencias entre diferentes partes…

Es muy posible que en fechas no muy lejanas veamos morir a más lenguajes .NET, seguro que C++/CLI entre ellos. De momento en Visual C++ 2010 no tiene IntelliSense porque al parecer no les dio tiempo a implementarlo, pero es que tampoco se ha actualizado para añadir algunas de las cosas de .NET 4.0…

Así que, una vez desaparecido éste, gente del Visual Basic, poneros a remojo. Y los Accesseros también. Son mis 2 céntimos sin usar información privilegiada de ningún tipo, pero son cosas que se ven venir. Y ya de paso metamos a Windows Phone, que tampoco creo que dure mucho y eso que acaba de nacer…

Volviendo a Evernote, y habiendo hecho un análisis somero, parece ser que han utilizado WTL, ATL y STL, con librerías de terceros, pero no MFC (No me extraña). De hecho, aplicaciones masivamente utilizadas como Chrome o Picasa no usan ni MFC ni WPF (ni .NET). Por algo será.

Tampoco han usado QT, cosa que en principio me extraña un poco porque es EL FRAMEWORK de moda y de éxito… Yo llevo bastante tiempo detrás de aprender QT, pero no me decido. Cojo un libro, leo un par de capítulos y lo dejo, para repetir al cabo de unos meses. Ahora con el iMAC en marcha veo QT de otra forma, y de hecho los dos libros de Cocoa (el de la Vespa y el Unleashed) creo que van a dormir el sueño de los justos…

Ah, por cierto, esta entrada ha sido escrita con Word 2008 para MAC, guardada como un fichero HTML, cargado en el IE 7 con una máquina virtual windows, visto su código fuente y copiado directamente como HTML en el editor WEB del blog (cosas de la interoperabilidad). Las aplicaciones Windows han estado corriendo en modo Unity y, Asertus, de momento tengo tanta faena en el curro que cuando llego a casa (antes no llegaba a casa, estaba en casa) sólo tengo tiempo y ganas de bajarme el correo personal, navegar un rato e irme a dormir. Tengo instalado QT tanto en la virtual Windows como en el iMAC, pero apenas lo he usado por encima, y eso que me está rondando una idea para un juego que…