[_______________]

Después de varios meses de tenerlo en espera pude leer Peopleware, todo un clásico de la administración de proyectos y de la ingeniería de software.

Peopleware es un libro sobre eso, sobre la gente, sobre como el factor humano tiene una incidencia gigante en cualquier proyecto y sobre todo nos cuenta como los gerentes se encargan de ignorar convenientemente toda esta información en pro de sus números, costos y tiempos apretados. Pero es ahí mismo donde radica la fuerza de Peopleware, no es un libro de empleados frustrados contando como nos ignoran, como no somos más que números para nuestras empresas o como hay cosas que importan más que el dinero.

Peopleware es un libro de jefes que le demuestran a los demás jefes que el factor humano si puede ser medido como más les gusta a ellos: en términos de tiempos y de costos. Les demuestra como las condiciones de trabajo, la motivación, la comunicación entre compañeros, la antigüedad de los empleados y todas esas cosas que se suelen ignorar, juegan un papel que hace que un proyecto sea más caro, más barato y al fin, que sea exitoso o no. Por eso es que es un libro que se debe tener en cuenta, por que tiene argumentos aplastantes para hacer que las cosas sean mejor, para hacer que los jefes piensen en serio en mejorar definitivamente las condiciones de trabajo, en disminuir las jornadas de 12 ó 16 horas al día y lo hacen de una forma que hasta el jefe más inhumano se lo plantee, insisto una y otra vez, lo hace con cifras.

Después de esto muchos supondrán que es un libro que deben leer los gerentes o los aspirantes a gerentes, de hecho, es lo que suelen decir las editoriales y reseñas. Pero no, ahí está la otra gran enseñanza de Peopleware, que es un libro que debe ser leído por todos, por que si a nivel individual no enseña como ser mejor persona o mejor programador si que nos enseña la importancia de la motivación, no de darla, sino de saberla recibir; nos enseña lo importante que es mantener nuestro entorno de trabajo en condiciones adecuadas, claro, nuestro jefe nos puede dar los mejores muebles, espacio, etc., pero somos nosotros quienes debemos procurar un silencio que facilite el trabajo creativo.

Finalmente algo que me impactó bastante al ver lo complejo que puede ser para un gerente, es la importancia del trabajo en equipo. Este aspecto, siempre tan descuidado, tiene una influencia definitiva en la calidad del producto que se desarrolla y deja un claro mensaje: hay que saber trabajar y pertenecer a un equipo de trabajo, no solo interactuar técnicamente sino que hay que crear la mística y ese sentimiento de superioridad que caracteriza a los equipos triunfadores.

Es un libro absolutamente recomendado y que seguramente volveré a leer en alguna etapa de mi vida.

No quiero finalizar sin dejar un par de buenos consejos o datos d los aprendidos:

Durante mi entrada a este mundo de la ingeniería de software me he encontrado con cosas increíbles: la forma como se puede concebir un proyecto a un alto nivel, las técnicas para estimar su duración, el cálculo de puntos de función, las metodologías iterativas y la convivencia con el cambio, la asignación de recursos, el modelado del negocio, el análisis, el diseño, las pruebas todas las disciplinas de RUP, etc. Hace 6 meses ni me imaginaba todas las herramientas que existen para administrar un proyecto de desarrollo de software, no es que esté administrando un proyecto ahora, pero si que he tenido que preocuparme por estos aspectos.

Pero son tantos, tan diversos, hay tantas formas de ver un proyecto que resulta abrumadora la cantidad de materias en las que me encuentro ignorante; puedo mirar el proyecto desde el punto de vista de su desarrollo, es decir, las etapas que comprenden el modelado del negocio, la definición de requerimientos, el análisis y diseño, la implementación, las pruebas y el despliegue. Esta es la primera “vista” a la que me acerqué, es la que más conozco o al menos la que se me antoja menos ajena, de todas formas en la universidad se aborda cada uno de estos temas, no con gran profundidad, pero se hace y ya tenía idea de que se trata cada uno. Aún así me he llevado muchas sorpresas: la relevancia que tienen los casos de uso, como a través de ellos se puede conocer el tamaño de un sistema y como a través de ellos se puede hacer un seguimiento a todo el proceso de desarrollo; también he descubierto muchas cosas sobre el diseño, que se trata como todo de un proceso iterativo, que de un diagrama de clases se hace un esbozo inicial y a través de otros diagramas (especialmente el de secuencia) se pude probar ese diseño inicial para entrar en una etapa cíclica de refinamiento. Me he enterado de otras disciplinas sobre las que no tenía mucho conocimiento: las técnicas para modelar el negocio y la preparación de casos de prueba, no solo las he conocido, sino que he aprendido a reconocer su valor en el proceso.

