Todo comienza cuando actualizo mi Ubuntu 10.10 a la versión 11.04. Todo parece ir como la seda, pero justo al reiniciar, kataklan!! cuelgue al inicio. Suerte que tengo el menú de arranque con GRUB. El sistema de arranque por defecto era el Ubuntu 2.6.38-8-generic-pae, pero entre las otras opciones tenía el Ubuntu 2.6.38-8-generic y este sí que arrancó.

Lo primero que me vino a la cabeza es que se trataba de un problema con la tarjeta gráfica (una Nvidia), pero tampoco tenía demasiado sentido. Buscando un poco por ahí me enteré de que el kernel “con pae” soluciona el hecho de que los sistemas de 32 bits sólo reconocen 3Gb de RAM. Y efectivamente, como había arrancado el sistema con el kernel “sin pae”, el monitor del sistema sólo reconocía 3Gb. Evidentemente no estaba dispuesto a renunciar a mis 4Gb de RAM, así que seguí buscando y encontré esta página. Allí explican que la solución es reinstalar los siguientes elementos del kernel:

linux-image-2.6.38-8-generic-pae
linux-generic-pae
linux-headers-generic-pae
linux-image-generic-pae
linux-headers-2.6.38-8-generic-pae

Me fui al Synaptic y efectivamente allí estaban, pero no todos. Por alguna razón, faltaban el linux-headers-generic-pae y el linux-headers-2.6.38-8-generic-pae. Sólo tuve que instalarlos. No tuve que reinstalar el resto.

Reinicié el sistema, entré con el kernel “con pae” y listo. Arranque sin cuelgues y vuelvo a tener mis 4Gb de RAM.

Espero que les sirva…Saludos.

En fin, resulta que a algún “alumbrao” se le ocurrió instalar un cajero automático falso en la DEFCON que se celebraba en Las Vegas y timar así a la flor y nata de la comunidad hacker. Y además con el ingenio de instalarlo justo al lado de la oficina de seguridad del casino en el que se celebraba la convención, el único lugar que no estaba al alcance de las cámaras de vigilancia.

Me quito el sombrero.

Más información en Engadget.

En el día de ayer se presentó en España la tecnología mediante la colaboración entre Yahoo e Intel, a través de la cual podremos acceder desde nuestro televisor a diversa información, proporcionada por pequeños widgets. Lo más interesante es que se va a liberar un SDK para que los desarrolladores podamos implementar nuestros widgets y publicarlos en su plataforma.

No es un paso definitivo, pero sí un acercamiento interesante a la inevitable cotidianización de internet en nuestras vidas. El otro paso más defitivo aún, es el acceso móvil a precios razonables. Tiempo al tiempo.

Ah por cierto, adiós Teletexto¡¡

Así da gusto.

Enhorabuena a los organizadores. No faltaré el año que viene, lo prometo.

Ellos saben que adopto esta postura por posicionarme en el lado más realista que puedo, aunque se podría entender que es ya una deformación profesional.

De todas formas, no me siento mal por ello. Tengo asumido que debo trabajar siempre situándome en dos perspectivas diferentes: el lado del usuario y el del programador. Ellos lo hacen sólo desde el lado del usuario y conocen bien esa parcela; lo que es vital para el usuario, cómo y qué se debe permitir personalizar, etc.

Supongo que no soy el único que se siente así en esta situación. Sólo quería expresar mi parecer.

{“Cod”:33423,“Nombre”:”Juan”,”Profesion”:”conductor”,”Nacionalidad”:”española”}

Si se desea indexar por estos campos-propiedades, se usará una tabla por cada campo por el cual se vaya a indexar. De esta forma, si se desea añadir o eliminar índices, basta con crear o eliminar la tabla correspondiente.

No voy a profundizar demasiado. Se pueden ver más detalles acerca de la implementación en el propio post. Lo que me llamó la atención, aparte de la sencillez del sistema tanto para implementarlo como para mantenerlo, fue la razón que les llevó a implementarlo: Hay muchos proyectos diseñados para abordar el problema (alto crecimiento y constantes cambios en el esquema) almacenando los datos con esquemas flexibles y construir nuevos índices al vuelo (por ejemplo. CouchDB). En cualquier caso, ninguno de ellos parece lo suficientemente utilizado por sitios grandes como para inspirar confianza.

Bien, intentaré hacer mi propia implementación de un sistema similar y si puedo, publicaré los resultados al respecto.

Ahora, la duda que me viene a la cabeza es si estos resultados se mantienen cuando la transferencia se establece entre dos servidores, por ejemplo cuando consumimos un webservice y es, desde el lado del servidor desde donde procesamos los datos transferidos. Y si es así, ¿no deberíamos plantearnos la conveniencia del XML para el transporte de datos, aún siendo éste el estándar para la comunicación entre aplicativos?

