.NET o no .NET, esa es la cuestión : rationale

ReSharper para Visual Studio

Rafael Ontivero — Sat, 17 Nov 2012 12:55:10 GMT

Esta es una historia un tanto extraña porque ni en mis más locos sueños hubiera yo decidido usar este complemento en Visual Studio. No porque no me guste la empresa, ni porque piense que el producto sea malo.

Simplemente porque no soy yo mucho de añadir complementos a mi herramienta de trabajo más allá de las cosas imprescindibles, más que nada porque los tiempos de carga se alargan en extremo, y la estabilidad de Visual Studio decae en picado.

Por ejemplo, si ya la versión 2010 de VS anda algo inestable, con vahídos extraños, cuando le añades el SDK de Windows Phone la cosa empeora y te encuentras con que a veces el compilador se encuentra errores fantasma que sólo él ve, o simplemente el IDE se queda autista.

Añádele alguna herramienta más y eres un firme candidato a lanzar tu ordenador por la ventana y dedicarte a criar setas en el sótano de tu abuelo.

Sin embargo Visual Studio 2012 parece más estable, y he estado como dos semanas usándolo sin que hiciera cosas raras, incluso tras añadirle el citado SDK, que es imprescindible para mi en estos momentos.

De repente a un compañero que trabaja en la aplicación de Java de mi empresa le compraron el IntelliJ y comenzó a comentar las bondades del producto y cómo había pasado de desesperarse y tirarse de los pelos con la cosa esa del Eclipse a tener un IDE en condiciones.

Eso me llevó a recordar que cuando asisto a alguna charla virtual suelen regalar un ReSharper a los asistentes… y una cosa me llevó a la otra, y es que la envidia es tiñosa, y muy mala malosa, y yo soy el peor de todos. Por lo tanto entré en la web de JetBrains y me bajé el producto en su versión demo de treinta días y…

¡¡MADRE DEL AMOR HERMOSO!!

¡Como alguien me quite el producto me lo como con ropa y todo! ¿Cómo he podido vivir yo sin eso?

A ver, que no estoy exagerando ni mucho menos. El producto cuesta sus pelas, pero os aseguro que las vale. Ahora que estoy desarrollando en C# porque no tengo más cojones, se me ha hecho prácticamente indispensable y eso que lo llevo usando tan sólo unas dos semanas.

Os cuento lo que hace. Y ya me conocéis, que yo no me caso con nadie y no tengo pelos en la lengua.

***

ReSharper es una extensión a Visual Studio (creo que soportan todas las versiones del producto desde la 2003 menos las Express). En mi caso lo instalé en mi Visual Studio Ultimate de la MSDN.

Lo que hace el producto es ayudarte a teclear código, pero a todos los niveles. Hay que verlo para creerlo. Cuando está instalado lo que más llama la atención es que te coloca una tira vertical al lado derecho de la ventana de edición, similar a la de la derecha en donde pones los breakpoints, bookmarks y el IDE te marca el código modificado.

En esa columna te coloca una serie de rayitas horizontales de colorines. Rojo para los errores. Naranja para las mejoras (ahora os cuento), verde para las sugerencias. Creo que hay más colores, pero en este momento no me acuerdo (son las cosas de estar tirado en el sofá tecleando en mi MacBook). Arriba del todo hay una marca global que te dice el

Cuando posas el ratón sobre la rayita, te dice de qué va la cosa, y si haces clic te lleva al código fuente en cuestión.

Y aquí es donde viene lo interesante. Te ofrece la mejora o la solución, y si le dices que sí, te lo corrige.

Pero os aseguro que es algo terrorífico. Hay cosas más o menos chorras, como cambiar un tipo por una variable automática, pero otras dan miedo.

Es capaz de cambiar tus bucles for o foreach por sentencias LINQ. Con eso ya os lo he dicho todo. A mi al menos eso me da mucho miedo. Del bueno, ojo. Que coja tres bucles anidados y te los convierta en una sentencia LINQ de una línea me deja embobado.

Peor hay más. Simplifica los operadores lambda, te transforma bloques de código en otros menos agresivos con la aplicación, te formatea el código, te ofrece lo que vas a escribir a continuación…

No sé, cada vez que hago algo nuevo me sorprendo por las posibilidades que te ofrece. Otra de las cosas que me trae loco es que es capaz de eliminar código redundante, como la creación de delegados o la eliminación de código redundante.

Os pongo un ejemplo que me dejó todo loco.

Yo solía poner sentencias del tipo:

Debug.WriteLine(String.Format(“bla bla {0} bla bla {1}”,a.Hola,a.Adios));

Pues bien, él me sugiere

Debug.WriteLine(“bla bla {0} bla bla {1}”,a.Hola,a.Adios);

Vale. Tú lo sabes. Yo no lo sabía hasta que no me lo ofreció ReSharper. Y así con muchas cosas más, pero lo que de verdad me admira son las transformaciones a LINQ y viceversa. No me canso de repetirlo. Bucles a LINQ. Bucles a LINQ.

También tiene soporte en XAML. Es decir, editar XAML pasa de ser una pesadilla a ser bastante mejor. Si tu usas Blend, mejor para ti. Yo la última vez que intenté hacer algo con el producto terminé hasta la coronilla. Entre excepciones y la *** manía de ponerle márgenes hasta a su madre… Pues bien, con ReSharper editar a mano XAML también mejora la cosa.

Refactoring. Todo lo que te puedas imaginar y más. Si añadimos las reglas para estilo de código, te detecta las variables y los métodos que no lo siguen, ofreciéndote cambiarlos si así lo deseas. Y es una cosa a la que vas a decir que sí, porque esas rayitas naranjas no molan nada, y que no te las vea el jefe… :-P

Lo dicho, en cuanto te sales de las guías de estilo el producto no solo te lo dice sino que te ofrece la posibilidad de cambiarlo. Por supuesto puedes definir las tuyas, no las que el programa quiera.

Como abras la pantalla de opciones te vas a caer de culo, porque puedes configurar cualquier cosa. Por tener hasta tienes “juegos de configuración”, pudendo cargar la que quieras cuando quieras, por si tienes un proyecto con unas reglas y otro con otras.

También tiene algunas chorradillas (es un decir) interesantes, como que te pinta una raya de color debajo de un número que represente un código ARGB, por poner un ejemplo. Son cosas que no se echan en falta hasta que no las tienen y luego te las quitan.

Ya para terminar comentaros los Find Usages. Algo así como Find all references pero con muchos esteroides. Pones el cursor sobre un símbolo, le das a la opción con el botón derecho del ratón y goza. Así he encontrado un par de problemas serios de sincronización que me tenían todo loco, y encima en un rato de nada.

Opciones que no he probado han sido la de limpiar el código de toda la solución de una tacada y otras que seguro se me escapan.

Bueno, pues lo dicho, si quieres aumentar tu productividad de forma bastante seria, prueba el producto. Seguro que luego pasas por caja. Y si entráis en la Web de JetBrains podréis ver capturas de pantallas y algún vídeo enseñando lo que es capaz de hacer.

Multiplataforma de la buena (mismo código fuente)

Rafael Ontivero — Tue, 03 Jul 2012 18:32:00 GMT

Antes de empezar, y de que me deis caña de la buena, quiero decir que todo esto son elucubraciones personales mías y que lo más seguro nadie esté de acuerdo conmigo. Dicho esto, vamos al meollo del asunto.

Ya sabéis que me he ido distanciando un poco de la plataforma Windows a la vez que me he acercado a la de Apple sin realizar el cambio total. De Linux no quiero hablar, porque cada vez que tengo que hacer algo con él, sudo tinta china y al final, tras muchos cabezazos, suelo terminar desistiendo.

Lo último fue compilar el SDK de lector del libros electrónicos Boox i62HD. Tras instalar una Debian 6 x86 virtual en vmWare Fusion (el Workstation del MAC) por segunda vez, ya que la primera falló estrepitosamente porque el instalador sí que reconoció el discos duro SCSI pero luego el kernel instalado no, fui incapaz de compilarlo.

Primero me encontré con una serie de paquetes que no estaban presentes y que el comprobador del SDK no avisó que faltaban, lo que te obliga a recorrer la cadena de errores para descubrir que te falta esto o aquello.

Lo último, y que todavía está sin solucionar, es que falta una dependencia en un fichero de proyecto, en concreto incluir “-l z” en el lugar correcto, que es enlazar con la biblioteca zlib. En mi caso el problema no es saber qué falta, sino dónde añadirlo. Tras varios intentos infructuosos y muchas páginas de internet leídas, no conseguí solucionarlo.

Había un bug similar si instalabas el SDK en un linux x64, pero el mío era x86, y el parche existente intentaba modificar ficheros que no existen (al menos en mi instalación).

Pues bien, ni me han hecho ni *** caso ni tampoco lo han solucionado, lo que me lleva a preguntarme cómo cojones están programando. Y menos mal que usé una Debian, que es la misma distribución que usan los que han creado el SDK, que si llego a instalarme otra cosa…

Esto es un ejemplo de la desidia reinante en Linux. Lo dije en un foro hace tiempo. Los programadores de linux me parecen muy poco profesionales, tendentes a montar cualquier cosa que les parezca c00l y luego, cuando viene la hora de la verdad y demostrar que se es un programador con dos cojones, pasan del tema porque eso de solucionar bugs ya no es tan fascinante como lo otro, y encima solventar cualquier cosa son un montón de horas en las que no estamos subiendo nuestra supuesta caché c00l en la comunidad.

Aparte de deleznable, me parece una práctica muy poco seria y que sigue dejando a Linux como lo que es: o bien un juguete para niños falsamente interesantes, o bien algo destinado a servidores de bajo coste, y si no contadme cómo es el único sistema operativo que ha reventado con el segundo extra añadido hace unos días.

Por lo tanto, para mi el desarrollo en Linux queda completamente descartado a corto y largo plazo, por lo menos hasta que se pongan un cohete en el culo, cosa que dudo mucho que ocurra jamás (y espero equivocarme).

***

Luego vino el tema del swtiching. Lo cierto es que tras el entusiasmo inicial, la cosa deja mucho que desear en cuanto a usabilidad y, sí, rendimiento. Ya lo he ido comentando por este blog con anterioridad. OS X Lion y Mountain Lion, si los comparamos con XP, son la rehostia, pero comparados con Windows 7 dejan mucho, pero mucho que desear. La usabilidad es pésima, aparte de ciertos problemas de ergonomía a los que al final uno termina acostumbrándose.

También es cierto que cuando le coges el tranquillo ya no hay vuelta atrás, más que nada por la integración de todos los elementos, más todavía si tienes un iPad o un iPhone. Puedes conseguir casi lo mismo en Windows, pero no de forma tan integrada ni coherente.

Respecto al rendimiento, diré que por fin tengo un MAC que funciona como yo quiero, tras gastarme más de 300 euros en añadirle un segundo disco SSD al iMac de 27”. Es decir, en este momento mi máquina principal es un iMac de mediados del 2011 con un i7 a 3.4 GHz, un disco SSD de 256GB como disco de sistema para el OS X y uno de 1TB como secundario para datos. En este momento el disco FireWire de 2TB que usaba como secundario lo tengo como copia de Time Machine y, aparte de que arranca en 8 segundos (antes tardaba más de dos minutos y el disco seguía rascando hasta casi los diez), sólo veo la roseta multicolor de la muerte cuando se para el disco mecánico y tiene que arrancar. Además, la carga de aplicaciones, incluso las pesadas como Pages o Word, es prácticamente instantánea.

Y justo ahora, mientras escribo esto en Scrivener, tengo abierta una máquina virtual en Unity con Windows 7 x86 en la que se está instalando el SP1 de Visual Studio 2010 porque he instalado el AtmelStudio, que es un IDE basado en el Microsoft para generar ejecutables para los microprocesadores de Atmel.

***

Acabo de hacer una pausa para lanzar el JTAG MK-II, conectarlo a Windows y verificar que el AtmelStudio lo reconoce y funciona, todo ello virtualizado. Que es una de las cosas a las que quería llegar. Con un buen producto de virtualización, uno puede tener lo mejor de ambos mundos. Un equipo silencioso a más no poder que ejecuta de forma transparente tanto aplicaciones Windows como OS X sin mayor complicación que molestarse un poco en configurar las cosas, y encima con un rendimiento equivalente a si se ejecutara en real.

Evidentemente tenemos BootCamp, pero os aseguro que Windows no funciona igual que en un PC real, y perdemos todas las cosas buenas que puedes hacer con un MAC.

***

Pero no es a eso a lo que me refiero. Más bien todo esto es una especie de parche o pegote. De lo que realmente quiero hablar es de desarrollar para al menos Windows y MAC sin tener que crear dos programas diferentes.

Descartamos de entrada que un mismo ejecutable pueda funcionar en ambas plataformas. Por parte de los dos contendientes queda descartado. Microsoft podría haber hecho .NET para OS X o Apple Cocoa para Windows, pero no creo que eso vaya a ocurrir nunca jamás.

La única posible solución es Mono, pero ignoro sin un EXE de Windows se lanzará en un MAC o no, y lo voy a descartar por razonamientos que expondré más adelante.