La otra vista desde la que se puede mirar el proyecto es desde la administrativa, es decir, las disciplinas que soportan el proceso y que brindan las técnicas y herramientas para medirlo y controlarlo adecuadamente. Hay técnicas muy interesantes para crear un cronograma iterativo, basado en el proceso y no en el producto, es decir, hay que pensar el proyecto en términos de etapas y disciplinas, no de módulos y submódulos como estamos acostumbrados a hacerlo. El diseñar un cronograma de esta forma es lo que ha permitido estandarizar la forma de administrar proyectos de desarrollo de software, por que podemos comparar los procesos llevados para proyectos similares y empezar a obtener patrones y métricas. Una vez realizada la planificación del proyecto se pueden empezar a definir requerimientos, requerimientos que muy seguramente irán cambiando con el tiempo, a los cuales se les puede hacer seguimiento con casos de uso bien definidos y con las herramientas adecuadas que proporciona la disciplina del entorno (environment); todo esto ya está bien documentando, depurado con el paso del tiempo, con aplicación en miles de proyectos y adaptado a la tecnología de nuestra época.

Todo el interés que me ha generado mi nuevo quehacer me ha traído también una cantidad infinita de recursos: libros, páginas Web completas, artículos en línea, revistas, etc. Es obvio que nunca en mi vida voy a leer todo lo que quiero leer, que por más que me guste hacerlo, debo ser efectivo con las cosas que estudio, es decir, escoger lo mejor, lo más clásico o “lo más” en algún aspecto. No puedo leer cuanto libro consigo o me prestan, no puedo leer todos los artículos de la Web. Por eso hice una selección del material que más me recomendaron o el que más interesante me pareció por el autor o el contenido; es una gran cantidad de material, pero al menos es finita y creo yo, la puedo procesar en unos tres o cuatro meses, ojala tres para finalizar el año con la frente en alto. El material corresponde a las dos vistas de las que he hablado: el proceso de desarrollo y la parte administrativa, todo muy orientado RUP y sus mil formas de hacer lo mismo, pero es que creo que RUP es maravilloso por la claridad y la madurez de las cosas que propone. Claro, también puede llegar a ser un ladrillo.

Ha existido desde siempre una línea que nos separa los ingenieros de nuestros usuarios, una línea construida sobre la diferencia en lenguajes y en la forma de pensar; en el caso del desarrollo de software, nos separa a quienes diseñamos y construimos las aplicaciones de aquellos usuarios que las van a usar o que de una u otra forma se van a ver beneficiados por ellas.

Que exista esta diferencia está bien, la hay en todas las ciencias, artes, deportes, etc. El mundo funciona por que a todos nos gustan cosas diferentes, hay quienes diseñan casas, hay quienes las construyen, otros se especializaron en hacer cemento y los otros en transportarlo, esto no es un problema en sí, es una condición. Sin embargo para que este mismo mundo funcione, debe haber comunicación entre las diferentes especializaciones: quien diseña la casa le debe explicar al que la va a construir para que éste pueda hablar con los que hacen el cemento y hacer el pedido exacto, pero eso no implica que quien hace el cemento, deba ser un experto en el diseño y/o construcción de casas.

Lo que me inquieta y me trae a este punto es que en los ingenieros que tenemos que ver con la informática hemos hecho todo lo posible por aumentar la brecha. Hemos vivido desde hace años con la ilusión de ser y hacer como hackers, de usar un lenguaje ininteligible para los “demás idiotas”; soñamos con cuartos oscuros, llenos de módems, computadores portátiles y un montón de geeks hablando de los temas que “realmente importan” (stuff that matters) y absolutamente aislados de ese mundo donde está el monstruo a vencer, ese monstruo que nos hace la vida más difícil con sus preguntas tontas, con su manejo torpe del teclado, con su odiosa indiferencia cuando le hablamos de Linux, ese monstruo que llamamos “usuario final”.

Los ingenieros (al menos los informáticos) somos unos pedantes, somos capaces de presumir con un pregrado y 10 años de experiencia aún sin conocer un pito sobre UML y programación orientada a objetos, nos encanta sentirnos diferentes con nuestro idioma lleno de tecnicismos, nos encanta hablar rápido para hacer que las cosas parezcan más complejas de lo que son, nos encanta el estrés para demostrar cuan importante es lo que hacemos, nos encanta odiar a nuestros gerentes por que no saben nada de programación. Nos encanta despreciar a nuestros usuarios por que no saben lo que se puede hacer con la tecnología, usamos sobrenombres tan divertidos como “el idiota aquel” para referirnos a ellos, creamos caricaturas y usamos nuestro gran ícono universal para representarlos: el pobre tipo o tipa dándole golpes a un teclado a ver si su aplicación funciona. Y lo peor de todo es que nos sentimos orgullosos de ser así, nos mantenemos aislados de lo no técnico, de lo administrativo, del negocio que estamos modelando.

Una de las características de los que desarrollamos software, es mirar con desprecio hacia las estimaciones. Cuando vemos los tiempos asignados para desarrollar un módulo se dibuja una sonrisa maléfica en nuestra boca para recordarle al gerente lo poco que sabe de desarrollo y cuando nos preguntan el tiempo que nosotros estimamos, siempre explicamos lo difícil sino lo imposible que es estimar, es eso, nos encanta retratar nuestro complejo mundo.

