Picacodigos

Los desarrolladores de Mono siguen desesperados por hacernos probar su port de .NET a entornos *nix.

Bien por ellos. Ya en su día nos facilitaron las cosas mediante Monoppix, esa modificación de Knoppix que le añadía Mono para que pudiéramos probar el IDE sin tener que instalar nada.

Siguen empeñados en hacernos las cosas fáciles: ahora la idea que han tenido es distribuir una imagen de una SuSE 10 con Mono, MySQL y alguna otra herramienta listada, lista para ejecutarse con el gratuito VM Player. Pero yo me pregunto, ¿es suficiente?

MonoDevelop, el IDE para Mono, incluye MonoDoc; que es la documentación de todas las clases que componen Mono. Para que os hagáis una idea, MonoDoc es muy similar a la ayuda que viene con el JDK de Java: por cada clase nos informa de su nombre, del espacio de nom bres o paquete al que pertenece, y nos detalla su colección de métodos, propiedades y eventos. Y ya está.

Y no es suficiente.

Sería suficiente si no existiera MSDN, pero da la casualidad de que existe. Y MSDN no se limita a darnos información sobre la clase que varias decenas de herramientas pueden generar automáticamente desde los comentarios escritos en el código, por ejemplo GhostDoc. No, MSDN incluye ejemplos de uso. Para el 90% de las páginas que tiene, MSDN incluye un ejemplo de uso tanto en C# como en VB.NET. ¿Cuesta tanto añadirlos? ¿Es tan difícil?

Si, ya sé que es un coñazo documentar. Lo he sufrido. Sí, ya sé que es más divertido añadir más funcionalidades antes que explicar bien las que ya se tienen. Pero alguien tendrá que hacerlo.

O de cómo Google hizo su propio SourceForge.

Google ha abierto, disponible para todos aquellos con una cuenta de correo GMail, Google Code Hosting, un repositorio para proyectos Open Source alojado por Google. Usa Subversion como control de código fuente, y permite a los administradores de proyectos manejar un tracker de incidencias, administrar los colaboradores del proyecto, añadir vínculos a las posibles páginas Web externas de un proyecto, etc.

Seguiré contando cosas según vaya probándolo.

Sí, lo sé. Comparado con el ritmo de actualizaciones real de este blog, la actividad de hoy está resultando frenética. A ver si ahora os vais a quejar también por eso. ;)

Dos muy buenas noticias para este post. La primera es la reciente actualización de nuestro IDE Open Source favorito para C#, SharpDevelop, a la versión 2.0 del Framework. Lo sé, esto no es ni mucho menos una noticia en tanto en cuanto no es reciente (¡y qué difícil es dar noticias en este medio!): fue el pasado 17 de Julio cuando hizo su aparición oficial la versión definitiva de SharpDevelop 2 2.0.

Pero ahora vamos a por la segunda noticia. Después de descargarlo (4.2 Mbs) e instalarlo (cinco minutos escasos) me dispongo a probarlo. Al crear una nueva solución de prueba (el enésimo Hola, mundo!) se me forma un nudo en la garganta: problemas de compatibilidad a la vista.

SharpDevelop 1 usaba los combines, ficheros con extensión .cmbx, como eje central: los combinados de SharpDevelop eran equivalentes a las soluciones de VS .NET. Por lo tanto, cuando veías en tu disco duro un fichero con extensión .cmbx sabías que era un fichero de SharpDevelop, y estaba por defecto asociado en el Explorador de Windows a dicha aplicación. Los ficheros .cs, .resx, etc. podías decidir con qué asociarlos.

Los combinados han desaparecido (al menos, hasta donde yo he probado) en SharpDevelop y han sido sustituidos por soluciones, como en Visual Studio. Y su extensión es la misma: .sln.

Horror. Ya me estaba imaginando teniendo que crear una carpeta para los proyectos VS y otra para los proyectos SharpDevelop, ya me estaba imaginando a los dos IDEs peleándose por la asociación con mis ficheros como dos web browsers en celo, ya me estaba imaginando el corromper sin remedio una solución de un tipo al abrirla con el IDE que no era, etc., etc.

Pues no ha habido tal. He creado una solución muy tonta, con dos controles DateTimePicker y un botón en VS 2005. Lo he compilado, y lo he probado. Después lo he abierto en SharpDevelop 2 (eso sí, habiendo cerrado previamente VS 2005) y me he preparado para lo peor. Sin problema: SharpDevelop no me ha dicho absolutamente nada sobre la solución, y la ha compilado y ejecutado como si fuera hija natural suya. Hago algún cambio en SharpDevelop 2, compilo y ejecuto. Guardo y cierro. Abro la solución en VS 2005, convencido de que ahora sí que voy a tener problemas: los desarrolladores de SharpDevelop 2 habrán tenido cuidado de que su IDE pueda abrir soluciones hechas en otros IDEs, pero los de Microsoft no creo que lo hayan hecho.

