knocte :: MonoTema

Really sad to read this:

.NET Culture Shock: Why .NET Adoption Lags Among Startups

Especially sad to find that Mono is not mentioned in the article.

Especially super sad to find that Mono is mentioned in the comments, but in a negative way.

Hey Mono community, help me reply all this nonsense.

Labels: CSharp, General, Ingenieria, Mono, Programacion, SoftwareLibre, WebDev

Some years ago, I started to get familiarized with abbreviations like 'l10n', 'i18n' when I started contributing to the translation efforts of Mozilla & Firefox under the NAVE Project.

Some months later I came to know the new term 'a11y', and I started to see it in a lot of places. By that time, I only associated it with the web development world. Terms like "Unobstrusive JavaScript" were very related to it (and I even created an "AJAXy" library called AMUSE for this purpose).

Now let's talk about the next one: I14Y. This concept is present when things like this happen: "I can open an (Microsoft's)OpenXML file with some (Novell's) edition of (Sun's)OpenOffice". Or even more weird things: "I can manage my (Apple's)IPod thanks to a (Microsoft's).NET-powered application called (Novell's)Banshee". Or even more awesome ones: "I can use (Sun?'s)Orca screen reader to control my (Microsoft's)Windows.Forms-powered applications in my (Novell's)SUSE Linux Box!".

So, yeah, we made it! Along with the awesome releases of Mono 2.4 and MonoDevelop 2.0.

Now, guess what's the word?

Labels: CSharp, General, Ingenieria, Mono, Mozilla, Programacion, SoftwareLibre, WebDev

I'm going to give a brief summary of what I've done in the past weeks (and specially previous week (last one in August), sponsored by Novell as The Hackweek - a form of ITO, in which you can hack at working hours and not only spare time!

I was not so lucky as most of my teammates, who spent the week on the wonderful offices (as they say) of Novell Utah. Maybe if I was in the states already... but well, I had recently an interview in the US Embassy which was the last step of my visa process, so I hope that at least I can make it for the Gnome Boston Summit!

So, firstly I thought of dedicating my week to this task that I submitted to the ideas website, but in the end realized it would be a ton of work to complete without help, and nobody joined me so I decided to learn to use OpenSuseBuildService in order to package Bugzilla, a pretty complex server side software.

Fortunately, I've learnt a lot this week, especially thanks to all the people in irc://irc.freenode.net/#openSUSE-buildservice (above all, darix) and some people from my team (Ray Wang and Stephen Shaw). I could also contact the author of the RPM file for Fedora (who was formerly working for Red Hat), and he's willing to help on joining efforts, as OBS is cross-distribution.

Unfortunately, packaging is a complex task and I didn't finish the package. The documentation is a bit incomplete and having past experience in packaging is a plus that I didn't have. It's awesome that inside our UIA Team we have exclusive resources dedicate to this, because it would be impossible to do from just the developer side.

One of the difficulties I found is finding packages I needed. I could find some of them (BTW, using Webpin is cool for searching on SUSE software repositories, including Packman; except for the fact that doesn't enhance one-click-install) but not all so then I'll have to help on providing packages for some CPAN Perl modules, contributing to the devel:languages:perl official repo.

On the way of learning OBS, I also filed bugs and feature requests (not only to OBS, but also to Banshee! as I have been using it a lot lately at the same time I hack and I even cooked some small patches):

OBS:
Usability issues in project creation page
Link to "My projects" fails if no home:login project has been created yet
New option for uploading the tarball
ChangeLogs parsing is too strict: lines beginning with tab are not recognized, only one date format is accepted
OBS should not allow to create a package named "packageand"
The spec parser should detect the use of a miscplaced packageand(_:_) keyword

Banshee:
No such file or directory errors while importing
Cannot empty some ID3 tag fields
Importing songs without album metadata breaks artist navigation on the iPod
Banshee inserts deduced fictional text on metadata
Should try to locate correct album (and download its cover) in case no album is supplied on metadata


The patches are quite simple so I hope they get committed soon! Clearly Banshee devs and contributors are doing an amazing work, I'm specially amazed by the Moonlight effects, the Muinshee front-end and the effort that it seems is being dedicated to bring Library Sync & Refresh for 1.4. I wish them all the best success.

So let's get back to packaging. Firstly I thought I had found some limitations in OBS or rpm systems because the lack of proper "dual dependency" support. In the past when I installed Bugzilla manually (and updated it to newer versions) I found it a bit hard to do it, specially to deal with DB creation and upgrade. I wanted to make this process easier for the potential rpm user, but without limiting the choice of the DB engine used (as now Bugzilla supports MySQL, PostgreSQL, and Oracle, although the latter was not on my scope). It turns out that it's really hard to apply virtual-provides rules for these cases, as we should stablish more sub-dependencies depending on the db engine you choose, such as perl-DBD-mysql or perl-DBD-Pg, and because it would cause inconsistent situations in case someone in the future replaces his DB-engine with the alternative one (as in theory it should work at the dependencies-level without warning). For references, you may be interested in reading the whole thread about it in the BuildService mailing-list, whose last message includes a possible hack to workaround these problems using patterns (although I don't like to use patterns for solving something like this).

Even discarding the dream about solving this at a package level, it's difficult to solve it at an app level that wouldn't involve reading manuals. My idea was to modify Bugzilla upstream in order to avoid running manually a local script for its initialization, and replace it with a nice web front-end (even if it's only allowed to be run locally). That would cause problems because normally the webserver user doesn't have enough permissions to create files and the database tables and initial data (I'm sure there's always a solution that also doesn't expose security problems, but it's hard to find it as it's noticed in this thread in bugzilla devel newsgroup; so, help is truly welcome).

Maybe the easier and fastest solution is a mixture of both worlds, that is, having a web front-end that asks you the initial configuration, and the form submission process just writes it in a local XML and tells the admin to open a console and run a script as root to finish the process. But even with this solution I guess we should need something to detect at runtime (which should be cross distribution) if some package is installed (which also checks the version). I guess there's already some of that capabilities used in the bugzilla's script checksetup.pl, so I would reuse them. However, in case it finds a problem, there's no way for the application to request installation of a package directly to your OS (but I've attended to a PackageKit conference in last Guadec in which I heard something about this possibility in the future!).

Labels: CSharp, General, Mono, Mozilla, Programacion, Seguridad, SoftwareLibre, WebDev

And we have to thank the cool Adobe's Open Screen Project for this. Why is this positive (extracted originally from here)?

1) Projects that seek to implement this standard (like Gnash), won't have to do reverse engineering anymore (unless the spec is not enough for some things, or the official Adobe software contradicts the specs because of bugs/typos).

2) These projects will provide implementations for architectures that are not supported by the official Adobe propietary software.

3) The implementations will no longer be considered risky because of future patents or intellectual property violations.

But, BEWARE:

a) this doesn't mean that Flash is now free/open source. This only means that projects like Gnash are analogous as Mono right now: they are open source projects that follow a standard published by a company with an open spec.

b) this doesn't mean that any flash content is patent-free either, because you can still embed proprietary formats inside it like MP3.

What I'll do now is start supporting Gnash, firstly by testing it and reporting any bugs I find. Fortunately I have some packages ready for OpenSUSE!

This news is positive, of course, but now let me give my technical opinion of this technology:

- The programming languages you can use with it are very few (some months ago I think the only one was ActionScript, which has the majority of limitations of JavaScript) and still today AFAIK there's no statically typed language you can use.
- AFAIK it's not accessible (and I mean for disabled people and for automation technologies like search-engine-bots).

However, with Moonlight, you already know that you can use C# with it so the first of these disadvantages doesn't affect it. And in respect to the last item, well, the second phase of my project in Novell is bring accessibility support to it so this item will be hopefully solved soon.

Will this mean the end of the Flash monopoly? Will this force Adobe to open its software too?