Pero no, el usuario no es tan torpe, el gerente no es tan inepto y nuestro mundo no es tan complejo. Es cierto, somos una ciencia nueva, con mucha incertidumbre, con muchas cosas por descubrir e inventar. Estamos en una situación que nos exige humildad, nos exige mirar con cara de niño curioso hacia otras ciencias, nos exige respetar al usuario que es quien más sabe sobre lo que hacemos, por que es él quien lo usa. Debemos acercarnos a él, preguntarle como se siente lo que hicimos, que hay de bueno, que hay de malo; por que el mundo no se divide entre lo que funciona y lo que no. Hay demasiados factores subjetivos que son clave en el éxito de una aplicación, al usuario no solo debería importarle si funciona o no, el usuario es humano y como tal hay cosas que le gustan por que sí o por que no

Sabemos que no se puede garantizar que una nueva aplicación sea 100% libre de errores, los bugs son el pan de cada día y de hecho la ingeniería de software existe para darle mantenimiento a las aplicaciones con errores. Cuando no podemos dar esta garantía, deberíamos por lo menos procurar una experiencia agradable en el uso de nuestros productos, por que no es justo que aparte de soportar una aplicación con errores, el usuario deba usarla y sentirla como el ingeniero lo ordena, no es justo que se sienta idiota por que las operaciones son como las pensó el ingeniero y no como él cree que deberían ser. Claro, eso tampoco debe llevarnos a implementar cuanta cosa se le ocurra a la gente, pero si debería llevarnos a un acercamiento que facilite el trabajo en equipo, dejar de ver a nuestros usuario únicamente como el receptor de lo que hacemos, debemos convertirlo en una ficha clave en lo que hacemos. Debemos hacer que aprenda UML (que para eso se diseñó), que comprenda como se hace una aplicación, debemos escucharlo, quizá la diferencia entre un botón azul o amarillo sea la clave para la aceptación de una nueva aplicación, en fin, debemos darle al usuario la importancia que se merece, seguramente haciéndolo vamos a encontrar muchas de las respuestas que necesitamos para que los proyectos de desarrollo de software fracasen menos, para tener más claridad en el camino a seguir. Al fin y al cabo, ¿Qué es lo que hace que MAC OS sea tan exitoso?, ¿Por qué sus usuarios lo sienten como una religión?, ¿Por qué aunque Linux sea ahora tan fácil como Windows, los usuarios prefieren este último aunque tengan que pagar mucho más?

La Ingeniería de Software siendo una de las áreas que se desprende de las ciencias de la computación, cuenta con un alto nivel de incertidumbre en cuanto a sus metodologías, procesos, disciplinas, etc. Uno de los problemas con los que siempre hemos tenido que lidiar quienes estamos involucrados en el desarrollo de software es tratar de hacerlo un negocio rentable y predecible, por que sabemos que aproximadamente el 70% de este tipo de proyectos fracasan en cuanto a sus costos y tiempos. Esta aterradora cifra nos plantea inmediatamente la pregunta: ¿por qué si es un negocio que genera tantas pérdidas, tiene tantas empresas que siguen empecinadas en invertir en él?

Seguramente la respuesta a esta pregunta no es fácil, seguramente es un negocio que genera tanto pérdidas como ganancias y eso lo hace atractivo. Pero para mí la respuesta es diferente. El software es mucho más que un negocio, es una necesidad real. Jonathan Schwartz's (http://blogs.sun.com/jonathan/) decía hace algunos meses en su Weblog que el software era una industria que estaba jugando un papel similar al que juega el petróleo hoy día: la civilización se está construyendo sobre él. Y esto es cierto, el mundo como lo entendemos hoy no sería posible sin el software, desde hipótesis matemáticas que solo se pudieron demostrar con la aparición del computador, hasta la invención de Internet que ha cambiado nuestra forma de interactuar, trabajar, leer, opinar y hasta jugar y entretenernos.

Estos hechos le dan al software la categoría de IMPRESCINDIBLE, es decir, por más problemas y pérdidas que nos implique su desarrollo tenemos que "lidiar" con él. Para mí esta es la razón por la cual después más proyectos fallidos que exitosos, la industria del software sigue avanzando y las empresas siguen invirtiendo en ella. Seguramente al principio la Ingeniería Civil, mucho antes de llamarse "Ingeniería Civil", tuvo que soportar grandes edificaciones derrumbadas, pequeños sismos que acabaron con ciudades a causa de las malas construcciones y muchos proyectos que tomaban 2 ó 3 veces el tiempo estimado; eso solo se pudo soportar por que es una ciencia imprescindible, por que los seres humanos necesitamos casas para vivir y carreteras para comunicarnos, no importan lo malas que estas sean.