De nuevo me decepciono: VS 2005 ha recogido los cambios realizados sobre la solución en SharpDevelop 2 como si los hubiera hecho él mismo. Compilo, ejecuto. Sin problemas.

A falta de pruebas más serias, como sería por ejemplo una aplicación ASP .NET, o incluir en el proyecto una batería de tests de NUnit, me alegra comprobar que de momento SharpDevelop 2 y VS 2005 son absolutamente compatibles.

Mientras que algunos, entre los que me incluyo, nos vemos a veces tentados por los cantos de sirena de la Web 2.0 y damos al escritorio de toda la vida prácticamente por difunto, otros se empeñan en demostrarnos que de muerto, nada.

Lo que podéis ver en el vídeo de arriba es una demostración de un prototipo de escritorio 3D, que utiliza datos físicos reales para emular un escritorio de verdad en el escritorio virtual de nuestro ordenador. Con él podremos ordenar los iconos en pilas, tirarlos, arrugarlos, hacerlos más grandes o más pequeños, ordenarlos, colocarlos en estanterías, etc... Habida cuenta la entusiasta respuesta que ha tenido el sistema, están pensando en pasar de prototipo a producto y para ello están buscando expertos en C++ y OpenGL. Más info, en su página, de donde también podréis descargaros el vídeo de demo en mejor calidad.

Me reservo mi opinión sobre la utilidad real de este nuevo sistema de escritorio, principalmente por mi forma particular de utilizar mi escritorio. Mientras que otras personas tienen literalmente atiborrado el escritorio con cientos de iconos y documentos, yo lo mantengo lo más limpio que puedo: generalmente el icono de Mi PC y la Papelera de Reciclaje. En mi caso el escritorio no es un lugar de trabajo: sólo lo veo cuando acabo de encender el monitor y justo antes de ponerme a invocar ventanas. Por lo tanto, para mí no sería de demasiada utilidad. Curiosamente, el orden espartano que mantengo en el escritorio de mi sistema no tiene absolutamente nada que ver con el desorden de mis mesas de trabajo, tanto en casa como en el trabajo remunerado. La primera desventaja de BumpTop sería, por tanto, lo fácil que resultaría emular el desorden real en el desorden virtual. Imagino entonces que el tiempo que uno tarda en reorganizar un escritorio real, y el tiempo que tarda el caos en volver a adueñarse de él, tendrían su fiel contrapartida virtual.

El segundo pero es que es algo tan, tan bonito que ya no necesitaríamos la web para hacer el vago: podríamos hacerlo directamente en el escritorio.

Como quiera que el problema del almacenamiento sigue siendo problemático; estuve por la tienda online Alternate viendo qué soluciones, y en qué rango de precios, tengo disponibles.

Cada vez tengo más claro que lo que necesito es un NAS: un dispositivo conectado a una red local, con gran capacidad de almacenamiento, que sea capaz de servir ficheros a varios sistemas operativos a una velocidad decente. La clave en todo esto es la capacidad de almacenamiento: cada día me fío menos de los DVDs y CDs.

Uno de los sistemas que más me han gustado es éste: Buffalo Terastation. 1 Tera de almacenamiento, rack de discos duros extraíbles mediante hot-swapping, sistema RAID, control de calor, servidor de impresión incorporado, servidor FTP incorporado, con la gracia añadida de disponer de cuatro entradas USB 2, para poder conectarle otros tantos discos duros externos. Me dirijo a la página web del fabricante del producto para ver más especificaciones:

Y ahí es donde salta la sorpresa. El dispositivo incluye un sistema de copia de seguridad con un nombre un tanto desafortunado:

Efectivamente, el sistema de backup se llama Memeo. De la risa. ;)

Estoy AGOTADO con el tema Windows/Linux, en serio. Llevo unos cuantos días discutiendo en varios blogs y foros y es que no hay manera, no hay nada que hacer. La comunidad libre no tolera la disidencia, y a la mínima que alguien sugiere que está con el Imperio del Mal pues ya es un vendido, un sicario mafioso, un inútil, un facha, etc... Y no exagero nada: me han llamado, con esas mismas letras o insinuándolo, todo eso en esta semana pasada.

Sólo por disentir de la opinión establecida. Sólo por no estar de acuerdo con ellos. Sólo por no querer comulgar con ruedas de molino.

Pues vaya con la comunidad libre. Qué poquito les gusta la libertad de los demás.

Y no quiero prolongar más este tema.

Ésa y no otra es la razón por la cual, y como medida excepcional, los comentarios de esta entrada y la anterior quedan cerrados. Si ellos (¡¡cómo me jode que tarde o temprano todo se convierta en un nosotros contra ellos!!) tienen el derecho a juntarse en manadas y apedrearme públicamente por tener una opinión distinta a la suya, me concederéis el derecho de mandaros a todos lejos, muy lejos y de ignoraros.

