ACM S.L. Free Software Repository

Finally I migrated the blog content to Redmine data model. I probably should have done it less manually, but I thought it would be so fast I shouldn't bother about scripting.

Once finished, I'm not sure I was right. I had to fix (again) encoding problems, and adapted (not yet 100% done) formatting rules. So I've been switching between Tora and Emacs constantly. Ironically, the limited visibility of the blog, as its number of comments say, has saved me some time :).

Once the content was copied, I had to fix the timestamps, since Trac used (according to MySQL) Unix format, whereas Redmine expects a more standard datetime type. So I added a new column to Redmine's blogs table, dragged & dropped from Tora, and finally executed

update blogs set created_on = from_unixtime(tmst)

Next, the wiki content itself. And learning how to include links and images in Redmine.

The previous www.acm-sl.org blog/project hosting was based on Trac (http://trac.edgewall.com).

I've been using and managing it for quite a long time, and I have a great opinion of it. However, my requirements include support for several projects, and AFAIK there's still discussion about when (and how) that will be supported by Trac.

So I decided to look for alternatives, and Redmine seems a good choice. Migrating to Redmine is part of a broader migration process which includes using Git instead of Subversion.

Now I just need to figure out how to recover previous blog posts (again).

Via [http://www.osoco.com osoco] I've just found out [http://www.wordle.net wordle.net], which allows you to generate a snapshot of the tags you used as metadata for your bookmarks.

Here it is http://www.wordle.net/thumb/wrdl/935988/chous%27_delicious,nolink

Acabo de leer una entrada en el blog de Partido Pirata relativo a luchar contra la campaña del gobierno de 'si eres legal, eres legal', utilizando una web alternativa [http://www.siereslegalcomparte.com/ si eres legal, comparte], y tratando de desbancarla de las primeras posiciones en google mediante un google-bombing. Aunque dudo mucho que sirva para algo, aquí van mis 2 cents :).

La 'clase política' es un fraude. Por un lado, los 'representados' podemos tener cierta inclinación a pensar que ante la duda ellos serán deshonestos, o tratarán de convencernos de sus mentiras si es necesario. Por otro, hay un 'tufillo' constante en la clase dirigente de 'triunfo', lo cual va arropado por su día a día de contactos con círculos de poder. Y eso es lo que al final hace tergiversar algo tan simple como la virtud de la generosidad. Hay intereses creados que, por estar más cerca de la clase política (desayunan o comen juntos, son 'colegas', etc.), contaminan de mercantilismo hasta los valores más fundamentales.

Por hacerlo más claro. Compartir está por encima del beneficio o pérdida económica. Las patentes no funcionaron para lo que se inventaron, sólo han servido para comprometer la innovación y hacerla un bien especulativo que pocas veces repercute en algún avance para la sociedad.

Last years I've tried to avoid Agile. Probably those days will be soon gone, since in the company I work for there's a strong commitment to adopt agile methodologies from the near future on.

So I'll have to adapt, I guess. There's no much space for discussion, but I still think Agile success means a failure in software engineering. Sounds dramatic, but I think its popularity has grown exclusively in business-focused software, since it's good to control (not exactly manage) software projects.

The main reason why agile practices are so popular among non-technical people is because it allows the software to follow their short-term criteria. They get the control, and they are no longer required to think deeply into their requirements, since the great news is that they can adapt when they actually see they were wrong. So now we have to deal ourselves with their trial-and-error approaches. This comes with the fact that now we (software engineers) have lost power. Maybe we didn't want it, or didn't use it, but it's gone. We are expected just to follow orders, and at the same time we don't need to think if what we develop will be able to handle probable future requirements. Nobody cares about them anymore.

Summarizing the point, we've lost the most precious area of our profession: modelling the abstractness. And nobody is doing it.

So I received some workshops about Agile. Of course, everything is carefully presented: all keywords are positive, some "benefits" but no "drawbacks" slides, and the annoying fallacy (http://en.wikipedia.org/wiki/Argumentum_ad_baculum Argumentum ad baculum) of trying to prove Agile is correct by exaggerating waterfall possible outcomes.

I tried to find people daring to say they don't like agility, and found one
(http://antiagile.indigenious.ro/ Agile Development in Outsourcing Considered Harmful). However, if you read the comments, you'll see what I perceived in the workshops: there's no discussion, Agile is good, if it doesn't work for you is your fault.

What kind of approach is that? What is Agile invented for? To exalt the reputation of the Manifesto signers? To build a business on top of that? To write useless[[FootNote(I have only regretted of purchasing two books: One from Robert C. Martin and one of Martin Fowler)]] books? Do we need this? I don't buy it. I don't accept becoming a "believer" of someone else's ideas. Why Agile is not applied to non-business (-focused) software development, such as free software? I was told they're ''completely different stuff''. Sure, but they define what we should consider '''success''', in terms of software.

Probably I'm upset because I'm about to lose what I've fought hard to achieve. Say respect, confidence, long-term results, while keeping the eye on the business. All this, thanks to think abstract, to look further what I was told to do, to care about what I do, and to avoid thinking exclusively if this is taking too long.

From my point of view, we are asked to get rid of the engineering stuff and do only what we're told to do. In practice, this is a list of business-visible features. It's not only that the rest is not important, but the lack of flexibility to non-feature-oriented tasks means they won't be supported in practice.
In other words: nobody but us wass doing engineering. Now we have to copy that if we want to be "good enough".

This blog is used by a group of individuals who doesn't share most of their interests, but we're friends.
We use this blog to say whatever we want, to get feedback from others, and to hear critics from whoever dares! :D.

The participants' interests range from software engineering, politics, free-software, and anything they eventually think worth publishing.

A pesar de que el concepto de ''herencia'' (en terminología de la programación orientada a objetos) es bastante fácil de asimilar, podemos encontrarnos ejemplos paradójicos, como el que ilustra el libro de Robert C. Martin Agile Software Development. Principles, Patterns, and Practices.

El ejemplo en cuestión trata de modelar los conceptos Figura, Rectángulo y Cuadrado. Intuitivamente, los conceptos se relacionarán de una forma similar a ésta:

  +--------+
  | Figura |
  +--------+
      ^
     / \
    +---+
      |
      |
+------------+
| Rectangulo |
+------------+
      ^
     / \
    +---+
      |
      |
 +----------+
 | Cuadrado |
 +----------+

Es decir, un Cuadrado no deja de ser un caso particular de Rectángulo, y ambos son Figuras.

Sin embargo, Cuadrado '''es''' un Rectángulo, y a la vez '''no lo es''', ya que que el concepto de Rectángulo mezcla dos definiciones:
Cuadrilátero cuyos lados:
1. forman ángulos rectos,
2. tienen longitud arbitraria (2 a 2).

Un cuadrado satisface la primera condición, pero no la segunda. Por ese motivo, si usáramos el modelo anterior, incurriríamos en incongruencias como métodos válidos en la clase padre Rectángulo, pero no válidos en Cuadrado, p.ej.: redimensiona(base, altura).

La única opción es, por tanto, un refinamiento en el modelo:

         +--------+
         | Figura |
         +--------+
              ^
             / \
            +---+
              |
              |
    +------------------+
    |   Cuadrilatero   |
    +------------------+
              ^
             / \
            +---+
              |
              |
    +-------------------+
    |   Cuadrilatero    |
    | de angulos rectos |
    +-------------------+
      ^               ^
     / \             / \
    +---+           +---+
      |               |
      |               |
 +----------+  +------------+
 | Cuadrado |  | Rectangulo |
 +----------+  +------------+

Se podrían unificar las clases ''Cuadrilátero'' y ''Cuadrilátero de ángulos rectos'', pero entonces podríamos encontrarnos con dificultades parecidas al tratar de modelar a la vez Cuadrado y Rombo, aunque curiosamente la intuición funciona mejor para éste caso, y no tratamos de pensar que "un cuadrado es un cierto tipo de rombo".

Es recomendable definir la herencia como una relación de pertenencia obvia, sin casos particulares, ya que de lo contrario podemos llevarnos sorpresas.

En concreto, en el libro citado se analiza el problema como una violación sutil del Principio de Sustitución de Liskov: "Subtipos deben ser reemplazables por sus tipos base".

El análisis se basa, como es frecuente en nuestros días, en una visión ''prágmatica'', consistente en mostrar las incongruencias en las que se incurren al aplicar el citado principio en el modelo de clases original. De hecho, incluso se llega a la conclusión de que la validez del modelo depende de un tercero: el código que recibe indistintamente un Cuadrado o un Rectángulo, y que sin embargo percibe que ambos no se comportan igual. En otras palabras: '''según el autor, un cuadrado es o no es un rectángulo dependiendo del punto de vista de quién los use'''.

éste es un buen ejemplo que muestra en lineas generales mi opinión del libro: tiene cosas interesantes, pero te va dando bofetadas sin parar.

Si alguno lo quiere, lo regalo/presto/vendo (depende de lo que le resulte más cómodo).

Encontré una frase de C.S. Lewis que me hizo reflexionar sobre la existencia de Dios:

"En "Hamlet" se rompe una rama y Ofelia cae al río y se ahoga. ¿Ocurre el suceso porque se rompe la rama o porque Shakespeare quiere que Ofelia muera en esa escena? Puedes elegir la respuesta que más te guste, pero la alternativa no es real desde el momento en que Shakespeare es el autor de la obra entera".

Poniendo en contexto la cita, C.S. Lewis trata sobre el dilema: ¿Quién tiene la responsabilidad de un suceso acaecido? Las leyes de la naturaleza o Dios. En la cita Dios es Shakespeare, y es que claro, si Shakespeare es el creador de la obra tiene poco sentido analizar quién es el responsable de la muerte de Ofelia, lógicamente Shakespeare lo quería así.

Me llama la atención como un ateo se convierte al cristianismo tras años de conversaciones con Tolkien, y dedica parte de su tiempo a escribir sobre el tema. Pero claro, si yo hubiera tenido la suerte de conocer a Tolkien puede que ahora también fuera creyente.

En fin, centrándome en lo que realmente quiero comentar aquí-. Partamos de la negación de las premisas normalmente asociadas a Dios (entendiendo a Dios como el creador del universo). A saber, bondad, omnipresencia y omnipotencia.

Empecemos por un Dios omnipotente y omnipresente pero carente de toda bondad. Esta situación no es del todo improbable y seguramente sería con la que me quedaría si creyera en Dios pero mi propuesta será otra. Esto explicaría por qué vivimos en un mundo tan injusto y absurdo, sin embargo no me parece que un Dios malvado se contentara con dejarnos en este difícil mundo a nuestro libre albedrío. Creo que usaría su omnipotencia para fastidiar más. Aunque claro, puede que en catástrofes como los ''tsunamis'' tenga algo que ver un Dios de este estilo.

Un Dios bondadoso, omnipotente pero sin omnipresencia causaría una situación curiosa, es decir le encantaría ayudar y podría hacerlo pero al no ser consciente de lo que ocurre en el mundo se ve impedido. No me quedo con esta ya que considero que la omnipotencia implica la omnipresencia; si todo lo puedes, ¿por qué no estar en todos sitios a la vez?

De igual forma, la combinación anterior pero con un Dios malvado es absurda por el mismo motivo.

Por otro lado un Dios bondadoso, omnipresente pero sin poder alguno --por haber consumido todo su poder en la creación del mundo, por ejemplo-- es factible aunque lamentable, áya podía haber reservado algo de poder para guiar un poco su creación! Es como construir un avión, hacerlo volar y no ponerle un piloto que lo controle, simplemente se estrella. En cualquier caso no creo que la omnipotencia permita la propia pérdida del poder así que volvemos al absurdo.

La opción que mantiene el cristianismo sin duda me parece la menos probable; hay que ser malvado para tener la capacidad de mejorar las cosas y no hacerlo. Y esto es una contradicción puesto que se parte de un Dios bondadoso.

Yo me quedo con la inexistencia de Dios y el concepto de infinito, me es más sencillo pensar que el momento de la creación está en el infinito. Es decir, no hay tal creación y por tanto no hay tal creador. Soy consciente de que el concepto de infinito nos hace sentirnos incómodos pero uno se puede acostumbrar a ello; basta con utilizar el símbolo adecuado y manejar rangos cercanos a nosotros. Con los números lo hacemos sin ningún problema aparente, raramente manejamos números muy elevados aunque sabemos que existen y el infinito lo manejamos como un concepto abstracto al que tienden los números y lo simplificamos con el símbolo correspondiente.

¿Por qué no asumir algo del siguiente estilo?

A mi me vale.

Esto no pretende ser una demostración, ánada más lejos de mis posibilidades! Es simplemente una opinión personal de un tema tan extensamente debatido en la historia.

Se me ha ocurrido una analogía entre determinadas prácticas políticas y formas de regular el tráfico.

La democracia, tal como comúmente se concibe, favorece el criterio más respaldado por la mayoría.
Eso da lugar, como es sabido, a lo que se denomina como dictadura de la mayoría.
Este hecho es algo característico y me da la impresión de que se considera valioso.

Por otra parte, en ocasiones la democracia se pone en práctica de forma que el poder se va alternando de una forma más o menos periódica entre (por lo general) dos partidos, los cuales "representan" (dicen representar) la voluntad y el criterio de amplios porcentajes de la población.

Dejando a un lado si de hecho se representa a nadie, y si dichos representantes actúan realmente como portavoces de los que dicen representar, se podría hacer un paralelismo, y pensar en la alternancia como un semáforo, que regula a quién se le permite pasar durante un período de tiempo en detrimento del resto.
Ese sistema es bastante fácil de entender, dado que no es muy sofisticado: se reparte el derecho de uso en franjas temporales.

Hay que tener en cuenta, por otro lado, que los sistemas que regulan el acceso a un recurso limitado se pueden analizar usando una rama matemática denominada teoría de colas.
Aprovecho para dejar caer que no está de más la aplicación del conocimiento científico a las disciplinas sociales, en la medida que se pueda, y no ceder ante la subjetividad generalizada bajo el argumento de que no hueco para la objetividad en las ciencias humanas.

Imaginémonos por otro lado lo que sucede en una rotonda.
A priori, es un modelo "liberal", en el sentido de carecer de elemento regulador: el que llega antes y puede, gana.
Comparado con el semáforo, funciona bastante bien.
Es más eficiente, ya que garantiza que el recurso sólo está desocupado si no hay usuarios que lo demanden.
Un semáforo hace esperar incluso si no hay nadie haciendo uso de la vía.

En términos democráticos, la mejora conseguida por un sistema basado en rotondas en lugar de semáforos encaja bastante con la idea de una democracia más "pura" (más representativa que parlamentaria), en la cual no hay que esperar 4 años (o los que acordados) para que tus ideas se vean reflejadas en el criterio de la clase dirigente.

Sin embargo, la rotonda, y por ende la analogía democrática, tiene un punto débil: margina a las minorías.
Si la mayoría de vehículos que accede a una rotonda va en la misma dirección, el resto de las rutas que se vean entorpecidas lo tienen crudo.
Es fácil ver ejemplos cada día: la rotonda no garantiza un acceso en un tiempo finito al recurso a nadie.
La corriente dominante favorece el uso de la rotonda a quienes van en esa dirección.
Llega un momento de saturación en el que sólo pueden acceder a la rotonda quienes vayan en una dirección que no entorpezca dicha corriente.

La pregunta es: ¿Las minorías importan?

Lo primero que quiero decir es que la idea de escribir este texto surgió de
un conversación con un desarrollador de entornos web que programa en C#
(sharp). También diré que las ideas que trataré de exponer no son propias, a
parte de que deben estar en muchos libros, a mi me lo explico un buen amigo.

El caso es que dicho desarrollador me enseñaba con orgullo las cosas que
hacía, lo bonitas que le quedaban y la magnífica herramienta de desarrollo
de que disponía.

Bien Yo, que no soy desarrollador de páginas web y que me dedico a los
entornos empotrados probablemente sea el menos indicado para hablar de este
tema, pero para esto está la web, para decir lo que quieras y en este caso
sin ser un experto, tampoco creo que vaya a decir algo sin sentido.

Dicho programador me enseñaba como loco lo fácil que era crear una
aplicación y lo mucho que le ayudaba la herramienta, y la verdad es que
tenía razón, una vez que aprendes a manejar la herramienta, cosa que no
parecia inmediata realmete parecia todo muy fácil.

Cuando me enseñaba el código que se generaba me di cuenta que se mezclaba
la capa de presentación con la capa de negocio, vamos para entendernos bien,
el html y la algoritmia de todo tipo se mezclaba.

Traté de hacerle entender que hacer las cosas así no erá una buena
dinámica, pero en seguida me di cuenta de que recibía frases prepotentes del
tipo, tu dedicaté a tu mi..da de C que yo he estudiado para esto y sobre
todo, me dedico a esto. Lo cual me lleva a pensar que no le enseñaron bien,
o que no es un buen profesional o que yo mejor me dedique a mi mi..da de C.

Después de una dura lucha al final lo único que pareció hacerle pensar un
poco es que si habóa que cambiar la forma de la página desde el punto de
vista de presentación de la interfaz, se podría hacer si todo estuviera bien
separado sin compilar código y sin que el desarrollador estuviera presente.
Por ejemplo lo podría cambiar un diseñador gráfico sin ayuda de ningún tipo.
Pero fué sólo un espejismo,pensar debió pensar pero al final decidió que no
le interesaba lo que le contaba.

Yo creo que podría haber mostrado más interes, la gente cree que lo
sabe todo y es mejor ser más humilde y tratar de aprender de las buenas
ideas, no porque sean mias, es que además están en los libros.

En resumen, no le convencí y yo me sigo dedicando a mi m...a de C.

Bueno voy a contar como hago últimamente las aplicaciones que necesitan una
interfaz de usuario. Simplemente es algo que me sirve a mi, y no tiene
porque gustarle a nadie más, pero me parece útil y sobre todo extremadamente
sencillo ya que en general la parte de la interfaz gráfica suele ser tediosa
y complicada, sobre todo en lo que se refiere al manejo de eventos.

Lo que hago es hacerlo todo en un entorno web. Me da igual si se va a
ejecutar en local, me simplifica muchísimo el trabajo y dependiendo del
nivel que se tenga en entornos web puede quedar aplicaciones muy vistosas.
Dejo claro que NO es mi caso. Es decir creo las interfaces necesarias con
html y algo de javascrip si es imprescindible. La parte inteligente en C o
C++.

Esté método tiene ciertas ventajas, que creo
son importantísimas, y supongo que también tiene desventajas, quizás una de ellas
es que puedan ser un poco más lentas, y que se necesita un servidor http.

Por supuesto si quieres hacer un juego con gráficos o cosas así este no es
el método adecuado, pero sí para realizar las típicas aplicaciones con
formularios para rellenar.

Las ventajas claras son:

1. Tu aplicación de un plumazo se convieten en distribuidas. Cualquier persona puede acceder a ellas desde donde quiera, en forma local, red privada, o incluso internet.
2. Es ideal para aplicacione donde varias personas tengan que utilizar la misma aplicacion. Pones en un servidor tu aplicación y todo el mundo la ejecuta desde donde quiera y a la vez.
3. Yo diría que casi cualquiera sabe algo de html, y si no se puede utilizar un editor de html de los de arratrar y soltar. Un libro de javascript para alguna cosa un poco más complicada y listo.
4. Si lo haces bien tienes separada totalmente la capa presentación, la lógica y la capa de persistencia o administración de datos.

Mi forma de trabajar es, creo la página html a mano o con un editor. Donde quiero
colocar información que se consigue con la parte lógica del programa pongo
un tag del tipo info1, info2 ... de tal forma que antes de servir la página
se parsea y se cambia los tags por la información deseada.

Es decir, aunque la página html tiene entidad propia, no la sirvo
directamente desde el servidor, la sirve la capa de negocio que lee del
disco el fichero con la información html y la presenta. Antes de presentarla
la parsea por si tiene que cambiar algo.

Es decir, la única interación entre las capas o nexo de unión son esos pequeños tags que se
sustituyen en el momento de presentar la página. Una vez creado el sistema
se puede cambiar el aspecto de la página si recompilar nada.

La lógica de negocio la realizo en C o C++, por lo que estoy creando un CGI. Este
tipo de aplicaciones ya no se utilizan mucho porque tienen ciertas
desventajas con respecto a, por ejemplo, un servlet o una JSP. De entrada
son más peligrosas con los recursos, OJO, ya que si no programas bien puedes
tirar un servidor, pero como son mis aplicaciones y me fío de mi mismo, lo
hago así, por comodidad ya que son los lenguajes que manejo a diario.

Otro inconveniente es la forma en que el servidor replica la aplicación en
memoria cuando hay varios usuarios utilizándola a la vez, siendo menos
eficiente en el caso de los CGI ya que lanzan tantas aplicaciones como
usuarios la utilicen, tal cosa se solventa de forma más ligera, mediante
hilos en otro tipo de aplicaciones como las servlets. Pero vuelvo a lo
mismo, en general sólo yo utilizo las aplicaciones y en cualquier caso los
PC actuales pueden soportar muchas aplicaciones en memoria sin problemas.

En resumen, un poco de html, un poco de mi...a de C básico y un apache y montas un
buen chiringo.

Por cierto, como siempre digo, ¿Alguien sabe en qué está escrito el
kernel de linux? SÍ, EN ESA MI..DA DE C.