Estoy ansioso por ver las calles canarias en el Street View. ¿Porqué será que queremos ver lo que ya conocemos?

La verdad es que el ambiente me recordó al de la facultad (mejor dicho al de las cafeterías aledañas), cuando nos reuníamos el grupo de siempre con las mismas discusiones sobre algoritmos, frameworks, OOP, etc, etc.

Bueno, informaré de futuras reuniones y sobre lo que vayamos sacando de ellas.

Saludos a los que estuvieron presentes y espero volver a vernos pronto.

Actualización:

Careto de los asistentes, imagen subida por Carlos.

Debemos intentar (admito que yo el primero) a convivir y aprender de ellos. Los programadores en muchas ocasiones, nos empeñamos en convencer al usuario de que la falta de una determinada funcionalidad no es un error, sino una omisión en los requisitos. Aún así debemos analizar el porqué se ha producido y eso, en parte, es también un tipo de error.

Según Alexander Pope:

“Debemos tener cuidado de extraer de una experiencia solamente la sabiduría que contiene, y detenernos; no seamos como el gato que se sienta sobre la estufa caliente. Nunca volverá a sentarse sobre una estufa caliente (y eso está bien); pero tampoco volverá a sentarse sobre una fría.”

En ocasiones, incluso provocar errores nos puede resultar útil. Una práctica que llevo a cabo muy a menudo (espero no ser el único), sobretodo cuando llevo varios proyectos en paralelo, es colocar errores de sintaxis en el punto del programa donde pretendo continuar la próxima vez. Así la compilación del programa me avisa donde lo dejé, sin tener que recurrir a documentarlo por escrito. Sé que es una chorrada, pero a mi me ha resultado bastante útil.

Comentar el contenido del libro no es el propósito de esta entrada, aunque recomiendo su lectura. De lo que quiero hablar es de una curiosidad que se comenta en uno de sus capítulos y que me llamó mucho la atención. En el capítulo en cuestión, se relata el experimento llevado a cabo por Joseph Weizenbaum, en el cual “exponía” a una serie de sujetos a una conversación con su programa “Eliza“, sin que aquellos supiesen que hablaban con una máquina:

Sujeto: Todos los hombres son iguales.
Eliza: ¿De qué manera?
Sujeto: Siempre nos están molestando con sus historias.
Eliza: ¿Está pensando en algún ejemplo preciso?
Sujeto: Pues sí, mi amigo me hizo venir aquí.
Eliza: ¿Su amigo le hizo venir aquí?
Sujeto: Dice que con frecuencia estoy deprimida.
Eliza: Siento mucho escucharle decir que está deprimida.
Sujeto: Es cierto, me siento mal.
etc, etc.

Al final, se demostró que los usuarios se implicaban emocionalmente en su relación con el ordenador. Lo que me resultó curioso, es que la secretaria de Weizenbaum se mostró interesada en mantener conversaciones con Eliza en privado, aún sabiendo que era un “simple” programa de ordenador en el que había visto trabajar a Weizenbaum durante meses.

De ahí podemos concluir que nuestras interacciones con las máquinas pueden llegar a ser tan sociales y naturales como las que establecemos entre humanos.

No se le niega, pero tampoco se le escapa a nadie la eficacia que adquieren las campañas publicitarias de sus anunciantes. De todas maneras, en Google no hacen oídos sordos ante las posibles críticas y anuncian la posibilidad de deshabilitar la cookie encargada de obtener los datos de los internautas. Se ha anunciado en el blog oficial hace unos días y con ello, a mi entender, dan un gran golpe de efecto ante quienes siempre han tenido una actitud crítica hacia la política de protección de la privacidad seguida por Google.

Enlace: Inhabilitación de la cookie de publicidad

Esto me ha animado el día y sobretodo cuando he estado media mañana peleándome con un script de esos que se resisten a funcionar y que te dejan con cara de idiota cuando encuentras el error.

Bueno, que he hecho mis pruebas y aquí podéis ver el resultado:

Como véis es bastante fiable en la detección. Se me ocurre ahora que podríamos currarnos una rutina de comparación de la zona obtenida con las que pudiésemos tener en una base de datos y hacer un reconocimiento de la persona fotografiada. Pero eso ya es otro cantar.

Lo que me gustaría recalcar es que cada vez se ven cosas más interesantes hechas con Javascript. Esto, unido a los nuevos motores de Javascript que se están incluyendo en las últimas versiones de los navegadores, nos demuestra por donde van a ir los tiros de ahora en adelante.

