Link del día: Comic Sans Project
Sé que muchos de nosotros nos encontramos en desacuerdo con el uso masivo de la tipografía Comic Sans, generalmente porque decimos que es inapropiada a mucho de los usos que se les da. No soy diseñador, y seguro que uno podrá dar infinidad de razones por la que es pecado hacer tu branding en esta fuente. Sin embargo, hay gente que piensa lo contrario y varios de ellos se han agrupado para dar lugar a Comic Sans Project, un Tumblr en donde se postea branding de distintas empresas, llevadas al Comic Sans. Debo confesar que está hecho con mucho cuidado, ya que la gran mayoría no se ven mal (aunque se puede argumentar que no es Comic Sans pura, ya que sufre de varias modificaciones). En fin, mirenló, diviértanse o lloren. Me lo trajo de regalo de reyes A Welsh View.
Soy un zorrinito poco serio.
Link del día: Software de sincronización
A esta altura ya todos conocemos Dropbox, y quizá varias otras alternativas similares (como Live Mesh, Sugarsync, etc). En este caso alguien preguntó qué servicios similares existen que no suban su información a internet, y obtuvo una buena variedad de respuestas. Es útil cuando la privacidad es un problema o la legalidad de la información también lo es (por ejemplo, que cierta información no pueda alojarse fuera de los servidores de una determinada empresa). En casos así, estos otros servicios pueden ser muy útiles.
Soy un zorrinito sincronizado.
Link del día: Cosmos (C# OS)
Cosmos es un proyecto opensource hosteado en Codeplex, que se trata de un sistema operativo completo construido en C#. Como tal, podemos deducir que no corre realmente de forma nativa en una máquina, sino sobre la plataforma .NET, pero creo que merece su atención como proyecto de extrema complejidad. No he visto el código, pero no dudo que mucho se podrá aprender de eso con solo mirarlo. Aparentemente, también hace utilización de extensas capabilidades de Visual Studio para un buen debugging del mismo, con lo que también es un buen ejercicio para aprender de esta herramienta.
Soy un zorrinito emulado.
UPDATE 3/1/2012 12:00 PM: Andrés agrega en los comentarios hablando de Singularity, un proyecto similar también en código managed (IL), pero no construido enteramente sobre eso, sino que tiene un kernel hecho en Assembler y un par de drivers hechos en C++. Aparentemente, este sí calificaría como un sistema operativo completo, ya que puede correr de forma independiente.
Link del día: Git Magic
Para aquellos aprendiendo – o con ganas de aprender – a manejar Git como sistema de control de versiones, Git Magic es un documento que cuenta cómo utilizarlo de a poco, varios trucos y analogías de para qué sirve, de forma muy práctica y muy orientada a lo que uno quiera lograr.
Soy un zorrinito distribuido.
Link del día: Cómo hacer presentaciones geniales
En mi último link del día mostré una presentación llamada Cómo GitHub usa GitHub para construir GitHub, pero más allá del contenido, lo que realmente me llevó a leer esa presentación era una nota sobre diseño de presentaciones. De hecho, Zach Holman escribió un pequeño artículo llamado Slide Design for Developers, en donde da varios puntos guías para gente que no está especializada en el diseño sobre cómo se deben diseñar buenas presentaciones.
Creo que muchas de sus afirmaciones son correctas, y el tema del estilo es muy propio y debe aprenderlo cada uno. Sin embargo, es importante ser consistente, y de forma visual, eso también importa mucho. Como él dice: unas buenas diapositivas no harán buena tu presentación mágicamente, pero malas diapositivas realmente hundirán una buena presentación. Creo que todos hemos visto eso pasar. Muchas veces.
Soy un zorrinito presentable.
Link del día: Cómo GitHub usa GitHub para construir GitHub
Pensé que esta iba a ser otra presentación de producto como cualquier otra, pero no es el caso. La exposición de Zach Holman de cómo se utiliza GitHub es realmente épica, en cuanto a lo simple de su mensaje y lo profundo de la filosofía de trabajo que tienen.
La presentación se puede ver aquí: How GitHub Uses GitHub to build GitHub, y cabe destacar que es una presentación muy clara de por sí, no hace falta realmente ver el video para imaginar qué es lo que se está hablando.
Creo que tenemos mucho que aprender de esa filosofía, de ir al punto y resolver el problema, olvidarnos de la burocracia a la que estamos expuesto todos los días, y darnos cuenta de cómo hicimos de este trabajo algo innecesariamente complejo cuando las soluciones siguen estando al alcance de la mano.
Soy un zorrinito directo.
¿Por qué HTML5?
Hace no mucho se me presentó en una conversación, en donde me encararon con la siguiente pregunta: “Si el estándar de HTML5 no está aprobado aún, por qué usarlo?”. Me abalancé con una respuesta salvaje del estilo “Por qué no?” (aunque con otras palabras) y no dije mucho más. ¿Por qué alguien querría no usarlo? Pasaron 30 segundos desde mi respuesta y me puse del otro lado, pensando en que me estaban hablando de una nueva versión de Windows y ahí creí comprender el punto de vista. Creo que no aplica a HTML5 pero… por qué habría una diferencia?
Fue entonces en donde me puse a dar una respuesta más elaborada, la cual reproduzco a continuación.
HTML5 es algo muy nuevo todavía, y eso tiene sus pros y sus contras.
El contra que todos obviamente vemos ahora es que puede cambiar hasta terminar de definirse, sumado a que tiene poca adopción y (va a tener) bugs en implementaciones en distintos browsers. Sumenlé problemas de seguridad que sin duda se van a venir, backward compatibility no-tan-suave y más temas.
Ahora, qué tiene de bueno? No voy a enumerar lo nuevo {en cuanto a capacidades} porque eso lo pueden leer en cualquier lado.
HTML5 va un poquito más allá de la tecnología que implementa. Se trata de, por un lado, una forma nueva de aproximarse a la tecnología de la web. Por otro lado, de un plan mucho mayor de lograr una mejor estandarización (que comenzó con XHTML 1.0 y siguió con Transitional HTML). Por otro lado más, el efecto que ha tenido sobre la comunidad online demuestra que estamos capaces de acelerar el proceso de estándares (que hoy por hoy, no baja de los 5 o 6 años, cuando las tecnologías nuevas aparecen cada 6 meses).
Déjenme explayarme sobre lo anterior:
- Una forma nueva de aproximarse a la tecnología de la web
HTML5 fue un poco más “democrática” que el resto de los HTMLs pasados, en donde ya la dirección no se lleva adelante por los que están experimentando en el área, sino los que además de tenerlo asimilado, ya aprendieron de los errores pasados y tienen visión del futuro. Cosas como webSockets, canvas, CSS3 3D acceleration (sé que no es HTML5 pero lo meto en el mismo paquete) no hablan tanto de algo que deba ser más fácil de programar, sino de una dirección distinta que va a empezar a tomar la web. Va a tratarse más de contenido multimedia e interacción, no más texto, imágenes y links. Abre otra forma completa en que las aplicaciones van a poder trabajar, y es un campo perfecto para la creatividad, la innovación y el avance. Cuando se asiente un poco el polvo va a venir la nueva revelación basada en esta tecnología. No estoy seguro de qué y no me las doy de visionario, pero es lo que siempre pasa, y a la velocidad que vamos, estoy seguro de que cada vez la revolución va a ser mayor.
- Forma parte de un plan mayor
Hace tiempo que la web viene “rota”, por su cualidad de “forgiving”. Cuando la web empezó había uno y luego dos navegadores. Tan poca variedad hizo que los programadores se educaran de forma terrible, y ambas partes luchaban por definir su estándar. El resultado: que cada empresa de IT tenga que tener un departamento de HTML+CSS porque algo que se suponía iba a poder hacer cualquiera se convirtió en toda una ciencia. Para sumar, el avance exponencial lo hace cada vez más difícil, con lo cual hoy hay activas 5 versiones de Internet Explorer, 4 de Firefox, 3 de Opera, 9 de Chrome, 2 de Safari y no sé cuántas más me estoy olvidando. Los renderizados y capacidades varían de SO a SO (multipliquen por todo lo que dije), y ni hablemos del mundo móvil. Cada navegador se tiene que acomodar a las 5 versiones de HTML que andan dando vueltas, más sus distintos modos. Cada navegador también implementa sus propios “extras”, que se idearon al principio para que los programadores lo eligieran y dijeran “este sitio funciona con Internet Explorer 6” ( ¿ActiveX alguien?). Eso era marketing: luego la web iba a ser basada en IE. {Eso hoy es inconsistencia cross-browsing.}
Por supuesto, esto es un quilombo {lío}. Todos usaban IE hasta que FireFox y la moda open source comenzaron a tomar popularidad, luego Google Chrome y la promesa de hacer todo más liviano, más rápido y ellos “apoyando y promoviendo” los estándares, hizo que el mercado se distribuyera mucho.
Programar en HTML y hacerlo “aceptable” en todos lados es complejo también, porque los navegadores se bancan {soportan} todas las formas de hacer cosas, y nosotros tenemos que ajustarnos a ellas para que nuestra nueva página haga lo que queremos. Hoy esto es una traba a la innovación y a la mejora, porque lo que tiene que ser simple es un infierno.
El fallback de HTML5 es HTML4 y se planea en un futuro (lejano) volverlo {al HTML} tan estricto como el XML (de hecho, un schema definido por el mismo), lo cual va a significar: menor cantidad de estándares, mejor performance de los navegadores, menos ambigüedad de implementaciones, más soporte y más acogimiento de distintas plataformas y usuarios. Si piensan que HTML es una regla definida en texto, está realmente muy difícil entender por qué esto no fue así antes. (Excepto que se lean la historia de los párrafos anteriores.)
Por supuesto, proponer algo así hoy está condenado al fracaso, por algo simple: nadie lo va a hacer, y nadie va a tirar a la basura la internet que tenemos hoy. Esos pasos graduales (que cada vez van más rápido) lo van a lograr. Lo mismo se hizo con IPv4 vs IPv6, que casi llega al final de sus días (y hablamos de algo que tuvo unas buenas décadas para llevarse a cabo).
- Acelera el proceso de estándares
Ahora que el UX está en su auge, el entrepeneurship es una palabra (sí, también me sorprende), Microsoft se quiere redimir, Google está en la lucha, y la comunidad misma es la que presiona por todo esto, todo se aceleró. Cuando propusieron HTML5, Google Chrome ya soportaba cosas a la semana. {Nota: Esto no es históricamente correcto. La expresión denota la velocidad con que se adoptaron los cambios.} Si algo cambiara, ellos lo cambian al toque. Se ganaron el corazón de los desarrolladores y de a poco mercado con eso. Es la misma historia, pero ahora sin la burocracia de ir contra un estándar, sino al contrario, presionar para que el estándar se consolide.
Y esto es bueno porque todo lo que conté antes va a ocurrir más rápido. En definitiva, nuestras capacidades en la web no van a ser imposibles por la arquitectura cliente-servidor a la que estamos acostumbrados, sino que pronto van a venir cosas que nos van a permitir esa revolución.
Y si yo estoy desarrollando un producto, ¿por qué me importa todo esto?
Si sos alguien a quien le importa la tecnología y tenés tu pasión en ella, ya tuviste tu respuesta.
Si sos alguien que solo quiere vender un producto, o un cliente al que le tengo que convencer de usar tecnología nueva, la razones son las siguientes:
- Si tenés un target determinado, podés forzar a que usen el navegador que mejor soporten lo que quieras, y hacer uso de las nuevas capacidades. Sistemas más limpios, más seguros, y que luego solitos van a funcionar con el resto de los navegadores.
- Si tu target es público en general, también te genera buena reputación estar sobre la cresta de la ola. Hay un mundo de apasionados y programadores que te van a mirar por cómo hiciste las cosas y no por lo que hiciste en sí (aunque claro, son la minoría). Si tu target es técnico, más interesante aún.
- Si te importa la experiencia del usuario, hay cosas nuevas que podés lograr que de otra forma no podés. No todos van a poder experimentarlo hoy (por la compatibilidad), pero los que sí son visitantes ganados.
- Cuando esta nueva tecnología se abra paso a más caminos, la ola te lleva sola sin ningún esfuerzo extra. Ejemplo: video HTML5 hizo que quienes adoptaron HTML5 llegaran al mundo móvil con multimedia. Los que se hicieron los cancheros diciendo “ya lo hicimos en Flash” se habrán enterado que esta semana Adobe anunció que abandona Flash para los móviles. Cuántos proyectos habrá que volver a tocar. Dicho sea de paso, yo pienso que Java (en web) va por el mismo camino.
- Last, but not least, si alguien se va a comprar un teléfono hoy, se compra un teléfono de los nuevos. Es lo que le vende y lo que mejor le va a andar hoy y mañana. Hacer un proyecto no es tan distinto, hay que usar lo nuevo para que dure más y funcione mejor hoy y mañana. Mejor aún: no hay diferencia de costos entre HTML4 y HTML5. ¿Por qué no elegir el mejor?
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.