Disclaimer: This is a personal web page. Contents written here do not represent the position of my employer.
Monday, December 19, 2005
El arquitecto de software
Al hilo de una conversación en BarraPunto sobre "Telecos e informáticos, los más solicitados", se discutió mucho sobre los colegios oficiales de ingenieros en informática, como siempre.
Uno de los comentarios que más puntos recibió consideraba comprensible que los ingenieros de nuestra especialidad abogasen por la implantación de colegios oficiales, siempre y cuando los ingenieros dejaran de "codificar" y se dedicasen a las tareas para las que realmente fueron concebidos y preparados.
Considero que este señor tiene parte de razón, aunque la línea que separaría un tipo de tareas de otras estaría bastante difuminada dado que la diferencia parece algo subjetiva. Sobre todo si tenemos en cuenta las típicas tareas que podría desempeñar un Arquitecto de software (y recordando que la aserción Architects Don't Code es un anti-patrón, es decir, algo totalmente incorrecto y a evitar). Algunas de estas tareas las mencioné en un comentario que puse de respuesta en BarraPunto pero las vuelvo a mencionar aquí:
Una de ellas, la número 3, la considero la más importante de todas y, paradójicamente, la que en general en la industria informática se tiene menos en cuenta. Hay que pensar que esta tarea no sólo sirve para cuidar la calidad de un desarrollo, también para evitar complejidades innecesarias, reutilizaciones de código no empleadas, y que ciertos personajillos se aseguren un trabajo de por vida a base de escribir código inmantenible.
Actualización 19-AGO-2007: Leyendo una entrada del blog de Ayende se me ha ocurrido otro elemento importante que hace un arquitecto de software: revisión arquitectural del sistema (pues la revisión no arquitectural de cada uno de los cambios de cada programador es una tarea demasiado larga como para que sólo la lleve a cabo una persona) para que el sistema no se convierta en The Blob (otro antipatrón). Ah, y Ayende también está de acuerdo en que Architects don't code es un antipatrón.
Actualización 27-SEP-2007: Veo que me siento totalmente identificado con las palabras de una acojonante entrada de Ted Neward, la cual voy a citar (énfasis añadido):
How could their idea of an architect be so far removed from someone like myself? I can't answer this one solidly, but I can say that the definition of an architect seems to be vague and indiscriminate a term, only exceeded in opacity by the term "software" itself. For some companies I've worked for, the "architect" was as you describe yourself, someone whose hands were dirty with code, acting as technical lead, developer, sometimes-project-manager, and always focused on customer/business value as well as technical details. At other places, the architect (or "architect team") was a group of developers who had to be promoted (usually due to longevity) with no clear promotion path available to them other than management. This "architect team" then lays down "corporate standards", usually based on "industry standards", with little to no feedback as to the applicability of their standards to the problems faced by the developers underneath them. A friend of mine on the NFJS tour, Brian Sletten, tells a story of how he consulted on a project, implementing the (powerful) 1060 Netkernel toolkit at the core of the system, to resounding success. Then, on deployment, the "architecture team" took a look, pronounced the system to be incompatible with their "official standards", and forced new development of a working product. In other words, the fact that it worked (and could easily be turned to interoperate with their SOAP-based standard, of which there were zero existing services) was in no way going to stand as an impediment to their enforcement of the corporate standard.
Is architecture supposed to be facilitative or restrictive? Ah, this is a harder one to answer. In essence, both. Now, before the crowd starts getting out their torches and pitchforks to have a good old-fashioned lynching, hear me out.
Architecture is intended to be facilitative, of course, in that a good architecture should enable developers to build applications quickly and easily, without having to spend significant amounts of time re-inventing similar infrastructure across multiple projects. A good architecture will also facilitate interoperability across applications, ensure a good code quality, ensure good maintainability, provide for future extensibility, and so on. All of this, I would argue, falls under the heading of "facilitation".
But an architecture is also intended to be restrictive, in that it should channel software developers in a direction that leads to all of these successes, and away from potential decisions that would lead to prolems later. In other words, as Microsoft's CLR architect Rico Mariani put it, a good architecture should enable developers to "fall into the pit of success", where if you just (to quote the proverbial surfer) "go with the flow", you make decisions that lead to all of those good qualities we just discussed.
This is asking a lot of an architecture, granted. But that's the ideal.
What relevance do architects have today? Well, this is a dangerous question, in that you're asking it of one who considers himself an architect and technologist, so take this with the usual grain of salt. Are we just overpaid out-of-touch developers? God, I hope not. Fowler talks about architecture being irrelevant in an agile project, but I disagree with that notion pretty fundamentally: an architect is the captain of the ship, making the decisions that cross multiple areas of concern (navigation, engineering, and so on), taking final responsibility for the overall health of the ship and its crew (project and its members), able to step into any station to perform those duties as the need arises (write code for any part of the project should they lose a member). He has to be familiar with the problem domain, the technology involved, and keep an eye out on new technologies that might make the project easier or answer new customers' feature requests.
And if anybody stands up at this point and says, "Hey, wait a minute, that's a pretty tall order for anybody to fill!", then you start to get an idea of why architects do, frequently, get paid more than developers do. Having to know the business, the technology at a high and low level of detail, keeping your hands in the code, and watching the horizon for new developments in industry, is a pretty good way to burn out any free time you might have thought you'd have.
Granted, all of these answers notwithstanding, there's a large number of "architects" out there whose principal goal is to simply remain employed. To do that, they cite "best practices" established by "industry experts" as a cover for making decisions of their own, because nobody ever gets fired for choosing what industry "best practices" dictate. That's partly why I hate that term: it's a cop-out. It's basically relying on articles on popular websites and magazines to do your thinking for you. Inevitably, when somebody at a conference says the word, "Best Practice", listeners' minds turn off, their pens turn on, and they dutifully enscribe this bit of knowledge into their projects at home, without considering the applicability to their project or corporate culture. Nothing, not a single technology, not a single development methodology, not even a single tool, is always the right answer.
Actualización 09-FEB-2008: Voy a citar dos fuentes más de información que expresan muy bien lo que es un arquitecto de software o la calidad del software que éste debe perseguir.
La primera es un párrafo del mítico libro The Mythical Man-Month, válgame la redundancia, citado en esta entrada de Scott Rosenberg:
The goal of "conceptual integrity" or unity of design: The best programs and software systems exhibit a sense of consistency and elegance, as if they are shaped by a single creative mind, even when they are in fact the product of many. The fiendish problem is less how to create that sense in the first place than in how to preserve it against all the other pressures that come to bear throughout the process of writing software.
Por último, dos párrafos sueltos de una entrada de Ayende Rahien titulada "Don't meake me THINK!", que habla sobre arquitectura y usabilidad:
A while ago I was asked what I think was a good quality for an architect. My reply was that he should set things up in such a way where the developers are bored.
That may sound... harsh to some, but I believe that we have enough complexity in our applications as it is. A success story is reducing the complexity to such a level that we focus on the business value, rather on the technical difficulties.
[...]
This means that we can spend all the time actually producing business value. It also means that I have a lot of junior people on my team that can immediately make use of very advance concepts and produce good, solid software.
Actualizacion 17-MAY-2008: Don't Let Architecture Astronauts Scare You es una interesante entrada de Joel Spolsky que desmitifica al perfil de arquitecto-soluciona-todo. No es que se meta con los arquitectos de software (aunque alguna frase sí me ha dolido, como Remember that the architecture people are solving problems that they think they can solve, not problems which are useful to solve), sino con el aire marketiniano que se le da algunas veces a cosas relacionadas con la arquitectura, pero que al final acaban resolviendo algo interno (no visible al usuario).
Y me ha dolido porque pienso que la arquitectura sí es algo util de resolver/perfeccionar, dependiendo del punto de vista claro. Y aquí voy a usar el símil que el mismo Joel ha utilizado: ?le interesa al cliente de un supermercado saber que los productos se llevan en camión desde el almacen? No. Pero, ?es por eso menos importante la eficiencia de los procesos internos para que el cliente pueda disfrutar de su producto finalmente? No.
Actualizacion 02-NOV-2008: Es triste como parece que España sigue igual en cuanto a la mentalidad de muchos informáticos. Cuando alguien te diga cosas como "¿Programando a los 50? No, por favor" o "A ver cuando me ascienden para dejar de programar", es que no es un auténtico ingeniero de software con vocación, y me apuesto a que no sabrá ni siquiera lo que es un arquitecto de software (un puesto de lo más relevante, y que precisamente suele ser la aspiración de los que quieren progresar en su carrera pero sin dejar de programar, puesto que es su pasión).
Uno de los comentarios que más puntos recibió consideraba comprensible que los ingenieros de nuestra especialidad abogasen por la implantación de colegios oficiales, siempre y cuando los ingenieros dejaran de "codificar" y se dedicasen a las tareas para las que realmente fueron concebidos y preparados.
Considero que este señor tiene parte de razón, aunque la línea que separaría un tipo de tareas de otras estaría bastante difuminada dado que la diferencia parece algo subjetiva. Sobre todo si tenemos en cuenta las típicas tareas que podría desempeñar un Arquitecto de software (y recordando que la aserción Architects Don't Code es un anti-patrón, es decir, algo totalmente incorrecto y a evitar). Algunas de estas tareas las mencioné en un comentario que puse de respuesta en BarraPunto pero las vuelvo a mencionar aquí:
- Estudio de nuevas herramientas, librerías, componentes.
- Elaboración de guías de estilo de codificación.
- Revisiones de las implementaciones/parches de los programadores.
- Implementaciones de partes globales de un sistema, que posteriormente serán utilizadas por los programadores (p.ej: creación y mantenimiento de una herramienta base, un "framework" del negocio).
- Formación a programadores.
- Generación de pruebas unitarias y de regresión, y planes/herramientas para la automatización de estas pruebas.
Una de ellas, la número 3, la considero la más importante de todas y, paradójicamente, la que en general en la industria informática se tiene menos en cuenta. Hay que pensar que esta tarea no sólo sirve para cuidar la calidad de un desarrollo, también para evitar complejidades innecesarias, reutilizaciones de código no empleadas, y que ciertos personajillos se aseguren un trabajo de por vida a base de escribir código inmantenible.
Actualización 19-AGO-2007: Leyendo una entrada del blog de Ayende se me ha ocurrido otro elemento importante que hace un arquitecto de software: revisión arquitectural del sistema (pues la revisión no arquitectural de cada uno de los cambios de cada programador es una tarea demasiado larga como para que sólo la lleve a cabo una persona) para que el sistema no se convierta en The Blob (otro antipatrón). Ah, y Ayende también está de acuerdo en que Architects don't code es un antipatrón.
Actualización 27-SEP-2007: Veo que me siento totalmente identificado con las palabras de una acojonante entrada de Ted Neward, la cual voy a citar (énfasis añadido):
How could their idea of an architect be so far removed from someone like myself? I can't answer this one solidly, but I can say that the definition of an architect seems to be vague and indiscriminate a term, only exceeded in opacity by the term "software" itself. For some companies I've worked for, the "architect" was as you describe yourself, someone whose hands were dirty with code, acting as technical lead, developer, sometimes-project-manager, and always focused on customer/business value as well as technical details. At other places, the architect (or "architect team") was a group of developers who had to be promoted (usually due to longevity) with no clear promotion path available to them other than management. This "architect team" then lays down "corporate standards", usually based on "industry standards", with little to no feedback as to the applicability of their standards to the problems faced by the developers underneath them. A friend of mine on the NFJS tour, Brian Sletten, tells a story of how he consulted on a project, implementing the (powerful) 1060 Netkernel toolkit at the core of the system, to resounding success. Then, on deployment, the "architecture team" took a look, pronounced the system to be incompatible with their "official standards", and forced new development of a working product. In other words, the fact that it worked (and could easily be turned to interoperate with their SOAP-based standard, of which there were zero existing services) was in no way going to stand as an impediment to their enforcement of the corporate standard.
Is architecture supposed to be facilitative or restrictive? Ah, this is a harder one to answer. In essence, both. Now, before the crowd starts getting out their torches and pitchforks to have a good old-fashioned lynching, hear me out.
Architecture is intended to be facilitative, of course, in that a good architecture should enable developers to build applications quickly and easily, without having to spend significant amounts of time re-inventing similar infrastructure across multiple projects. A good architecture will also facilitate interoperability across applications, ensure a good code quality, ensure good maintainability, provide for future extensibility, and so on. All of this, I would argue, falls under the heading of "facilitation".
But an architecture is also intended to be restrictive, in that it should channel software developers in a direction that leads to all of these successes, and away from potential decisions that would lead to prolems later. In other words, as Microsoft's CLR architect Rico Mariani put it, a good architecture should enable developers to "fall into the pit of success", where if you just (to quote the proverbial surfer) "go with the flow", you make decisions that lead to all of those good qualities we just discussed.
This is asking a lot of an architecture, granted. But that's the ideal.
What relevance do architects have today? Well, this is a dangerous question, in that you're asking it of one who considers himself an architect and technologist, so take this with the usual grain of salt. Are we just overpaid out-of-touch developers? God, I hope not. Fowler talks about architecture being irrelevant in an agile project, but I disagree with that notion pretty fundamentally: an architect is the captain of the ship, making the decisions that cross multiple areas of concern (navigation, engineering, and so on), taking final responsibility for the overall health of the ship and its crew (project and its members), able to step into any station to perform those duties as the need arises (write code for any part of the project should they lose a member). He has to be familiar with the problem domain, the technology involved, and keep an eye out on new technologies that might make the project easier or answer new customers' feature requests.
And if anybody stands up at this point and says, "Hey, wait a minute, that's a pretty tall order for anybody to fill!", then you start to get an idea of why architects do, frequently, get paid more than developers do. Having to know the business, the technology at a high and low level of detail, keeping your hands in the code, and watching the horizon for new developments in industry, is a pretty good way to burn out any free time you might have thought you'd have.
Granted, all of these answers notwithstanding, there's a large number of "architects" out there whose principal goal is to simply remain employed. To do that, they cite "best practices" established by "industry experts" as a cover for making decisions of their own, because nobody ever gets fired for choosing what industry "best practices" dictate. That's partly why I hate that term: it's a cop-out. It's basically relying on articles on popular websites and magazines to do your thinking for you. Inevitably, when somebody at a conference says the word, "Best Practice", listeners' minds turn off, their pens turn on, and they dutifully enscribe this bit of knowledge into their projects at home, without considering the applicability to their project or corporate culture. Nothing, not a single technology, not a single development methodology, not even a single tool, is always the right answer.
Actualización 09-FEB-2008: Voy a citar dos fuentes más de información que expresan muy bien lo que es un arquitecto de software o la calidad del software que éste debe perseguir.
La primera es un párrafo del mítico libro The Mythical Man-Month, válgame la redundancia, citado en esta entrada de Scott Rosenberg:
The goal of "conceptual integrity" or unity of design: The best programs and software systems exhibit a sense of consistency and elegance, as if they are shaped by a single creative mind, even when they are in fact the product of many. The fiendish problem is less how to create that sense in the first place than in how to preserve it against all the other pressures that come to bear throughout the process of writing software.
Por último, dos párrafos sueltos de una entrada de Ayende Rahien titulada "Don't meake me THINK!", que habla sobre arquitectura y usabilidad:
A while ago I was asked what I think was a good quality for an architect. My reply was that he should set things up in such a way where the developers are bored.
That may sound... harsh to some, but I believe that we have enough complexity in our applications as it is. A success story is reducing the complexity to such a level that we focus on the business value, rather on the technical difficulties.
[...]
This means that we can spend all the time actually producing business value. It also means that I have a lot of junior people on my team that can immediately make use of very advance concepts and produce good, solid software.
Actualizacion 17-MAY-2008: Don't Let Architecture Astronauts Scare You es una interesante entrada de Joel Spolsky que desmitifica al perfil de arquitecto-soluciona-todo. No es que se meta con los arquitectos de software (aunque alguna frase sí me ha dolido, como Remember that the architecture people are solving problems that they think they can solve, not problems which are useful to solve), sino con el aire marketiniano que se le da algunas veces a cosas relacionadas con la arquitectura, pero que al final acaban resolviendo algo interno (no visible al usuario).
Y me ha dolido porque pienso que la arquitectura sí es algo util de resolver/perfeccionar, dependiendo del punto de vista claro. Y aquí voy a usar el símil que el mismo Joel ha utilizado: ?le interesa al cliente de un supermercado saber que los productos se llevan en camión desde el almacen? No. Pero, ?es por eso menos importante la eficiencia de los procesos internos para que el cliente pueda disfrutar de su producto finalmente? No.
Actualizacion 02-NOV-2008: Es triste como parece que España sigue igual en cuanto a la mentalidad de muchos informáticos. Cuando alguien te diga cosas como "¿Programando a los 50? No, por favor" o "A ver cuando me ascienden para dejar de programar", es que no es un auténtico ingeniero de software con vocación, y me apuesto a que no sabrá ni siquiera lo que es un arquitecto de software (un puesto de lo más relevante, y que precisamente suele ser la aspiración de los que quieren progresar en su carrera pero sin dejar de programar, puesto que es su pasión).
Labels: General, Ingenieria, Programacion
Tuesday, December 06, 2005
Autopackage: sistema común de paquetería en Linux
Hace unas semanas, al hilo de una noticia sobre repositorios de Mandriva en BarraPunto, puse un comentario preguntando sobre una posible unión de esfuerzos en el mundo del software libre para mejorar y unificar el tan diverso mundo de los sistemas de paquetes software que tenemos actualmente en nuestras distribuciones.
Muchos me saltaron con la típica cantinela de que siempre es mejor la diversidad (arguyendo que los escritorios Gnome y KDE no se han unificado), pero en mi opinión hay ciertas áreas donde es mucho mejor la unificación que la diversidad, sobre todo en una cosa como ésta en la que no existen opiniones muy variadas sobre las funciones que debe cumplir un sistema de paquetes y dependencias (al fin y al cabo, todos cumplen las mismas funciones, pero con pequeñas diferencias). Además no estamos influenciados por decisiones "no técnicas", como ocurre con la eterna lucha KDE-Gnome, en la cual mucha gente intenta desplazar al contrario usando argumentos tan simples e inútiles como sus propios gustos.
El caso es que, como suele pasar con estas cosas, no soy el único que lo ha pensado, y de hecho ya hay gente que se ha puesto a trabajar. Lo comentan en una entrada de OSNews, en la que hacen referencia a un interesante artículo sobre el nuevo sistema de paquetes "AutoPackage" que nació hace poco y pretende venir para quedarse. Después de echar un vistazo al artículo, veo que no tiene el objetivo que yo planteaba desde un principio, pero sí pretendería separar los paquetes en dos tipos: los de sistema y los de usuario. De esta manera, el usuario podría instalar paquetes que no sean de sistema, sin necesidad de tener privilegios de administrador. Estos paquetes, además, deberían ser instalables en cualquier distribución. Los paquetes de sistema seguirían regidos por los sistemas de gestión de paquetes actuales, pero desde luego yo creo que éste es un buen comienzo para alcanzar el objetivo que yo planteaba y unificar éstos últimos también, así que me parece una iniciativa innovadora y muy interesante.
P.D.: Todo lo que sea unificar me gusta. Si estás interesado en modularizar y unificar el uso que haces del lenguaje JavaScript, no dejes de visitar mi proyecto GPL: AMUSE.
Actualización 05-FEB-2007: Hablando ahora de los sistemas de paquetes en el software libre en general, hay mucha gente que argumenta que son bastante mejores que los del software privativo, y no les voy a contradecir. Se basan en la comodidad de la resolución automática de dependencias, la instalación de únicamente piezas de software realmente necesarias (sin riesgo de spyware u otros) y la facilidad de configuración ya que incluso se hace más fácil que un típico asistente "Siguiente->Siguiente->Siguiente". Es cierto, sólo que con respecto al último argumento, hay veces en las que un asistente sí es mejor que un instalador completamente desatendido: cuando te da pistas de como empezar a utilizar el programa.
Esta idea me he planteado escribirla (porque ya la tenía en mi cabeza de hace bastante tiempo) al leer una entrada de Libertonia en la que un editor escribe:
(...) Como VDR sí estaba en mi distribución (Debian) me dije: "pan comido". Y una mierda. (...) Debian, que suelen darte todas las pistas necesarias para dejar funcionado cualquier paquete que instales, pensé que tras un apt-get ya iba yo a estar viendo la tele, y grabando... pues no. (...) Instalas el paquete y simplemente no ocurre nada. (...)
Y es que deberíamos tener un sistema estándar de "resumen de instalación de paquetes", en el que se le mostrase al usuario los principios básicos de uso del programa, el nombre de su invocación por línea de comandos o dónde se ha ubicado su icono de acceso directo. ¿No creéis?
Actualización 18-ABR-2007: No soy el único que se queja de que debería haber un estándar en el empaquetado. Aunque este sistema sea mucho mejor que el del software propietario, necesita seguir mejorándose. Una solución es que todo software use el sistema OpenSUSE BuildService, el cual es multi-distribución, es decir, preparas tu aplicación para el deployment una vez, y ya la tienes lista para n distribuciones.
Actualización 27-OCT-2009: Casi 4 años después de escribir la entrada inicialmente, no se ha solucionado el problema. El software opensource sigue dependiendo de complicados sistemas de despliegue de paquetes sin estándar definido (deb, rpm?). OpenSUSE BuildService ha ido ganando popularidad pero no ha ganado nicho oficial en otras distribuciones (quizás por el recelo de que el nombre de la distribución forma parte del producto, o por la simple impresión que da para los no iniciados de que no es una herramienta multi-distribución). Ahora en PlanetGnome se vuelve a hablar del tema pero no se menciona a AutoPackage, sino a otro sistema llamado Klik. En fin, ¿tendré que escribir aquí dentro de otros 4 años diciendo que el problema sigue sin resolverse? A veces la lentitud del progreso del open source me desespera.
Muchos me saltaron con la típica cantinela de que siempre es mejor la diversidad (arguyendo que los escritorios Gnome y KDE no se han unificado), pero en mi opinión hay ciertas áreas donde es mucho mejor la unificación que la diversidad, sobre todo en una cosa como ésta en la que no existen opiniones muy variadas sobre las funciones que debe cumplir un sistema de paquetes y dependencias (al fin y al cabo, todos cumplen las mismas funciones, pero con pequeñas diferencias). Además no estamos influenciados por decisiones "no técnicas", como ocurre con la eterna lucha KDE-Gnome, en la cual mucha gente intenta desplazar al contrario usando argumentos tan simples e inútiles como sus propios gustos.
El caso es que, como suele pasar con estas cosas, no soy el único que lo ha pensado, y de hecho ya hay gente que se ha puesto a trabajar. Lo comentan en una entrada de OSNews, en la que hacen referencia a un interesante artículo sobre el nuevo sistema de paquetes "AutoPackage" que nació hace poco y pretende venir para quedarse. Después de echar un vistazo al artículo, veo que no tiene el objetivo que yo planteaba desde un principio, pero sí pretendería separar los paquetes en dos tipos: los de sistema y los de usuario. De esta manera, el usuario podría instalar paquetes que no sean de sistema, sin necesidad de tener privilegios de administrador. Estos paquetes, además, deberían ser instalables en cualquier distribución. Los paquetes de sistema seguirían regidos por los sistemas de gestión de paquetes actuales, pero desde luego yo creo que éste es un buen comienzo para alcanzar el objetivo que yo planteaba y unificar éstos últimos también, así que me parece una iniciativa innovadora y muy interesante.
P.D.: Todo lo que sea unificar me gusta. Si estás interesado en modularizar y unificar el uso que haces del lenguaje JavaScript, no dejes de visitar mi proyecto GPL: AMUSE.
Actualización 05-FEB-2007: Hablando ahora de los sistemas de paquetes en el software libre en general, hay mucha gente que argumenta que son bastante mejores que los del software privativo, y no les voy a contradecir. Se basan en la comodidad de la resolución automática de dependencias, la instalación de únicamente piezas de software realmente necesarias (sin riesgo de spyware u otros) y la facilidad de configuración ya que incluso se hace más fácil que un típico asistente "Siguiente->Siguiente->Siguiente". Es cierto, sólo que con respecto al último argumento, hay veces en las que un asistente sí es mejor que un instalador completamente desatendido: cuando te da pistas de como empezar a utilizar el programa.
Esta idea me he planteado escribirla (porque ya la tenía en mi cabeza de hace bastante tiempo) al leer una entrada de Libertonia en la que un editor escribe:
(...) Como VDR sí estaba en mi distribución (Debian) me dije: "pan comido". Y una mierda. (...) Debian, que suelen darte todas las pistas necesarias para dejar funcionado cualquier paquete que instales, pensé que tras un apt-get ya iba yo a estar viendo la tele, y grabando... pues no. (...) Instalas el paquete y simplemente no ocurre nada. (...)
Y es que deberíamos tener un sistema estándar de "resumen de instalación de paquetes", en el que se le mostrase al usuario los principios básicos de uso del programa, el nombre de su invocación por línea de comandos o dónde se ha ubicado su icono de acceso directo. ¿No creéis?
Actualización 18-ABR-2007: No soy el único que se queja de que debería haber un estándar en el empaquetado. Aunque este sistema sea mucho mejor que el del software propietario, necesita seguir mejorándose. Una solución es que todo software use el sistema OpenSUSE BuildService, el cual es multi-distribución, es decir, preparas tu aplicación para el deployment una vez, y ya la tienes lista para n distribuciones.
Actualización 27-OCT-2009: Casi 4 años después de escribir la entrada inicialmente, no se ha solucionado el problema. El software opensource sigue dependiendo de complicados sistemas de despliegue de paquetes sin estándar definido (deb, rpm?). OpenSUSE BuildService ha ido ganando popularidad pero no ha ganado nicho oficial en otras distribuciones (quizás por el recelo de que el nombre de la distribución forma parte del producto, o por la simple impresión que da para los no iniciados de que no es una herramienta multi-distribución). Ahora en PlanetGnome se vuelve a hablar del tema pero no se menciona a AutoPackage, sino a otro sistema llamado Klik. En fin, ¿tendré que escribir aquí dentro de otros 4 años diciendo que el problema sigue sin resolverse? A veces la lentitud del progreso del open source me desespera.
Labels: General, SoftwareLibre
Monday, December 05, 2005
AMUSE ya está en el SVN de Berlios
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í:
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:
Luego, en el <head> de la página, referenciaríamos a dos ficheros javascript externos:
El fichero "amuse.js" es el que implementa el interfaz de AMUSE. En el fichero mi_pag.js podríamos introducir lo siguiente:
De esta manera estaríamos llamando al módulo EmailAntiSpam, el cual, si miramos en su implementación interna haría cosas como:
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:
Módulos:
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:
TO-DO:
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
Sunday, December 04, 2005
Manifestación contra la constitución monárquica
No sé si es lo más correcto introducir entradas con contenido político en mi blog, pero esta vez no puedo aguantarme, pues me parece ciertamente preocupante que después de 30 años de constitución monárquica los españoles no se nos ocurra mayoritariamente replantearnos ciertos puntos de ésta, la cual es la menos mala donde las haya, por supuesto.
¿Por qué debemos quedarnos con el modelo obsoleto de monarquía parlamentaria? Creo que los ciudadanos queremos una soberanía popular completa, y no parcial. Además, deberíamos abogar por un modelo de estado laico, en lugar de aconfesional, para poder prohibir taxativamente de una vez por todas cualquier financiación de ningún tipo a ninguna institución religiosa, procedente del estado.
Quizás debería hacer algún día otro "antiFUD", que sirviera para dejar claro que el modelo republicano de estado no tiene por qué identificarse con ninguno de los dos típicos lados de la balanza: la izquiera o la derecha. De hecho, la mayor prueba de ello son los EE.UU., los cuales poseen un sistema republicano federalista que actualmente regenta un gobierno que se posiciona ciertamente más a la derecha que su alternativo (pues tienen un modelo bipartidista por el momento), el cual tampoco se puede tildar de "izquierda".
Si a alguien le interesa "mejorar" nuestro sistema de soberanía español, le recomiendo que ponga su granito de arena acudiendo a la Manifestación contra la constitución monárquica que tendrá lugar este martes día 6 de Diciembre a las 12:00 horas, en Madrid, desde Atocha a Jacinto Benavente.
Actualización: Parece que en nuestro estado democrático sigue existiendo la censura porque ninguna de las cadenas de televisión hizo referencia a una manifestación de 10.000 personas en Madrid.
¿Por qué debemos quedarnos con el modelo obsoleto de monarquía parlamentaria? Creo que los ciudadanos queremos una soberanía popular completa, y no parcial. Además, deberíamos abogar por un modelo de estado laico, en lugar de aconfesional, para poder prohibir taxativamente de una vez por todas cualquier financiación de ningún tipo a ninguna institución religiosa, procedente del estado.
Quizás debería hacer algún día otro "antiFUD", que sirviera para dejar claro que el modelo republicano de estado no tiene por qué identificarse con ninguno de los dos típicos lados de la balanza: la izquiera o la derecha. De hecho, la mayor prueba de ello son los EE.UU., los cuales poseen un sistema republicano federalista que actualmente regenta un gobierno que se posiciona ciertamente más a la derecha que su alternativo (pues tienen un modelo bipartidista por el momento), el cual tampoco se puede tildar de "izquierda".
Si a alguien le interesa "mejorar" nuestro sistema de soberanía español, le recomiendo que ponga su granito de arena acudiendo a la Manifestación contra la constitución monárquica que tendrá lugar este martes día 6 de Diciembre a las 12:00 horas, en Madrid, desde Atocha a Jacinto Benavente.
Actualización: Parece que en nuestro estado democrático sigue existiendo la censura porque ninguna de las cadenas de televisión hizo referencia a una manifestación de 10.000 personas en Madrid.