Hasta más ver, comunidad libre. No ha sido un placer.

Como los lectores de Velocidad de Escape ya sabréis si leéis también los comentarios, ando estos días liado probando una distribución de MonoDevelop, el IDE para programar con C# en escritorios Gnome. Arranco el Synaptics, un gestor de paquetes de Ubuntu para descargar e instalar programas; y busco "MonoDevelop". Me carga una lista con los paquetes que ha encontrado bajo tal nombre, y yo marco el que parece el principal. Automáticamente, Synaptics detecta que ese paquete principal tiene una serie de dependencias y me avisa de que va a marcarlas también. Correcto, no problemo. Pulso en Aceptar y Synaptics se pone a descargar los paquetes de algún sitio que desconozco y que, de momento, no me importa. Luego se pone a configurarlo, supongo, y voilá! Ya tengo instalado MonoDevelop. Efectivamente, al navegar por el menú de Ubuntu hasta Aplicaciones, Programación veo que se ha añadido un icono de MonoDevelop que al pincharlo funciona y me arranca el entorno de desarrollo. Perfecto. Fantástico. Maravilloso. Nótese que en ningún momento he tenido que hacer una búsqueda de absolutamente nada en Internet, ni preocuparme de ir a ningún sitio como SourceForge a bajarme ningún binario, ni fuente ni nada de nada, que luego tuviera que buscar por el disco duro y hacer doble clic para instalar o, aún peor, tener que recompilar o configurar manualmente o demás zarandajas. Buscar, click e instalar. Una simplicidad tan absoluta que parece Zen: éste es el camino.

Desgraciadamente, también ha sido la notable excepción del fin de semana. Lo primero, el tema de mi tarjeta Wireless, que no he sido capaz de hacer que funcione. De ningún modo; y he mirado Wikis, páginas, tutoriales e incluso he consultado en IRC¹. Y aquí es donde se ha hecho evidente uno de los puntos débiles de Linux. Mi tarjeta wireless tiene un chipset Atheros: dependiendo de con quién hablases o qué web consultaras, el chipset Atheros era estupendo para Linux o no funcionaba ni para atrás. Según algunos, era imprescindible utilizar ndiswrapper y para otros no, para otros era el MadWiFi que, incidentalmente, es el que he probado yo sin resultados. Bueno, he conseguido que vea una red que no es la mía ni la de ninguno de mis vecinos, y no tengo ni puñetera idea de dónde sale. Ya es algo. Y yo no hacía más que preguntarme si esa diversidad de opiniones (en cosas que no admiten opiniones, ojo: 2 más 2 son cuatro, un chipset funciona o no funciona) iba a ser la excepción o la norma. Parece ser la norma, y eso se me antoja difícil de tragar para un hipotético futuro nuevo usuario. Ya sé que la culpa es del fabricante de la tarjeta PCMCIA, que no publica drivers para Linux. Pero cuando un fabricante hacía malos drivers para Windows, y esos malos drivers producían pantallazos azules, ¿a quién le echáis normalmente la culpa? Pues eso.

Después, las instalaciones. Como no sabía muy bién que hacer con ese sistema operativo nuevo y flamante, me he puesto a instalarle cosas. Y, como ya he dicho antes, lo de MonoDevelop ha sido un espejismo. No niego que la mayoría de las veces que algo no me ha funcionado (por ejemplo, compiz) haya sido por negligencia mía. Pero un fin de semana de manipular configuraciones, aprenderme el sudo gedit /usr/bin/archivo o el sudo apt-get update pues no ha sido muy divertido. Más que nada por dos razones: la primera, la frustación. Si después de seguir un tutorial de cómo instalar y/o configurar algo a pies juntillas consigues que funcione, pues estupendo: no te importa el tiempo que has tardado en hacer lo que otros consiguen con un doble click, porque al menos te queda la (falsa) impresión de que estás aprendiendo. Y la segunda razón es, también, la frustración: tienes que seguir como la Biblia un tutorial que te dice que ahora tienes que hacer un apt-get, y luego hacerle un alien al RMP para convertirlo en DEB y después editar un script de configuración y después darle permisos de ejecución a ese script,... y jamás se molesta en explicarte qué estás haciendo ni por qué lo estás haciendo. Y así tampoco se aprende.

Miedo me da pensar que me queda por instalar MySQL, Ruby, OnRails, Apache, y un buen montón de cosas....

---

1.- Vaya desde aquí mi más sincero agradecimiento a la gente del canal #ubuntu en IRC Hispano, que me echaron una mano con paciencia y buen humor. A pesar de ser Windowsero confeso. Si me pilláis una de estas tardes trasteando con Linux, seguramente me encontraréis en ese canal. Actualización 17/06/2006.- A tenor de los acontecimientos de los últimos días, que detallo en el post del 17/06/2006, se cierran los comentarios de esta entrada.