lunes, abril 02, 2007

El Espejo

En su libro "El Fenómeno Humano" (Taurus Ediciones, 1967, página 44), el Padre Teilhard de Chardain dice:
Llegados al extremo de su análisis, [los físicos] ya no están muy seguros de si la estructura conseguida es la esencia misma de la Materia que estudian o el reflejo de su propio pensamiento. Y de una manera simultánea se dan cuenta de que, por un choque retroactivo de sus descubrimientos, ellos mismos se hallan cogidos en cuerpo y alma en la red de las relaciones que habían creído lanzar desde el exterior sobre las cosas; en una palabra: se hallan presos de su propia trampa. Metamorfismo y endomorfismo, diría un geólogo. El objeto y el sujero se mezclan y se transforman mutuamente en el acto del conocimiento. Quiéralo o no, desde ese momento, el Hombre vuleve a encontrarse a sí mismo y se contempla en todo lo que observa.

El límite de nuestro conocimiento es un espejo en el que mejor nos vemos cuanto más nos acercamos. Y detrás, lo inexcrutable. Lo que vemos es lo que somos, y somos lo que vemos.

viernes, marzo 23, 2007

Gato

Una casa sin un gato, un bien alimentado, bien cuidado, bien reverenciado gato, puede ser una casa perfecta, pero ¿cómo puede llegar a demostrarlo?
Mark Twain

martes, marzo 20, 2007

TSLOC

En su artículo "Cracking Software Reuse", Diomidis Spinellis comenta algunos aspectos relativos a la reusabilidad del software, del que se ha dado en conocer "de grano gordo" o coarse-grain reuse. Describir una extensión no inherente a MediaWiki (el motor de Wikipedia) que permite la representación de tableros de ajedrez combinando elementos como tablas html e imágenes entre otros, le sirve para desvelar algo de lo que pocas veces somos conscientes:
Digging deeper, we’ll find that MediaWiki consists of about 175,000 lines of PHP (PHP: hypertext preprocessor) code using the MySQL relational database engine. A rough count of C/C++ source code files in the PHP and MySQL distributions gives us 740,000 and 1.8 million lines, respectively. And underneath, we’ll find many base libraries on which PHP depends, the Apache and Squid server software, and a multimillion-line-large GNU/Linux distribution. In all, we see a tremendously complex system that lets hundreds of thousands of contributors cooperatively edit two million pages—and still manages to serve more than 2,000 requests each second.
(en: Diomidis Spinellis, "Cracking Software Reuse," IEEE Software, vol. 24, no. 1, pp. 12-13, Jan/Feb, 2007).

Lo que sorprende es que todo esos trillones de líneas de código fuente (TSLOC) den soporte a un grupo de personas para elaborar una plantilla que permite mostrar un tablero de ajedrez. Marea pensar la complejidad conjunta de todos esos sistemas, y la manera en la que han sido integrados entre ellos. Cómo dice Spinellis, we should be doing something right.

miércoles, marzo 14, 2007

Martin Fowler

Indudablemente, uno de los ingenieros software que más me ha influido ha sido Martin Fowler. Su forma de razonar un diseño, su manera de expresarlo, y los ejemplos de código presentados para ello han hecho mella en mí.

viernes, febrero 23, 2007

Búsquedas web en el contexto de intereses personales

¡Parece que me han oido! Investigadores de la Universidad de Utah están trabajando en un sistema de búsqueda contextual, basada en intereses personales. Todavía no he leido el artículo (sólo el abstract), pero puede resultar interesante. Si veo que es interesante lo comentaré aquí.

martes, febrero 20, 2007

Information overflow

Llevo unos días probando Google Reader, la herramienta de Google para leer los feeds de atom y rss. La verdad es que está bastante bien, sobre todo porque aplica un concepto conocido (mi buzón de entrada) a un concepto nuevo (una lista de actualizaciones realizadas en un blog). Eso creo que lo hace más fácil de usar.