Bueno, que todo sea para bien y no para tener mañanas como la de hoy.

Gracias a otros blogs que se habían hecho eco de su publicación, había llegado al blog de Paul Graham, donde había leído la siguiente entrada y que me he atreví a traducir. Espero que os guste:

“Un buen programador que trabaja intensivamente en su propio código, puede mantenerlo en su mente de la misma manera en la que un matemático mantiene el problema en el que trabaja. Los matemáticos no buscan respuestas trabajando con lápiz y papel, tal y como lo haría un escolar, sino que intentan comprender el ámbito del problema lo suficientemente como para trabajar con él de forma mental. Y para la programación es lo mismo. Puedes mantener el código en tu cabeza y manipularlo a voluntad.

Esto es particularmente valioso al inicio de un proyecto, porque inicialmente, lo más importante es ser capaz de cambiar cualquier cosa. No sólo resolver un problema de una forma diferente, sino cambiar el problema que estás resolviendo.

Tu código es la comprensión que tienes del problema que estás analizando, así que sólo cuando seas capaz de mantener el código en tu mente, habrás comprendido realmente el problema.

No es fácil llevar el código de un programa a tu mente. Si abandonas un proyecto por unos meses, puede llevarte días el comprenderlo otra vez cuando lo retomes. Incluso cuando estás trabajando activamente en un programa, puedes tardar hasta una hora el llevártelo a tu cabeza, cuando empiezas a trabajar en él cada mañana. Normalmente, las condiciones de trabajo de las oficinas, no permiten trabajar de este modo. Es más, muchos programadores trabajan en condiciones tales que no llegarán a comprender nunca el problema que están resolviendo.

Incluso los mejores programadores no son capaces de mantener el programa con el que están trabajando, idealizado en su cabeza por completo. Pero hay algunas cosas que pueden ayudar:

1. Evitar las distracciones. Las distracciones son malas para muchos tipos de trabajos, pero espcialmente para la programación, porque los programadores tienden a operar al límite de detalle del que son capaces. El peligro de una distracción depende no de cuanto dura, sino en cuanto desordena tu cerebro. Un programador podría dejar la oficina e ir a por un bocadillo, y ser capaz de mantener el código en su mente. Pero una distracción de la “malas”, podría dejarte en blanco en tan sólo 30 segundos.Curiosamente, las distracciones programadas pueden ser peores que las inesperadas. Si sabes que vas a tener una reunión en una hora, simplemente no eres capaz de comenzar a trabajar en algo complejo.

2. Trabaja en tramos largos. Como hay un coste fijo cada vez que comienzas a trabajar en un programa, es más eficiente trabajar en pocas sesiones largas que en muchas sesiones cortas. Por supuesto, llegará el punto en el que te canses. Esto varía de una persona a otra, y como mejor trabajo es en tramos no superiores a 12 horas. Aunque he oido de gente que “hackea” durante 36 horas seguidas.Lo óptimo no es el límite físico que puedes aguantar. Hay ventajas a la hora de aparcar un proyecto y es que cuando lo retomas después de un descanso, a veces encuentras en tu inconciente una respuesta esperando por ti.

3. Usar lenguajes precisos. Cuanto más potente sea el lenguaje de programación, más cortos serán los programas. Y parece que los programadores piensan (al menos, parcialmente) en el lenguaje en el que programan. Así, cuanto más preciso es el lenguaje de programación, más corto es el programa y más fácil es asimilarlo y menteberlo en mente.Puedes ampliar el efecto de un lenguaje potente usando un estilo de programación llamado “bottom-up”, donde escribes los programas en multiples capas y donde las de nivel inferior actúan como lenguajes de programación para las de nivel superior. Si haces esto así y lo haces bien, solo tendrás que mantener en tu cabeza la capa de más alto nivel.

4. Reescribe tu código. Del hecho de reescribir tu código, a menudo resulta un diseño más limpio. Pero esto puede tener ventajas incluso si no lo consigues: tienes que comprender un programa completamente para reescribirlo, así que no hay mejor manera para mantenerlo en tu mente.

5. Escribe código legible. Todos los programadores sabemos lo bueno que es escribir código legible. Y esto es más importante aún cuando tú vas a ser el principal lector. Especialmente al principio; un prototipo es una conversación contigo mismo, y cuando escribes para ti mismo tienes diferentes prioridades. Si escribes para otros programadores, es mejor que no hagas un código demasiado denso. Algunas partes del programa pueden ser más fáciles de leer si te extiendes, mientras que si lo que quieres es facilidad a la hora mantener tu código en tu cabeza, será mejor que optes por la brevedad.

