The Emotion Machine
I have finally finished reading Marvin Minsky’s The Emotion Machine. As I read the different chapters, I had written some reviews about it ([1], [2]), but I decided not to do that anymore as I was missing the point of the book into the details. My assumption was correct: the final chapters do provide some sort of global vision of the rest of the book that explains the whole theory and provides a good wrap-up of Minsky’s theory.
In short, my previous reviews and summaries are still valid, but what’s new is, in laymans terms, that being a difference-identification machine, the mind analyzes itself and detects internal changes so that it can react based on its own approaches, and that gives us the ability of changing strategies when solving problems, of analyzing things in different aspects (Minsky calls them “levels”) and knowing at the same time how to work with itself. The model sounds very consistent, and regardless of the original statements, it does seem like a simple model of the mind that allows to explain its complexities.
I do see, however, certain points that were not covered in the book and would have been very enlightening. But it probably is my fault, as I have read Minsky’s draft on his page and not the actual published, revised and edited book. I’ll try to avoid reading drafts in the future, as you can really tell that there’s content missing or further explanations that will be missing from these unfinished versions. On this particular example, I would have wanted to see how Minsky’s theory explains what other psychology theories can explain, and be the explanation that no other theories could give. I could only find some references to Freud and the Self on the last chapters, and Jung on the first ones.
Also, I saw that the evolutionary arguments for explaining that the brain has developed in the way that it is right now were quite weak. I can’t really argue against them as I’m not biologist nor close to one at all, but I haven’t read in there any real good explanation of how brains evolved and to assume that they just did is not a proof to the theory, but part of the theory itself. In such a way, I don’t feel disbelieve in it, but I think it should be polished a little more. I wonder if further editions of the book (or maybe other Minsky’s books) do contain the necessary background to cover all of my doubts. I guess I’ll have to find out. ;)
As a general reading, I liked the way Minsky used to introduce several points of view and dialogues in the explanations itself. It seems that he could be actually having a dialogue with the reader, and in such a way, it was really easy to follow and natural to understand. The end of the book needed some more revisions as it was clearly unfinished and with Minsky’s personal notes, but that’s what I get for reading a draft.
I really look forward to read more of the Society of Mind saga.
Link del día: Atributos .NET
Los atributos de .NET son una de esas características del lenguaje que están presentes desde hace un buen tiempo, pero es una de esas características que tardamos en descubrir y utilizar.
No hace mucho me encontré con una pregunta en Stack Overflow con el nombre: Most Useful Attributes in C#?, y las respuestas son cosas que nos serían útiles a todos los que trabajamos con ese lenguaje. Desde pequeñas mejoras para el uso del debugger hasta características auto-implementables que de otra forma hay que reescribir. Los dejará explorar esa pregunta con sus contestaciones, que al momento de redacción son 27.
Soy un zorrinito atribuíble.
Link del día: Buenas Prácticas UX
Encontré tres preguntas particularmente útiles en el foro de UX de Stack Exchange, las cuales son:
- Have I missed anything from my list of web form best practices?
- Common Web App Usability gotchas?
- What are your desktop UI Pet Peeves?
- Whare are ccommon UI misconceptions and annoyances?
Estas cuatro preguntitas (y muchas otras si también checkean la sección de related en cada una) son un buen comienzo para identificar cuáles son las bases de la experiencia de usuario. Seguramente sepamos mucho al respecto por el uso diario que tenemos de distintas aplicaciones, tanto web como de escritorio, y al momento de ver algo nuevo, podemos distinguir de forma muy fácil si se trata de una experiencia positiva o negativa. Sin embargo, al momento de explicarle a alguien más cuáles son esas bases, o al momento de checkear todo, se hace un poco difícil enumerarlas.
Me gustaría saber qué adiciones les harían a esos listados. Confieso no haberlos leído completamente, pero sí en una buen parte.
Soy un zorrinito de buena experiencia.
Link del día: Nuevos status HTTP
Y la tecnología se mueve más y más rápido y lo que dábamos por conocido vuelve a cambiar. En este caso, se trata de los HTTP Status Codes, en donde ahora hay cuatro nuevos propuestos, en estado de draft por la IETF: Additional HTTP Status Codes. Nada del otro mundo realmente, aquí no se están proponiendo cosas que salieron ayer, pero es curioso ver cómo las cosas que dábamos por sentado también cambian de a poco.
En este caso está agregando status codes para Too Many Requests, Requests Fields too Large, Requires Network Authentication y Precondition Required, por lo que no nos vamos del rango 400 ni del 500. Unas pequeñas adiciones a lo que ya estábamos acostumbrados.
Soy un zorrinito estándar.
Link del día: Demos HTML5 prácticas
Cuando se viene el momento de implementar cosas en HTML5 puede que nos demos cuenta que nuestro conocimiento del mismo no es lo suficientemente profundo aún como para poder utilizarlo de una forma autónoma. Esto es, todavía nos falta algo de práctica y de separación de conceptos para tener todo claro y simple en nuestra cabeza. Lo mejor para estos casos sería sin duda un manual de referencia con ejemplos cortitos, y eso es lo que alguien más pensó para hacer esta galería de demos.
HTML5 Demos and Examples es una pequeña galería de ejemplos HTML5 en donde podemos ver cómo se utilizan las distintas características expuestas por esta nueva tecnología. Incluye también una clara referencia de en dónde se puede utilizar y dónde no (aunque una referencia completa de esto podemos encontrar en Where Can I Use…).
Soy un zorrinito práctico.
Link del día: UI Layout Plugin
Del mundo de jQuery nos vuelve a caer un plugin de buena utilidad, bajo el nombre de UI Layout Plugin. Este plugin nos permite manejar dinámicamente el layout de nuestra página, permitiendo interacciones complejas o pantallas con mucha información para ser mostradas de forma dinámica.
Está claro que no siempre esto es deseable, pero para esos momentos en donde la interfaz debería complicarse para permitir variadas acciones sin interrumpir el curso normal de lo que estaba pasando, quizás hasta permitiendo una interacción rica y compleja antes de continuar con el intento original, incluso sin perderlo de vista, imagino que ese es el uso más interesante que este plugin nos puede ofrecer.
Soy un zorrinito modificable.
Link del día: Framework HTML5 Mobile
Muchas buzzwords en el título, pero no deja de ser verdad. Hace un tiempito ya anda dando vueltas The-M-Project, bajo el título de “HTML5 JavaScript Framework, escribe aplicaciones móviles multi-plataforma”. Si eso no es prometedor, no sé qué lo es.
El proyecto aún está en estado alpha, y nos instancian a que le hagamos las modificaciones que nos plazca en GitHub para luego integrarlo al proyecto principal, si es que son buenas modificaciones, claro.
Hay una aplicación demo que tienen llamada Todo2, que es básicamente una lista de tareas, o Twitter Sample, una aplicación de búsqueda de Tweets, o mejor que nada, el Kitchen Sink, para ver un poco de todo.
Soy un zorrinito web.
Link del día: debugCSS
Como todo elemento del desarrollo web, los CSS también pueden tener errores, y nuestra forma de utilizarlo puede no ser la óptima. Hay muchas herramientas que nos permiten ver cómo podríamos mejorarlo, pero hasta ahora no había visto ninguna que se enfocara directamente en corregir las buenas prácticas (junto con los errores, claro).
Entonces me crucé on debugCSS, un proyecto en forma de bookmarklet que nos da feedback sobre la página que estamos viendo. Al ser un bookmarklet, no toma más que un click y una arrastrada para instalarlo, y lo podemos usar tanto en páginas web como locales. Estuve probando varias páginas y de verdad que aunque no tenga errores graves, siempre estará dando sugerencias de como hacer el CSS y el HTML, más acorde, y no mancharlo con JavaScript inline.
En fin, otra de las herramientas útiles al momento de hacer desarrollo web.
Soy un zorrinito criticón.
Link del día: Qué debería saber todo programador JavaScript
Aquellos que están en el mundo web, y más que nada en el mundo de las RIA (Rich Internet Applications), no dudarán en decirme que JavaScript es sin duda una de las herramientas más potentes que tenemos disponibles. Otros sabrán de muchas de las mejoras que se vienen en este área, pero no es lo que quería comentar hoy.
Lo que quería contar es sobre una pregunta en StackOverflow llamada What should every JavaScript programmer know?, con puntos muy interesantes, referencias muy completas y hasta un quiz, y yo creía que sabía y no respondí correctamente ni la mitad de las preguntas.
Leer esas respuestas llaman la atención y sacan a la luz muchos puntos curiosos que quizá no habíamos considerado.
Soy un zorrinito JavaScript.
Link del día: Programando con el sombrero rosa
La gente de Babcock y Jenkins escribió un artículo sobre una actividad que ellos denominan “Coybow coding”, que como lo pueden imaginar, tiene que ver con la codificación temeraria. En este caso, se trata sobre la programación o remediación de defectos directa en servidores de producción. Su artículo se titula Cowboy Coding and the Pink Sombrero.
La metodología de ellos es realmente hacer llamar la atención a alguien cuando se están haciendo cambios en producción. Es muy común que ciertas empresas muestren un mensaje cuando se accede a un servidor de producción, o que muchas acciones estén restringidas, o que se necesite usar passwords a cada rato. En defnitiva, es la importancia de recordarle al programador / administrador de sistemas que se encuentra trabajando en un sistema que está en vivo.
Ahora, otra forma de lograr este efecto es “haciendo pensar” al programador si realmente se justifica estar haciendo estos cambios en producción, y para eso, nada más llamativo de la atención que un sombrero rosa. Lo llamativo del sombrero hace que todos sepan que hay alguien trabajando en producción, y cuando se acercan a preguntar, la persona haciendo los cambios comienza a dudar si realmente lo mejor era hacer eso.
Buena técnica, curiosa implementación. Me gusta como se juega con la psicología para que de a poco se vayan castigando estos comportamientos. Sin embargo, creo que si alguien debe de hacer un cambio en producción, dudo que el ambiente sea tan animado como para andar poniéndose sombreros.
Soy un zorrinito sin sombrero.