Sin embargo, no quiero entrar ahora en ese tema. Lo que me trae hoy aquí es que vuelvo a sufrir (otra vez) eso que llaman information overflow. Vamos, que ando saturado de información, demasiada información. No es que sea inutil, es que es demasiada. En esta disyuntiva, se me vienen a la cabeza algunas alternativas. La primera de ellas es cortar de raiz... Si tienes un feed que te ofrece más de 10 enlaces al día, te has equivocado de feed. Lo mejor, es quitarse de encima el feed. Es casi como spam... Es insufrible...

Pero claro está, ¿qué voy a hacer si pierdo, de entre esos 10 enlaces diarios, el que me resuelve el problema de mañana, el que me hace cambiar mi manera de pensar y me hace entrar en un nuevo estado mental, el que necesito para entender por qué las cosas funcionan en el mundo como lo hacen? La solución de cortar por raiz, es muy efectiva, pero no muy eficiente. Lo ideal sería poder filtrar el contenido. ¿Lo que me gustaría? Una herramienta que fuera capaz de ir "aprendiendo" de los artículos que me gustan, de los que leo, de los que desecho... Que analice la metainformación de la información que me llega, y deduzca si el artículo va a ser relevante o no... Lo que yo quiero es una función consumir(informacion) que devuelva un booleano indicando si debo leer/usar/procesar esa información... Mejor, una función consumir2(informacion) que devuelva un entero, indicándome la relevancia de la información. De esa manera consumir(informacion) = consumir2(informacion) > umbral, donde yo pongo el umbral. "Hoy sólo quiero información con umbral = 1", por ejemplo...

También es cierto que una función así, si funcionara como se espera, me iría etiquetando, de forma que sería muy difícil que pudiera decidirme en un momento dado a explorar otros caminos, con umbral < 0,5. En fin, que hoy por hoy, voy a hacer yo de función consumir, y utilizaré como información las cabeceras de los artículos de los feeds.

Feliz navegación.

viernes, febrero 09, 2007

La junta de la trócola

Para persistir la información de una aplicación, usamos un framework de persistencia, desarrollado por nosotros, pegando trozos de distintos libros y artículos, en una especie de framekenstein de software. Como en la mayoría de los frameworks, impera el principio de inversión de control o Principio de Hollywood. Para ello, creas una clase que hereda de otra base en el framework, e implementas los métodos que necesita la clase base.

Si existen muchas clases que heredan de una de esas clases del framework, cambiar esa clase puede ser un problema. En nuestro caso, nuestas clases heredan de un Data Mapper (más información aquí), llamado BrokerSql.
class ClienteBroker : Servicios.Persistencia.BrokerSql {...}
Si mañana decidimos hacer que las clases hereden de otras, tendríamos que ir clase por clase cambiando el nombre. Tampoco es que sea mucho problema, pero ¿qué tal si hacemos esto?
class JuntaTrocolaBroker: Servicios.Persistencia.BrokerSql {...}
y luego
class ClienteBroker: JuntaTrocolaBroker {...}
Bueno, la verdad es que esto es más una comida mental, porque estoy asumiendo que el día que en vez de heredar de BrokerSql heredemos de BrokerXml, los métodos a implementar por ClienteBroker serán los mismos, que seguro que no es el caso, ni siquiera en los valores devueltos, pero en fin, estoy en plan brainstorming, por si a alguien le sirve directamente, o para generar otra idea.

martes, diciembre 12, 2006

El Programa

¡Cuántas veces nos dejamos guiar por el programa que hemos construido desde nuestra educación, nuestra sociedad, nuestra manera de ser o nuestras costumbres! Y los "nuestros" de antes no son malos, simplemente son. Pero en ocasiones, merece la pena, levantar el pie del acelerador, quizá incluso apretar un poco el pedal del freno y mirar mejor por dónde vamos. O mejor, mirar mejor cómo nos conducimos. Y veremos que muchas veces no es que las señales estén equivocadas, o que lo estén las normas... Lo que parece que está equivocado es el camino que estamos siguiendo...

miércoles, septiembre 06, 2006

Estética

Otro pensamiento medio cocinado.