6. Trabaja en grupos pequeños. Cuando manipulas un programa en tu mente, tu visión tiende a pararse justo en el lugar donde termina el código que has escrito tú. Las otras partes no las entenderás tan bien y por tanto no podrás tomarte demasiadas libertades con ellas. Así que, cuanto más pequeño sea el número de programadores, más completamente podrá mutar el proyecto. Si hay solo un programador (como suele ocurrir al principio), podrá llevar a cabo rediseños que lo abarquen todo.

7. Evita tener a mucha gente que puedan editar el mismo trozo de código. Nunca podrás entender el código de otros tal y como entiendes el tuyo propio. No importa con que profundidad lo has leído; solo lo has leído, no lo has escrito. Así que, si un trozo de código ha sido escrito por varios programadores, ninguno de ellos lo entenderá tan bien que si lo hubiese escrito un único programador. Y por supuesto no podrás rediseñar de forma totalmente segura, cosas en las que está trabajando otra gente. No es sólo que tendrías que pedir permiso. Rediseñar código en el que trabajan varios programadores es como cambiar las leyes, es como la interpretación de una imagen ambigua. Si quieres asignar varias personas a un proyecto, divídelo en módulos y asígnalos a cada programador.

8. Comienzo pequeño. Un programa te será más fácil de mantener en tu mente cuanto más familiarizado estés con él. Puedes comenzar tratando las partes como cajas negras. Pero cuando comienzas a trabajar en un proyecto, te vez forzado a verlo todo. Si comienzas con un problema grande, puede que nunca puedas abarcarlo por completo, por lo que necesitas escribir una aplicación grande y compleja, la mejor manera de comenzar es escribir un prototipo que resuelva un subconjunto del problema. Lo que se perderá en la planificación, se verá compensado con la ventaja de poder mantener al programa en tu cabeza.

Es curioso la de veces que los programadores gestionan los 8 puntos anteriores por casualidad: alguien tiene una idea para un nuevo proyecto, pero tiene que llevarlo a cabo fuera de horas (ya que no es un proyecto autorizado), lo que provoca que sea más productivo al no producirse distracciones. Llevado por su entusiasmo, le dedica sesiones de varias horas. Como es inicialmente un simple experimento, en vez de usar un lenguaje “de producción”, hace uso de uno más de “scripting”, que al final acaba siendo más robusto. Por amor propio y buscando la perfección, reescribe completamente el programa varias veces (lo que sería injustificable para un proyecto official). Y puesto que nadie va a verlo excepto él mismo, omite del código cualquier comentario excepto los del tipo “nota-a-mi mismo”. Trabaja forzosamente en un grupo reducido ya que, o no le ha comentado a nadie la idea o a nadie se le permite trabajar en un proyecto tan poco prometedor. Incluso si hubiese un grupo de trabajo, no podrían tener a mucha gente trabajando en el mismo código, porque cambia demasiado rápido para que eso sea posible. Y el proyecto comienza pequeño porque la idea es pequeña al principio; él solo quiere intentar una implementación que tiene en mente.

Más asombroso aún es el número de proyectos autorizados de forma official que gestionan los ocho puntos de manera errónea. De hecho, si nos analizamos la manera en que el software es escrito en la mayoría de las organizaciones, es casi como si estuviesen intentando hacer las cosas mal. Y en un sentido lo están. Una de las cualidades de muchas organizaciones es tratar a las individualidades como partes intercambiables. Esto funciona para muchas tareas “paralelizables”. Pero el tener ideas no es una tarea muy “paralelizable”. Y eso es lo que son los programas: ideas.

Hay una contradicción en la frase “compañía de software”. Las dos palabras empujan en sentidos opuestos. Cualquier buen programador en una gran compañía va a estar en desacuerdo con ella, porque las organizaciones están diseñadas para impedir aquello por lo que los programadores se esfuerzan.

Los buenos programadores gestionan demasiadas cosas a toda costa. Y esto a menudo requiere un acto de rebelión en contra de las compañías que los emplean. Quizás esto ayude a entender que la manera en la que se comportan los programadores es conducida por las demandas del trabajo que realizan. No es que sean irresponsables, ni se enfrasquen en la programación en vez de escribir primero las especificaciones. No es que se empeñen en reescribir código que ya funciona. Ni que sean antipáticos y prefieran trabajar solos. Esta colección al azar de hábitos molestos tiene una sola explicación: la capacidad de alojar un programa en la cabeza.

El punto más débil de las compañías grandes es que no dejan a programadores individuales que hagan un buen trabajo. Así que si eres una pequeña startup, éste es el lugar donde atacarles. Coger el tipo de problemas que tengan que ser solucionados por una gran mente.”