***

Por lo tanto, la otra posible solución es compatibilidad en el código fuente. Que yo conozca, sólo tenemos dos grandes contendientes: QT y lo que ahora es Embarcadero pero que todos conocemos como Delphi y/o C++Builder.

De QT he hablado ya por aquí, pero no como plataforma cruzada. He estado usándolo un poco, en un proyecto en donde trabajaba, pero sólo para generar aplicaciones Windows.

En principio QT es multiplataforma si no te sales del propio Framework, y de hecho he podido compilar un mismo código fuente en ambas plataformas sin más que compilar o bien desde Windows o bien desde OS X. Hay que tener mucho cuidado y usar el propio Creator de QT, y todos los ficheros servirán sin problema. Eso sí, necesitas dos ordenadores, uno para cada plataforma. Tres si quieres también Linux.

Esto nos trae a lo que hemos tratado antes. Como no es posible ejecutar OS X desde una máquina Windows (no sin violar licencias y sin hacks y sin limitaciones y fallos aleatorios), la única solución es tener un MAC más o menos potente y usar un Windows virtualizado, compartiendo la carpeta de desarrollo.

En mi caso, pese a no estar haciendo nada más que estudiar ahora que estoy en paro y tengo tiempo para jugar con todo esto, tengo una carpeta en donde está todo mi código fuente, carpeta que está compartida con SkyDrive y de ese modo puedo verla también en mi ordenador Windows (no el virtualizado), aparte de hacer copia de seguridad de forma automática.

Ojo con sincronizar mediante SkyDrive entre real y virtual, porque el tema no es instantáneo y puedes armar un buen jaleo. La solución es compartir una carpeta de tu MAC en tu Windows virtual. Con Fusion la cosa funciona muy bien, y hasta Embarcadero ha solucionado los problemas que tenía para compilar sobre carpetas de red (Microsoft siempre lo ha tenido resuelto, incluso dando la posibilidad de cachear localmente los ficheros intermedios).

Si nos damos cuenta, con QT tenemos que compilar y ejecutar en cada máquina, lo que en principio no es un gran problema, pero sí cuando quieres algo que no está en el Framework. Ahí si que tienes que, mediante compilación condicional, sacarte tu mismo las castañas del fuego. Dada mi escasa experiencia con QT multiplataforma, no puedo asegurar si es algo muy habitual o no.

***

El otro participante es Embarcadero, con su FireMonkey bajo Delphi/C++ Builder. La historia de todo esto es un poco rocambolesca, ya que la empresa ha llevado muchos años implementando compilación condicional en su VCL. Sólo hay que mirar el código fuente de cualquier versión (creo que desde la 2009) y ver cómo muchos ficheros tienen secciones para Windows, MAC y Linux.

Uno, por tanto, se esperaba que cualquier día anunciaran que la VCL se había convertido en multiplataforma y que se podría compilar para estos tres sistemas operativos.

Pero no, Embarcadero compró un producto a medio hacer y en seis meses lo transformó en su FireMonkey, que anunció a bombo y platillo con su nueva versión de RAD Studio XE2. Que por cierto se encuentra completamente lleno de bugs y no hay entrada de blog explicando esta o aquella característica que no hable de que hay un problema y que han tenido de resolverlo de alguna manera. Y es que seis meses es muy poco tiempo.

FireMonkey es una gran idea implementada muy pobremente. La idea es usar el IDE de Delphi o de C++ Builder para, a partir de un mismo código fuente, generar un ejecutable Windows o MAC, pero siempre desde Windows, por lo que estamos ante el mismo problema que antes.

La ventaja aquí es que puedes hacerlo todo desde Windows, hasta depurar. Es decir, es necesario instalar un servidor en el lado MAC, servidor que te va a permitir enviar el bundle OS X al MAC y depurarlo.

Y como todo primer producto, está completamente lleno de bugs y da muchos problemas, tanto el IDE como la depuración remota y el framework en sí. Embarcadero lleva sacados cinco parches, uno de ellos tan grande que exige reinstalarlo todo, que mejoran algo pero no mucho.

Y para más INRI, son aplicaciones de 32 bits, cosa que en los MAC se está acabando a pasos agigantados.

Esperemos que el XE3, que saldrá este verano, mejor algo la cosa.

***

Nos falta comentar Mono, el C# multiplataforma y de código abierto. Ya he hablado algo de él aquí con anterioridad, pero ahora voy a matizar un poco más. Mono engloba una serie de tecnologías más o menos integradas que comparten un mismo lenguaje de programación: C#.

Basado en ports, todo el meollo se centra en un IDE (disponible para ambas plataformas, como el de QT) que permite crear aplicaciones basadas en los ya citados ports, de los que disonemos de varios según qué plataforma.

Por un lado tenemos el de Windows.Forms, que nos permitirá generar código compatible con la tecnología de Microsoft y ejecutar en Windows, MAC y Linux. GTK# es otro de ellos. También está MonoMAC, en exclusiva para MAC. Hay más pero nos detenemos aquí.

La idea es que cada port conserva la idiosincrasia de cada origen. Es decir, el API de GTK# es el GTK pero traducido a C#, y así con todos. Es una buena idea y en general, se puede generar código para Windows y MAC sin problemas mayores que los que tendríamos con QT.

***

Pero ahora viene el tío de la rebaja. Hemos visto algunas pegas que tienen todos estos sistemas de desarrollo, pero no son las peores de todas. De todos modos, si desarrollas para MAC necesitarás un MAC, y lo mismo para Windows, así que llevar a cabo esas tareas en ambas máquinas no es todo lo malo que se puede esperar, y de hecho en todos los casos existen soluciones bastante óptimas, aunque lo más deseable sería el acercamiento de Embarcadero, con compila en un sitio, ejecuta en dos.

La mayor pega de todas consiste en que prácticamente ninguno de estos sistemas pinta los controles como nativos. QT podría salvarse por los pelos, pero ni FireMonkey ni Mono, salvo MonoMac, aparecen como aplicaciones nativas. En la documentación de algunos productos la llaman hasta “alien”. Ya os podéis imaginar. Y si bien en Windows un usuario normal puede aceptar ciertos interfaces exóticos, un fanboy (perdón, maquero) de pro seguro que te manda a la mierda con todas sus palabras, y encima con razón.

El caso de MonoMac no se aplica, ya que no podremos compartir código fuente con Windows puesto que se trata de un envoltorio sencillo sobre el propio Cocoa con la idiosincrasia de OS X.

Por lo tanto, el único Framework que sé de forma fehaciente que ha entrado en la App Store de los MAC ha sido QT tras aplicar unos parches para evitar que el propio QT modificara ficheros dentro del bundle. De todos modos no sé qué pasará con el Sandboxing y si QT (y los demás) lo soportan.

Finalmente, está completamente claro que, a fecha de hoy, desarrollar en multiplataforma de manera coherente continua prohibido, principalmente por limitaciones de los Frameworks existentes que de problemas técnicos, dado que el rendimiento y las herramientas base (como compiladores de plataforma cruzada o lenguajes comunes en diferentes plataformas), están más que maduros.

Tan sólo habría que crear un Framework que utilizara los controles nativos de cada plataforma, cosa que a fecha de hoy no existe (más sobre esto luego).

***

¿Qué nos queda, pues? Tan sencillo y tan complejo como dividir nuestra aplicación en dos partes. La primera, la parte visual, tendremos que hacerla diferente para cada plataforma. Objective-C en MAC, Win32 (MFC, o cualquier otro que pinte nativo), y la parte no visual o el núcleo de nuestro programa en algún lenguaje común, como puede ser C++ y STL y mantener al loro todo el tema para que compile y funcione en todos los sistemas de destino…

Es más trabajo, pero creo que es la única forma de mantener un interfaz visual nativo y coherente. El problema viene cuando nuestra aplicación es demasiado simple de modo que mantener esta estructura es más costoso que crear dos programas de forma independiente.

Aparte, claro está, la bajada de rendimiento al tener que desacoplar ambas partes, aunque esto es muy bueno y debería ser una constante en cualquier desarrollo no trivial, aunque estemos haciéndolo solo para Windows o sólo para MAC. No obstante, a veces la caída de rendimiento es tal, o el programa es tan meramente visual que este acercamiento no es aplicable.

***

Si os dais cuenta no he entrado en el tema de código abierto versus código cerrado, y es que para el programador medio, se la trae floja si tiene el fuente o no de lo que esté usando: no lo va a mirar porque o bien no tiene tiempo o bien no está capacitado.

Tampoco he cubierto el tema Metro de Windows 8, que está de lado del tema móvil, en el que no he entrado pese a haber también Frameworks genéricos. Aquí estamos igual, pero ahora las plataformas son Windows Phone, Windows Metro (o RT), Android e iOS, y si las de Windows y MAC son disparejas, no os digo estas. Y, a fecha de hoy, que yo sepa, no hay ningún Framework multiplataforma y compatible. FireMonkey promete llegar a Android, Metro y a C++ en próximas versiones, pero si ya con dos plataformas la cosa está como está, no quiero saber cuando haya tantas…

***

Me falta hablar de un jugador que no he nombrado y que tiene muy buena pinta, quizás la mejor de todas pero, como apenas lo he probado, lo dejo para una futura entrada. Se llama wxWidgets y hace tiempo que hablé de él aquí, pero para Windows. Estamos ante un Framework con mucha solera en el mundo del desarrollo y que usan empresas como Google en su producto Google Drive a través de wxPython.

Y la mayor ventaja está en que, aparte de estar disponible para alguna que otra plataforma embebida, los controles son los nativos de cada sistema operativo.

***

QT en Windows y OS X (Fijaos cómo los controles son casi nativos en cada sistema).

FireMonkey en Windows y OS X (Esto no pasa la MAC App Store ni a golpe de talonario. Por no aparecer ni el menú aparece donde debe).

WxWidgets en OS X (Todos los controles son nativos).

Visual C++ 2012 soportará Windows XP

Rafael Ontivero — Fri, 15 Jun 2012 20:49:28 GMT

Dicho así, a bote pronto, puede parecer una tontería, pero no lo es. Los que hayan estado probando las diferentes versiones alfas, betas y omicrones de Visual C++ 11 se habrán dado cuenta de que no generan código para Windows XP.

El motivo no era otro más que se han hecho una serie de mejoras al runtime de C++ (ya sabéis, la biblioteca de C y de C++) que se basan en una serie de funciones de Win32 que no están presentes en Windows Xp y sí en Vista y siguientes.

La respuesta fácil sería decir que han hecho eso para empezar a ir descartando a XP como sistema operativo soportado y forzar que los nuevos programas no funcionen con él, pero a la vista de las noticias no ha sido así. De hecho, hace poco tiempo alguien publicó la forma de soportar XP con las versiones beta ya publicadas mediante un truco. No me preguntéis cómo porque no lo he mirado.

Independientemente de eso, cuando un programa debe ejecutarse en un sistema que no tiene todas las importaciones de, por ejemplo, Kernel32.DLL, lo que hace es realizar una carga parcial o suministrar funciones dummy para que el sistema funcione. Es decir, si por ejemplo el runtime de C++ llama a una supuesta función de Kernel32.DLL llamada UnaFuncion() que no está en, digamos, XP pero sí en Windows 7, lo que se hace es, o bien esas se marcan como delayed (retardadas) y sólo se cargan manualmente una vez que el runtime ha comprobado que el sistema operativo la posee, o bien se suministra una vacía o con emulación.

No me preguntéis más porque realmente no sé cómo se hace ya que nunca me ha hecho falta, y tampoco sé si está documentado de forma oficial o no, pero es un mecansimo más o menos conocido que usa al menos la propia Microsoft para soportar sistemas operativos obsoletos y no tener varios juegos de ficheros.

***

Y ya que estamos en el tema, os comento otra cosa. Hace unos días se anunció que las versiones Express (todas) de Visual Studio 2012 sólo soportarían crear aplicaciones Metro en Windows 8 y que, si queríamos escritorio, deberíamos seguir usando las 2010 para ello.

Hablamos, claro está, de las gratuitas. La versión Professional y superiores sí que iban a poder crear ambos tipos de aplicaciones, y todo bajo un mismo IDE tal y como estamos acostumbrados.