Claro, como esta es una nueva disciplina, nos hemos enfrentado a muchos inconvenientes para llevar a cabo proyectos exitosos. Durante los 90, el modelo de desarrollo de software en cascada fue el paradigma a seguir; había un número de etapas que se ejecutaban una a continuación de la otra, la aplicación se definía en su totalidad y luego se implementaba, igualmente, en su totalidad. Este modelo aunque parece ser que funcionó bien al principio, hizo que nos restregáramos en la cara el dinamismo y la incertidumbre de los negocios que teníamos que implementar, fue descubrir que era poco menos que imposible definir completamente un negocio antes de implementarlo. Esto ocurre bien sea por que los encargados del negocio no lo tienen claro, por que el mercado cambie las reglas del juego, por que esté regido por normas del estado que pueden cambiar en cualquier momento o simplemente por que los clientes no saben exactamente lo que quieren.

Pero los únicos inconvenientes del desarrollo no son por la incertidumbre en el negocio, la tecnología también trae muchos problemas implícitos: enfrentarnos a nuevos lenguajes de programación, frameworks o bases de datos con los que no tenemos experiencia o peor aún, no han sido probados en el dominio del negocio; también siempre hay problemas de integración entre módulos o integración con sistemas heredados (legacy); el rendimiento de las aplicaciones, la infraestructura de la red, la diversidad de sistemas operativos, etc. son factores que silenciosamente pueden llevar al fracaso. La innovación tiene un precio, y es muy alto.

Para mí esta situación es poco menos que aterradora: nunca tenemos claro lo que vamos a implementar y tampoco estamos seguros si va a funcionar.

Ante esta situación angustiante, salieron al rescate las metodologías iterativas. Donde se siguen pasos similares a los del modelo en cascada, pero se hacen una y otra vez sobre los diferentes módulos de la aplicación. Estas iteraciones mitigan inteligentemente el riesgo de lo desconocido, seleccionando en una etapa temprana del proyecto un caso de negocio a implementar y con el cual se hace una prueba de todo el proceso a seguir, la tecnología a implementar y se entrega rápidamente al usuario una "muestra" de lo que va a ser el sistema, aterrizando de esta forma las expectativas y trabajando sobre la base de un producto real. Si la primera iteración complace al cliente y al equipo de desarrollo, se continúa con otra iteración seguramente más grande, pero con la confianza de ambos bandos: hay una idea general y clara de lo que se está haciendo.

Además hay otro factor clave para el éxito de esta metodología: el cambio es algo natural dentro del proceso. Esto quiere decir que un cambio en los requerimientos no va a tener el impacto que tiene cuando se usa una metodología en cascada y es que para eso están diseñadas las iteraciones, para construir nuevos módulos y para refinar los que ya están construidos, por que otro mito que se derrumbó es el de tener módulo perfectos en un solo tirón.

Después de haber estudiado sobre el modelo iterativo, sobre todo RUP, me queda claro que una aplicación nunca está completamente terminada, con el desarrollo de software ocurre lo que le ocurre a cualquier artista con su obra: nunca la termina, siempre habrá algo que no nos gusta y que puede ser mejorado. Esto hace parte de la naturaleza humana.

Hay una gran pregunta que me queda dando vueltas:

¿Qué tan seguro es definir e implementar una arquitectura y tomar decisiones basados en una pequeña parte del problema?
¿Aplica acá la ley de Pareto? ¿El 20% de la funcionalidad me mostrará el 80% de lo que va a ser el proyecto?

Pero a pesar de todas las dudas, estoy encantado con los modelos iterativos. El mundo del software nos ofrece demasiados enigmas que pueden ser descubiertos en su mayoría con una pequeña implementación temprana y hay que olvidarnos de las implementaciones perfectas para empezar a pensar en productos imperfectos que siempre deben ser mejorados.

Por estos días con todo eso de el cambio y de la ingeniería de software estoy estudiando "Object Oriented Análisis and Design with Applications" de Grady Booch y compañía. Estoy empezando y es casi un viaje cósmico, Booch es de los que sabe lo que dice en cuando al diseño y construcción de software.

Pero lo que más me ha gustado es esta joya, no la traduzco por que sería vulgar:

El último año de mi vida ha tenido cambios brutales, la palabra es muy aparatosa, pero es cierto.

La cosa empezó hace un poco más cuando empecé a programar en Cobol para la empresa en que trabajaba. El paso de Java a Cobol no fue muy bien visto, para muchos era un retroceso, significaba devolverse como 15 ó 20 años en tecnología y dejar de pensar en clases, paquetes, objetos, Web, etc, etc.

La verdad es que me estaba hartando de Java, no de la tecnología, sino de lo que había en torno a ella. No parecíamos programadores de un lenguaje, eramos más bien un montón de fanáticos religiosos donde lo mejor de Java es que era Java. Sin muchos argumentos, sin preguntarnos mucho de nada, leyendo siempre javaHispano, TheServerSide, java.net y todas las páginas en las que solo se habla de Java, aprendiendo a defendernos de "Los Otros", los programadores de .NET, pero defendiéndonos sin conocer esa plataforma, defendiéndonos con lo que nos daban las noticias de javaHispano y los objetivos "BenchMarks" de TheServerSide. Era claro para mí que necesitaba un cambio.