BTW, is Moonlight/Silverlight one of the reasons for publishing Flash specs freely? All I can see is that in Adobe they are start to changing their minds quickly. One of the most important facts of this is the liberation of the Tamarin project, which has supposed a big step forward in the Mozilla community (FYI, the Mono VM was also a candidate for the Tamarin current job, but unfortunately wasn't considered in the end).

Well, and how's the progress of the first phase of the A11Y project? We're progressing slowly, but hopefully cooking the base for the ton of work we already lack. Many issues are because we needed to complete Atk#, and other ones are appearing which may be related with the runtime (hopefully not, but here they are if you want to have a look: 386802, 387221). I have to thank Mike Kestner for all his help in this side (thanks to him I'm learning a lot about bindings, and about how delicate :) are the glib/gtk/atk bindings in particular; I love when someone is so meticulous for maintaining a project!), and Sandy for all the help on the bridge (which recently got a nice refactoring, but I already got some additional ideas I need to share...). Mike Gorse seems to progress a lot (and now there will be cooperation with CodeThink as well on the CORBA->DBUS migration!), and Mario is starting with us these days, welcome Mario! Unfortunately I don't deal too much with the rest of the team (Brian, Calen, Neville, Ray) but they seem very busy too all the time!

Update 23-DEC-2008: I have tested Gnash on OpenSUSE 11.1 and the Firefox plugin doesn't work with YouTube :( However, according to the comments of this blog post, SWFdec is a much better alternative (so I have changed the title of this entry).

Labels: CSharp, General, Miscelanea, Mono, Mozilla, Programacion, WebDev

[English version below]

DESDE: Me enorgullece comunicar que finalmente el Planeta Mono-Hispano ha resucitado! Felicitaciones a toda la gente involucrada en que esto saliera adelante.

PARA: Si estás terminando tu carrera de Ingeniería Superior en Informática en la UPM (donde yo la hice también), conozco una profesora que está buscando un alumno para hacer un PFC en el que tendrá que usar Silverlight/Moonlight, así que si estás interesado, ponte en contacto conmigo!

--

[English version]

FROM: I'm glad to tell that finally the Mono-Hispano Planet has resurrected! Congratulations to all the guys involved in making this happen.

FOR: If you are finishing your engineer's degree in Computer Science at the UPM university (where I did in the past), I know a teacher that is looking for a student to do his PFC (how do you guys call this en English?) using Silverlight/Moonlight, so if you're interested, contact me!

Labels: CSharp, General, Ingenieria, Mono, Programacion, SoftwareLibre, WebDev

Mucho se ha hablado ya en internet sobre estas dos nuevas versiones de los navegadores más usados. Yo no voy a dar más el coñazo contando lo mismo, pero sí voy a dar mi opinión sobre ello.

En primer lugar, me parece genial que Microsoft se haya puesto las pilas y haya decidido mejorar un software que, a pesar de su monopolio y su uso masivo, llevaba más de 5 años sin actualizarse, provocando así un estancamiento brutal en lo que a tecnologías web se refiere, pues prácticamente el 100% de los desarrolladores web tenían que amoldarse a este viejo navegador, el cual sigue teniendo muchos fallos e incompatibilidades con los estándares de la industria. Han arreglado problemas con la visualización de PNGs y ciertos bugs de CSS, pero aún les queda muchísimo por recorrer, sobre todo en temas de JavaScript (EcmaScript) y la API de DOM.

¿Los bugs que se han encontrado? Me parece una ridiculez pelearse por eso o basarse en ellos para argumentar sobre la calidad de uno u otro navegador. Lo que importa es la gravedad de cada invulnerabilidad y el tiempo de respuesta en su corrección, y he de confesar que, pese a la mayoría de las declaraciones de personas relacionadas con Mozilla sobre el de Firefox, un bug que permite a un desarrollador web colgar el navegador del visitante o volverlo inusable me parece bastante grave (¿quizás ahora no tanto gracias al restaurador de sesiones? ¿o acaso la restauración de la sesión implica la recarga de la página que provoca el bug, invalidando este workaround?). Además, lleva bastante tiempo sin arreglarse el problema de seguridad más simple del mundo (bug): poner un alert("hola") bajo un bucle infinito en una página. Como las alertas de JavaScript son modales y no son locales a cada pestaña sino que roban el foco de la pestaña actual, y la ejecución de JavaScript no se puede detener, esto se convierte en un bug que representa el mismo problema que el bug anteriormente mencionado y más polemizado: un desarrollador web puede inutilizar la navegación de un visitante.

Las cosas positivas que veo de todo esto: la gran cuota de uso que están teniendo los navegadores alternativos está provocando que los desarrolladores web en general se preocupen más por los estándares, lo que hace que se pierdan menos usuarios por la falsa y típica sensación de que los navegadores basados en Gecko no son capaces de abrir todas las páginas. Y esto mismo ha provocado que Microsoft tenga por primera vez que darse cuenta de que tiene competencia y a movilizarse, lo que como consecuencia tendrá una mejor calidad de vida (profesional) de los desarrolladores web y un aumento en la innovación en el campo de las tecnologías web (¿veremos por fin la publicación oficial de CSSv3?). Otra cosa positiva es el apoyo que veo que le dan algunos medios a Firefox: por ejemplo Informativos Telecinco o 20minutos (INCISO: atención a la última palabra de la URL del enlace que acabo de poner, no le veo ningún sentido, la verdad), el único periódico que conozco que tiene licencia Creative Commons (copyleft) en sus contenidos, lo que creo que influyó bastante para que en NAVE decidieramos que esta vez el canal RSS incluido por omisión en el navegador apuntara a esta fantástica fuente de noticias.

En fin, para despedirme, voy a dar un regalito a los usuarios de SUSE: Mozilla BuildService Repository.

Labels: General, Mozilla, Programacion, WebDev

Hoy he tenido que desconectar y reconectar un cable RJ-45 y, ¿qué me ha evocado eso? Un grave sentimiento de frustración al encontrarme con un invento satánico: la pequeña protección de plástico que recubre la pestaña del conector RJ-45, que quien la inventó pensaría que facilitaría la tarea de apretar la pestaña para desconectar el cable, ¡¡¡craso error!!! Pues la dificulta en varios órdenes de magnitud.

Otro invento satánico podría ser la tecla CAPS LOCK, como ya otro mortal ha denunciado, ¿alguna vez la habéis utilizado? Yo creo que sí, hará como 3 o 4 años. En fin, que provoca más dolores de cabeza que utilidades reales.

Por último, me viene a la cabeza lo que parece una costumbre, y no una invención, pero que tiene el denominador común de la estupidez también entre los diseñadores de páginas web: el botón "Restaurar"/"Borrar" de los formularios web. ¿Alguna vez lo has utilizado? ¿Alguna vez has tenido que borrar de golpe todos los datos que has introducido? ¿No os parece completamente inútil e idiota? Creo, incluso, que hasta me ha provocado algún que otro considerable disgusto por culpa de un mal uso (o uso ausente) del atributo tabindex del XHTML.

Labels: General, Miscelanea, WebDev

Parece que los programas de workflow están de moda. Sobre todo los basados en web, que son muy fáciles de instalar (para el usuario, que no de administrar para el sysadmin) pues sólo se necesita un navegador.

En realidad, ¿qué es un workflow? Es un concepto un poco "cajón de sastre" pero básicamente es un software que te permite archivar, monitorizar, en general ayudarte a gestionar las tareas en un entorno de trabajo. Hay workflows más generales (como eGroupWare) y otros más específicos (como por ejemplo Bugzilla, que se centra en la gestión de bugs [defectos] en el software).

La verdad es que yo soy un enamorado de Bugzilla y siempre he pensado que se podría usar como workflow "general" a falta de alguna que otra funcionalidad, como wikis, calendarios con timelines/roadmaps, etc. Porque yo creo que es el software de gestión de incidencias más maduro y completo que existe.

¿Y por qué ahora he utilizado la palabra incidencia en lugar de defecto? Pues porque hay una interesante polémica desde hace bastante, en torno a este software, que consiste en que un cierto grupo numeroso de personas abogan porque esta herramienta gestione no sólo defectos o petición de nuevas funcionalidades (enhancements) sino también simples y llanas "tareas". Luego existen otros dos grupos en contra de esto: los primeros se escudan en que Bugzilla nació para ser un software de seguimiento de defectos del software, y no más, y luego hay otros que aseguran que un "bug" también puede ser válido como acepción general de una tarea.

Yo a estos últimos les preguntaría ¿la tarea de, por ejemplo, configurar un apache, se podría considerar un bug? A mí me suena un poco raro... Pero no me voy a casar con nadie, así que yo he encontrado mi solución particular, jugando con los "value fields" de Bugzilla, ya que originalmente contienen:

Gravedad/Severity: blocker, critical, major, normal, minor, trivial, enhancement
Prioridad/Priority: P1, P2, P3, P4, P5, P6

Si nos fijamos, el campo de prioridad es tan poco descriptivo que ni siquiera sabemos si P1 es el más o el menos prioritario; y el segundo es tan ambiguo que parece que en sus valores se están mezclando prioridad, gravedad, complejidad, y tipo de incidencia. Así que yo he optado por usar los valores siguientes

Severity (gravedad): critical defect, major defect, normal defect, slight defect, improvement, new feature, task.
Priority (prioridad): undecided, showstopper, urgent, normal, interesting, desirable

Con esto yo creo que resolvemos el problema de la ambigüedad de la gravedad y a la vez tenemos un workaround para el bug #88177 ;)

Para cubrir las necesidades de workflow que no cubre este "bugzilla parcheado" podemos recurrir a eGroupware o derivados. Sin embargo, puesto que soy un ex-programador PHP, en el sentido en el que cuando me cambio de equipo ya no puedo ni acordarme de lo antiguo, pues siempre me atraerán más los proyectos que se casen con una arquitectura de desarrollo más decente. Es el caso del recién nacido NProject el cual usa el eficiente CastleProject (que usa por debajo MonoRail, ActiveRecord + NHibernate, etc.) el cual es un framework que es el resultado de un port de Ruby on Rails a C#. Parece que en cuestión de frameworks web MVC, éste junto a Maverick.NET y Spring.NET son los más populares.

Otros podrían decirme: "¡pues Bugzilla está programado en Perl, ¿qué me dices de eso?" En cuyo caso respondería: ojalá tuviera tiempo de emprender mi propio proyecto "NBugzilla" o "MonoBugz" para conseguir, no sólo una herramienta divertida de usar, sino divertida de programar y extender. Y es que podríamos hacer uso de una arquitectura bastante apetecible en la que manejar casi cualquier base de datos gracias a NHibernate (al contrario que el Bugzilla actual que sólo soporta MySQL y PosgreSQL), o bien una base de objetos como DB4O, o bien soporte configurable para ambas cosas, etc. Es un proyecto que propuse en el GoogleSoC pero que evidentemente distaba mucho de ser aceptado :)