[Para los despistados, diré que con las versiones Express, si uno necesita crear un proyecto mixto, digamos una DLL hecha en C, C++ ó C++/CLI para que luego una aplicación en C# la use, tienes que instalar los productos por separado y manejar cada tipo de proyecto también por separado, y nada de depurar y saltar de código manejado a nativo y viceversa. Con las versiones de pago todo está en un mismo IDE y se pueden manejar de forma conjunta].

En principio la imposibilidad de crear aplicaciones de escritorio con la Express 2012 puede parecer trivial ya que tenemos las 2010, pero lo cierto es que perdemos muchas mejoras en todos los lenguajes. Podría citar como ejemplo los métodos asíncronos en C# y toda la nueva parafernalia del C++11 para C++, que no es poco.

Pero ha sido tal el clamor popular (y no tan popular, porque algunos MVP le han dado caña de la buena a MS -no, esta vez yo no he movido un dedo), que Microsoft ha reaccionado y va a sacar una versión 2012 Desktop para crear aplicaciones de escritorio.

Es decir, que vamos a tener al menos dos C# Express, dos C++ Express y demás, una para aplicaciones Metro y otra para escritorio. Y lo que es mejor, las versiones escritorio creo, y digo creo porque no lo tengo claro, va a ser un solo IDE que va a soportar todos los lenguajes como las versiones de pago…

***

Enlaces originales:

Menuda porquería de gestión de memoria que tiene el OS X

Rafael Ontivero — Sun, 06 May 2012 18:24:35 GMT

A veces, cuando uno es un swicher de pro como yo, se encuentra con cosas que le resultan un tanto kafkianas como la que os voy a contar.

¿Tiene alguien queja de la gestión de memoria de Windows? No me refiero a si consume más o menos, sino a si funciona como debe, sin que haga cosas raras. ¿A que no? Pues en OS X (los MAC para los despistados), dicha gestión deja mucho que desear.

Hace tiempo empecé a leer en los blogs fanboys la existencia de ciertas aplicaciones que liberaban y optimizaban la memoria de los MAC. En principio algo similar a los supuestos optimizadores de memoria en Windows, pero para OS X. Y si en Windows no hacen falta y sólo consumen recursos, en OS X debería ser lo mismo o, en opinión de los expertos, todavía más inútiles que en la plataforma de Microsoft.

Yo fui uno de esos que comenzó a defender a capa y espada la gestión de memoria del OS X sin haber hecho ninguna prueba porque suponía que era una cosa que se caía por su propio peso: si un sistema operativo es incapaz de gestionar bien su memoria, poco útil va a ser…

Y de hecho, igual que pasó en su momento cuando se promocionaban ese tipo de aplicaciones para Windows, con artículos pagados y demás, se armaron en los citados blogs unas buenas trifulcas sobre el tema, con razonamientos a favor y en contra más o menos elaborados y veraces…

Una puntualización. En OS X, cuando tu cierras una aplicación, está no se cierra realmente, sino que se suspende y queda residente en memoria. Es lo que ocurre cuando le das al aspa de cerrar, o cuando presionas Command-W. Si realmente quieres retirarla de la memoria, o cerrarla ala Windows, tienes que presionar Command-Q o hacerlo a mano desde el Dock. Aquí hablamos de cerrarla realmente, que es cuando se debería liberar su memoria. No obstante, hay programas que realmente se cierran ellos solos, como el gestor de libros Calibre.

Por lo tanto, en OS X tenemos dos formas de cerrar una aplicación. En la primera realmente no se está cerrando, sino que se está ocultando y no es aplicable lo que estamos hablando aquí. Sería el equivalente de minimizar en Windows.

En OS X, la memoria se va asignando pero no liberando. Es decir, tu abres un programa, lo usas y luego lo cierras del todo. La memoria asignada no se libera, sino que queda asignada por si se vuelve a abrir la aplicación y se aprovecha la huella de memoria ya existente.

Por lo tanto, conforme vas abriendo y cerrando aplicaciones la memoria se va llenando poco a poco hasta que apenas queda libre. Hasta aquí la cosa está bien, porque de este modo mantenemos una caché que podría resultar en un aumento de rendimiento.

Y a veces es así. La segunda vez que abres ciertos programas, estos se cargan mucho más deprisa porque recuperan su imagen de la memoria física. Por ejemplo, en el caso del Opera con varios miles de mensajes de correos y de news, la diferencia es abismal. De tardar como treinta segundos o más a ser completamente instantánea.

Según la teoría, una vez que se ha ocupado toda la memoria y se necesita más, es esa caché la que se va liberando según un algoritmo que no me he preocupado en mirar.

Eso es la teoría. La práctica es otra: se tira de swap y el rendimiento de tu MAC empieza a caer en picado y oyes cómo empiezan a rascar los discos duros. Y nadie puede negármelo porque lo he comprobado yo mismo esta mañana.

Todo ha comenzado pasándome del iMAC al Air la biblioteca del iTunes. Para ello he iniciado el AirDrop y con ambos iTunes cerrados, lo he copiado. En el Air estaba vigilando el uso de procesador del Sparrow, que me tiene mosca, así que he abierto el monitor de actividad en el iMAC.

La primera en la frente: de los 12GB de RAM que tiene el iMAC, he visto cómo conforme si iban pasando los ficheros de uno a otro se iba quedando en cero libres. Una vez ha terminado de copiar, he abierto varios programas como el Word, el Pages y el ordenador ha comenzado a tirar de swap en lugar de liberar la memoria inactiva. Los he cerrado del todo y no ha decrecido el consumo.

Para completar el ejercicio he lanzado una máquina virtual que consume 2GB de memoria y ni aun así se ha liberado lo ocupado, sino que los discos han empezado a rascar todavía más furiosamente y el rendimiento ha caído en picado…

Tras eso me he ido a la App Store y me he bajado un liberador de RAM. Al poco de ejecutarlo y lanzar la limpieza de la misma, mano de santo, oye. Los discos han dejado de rascar y me ha dejado algo más de 8GB de RAM libres, que han subido a 10 cuando lo he vuelto a ejecutar tras cerrar la máquina virtual.

El problema, evidentemente, no está en el consumo de RAM. Por mi como si se ocupa toda, sino en el hecho de que un consumo real de 2GB del sistema operativo más otros 2 GB de la máquina virtual, han tirado abajo el rendimiento de un iMAC con 12GB de RAM y un i7 con 8 cores…

Pensaba que Apple podía hacerlo mejor, pero al final resulta que son unos chapuceros de mucho cuidado…

Por si os interesa, he probado el FreeMemory y tras comprobar que funcionaba bien, he comprado la versión Pro por tres cuartos de euro.

Ocultación de datos y paso de variables

Rafael Ontivero — Tue, 24 Apr 2012 09:45:00 GMT

Leo en Twitter un par de preguntas más que curiosas sobre dos cosas que se dan por supuestas en el desarrollo orientado a objetos. Aunque una de ellas está formulada al revés, yo aquí le voy a dar el sentido correcto, e intentaré responder, en la medida de mis conocimientos, a ambas.

***

La primera de ellas es “¿por qué las variables de una clase no deben ser públicas?”

Es una de las primeras cosas que nos enseñan en la POO. Extendiendo la pregunta al ámbito completo, el concepto se conoce como “ocultación de datos”, y se extiende no sólo a las variables de clase, sino también a los objetos en sí y en general al programa completo.

Por poner un caso extremo, en la mayoría de Frameworks serios, el punto de entrada de un programa cualquiera debería ser:

MiApp theApp;

theApp.Run();

Vale, es un poco extremo, pero a ese nivel es lo que necesitamos: una aplicación, y que la vamos a ejecutar. No nos hace falta nada más ni tenemos que conocer nada más a ese nivel.

Es decir, uno de los motivos de la ocultación de datos es dar a conocer únicamente lo estrictamente necesario, y de hecho no nos importa si theApp tiene una variable llamada Juanito o Pepito porque no tiene utilidad conocerlo a ese nivel.

Y de hecho no nos interesa que nadie sepa la estructura interna de MiApp porque sencillamente ahí no podemos y no debemos hacer nada más que ejecutar el objeto que es la representación en memoria de nuestra aplicación. Quizás, o bien en el constructor o bien en el método Run(), pasar los argumentos con los que ha sido llamada la aplicación, pero sólo si es pertinente y nos interesa.

La regla nos dice que si no lo necesitamos a ese nivel, no lo hagamos público. Pero claro, todavía no he explicado por qué. Simplemente he definido la regla: oculta todo lo que puedas.

Jorge Serrano, respondiendo en Twitter, lo ha dicho bastante claro: No te interesa que nadie te pueda cambiar los zapatos sin tu consentimiento. Yo diría que cada perro debe lamerse su pijo, expresión más castiza. Imagina que vas andando por el monte, y alguien te cambia tus botas de trekking por unas chanclas de playa sin tu consentimiento… O que estás en una reunión de alto copete y una chavala empieza a esto…, lamerte el tema…

Reformulado en código, y retrocediendo un poco, la idea es bastante interesante.

En la programación procedural clásica (es decir, C y similares), y tal y como lo dijo Stroustrup en no recuerdo qué lugar, un programa es un conjunto de funciones que menean un conjunto de datos.

En teoría, cualquier función podría tocar cualquier dato. Digo en teoría porque en C y similares también hay métodos, más primitivos, para ocultar datos. Quien haya desarrollado aplicaciones más o menos grandes con esta filosofía, se habrá encontrado con serios problemas:

Métodos que cambian datos que no deberían cambiar.
Datos que deberían ser diferentes pero que por un despiste tienen el mismo nombre y que son combinados por el enlazador como uno solo.

Poniéndolo en otras palabras: se pueden dar situaciones en las que la modificación de un dato genere efectos laterales que terminen en un comportamiento no deseado, o incluso generar una onda de interferencia que termine tumbando la aplicación.

Lo mismo podría pasar con dos variables que accidentalmente han sido nombradas igual. Un compilador moderno debería avisar de este último caso a nivel de enlazador, y en general, al menos con Visual C++, así ocurre. Otra cosa es que el programador novel le haga caso o se dé cuenta del aviso. Y no todos los compiladores notifican de este hecho, sobre todo los de plataforma cruzada para sistemas embebidos, que suelen ser bastante antiguos.

Volviendo al tema central, la OO intenta solucionar este problema con las clases y la ocultación de datos. Es decir, una clase es una serie de métodos que definen cómo tocar a una serie de datos de forma auto contenida. Y hasta la fecha es la mejor solución que se ha podido encontrar, y si alguien conoce alguna mejor (que no sea una paja mental), le vaticino los laureles del éxito más absoluto y arrollador.

En otras palabras: una clase es una entidad con un comportamiento definido por su código y es algo opaco a cualquier cosa que intente ver su interior excepto un interfaz público que sirva para tratar con ella.

Y hay varias razones, todas ellas muy poderosas, para que esto deba ser así, lo que lleva implícito una serie de obligaciones: ocultación de datos, interfaz pública y autocontención. Otras características como polimorfismo extienden pero no obligan, por lo que las vamos a obviar.

Volviendo al ejemplo de los zapatos, pensemos en un objeto zapato genérico. Cuando construyamos una persona, a la clase persona le añadimos dos objetos zapatos (que podrían ir en un array, pero no es imprescindible).

Y ahora viene el truco del almendruco. Atarse los cordones. Podemos hacerlo de varias formas.

La más chapucera es acceder al método miembro cordón de cada zapato y atarlo, ejecutando una serie de acciones (código) sobre dichos cordones. Para ello necesitamos que cordón sea público.

¿Pero qué pasa si tenemos varios tipos de zapatos? Por ejemplo, unos que lleven hebillas. Ups. El código para atar zapatos que está en la clase persona ya no nos sirve…

Si embargo, si definimos un zapato padre que tenga un método llamado AtarCordones() y que internamente use el dato miembro cordón para realizar la misma operación que antes hacíamos desde la clase persona, cuando heredemos de dicho zapato una nueva clase llamada sandalia, tan sólo tendremos que redefinir el método AtarCordones() que, en lugar de usar cordón, usará hebilla y una serie de acciones con ellas.

Y lo que es más importante, la clase contenedora, persona, se desentiende de qué zapato tenemos, de si tiene hebillas o cordones. Simplemente llama a zapato.AtarCordones() y la acción estará hecha.

[Hablando más seriamente, deberíamos tener una clase base virtual llamada, por ejemplo, ZapatoGenérico que defina un método virtual llamado AtatCordones(). Y luego deberíamos heredar de ahí el Zapato normal y la Sandalia. Y quizás otras variantes de calzado.]

Por lo tanto, al ocultar los datos internos y dejar una interfaz pública, ganamos muchas cosas:

Los objetos que manipulen nuestro objeto lo harán a través de una interfaz definida y que debe ser siempre la misma (con la salvedad de los pasos de refactorización que sean necesarios y que cambien los nombres o la propia interfaz).
El punto de arriba mejora la claridad del código,
Nos evita tener que depurar los objetos llamadores porque no ha cambiado nada en ellos,
Nos permite cambiar el comportamiento interno del objeto manipulado sin tener que preocuparnos de la clase manejadora,
Permite el efecto biblioteca (comentado por Herb Sutter en su Rationale a C++/CLI, que su vez lo toma de Stroustrup): podemos meter la clase Zapato en una biblioteca, y podremos cambiar su comportamiento interno sin tener que recompilar el código que la use,
Oculta la visibilidad, permitiendo un código mucho más limpio y con menos interferencias y símbolos globales, que al menos en C++ pueden lentificar la compilación en grado sumo.
Acelera la carga en tiempo de ejecución, porque el cargador del sistema, al tener menos símbolos públicos, tiene que inicializar y relacionar menos cosas.

Vale, creo que no se me escapa nada, y si lo hiciera, con los puntos de arriba hay suficiente.

Todo esto nos lleva a una serie de reglas de diseño con las clases que, al menos yo, llevo a rajatabla:

Oculta todo lo que puedas.
Usa el nivel más cerrado posible: private en C++ para todo lo que puedas. Luego, cuando refactorices y necesites que algo sea conocido por clases hijas, pásalo a protected, pero con sumo cuidado ya que si hay (o se quiere) efecto lateral, mejor pon un método protegido en el padre que pueda ser llamado por el hijo para acceder a ese miembro privado.
Define interfaces públicos, pero los menos posibles. Si un zapato no va desatar los cordones, no lo definas. Si lo necesitas, ya lo definirás. (Aquí hay que mantener cierto equilibrio, porque si sabes que lo puedes necesitar, mejor lo declaras pero no lo defines –cuerpo vacío-, ya que podría ser peor luego tener que cambiar la interfaz ya definida y usada).
Documenta por qué, no cómo (el cómo ya te lo dice el propio código, a no ser que sea algún algoritmo complejo, y en ese caso en el 99% de las veces seguro que se puede hacer de otra forma más sencilla).

Finalmente esto nos lleva a un problema que plantea mucha gente, y es que toda esa ocultación y esos métodos de acceso pueden volver un programa extremadamente lento.

Os lo puedo asegurar: eso fue en tiempos pasados, cuando los compiladores eran animales mitológicos y se sabía poco sobre ellos. Ahora, cualquier compilador medio decente se va a comer tus miles de líneas de código en un santiamén y va a generar mejor código que el que tu pudieras hacer a mano saltándote todos esos pasos. Al menos en C++ y quiero creer que también en C#.

***

Bueno, ahora viene la segunda pregunta, que reformulo pues está planteada con los conceptos cambiados: “¿Alguno sabe la razón de por qué las variables se pasan por valor y los objetos por referencia?” Hablamos de C#, ya que en C++ y C++/CLI podemos pasarlos como nos salga de la pepitilla…

Para responder a esta pregunta debemos meternos un poco en cómo funcionan los compiladores.

Una variable nativa, digamos un entero, ocupa 4 bytes (por decir algo, todo depende de dónde ejecutemos). Un objeto ocupa tanto como la suma de sus datos miembro y una o varias vtable en caso de que tenga métodos virtuales y del nivel de anidación de la herencia (así como de lo bueno que sea el compilador).

[Una vtable es un array de punteros a función que, en tiempo de ejecución, determinan qué método se va a ejecutar dentro de un objeto con métodos virtuales. Un buen compilador resumirá esto en cambiar un call directo a un call indirecto en base a un índice almacenado en algún lugar.]

Cuando nosotros definimos una clase, y a partir de ella instanciamos un objeto, el compilador (y en tiempo de compilación) hace un pase de manos y agrupa todos los métodos miembro en un bloque que junta con los demás métodos miembro de las demás clases, añadiendo unas firmas especiales a los nombres de función.

Digamos que una vez compilado, un programa OO se convierte en un programa no OO que tiene una serie de funciones globales que acceden y modifican una serie de datos… ¿Os suena, verdad? Es que es la única forma de hacerlo, os lo puedo asegurar. La ventaja está en que, salvo oscurísimos errores del compilador que cada vez ocurren con menos frecuencia, a todos los efectos, el comportamiento final simula ser completamente orientado a objetos.

Bueno, cuando pasamos parámetros en una llamada a método, el sistema usa una pila, que es un área de la memoria especialmente destinada a las tareas descritas.

No vamos a entrar en detalles técnicos, pero la cosa funciona así: el compilador pone en la pila los datos a pasar, copiándolos quizá de otro punto de la pila. Entonces hace un call en ensamblador a la función que hemos llamado, y cuando entremos en ella, sabrá que en la cima de la pila tiene sus parámetros.

Cuando pasamos un parámetro por valor, estamos copiando dicho valor en la pila. Si es un entero, ocupará 4 bytes. Si es un objeto, ocupará tantos bytes como datos miembro tenga (ojo, sólo los datos, no el código), más las tablas virtuales más algún que otro elemento más que hace la función de metadatos del objeto pasado.

Si el objeto ocupa 10 bytes, se copiarán, y si ocupa 100, 1K o 100K, se tendrán que copiar absolutamente todos los bytes. Dependiendo de qué objeto, la copia podría ser onerosa en tiempo de ejecución y gasto de memoria.

Cuando pasamos un objeto por referencia, estamos pasando un puntero al dato. No importa en qué lenguaje estemos, siempre es un puntero. Todo lo demás lo hace el sugar syntax del lenguaje, que nos endulza la sintaxis y el operar con ellos.

En este caso, de media, una referencia a un objeto en C#, y si no lo han cambiado, ocupa unos 10 bytes independientemente de qué tamaño real tenga el objeto en sí.

Por lo tanto, ahora vemos por qué en C# un objeto se pasa por referencia y un tipo nativo por valor: optimización.

Esto genera una serie de idiosincrasias en C# que al menos a mi no me gustan mucho, ya que estamos obligando al programador a que lo haga al estilo del lenguaje y no como uno quiera (ya sabéis, eso de “programar en” y “programar con”).

La optimización es la adecuada para la mayoría de casos, pero a veces querríamos hacerlo de otra forma, y es cuando uno ve las limitaciones del lenguaje. En el caso que nos ocupa, un objeto no se puede pasar por valor, lo que fuerza a copiarlo a mano si vamos a modificarlo y no queremos que el original sufra cambios. Y a veces eso es difícil, ya que en algunos casos la copia es de nuevo por valor y no se produce la mutación a nuevo objeto cuando modificamos la referencia creada, y no podemos hacer nada porque el C# (y el .NET) son así.

Sin embargo sí que podemos pasar un tipo nativo por referencia, añadiendo ref al parámetro (con lo cual modificaremos su valor desde dentro de la función llamada). No obstante, la implementación es una chapuza como un castillo, ya que la cosa funciona así dadas las severas limitaciones de la máquina virtual .NET: El valor a pasar por referencia se copia al montículo (heap en inglés, que es donde se guardan los objetos y demás elementos instanciados por referencia) y entonces se pasa, en la pila, una referencia a ese valor puesto en el montículo. Cuando salimos de la función llamada, el sistema coge del montículo el valor modificado y lo vuelve a poner en la pila.

Es lo que se llama box/unbox, y viene determinado por la limitación del .NET de acceder a la pila cuando el elemento a tocar no está encima de ella. La única ventaja que obtenemos de esto es que es mucho más difícil generar una inyección de código mediante el envenenamiento de los parámetros de retorno de la pila.

***

Para aquellos que quieran tener una visión más amplia de la orientación a objetos, así como muchas explicaciones, les recomiendo el libro de Bertrand Meyer, Construcción de software orientado a objetos Segunda Edición, que es un tocho de más de mil páginas denso como él solo… Pese al proselitismo hacia Eiffel, es un gran libro. Hay edición en castellano de Prentice Hall (que es la que yo tengo), pero no sé si se podrá encontrar o no.

Otro no menor pero más práctico, es Code Complete 2 de Steven C. McConnell. Este es mucho más práctico y orientado hacia el código real que escribimos las personas normales.

C++/CX (II). C++/CX vs WRL

Rafael Ontivero — Fri, 04 Nov 2011 19:13:32 GMT

Bueno, una vez que hemos visto lo que hay dentro del nuevo Windows 8, y comprobado que WinRT no es un subsistema sino algo por encima de Win32 como es .NET, vamos a contaros las dos formas que hay de programar con C++ para la interfaz Metro.

Ya lo he comentado antes, pero voy a repetirlo aquí por mor de claridad. En Windows 8 hay dos escritorios diferentes. Por un lado tenemos el clásico de toda la vida que es prácticamente idéntico al de Windows 7, y por otro el de la interfaz Metro. Si no cambian las cosas, los equipos que lleven un procesador x86 tendrán acceso indistinto a los dos, mientras que aquellos que lleven procesador ARM sólo verán la interfaz Metro.

Eso quiere decir que habrá dos tipos de aplicaciones: las clásicas y las Metro. Las primeras sólo podrán compilarse para x86 (de 32 o de 64 bits) y sólo funcionarán en las máquinas Intel. Si estamos en la interfaz Metro y lanzamos una aplicación de este tipo, el sistema cambiará al escritorio clásico.

Las segundas podrán compilarse para x86 o para ARM y en ambos casos funcionarán en sus propios sistemas, pero siempre bajo la interfaz Metro. Es decir, si queremos que nuestra aplicación Metro escrita con código nativo pueda correr en los dos tipos de arquitectura, tendremos que proveer dos compilaciones.

Con .NET (C# y VB.NET) viene a pasar lo mismo, aunque en este caso creo que con especificar AnyCPU será suficiente para que la aplicación corra en ambas arquitecturas. Y de nuevo tendremos los dos tipos de aplicaciones: de escritorio y Metro, con las mismas reglas.

Por lo tanto, cualquier programa escrito en cualquier lenguaje que funcione ahora mismo en Windows 7, no debe tener ningún problema en ejecutarse en la siguiente versión, pero siempre en el escritorio clásico. Y podremos seguir escribiéndolos como hasta ahora.

***

Eso quiere decir que tenemos dos API diferentes e incompatibles entre sí. Por un lado tenemos el API de Win32 clásico y tradicional, sobre el que se construyen bibliotecas de terceros y el .NET. Aquí podemos meter VB6, Delphi, C#, C++/CLI, QT… Vamos, lo que hasta ahora.

Y para Metro hay una nueva API que se llama WinRT. Creo que hay cosas compartidas con Win32, pero no me hagáis mucho caso porque todavía no he visto nada. De todos modos si las hubiera, podemos tomarlas como si fueran nuevas, porque son excluyentes, al menos de momento.

Es decir, o bien desarrollas para Win32 o bien para WinRT, pero no puedes tener un ejecutable que use partes del otro más allá de las que MS ha querido compartir, y entre ellas no se encuentra C++/CX.

Por lo tanto también hay dos versiones de .NET. La de la interfaz Metro se construye sobre WinRT, y la clásica sobre Win32. Nos podemos hacer a la idea de que, aunque tengamos un API con nombres similares, por dentro funciona todo diferente (lo que no es cierto, pero a efectos prácticos sí que lo es, ya que las aplicaciones Metro deberán ir firmadas y el proceso de firmado garantiza que no vas a salirte de las API estándar -¿De qué me sonará eso?).

***

No obstante, WinRT no está escrito con C++/CX si no que está hecho con C++ clásico. Y en cierto modo es lógico, ya que no es más que una extensión a Win32, que es C y C++. Además, independientemente de mis diatribas personales, es algo bueno que le añada funcionalidad a un API que lleva tanto tiempo funcionando con regularidad y sin grandes problemas. Imaginaos los bugs que podría tener algo escrito desde cero.

Por lo tanto, podemos desarrollar aplicaciones para Metro sin usar .NET ni C++/CX. Podemos utilizar C++ y una biblioteca de plantillas llamada WRL (Windows Runtime Library), que viene a ser algo así como el ATL de Metro.

Microsoft no recomienda usarla, más que nada porque es compleja y porque de momento no hay documentación alguna sobre ella, pero está ahí, y es la base de Metro.

Si queremos echarle un vistazo, podemos acercarnos a “Program Files (x86)\Windows Kits\8.0\Include\winrt\wrl” y ver qué hay dentro. Tomaos un par de aspirinas antes.

Básicamente se trata de toda la infraestructura y parafernalia para acceder a los objetos COM y componentes de Metro.

***

C++/CX ocupa el nicho de lenguaje nativo para Metro, con lo que es más rápido que C# y que VB.NET, y es con el único con el que se puede acceder a DirectX (y por tanto a la creación de juegos). También es nativo. Es decir, que no es .NET y compila al código máquina que todos conocemos y de hecho es idéntico al C++ de toda la vida.

Lo que ocurre es que contiene una serie de extensiones que nos van a facilitar la vida a la hora de operar con Metro y sus componentes. Soporta clases parciales, se entiende bien con XAML e instanciar o crear un componente COM es un juego de niños comparado a como se hace con Win32.

Digamos que con esas extensiones nos ahorramos una buena faena a la hora de programar, y será el compilador el que sustituya esa azúcar sintáctica por el código necesario.

En siguientes entradas os contaré más sobre C++/CX.

¿WinRT un subsistema? No, no lo es

Rafael Ontivero — Wed, 02 Nov 2011 16:41:00 GMT

Bueno, al final no ha costado mucho encontrarlo. Básicamente, el resultado de esta investigación es:

O con otras palabras: WinRT y Metro se ejecutan, como todo lo demás, sobre Win32, con las ventajas y los inconvenientes que eso pueda tener. No me malinterpretéis: no hay nada malo que la arquitectura sea diferente a la indicada en el gráfico de arriba, lo que está mal es que Microsoft nos mienta tan descaradamente. Simplemente eso.

Si lo han hecho así, por algo será y sus motivos tendrán, y es entonces cuando, ya definitivamente, yo tenía razón: Windows ya no es Windows NT, y su grandiosa arquitectura por bloques se ha perdido en el camino. Y esto sí que es malo, bastante malo, porque estamos volviendo a un batiburrillo de código como es, por cierto, el OS X (quizás algún día hable de ello).

Vosotros mismos podéis comprobarlo sin problema alguno y de forma muy rápida. Tenéis que construir dos aplicaciones, una WinRT en C++/CX y otra clásica de Win32. No hay más que utilizar las plantillas por defecto sin ningún cambio.

Eso sí, hay que hacerlo a partir de la versión Developer de 64 bits de Windows 8, e instalar una versión de la MSDN, porque la Express creo que no es capaz de generar programas Win32 puros.

He llamado “TestWin32” a mi aplicación tradicional, que genera una ventana de Windows normal y corriente utilizando directamente el API de Win32. A la Metro la he llamado “TestSplitApplication”. Una vez generadas, tenemos que compilarlas. Visual Studio se os quedará más o menos así:

Si ahora nos vamos a la carpeta en donde está almacenado el proyecto (que podemos hacer desde el mismo IDE posicionándonos en el nombre de la solución en el Explorador y elegimos Open Folder in Windows Explorer), carpeta Debug, encontraremos el ejecutable del programa nativo (TestWin32.exe) y dentro de la carpeta TestSplitApplication, el de la aplicación Metro.

(Por cierto, en uno de esos lapsus teclae tan habituales en mi, le he dado el nombre de “TestSplitApplicarion” en lugar del correcto.)

Ahora debemos conseguir el Dependency Walker, aunque existen otras herramientas de línea de comandos que nos permiten hacer lo mismo dentro del SDK, lo interesante es utilizar esta porque lo veremos todo de un golpe. El mayor problema es que se trata de una utilidad que hace tiempo que no se incluye en ningún SDK, por lo que hay que conseguirla de forma externa.

Una vez obtenida la versión de 32 bits, porque nuestros proyectos son de dicho tipo, la ejecutamos sobre cada uno de los dos programas. Este es el resultado:

¿Lo veis? Ambos programas importan las mismas DLL, las de Win32 como KERNEL32.DLL y USER32.DLL.

Es decir que ambos son aplicaciones Win32 nativas.

***

Si nos diera por abrir, por ejemplo, uno de los dos KERNEL32.DLL, veríamos que ambas DLL son la misma con las mismas dependencias y exportaciones. Por lo tanto, ambas aplicaciones dependen del mismo subsistema.

Reitero que es una tontería, pero no lo es cuando intentan engañarte.

Lo que sí parece han hecho ha sido romper KERNEL32.DLL en otros ficheros más pequeños que contemplan subconjuntos de lo que en versiones anteriores había en él. Quizás de esta forma reduzcan la huella de memoria evitando cargar sub ficheros cuando estos no se vayan a utilizar.

***

Esto nos lleva a un tercer problema: parecer ser que una aplicación Metro no puede ejecutar funciones de Win32, y una de Win32 tampoco de WinRT.

¡¡Pero si es el mismo subsistema!!

Pues bien, estamos ante una limitación artificialmente impuesta por Microsoft sin ningún motivo técnico aparente… con lo guapo que sería hacer aplicaciones Win32 con C++/CX…

Se me ocurren un par de trucos para poder forzar esto, pero no creo que valga la pena hacerlo en una versión tan temprana como esta. Quizás cuando salga la definitiva, si tengo ganas y si nadie más se me adelanta, lo intente.

Code Complete 2, Steve McConnell

Rafael Ontivero — Thu, 27 Oct 2011 18:51:12 GMT

Ñas. Por fin lo he leído. Más de un año para acabarlo. Entre lo que os conté con mi jefe y la empresa, y cierto bajón existencial, dejé de leer temas técnicos, pero creo que he vuelto, o eso espero.

Bueno, al rollo.

Lo primero de todo, y pese a que me vais a llamar de todo, el libro no me ha aportado nada nuevo, salvo quizás en los últimos capítulos cuando habla de integraciones y manejo de grandes grupos de programadores, entre los que no me cuento. Es decir, o bien programo solo o bien en pareja o para un tercero, haciendo rutinas de bajo nivel o bibliotecas (DLL, como las llama mi jefe).

Lo único ha sido la sorpresa de encontrar veinte años de experiencia condensados en un solo libro. Y lo que falta, que no es poco. Pero bueno, lo cierto es que este libro tienes que leerlo.

Si no lo has hecho, cómpralo y ponte a ello, porque seguro que te va a resultar constructivo. Y si te dice cosas nuevas, vuélvelo a leer cada año o cada seis meses. O si eres de los que va despacio, cuando termines por una punta, cógelo por la otra.

Es increíble lo que pueden dar ochocientas páginas, pero lo dan.

Te pego una cita, sacada de aquí:

Si sólo tienes oportunidad de leer un libro sobre desarrollo de software en toda tu vida, procura que sea éste. Code Complete es prácticamente la biblia del desarrollo de software, además de una de las mejores guías prácticas sobre la programación de todos los tiempos. Es un libro muy fácil de leer, entretenido, y tremendamente práctico, con montones de recomendaciones útiles para cada fase del ciclo de vida del software. El simple hecho de leerlo te hará mejor programador. Seguro.

Con eso creo que basta.

iCloud o la flagrante tontería

Rafael Ontivero — Sun, 16 Oct 2011 11:09:38 GMT

¿Sabéis lo que es iCloud? Aunque digáis que sí, me juego un gallifante a que no. ICloud es una mierda envuelta en papel brillante, un trozo de bisutería rodeado de oro del que cagó el moro.

Acabo de comprobarlo. Tengo dos iMAC, un iPad, un iPod y un iPhone (este del curro, que todavía no he actualizado).

Como sabéis, hace unos días salieron todas las actualizaciones de golpe, tanto para el escritorio como para los dispositivos móviles. En mi caso la actualización a Lion 10.7.2 se realizó sin problemas, salvo una notable ralentización del sistema una vez reiniciado, ralentización que parece es temporal ya que ahora funciona todo casi igual de rápido que antes… excepto algún que otro rosetón multicolor de la muette que deja mi i7 de cuatro núcleos dobles y 12 GB de RAM como autista unos segundos… Eso no lo hacía antes de aplicar el parche.

No obstante, la actualización de los dispositivos móviles ha sido más que penosa. En primer lugar falló la descarga y la actualización. Me dio el infausto “internal error” causado por la caída de los servidores de Apple. Hay que joderse, con la expectativa generada y que la empresa no fuera capaz de preverlo con antelación. Joder, hasta Microsoft, el denostado Microsoft, cuando saca un producto nuevo que es muy esperado, aumenta y confía en terceros para las descargas…

Pero no todo termina ahí, no. El iPod se actualizó más o menos bien, a la tercera o la cuarta, pero el iPad hubo de sufrir bastantes intentos. O bien se quedaba autista o bien simplemente fallaba. Como tengo casi 40 GB de datos en él, y la interrupción se producía casi al final, la cosa llevaba su tiempo. Al final, restauración de fábrica, instalación de las aplicaciones y vuelta a meter los datos. Menos mal que soy un chico previsor y los tengo en el MAC, listos en sus carpetas. Eso sí, todavía estoy configurando programas…

¡Quietos parados, fanboys! A ver. Uno mete el iPad, te dice que tiene una actualización, le dices que sí, y a medias falla. No hay otra. No es mi culpa. Es de Apple. Por el motivo que sea. Mi iPad está impoluto, sin Jailbreak, sin cosas raras. Ya que está todo cerrado, debería funcionar a la primera, porque si no me vuelvo a Windows que me deja hacer lo que quiera sin más, y si falla puedo achacarlo a mi ineptitud, no a la de Apple. [Como colofón a esto, no soy el primero que ha tenido problemas. Básicamente la actualización a iOS 5 ha sido pésima. También quiero pensar que no se trata de un intento de que estampe mi iPad 1 contra la pared y me compre un 2.]

***

Bueno, ahora sí, ahora hablemos de la magia de la cosa esa del iCloud. ¿Os pensáis que es una versión mejorada de Dropbox? Juas, ni se le acerca. Hasta el infausto SkyDrive de Microsoft es mejor.

No, no es que vaya mal, es que no cumple mis expectativas. Es una decepción total, más que total, humillante. Lo único que te va a guardar iCloud son los documentos de Pages, de Office (a mi no me lo hace), tus fotos y los calendarios… pero los que crees en la nube. Es decir, la cacareada sincronización sólo se va a producir entre los documentos políticamente correctos que, como siempre, le vengan en gana a Apple. No mis documentos. No mis fotos ya hechas, no los documentos que yo quiera, no.

Y encima, como elemento de obsolescencia programada, si quieres tus documentos en la nube, paga por nuevas versiones que lo soporten. Asco me da. Decepción. Tristeza.

***

En serio, tengo una extraña sensación que me parece que, conforme va pasando el tiempo, es más fuerte y coherente: cuanta más cuota de mercado coge Apple, más se parece a los peores tiempos de Microsoft, con fallos estúpidos, dejadez en atender los requisitos de los clientes y olvidarse de que uno debe estar al loro con las actualizaciones de seguridad y que no debe esperar dos meses a, por ejemplo, invalidar una entidad certificadora. Es una especie de deja-vu, una sensación como de inquietud y de malestar… Ahora que Jobs ya no está, quizás la cosa mejore… aunque lo más seguro es que empeore.

Básicamente, maldita la hora en que me pasé a Apple.

WinTablet.info: Windows 8 y los Tablet

Rafael Ontivero — Sun, 25 Sep 2011 09:43:55 GMT

Ya sabéis que me gusta meter baza en los nuevos productos de Microsoft más que a un pollo la mierda. No creo que os pille de sorpresa, pero en este caso estamos hablando de caviar Beluga ya que encima tenemos dominio y web propia.

Sí, lo que leéis, el RFOG ha sido invitado a participar en un blog de temática exclusiva sobre Windows 8 y su orientación hacia los Tablet. Sin restricción de temática, sin censura y con libertad total de publicar lo que quiera (no, que no se os abran los ojos como platos, de momento no voy a poner porno).

Bueno, después de la presentación chula, vienen los detalles. Nos hemos juntado cuatro interfectos de entre los indeseables de la internet y que encima somos granos en el culo de las grandes corporaciones y nos hemos decidido a poner los puntos sobre las íes en el tópico descrito más arriba. La idea fue originalmente de Juan Luis Chulilla, quien la propuso a Ctitanic y a mi. No hace falta decir que tardamos 100 milisegundos en decir que sí, que es el tiempo medio de reacción entre el ojo y el cerebro (para aquellos que tengan neuronas, claro). Luego se nos unió Mahjong, y así formamos el cuarteto concertante (la referencia es de Verne).

Dicho y hecho, sólo faltaba arremangarse y empezar a escribir, así que el sitio ya contiene entradas chulas, aunque todavía anda algo en obras y debéis poneos casco no sea que se os caiga algún ladrillo en la cocorota.

Para aquellos que todavía estéis en Babia, os comento. Windows 8 es la siguiente versión de Windows 7, y viene en modo dual. Es decir, que trae dosShell de usuario. La primera es la que todos ya conocemos, con su menú inicio, su explorador y su Internet Explorer, con las mejoras pertinentes. Lo pongo en cursiva porque hay mucha gente a la que la Ribbon en el Explorador no les mola nada… a mí sí.

La segunda interfaz se llama Metro y está destinada a los Tablet, sean del tipo que sean. Si habéis visto Windows Phone ya tenéis una idea de qué es. Como siempre con las tecnologías de Microsoft, debajo hay más de lo que parece, y también ahora ocurre así.

A simple vista Metro parece nada más que una interfaz de apretar botones, pero dentro existe un motor basado en DirectX muy potente e interesante, envuelto en una capa que se programa con C# y una variante de C++/CLI. Y no es .NET, es nativa. De esto os contaré más aquí, pero en otro momento.

Finalmente también hay una preview de la siguiente versión de Visual Studio que es capaz de generar ejecutables para esta nueva plataforma, y de esto también hablaré por aquí.

Bueno, lo dicho, daos una vuelta por WinTablet.info.

Aprobado: C++0x ya es C++11

Rafael Ontivero — Sat, 13 Aug 2011 10:16:00 GMT

Leo en el blog de Sutter, la representación de Microsoft como compañía en el comité internacional de estandarización de C++, que, por fin, el nuevo estándar ha sido aprobado por unanimidad y que pasa a llamarse, como ya se esperaba, C++11.

Un poco más y lo tentemos que llamar C++12.

El rey ha muerto. ¡Viva el rey!

Ahora a ver qué tal lo hace Microsoft con su próximo compilador, y a ver si BorlandEmbarcadero se pone las pilas y también hace algo, aunque lo más seguro sea para C++Builder XE3 el año que viene o el otro, porque el XE2 ya está terminado y a punto de salir, por cierto con compilación cruzada para MAC OS…

La noticia original: http://herbsutter.com/2011/08/12/we-have-an-international-standard-c0x-is-unanimously-approved/

OS X Lion: Ver la carpeta Librería desde dentro del Time Machine

Rafael Ontivero — Fri, 05 Aug 2011 15:37:47 GMT

De nuevo volvemos a Lion y a sus chipirtifláuticas nuevas características súper fashion de la muette. Ahora hablamos de cómo mirar dentro de la Librería de nuestra carpeta de usuario cuando estamos dentro de Time Machine porque queremos recuperar algo de allí. No, no se ve. Aparte de que es un poco complicado acceder a la carpeta de usuario porque Apple nos quiere ocultar cada vez más el sistema de ficheros de OS X, cuando entras en ella la carpeta Librería no está aunque le hayas cambiado el atributo de oculto… Mola, ¿no? Si buscas por la red verás un montón de páginas que explican cómo hacerlo, matando el Finder y con otras técnicas un tanto barrocas. La mía no es que sea muy directa, pero al menos no le tocamos las pelotas al sistema operativo y se hace todo de forma ordenada. Lo primero que hay que hacer es montar la unidad en donde se guarda la copia de seguridad. Hay varias formas, como lanzar una copia de seguridad manual, entrar en el Time Machine y luego salir o simplemente haciendo clic en la unidad en donde estemos realizando la copia. Una vez montada, es tan fácil como abrir un Terminal y movernos al home de la copia que queramos. Partimos de la carpeta "/Volumes" y nos vamos adentrando en la copia. También podemos hacer doble clic en el disco montado en el escritorio o seguir navegando por el Finder… La cosa es llegar al home de la fecha que nos interese, ya sea por terminal o con el Finder. Una vez allí podemos pulsar CTRL-I (o Ver información) sobre la ruta, para saber dónde estamos. Si hemos usado el terminal no tenemos que hacer nada más que, una vez en nuestro home, picar "cd Library" y estaremos dentro. Si lo hemos hecho con el Finder, ahora es turno de abrir un Terminal y seleccionar y copiar la ruta completa que nos aparece en la ventana de información, picar "cd " en el terminal y pegar dicha ruta sobre el mismo. Al pulsar Enter estaremos en la misma situación que el párrafo de arriba. Ahora viene el truco del almendruco. Podemos usar el terminal para copiar lo que queramos con los comandos de Unix (ya sabéis, cp), pero resulta mucho más cómo hacerlo con el Finder. Por lo tanto ahora picamos pwd en el terminal y presionamos enter. Justo arriba del cursor nos aparece la ruta completa en donde estamos. La seleccionamos con el ratón y la copiamos. Hacemos clic sobre el escritorio para que en el menú del sistema nos aparezca el del Finder. Elegimos "Ir -> Ir a la carpeta" y en cajetín, pegamos la URL que acabamos de copiar. Se nos abrirá una ventana del Finder en todo su esplendor. [Sí, ya sé que hay una forma muy fácil de mostrar la Libería, que es explica en infinidad de sitios, pero sólo sirve para la carpeta de la cuenta actual, no dentro del Time Machine.] Por supuesto también vale hacer esto para entrar en la Libería del home actual de nuestra cuenta de usuario. Otra forma para, desde cualquier carpeta, ir retrocediendo carpetas padre, es pulsar Commando+Flecha Arriba o, sobre el título de la carpeta en el Finder, retroceder haciendo clic con el botón secundario del ratón.

¿Se cree Apple que somos imbéciles?

Rafael Ontivero — Thu, 21 Apr 2011 16:59:51 GMT

Supongo que a estas horas, con toda la parafernalia mediática que lo está rodeando, todo el mundo sabe que el sistema operativo iOS realiza una triangulación y seguimiento de nuestros aparatos siempre que lleven 3G…

Mención especial de la noticia son los blogs voceros y defensores de Apple a toda costa, transformando lo terrible y lo intolerable en algo leve y sin mucha importancia… Estoy hablando de entradas como esta, esta y esta. Y ya de paso, un olé al amigo Malo Maloso de Spectra, Chemita y su entrada por decir las cosas claras.

Ya cuando empecé a leer sobre el tema, anoche, en mis aplicaciones dentro de un, vergüenza me da escribirlo, iPad, empezó a hervirme la sangre.

Hace ya tiempo que veo un enorme paralelismo entre los malos tiempos de Microsoft y la actualidad de Apple. Microsoft hizo muchas cosas malvadas y de las que debería hacer acto de contrición, como robar a Stacker y envolver su driver en otro simulando que lo habían hecho ellos, o cuando metieron un payload en Windows 3.1 para que éste fallara si corría sobre DR-DOS…

Pero lo de Apple no tiene nombre. Aparte del oscurantismo y el control dictatorial, aparte de ese aura de estúpida magicidad, de ese espíritu cool y guay del Paraguay se esconde una de las empresas más ingentemente malignas, más absurdamente controladoras, manipuladoras y aberrantes de toda la historia de la informática. Para mi Apple es el Cuarto Reich, Steve es Hitler, con la evidente distinción de que, y solo de momento, Apple no mata, o casi (sólo hay que recordar lo que pasa en Foxconn).

Para aquellos que no lo sepáis todavía, iOS guarda en un fichero sin encriptar la geolocalización de todas las iCosas que tengan 3G. No sólo lo guardan los dispositivos, sino que también está presente en las copias de seguridad de los ordenadores. Si bien es cierto que este hecho viene indicado en el contrato de treinta páginas que te obligan a aceptar, la verdad es que resulta inconcebible que se pueda hacer impunemente algo así.

El hecho no es malo en sí, el hecho es que se trata de algo que ha sido ocultado, manipulado y que pone en peligro la integridad física de algunas personas. Es evidente que, en principio, poca importancia tiene por dónde haya pasado un iPhone. Pero no para un juez antiterrorista, ni para un político en el punto de mira de alguna organización terrorista, o incluso como herramienta de chantaje. Es tan fácil como entrar en casa del interfecto, volcar la copia de seguridad de su iPhone en un pincho USB y conocer por dónde se pasa… o pagarle a un chorizo para que robe la iCosa en un descuido de la persona vigilada.

Pero lo peor de todo no es eso. Lo peor ha sido la respuesta de Apple. Con toda su desfachatez, con toda su cara dura, ha dicho que es un bug y que será solucionado en la siguiente versión.

Apple, ¿te crees que somos imbéciles? ¿Que nos chupamos el dedo? Hay que joderse y hay que ser muy cínico y muy jodidamente oscurantista para que el común mortal se crea una mandanga así… No obstante, seguro que más de un fanboy salta a pies juntillas con la justificación…

En fin, que cada vez me dan menos ganas de seguir con esto de programar para las herramientas construidas por tales interfectos…

Hasta los putos cojones del instalador del Flash Player

Rafael Ontivero — Sun, 03 Apr 2011 13:17:00 GMT

Pues eso, que estoy hasta los mismísimos cojones del instalador del Flash Player.

En primer lugar por instalarme un acceso directo al antivirus de McAffee sin mi permiso. Y aun más a lo mierda que es ese antivirus.

En segundo lugar, y no menos importante, es que según Adobe yo soy imbécil. Primero me pregunta si lo quiero bajar, y luego me pregunta si acepto la licencia.

¿Por qué cojones no haces una sola pregunta? Al principio. Pregunta si quieres bajarlo, aceptas la licencia y quieres instalarlo. Una sola vez y una sola pregunta. No creo que sea tan difícil. O mejor aún, si he elegido instalarlo, ¡cojones! No me preguntes más. Ya te he dicho que sí, que lo quiero.

Y tercera, por instalarme la mierda esa del download manager mierdoso...

Ya está aquí C++0x, digoooo C++11

Rafael Ontivero — Fri, 01 Apr 2011 16:49:24 GMT

En qué estaría yo pensando, aisssss. J Bueno, pues eso, que hace unos días Sutter anunciaba en su blog que ya está todo cerrado y que en unas pocas semanas (esperemos) estará todo cerrado y el estándar publicado.

También comenta (él u otro de los enlaces que pongo abajo) que esperan que esta nueva versión no necesite más que correcciones nimias dado que ya hay muchos fabricantes de compiladores que han implementado casi todas las características (y los TR publicados) y no se han detectado errores de concepto ni de implementación, por lo que se está bastante seguro de que no se ha cometido ninguna pifia que luego haya que corregir (me refiero a la definición del estándar, como ya ocurrió con la versión anterior, en la que hubo de modificar errores de concepto y clarificar puntos oscuros).

Las cosas chulas que trae este nuevo estándar se pueden resumir en las siguientes:

-rvalues y semántica de movimiento.

-Operadores lambda (como los de C# pero con esteroides).

-Variables automáticas (que rompen el estándar anterior).

-Enumeraciones fuertemente tipadas.

-Plantillas variadic y otras cosas sobre plantillas.

-TLS y soporte para threads

-Alguna cosa más.

Mi intención es ir publicando aquí sobre todo eso, así que estad atentos.

Y ahora, algunos enlaces de los gurús de todo esto:

· We Have FDIS! (Trip Report: March 2011 C++ Standards Meeting)

· Effective C++ in the C++0x (C++11) Age (o cómo mear en tiesto propio)

· C++0x will be C++ 2011

Lo que valen los test case

Rafael Ontivero — Tue, 29 Mar 2011 20:36:36 GMT

Seguro que más de uno, tras leer esta entrada, decide buscarme y matarme, pero os lo tengo que contar, y supongo que por el título ya habéis adivinado de qué va la cosa: otra diatriba del RFOG.

Ya sabéis que yo no soy muy dado a las formalidades esas de seguir un método de desarrollo como Scrumm o Agile o como quieran llamarse, y que siempre he dicho que los test units no sirven para nada… al menos en mi trabajo.

Bueno, pues ahora le toca el turno a los “test case”… Según yo los entiendo, se trata de pasar una pieza de código más o menos importante y/o completa por una serie de test automatizados (o no) para determinar si los cambios realizados para resolver un problema han roto otra parte.

El concepto es hacer pequeños tests (los units esos) sobre pequeños bloques de código como funciones y demás. Y luego, cuando ya tienes un módulo completo e independiente (sea lo que quiera que signifique eso en tu caso), lo vuelves a verificar como un todo.

Y si has sido bueno y has hecho los deberes, todo debe funcionar perfectísimamente bien y no presentar ningún problema final, y si lo hace, pues vuelves a revisar el código e iteras.

Luego queda un paso final, que es poner delante del monitor (o lo que sea) a alguien y que compruebe a mano que todo va bien.

***

Esa es mi visión de una secuencia de verificación de código, pero en mi caso muchas veces te encuentras con serias limitaciones, como las que os voy a contar, aunque realmente no puedo hacerlo como quisiera porque tiene que ver con mi trabajo y no puedo hablar con mucho detalle sobre él.

El caso es que tenía una secuencia como la descrita que falló estrepitosamente en producción, o más bien que falló en la etapa final de verificación del producto, que es sacarlo a la calle y dejar que los lusers lo revienten, como así ha sido.

Supongamos por un momento que tenemos un algoritmo del que sólo hay una implementación razonable y posible con los recursos disponibles, y que encima dicho algoritmo es la primera vez que se realiza en donde trabajas, por lo que no hay experiencia anterior ni reutilización de código.

Y encima el algoritmo es indivisible, es decir, no se puede dividir en tareas más pequeñas y verificables. Bueno, sí, pero esas partes son triviales y ni siquiera necesitan un unit test por lo de siempre: un qsort va a funcionar y te va a dejar el tema ordenado sí o sí, y todavía va a funcionar mejor si usas de origen ya algún contenedor STL ordenado…

Y es en este caso donde entran a pleno rendimiento todas esas metodologías chachi piruli Juan Pelotilla que tanto bombo y platillo tienen.

Ahora suponed que con esfuerzo uno hace un análisis de lo que va a ser la entrada al algoritmo y descubre que tiene cuatro variaciones sobre otras cuatro, es decir, 16 familias o grupos de datos. Y a mano, hace al menos dos tests para cada una de ellas. Es decir, calcula a mano, para dos entradas de cada familia, qué dos salidas debe haber.

Y lo mete todo en un test por tabla iterativo. Ante cada entrada se procesa ésta y se compara la salida obtenida con la que se debería obtener, y si todo coincide, se pasa a la siguiente.

Aparte se generan entradas aleatorias y se anotan las salidas, y se le aplican todas las comprobaciones heurísticas posibles, como por ejemplo que el total de la entrada debe ser el total de la salida, que si A es cero, B debe ser cero, etc., pero lo que no se puede hacer es tener un código que verifique los datos porque ese código sería exactamente el mismo y no se puede realizar un algoritmo inverso porque el resultado es entrópico: no se puede obtener el origen en base al resultado.

Si recordáis otra entrada similar a ésta, ese proceso sí que se podía verificar ya que el PC tenía artimética de 32 bits pero el origen no, y lo que se tenía que simular era eso: cierta aritmética de 32 bits en un procesador de 8 bits en el que, encima, el compilador hacía cosas mal.

Bueno, volviendo al presente, una vez todos los casos funcionaban bien, y se generaban millones de secuencias sin que aparentemente nada descuadrara, y se revisaran algunas de forma aleatoria, se integró el algoritmo en el equipo de destino y… falló.

***

Tardó dos semanas pero falló. Vuelta al laboratorio. Primero se encontraron errores chorra de otras partes del código que alimentaban a la rutina con datos incorrectos, pero aun así seguía fallando miserablemente en uno de los 16 casos.

Escribirlo es infinitamente más sencillo que encontrarlo. Me refiero a delimitar el problema a una de las 16 familias, pero tras muchas pruebas, muchos análisis de logs, se encontró.

Luego uno miró los test cases y no vio error alguno… excepto que estaban mal. Es decir, la salida que el programa generaba era incorrecta, y como la salida coincidía (recordemos que pese a ser determinista es entrópica, como un compilador) con lo que decía el test, la cosa fue para adelante.

El primer problema es cómo cojones se pudo equivocar uno en eso. Para mí está claro: dislexia. Invertí dos valores de una tabla, que encima coincidían con la salida incorrecta. Una de esas casualidades que uno encuentra en la vida y que piensa que no deberían ocurrir porque son tan improbables… antes de que Murphy haga su aparición, claro.

Pues bien, una vez corregida la tabla, rápidamente se encontró el error… que era bien estúpido. Para que os hagáis una idea, después de una ordenación mediante quicksort (estamos en C embebido), se recorría la ordenación buscando un elemento con una característica concreta, pero la comparación se hacía… sobre la tabla sin ordenar, o más bien sobre el índice de uno de los elementos ordenados pero tomando la tabla de origen como base del índice… En fin.

Aquí entra una de las cosas que me molan mucho: código auto defensivo. En el caso de las otras familias el código no fallaba porque se recuperaba del error anterior debido a las seguridades insertas en él, pero en el caso que nos ocupa se concatenaba una debilidad de la auto defensa con el error y al final el algorrino terminaba fallando.

***

Ya como conclusión me gustaría hacer algunos comentarios. Los tests estaban mal. Si hubieran estado bien el problema se habría detectado inmediatamente, pero el hecho es que sirvieron de poco o de nada.

En el caso que nos ocupa, el algoritmo era bastante complejo y encima se tenían recursos limitadísimos en la máquina de destino, por lo que no se podían hacer grandes implementaciones ni grandes comprobaciones, y de hecho todavía no se está seguro de que se haya solventado por completo. Las verificaciones automáticas siguen ejecutándose todas las noches, con la ventaja de que ahora los fallos terminan en un bucle infinito desde el cual se puede determinar qué falló y por qué.

Pero la advertencia es muy seria, y es la conclusión a la que quiero llegar. Los tests no sirven para nada, o casi para nada. Porque cuando uno los necesita de verdad, nunca puedes estar completamente seguro de que estén bien. De hecho, los propios tests son código, y podría darse, y os aseguro que se da, la situación en la que un error en el código a comprobar, más un error en el código del test producen una salida correcta.

Es evidente que uno puede tener todo el cuidado del mundo en hacerlos, pero nadie está a salvo de equivocarse. Y al menos yo pienso que, si puedes hacer un test del que estés seguro que no va a fallar es porque no lo necesitas, ya que también estás seguro de que el código funciona bien porque es ese mismo código el que te indica la correctitud o no del test.

Y sobre la verificación de parámetros de entrada, en muchos casos es un objetivo irreal. En el caso que nos ocupa, el algoritmo (y nuestros tests) son completamente incapaces (o casi) de verificar que la entrada es incorrecta salvo en los casos más triviales. Y, de nuevo, los tests no sirven para nada.

Con esto no quiero decir que no se deban hacer tests, que se deben hacer, y cuantos más mejor, si no que cuando más útiles deberían ser, menos utilidad tienen, y encima podría decir que se trata de una relación exponencial inversa…

MAC Rationale vs Windows Rationale en el desarrollo

Rafael Ontivero — Sat, 19 Mar 2011 14:42:00 GMT

Todavía estoy leyendo temas generales sobre el desarrollo en MAC, de hecho aún no he pasado de los manuales que describen las tecnologías y los diferentes bloques en que se divide el desarrollo en MAC.

No obstante me ha surgido una curiosa reflexión que quiero compartir con vosotros. Todavía no estoy muy seguro de que sea completamente cierta, porque todavía no he profundizado en los conceptos MAC y lo que he leído tiene más que ver con la publicidad del desarrollo en esta plataforma que otra cosa, pero creo que tiene muchos visos de ser real como la vida misma.

Y lo más curioso de todo es que tiene mucho que ver con el desarrollo Windows, y más cercanamente al de las tecnologías .NET. Cuanto más leo sobre Cocoa, QuickTime (que no sólo es un programa sino una tecnología), etc., más me parece estar leyendo sobre .NET, o más bien sobre la forma en la que se publicita .NET.

Se habla de grandes grupos de tecnologías orientadas a objetos, con grandes rendimientos y grandes facilidades ofrecidas a los desarrolladores. Calcado uno de otro. Ahora habrá que ver la pura realidad.

Del lado .NET ya lo tengo claro: mucho ruido y pocas nueces, al menos para desarrollo de sistemas. Quiero creer que del lado MAC no será igual, pero cualquiera sabe. Ya os iré diciendo.

***

Pero no, no es sobre eso sobre lo que os quería hablar. Veamos por un lado la arquitectura lógica expresada por los manuales de MAC, que creo es más real que la dicha por los de Windows.

Debajo del todo un ordenador de Apple hay un Kernel BSD que no es otra cosa que una variante de UNIX igual que es Linux. Y luego hay un sistema POSIX de toda la vida que de nuevo tiene que ver con el mundo UNIX (que viene a ser como una serie de servicios que simplifican el acceso al núcleo del sistema igual que una consola de comandos en Windows permite trabajar con ficheros sin tener que tocarlo).

Aunque Apple lo ha llamado Darwin, no deja de ser lo que es, y de hecho Apple publica todo el código fuente de ello. Al ser un estándar debe estar separado. Realmente está separado.

Encima de eso hay una serie de capas, Cocoa, Carbon, QuickTime. Más o menos. Pero lo que es cierto es que esos subsistemas están completamente separados del núcleo o más bien encima de él.

En Windows creo que no es así. En su momento, en las versiones NT originales sí que lo era (o al menos así se publicitaba). Recordemos la capa HAL que podía ser para un montón de procesadores y luego el sistema NT Executive nativo, que corría sobre dicha capa. Pero ahora, después de la unificación con la plataforma 9x en lo que fue Windows XP dudo mucho que siga siéndolo.

Porque ahora no hay soporte para ARM, ni para SuperH, ni para PPC. Sólo Intel x86 y dando gracias. Me juego un gallifante a que ahora está todo mezclado y revuelto (y de ahí los problemas de Microsoft para volver a añadir soporte para ARM). Porque si no fuera así no se entendería cómo puede funcionar el sistema de vídeo sobre Win32 accediendo al driver que está en el núcleo (sí, ya sé, anillos, gateways y todo eso, pero no voy por ahí)…

Bueno, quizás en esto me equivoque, pero si alguien me explicara cómo el hecho de reproducir un vídeo dentro de un navegador pueda generar una BSOD estando los sistemas separados, que me lo diga. Porque me ha pasado. Y no una, sino varias veces. Putas ATI.

De todos modos luego veremos alguna razón más de ello y quizás uno de los puntos más fuertes de por qué Microsoft está un poco contra la espada y la pared.

***

Apple ya lo ha hecho al menos dos veces y lo va a hacer una más. En x64 no va a haber Carbon, que es como se le llama al subsistema que soporta programar en C y C++ de forma nativa. En x64 sólo vamos a tener Cocoa (Objetive-C y Objetive-C++) y POSIX (que yo sepa). En su momento, con el cambio de PPC a x86 repitió jugada, haciendo borrón y cuenta nueva y forzando a muchas empresas de software a reescribir sus programas. Como cosa curiosa os diré que Apple encargó a Adobe la creación de su iPhoto, iVideo y demás programas de esa plataforma y Adobe los mandó a freír espárragos porque estaban como locos rehaciendo sus propios programas. Creo que hubo otro cambio rompedor más en los MAC pero ahora no recuerdo qué.

Bueno, el meollo del asunto está en que a veces es conveniente hacer borrón y cuenta nueva. Hasta donde sé, el API de MAC OS X y el de iOS es un API moderno, orientado a objetos y bastante potente. Ya os diré si realmente es cierto cuando me enfangue las manos con ello.

***

Ahora volvamos a Windows. Aquellos que hayan leído sobre el tema, sabrán lo que son los subsistemas. Para los que no, una pequeña introducción.

Win32 es un subsistema. POSIX es un subsistema (o lo era hasta que lo quitaron). De hecho, en las primeras versiones de NT había hasta un subsistema OS/2.

Un subsistema es una API completa que sirve para que las aplicaciones escritas para tal subsistema se ejecuten en él, sean independientes del núcleo y no puedan afectarlo en ninguna manera. Ved la siguiente imagen de la Wikipedia y fijaros arriba a la derecha.

http://en.wikipedia.org/wiki/File:Windows_2000_architecture.svg

Básicamente esa debería ser la arquitectura de Windows. Fijaros también en lo que hemos hablado antes sobre el HAL y el Executive.

¿Realmente Windows es así? Creo que no. Teóricamente si cogéis un programa 100% compatible POSIX y lo ejecutáis en Windows 2000, debería funcionar. ¿Lo hace? Pues no. En su momento lo probé y no funcionaba. Tampoco lo hacía uno de OS/2 cuando ese subsistema estaba, todavía, presente. No es que no funcionaran bien o hicieran alguna cosa rara, es que la mayoría de veces simplemente no cargaban.

¿Ha visto alguno de vosotros un Windows NT ejecutado en un ARM o en un SuperH? Yo no y no creo que funcionen. ¿Vais viendo ya por dónde voy?

Con esto no quiero decir que nunca hayan llegado a funcionar, lo que quiero decir es que yo al menos no lo conseguí en su momento. En un MAC moderno podemos ejecutar prácticamente cualquier comando típico UNIX, desde un “ls” hasta un “ps” pasando por un “dd” o lo que queramos. Aparte de los que la propia Apple ha añadido, que hay unos cuantos.

De nuevo no me malinterpretéis, en ningún momento estoy diciendo que un MAC sea mejor que un Windows por eso. Simplemente estoy diciendo que en un MAC sí que están separadas y presentes las distintas piezas, o al menos así lo creo. De nuevo el tiempo me lo dirá, y yo a vosotros.

***

Y ahora entramos de lleno en .NET. ¿Por qué .NET no es un subsistema y sin embargo está construido sobre Win32, que no es precisamente un API limpia y ordenadita sino más bien todo lo contrario? ¿Por qué no aprovecha Microsoft la arquitectura de los subsistemas para hacer a .NET miembro de derecho propio dentro de Windows y no un mero envoltorio que cada vez se va pareciendo más a lo que envuelve, sobre todo en el tema de la guarrería?

Si ya .NET es algo grande en el aspecto del rendimiento y funcionalidad (comparado con su contrapartida Java y a veces con el propio Win32), ¿qué rendimiento no tendría si fuera un subsistema independiente?

¿O es que toda la estructura arquitectónica de Windows es una mentira como un castillo y no puede haber otros subsistemas cooperando sobre el ejecutivo?

Me gustaría que alguien me aclarara todo esto, porque sinceramente no lo entiendo. Yo tengo mi teoría, que no voy a exponer aquí no sea que se me acuse de lo que creo no soy, y menos ahora que tengo mi calentón de fanboy…

C++Builder XE/Delphi XE Starter edition (como los Express de Visual Studio, pero pagando poco)

Rafael Ontivero — Sat, 29 Jan 2011 11:27:00 GMT

Actualización 31/01/2011: Definitivamente es una realidad. Hoy acaba de ser anunciado oficialmente, con los precios indicados (al menos en USA), y para Europa, como siempre, la traducción 1 dólar 1 euro, es decir, 199 euros para la versión completa y 149 para la actualización. En un primer vistazo, la versión Starter es la Professional pero sin el soporte para UML, refactorización y competado de código, así como de alguna que otra cosilla más...

Hacía ya varios años que BorlandCodegearEmbarcadero no sacaba nada express como ya lo hicieron con sus Turbo Explorer hace bastante tiempo. De hecho esas ediciones ya no se pueden conseguir, ni funcionan las activaciones aunque tenglas la clave...

Pues bien, se comenta por los mentideros de la red que van a aparecer una versiones Starter de los productos citados. Parecer ser que a alguien se le escapó sin querer la semana pasada, y la noticia ha sido comentada hasta el punto de que Embarcadero ha reconocido que está en ello.

http://delphi-insider.blogspot.com/2011/01/delphi-starter-official-announcement.html

http://blog.marcocantu.com/blog/delphi_started_edition.html

http://www.sdtimes.com/link/35223

El mayor problema es que esas ediciones van a ser de pago. Se habla de unos 199 dólares o 149 euros, aunque permiten desarrollar hasta en cinco máquinas simultaneamente y para fines comerciales hasta que los beneficios producidos por ellas no sobrepasen los 1000$ anuales (o al menos eso es lo que creo haber entendido de las noticias en inglés).

No es mala idea ofrecer esos productos a ese precio, aunque si fueran gratis sería todavía mejor ya que tienen que competir con las versiones Express de Visual Studio, que son gratis total para cualquier uso. No quiero hablar de la estupidez que me parece eso de los 1000 dólares, como tampoco del hecho de que Delphi no puede competir con Visual C# Express por la sencilla razón del precio. En el caso de C++ Builder sí que podría existir una sana competencia con su equivalente de Microsoft, más que nada porque, aunque el compilador de C++/CLI es superior, Windows Forms orientadas a C++ son un poco mierdosas, sin hablar de que C++ no vale para WPF (y poco les habría costado implementar clases parciales en C++/CLI)... C++ Builder es mucho más rápido y con mucha más funcionalidad que Visual C++, ya sea con MFC o con C++/CLI y Windows Forms (recordemos que los sueños de Microsoft de dejar atrás C++ han fracasado completamente).

Desde un punto de vista general sí que es una buena jugada, ya que la próxima versión de Delphi/C++Builder se supone será lo suficientemente multiplataforma como para poder desarrollar para Mac y para Linux... o al menos es lo que se pretende. De hecho, toda la documentación y el código fuente que he podido ver así lo indica: en muchos lugares hay compilación condicional para las tres plataformas y en otros la documentación indica que eso no está disponible para Linux o para MAC...

Por lo tanto, una ampliación de usuarios les vendría muy bien para luego vender las nuevas versiones, porque debemos recordar que, al menos C++Builder en sus versiones 2009, 2010 y XE son casi el mismo producto con la diferencia de que cada versión soluciona los bugs de la anterior (y genera nuevos) y trae complementos de terceros. Y es que la goma no se puede estirar más. La VCL está completa, pocas cosas genéricas se les puede añadir, los IDE tampoco dan más de sí, y a lo sumo a C++Builder se le podrían añadir lo que le falta para ser compatible con C++0x...

C++ Builder XE, en su fecha de salida y pese a haber corregido varios miles de bugs de la versión 2010, era un puñadito de caca que casi no podía compilar nada. No obstante unos meses después sacaron el primer parche y el producto se convirtió en lo que debía haber sido en un principio. Esta versión mejora también el sistema de búsqueda (*), y parece ser que hay una nueva actualización de la misma que todavía arregla más cosas. Yo lo estoy usando un poco y ciertamente es bastante más estable que las versiones anteriores.

De todos modos imaginaros el siguiente escenario dentro de uno o años a partir de estas fechas. Un futuro C++ Builder XE 3 Starter gratuito o de coste mínimo, capaz de compilar sólo para Windows y Win32. Y un C++ Builder XE 3 Professional y superior capaz de compilar para Win32, Win64, MAC x64, Linux x64... Esos son los planes de Embarcadero, pero como no se espabilen les van a comer la merienda. QT viene pegando fuerte, muy fuerte.

(*) Lo que demuestra que la tecnología dentro del Document Explorer de Microsoft no es el problema. El problema es la poca preocupación de la integración del sistema de ayuda con los IDE...

El RFOG se renueva, por dentro y por fuera

Rafael Ontivero — Thu, 02 Dec 2010 20:40:45 GMT

Sí, pese a lo que dijo sobre su MAC, al final se ha comprado un PC que sin ser lo último de lo último, tiene su cosa. El MAC está bien, pero le echa a faltar muchas cosas, muchos programas y otros temas, así que, al final, en lugar de comprarse un MAC PRO, se ha decidido por un clónico.

Si os preguntáis qué le ha pasado con su ordenador viejo, no lo hagáis directamente a él, porque va a coger un cabreo de cojones y posiblemente os deje con la palabra en la boca… si no os suelta alguna fresca.

Básicamente su QUAD con 8 GB de RAM se ha quedado en la empresa. Para evitar jaleos y tener la fiesta en paz, ha decidido que no vale la pena batallar por cosa tan nimia (Si no lo sabíais, el RFOG ha pasado, por ordeno y mando, de trabajar en su casa a tener que ir, todos los días, a una empresa, gastando por ello al menos hora u hora y media más de su vida por las mismas prestaciones económicas, y de hecho sigue preguntándose por qué no se ha ido sin más... Corramos un estúpido velo sobre el tema y dejemos la cosa como está.

Bueno, el nuevo ordenador del RFOG está compuesto por una placa Gigabyte (Modelo P55A-UD4) que tiene hasta tres chipsets para discos. Uno para el eSata, otro para los SATA II normales y un tercero para dos discos SATA III. Aparte la placa tiene FireWire 400. Ahí es nada, y también ahí es nada el tiempo que tarda toda la rutina del POST, de hecho más tiempo que el necesario para arrancar su Windows.

Esa placa ejecuta un Core i7 870 a 2.93 GHz que tiene cuatro núcleos dobles con HyperThreading, lo que suman 8. Y bien bonitos que se ven en el Administrador de Tareas. Y también, de momento, no les ha visto el culo, porque no suben del 40% total de tiempo de proceso.

La idea original era ponerle 16GB de RAM, pero al final sólo pudo disponer de 4 porque no le pudieron encontrar módulos de 4GB, aunque le han dicho que en cuanto los consigan lo avisan y se los cambian. De todos modos, 8GB ya son gigas para lo que el RFOG quiere.

La tarjeta de vídeo es una ATI HD6850. El rendimiento es tal que ni el StarCraft II ni el Civilization V a plena resolución hacen que la el ventilador de la misma se revolucione. Ahí es nada. De hecho, apenas nota que tiene algunas cosas con vmWare en modo Unity (que ya es decir).

Luego están los discos. Un SATA II de 1 TB normalito como disco de datos y de seguridad. Y cuatro discos SSD de 64GB en dos RAID 0. Sí, lo que oís, los discos valen más que el resto del ordenador.

Pero ¡chico!, cómo van. Y eso que no son de los más rapiditos que hay, que si no… El arranque de Windows hasta mostrar el escritorio es unos 10 segundos. La tasa de transferencia en copia entre las dos agrupaciones RAID es de unos 220-230 MB/s sostenida (unos 40 GB de una tacada).

A todo eso ha añadido a su ya existente monitor de 24”… otro más. Y como el primero tiene resolución de 1920x1200, el nuevo también la tiene (los modernos traen una de 1920x1080, quizás para poder bajar precios). Y el RFOG se pierde entre tanta pantalla.

***

Eso en cuanto al hardware. Respecto al software la cosa es algo más normal. El SATA II tiene dos particiones, en una de ellas está su trabajo y en la otra se mantienen las copias de seguridad de los otros dos conjuntos RAID, que el RFOG no se fía mucho ni de los SSD ni de los RAID. Relativamente amargas experiencias ha tenido con los últimos.

En uno de los RAID está Windows 7 x64 al completo con algunos programas más, entre ellos vmWare y Office. En el otro hay almacenadas varias máquinas virtuales, en donde se han instalado diferentes programas. En una de ellas está Visual Studio 2010, y en otra, Visual Studio 2008SP1 con los SDKs embebidos. Y así. Esas dos son Windows 7 Ultimate x86 con 3GB de RAMy 2 procesadores con 2 cores, y se pueden tener ambas abiertas sin mucha penalización de rendimiento (en su i7, claro, y más cuando tenga 16GB de RAM).

Y la idea es mantener limpio su HOST e ir intercambiando las máquinas virtuales según necesidad. Su nueva máquina lo da, y de momento la cosa está funcionando bien, con algunos detalles que está puliendo a ratos. Puede poner accesos directos a los programas en su barra de tareas como si una aplicación no virtualizada se tratara, y cuando la lanza primero se abre la máquina virtual en modo Unity y luego se lanza la aplicación.

El único problema es que Visual Studio no se lleva bien con los proyectos situados en carpetas de red, aunque sean compartidas a nivel de vmWare, así que ha metido todos sus proyectos en un disco duro virtual de Windows (VHD) y lo ha añadido a la configuración de la máquina virtual.

Un detalle del que se ha dado cuenta es que la máquina virtual, salvo el acceso a video, es sensiblemente más rápida que la real. Ignora si eso se debe a que es de 32 bits en lugar de 64, o a que al estar el disco comprimido sobre un SSD la rapidez es impresionante…

Evidentemente todo esto es a nivel particular. A nivel de curro la cosa sigue como antes. (Bueno, mucho peor, pero sigue haciendo proyectos interesantes, que quizás sea lo único que lo mantenga apegado a él).

***

Bueno, ya para finalizar, la idea original era hackintoshear la placa base (que se puede, es una de las que tienen el parche de la BIOS) para instalarse un Snow Leopard en nativo y virtualizar todos sus Windows, pero una vez que tuvo delante de sí el PC… se le quitaron las ganas de hacerlo. Es muy posible que en un arranque de aburrimiento lo intente, o que se instale una VM pirateada.

Ya veremos.

Manifiesto por una Red Neutral

Rafael Ontivero — Tue, 30 Nov 2010 16:31:00 GMT

Los ciudadanos y las empresas usuarias de Internet adheridas a este texto manifestamos:

1.Que Internet es una Red Neutral por diseño, desde su creación hasta su actual implementación, en la que la información fluye de manera libre, sin discriminación alguna en función de origen, destino, protocolo o contenido.

2.Que las empresas, emprendedores y usuarios de Internet han podido crear servicios y productos en esa Red Neutral sin necesidad de autorizaciones ni acuerdos previos, dando lugar a una barrera de entrada prácticamente inexistente que ha permitido la explosión creativa, de innovación y de servicios que define el estado de la red actual.

3.Que todos los usuarios, emprendedores y empresas de Internet han podido definir y ofrecer sus servicios en condiciones de igualdad llevando el concepto de la libre competencia hasta extremos nunca antes conocidos.

4.Que Internet es el vehículo de libre expresión, libre información y desarrollo social más importante con el que cuentan ciudadanos y empresas. Su naturaleza no debe ser puesta en riesgo bajo ningún concepto.

5.Que para posibilitar esa Red Neutral las operadoras deben transportar paquetes de datos de manera neutral sin erigirse en “aduaneros” del tráfico y sin favorecer o perjudicar a unos contenidos por encima de otros.

6.Que la gestión del tráfico en situaciones puntuales y excepcionales de saturación de las redes debe acometerse de forma transparente, de acuerdo a criterios homogéneos de interés público y no discriminatorios ni comerciales.

7.Que dicha restricción excepcional del tráfico por parte de las operadoras no puede convertirse en una alternativa sostenida a la inversión en redes.

8.Que dicha Red Neutral se ve amenazada por operadoras interesadas en llegar a acuerdos comerciales por los que se privilegie o degrade el contenido según su relación comercial con la operadora.

9.Que algunos operadores del mercado quieren “redefinir” la Red Neutral para manejarla de acuerdo con sus intereses, y esa pretensión debe ser evitada; la definición de las reglas fundamentales del funcionamiento de Internet debe basarse en el interés de quienes la usan, no de quienes la proveen.

10.Que la respuesta ante esta amenaza para la red no puede ser la inacción: no hacer nada equivale a permitir que intereses privados puedan de facto llevar a cabo prácticas que afectan a las libertades fundamentales de los ciudadanos y la capacidad de las empresas para competir en igualdad de condiciones.

11.Que es preciso y urgente instar al Gobierno a proteger de manera clara e inequívoca la Red Neutral, con el fin de proteger el valor de Internet de cara al desarrollo de una economía más productiva, moderna, eficiente y libre de injerencias e intromisiones indebidas. Para ello es preciso que cualquier moción que se apruebe vincule de manera indisoluble la definición de Red Neutral en el contenido de la futura ley que se promueve, y no condicione su aplicación a cuestiones que poco tienen que ver con ésta.

La Red Neutral es un concepto claro y definido en el ámbito académico, donde no suscita debate: los ciudadanos y las empresas tienen derecho a que el tráfico de datos recibido o generado no sea manipulado, tergiversado, impedido, desviado, priorizado o retrasado en función del tipo de contenido, del protocolo o aplicación utilizado, del origen o destino de la comunicación ni de cualquier otra consideración ajena a la de su propia voluntad. Ese tráfico se tratará como una comunicación privada y exclusivamente bajo mandato judicial podrá ser espiado, trazado, archivado o analizado en su contenido, como correspondencia privada que es en realidad.

Europa, y España en particular, se encuentran en medio de una crisis económica tan importante que obligará al cambio radical de su modelo productivo, y a un mejor aprovechamiento de la creatividad de sus ciudadanos. La Red Neutral es crucial a la hora de preservar un ecosistema que favorezca la competencia e innovación para la creación de los innumerables productos y servicios que quedan por inventar y descubrir. La capacidad de trabajar en red, de manera colaborativa, y en mercados conectados, afectará a todos los sectores y todas las empresas de nuestro país, lo que convierte a Internet en un factor clave actual y futuro en nuestro desarrollo económico y social, determinando en gran medida el nivel de competitividad del país. De ahí nuestra profunda preocupación por la preservación de la Red Neutral. Por eso instamos con urgencia al Gobierno español a ser proactivo en el contexto europeo y a legislar de manera clara e inequívoca en ese sentido.

Si te sientes representado por este manifiesto te pedimos encarecidamente que lo copies y lo publiques en tu blog o que lo menciones en tu cuenta de Twitter o en Facebook usando el hashtag #redneutral. ¡Muchas gracias!