Cada vez creo más en la importancia de la estética en la informática. No me estoy refiriendo (únicamente) a la interfaz del usuario, la característica más visible del software, o al menos la de público más amplio. Me estoy refiriendo sobre todo a la estructura interna, la arquitectura, el uso de patrones, el estilo del código, los nombres de las variables, los diagramas de bases de datos, los diagramas de clases, la claridad de la descripción en los casos de uso...

En ese sentido, creo que otras ingenierías artísticas (o artes ingenieriles), como por ejemplo la arquitectura, tienen mucho que ver con la informática. Conceptos como los de simetría, repetición, coherencia (integridad conceptual, The Mythical Man-Month, Brooks), etc. los veo fácilmente aplicables a la ingeniería del software.

Creo además que incluso la literatura nos puede ayudar (Knuth). El desarrollo de software tiene que ver mucho con escribir un buen libro, o crear un edificio.

Una pequeña nota. Cuando antes hablé de repetición, no me refería al modelo de reusabilidad de código que denomino copypaste (es decir, si este código me vale, lo copio, y lo pego en mi proyecto con pequeñas modificaciones), sino más bien a la inteligibilidad que otorga que lo que es conceptualmente igual se refleje de la misma manera en el código (Añadir y Agregar son sinónimos, pero en un código estético sería imperdonable utilizar en unos sitios un identificador, y en otros sitios el otro.

Me gusta la idea, creo que reincidiré en ella.

viernes, abril 21, 2006

Formación rentable

Últimamente estoy muy influenciado por ciertos pensamientos de índole económica. Los culpables son Barry Boehm, y su libro "Software Engineering Economics", Kent Beck con su "Extreme Programming Explained" y algunos compañeros del trabajo, que justifican sus decisiones técnicas y no técnicas en términos de inversión, rentabilidad, retorno, valor, ingreso, gasto o beneficio.

Como siempre a la hora de tomar una decisión, tener el máximo de información es bueno, y tener máximo de información de un sólo aspecto es malo. Así que es lógico tener en consideración tanto los aspectos económicos como los técnicos, los psicológicos, los éticos o los sociológicos, por poner algunos ejemplos. Pero me estoy desviando del mensaje original.

Parafraseando la presentación de los eXpedientes, "el conocimiento está ahí fuera", y es enorme (entiende uno la importante labor de los bibliotecónomos y los archiveros). La pregunta es ¿qué conocimiento me interesa aprender? que es una pregunta similar a la que se hace un eNavegante mientras explora la Red: "De todas las páginas que puedo ver, ¿cuáles me interesan más?".

Pues nada, aplicamos conceptos económicos. Aquellos que puedes aprender una vez (inversión) y aplicar muchas veces (retorno). Además ese conocimiento debe ser útil para los demás, no necesariamente para tí, aunque deberías poder disfrutar aprendiendo de él (el aprendizaje es más eficaz si te gusta lo que estudias, eso lo sabemos todos). Para que puedas aprenderlo una vez y aplicarlo muchas (read once, write many ;-), el conocimeinto no debe "degradarse" con el tiempo, es decir, debe ser un conocimiento que no dependa de aspectos pasajeros (por ejemplo, enfoca en principios universales de diseño software, en vez de en la última versión del HackerMasterDeveloperEnvironment Professional Edition, que tiene muchas probabilidades de tener una próxima versión en la que cambia casi todo). Además, con el tiempo, aprender cuesta más, y es lógico que pasados unos cuantos años, alguien con más tiempo y habilidad que tú, con el cerebro más avispado te adelante con la última tecnología... Empleate en los fundamentos, en los conceptos, en los principios, en la base... Y mejora tu habilidad para aplicar esos conocimientos.

lunes, marzo 06, 2006

Pruebas

Hoy he probado a probar. He instalado la última versión de NUnit (la 2.2.7) y he decidido probar con uno de nuestros proyectos. La experiencia ha sido intensa para ser la primera vez que intentaba probar un sistema real ya construido (algunos me dirán, con razón, que eso debería haberlo pensado antes, pero equivocarse es una buena manera de aprender).

Bueno, pues sólo por haberlo intentado, ya me he encontrado con ciertas dificultades, que me han servido para reflexionar un poco y llegar a algunas conclusiones.

Diseña para probar
La primera es que el sistema tiene que estar diseñado para ser probado. Es muy difícil probar un sistema que no está pensando con el proceso de pruebas en mente. Los criterios de acoplamiento y cohesión son en mi opinión de especial importancia, y tener este proceso presente favorece su aplicación. En particular, disponer de clases poco acopladas facilita el diseño de los casos de prueba al no ser necesario simular demasiadas de esas clases. Para ilustrar esta reflexión y las siguientes, voy a describir el caso particular que me llevó a ellas.

El sistema es una aplicación web con arquitectura en tres capas (presentación, lógica y datos) con sus funciones habituales. Ciertas operaciones usadas habitualmente por varias clases de la capa de presentación fueron recogidas en varios métodos de clase. Una de estas funciones determina si la IP del navegador pertenece a la red local o no. Su signatura tal y como estaba programada en un principio es la siguiente (Visual Basic.NET):
Public Shared Function EsIPInterna() As Boolean
:
El principal problema era que ¡no recibía ninguna dirección IP! Examinándo el código, comprobe que la dirección IP se obtenía de la cabecera HTTP enviada por el navegador:
:
Dim direccionIp As String = Request.ServerVariables("HOST_ADDRESS") 'O algo así
:
La función dependía internamente de un objeto disponible en el contexto del Internet Information Server de Microsoft. Las pruebas deben ejecutarse en un entorno que desde luego no es el IIS y en el que por tanto no tenemos acceso al objeto Request. Para salvar este primer inconveniente, modifiqué la signatura de la función de esta forma:
Public Shared Function EsIPInterna(ByVal ip As String) As Boolean
:
Y a continuación, cree una nueva función que permitiría no modificar el resto del código:
Public Shared Function EsIPInterna() As Boolean
   Return EsIPInterna(Request.ServerVariables("..."))
End Function
La primera función me permitiría pasar varios argumentos a la función y poder probarla. Lo dicho, las pruebas tienen que estar siempre presentes en el proceso de diseño y construcción.

Prueba la reusabilidad
Como segunda reflexión, he percibido que el proceso de pruebas puede favorecer la reusabilidad. En efecto, el obligar a probar una u otra función con un juego de datos que cubra por ejemplo el criterio de pruebas de caja negra obliga a exponer aquellos parámetros que sean necesarios para ejercitar el código. Esta exposición En otro caso, el sistema debe cambiar para adecuar las pruebas. Mejor hacerlo entonces desde el principio. Lo hemos visto en el caso anterior. La función EsIPInterna que recibe el parámetro podría ser reusada en otros proyectos.

Prueba a desacoplar
Probar un sistema casi obliga a disminuir todo lo posible el acoplamiento. La necesidad de probar las clases por separado fuerza en cierta forma a diseñarlas de manera que dependan lo menos posible unas de otras. Para que el proceso de pruebas sea efectivo, es necesario en todo caso que dicha dependencia sea explícita (por ejemplo, en la forma de parámetros en la construcción). Además, se refuerza la esencia colaborativa del diseño orientado a objetos.

Castillos en el aire
Las pruebas son especialmente difíciles de diseñar en aquellos casos en los que el código depende de alguna plataforma tecnológica, precisamente porque es difícil simular dicha plataforma (salvo que, una vez más, el sistema esté diseñado de forma que lo permita). Ejemplos de dichas plataformas son el servidor web (un IIS en mi caso), o un middleware o monitor transaccional (COM+ en mi caso). En el ejemplo esta reflexión se hace evidente.

Conclusiones
Como resumen, probar te permite orientar tu diseño para permitirte precísamente poder probarlo, aumentar su reusabilidad, disminuir su acoplamiento y abstraer lo más posible tu código de la plataforma tecnológica que estés usando en cada momento. No se le puede pedir más a una función... Veremos a ver qué aprendo de las próximas cientos de miles...

domingo, noviembre 27, 2005

Un momento de furia

Me voy a permitir un momento de queja.

Empezaré describiendo ciertas situaciones que me han sucedido varias veces, y luego terminaré con una conclusión y quizá una petición, un ruego.

Una vez dentro de la estación de metro, te dispones a coger la escalera mecánica para bajar, o para subir. Cuando llegas al otro lado de la escalera, la persona que está inmediatamente delante tuyo se detiene para decidir, allí, en el rellano de la escalera, si debe moverse a la izquierda o a la derecha, o quizá no sabe donde va... Es posible que le haya pasado algo, un mareo o un vaído, o que haya sufrido una hipoglucemia o un breve malestar, pero te aseguro que nunca me ha ocurrido que a la persona de delante haya necesitado a una enfermera o a un sámur.

Ya estás para salir. Subes la escalera, y el fumador que te abandera decide que ya es momento de encender un cigarro. Ha aguantado cerca de media hora sin fumar, y ahora siente que por fin puede dar via libre a su deseo contenido y casi inconscientemente saca el cigarrillo del paquete, lo toma entre los labios, chisca el mechero y lo acerca a la boca. Da la primera calada y expulsa satisfecho la primera bocanada de humo. Esa primera bocanada que, por efecto de la diferencia de temperatura entre el exterior y el interior del metro, va hacia atrás y en particular a tus pulmones, sin pagar peaje.

Tras varios intentos infructuosos (ninguno de ellos violentos hasta ahora), he conseguido sentarme. En el peor de los casos, el individuo a tu derecha se ha sentado de forma que extiende sus piernas hacia los lados, no se ha quitado el plumas a pesar del calor que hace en el vagón, y se dispone a leer un libro o peor, el periódico, acercándolo lo más posible hacia si, lo que provoca que también los codos sigan el mismo camino que sus codos. Sus rodillas pegadas a las tuyas y los codos clavados en tus costillas hacen que el lado derecho de tu cuerpo no se encuentre, digamos, cómodo. Por su parte, la joven a tu izquierda ha decidido que, puesto que no ha encontrado un sitio normal, el reposabrazos en ese mismo lado puede hacer las veces de asentáculo. El bolso colgado de su brazo derecho ha decidido también imitar al codo de la persona a tu izquierda. Por desgracia, la joven tampoco se ha quitado el plumas.

Las puertas de la salida (o de la entrada, depende del sentido que lleves) son conocidas entre los usuarios del metro porque son especialmente costosas de abrir. Así que, como dictan las normas de educación, una vez que has abierto las puertas, la sostienes y esperas a que la persona detrás de ti alargue el brazo y la sujete por ti mientras ella pasa. Si no fuera así, si hubieras soltado la puerta, podrías haber provocado que ésta se fuera hacia la cara del que te sigue, provocando algún daño o lesión. Pero la otra persona, lejos de sujetar la puerta, te ha visto quizá con cara de conserje y aprovechando tu maniobra, hace las necesarias para pasar por el dintel mientras tú, con cara de ingenuo, empiezas a dudar de cuándo deberías soltarla.

Por favor, somos más de cuatro millones de personas aquí en Madrid. Necesitamos colaborar unos con otros. A ¿todos? nos gustaría hacer lo que nos dé la gana, tener todo tipo de asistentes-esclavos para no tener que esforzarnos, estar cómodos en nuestro entorno. Pero si quieremos vivir medianamente bien (lo que significa vivir medianamente como humanos), debemos considerar a los demás, respetarlos. Es BÁSICO. Es quizá uno de los valores que vamos perdiendo cada vez más. El respeto es tener en consideración a los demás, primero por compartir la misma naturaleza, luego por la posesión de ciertos valores que igualmente respetamos, por ejemplo, la edad o la situación personal, o por qué no decirlo, por su cargo, por su autoridad... La cortesía es la expresión de ese respeto que tenemos por los demás, y en última instancia a nosotros mismos (el respeto por los demás empieza en el respeto por uno mismo).

¡Buff! Bueno, pues ya.

Vida y muerte

El trágicamente doloroso sentir que las cosas que ves, la gente que conoces, tu familia, tus amigos, tu mujer o tu novia; aquello por lo que has luchado, lo que has ganado, lo que has creado, lo que has hecho; todo lo que has sentido, todos tus recuerdos, tus emociones, lo que has visto; todo tu dinero... Todo. Absolutamente todo, desaparecerá algún día. Algún día, porque tú mismo desaparecerás.

Y todavía el día que desaparezcas, bueno, tampoco será tan trágico. Al fin y al cabo como decía aquel
No debes preocuparte por tu muerte, porque cuando tú estás, ella no, y cuando ella está tú no.
Pero ¿y todo aquello que desaparecerá cuando tú estés? Piénsalo.

Sin embargo, hay un efecto curioso. Cuanto más piensas en esas cosas, cuanto más piensa en tu muerte y en la de todas las demás cosas y personas, más te alegras de estar vivo e igualmente de que estén vivas todas las cosas y personas que te rodean. Y que no van a estar ahí para siempre.

Ahora no me extraña que el Bushido Shoshinshu empezará directa y claramente:
No dejes de pensar en la muerte. En cada momento.
Vive tu vida, pensando en tu muerte.

sábado, noviembre 26, 2005

Einstein

Ayer estuve en una charla de la Cátedra de Ciencia, Tecnología y Religión, organizada por la Universidad Pontificia Comillas.

Me considero una persona de cerebro inquieto, y me gustan mucho áreas de conocimiento como informática, astronomía, matemáticas, psicología... O sea, soy más bien del lado de las ciencias, sean biológicas, físicas, humanas o del conocimiento, y en particular, me gusta la relación que tienen esas áreas con otras que domino menos, pero que también me provocan cierta curiosidad, como la teología, la filosofía o la religión. Soy un firme defensor del efecto Medici (como siempre, Google encontrará por ti mucha información en inglés o en español).

Asi que era normal que me interesara el tema de la Cátedra, que esta vez relacionaba la figura científica de Einstein con su pensamiento. Aunque no era lo que se entiende por una persona religiosa, si es cierto que tenía una concepción de Dios muy profunda y muy newtoniana, es decir, la de un magnífico relojero, no intervencionista en la vida de los seres humanos, a los que dio la primera cuerda y que poco después permanecía absorto contemplando la obra y la exacta forma en la que todo funcionaba.

Que duda cabe de que el Einstein científico (hasta 1919, en el que se confirmaron sus teorías gracias a un eclipse de Sol) y el Einstein figura pública (desde ese año, en el que le alcanzó la fama) son los más conocidos, pero sería muy interesante estudiar su aspecto más humano. De especial interés son el divorcio de su primera mujer (precisamente en ese mismo año 1919) o la relación con otros científicos y físicos de su época, sobre todo aquellos relacionados con la mecánica cuántica.

Comentaré en mi diario otros temas relacionados con Einstein según me vayan llegando a mi memoria.

viernes, noviembre 25, 2005

Presentación

Este soy yo.



La única diferencia es que no llevo gafas, no llevo corbata, todavía no he caído en la tentación de llevar un par de bolis en el bolsillo de la camisa, y bueno, el pelo sí se parece un poco. En lo demás, soy idéntico.

Soy ingeniero software. El nombre parece un poco presuntuoso, pero lo más importante sobre él es que todavía no está claro qué significa ser "ingeniero del software". Algunos, los más radicales, nos niegan el título de "ingeniero".

Es verdad que nuestra profesión (¿alguien por ahí piensa que no existe?) está todavía un poco verde. El cuerpo de conocimiento no parece estar muy bien definido, por ejemplo, aunque hay la ACM y la IEEE están metidas en el proyecto swebok (Software Engineering Body of Knowledge).

¡Ay! Me pasa que cuando intento pensar sobre un tema, me da la sensación de que he leído mucho, pero que sé muy poco. Que mucho pasó por mis ojos, pero que poco de ello permaneció en mi memoria, o mejor, en mi entendimiento. Creo que voy a hacer una lista con las cosas que me gustaría saber bien, y ponerme en serio a estudiarlas.