Volviendo un poco desde las ramas, me gustaría comentar mis andanzas a la hora de instalar este workflow que me gusta tanto: la primera vez lo instalé desde las fuentes en una distro Mandriva, la segunda con un RPM automático (aunque al final no tan automático, ¡oye!) en otra versión mejor de Mandriva, y esta tercera ha sido en una Ubuntu, con los siguientes procesos prueba-error (es una pena que OpenSUSE no incluya un paquete para Bugzilla):

1. Instalación del paquete del repositorio universe, versión 2.20, con mucho miedo (las cosas no oficiales, es lo que tiene).
2. Problemas de configuración.
3. Problemas con el envío de correo.
4. Desinstalación de sendmail e instalación de postfix.
5. Errores de corrupción de tablas MySQL.
6. Reinstalación desde cero.
7. Problema con los caracteres internacionales (tildes, eñes, ...) en el envío de correo; al parecer resueltos por la versión siguiente (v. 2.22) gracias a UTF-8.
8. No existe la versión 2.22 en Ubuntu Dapper.
9. No parece que estén disponibles todavía los paquetes de Ubuntu inestable.
10. Localización del paquete de Debian Sid (inestable) con la versión 2.22.
11. Desinstalación y purgado de lo antiguo.
12. Instalación del paquete de Debian en Ubuntu.
13. Problemas de configuración no resueltos.
14. Tiro la toalla e instalo el programa desde fuentes.
15. Versión obsoleta del módulo estable de CPAN llamado Mail::Mailer.
16. No hay versión inestable Debian/Ubuntu del mencionado módulo.
17. Instalación manual del paquete por CPAN.
18. Configuración correcta.
19. Todo funcionando correctamente.

Sólo tengo clavada una pequeña espinita (al parecer asignada para su implementación en la 2.24).

Me ha gustado esta versión: la configuración general del programa (malamente llamada "Parameters") ahora está dividida en secciones por temas; existe opción de editar automáticamente los "Field values" de los que ya os he hablado, sin la antigua necesidad de recurrir a un fichero de texto y especificarlos al inicio para luego ser inmutables.

Actualización 03-SEP-2006: Parece ser que el concepto de Workflow es algo más subjetivo y diluido como para asociarlo a este tipo de gestores de incidencias. Parece que hay gente que lo atribuye más a programas de gestión de diagramas de flujo (los típicos que dibujamos los informáticos antes de describir un algoritmo), o incluso otros van más por el lado ERP, y un ejemplo concreto es el NetBPM, al parecer hecho con y usado por el proyecto Mono, que tiende más a la gestión al estilo Microsoft Project, en el que podemos incluso gestionar peticiones de vacaciones de los empleados (una demo aquí).

Actualización 17-NOV-2006: También me gusta más renombrar el estado ASSIGNED a INPROGRESS, lo que se puede hacer editando el fichero /var/www/bugzilla/template/en/default/global/field-descs.none.tmpl a partir de la versión 2.20.

Actualización 2-FEB-2006: Resulta que cambiando el valor a INPROGRESS en el punto en el que he mencionado antes, sólo lo cambia para la intefaz gráfica pero el valor lo sigue poniendo como ASSIGNED en los emails enviados, así que voy a investigar como se hace el cambio bien. Otra cosa que echo en falta es un campo nuevo para la "complejidad de la solución estimada", que bien podría dividirse en dos: un campo con valor enumerado, y otro con una estimación de tiempo de resolución de la incidencia.

Actualización 20-MAY-2006: Vaya, viendo esta página sobre Bugzilla puedo comprobar que se empieza a imponer el sentido común: y es que usar Perl para una herramienta tan grande empieza a verse como un handicap, y se están proponiendo alternativas para reescribirlo desde cero. Como no, he colocado mis propuestas en la página de discusión, máxime al ver que no existía una sección de Mono y sólo un párrafo hablando de C#. Si Mono no se lleva el gato al agua (que parece ser lo más seguro, dado el poco apoyo que tiene), espero que al menos gane Java.

Actualización 04-NOV-2007: Otra característica interesante de bugzilla para poderle cambiar la cara y que se adapte más a una herramienta de tipo genérico de ticketing o workflow, es la capacidad de cambiar la palabra "bug" por otra distinta, como "issue" o "ticket". Aquí más información.

Actualización 13-MAY-2009: Resulta que el tema de que las prioridades predeterminadas no son entendibles y el bug de que Enhancement sea un valor del campo "Severity" tienen sus correspondientes bugs abiertos!:
- Bug classification field: este bug tiene nada más y nada menos que 10 años de edad.
- Default Priority values are unclear: ya he aportado mi sugerencia aquí :)

Labels: General, Mono, Mozilla, Programacion, SoftwareLibre, WebDev

Estos días me he puesto a empezar un pequeño proyecto que tengo en mente desde hace mucho tiempo: la versión 3.0 de Prodler, que no es, ni más ni menos, que lo que en su día fue mi proyecto fin de carrera: un CMS vía web que programé con PHP4, sistema de plantillas Smarty, especificación XHTML, estilos CSS (multi-skin), unas librerías agnósticas de acceso a base de datos llamadas DBX (aunque en producción utilicé MySQL), JavaScript no intrusivo, internacionalización (i18n) mediante GetText, etc.

Siempre he tenido ganas de ir actualizándolo poco a poco (por ejemplo el cambio más inmediato era pasarlo a PHP5) pero mis buenas experiencias con C# y Mono han hecho que cambie el chip completamente y que me entraran ganas de rediseñar completamente su arquitectura.

Y ya estoy empezando: usaré mi arquitectura predilecta, con C#, pero no ASP.NET sino Maverick.NET con plantillas XSLT de transformación XML en XHTML. Para los datos usaré DB4O y para la internacionalización usaré un método casero que me estoy montando mediante XSLT. Y todo esto lo pondrá en funcionamiento el motor de Mono, el módulo mod_mono para Apache (AutoHosting activado), y por debajo una SUSE 10.1 coordinándolo todo.

Prodler 1.0 estaba hecho con las siguientes tecnologías, la mayoría propietarias: IIS + ASP (HTML) + MS Access + JavaScript...
Prodler 2.0 fue un cambio radical de arquitectura a sistemas basados en software libre, usando PHP, Apache, MySQL.
Y ahora Prodler 3.0 vuelve a cambiar para basarse en una tecnología (.NET) que inicialmente fue creada por una empresa que crea software privativo mayoritariamente (Microsoft), pero que puede seguir basándose en software libre gracias al proyecto Mono.

Labels: General, Mono, Programacion, WebDev

Bueno, pues acabo de llegar de unas conferencias en la UEM, patrocinadas por Hazent Systems, que han sido muy interesantes. Bueno, a la primera he llegado tarde, la segunda no me ha gustado demasiado (la tecnología VoIP no es una cosa que me entusiasme, de momento) pero la tercera ha estado bastante bien, porque desconocía que hubiera un equivalente en el software libre a la tecnología Passport de Microsoft (que se engloba como una técnica de S.S.O.: Single Sign-On), y menos que estuviera tan evolucionada como al parecer ocurre, ya que incluso hay estándares que ya van por la version 2.0, como SAML, promocionados por la iniciativa Oasis (los mismos que especificaron el estándar OpenDocument usado por OpenOffice).