Programar en Cobol fue una experiencia bastante loca, dejar de pensar en términos de clases, ver algoritmos con 20 ó 30 mil líneas y empezar a entender las bases de datos jerárquicas era como cambiar de mundo, cambiar de trabajo, eso sí, el negocio era similar, por que fue bien divertido ver como soluciones que en el mundo de los objetos y las arquitecturas multicapas llevaban varias semanas de implementación, en Cobol tomaban apenas unas horas. Claro, lo contrario era mucho más común.

Los meses que duré como programador Cobol fueron rejuvenecedores, me mostraron un mundo que no conocía y sobre todo entendí por que muchas de las cosas son como son ahora, jeje, por ejemplo el impacto que tiene sobre la legibilidad de un programa el poder declarar variables en cualquier punto o el tener que declararlas todas al principio, es mucho más de lo que uno se imagina o por lo menos fue muchísimo más del que yo me imaginaba.

Durante mi "estadía" en Cobol descubrí algunas cosas que hacían falta en el proceso que seguíamos. Una de esas cosas que hacían falta era un IDE que permitiera agilizar el trabajo y detectar algunos problemas que el compilador no detectaba, aunque busqué bastante, no encontré mucho, de hecho nada. Aprovechando que tenía la energía suficiente para trabajar 14 horas al día me puse en la tarea de desarrollarlo. No fue algo maravilloso, pero si que resolvió numerosos problemas, de paso conocí el entorno de NetBeans 5 para aplicaciones Swing y ya entrado en gastos, usé parte del tiempo para estudiar y certificarme como programador Java. No tengo idea como hice para que el tiempo fuera suficiente en ese entonces, solo se que cuando más tareas tenía por hacer, mucho mejor era usando los recursos con que contaba (tiempo, espacio y hasta dinero).

Después a causa de algunos movimientos clave en la empresa pasé al área de investigación y desarrollo, donde apenas duré unos días por que llegó una nueva propuesta de trabajo que tomé, claro, después de meditarlo mucho.

Entré al mundo SAP en un proyecto que se trataba de instalar y personalizar el portal integrándolo con el CRM y la tienda en línea. Algo bien interesante y diferente con respecto a lo que había hecho hasta el momento. Aprendí bastante sobre sistemas integrados, su filosofía, sobre CRMs, tiendas en línea, ABAP y todo lo que pude en los 4 meses que estuve en el proyecto.

Ahora estoy en una nueva ciudad, lejos de mi mundo conocido y entendiendo todas las cosas de las que nunca quise entender por que siempre creí que "lo mio" era ser muy técnico, usar un lenguaje ininteligible para los gerentes, estar encerrado en un garaje con un pc y unos manuales de referencia tipo biblia, tomando café y trabajando hasta la madrugada. Pero no, para eso es la vida, para demostrarle a uno que casi todo lo que creía era mierda, que antes de los 60 no hay criterio para tomar decisiones y que definitivamente la casualidad es la que me guía. No nací para nada, hago lo que haya por hacer y casi todo me gusta. Hago lo que hago por pura casualidad, soy ingeniero de sistemas por que para ser electrónico hubiera tenido que viajar mucho y a mis papás en mis 17, les parecía exagerado eso sabiendo que habían tantas otras cosas por estudiar.

Hoy estoy aprendiendo sobre todo lo que tiene que ver con ingeniería de software, todas las etapas de un proyecto, donde la programación y el desarrollo solo ocupan a lo sumo una tercera parte del ciclo. Ahora lo mío es entender como gestionar un proyecto, ahora lo mío es leer "The Mythical Man-Month" y entender como funcionan los equipos de trabajo, como disminuir el riesgo en un proyecto de desarrollo. Ahora lo mío es sentarme con un usuario y entender como siente, que quiere, ponerme de acuerdo con él y asegurarme de que los dos pensemos lo mismo cuando planteamos una solución. Ahora estoy en un mundo donde la cosa es más un arte que una ciencia exacta, donde no hay soluciones exactas, donde no hay bueno y malo sino lo uno y lo otro. Ahora estoy entendiendo por que UML sí es importante y sobre todo por que los casos de uso en verdad fueron una revolución en su momento, entendiendo que no se trata de los pinches gráficos, que no se trata de hacer bien el muñeco y que los círculos cumplan con un montón de reglas estrictas, donde no importa si tengo que comunicar dos muñecos para entender mejor el funcionamiento del sistema. Donde ahora UML y Java en verdad son herramientas, ya no defiendo las cosas religiosamente, ya no puedo hacerlo.

Eso si me ha gustado de el cambio, que me ha restregado lo equivocado que me mantengo y como es que el mundo no funciona dentro de una cuadrícula.

Finalmente lanzan Windows Vista y solo les tomó 5 años, 7000 millones de dólares y unas cuantas promesas sin cumplir.

¿En qué demonios piensa Microsoft?
Al parecer han dado un gran paso creando una versión según la clase social.
Gracias Linux por existir, para lo demás (jugar?) está XP.

Dado que no había nada que escuchar en la radio, durante el viaje a casa empecé a dar vueltas por todo lo que había en FM, al final me encontré en una extraña entrevista de un argentino (creo por su acento) que había venido a la Universidad de Antioquia (creo) a dar algún seminario sobre Platón; en medio de la entrevista tocaron un tema que me llamó la atención: La Dialéctica.

Alguna vez en la universidad tuve que hacer una exposición sobre este tema y lo único que me quedó por entonces es que la dialéctica constaba de tres partes, estados o etapas: una tesis, una antítesis que contradiga la tesis y al final se formula una síntesis que resuelve la contradicción. Este proceso por ejemplo, es ampliamente conocido por los políticos quienes deben asistir a debates y defender sus tesis de las contradicciones de sus contendientes u opositores.

Me disculpo con los conocedores del tema por que a lo mejor no estoy dando información exacta, pero repito que esto fue lo que me quedó de aquella exposición en la universidad.

Volviendo al programa que escuchaba en la radio, recuerdo que me gustó mucho una de las opiniones del expositor en donde contaba que la dialéctica no solo servía para defender argumentos sino para aprender a fortalecer las tesis a partir de las contradicciones de los demás, es decir, aprender de la crítica.
Esto me hizo pensar en lo inútil que se me antojan últimamente algunas "discusiones" en la web, donde nadie aprende nada, nadie enseña nada, solo se trata de un montón de ególatras mostrando lo que saben a los demás que a su vez se "defienden" mostrando lo otro que saben ellos pero no los demás. Aquí no hay espacio a la discusión, es más bien un montón de retazos de opiniones con el que no se puede hacer nada, a lo sumo una colcha.

En una buena discusión cualquiera de sus actores debe consciente que puede estar equivocado, que su argumento tiene puntos flojos que seguramente otro notará y lo hará saber, que hay cosas que no sabe y se las van a enseñar; con todo esto seguro que la tesis con que se empieza cambia pero para mejorar, para llenar esos "agujeros" para los que no había respuesta.
El problema de estas discusiones de Internet es que todo mundo se va con lo mismo que llegó y de hecho ese es el objetivo, imponer mi verdad a como de lugar. Como si usar un argumento del otro para fortalecer el mío fuera una señal de debilidad o de ignorancia, como si fuera necesario mostrar lo valiente que se es sometiendo al otro a lo que pienso. La crítica deja de ser tomada como tal, la han convertido en cañonazos que se deben esquivar y aún mejor si se pueden lanzar de nuevo para herir al "adversario".
Y eso que todo lo anterior es al máximo punto donde se llega, a la "colcha de retazos", por que en muchas ocasiones todo se queda en una horda de "insultadores profesionales" (como diría Daniel Samper) que solo logran hacer que varios cerebros se vayan hartos de la web 2.0 por que después de tantas promesas, solo aprendieron que cuando todo el mundo tiene boca para opinar, la mayoría la usa para escupir.

Esperemos a ver si con los wikis podemos hacer algo más constructivo.

La semana pasada sacaron del aire la última emisora que sonaba rock en esta ciudad, hemos perdido la guerra contra el horrendo reggaetón (o como esta aberración se escriba), el vallenato y los ritmos tropicales; soy colombiano y me siento más o menos orgulloso de ello, de hecho, no me haría sentir muy orgulloso ser de alguna nacionalidad en especial, no soy de los que gusta del crédito ajeno; el punto es que a pesar de ser latinoamericano de la zona del Caribe no me gusta ninguno de los ritmos populares por estos lados: reggaeton, salsa, vallenato, merengue, etc.

La música para mí ha sido siempre algo fundamental, la necesito todo el tiempo, me gusta conversar de música con mi novia, amigos y cualquiera que esté dispuesto a hacerlo; de vez en cuando compro CDs a pesar de poder descargarlos vía emule, hay muchas canciones que erizan mi piel y es un factor muy importante para cualquier tipo de relación que vaya a entablar con alguna persona (amistad, amor); por ejemplo no podría tener una relación sentimental con alguien cuyo tipo de música favorito sea el vallenato; tampoco soy capaz de ser gran amigo de un reggaetonero, esa es una línea que no deseo cruzar.

Por eso puedo decir ahora abiertamente que aunque hasta hace poco respetaba cualquier género musical, odio el reggaetón y el vallenato. Una cosa es respetar y que haya espacio para cualquiera en este mundo, pero cuando empiezan a quitar el rock para poner más y más reggaeton, de verdad, como dicen los españoles, me están tocando los cojones.

Ya hace varios días que escribí esto, justo cuando la sección de weblogs estuvo caída. Igual lo publico, a lo mejor de algo sirve.

Es muy poca la experiencia que tengo instalando y configurando Linux, sin embargo instalé muy facilmente la versión de Kubuntu 6.06 a 64 bits en mi computador portátil. Escribí anteriormente que algunas cosas no funcionaban y que aún faltan cosas por configurar para decir que tengo un Linux "bien montado"