La verdad es que aún no he tenido ocasión de idear la arquitectura de una solución web que permitiese el registro de usuarios (sí he tenido que mantener muchas ya desarrolladas en el pasado, y también he utilizado autenticación de usuarios en web, pero a modo de BackOffice), pero si lo hago a partir de ahora, utilizaré Liberty (Liberty Alliance), ya que es el Identity Provider por excelencia que actualmente implementa estas tecnologías.

Aprovechando mi hambre de conferencias/charlas, y aprovechando también, válgame la redundancia, que la Fundación Mozilla ha decidido financiarme el viaje a Bruselas, al igual que a (casi) todos los colaboradores/localizadores europeos, me pasaré por el FOSDEM este fin de semana. Promete ser super-interesante, sobre todo porque tendré la oportunidad de refrescar mi inglés, porque estaré de nuevo con la gente de NAVE, y porque seguro conoceré otra gente muy interesante (de Mozilla/Mozilla-Europe, de Gnome, de Softcatalá... ¡incluso de Mono!, pues me he enterado por Monologue que el creador de Beagle va a estar allí).

Actualización sobre Single-Sign-On [30-AGO-2006]: Parece que Sun ha publicado un framework basado en esta tecnología, llamado OpenSSO, bajo una licencia semi-libre.

Labels: General, Mozilla, Programacion, Seguridad, WebDev

Llevaba un tiempo pensando en usar WINE para ejecutar Internet Explorer en mi sistema operativo Linux. Ya sé que suena aberrante, pero en ocasiones a para los desarrollos web resulta absolutamente necesario comprobar que las aplicaciones funcionen en el navegador mayoritario (que no mejor) para asegurarse la compatibilidad cross-browser (algo que hipotéticamente no debiera ser necesario gracias a los estándares definidos por la W3C, los cuales no son seguidos en este caso por este programa de Microsoft).

El caso es que empecé a leerme tutoriales de cómo usar WINE hace tiempo, pero la pereza de usar herramientas cercanas a software propietario unido a la relativa dificultad que estaba encontrando para usar WINE, hicieron que no acabara de implementarlo nunca.

Pero últimamente en mi trabajo he empezado a usar mucho programas de virtualización como VMWare, y entonces me picó la curiosidad de usar Qemu, el equivalente a VMWare en software libre. De esta manera podría, no sólo usar Internet Explorer en Linux, sino también usar el sistema operativo completo de Microsoft, con cualquier herramienta que necesitase probar, todo emulado desde SUSE.

Así pues, voy a mostrar los pasos básicos para usarlo y los pequeños problemas que me he encontrado, haciendo un resumen lo más reducido posible.

• Problema: Según la lista de compatibilidad de la web de Qemu, Windows XP, que es el S.O. que me interesaba ejecutar, sólo puede ser usado desde la versión 0.8 de Qemu, cuando en mi SUSE 10.0 tenía una versión anterior. Solución: Me bajé el paquete de Qemu 0.8 de la versión beta de SUSE 10.1 (de uno de sus mirrors) y todo funcionando sin problemas.


• Problema: Intenté convertir una imagen de WindowsXP que ya tenía funcionando con VMWare, al formato de Qemu (qcows), y parece que la conversión funcionó satisfactoriamente aunque luego al intentar ejecutarla no funcionó. Solución: Creé una imagen nueva de 10GB e instalé en ella Windows XP SP2 desde cero. Sin problemas.


• Creación de una imagen:
  qemu-img create -f qcow WinXPSP2-10GB.qcow.img 10G


• Instalación de la imagen:
  qemu -cdrom WindowsXPSP2.iso -boot d WinXPSP2-10GB.qcow.img


• Uso de la imagen:
  qemu WinXPSP2-10GB.qcow.img

Actualización 07-FEB-2007: Parece que comienza a haber competición seria en este mercado porque empiezan a liberar programas a diestro y siniestro, tal como VirtualBox y KQemu. Nos depara buen futuro esto.

Y para terminar la actualización de la entrada, lanzo una pregunta en plan LazyWeb: ¿existirá algún sistema de virtualización que me permita correr un SO WinXP en mi OpenSUSE con la particularidad de que el sistema operativo de MS sea uno ya instalado en el mismo disco duro pero bajo otra partición? Es que veo tremendamente necesaria esta funcionalidad.

Labels: General, Miscelanea, Programacion, WebDev

Tras unas semanas después de abrir el proyecto AMUSE en Berlios, me he animamdo a subir al repositorio de Subversion (SVN) la primera versión.

También me he animado a desarrollar un poco más en detalle lo que significa y pretende este pequeño proyecto:

Inspirado en todos los inconvenientes que le he encontrado al lenguaje JavaScript para el desarrollo web en el cliente, he creado este proyecto GPL, destinado a hacer más llevadero el desarrollo con este lenguaje.

Las siglas AMUSE significan: Ajax-based Modular Unobstrusive System for Ecmascript. Lo que se puede deducir de esto es que AMUSE es una especie de framework hecho en y para javascript (ecmascript) con el objetivo de construir un modelo consistente de desarrollo de paquetes javascript, en el que se persigue la modularización de código y separación en capas, el uso de eventos no intrusivos, y un sistema de dependencias entre paquetes.

Según mi visión (la cual está aplicada en el framework), los paquetes los dividiremos en dos tipos: librerías y módulos. Los primeros, las librerías, básicamente proporcionarán una nueva API, una serie de funciones y/o objetos de los que podrá hacer uso el programador de JavaScript. Las librerías podrán depender de otras librerías, sobre las que apoyarse para implementar su propia API, pero nunca de módulos. Los módulos podrán definir funciones y/o objetos, y podrán depender de librerías, y al invocarlos podrán incorporar funcionalidades y procesos al documento web en el que se adjuntan (al contrario que las librerías, que sólo aportan una interfaz, en lugar de automáticamente añadir funcionalidad).

Es difícil que se me entienda si no pongo un ejemplo: Veamos, normalmente los paquetes JavaScript que se pueden encontrar en internet y que son de libre uso, para utilizarlos debemos referenciarlos con una etiqueta <script> en nuestra web, y luego normalmente adjuntamos invocaciones a sus funciones en los eventos de nuestros controles web. Por ejemplo, imaginemos que tenemos un sistema para crear enlaces "mailto" para evitar el spam. Normalmente haríamos algo así:

<a onclick="envia_mail('pepito','gmail.com');">pepito arroba gmail punto com</a>

Sin embargo, si desarrollamos un módulo teniendo en mente el sistema modular de AMUSE y el estilo de código que con éste se propugna, podríamos hacer lo siguiente:

<span class="email">pepito<img href="arroba.gif" alt="@" />gmail.com</span>

Luego, en el <head> de la página, referenciaríamos a dos ficheros javascript externos:

<script src="mi_ruta/amuse.js"></script>
<script src="js/mi_pag.js"></script>

El fichero "amuse.js" es el que implementa el interfaz de AMUSE. En el fichero mi_pag.js podríamos introducir lo siguiente:

RequireOnce("EmailAntiSpam.js");

De esta manera estaríamos llamando al módulo EmailAntiSpam, el cual, si miramos en su implementación interna haría cosas como:

//apoyarse en una librería de JavaScript agnóstico
RequireOnce("CrossBrowser.js");

function AddLinksToEmailSpans() {
//esta función buscaría todos los nodos 'span' que tuvieran
//la palabra "email" en su clase y les adjuntaría un nuevo
//comportamiento para su evento onclick, de manera que
//el visitante pudiera obtener un enlace "mailto:" generado
//automáticamente con código en el lado del cliente, con
//lo que evitamos el SPAM generado por los robots de búsqueda
//de direcciones de email
}

//adjuntar la función de conversión de nodos span al 'onload'
//de la página
CrossBrowser.AttachEventListener(window, "load", AddLinksToEmailSpans);


De esta manera, el usuario de nuestro nuevo módulo, denominado "EmailAntiSpam", sólo tendría que hacer una llamada RequireOnce a nuestro módulo, adjudicar la clase correspondiente a sus nodos span y olvidarse de escribir más código javascript.

Además, evitamos el tener que escribir etiquetas <script> por cada funcionalidad que queramos añadir. De esta manera, el propio código JavaScript puede llamar a otros ficheros javascript externos. Si nos fijamos también, los módulos deben adjudicar eventos a elementos de manera no intrusiva, es decir, que los comportamientos se añaden desde el propio código javascript, en lugar de tener que escribir invocaciones y eventos en el marcado HTML/XHTML.