MP3 y Multimedia
El primer problema visible fue cuando intenté reproducir algunas canciones en formato MP3, ninguno de los reproductores multimedia logró hacerlo. Pensé que era un problema de instalación y dado que esta fue tan sencilla, decidí hacerlo de nuevo; seguí los mismos pasos, usé las mismas particiones e hice el proceso rápidamente con la ilusión de obtener resultados mejores, sin embargo el problema con la reproducción de MP3 continuaba. Más tarde me di cuenta que no se trataba solo de el formato MP3; los videos en formato MPG mostraban la imagen pero no había nada de sonido.

Una búsqueda sencilla en google me arrojó los resultados con las respuestas que necesitaba: resulta que los códecs para reproducir MP3 se deben descargar desde su página oficial y no pueden ser distribuidos por terceros (como quienes distribuyen Kubuntu). Por esto es que no vienen en el cd de instalación. Aún así es posible instalarlos con un ?apt-get?. No se si existe el mismo problema con el resto de formatos multimedia pero si hay que seguir un proceso similar y hay una página oficial de Ubuntu con información detallada sobre el tema: https://help.ubuntu.com/community/RestrictedFormats.

Finalmente todo se reduce a una actualización que se hace via internet con "apt-get install [librerías]", algo simple cuando todo funciona bien.

Actualizaciones con APG-GET
Me puse en la tarea de instalar las librerías pero no lo logré por que al parecer el ?apt-get? no estaba funcionando, no había ningún mensaje de error, solo mostraba ?Reading package lists ... Done?. Estaba conectado a través de la red de mi trabajo y me dí cuenta que no había configurado el proxy, así que lo hice a través de simples variables de entorno: export http_proxy="http://laurl:elpuerto" export ftp_proxy="ip:puerto"

Intenté de nuevo hacer un "sudo apt-get update" pero obtuve los mismos resultados: "Reading package lists... Done". Encontré algún sitio donde decían que era necesario modificar el archivo /etc/apt/apt.conf y configurarle el proxy http y ftp; lo hice tal como indicaban pero tampoco funcionó.

No creía que fueran problemas de conexión, pues a través de Konqueror pude navegar en internet únicamente configurando el proxy.

Emulación a 32 bits
Como no pude instalar las librerías via apt-get, busqué en internet algún sitio de donde pudiera descargarlas y me explicara como realizar la instalación teniendo los archivos en mi máquina. La cosa no mejoró al ver que algunas de las librerías no estaban compiladas a 64 bits. Él único camino a seguir es instalar un emulador de 32 bits y luego descargar las librerías, de todas formas es necesario hacerlo para ejecutar las aplicaciones hechas en Java, pues aún no hay una implementación a 64 bits de la máquina virtual para Linux.

De nuevo navegando en la red, he hallado un buen manual para instalar el emulador de 32 bits en un Ubuntu de 64: http://en.jakilinux.org/linux/ubuntu/kubuntu-606-on-athlon-64/; el asunto no pinta sencillo y dado que no me funciona el apt-get ni tengo conocimientos medianos sobre Linux voy a tener que aprender y arreglar el resto de cosas de mi máquina antes de hacer esta instalación.

El Problema
El problema es claro: ?No conozco Linux?. Además esta configuración del sistema operativo a 64 bits tiene muchas cosas para las que creo no basta ser un aprendiz del tema; es necesario conocer bien el sistema de paquetes para no tener conflictos con las librerías de 32 bits que se deben instalar para que las emulaciones funcionen; tengo que aprender que hace el ?apt-get? para arreglarlo o por lo menos saber por que no funciona. Esto antes de intentar la endemoniada instalación del emulador para 32 bits.
¿Qué aplicaciones hay estables para 64 bits? ¿Estará la mayoría de lo que necesito? ¿Qué necesito?
Estas son preguntas que me debo responder antes de continuar; estoy tan encantado con Linux que dificilmente opte por dejarlo a un lado. Más bien creo que voy a leer unos cuantos ?Linux para dummies?, buscar en las guias oficiales y como siempre preguntarle a quienes tengan más experienca que yo en esto, solo así estaré listo para el gran paso al mundo de 64 bits.

Comenté en mi post anterior mis intenciones de instalar una versión de Linux a 64 bits para aprovechar mi procesador y ver de una vez por todas cual es la diferencia con las aplicaciones actuales a 32 bits. Pensé en una versión de Linux, por que me han dicho que el Windows XP actual a 64 bits no anda bien y hay muchos problemas de drivers. Me imaginé que el asunto de los drivers iba a ser igual o muy similar en Linux, pero si he oído que la estabilidad es impresionante y es sabido que hace ya varios años existen versiones estables para plataformas de 64 bits.

Justo cuando acababa de descargar la imagen de Kubuntu 6.06-AMD64, ha llegado a mis manos el pedido que hice hace poco más de un mes: 10 cds de Kubuntu 6.06. El pedido llegó con 8 cds para pc de 32 bits y dos para AMD64; dada esta casualidad me decidí a instalar la versión de uno de los cds que acababan de llegar, no fuera a ser que la descarga hubiera fallado y la presentación del CD, aunque no es tan bonita como la anterior, hace que den ganas de instalarlo :-). Por cierto, esta nueva versión trae un solo cd que sirve para ejecutarla en vivo (CD-Live) y como instalador, a diferencia de la anterior (5.10) que traía por separado cada una de estas opciones.

La instalación es un proceso sencillo: arrancar la máquina desde el CD de Kubuntu y al terminar de cargar el escritorio de KDE hacer clic en el ícono de instalación que aparece solo en la esquina superior izquierda. Es un instalador muy similar al los asistentes para Windows, incluso más sencillo; la única parte complicada para un usuario super-novato (yo soy novato y lo hago fácilmente) puede ser configurar las particiones; el instalador por defecto da la opción de formatear una unidad y hacer todo automáticamente o también hay una opción para que el usuario se encargue de hacerlo. Yo lo hice de forma manual por que deseaba mantener instalado el XP Profesional que vino preinstalado, ya sabemos como es esto de no tener Windows a la mano; también hice una partición FAT32 para mantener datos compartidos y escribir en ella desde ambos sistemas operativos sin riesgos de perder información. La única duda que tuve, fue la partición swap, pues teniendo 2 gigabytes de RAM no es muy factible que se llegue a usar una gran cantidad de memoria virtual, pero el instalador me decía que mínimo debía dejar 256 mb y he leído recomendaciones donde la ésta debe ser proporcional a la cantidad de RAM, al fin dejé 1 gigabyte de los 100 que tiene mi disco duro para swap. No tengo ni idea si esto será lo adecuado, pero al menos la instalación se ejecutó exitosamente y en tan solo unos 20 minutos.

Al reiniciar la máquina ésta arrancó sin problemas y rápidamente. Me puse pues a escribir esta pequeña experiencia como me lo había prometido en mi post anterior y mientras escribía quería escuchar un poco de música. Como reconoció sin problemas la partición de mi Windows XP fui a buscar mi carpeta de música para seleccionar algunas canciones en mp3 y cual fue la sorpresa cuando ninguna de las aplicaciones para procesar multimedia fue capaz de reproducirlas. Igual me sucedió a reproducir un video en formato mpg, la imagen se veía bien pero no había nada de sonido.

Traté de solucionar esto con un ?sudo apt-get udpate? que recomiendan para hacer una actualización, pero la operación no hizo nada, no hubo mensajes de error; fue más bien como si no hubiera encontrado nada que actualizar y no supe que era. Traté entonces de arreglar el sonido por ?System settings?, pero de hecho cuando ingreso al módulo de sonido y multimedia, hago el test y los parlantes suenan bien. El problema al parecer tiene que ver solo con la reproducción de videos y mp3.

Como se puede ver hay que ?pelear? bastante para instalar Linux en estos portátiltes que vienen hechos para que funcionen en Windows; el resto de problemas, como la instalación de Java, tienen que ver con los programas a 64 bits y la necesidad de un emulador para porderlos ejecutar.

Espero solucionar pronto estos problemas y poder escribir algo al respecto. Por ahora esto es todo lo que se puede contar.

Saludos.

Finalmente y después de algo así como 20 días de espera, estoy escribiendo desde mi nuevo computador portátil. Se trata de un "Acer Aspire AS5003WLMi-XPH" (vaya nombre), una máquina con un buen precio (lo que no siempre es bueno), y con muy buenas especificaciones para mi gusto: un procesador AMD Turión de 1.8 gz, por supuesto a 64 bits; dos gigabytes de memoria RAM (la versión oficial viene con un solo giga), disco duro de 100 gigas, lector/quemador de DVD, etc. el resto se puede ver en las especificaciones de la página de Acer.

Lo poco que he probado indica que es un buen equipo, aunque debo instalar un sistema operativo de 64 bits si quiero ver de verdad lo que es capaz de hacer. Justo ahora estoy descargando la nueva versión de Kubuntu (6.06) para instalarla este fin de semana y veremos como marcha la cosa, aún no conozco ningún pc de escrtorio/portátil con un SO a 64 bits, así que me intriga demasiado como será esto, estoy seguro que no me voy a decepcionar.

Estoy escribiendo este texto en OpenOffice 2.0 (para luego pasarlo al weblog), tengo dos instancias de EasyEclipse Server Java 1.0.2 abiertas, edito algo en Netbeans y tengo tomcat arriba; también escucho un agradable disco de Killers. Según Windows hay un consumo de 515 Mb de RAM y el procesador marcha sin problemas. Solo me molesta un poco el asunto del calor, siento que el touchpad se calienta más de lo que debería y por debajo calienta lo suficiente como para dejarme estéril. El touchpad lo puedo reemplazar, y lo haré, con un mouse; el asunto de la esterilidad debo meditarlo bien, a lo mejor un ventilador que nos refresque un poco sea la solución.

Prometo escribir de nuevo cuando haya instalado (bien o mal) Kubuntu y a lo mejor hasta hago mi aporte para linux-on-laptops.com.