Este módulo EmailAntiSpam en realidad aún no está implementado, pero cualquiera puede hacerlo con un poco de tiempo. Con AMUSE también distribuyo librerías y módulos de ejemplo, entre las cuales se unirá nuestro módulo EmailAntiSpam en cuanto lo tenga desarrollado (o bien si lo desarrolla antes un voluntario, pues todo esto es software GPL).

Voy a poner una pequeña descripción de estos añadidos que aporto con AMUSE:

Librerías:

• ArraysAdvanced.js (proporciona nuevos métodos útiles para el tipo de objeto array de javascript).
• CrossBrowser.js (proporciona un conjunto de API común para el acceso a ciertas características del DOM las cuales están implementadas en Internet Explorer de un modo distinto).
• CssHandling.js (proporciona funciones útiles para el tratamiento de CSS desde JavaScript).
• Debug.js (proporciona un sistema común para la muestra de mensajes a la hora de depurar JavaScript).
• FormValidation.js (proporciona un sistema de validación de formularios el cual está aún un poco en pañales y podría suponer otro proyecto GPL distinto por la cantidad de ideas que se me ocurren para ampliarlo).
• FunctionForEvent.js (proporciona un pequeño conjunto de funciones para adjudicar una función a múltiples eventos similares de un control, por ejemplo: onchange, onkeyup, keydown, keypress).

Módulos:

• AccessiblePopups.js (proporciona un sistema cómodo, accesible y no intrusivo para convertir nuestros enlaces en popups; también tiene una funcionalidad útil para hacer popups modales "crossbrowser").
• DisableAtSubmit.js (proporciona un comportamiento a los formularios de nuestra web que consiste en desactivar todos los botones una vez se haya activado el evento "submit", de manera que evitemos posibles errores de duplicación de datos o sobrecarga del servidor).
• IntroEnhancements.js (proporciona funcionalidades que tienen que ver con la pulsación de la tecla ENTER en los formularios, por ejemplo, un modo multinavegador de desactivar esta tecla, o bien que al pulsarla se consiga tener un efecto similar al haber pulsado la tecla tabulador para desviar el foco al siguiente control).
• OnlyScriptElements.js (podremos conseguir tener una funcionalidad inversa a la proporcionada por la etiqueta <noscript>).
• PreContent.js (nos permitirá mostrar un DIV transicional, al que normalmente se le pone el texto de "Cargando" y una animación, que se mostrará cuando el evento load de la página aún no haya llegado, o cuando se submita un formulario, se pinche en un enlace, o se pulse Adelante o Atrás en el navegador).
• PrintLink.js (nos permite crear enlaces que, al pulsarlos, mostrarán la interfaz de impresión del navegador del visitante).

Como véis, algunos son muy sencillos y tontos, pero otros yo creo que muy útiles. Sobre todo el módulo PreContent.js que en mi opinión es de obligado uso si queremos resolver el problema de usar JavaScript no intrusivo (es decir, que los controles de nuestra página adquieran sus comportamientos sólo cuando la página se cargue por completo) cuando la velocidad de conexión de nuestro visitante es algo lenta y existe el peligro de que use un formulario antes de que haya llegado la página entera.

KNOWN ISSUES:

• El módulo IntroEnhancements no desactiva bien el botón ENTER ni desplaza el foco a modo de tabulador si se usa la versión 1.5 de Firefox (sí funciona para la 1.0.x).
• El módulo PreContent no es compatible con el script IE7 de Dean Edwards (este problema de compatibilidad problablemente sólo aparecerá cuándo haya controles de formulario en la página).
• El sistema de dependencias de AMUSE se basa en llamadas XMLHttpRequest para obtener el contenido de los módulos. Actualmente estas llamadas se utilizan de modo síncrono, pero estoy en fase de estudio de desarrollo del modo asíncrono activable de manera opcional (por tanto, AMUSE aún no hace honor completo a su nombre aún pues usa "SJAX" en lugar de AJAX ;)

TO-DO:

• Arreglar las "Known Issues".
• Crear módulo EmailAntiSpam.js.
• Crear módulo FrameAway.js, que detecte si la web actual está englobada en un frame, en cuyo caso cambiará la URL de la barra de direcciones para mostrar sólo el frame interior, para evitar suplantaciones de webs, mediante el siguiente código:
  if( window.top != window ) window.top.location = window.location;
• Integrar la función CssQuery() de Dean Edwards en mi módulo CssHandling.js.
• Crear un módulo "Marquee.js" que se encargue de emular la obsoleta y propietaria etiqueta <marquee> usando métodos JavaScript no intrusivos y funciones del nivel 2 DOM. Un pequeño ejemplo por donde podría empezar.
• Integrar "the IE Factor" en CrossBrowser.

Labels: General, Mozilla, Programacion, WebDev

Puesto que ya he recibido mi primer mensaje de SPAM en la bitácora (el cual he borrado ya), me he decidido a activar la verificación de "palabra" en la introducción de comentarios. Esta bitácora no es leída por casi nadie, y casi nadie escribe comentarios, y si alguien lo hiciera seguramente tendría que tener un nivel técnico medianamente elevado para hacerlo; por lo tanto, no considero que esta verificación suponga barrera alguna. Quien más y quien menos que tenga cierta experiencia en la red, sabe lo que significa una verificación de este tipo, en qué consiste y el motivo de su existencia.

Actualización: ¡Pues vaya! Me considero a mí mismo un desarrollador web preocupado por términos como accesibilidad (a11y), y sin embargo no me había dado cuenta de que esta práctica de validación hace inaccesibles a los navegadores que no muestren imágenes, como bien indican en un artículo de uno de los blogs de Monologue. Habrá que ir pensando en soluciones mejores...

Actualización 24-MAY-2007: Cojonudo este nuevo sistema para combatir el spam, basado en el reconocimiento de dos palabras, una para verificar que eres humano y otra para ayudar en la digitalización de libros.

También hay otra técnica interesante y no intrusiva, pero que no da retorno de la inversión a la digitalización de libros :)

Actualización 17-JUL-2007: ¡Hablando de SPAM! Nunca en mi vida había recibido uno tan original como el de hoy:

Hello!!!

How are you doing? My name is Vera. I am 26 years old. Live in
Russia, city Zelenodolsk. I am cheerful woman, and like to do many things
as sport, camping, go to the cinema, theatre etc. In a word I like to do
all what like all people. I work in shop.
My dream this travel abroad. I know the english language well enough.
I began to study english language approximately one year ago.
I wish tell to you history which have pushed me write to
you. 7 months ago I have got acquainted with the man from other country by
name Alfonso. During this time we had good relations. We have understood
that our relations become serious and we have decided to meet in his country.
I wrote the application for reception the visa.
I waited reception of the visa approximately half of year. All time I kept in
touch with Alfonso through the internet and often called to each other. I
and Alfonso waited reception of the visa to our meeting. I have received
the invitation from the ambassador for reception of the visa.
My director has given me long-term holiday from work and I have gone to
Moscow to receive the visa. I informed good news to Alfonso, but he has
answered, that does not want our meeting.
He played with me. He has informed that has the wife with
two children and at all has no plans to meet me. I was not ready to such
turn of events. I could not think what even after one year of
acquaintance he can so unscrupulously act with me. Now I am in Moscow
trip to Moscow and reception of visa. I do not want that all was gone
for nothing and will be glad if my visa will be useful to our meeting.
I could arrive already through 4-5 days, but a problem in that that
now I have no man which would like my arrival. Probable it will silly
sound but if you will be interested in a meeting with the good woman I
shall like to meet you sometime soon! As Alfonso was dishonest with me I
have decided to find the man which is interested to meet the woman from
Russia. I do not know your ideas about my letter, but it would be fine
if we could meet and have some weeks or months together. On my trip I want to
receive rest from my work and a life in Russia. Also the basic purpose
for the future it is search good men for serious attitudes which go to a
marriage. I have no children, but I want to have children in the future.
I am the mature woman and ready to creation of family with good man. I
do not know what you really search in the future but if we could meet I
shall be happy to discuss with you more about our meeting. What are you
going to do this time? It would be fine if we could meet, do
friendship or more than simply friendship. I shall be happy if you also
have a free time and we could meet soon. I do not know your interests,
but anyhow write to me back and I shall tell to you more about myself.
Write to me all that you want. Maybe we have similar plans and it will
be interesting to us together.

You can write all that you want. Ask any questions which interest you.
Write to me back and I shall tell more about myself and send more my
photos.
Write me please on my regular e-mail xxxxxx@xxx.xxx
Have a good day, Vera

¿O acaso esto se llama SCAM tal como reza esta web?

Actualización 29-JUL-2007: Otra interesante iniciativa para reaprovechar la inteligencia humana:


Enlace al vídeo

Labels: General, WebDev

Es extraño que a una persona que le guste .NET le atraiga también el software libre, y viceversa. Es lo que les ocurre a las que personas que vemos futuro en Mono. Pero, si además le sumas a esto que, a una persona como yo, no le termina de gustar ASP.NET (la cual es la tecnología por excelencia dentro de .NET para desarrollar aplicaciones web), pues para de contar.

Y es que a ASP.NET le veo inconvenientes técnicos que no se pueden solventar de un día para otro, pues son problemas que influyen de raíz en la concepción de esta tecnología. Ésta aporta un modo de desarrollo por el cual le permite a un desarrollador olvidarse un poco de los intríngulis de la especificación HTML. Se basa en una serie de componentes a los cuales el desarrollador les adjudica características y comportamientos a sus eventos, de manera que parezca que se está desarrollando una aplicación de escritorio, pues luego cada control genera su salida HTML+CSS+JavaScript a la hora de enviarse del servidor web al cliente. Esto hace que tengamos poco control sobre las tecnologías que hay por encima de HTML, las cuales, en mi opinión, son de obligado conocimiento para cualquier desarrollador web.

Es más, no sólo oculta estas capas al programador sino que además le provoca malos hábitos. Da bastante grima ver cómo la mayoría de ejemplos existentes en páginas de documentación sobre ASP.NET (como MSDN) no separan el estilo del contenido, usando directivas de presentación (CSS) en los atributos de un control ASP.NET. Si actuamos así, luego será mucho más complicado, por poner un ejemplo, hacer que la aplicación web tenga estilos intercambiables (de manera que con cambiar los ficheros CSS se tenga un aspecto absolutamente distinto y la aplicación siga funcionando correctamente). Por el contrario, podemos usar CSS en los controles ya que podemos adjudicarles el valor de la propiedad "class" con el atributo "CssClass", pero esto en realidad no acaba de encajar bien con este modelo de desarrollo pues, al final, los especialistas en CSS, no sólo necesitarán los nombres de las clases, sino también los nombres de las etiquetas HTML usadas: algo que, en principio, está oculto debido al modelo de desarrollo intrínseco de ASP.NET.

¿Y cuál es el inconveniente de que los controles ASP.NET generen un código HTML que en principio el desarrollador no tiene por qué conocer? Pues que el desarrollador desconoce la calidad de este código generado. No sabe si tendrá JavaScript con errores, si el código cumplirá a rajatabla la especificación HTML, o incluso si cumplirá unas normas básicas de accesibilidad. Un buen ejemplo de ello es el control DataGrid de ASP.NET, que en sus primeras versiones renderizaba las cabeceras de una tabla como elementos de celda TD en lugar de TH, lo que es fundamental para aplicar un control de estilo CSS decente. Según la guía de "Cómo conseguir que un sitio web de ASP.NET sea accesible", ya existe un parche para este inconveniente, pero yo no lo he encontrado en ningún Service Pack ni he encontrado la versión en español de este mínimo HotFix.

Otro de los problemas que veo en ASP.NET tiene que ver con la extracción de datos desde la capa de presentación al modelo de datos. Si se desea un tratamiento avanzado de un dato extraído de una iteración de un componente asignado con el DataBind, deberemos utilizar funciones y código del back-end en las páginas ASPX (usando el método Eval del DataBinder), es decir, que estaremos mezclando lógica con presentación.

Es más, ASP.NET no tiene compatibilidad con XHTML y, lo que es peor, presupone el funcionamiento de JavaScript en la parte del cliente. Un usuario que tenga un navegador sin JavaScript o con JavaScript desactivado no podrá utilizar una aplicación web ASP.NET que tenga una cierta complejidad.

Aunque, todo sea dicho, y es que al parecer la versión 2.0 de ASP.NET (que viene con Visual Studio 2005), la cual aún no he tenido la oportunidad de probar, va a respetar mucho los estándares de la W3C. Sin embargo, en mi opinión, podrán arreglar pequeños problemas o pulir muy bien esta tecnología, pero al final, el concepto inicial en el que se basa, será siempre erróneo.

Un desarrollador web debe conocer bien las especificaciones XHTML, debe desenvolverse bien con JavaScript y usar CSS siempre, no de modo opcional. Por eso yo creo que el mejor modo de utilizar separación de capas de abstracción sin perder el control de la salida XHTML, es utilizar tecnologías propias de XML para la transformación de datos: XSLT. Si quieres más detalles sobre mi modelo de desarrollo web no dudes en leer mi artículo Evolución de mi arquitectura de desarrollo web (desde ASP hasta Mono, pasando por PHP y Java).

Actualización 04-NOV-2007: Hoy al visitar la Wikipedia me he encontrado con cosas que reafirman las quejas que expongo en este artículo. Cito:

ASP.NET 2.0 produces markup that passes W3C validation, but it is debatable as to whether this increases accessibility; one of the benefits of a semantic XHTML page + CSS representation. Several controls, such as the Login controls and the Wizard control, use HTML tables for layout by default. Microsoft has now gone some way to solve this problem by releasing the ASP.NET 2.0 CSS Control Adapters, a free add-on that produces compliant accessible XHTML+CSS markup. However, some controls still rely on JavaScript.

Labels: CSharp, General, Mono, Programacion, WebDev

Acabo de publicar mi nuevo proyecto GPL, que tiene el nombre de AMUSE: Ajax-based Module Unobstrusive System for EcmaScript.

Es un sistema de librerías y módulos que permite modularizar más fácilmente las funcionalidades que se desarrollan en las aplicaciones web. Ya de paso aprovecho para probar Berlios (ya tenía experiencia con SourceForge.net), que dispone de servicio de Subversion (SVN) además de CVS.

Dejaré aquí la descripción, en inglés, que puse al dar de alta el proyecto (daré más detalles cuando introduzca el código en el repositorio):

My project consists of one javascript file that will provide a consistent way of making javascript (ecmascript) features unobstrusively. This will make easy the task of deciding to include or not include features in web applications, instead of doing it the old way (adding <script> tags, initializating variables, etc.).

Refer to this URL for the meaning and tutorials of the term "Unobstrusive Javascript":

http://www.onlinetools.org/articles/unobtrusivejavascript/index.html

The features provided by ecmascript code will be available through two types of files: library files and module files. Library files will provide some API (functions, constants, variables) to use in other libraries/modules. However, modules will be able to access the current webpage to modify its behaviour, using external libraries and/or resources, such as CSS or XML files.

I have developed some example libraries and modules that I would like also to host on this project page, as an example. I will license them with the same license as the project (GPL). The names of some of them are:

Libraries: ArraysAdvanced.js, CrossBrowser.js, CssHandling.js, Debug.js, FormValidation.js, FunctionForEvent.js, ...

Modules: AccessiblePopups.js, DisableAtSubmit.js, IntroEnhancements.js, OnlyScriptElements.js, PreContent.js, PrintLink.js, ...

The system also comes with the feature of automatic detection of redundant dependencies, which will provide a similar function in javascript than the PHP function "require_once".

Labels: General, Programacion, WebDev

Lo primero que utilicé fue ASP a secas. En cuanto el proyecto crecía, era muy difícil su mantenibilidad, por problemas derivados de su rapidez y potencia del lenguaje (VB Script).

Más tarde, reescribí el proyecto ASP anterior en PHP, esperando que con software libre obtuviera resultados mejores. Y lo fueron: PHP, además de ser libre, era más potente, disponía de más herramientas para facilitar el trabajo, más funcionalidades, etc.

Sin embargo, a medida que se va profundizando en PHP y los proyectos PHP van creciendo, se empiezan a ver herramientas para PHP que permiten tener más estructuradas las cosas: sistemas de plantillas como Smarty, frameworks MVC (Modelo Vista Controlador), e incluso la propia actualización de PHP4 a PHP5. Hasta que te das cuenta de que PHP, y todo su plataforma de desarrollo conjunta formada por estas herramientas, tiende a parecerse a cosas más robustas y estructuradas como las que existen para el mundo Java.

También he tocado Java con aplicaciones web, un poquito de JSP's y demás, pero no demasiado. Porque la verdad, yo también soy un poco reticente a Java, por el hecho de que no es software libre (quiero decir, que las máquinas virtuales de Java hechas por Sun, son de código abierto pero aún así no tienen licencia libre; y las máquinas virtuales de terceros que sí lo son aún están algo verdes).

Por eso, como veía que mi tendencia era llegar a Java sin usar Java, eché un vistazo a .NET. La plataforma .NET sin duda ofrece mucha productividad y el lenguaje C# se puede codear perfectamente con Java (incluso es mejor en algunas cosas EMNTHO, pero esto ya es discutible). Sin embargo, lo que echaba de menos con .NET eran dos cosas:

a) Una plataforma de desarrollo multiplataforma.
b) La tendencia "inherente" a los proyectos y plataformas de desarrollo del mundo Java de estructurar completamente y de forma exquisita el código, obteniendo capas de abstracción de la más mínima cosa (pero sin llegar al concepto del "over-engineering").

El punto (b) viene fundado, sobre todo, por la tecnología ASP.NET con la que irremediablamente he tenido que tratar a la ahora de utilizar la plataforma .NET. La versión 1.1 para empezar tiene importantes fallos concernientes a la arquitectura, como que resulta difícil hacer páginas web que validen con los estándares, y sobre todo, páginas web accesibles, en las que el JavaScript sea solamente una opción. Ofrece una capa de abstracción que hace que el programador se olvide de todo, y que incluso no necesite saber ni CSS ni JavaScript. Esto es en mi opinión un error. Además, desde el punto de vista del backend de una aplicación web, con ASP.NET es más difícil elaborar una estructura MVC (al parecer, Microsoft se enorgullece de hacer desaparecer, por arte de magia, la capa del Controlador). [Más información sobre esto en mi otro artículo "Inconvenientes de ASP.NET".]

Sin embargo, en el mundo Java, un ejemplo del punto (b) puede ser el proyecto Maverick, que ofrece un framework MVC para desarrollar aplicaciones web. Algo bastante elegante.

¿Qué decisión tomé entonces? Una intermedia: olvidarme definitivamente de PHP, no usar Java (J2EE), pero tampoco ASP.NET, ni nada que tenga que ver con Microsoft.

Actualmente estoy utilizando un framework MVC denominado "Maverick.NET", el cual es un port de Maverick de Java a C#, y me está dando unos resultados muy buenos. De esta manera solucionaba el punto (b) de mi lista de inconvenientes, pues es posible no utilizar ASP.NET con este Framework.

Para desarrollar utilizo MonoDevelop, y para los deployments utilizo el runtime de Mono, Apache 2.0 y el módulo mod_mono que permite reenviar las peticiones al servidor XSP de Mono. De esta manera solucionaba el punto (a) de mi lista de inconvenientes anterior.

Para la vista estoy utilizando serialización XML de las clases del controlador de manera que su resultado es transformado en XHTML mediante XSLT. Para la vista también utilizo CSS2/CSS3 (usando IE7/FixIE/IEpatch) y JavaScript no intrusivo (Unobstrusive JavaScript), al igual que JavaScript agnósitco ("crossbrowser") para la captura e implementación de eventos, y demás cosas, e incluso un poquito de AJAX...

Para el controlador uso lenguaje C# compilado en una librería .DLL. No necesito a Microsoft para nada porque he conseguido hacer funcionar Maverick.NET con Mono.

Y para el modelo, me había planteado utilizar algún sistema de mapeado objeto-relacional, como NHibernate, pero me estoy dando cuenta de que al final lo más eficiente, y EMO lo que es el futuro, son las bases de datos ya de por sí orientadas a objetos como DB4O (¡y te olvidas del SQL!).

Agradecería, pues, cualquier sugerencia/comentario/crítica, para mejorar la arquitectura y forma de desarrollar que he escogido por el momento ;)

Moraleja: EMO se pueden desarrollar aplicaciones web usando soluciones distintas a LAMP/J2EE/.NET, que a la vez cojan "lo mejor de los tres mundos": la libertad de licencia que proporcionan cada uno de los componentes del sistema LAMP (porque Mono también es libre), la estructuración y elegancia del mundo Java, y el novedoso lenguaje manejado/administrado y altamente tipado, propuesto por Microsoft como estándar ECMA: C#; y sin dejar de lado otras tecnologías complementarias que dan mucho que hablar últimamente, como AJAX en el lado del cliente y librerías de tratamiento de datos XML (transformaciones XSLT, serialización XML, ...) en el lado del servidor. Incluso he pensado en modificar las fuentes de Maverick.NET para dar la posibilidad a la capa del controlador de comunicarse con el modelo usando servicios web XML.

Saludos.

Reproducido de un comentario en BarraPunto que dejé al hilo de la noticia "El sistema LAMP pierde cuota de mercado".

Labels: General, Mono, Programacion, WebDev

Creo sinceramente que muchos desarrolladores web de habla hispana se beneficiarían infinitamente al usar las librerías javascript de Dean Edwards, un proyecto denominado, precisamente, IE7. Por eso hago mi segundo intento de publicar información en BarraPunto.

Debe ser que los editores están algo empeñados en que cualquier cosa que tenga que ver con IE7 es malo (opinión que respeto y comparto) pero la vez anterior no deben haber entendido bien de lo que hablaba, o sino no entiendo por qué se rechazaría...

Labels: General, Programacion, WebDev

A pesar de que el lenguaje JavaScript ya se viene llamando oficialmente ECMAScript, el nombre antiguo es mucho más fácil de reconocer.

Aunque soy un programador al que le atraen mucho más las aplicaciones de escritorio y los lenguajes de servidor (especialmente los estáticamente tipados como C#), no puedo evitar entrometerme en temas sobre XHTML+CSS+JavaScript, máxime cuando mi trabajo lo requiere. Y de hecho, por esta razón, creo que me estoy convirtiendo en un pseudo-experto en la materia, modestias aparte :)

El caso es que en ocasiones uno empieza a profundizar mucho en un tema y se da cuenta de cómo optimizar una manera de programar, para hacerla más mantenible y robusta. Es entonces cuando entran ganas de escribir un artículo sobre ello. Pero antes de nada, intentas que no quede ningún agujero por tapar, y a mí sí que me quedaba alguno.

La cuestión es la forma de programar con javascript de manera no intrusiva, es decir, sin mezclar código XHTML con llamadas o instrucciones javascript (en eventos de tipo onclick, onchange, etc.).

El tema está en que yo conocía sólo *UN* argumento en contra de utilizar javascript no intrusivo, contra el cual tenía una solución, pero aún sin llevar a la práctica, así que me decidí a escribir en los grupos de noticias de javascript planteando la duda, antes de escribir un posible artículo. El resultado fue éste: Attaching functions to events, from external JS files.

Y no me puedo quejar, pues las respuestas me han ayudado bastante. Una de ellas me apuntó hacia un artículo sobre Unobtrusive JavaScript, lo cual puede ser una réplica sobre lo que yo exactamente quería hablar. Otra persona sin embargo se mostró totalmente contraria al uso de esta técnica, precisamente por el inconveniente que mostraba yo en mi comentario, del que escribía como sin tener absolutamente ninguna solución.

Aunque se puede leer detalladamente sobre el problema en el enlace que ya he proporcionado, haré un resumen: cuando se utiliza javascript no intrusivo, los comportamientos de los controles son adjudicados cuando se dispara el evento onload de la página, lo que puede traer problemas cuando el cliente (o el servidor) dispone de una conexión lenta o la página es muy grande.

La solución que había pensado yo (que no es perfecta) es utilizar un DIV transicional con el típico texto de "CARGANDO...", que desaparecería al cargar la página. Desgraciadamente aún no tengo la prueba de concepto, pero estoy en ello.

Más información en enlaces derivados del artículo anteriormente mencionado: Call of the wild (scripts) y Blog sobre Unobtrusive Javascript.

Actualización: La prueba de concepto ya está lista. Bueno, en realidad, lo que he preparado ha sido un módulo denominado PreContent, que se integra dentro de mi framework JavaScript AMUSE cuyo código he subido hace poco.

Labels: General, Programacion, WebDev

Éste es mi segundo AntiFUD, quizás debería crear una sección con este nombre :D

El caso es que también me suele enfadar mucho los hilos de BarraPunto que se dedican a desprestigiar a la plataforma de desarrollo de Mono, por la única razón de que con ésta se intenta reutilizar/adaptar/imitar un lenguaje, un entorno de desarrollo y unas API's de Microsoft (pero que, deliberadamente, ha publicado sin peligro de patentes, aunque esto podría suponer otra discusión...) de un modo multiplataforma.

Además, puesto que es mi plataforma de desarrollo preferida, me apetece defenderla. Y voy a hacerlo objetivamente: comentando aspectos técnicos sobre ésta y comparándola con otras plataformas de desarrollo (al final, con la que queda más reñida es con Java, pero en resumen yo creo que ésta queda derrotada).

[Este "artículo" fue inicialmente publicado en la lista de correo de NAVE, al hilo de una conversación sobre plataformas de desarrollo y la deliberación sobre la creación de un posible "Mozilla Translator II". Al cabo de los pocos días, salió una noticia en BarraPunto sobre .NET, y decidí copiar estas reflexiones en un comentario (como véis, lo hice como anónimo, lo que a veces permite hablar como si estuvieras convencido de que llevas la razón... jejeje, aunque reconozco que seguro que hay cosas en las que me he colado :) ]

EMHO, la mejor forma de programar hoy en día es en C# con Mono, por las siguientes razones:

1. Completamente multiplataforma (si no sacas los pies del tiesto). [Esto lo tiene Java, PHP, Perl, Python, pero no siempre C++ (en ciertas circunstancias...)]

2. Muchas interfaces gráficas multiplataforma a elegir (Web, GTK#, QT#, wx.NET, e incluso SWF a partir de la versión 1.2 de Mono; aunque EMO esto no debe suponer el plantearse a hacer proyectos desde el principio con esta última librería, sino sólo como arreglo para portar aplicaciones ya hechas).

3. Es un lenguaje estáticamente tipado (su compilador tiene análisis semántico). Esta característica suele resultar muy reñida y levanta polémica entre los programadores. Mi opinión personal es que es mejor pues evita que ciertos errores se descubran en etapas posteriores del desarrollo, sin sacrificar demasiado la complejidad del lenguaje, y ofreciendo aún así una buena flexibilidad como ofrecen los dinámicamente tipados (a esto se suma que la "estaticidad" del lenguaje ofrece mejor rendimiento). [Esto lo tiene Java y C++, pero no lo tiene ni Perl, ni Python, ni PHP]

4. Es un lenguaje pseudo-interpretado (que no interpretado, como Perl y PHP, aunque tengo entendido que para estos se pueden generar ejecutables específicos para cada procesador). Eso significa que tiene la ventaja de independizarse de la arquitectura, sin sacrificar la etapa de compilación. Es decir, que lo que se encontrará el framework de Mono siempre será código intermedio validado, que haya pasado el filtro de la compilación, lo que es más eficiente. [Esto lo tiene Java, pero no lo tiene ni Perl, ni Python, ni PHP, ni por supuesto C++.]

5. El modo de programación predeterminado es con "código seguro", es decir, sin aritmética de punteros. [Esto lo tiene Java, PHP y Perl (y creo que Python), pero no C++.]

6. Tiene tratamiento avanzado de excepciones nativo (try-catch-finally). [Esto lo tiene Java, C++, PHP5, pero no Perl (lo tiene no nativo).]

7. Soporte total del paradigma de la Orientación a Objetos. [Esto lo tiene Java y C++, PHP se queda corto, Perl no tiene distinción entre lo público y lo privado (dónde quedó eso del diseño por contrato o el principio de ocultación de la información o abstracción, concepto importantísimo de un TAD) y Python creo que también se queda corto.]

8. Es LIBRE. [¡¡Esto no lo tiene Java!! Y sí que lo tienen PHP, Perl, Python, C++ (depende).]

La idea general es que, como podréis comprobar, tengo en buena estima a Java y creo que su único inconveniente es que no es libre. Si además sumamos el hecho de que los programadores de .NET pueden migrar ahora a Linux con Mono, pues para de contar...

Y sí, sé que muchos de estos puntos podrían ser discutibles, en el sentido de que muchos preferirán el rendimiento de C++ sacrificando la productividad. Pero lo que yo creo es que C# (con Mono) coge lo mejor de los dos mundos en muchos puntos a discutir (la "eficiencia" frente a la productividad y a la capacidad multiplataforma).

No podía resistirme; sobre todo al oir lo de que es imposible usar C# sin MS: en mi opinión no es difícil. Yo creo que si usas C# en una aplicación de "propósito general" (sin usar llamadas a sistema, P/Invoke...) y no consigues hacerla multiplataforma, es que has sido un poco chapucilla...

Actualización: He encontrado un enlace de un documento en el que se compara Java con C#, en el cual veo lo más destacable su capítulo "Las 20 cosas que tiene C# y no tiene Java". EMO estos 20 puntos son mucho más importantes/interesantes que las otras 7 cosas que tiene Java y no tiene C# (que se quedan en 6 porque gracias a Mono tenemos la portabilidad).

Actualización 9-SEP-2006: Cada vez me doy más cuenta de que la mayoría de la gente detractora de Mono no expone argumentos técnicos, sino básicamente legales/filosóficos respecto del uso de un estándar ofrecido por Microsoft. En general podemos recopilar todos estos miedos en este artículo de Seth Nickell, el cual me parece un poco catrastrofista y totalmente rebatible, cosa que ya ha hecho un desarrollador de Mono en un mensaje en Slashdot (probablemente sea el mensaje más reconfortante que haya leído nunca sobre este tema :).

Actualización 19-SEP-2006: Y para los que siguen recurriendo al socorrido tema de la eficiencia del código nativo frente al código administrado, aquí va un mensaje de un desarrollador de Mono que habla sobre la compilación directa a código nativo y de cómo es impredecible saber si el resultado será más rápido o no. La desmitificación que sustenta se basa sobre todo en que, como los ensamblados de código administrado tienen menor tamaño, la computadora tarda menos en leerlos y eso hasta puede significar una ganancia en velocidad con respecto al código ya compilado en lenguaje máquina.

Actualización 02-OCT-2006: No tiene desperdicio este e-mail de Jonathan Pryor, un desarrollador de Mono, que habla sobre ventajas de C# frente a Java (en concreto sobre ciertas librerías de clases de .NET comparado con las de Java).

Actualización 03-DIC-2006: Parece que después de la liberación de Java, quedan menos argumentos en favor de Mono, jeje. No importa, aquí rescato una entrada de un blog en la que la gente echa pestes sobre cómo están implementados los tipos genéricos en Java, en comparación a cómo lo están en .NET.

Actualización 06-FEB-2007: Empiezan a surgir casos de prueba en los que se demuestra que aplicaciones hechas en código administrado (C#) pueden ser igual o más rápidas que otras hechas en C++. Esto no es más que consecuencia de que gracias al JIT que precompila a código nativo el código IL de nuestra aplicación al invocarla, tenemos un rendimiento similar en el funcionamiento normal del programa; es decir que casi se podría decir que el único handicap en velocidad lo tenemos en el momento del arranque de nuestro programa.

Actualización 18-MAY-2007: Añadida mención nueva a Perl como poco POO, nada amigable con las excepciones, y muy críptico. Tachado lo de que Java no es libre :D

Actualización 29-SEP-2007: Más diferencias entre Java y .NET: los genéricos son globalmente mejores en este último.

Actualización 01-FEB-2008: Aunque esta entrada se centraba en C# (sobre Mono), podría haber argumentado también que Mono puede soportar muchos lenguajes. Sin embargo, este argumento ya no sería válido contra Java porque están surgiendo más lenguajes que compilan al bytecode de Java: Groovy, JRuby, Jython y Scala. ¡Muy interesante!

Labels: CSharp, General, Mono, Programacion, SoftwareLibre, WebDev

Bueno, pues acaba de salir IE7 pero, para sorpresa del personal, IE7 no es "Micro$oft Internet Exploter 7". Es un programa fantástico, que va por su versión 0.8 alpha, hecho en JavaScript, que sólo ocupa 23KB y que transforma por completo el comportamiento de Internet Explorer 6 para que respete, un poquito más, los estándares. Sólo tendríamos que invocar el script y sus módulos en todas nuestras páginas, para no preocuparnos más de los problemas que tenemos los desarrolladores web para cumplir con los estándares y a la vez permitir la navegación con el peor navegador de la historia. Corrige renderizado de elementos y comportamientos de hojas de estilo, añade características de CSS2 que faltan, e incluso algunas del borrador de CSS3 (un estándar aun no oficial). Yo le pongo la nota de un 10.

La licencia es LGPL así que no hay problema para incluirlo en aplicaciones web cerradas (que es lo que más abunda actualmente). Lo que podríamos hacer los desarrolladores web para ayudar al desarrollo de este programa, es escoger entre alguna de las siguientes opciones:

• Hacer alguna donación al proyecto (actualmente el desarrollador no tiene "trabajo remunerado").


• Ayudar al desarrollo (aunque actualmente no sé en qué terminos aceptaría o actuaría el desarrollador frente a las aportaciones).


• Utilizarlo en todas nuestras webs. Cuando veamos que IE se comporta de manera diferente a Firefox (por ejemplo) aún a pesar de utilizar IE7, notificar del bug o sugerencia de implementación en SourceForge, ya sea en el foro de IE7 o en el gestor de incidencias de IE7.

Nota: He enviado esta historia a BarraPunto, pero la coloco en mi blog por si no saliera publicada.

Labels: General, Mozilla, Programacion, WebDev