Archive: 2011
109 posts published in 2011
A black and white figure's thought-hive
109 posts published in 2011
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.
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.
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?
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.
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.
Encontré tres preguntas particularmente útiles en el foro de UX de Stack Exchange, las cuales son:
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.
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.
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.
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.
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.
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.
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.
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.
BuiltWith es un servicio web que nos proporciona información sobre las tecnologías que soportan un determinado sitio. Más allá de sólo describir los módulos básicos de Apache y el tipo de servidor sobre el que se encuentre dicho sitio, nos comenta sobre varios tipos de utilización de contenido, como CDN, codificación, qué tipo de frameworks se están utilizando, qué tipo de CMS si se puede reconocer, librerías JavaScript, información sobre HTML si se encuentra disponible, y un poco más.
Nos dejan investigar también sobre otros sitios que usen la misma tecnología, pero no lo veo realmente útil a menos que queramos comparar determinados sitios que usen plataformas algo raras. Por ejempo, una búsqueda entre qué sitios usan Wordpress no aportará nada interesante, una búsqueda entre qué sitios utilizan codificación UTF8 creo que no sirve de mucho. De todos modos, este tipo de reportes son pagos, pero la información general no lo es.
Soy un zorrinito curioso.
La gente de Github no me deja de sorprender, parece que siempre tuvieran algo nuevo. En este caso, me crucé con algo que no es demasiado funcional, pero sí muy interesante para lograr buenas interfaces de usuario.
Han notado cómo GMail utiliza el título de la página/tab para avisarnos de cuando tenemos un mail nuevo, incluso si estamos en otro tab? Bueno, algo muy parecido se puede hacer con los favicons, cambiandolos para dar una notificación al usuario. Algo parecido hace Google Calendar, poniendo un favicon distinto cada día con la fecha actual.
El código fuente de este proyecto se puede encontrar en este sitio de Github: Notificon.
Recuerdo haber leído unas pruebas cross-browser del soporte de favicons y su posible utilización. El único caso en donde no funcionaban era en Safari, ya que en lugar de mostrarse los iconos, se mostraba un ícono propio de Safari, y dependiendo de la cantidad de tabs, directamente no se mostraba nada. Desafortunadamente, olvidé en dónde leí eso (y mis búsquedas no dieron resultados). El estudio concluía que Safari debería ponerse al tanto con el resto de los navegadores.
Soy un zorrinito visible.
Me encontré con dos fuentes de documentación extra-oficial de jQuery, con lo cual, por supuesto, pueden estar desactualizados y hasta incorrectos. Pero lo interesante de ellos es que nos ofrecen una navegación un poco distinta que la que la documentación original nos ofrece.
Es el caso, por ejemplo, de Visual jQuery (actualmente en 1.2.6), que nos permite navegar la documentación de forma jerárquica, sin perder el nivel de dónde estábamos. Además, encontré que es muy orientado a ejemplos, con lo que es fácil llegar al punto de lo que hace cada cosa y cómo se utiliza.
jQAPI es un caso parecido, y parecería que la navegación es aún más fácil en este caso, incluyendo búsqueda HTML5 y todo. Me pareció que este tiene explicaciones más detalladas y ejemplos más completos.
Soy un zorrinito javascript.
Este link que me llegó del nuevo Delicious trata de un rant de Zed Shaw titulado Programmers need to learn statistics or I will kill them all. Trata de las frustraciones que él encuentra al momento de discutir resultados de tests y generalizaciones con determinados programadores con los que ha trabajado.
Si bien no deja de ser un rant y por eso no es realmente informativo, es un buen punto de partida para entender por qué el conocimiento básico que tenemos de estadística (si no todos, probablemente una gran mayoría). Creo que muchos hemos pecado de cometer las mismas acciones que él cuenta en su artículo, como dar un número grande de pruebas, sacar un promedio y entender que ese es el promedio de los casos, cuando hay muchos otros factores que afectan y muchos otros datos que aportan información y nunca se tienen en cuenta. Para sacar una frasecita de su artículo: “El punto es que si ustedes dan un promedio sin mostrar la desviación estándar, perdieron completamente el punto de siquiera intentar medir algo”.
Soy un zorrinito promedio.
Me crucé de casualidad (y ya ni recuerdo cómo) con un artículo de un blog llamado Algoritmic symphonies from one line of code – how and why?, en donde el autor mostraba un viejo experimento que había hecho: hacer iterar una variable sobre valores incrementales, y que una función de esa variable fuera enviada a la salida de audio.
Resulta que experimentando con distintas fórmulas pudo crear sonidos y hasta “canciones” bastante avanzados. Por supuesto, no podremos compararlos con obras musicales actuales (excepto que hablemos de dubstep o industrial experimental – encajarían bien ahí), pero aún así es increíble la complejidad que estos pueden adquirir con esas simples pruebas. Allí es en donde el autor encuentra esa belleza escondida de las fórmulas.
Por si fuera poco, alguien hizo una versión en JavaScript, que pueden probar y divertirse creando música (o ruido) desde fórmulas, y hasta estéreo (acompañamiento!).
Soy un zorrinito musical.
Desde los geniales posts que nuestro amigo Alan Pasho ha escrito para el blog de CommonSense, en la serie de Is Your Website or App Secure? (recomiendo la lectura de todos ellos), me encontré ayer con los lieamientos que Mozilla impone a sus desarrolladores como medidas de seguridad al momento de desarrollar aplicaciones.
Cabe destacar que estos lineamientos, WebAppSec/Secure Coding Guidelines, no son nada cortos, pero sí detallados, y se cubren tópicos desde manejo de sesiones a (lo más básico) validación y autenticación. Si alguien está pensando en armar un checklist, este es muy buen comienzo, y si alguien quiere una guía completa de qué cubrir, puede leer esto o, por supueto, todo el contenido de OWASP y los libros relacionados.
Sabemos que la seguridad es todo un mundo, pero cuando se trata de hacer verificaciones o checkeos, siempre necesitamos una lista rápida,y tanto los posts de Alan como la guía de Mozilla son un buen lugar para hacer esa checklist de items.
Soy un zorrinito asegurado.
Como de costumbre, la gente de DragonJar postea cosas muy útiles e informativas en el ámbito de la seguridad. En este caso se trata de dar a conocer HackArmoury, un sitio dedicado a ser un repositorio de herramientas lo más accesible posible, de forma que estemos en donde estemos, con las restricciones que tengamos, siempre podamos acceder a las herramientas útiles en el ámbito de la seguridad.
Cabe destacar que este sitio ha innovado en cuanto a las formas que se tiene de acceder a él. No sólo están el típico HTTP y FTP, sino que también podemos entrar a través de Samba (SMB), rsync, IPv6, TFTP, SVN.. por supuesto, lo estarán expandiendo en el futuro. (Por qué no, por ejemplo… email?)
Soy un zorrinito armado.
Cuando exponemos a los usuarios la posibilidad de agregar bugs para revisar, es muy importante que este proceso no sea ni complicado ni difícil de lograr. Debe ser algo que cualquiera pueda entender, y que no sea una interrupción al flujo de la aplicación para que los usuarios puedan reportar también detalles que necesiten ser arreglados.
Si han visto la forma en la que Google Plus permite dar feedback, habrán notado que, aunque es una forma simple, involucra varios pasos que hacen del proceso algo “pesado”.
BugHerd se encarga de ambas cosas. En cuanto a la interfaz, sólo se trata de señalar algo en la pantalla y un texto para decir qué está mal al respecto. En cuanto al proceso, solo se trata de una interfaz con un botón y un campo de texto. Bastante simple, bastante claro.
Está de más aclarar que con un proceso tan simple el feedback de los usuarios será mucho. No hagan esto si no están dispuestos a prestar atención a lo que los usuarios quieren.
Por otro lado, BugHerd es pago, pero los precios no son altos para nada.
Soy un zorrinito buggeado.
La idea me parece fantástica, pero la forma en la que se desarrolló, no tanto. La idea era, Scalable and Modular Architecture for CSS, una organización del código CSS de una aplicación para que fuera dividido en forma modular. De esta forma, habría determinados estilos base, y otros estilos pertenecientes a módulos que especificarían cosas extra, o modificarían detalles (aunque no deberían) de los estilos base.
Ahora, los estilos base se subdividen, a su vez, en estilos que tienen que ver con el layout, y los que no se llaman “base”. Por último, hay una cuarta clasificación que tiene que ver con estilos de estados, es decir, cuando algo está activado, cuando se encuentra deshabilitado, etc.
Si bien la idea está muy interesante, veo algunos puntos grises en cuanto se debe determinar qué estilo pertenece a qué. Hay reglas CSS particulares que van a ser seguramente pertenecientes a una de las anteriores categorías mientras otras no, pero podemos estar hablando de los mismos elementos en pantalla. Para poder lograrlo de forma precisa, debería tenerse demasiado cuidado y una gran cantidad de reglas que aplicarían a un determinado elemento. En ese sentido no se me hace demasiado natural, aparte de la necesidad de marcar de múltiples formas un mismo elemento (un id, varias clases).
Sin embargo, me parece un muy buen comienzo, y quisiera escuchar ideas, porque creo que esta arquitectura es una base muy poderosa para hacer de CSS complejo algo muy ordenado.
Soy un zorrinito estilizado.
De parte de la gente de HTML5 Rocks! tenemos un pequeño post con dos videos cortos (7 minutos cada uno), llamado 7 minute videos: Javascript Console Protips & newish DOM APIs, en donde Paul Irish nos cuenta sobre determinados truquillos que podemos utilizar para debuggear JavaScript, mayormente en Chrome (aunque dos de los trucos se aplican a Firefox y a Opera).
Personalmente no me encuentro desarrollando mucho JavaScript pero creo que adoptaré alguno de estos trucos, especialmente el $0 que hace las cosas terriblemente más fácil, junto con keys(), console.time() y copy(). A ver si puedo ponerlos en mi navaja suiza diara.
Soy un zorrinito loggeado.
Del blog de Seth Godin:
Corre tu propia carrera
El espejo retrovisor es una de las herramientas motivacionales más efectivas jamás creadas.
No hay duda que mucha gente acelera en el rostro de la competencia. Preguntamos “cómo le fue al resto de la clase?” Escuchamos a quién respira en nuestras nucas. Y descubrimos que la competencia a veces saca lo mejor de nosotros.
Pero hay una desventaja. Años atrás, durante mi nado de larga distancia (por Long Island Sound… agua fría, medusas, en todo el trayecto), la competencia estaba bastante dura. Desde el bote hasta la línea de comienzo había cientos de nadadores, estirándose, presumiendo, pavoneándose y calentandosé. Para el momento en donde tocamos el agua, todos estaban corriendo la carrera de los demás. El comienzo fue una explosión de ego y adrenalina. Veinte minutos después, la mitad de los participantes estaban exhaustos, con tres horas faltando.
Si vas a contar con la competencia para sacar tu mejor trabajo, entregaste el control sobre tu objeto más preciado. El verdadero logro viene de correr hacia adelante cuando nadie más ve un camino– y detenerse cuando la aceleración no te llevará a donde quieras ir.
Si eres dependiente de la competencia entonces estás contado con la calidad de esos que se muestran a sí mismo para determinar qué tan bien lo harás tú. Peor aún, te has inscripto para una carrera de empates terribles y falsos como la mejor forma de hacer tu trabajo.
La auto-motivación es y siempre será la forma de motivación más importante. Conducir con tus ojos en el espejo retrovisor es agotador. Es más fácil que nada medir tu performance contra la de los demás, pero si no te está ayudando con tu misión, detente.
Ya alguna vez había mencionado una librería JavaScript para encriptar datos (jCryption), pero nunca está de más considerar otras alternativas. En este caso se trata de cryptico.js. El proyecto también es de Open Source y nos permite usar AES y RSA (o eso leí, pero la documentación sólo menciona RSA), y con una serie de métodos muy simples, nos permite operar con cadenas que queramos utilizar para transmitir de forma segura.
Lo curioso es que podemos generar claves especificando el tamaño de la misma, pudiendo ir desde una clave de 512 bits hasta 8192… pedazo de clave.
Este tipo de encriptación, por el hecho requerir una clave “insegura” para generar la clave RSA, no es inseguro de por sí. Recordemos que estamos hablando de encriptación asimétrica, de forma que por más que se tenga la clave generada, no hay inseguridad, puesto que es la otra clave (la que se queda con nosotros, la privada) la que se usará para desencriptar los datos.
Soy un zorrinito encriptado.
IfTTT.com es un servicio que me atrevo a calificar de “maravilloso” en donde nos permiten integrar distintas redes sociales o servicios 2.0 en workflows que nosotros definiremos. Dependiendo del uso que le demos, puede sernos más o menos útiles.
Aunque su página de WTF lo explica, les daré un ejemplo de lo que se puede hacer para que lo vean de una forma simple, con unas reglas que uso yo:
Y este servicio todavía está en Beta, me encantaría que agregaran en el futuro nuevos servicios y nuevas integraciones. La idea está fantástica y su utilidad es impresionante. Por supuesto, también podemos hacer interactuar muchos otros servicios (Craiglist, Evernote, Youtube, feeds, Facebook, Twitter, teléfono y sms!, linked.in, vimeo…).
Como extra, podemos utilizar “recetas” (tareas que ya otra gente ha programado) o crear las nuestras propias.
¿Para qué lo utilizarían ustedes?
Soy un zorrinito automatizado.
Ayer hablé un ratito más con JH y siendo que no hay una sola charla que pueda tener con él en donde no aprenda algo, me comentó de su más reciente descubrimiento: Chirpy.
Chirpy es un proyecto open source de un plugin para Visual Studio que nos permite trabajar con archivos js, css, .less y T4 de forma casi nativa. Además, nos genera minimizaciones, hojas de estilo y transformaciones a medida que vamos guardando los archivos, casi “real time” a como estamos trabajando. Básicamente, nos permite extender la cantidad de herramientas que disponemos en tiempo de diseño.
No lo he probado personalmente, y no sé si es que introduzca algo de lentitud al entorno pero parece realmente convenir para tener una más variedad de posibilidades al momento de desarrollar, ahorrándonos tiempos de pruebas e integración.
Soy un zorrinito integrado.
Justo ayer, rondando la medianoche, JH me envió por email un link a este proyecto llamado Combres 2.0, una librería para optimización de sitios ASP.NET. Recuerdan el caso de Minify para PHP o mod_pagespeed para Apache, este es el turno de ASP.NET.
Esta librería nos permite incluir recursos haciendo uso de ella, de forma que al momento de generar los links también se hacen referentes a una dirección que esta librería manejará, y se encarga del cacheo, compresión y minimizado de los documentos. La reducción de HTTP requests es, por lejos, una de las ganancias más útiles y menos costosas de lograr que nos ofrece.
En el sitio de CodeProject (en donde se encuentra alojado) se pueden ver varias de las aplicaciones y usos que tiene. Veré si prontamente puedo comenzar a utilizarla.
Soy un zorrinito optimizado.
Me encontré en Del.icio.us este interesante artículo (de agradable estética, dicho sea de paso), titulado 100 ways to get more done, que es un buen listado de muchos consejos. Aunque no me encuentro de acuerdo con todos ellos, una gran mayoría son realmente útiles e interesantes para investigar.
Leer estos me volvió a llevar al método de Inbox Zero de Merlin Mann, una técnica muy interesante de concentrarse para hacer lo que uno tiene que hacer cuando el email se convierte en una distracción constante. Creo que los consejos no aplican realmente a todo tipo de situación pero tiene un par de técnicas interesantes. Yo estoy comenzando a aplicarlo, con algunas variantes para que sea menos drástico al principio, pero todavía no puedo hablar de los resultados… aunque de comienzo sí puedo decir que ver el inbox vacío genera una satisfacción muy particular.
Soy un zorrinito productivo.
Este artículo de Smashing Magazine habla muy en detalle sobre la comunidad de desarrolladores de navegadores (una buena gran mayoría de ellos) y cómo es bienvenido el feedback de los usuarios para mejorar los navegadores mismos.
Explica un poco de qué forma se puede encontrar o aislar algo que creemos que es un bug, que también sirve para método de solución de problemas: una vez aislado el comportamiento no deseado siempre podemos idear un workaround (que es, de hecho, como surgieron muchos de los hacks vigentes para hacer las cosas funcionar cuando no funcionan como deberían). El resto del artículo nos explica cómo reportar este comportamiento, bajo las líneas básicas de: ver si realmente es inesperado lo que ocurre, ver si no fue reportado antes, y cómo hacer un buen reporte de bug.
Allí están también los links a los bugtrackers de los navegadores más importantes: Internet Explorer, Firefox, Opera, Webkit (Safari/Chrome) y Chrome. (Chrome también tiene otro para el sistema de Javascript, V8).
Para los investigadores, también es interesante poder revisar esos links para ver el estado de avance y noticias de implementaciones de cada navegador.
Soy un zorrinito buggeado.
Alguna vez les conté de Xenocode, una suerte de plugins que ejecutándose virtualizaban distintas versiones de Internet Explorer (aunque me pregunto en dónde dejé ese artículo). Ahora que no está más disponible, entre nuestras opciones disponibles para hacer testing de IE está Utilu IE Collection, un conjunto de versiones standalone de Internet explorer (desde la 2.0!) para poder utilizar en nuestro testing de cross-browsing.
No sólo eso, la gente de Utilu también ha trabajado para ofrecer lo mismo en el mundo de Firefox, coherentemente llamado Utilu Mozilla Firefox Collection.
Al ser todas standalone se pueden correr en paralelo y comparar. Todo sin dejar la comodidad de tu localhost.
Soy un zorrinito 2.0, 3.0, 4.0, 5.0, 5.5, 6.0, 7.0, 8.0, 9.0 y 10 CTP 1.
De la misma forma que hace poco hablamos de Adaptive Images, hoy tenemos una propuesta parecida para videos, llamada FitVids (también de parte de la gente de CSS Tricks). Más que una configuración del lado del servidor, FitVids se trata de un plugin de jQuery que nos permite hacer el tamaño de los videos fluidos, ajustados al máximo de su contenedor, permitiendo que las cajas de los videos sean también fluidos con el diseño de la página.
Hay un video de demostración, y mejor aún, la misma página es la demostración de su funcionamiento, en donde podemos cambiar el tamaño de la ventana y ver cómo el video se escala de forma proporcional. Haciéndolo un par de veces logré hacer crashear el plugin de Flash en Chrome, pero estoy seguro que eso es un problema relacionado con el navegador y con el plugin, no con el funcionamiento del plugin en sí.
Según cuentan, ya soporta una buena cantidad de proveedores de video populares (por supuesto, Youtube y Vimeo son los dos primeros de la lista), con lo cual ya debería ser útil para el 99% de todos nosotros.
Soy un zorrinito adaptativo.
Las redes sociales siempre fueron una preocupación en cuanto a la privacidad de los datos y la forma en la que fácilmente otras personas nos pueden engañar. De hecho, mientras mejor cumplan su trabajo, más peligrosas van a ser en este sentido.
Es por eso que la gente de DragonJar hizo un buen post, casi-recopilatorio, sobre este tema. Se titula: Cómo conservar la privacidad en las redes sociales. En él nos explican una serie de conceptos básicos a modo de caricatura (orientado a chicos que ya son familiares con estas tecnologías) y de ahí una serie de posts que ellos mismos poseen sobre la seguridad en internet, y guías específicas para proteger los datos en cada una de las redes sociales que hoy son más populares (Facebook, Flickr, Hi5, Last.FM, LinkedIn, MySpace, Orkut, Tuenti, Twitter, Windows Live Spaces, Xing y Youtube).
Soy un zorrinito privado.
Nuevamente de la gente de CSS Tricks me llega un dato de una librería muy útil. En este caso es Adaptive Images, es una librería en PHP que nos permite servir imágenes con el tamaño justo dependiendo del tipo de cliente. No sólo se hace la diferenciación del tipo de cliente, sino del tamaño de la pantalla real.
Cómo es que funciona? Básicamente al momento de cargar la página un javascript se ejecuta antes de que ejecute el cuerpo. Este javascript carga una cookie en nuestro navegador con esa información de tamaño de pantalla, y cuando nuestro navegador procede a buscar las imágenes, ese cookie viaja también y el servidor puede devolver una imagen del tamaño justo.
Por supuesto que posee varias opciones de configuración para servir imágenes de la mejor forma para nuestra necesidad, y por supuesto, podemos servir una imagen de baja resolución si la ventana del navegador tenía poco espacio y luego se amplió. Pero hay workarounds para todo, de forma que sigue siendo una herramienta útil.
Soy un zorrinito adaptativo.
Títulos amarillistas si los hay, MD ha compartido con nosotros este link de la gente de ForoAlfa, un grupo que habla sobre la usabilidad en su forma teórica, y eso es en general de lo que trata este artículo. El artículo, también bajo el título de La Usabilidad ha muerto. ¡Que viva la usabilidad! habla de cómo la web actual (y los que trabajamos en el software en general) ha degenerado el concepto de usabilidad.
Según dicen (y si lo entendí correctamente), la teoría sobre la usabilidad se desarrolló como una serie de medidas y patrones que permitía que las interfaces pudieran dialogar con un usuario y mantener una conversación fluida. Hoy cuando hablamos de usabilidad hablamos de la forma en la que se mueven las pantallas, cuánto se ve y cuánto no se ve, cómo se scrollea, cómo pasan las imágenes y los colores que usamos. Por supuesto que está relacionado, pero no conserva la idea pura original de lo que es usabilidad.
En mi opinión el artículo no llega a una conclusión definitiva de cuál sea el problema y qué habría que hacer para solucionarlo, sino que nos cuenta esta historia y nos hace pensar un poco más allá de lo que vemos en el día a día sobre conceptos que quizá estamos demasiado acostumbrados a manejar.
Soy un zorrinito inusable.
Seguramente nosotros nos sentimos protegidos porque tenemos… qué? Un antivirus y un firewall? Muchos de nosotros ni eso debemos tener.
Sin embargo hay gente que se toma la seguridad en serio, y está muy interesante analizar esos casos para aprender qué hacen y por qué. Y creanmé, que las posibilidades que se pueden abordar son enormes y extrañamente complejas. ¿Has pensado que podrías encriptar todo lo que se almacena en tu RAM? ¿Has pensado en llevar contigo tu partición de booteo para que nadie pueda encender tu máquina? ¿Has pensado en usar Windows como honeypot para que alguien lo use y puedas detectar en donde está tu máquina? ¿Restringir los permisos del navegador?
Y la lista continúa. Por supuesto, según dice el autor de este artículo, se puede hacer mucho más, y no estoy realmente seguro, pero por lo menos lo hice un poco más difícil.
El artículo en cuestión es Protecting a laptop from Simple and Sophisticated Attacks, de Mike Cardwell.
Soy un zorrinito inseguro.
Muchos me felicitaron por cómo se veía mi presentación sobre una pequeña encuesta sobre redes sociales, aunque la verdad los créditos no me los debo llevar yo sino Prezi… pero lo bueno es que todos podemos tener algo así en nuestros sitios sin usar ningún servicio de terceros. Deck.js (lo encontré en CSS Tricks) es una librería JavaScript que utilizando HTML5 nos permite crear presentaciones con una visualización muy atractiva (lo cual también ayuda a llamar la atención y transmitir nuestro mensaje).
Deck.js nos permite crear una variedad de animaciones y formatos de presentación, y lo bueno es que nos ofrecen distintos downloads dependiendo de nuestro nivel de habilidad con HTML/CSS/JavaScript, para que estemos cómodos utilizándolo.
A ver quién me muestra la primera implementación que hayan hecho con deck.js así lo coloco aquí!
Soy un zorrinito animado.
Esto no es particularmente nuevo, y de hecho, he escuchado de algunas personas que ya se han adquirido uno de estos productos. Se trata de una versión “simpática”/”neko” de Emotiv, aunque realmente no sé si las marcas estén relacionadas. Aunque está claro que la tecnología detrás de esto si lo está.
El producto en sí se llama Necomimi Neurowear (gracias MicroSiervos), y se trata de una cinta que ajustada a nuestra cabeza, detecta nuestros cambios emocionales y mueve unas orejitas de gato acorde a ellas. Realmente lo creamos o no útil, no podemos negar que la tecnología está alcanzando límites de ciencia ficción.
Ni hablar de una noticia que me ha llegado ayer por Twitter llamada “La frontera entre neurociencia y neurotecnología ha sido superada” (gracias Fernando!), que claramente muestra que los avances son cada vez mayores.
Soy un neurozorrinito.
Sabemos que medir numéricamente la calidad de cierto código no es nada fácil, tratesé del lenguaje que se trate. Siempre hay muchos factores que no afectan en nada a lo funcional, pero que sí afectan a qué tan legible es el código, qué tan mantenible es, y qué tanto puede evolucionar de forma “grácil” sin ser un peso para el futuro de los programadores.
HTML y CSS son un caso particular, porque a diferencia de otros lenguajes, no son lenguajes de programación, pero sí se hacen aplicaciones con ellos. Alguna vez alguien me dijo que sí deberían considerarse lenguajes de programación porque aunque no fueran instrucciones, de alguna forma estábamos trabajando con datos, su procesamiento, y su salida… pero esa es otra historia.
Al momento de medir la calidad de estos lenguajes, existe un problema extra: ya no hay funcionalidad que medir, sólo el código en sí (porque no tienen interacción directa como un lenguaje que se ejecuta). Entonces el desafío se pone más interesante. Google ha atacado este problema y ha escrito sobre como validar y trackear la calidad del código de sus páginas. El artículo en sí no es ni extenso ni detallado, pero despierta algunas ideas que pueden ser útiles para profundizar en este tema. Un punto muy importante es, cualquiera sea el criterio que se tome, trackearlo. De esa forma podemos ver si hay mejora o no… o si el criterio realmente nos dice algo o no.
Soy un zorrinito de calidad.
Esto no es ninguna novedad, pero para mí sí lo es: La ley de Benford es una ley estadística que dice que en muestras númericas del mundo real, hay una distribución determinada de la aparición de los primeros dígitos en esos números. Es decir, que si midiéramos a todos los seres humanos, el número que más aparecería en esas mediciones, los números que empiezan con 1 tendrían cierta distribución, los que empiezan con 2 tendrían otra, etc.
Esto ha sido comprobado con una buena cantidad de ejemplos (incluso con mismas muestras y distintos sistemas métricos). Por supuesto, hay mucha controversia al respecto pero no quiero hablar de ella ahora.
Lo interesante es el tipo de aplicaciones que esto tiene. A veces se usa como regla heurística para determinar fraudes en aplicaciones online. ¿Quién lo usa? Apple por ejemplo…. podría. Este post de Rob Conery no me deja del todo claro si Apple hace actualmente uso de esta técnica o no, pero está claro que es totalmente aplicable. Su post está titulado apropiadamente: Could Benford’s Law have saved an Apple ID?… maybe.
Checkeen el testeo estadístico y la forma en la que se aplica, es altamente ingeniosa, pero lo más curioso es cómo puede aplicarse una (o más de una) simple regla estadística para, a modo de un quick datamining, determinar cuáles situaciones están realmente fuera de lo esperado y detectarlas como fraude. Esto es aplicable a muchos otros campos, y por supuesto, no sólo a ventas online.
Soy un zorrinito fraudulento.
Como ya sabemos, la web está llena de herramientas gratis que podemos utilizar, y el load testing no queda excluído. Hace poco me crucé con una herramienta llamada LoadImpact, que, como su nombre nos da a pensar, es una herramienta web que permite hacer test de stress sobre websites. En este caso, para acceder a la totalidad de sus funcionalidades deberíamos subscribirnos y abonar un pago, pero también podemos acceder sin registrarnos a una batería de tests gratuitos.
Desafortunadamente los tests al correr no nos dan información demasiado detallada sobre lo que ocurre tras el telón, pero logra el objetivo de mantener los resultados y la información simple como para poder detectar cualquier problema de performance que la concurrencia de usuarios nos pudiera llegar a dar.
Soy un zorrinito concurrente.
Gracias a una característica propia de los browsers en cuanto a la forma que cachean elementos (algo que está funcionando desde hace un buen tiempo ya), resulta que es posible que explotando esa funcionalidad se pueda hacer trackeo de usuarios de la misma forma que podríamos hacerlo con cookies u otros elementos persistentes (recuerdan EverCookie?).
Y resulta que las técnicas no son simples de salvar para que esto no ocurra. Como el autor lo menciona en su artículo, Preventing Web Tracking via de Browser Cache, “esto no es algo con un arreglo simple”.
él nos explica también cómo se puede lograr este tracking con varios métodos, sin nada que alerte al usuario de estar siendo trackeado.
¿Ustedes qué piensan? ¿Puede esto ser un problema para la seguridad?
Soy un zorrinito cacheado.
Ya hemos hablado mucho de educación online con las distintas posibilidades que la internet ofrece a través de videos, podcasts y demás multimedia. Sin embargo, por lo general es raro que las instituciones que crean este contenido se vinculen demasiado con los consumidores de dicho contenido.
No es el caso de la gente de Stanford, que hoy está ofreciendo anotarse a tres cursos en particular: Introduction to Databases, Introduction to Artificial Intelligence, Machine Learning. Cualquiera puede anotarse y cursará el mismo curso que la gente de Stanford cursará, incluyendo los exámenes y todo. No obtendremos un título oficial de Stanford pero sí un certificado de haber pasado el curso firmado por los profesores (que son respectivamente Jennifer Widom, Peter Norvig con Sebastian Thrun, y Andrew Ng). No es poca cosa.
No sé ustedes, pero yo me anoté y pienso formar parte de esa experiencia. Gracias i.MicroSiervos por haber pasado el dato!
Soy un zorrinito stanford.
Para los que no conocen la sigla, TDD representa el concepto de Test Driven Development, la metodología de hacer las pruebas de lo que queremos lograr antes del código.
Este es el caso de alguien que estaba demostrando esa metodología ante uno de los escépticos que no creen que sea realmente aplicable. “Funciona muy bien en la teoría pero al momento de la verdad no se puede respetar totalmente”, pensaba. Ese es el caso de Rob Conery, explicando las técnicas de TDD de Brad Wilson.
Lo que él hizo fue, intencionalmente, planear una situación en un sistema medianamente complejo, para luego introducir un nuevo requerimiento que cambiaba todo el diseño. Parece que entonces lo que Wilson hizo fue, en lugar de tirar todo y comenzar de cero, ir adaptando las pruebas gradualmente, ir refactorizándolas hasta que comenzaron a formar “clases”, que luego se movieron del entorno de pruebas al sistema real.
“Un concepto en el que no había pensado nunca” – menciona Conery – “usar el archivo de pruebas como una especie de útero {de dónde nacen las clases}”.
Soy un zorrinito TDD.
Desde CSS Tricks (muy buen sitio de referencia, por cierto) me llegó un artículo llamado What Makes for a Semantic Class Name? Este tema parece algo tonto desde su concepción básica: “cómo nombrar clases de CSS”. En un principio, realmente no importa cómo se llamen, si el estilo está bien, se verá bien y será como nosotros queremos.
La situación se pone realmente interesante cuando estamos planeando nuestro sitio para el cambio, y entonces una clase como “hd24ba” no tiene mucho sentido (menos aún si la generó algún software nefasto de web development). Ahí es donde – la buena práctica dice – lo conveniente es trabajar con nombres de clases semánticos, que representen el real hecho de por qué son clases. Una clase de qué están representando, un tipo de qué objeto están estilizando.
Por supuesto que esta definición es algo vaga y entonces es difícil determinar cuál es el punto específico de abstracción es realmente semántico y cuando excedemos un punto límite que hace que no estemos hablando de nada.
Yo creo, aún así, que estas prácticas son bastante discutibles, y que las reglas se pueden torcer un poco. ¿Qué opinan?
Soy un zorrinito semántico.
Hablando de user experience en algo tan complejo como puede llegar a ser construir un sitio, hay pocos ejemplos que realmente muestran cómo puede hacerse fácil a la vez. Ya alguna vez CD me había mostrado Unbounce, una aplicación web que más que construir una página nos da varias herramientas útiles para marketing, como A/B Tests, analíticas y varias otras capacidades.
Pero la noticia para mi hoy es SiteCake, que encontré gracias a MicroSiervos. Según lo ponen ellos, es el tipo de aplicación que “hasta la abuela podría usar”. De verdad que sí, el diseño es muy intuitivo y la forma de interactuar también (aún así, dispositivos móviles quedan fuera). También disponen de un live demo que podemos utilizar sin registrarnos ni nada, pero aún así estimo que estando registrados tendremos una mayor variedad de opciones y capacidades.
Soy un zorrinito cake (a lie).
Me crucé con este plugin hace tiempo y lo quería probar pero no he tenido la oportunidad de hacerlo todavía. Este plugin envuelve básicamente toda la funcionalidad de subir archivos a un servidor, mostrar barras de progreso, permitir drag & drop, aparte de la clásica búsqueda de archivos desde cuadros de diálogo, selección múltiple y sin usar Flash.
También: posibilidad de cancelar el upload, preview de imágenes, formulario estándar si no hay JavaScript habilitado, extensible, y por supuesto, open source.
jQuery File Upload parece ser una de esas joyitas que nos dan un problema muy común ya solucionado.
Via Creativos Online, y alguien que lo compartió en Google Reader (perdón, pero ya no sé quién fue!).
Soy un zorrinito con soluciones.
Notesé que el título habla de mónadas, y no de monadas. Esto se trata de un artículo algo extenso, pero muy interesante, de cómo el concepto de mónadas se puede aplicar a cualquier lenguaje que permita el uso de objetos función o lambdas. Y qué lenguaje más simple para demostrar esto que JavaScript: Understanding Monads With JavaScript.
El artículo nos lleva sobre una estructura muy simple (un array utilizado como pila) en donde se ponen dos valores y luego se recuperan. Ese mismo proceso se va modificando en la forma en que se codifica hasta el punto de lograr las mónadas: objetos “computables” totalmente encapsulados en donde se abstrae de nosotros el procesamiento y la estructura, que a la vez, es más funcional que procedural.
Por supuesto que para los que venimos de programación orientada a objetos (OOP) esto nos debe de resultar un poco raro, pero podemos ver fácilmente la relación con otros lenguajes que no tienen esta orientación, sino una orientación, como decía, más funcional, y como podemos en base a ellos también modelar la encapsulación, en estructuras “fractaloides”, que contienen subpartes que, bajo la misma estructura, hacen más simple los procesamientos internos de nuestro sistema.
Suena muy loco, pero si logran comprender el artículo los invito a llevarlo hasta donde su imaginación lo permita, y luego preguntarse si el gráfico en ese blog no está muy apropiadamente colocado.
Soy un zorrinito funcional.
Esta noticia la vengo guardando desde Marzo, así que ya de nueva no tiene demasiado. Pero no deja de ser interesante. Resulta que para una de las versiones beta de Google Chrome (que de hecho, ya no es más beta), hay un nuevo attributo para los elementos input de HTML5 que básicamente permite obtener reconocimiento de voz. Este atributo, debería hacer que el navegador automáticamente reconozca nuestra vos como para rellenar un campo de texto, permitiendo búsquedas más rápidas o entrada de datos más correctas (si es que el usuario tiene problemas con la ortografía).
Por supuesto, como con todo reconocimiento de voz, hay que ver qué tal funciona. Yo estuve jugando un poco con el que ya está disponible en Google y parece funcionar bastante bien (en inglés). Por supuesto que con palabras raras tampoco funciona bien, parece estar muy basado en un diccionario… pero es una muy buena aproximación. Además de innovador, es en cierta forma divertido.
Soy un zorrinito reconocido por voz.
Scrollability es un pequeño proyecto/librería que podemos utilizar para dar una suerte de scroll para páginas móviles, del mismo tipo que los dispositivos iOS presentan en sus interfaces nativas. Por supuesto, queremos aprovechar esa características para poder dar al usuario una experiencia mucho más cercana a la que ya posee en su teléfono.
Si a eso le sumamos el uso de HTML5 y canvas, prácticamente podemos hacer aplicaciones iguales a las nativas o más aún, aprovechando las posibilidades de la web sin necesidad de pedir permiso al usuario (o al sistema) de usar una conexión saliente. Incluso más, no hace falta pedir permiso a Apple para instalar nada en el teléfono de nadie.
Sé que divagué un poco pero, ¿ustedes qué opinan?
Soy un zorrinito scrolleable.
Sacando esto del cajón de_ las aplicaciones que no hacen nada pero son útiles_, me encontré a ScriptSrc, una aplicación que mantiene las últimas versiones a varios frameworks y librerías comunes, como jQuery, mooTools, extJS, YUI, etc. Por supuesto, los scripts no están alojados en este propio servidor, sino que ellos nos dan el link al CDN correspondiente que lo aloja, permitiéndonos linkearlo directamente.
Y aunque hay un poco de discusión sobre si realmente conviene usar CDNs o mejor archivos pequeños en nuestro propio host, hay ciertas ventajas y desventajas. Las ventajas son ineludibles, las desventajas no lo son tanto.
Soy un zorrinito distribuido.
Ni más ni menos que como lo dice el título, este es el caso de alguien que con un poco de tiempo libre (bueno, mucho) y algo de ingenio (bueno, mucho) logró hacer un algoritmo genético que aprendiera a jugar al Tetris. Podemos ver tanto la teoría como la práctica en videos en el artículo de su blog. Allí se explican los detalles al respecto, que serán muy útiles para todos lo que estén interesados en dotar de inteligencia compleja a algún sistema y no sepan muy bien por dónde comenzar.
Soy un zorrinito genético.
De la gama de productos Google que todavía están en beta y en laboratorios (una buena cantidad), ahora tenemos a Google Swify, cuya funcionalidad es tomar archivos de Flash para convertirlos a HTML5.
No lo he probado, pero supongo que hará un uso excesivo de los elementos de Canvas y animación via JavaScript. Tampoco he sabido cuál sea la performance general de los resultados. Pero, sí podemos saber, que gracias a esta conversión, podremos fácilmente estar disponibles en cualquier tipo de plataforma.
Via i.MicroSiervos.
Soy un zorrinito HTML5.
Tratando de retomar la periodicidad de los links del día, hoy quiero hablar de Minify. Minify es una librería PHP de código abierto autocontenida que podemos utilizar para minimizar, unificar, cachear y definir nombres propios para recursos que queremos utilizar y mejorar la performance de nuestro sitio.
La librería no sólo soporta el trabajo con CSS, JS y HTML, minimizándolo completamente, sino que además puede ser utilizado para minimizar recursos bajo un solo nombre, y mejor aún, también es extensible para que podamos servir cualquier tipo de contenido de cualquier otra fuente. De hecho, lo probé cacheando y sirviendo recursos desde un sitio propio cuando los recursos en realidad son leídos de un lugar ajeno. Las ventajas de eso son el poder servir todo el JavaScript/CSS junto incluso aunque no nos pertenezcan, y ahorramos pedidos, y evitamos que el cliente deba acceder a múltiples dominios.
Y lo mejor, ni siquiera tenemos que andar haciendo referencia a los nombres de los archivos (aunque es la forma más fácil), ya que podemos definir grupos con nombres y utilizarlos. Eso nos brinda la ventaja de poder jugar mucho con eso y con el dinamismo de nuestra aplicación.
Pero en fin, lo interesante es la forma en la que minimiza, y lo simple que es de usar. ¡Dénle un intento!
Soy un zorrinito minimizado.
Building JavaScript Web Apps with MVC and Spine.js es un artículo muy explicativo de cómo debe ser la estructura de una aplicación MVC junto con herramientas de Spine.js que nos permitirán hacer más sólidas nuestras aplicaciones. Para aquellos que no sepan qué es MVC, aquí tienen una corta y buena explicación, y para los que no sepan cómo se usa Spine.js, también tienen un buen ejemplo.
Personalmente me gusta que la aproximación presentada es bastante limpia y lo suficientemente simple como para ser entendible sin confundir distintos conceptos. Recordemos que, aunque poco funcional, es un ejemplo para aprender de qué se trata.
Como extra, y para los más interesados, el artículo incluye una entrevista con uno de los desarrolladores de Spine y varios otros ejemplos.
Soy un zorrinito MVC.
Para todos aquellos que necesitábamos una forma de fácilmente comenzar con trabajos en HTML5, tenemos la opción de comenzar con algo ya estructurado sobre lo que podemos hacer nuestras modificaciones a gusto.
Me he encontrado principalmente con dos opciones muy interesantes. La primera de ellas es HTML5 BoilerPlate, del cual habíamos hablado algún momento en el pasado. Básicamente es un template que podemos utilizar para arrancar rápidamente con la configuración básica de una aplicación HTML5. Ya incluye un poco de configuraciones para cacheo, optimizaciones para mobile, un framework de testing y varias cosas más.
La segunda opción es G5 Framework, que bajo el mismo concepto tiene también varios elementos sobre los que podemos pararnos para impulsar nuestro proyecto. Este además ya tiene una buena cantidad de librerías incluidas con lo que podemos inmediatamente comenzar a constriur sobre ellas, y sobre un framework CSS, útil como siempre.
Quisiera ver qué trabajos se logran con estos frameworks.
Soy un zorrinito HTML5.
Quería dejar pasar un poco más de tiempo para poder indagar en detalle sobre esto, pero aparentemente no hay demasiada información, o al menos no más allá de lo que los fabricantes disponen para el público.
Aparentemente, hemos llegado al punto en donde la computación cuántica entró al mundo de los negocios, y hay empresas que ya disponen de estos bebés para la venta en general. Por supuesto, están un poco caros (según MicroSiervos, de donde me enteré, hablamos de unos 10 millones de dólares), y más todavía si consideramos que no son demasiado potentes todavía (128 qubits). Ah, no es para cualquier ambiente tampoco, la instalación toma algo así como un mes, en donde la mitad del tiempo son testeos de entorno para ver si nuestro cuarto (?) es lo suficientemente estable para la computación cuántica.
Sin embargo, son algo totalmente novedoso y por eso interesante, muy seguramente en poco tiempo ya tendremos modelos que sean más alcanzables y más estables para el resto del mundo, para nosotros, los no-ricos.
Si les interesa la tecnología detrás de esto, pueden visitar la misma página del producto, D-Wave One, en donde tienen varios documentos de distinto nivel técnico explicando cuál es la ciencia detrás del telón. Aparentemente, hasta hay varios papers de reconocimiento oficial por ahí.
Soy un zorrinito pobre.
Para quienes es sólo una palabra difícil, interpolación significa en el ámbito de funciones matemáticas, calcular valores aproximados de datos que no tenemos realmente. Esto se lleva al punto en donde para interpolar, podemos calcular una fórmula que rige los valores con los que estamos trabajando. Cuando estas funciones realmente predicen los datos con los que estamos trabajando, logramos obtener la “regla” por la que estos valores se guían.
Y esto es interesante cuando tenemos un conjunto de valores y luego tenemos que predecir su comportamiento en el futuro. Más que nada, en casos de la vida cotidiana. ¿A qué hora estará peor el tránsito? ¿Cuántas llamadas voy a recibir en cada momento del día?
Eureqa es un software que nos permite hacer este trabajo. Tomando un conjunto de datos y permitiéndonos cierto margen de error (muchos algoritmos de interpolación los permiten) nos permite identificar con cierta exactitud una fórmula que describa el comportamiento de nuestros datos. Se hace generando distintos bloques de operaciones aritméticas que den lugar a un resultado más o menos cercano a nuestro conjunto de datos. Personalmente no reconozco si este es un algoritmo de interpolación en particular, o sólo se trata de un algoritmo de búsqueda (en pocas palabras: prueba y error).
Muy relacionado, quiero dejar un link a Google Correlate, uno de los productos de Google que ahora se encuentran en sus laboratorios, que básicamente nos devuelve cuáles son las búsquedas más íntimamente relacionadas en cuanto a números con una búsqueda que a nosotros nos interese. Como extra, nos permite loggearnos y relacionar nuestro propio conjunto de datos con los que ellos tienen de sus búsqueda. O mejor aún, podemos dibujar nuestro propio gráfico y saber qué búsquedas tuvieron esa característica de interés (por ejemplo, una curva creciente y luego decreciente, algo que a la gente ya le aburrió).
Soy un zorrinito de datos relacionados.
A pesar de lo que parece, Normalize CSS no es lo mismo que reset CSS. El reset común vuelve todos los valores que los navegadores por defecto tienen distinto a 0, para que cualquier cambio que hagamos tenga el valor que nosotros asignemos.
Sin embargo, hay quienes realmente defienden la diferencia de estilos que cada navegador utiliza por defecto, para dar una experiencia del usuario distinta (y todavía me falta crear un post sobre el tema para exponerlo en detalle). Para ellos, Normalize CSS tiene mucho más sentido, porque no se fuerzan las propiedades a tener determinados valores, sino que sólo se normaliza todo a un estado consistente, desde el cual cada navegador utiliza sus valores por defecto.
Como extra, esta librería en cuestión también corrije varios errores comunes, o bugs que los navegadores pueden tener, y agrega ciertas mejoras de las que podemos aprovecharnos.
Soy un zorrinito normalizado.
Siguiendo con la seguidilla de links sobre CSS, hoy les traigo CSS Crush. En este caso en particular, se trata de una librería php que muy gentilmente se encarga de extender nuestras capacidades sobre CSS para evitar la repetición de código, mientras que la información que se envía al cliente es totalmente distinta.
El artículo que lo explica lo compara con otros pre-procesadores CSS que se han probado, y aparentemente CSS Crush sería el más completo de todos ellos. Debe ser server-side, debe tener la posibilidad de cachear, de utilizar variables a gusto, y CSS Crush provee todo eso y un poco más, permitiendo una generación de código muy consistente.
Soy un zorrinito preprocesado.
Para mi sorpresa, me encontré con un artículo de Mathias Bynens llamado In defense of CSS hacks – introducing “safe CSS hacks”. él habla e introduce el concepto de los hacks CSS. Permítanme hablar un poco sobre su idea.
él menciona que los CSS hacks son básicamente comportamiento especial que podemos invocar en cada navegador, algo que a veces es totalmente deseado, y no tiene por qué ser un problema o una mala práctica, sino que puede ser usado para muchas cosas. El uso más común que se le ha dado hoy en día es hacer “tweaks” específicos para la forma de renderización de cada navegador/versión y entonces lograr una visión consistente a lo largo de todos los navegadores.
Sin embargo, decir que tenemos control sobre el estilo de cada navegador y/o versión no necesariamente quiere decir que lo utilicemos sólo para lograr una vista homogénea. De hecho, gracias a ellas podemos utilizar determinadas características que hacen la exploración en un determinado navegador más natural dentro de las capacidades del mismo.
Esto, combinado con sentencias condicionales, hace que podamos tener mucho control sobre lo que el navegador utiliza de nuestro código.
Los dejo con el último ejemplo que el artículo plantea:
<!--[if lt IE 9]><html class="lte-ie8"><![endif]-->
<!--[if gt IE 8]><!--><html><!--<![endif]-->
.foo {
color: black;
}
.lte-ie8 .foo {
color: green; /* IE8 and older */
*color: blue; /* IE7 and older */
_color: red; /* IE6 and older */
}
Personalmente no me encuentro de acuerdo con esta propuesta, pero veo que tiene sus fundamentos. ¿Ideas? ¿Críticas?
Soy un zorrinito hackeado.
… te permite hacer este tipo de cosas:

¿Acaso a alguien más le encanta la forma en la que Twitter maneja los emails? Me agrada muchísimo la idea en donde hicieron el estilo de los emails totalmente similar al de la web. Simple, clara y con la información justa.
Notesé hasta la presencia de la barra superior, al estilo de la web, cuando notificaba de la existencia del nuevo Twitter. (De hecho, por alguna razón a veces lo sigo viendo. Hay alguien que todavía no esté usando la nueva versión?)
Soy un zorrinito simplista.
Recuerdan Freenet y cómo se basaba en el concepto de crear una internet paralela, totalmente descentralizada e indetectable? La idea sigue creciendo y el proyecto sigue obteniendo sus aportes, pero también han surgido esfuerzos paralelos, que también intentan solucionar alguno de los problemas que este proyecto tuvo.
Phantom es un proyecto similar. Básicamente plantea los mismos estándares y, para ser más precisos, lo indico desde la página de su proyecto:
- Completamente descentralizado
- Resistencia máxima a todo tipo de ataque DoS
- Anonimidad segura
- Encriptación de transporte segura de punta-a-punta
- Aislada completamente de la internet actual
- Protección máxima de identificación de uso del protocolo a través de análisis de tráfico
- Capaz de trabajar con altos volúmenes y buenos resultados
- Diseño genérico y abstraído compatible con todos los softwares de redes actuales y futuros
Por lo que vemos, no es nada de principiante, y personalmente no he podido probarlo pero sí me siento muy interesado en poder hacerlo. ¿Ustedes qué opinan?
Soy un zorrinito seguro.
Para aquellos que hayan trabajado con jQuery (o con otras librerías JavaScript) sabrá que la sintaxis para usar los selectores es prácticamente algo mágico, que hace muchísimo más simple nuestro trabajo.
Alguien pensó que sería muy buena idea poder seleccionar datos en esa forma desde una estructura en JSON y, justamente, creó JSONSelect. Esta pequeña librería todavía se encuentra en una etapa muy experimental, muy poco madura, pero ya podemos ver determinadas demostraciones en vivo funcionando.
Cuando tenemos un sistema que diseñamos nosotros y elegimos transmitir la mínima cantidad de datos posibles, no tiene mucho sentido la aplicación de esta técnica. Pero si necesitamos dejar muchos datos del lado del cliente (y por qué no, decidamos hacerlo en JSON), o estemos usando servicios de terceros que nos den una estructura algo compleja, puede que JSONSelect nos haga muy fácil, intuitivo y legible la forma en que estamos accediendo a determinados de esos datos.
Soy un zorrinito selectivo.
Hace poquito encontré esta serie de notas que conformaron un artículo sobre HTTP Load Testing. El artículo trata distintos puntos relativos a cómo se ve afectada la calidad del testing, a la vez de distintas técnicas para tener (o para evitar) de forma que los resultados del testing sean lo suficientemente confiables como para significar algo.
Por otro lado, siempre están esos consejos de la experiencia que podemos leer ahí también, y que si bien no tienen mucho sentido en un principio, tras haber hecho caso podemos ver la razón real de por qué se nos aconsejaba eso.
El artículo está muy interesante, incluso si están pensando en aplicarlo a load testing que no necesariamente sea HTTP, yo creo que aplicaría a cualquier tipo de testing cliente-servidor, y también varios de estos conceptos serían útiles para load testing de cualquier tipo de aplicación.
Soy un zorrinito cargado.
Acordándome de cuando hablé de Create Free iPhone Apps, quería charlar sobre esta aplicación web llamada Mokk.me, una aplicación que nos permite visualmente construir elementos de un diseño gráfico para iPhone y personalizar esos elementos a gusto.
Cabe aclarar que todo este sistema funciona en nuestra máquina, quizá la única funcionalidad del servidor es guardar URLs de diseños en particular para luego poder modificarlos. El UI es bastante completo y fácil de utilizar, prácticamente todo se puede hacer con un click, así que es una experiencia muy intuitiva.
Mejor aún, del resultado que tengamos, sólo tenemos que visitar un link para verificar en nuestro iPhone cómo se ve, y luego de eso ya podemos guardar ese HTML para utilizarlo en nuestro producto. Más simple, quizá sólo sea la otra aplicación, que hace todo por nosotros.
Soy un zorrinito mobile.
De los creadores de Compiladores en línea y de Más compiladores online y compitiendo con Máquinas virtuales en la web nos llega un linux que podemos correr en nuestro navegador. Emulado. En JavaScript.
Así como suena, este logro interesante llamado JavaScript PC Emulator parece correr totalmente del lado del cliente, con unos 150 Ks de memoria (aunque no lo he verificado).
Parece que este es otro de los proyectos de Fabrice Bellard, aunque no el único. Si no les suena el nombre de este muchacho, él es quién comenzó qemu, ffmpeg, lzexe… palabras grandes.
En fin, la versión de Linux en el navegador parece ser totalmente funcional, aunque no tiene mucho en él, y no me he puesto a investigar de qué forma podrían extenderse sus capabilidades, tampoco he visto que detecte dispositivos de comunicación más allá del clipboard (que tenemos disponible como un textbox en la página), como para poder instalar algo. Aún así… interesante, no?
Si leemos las notas técnicas al respecto veremos otros detalles y el hecho de que esto comenzó como pura diversión, pero que fácilmente podrían encontrársele algunas aplicaciones útiles. Cómo que no! Un sistema operativo corriendo en el navegador!
Soy un zorrinito asombrado.
Desde hace rato que tengo ganas de hacer algo en CSS3, y no dudo que muchos de ustedes también. La gran pregunta que todos debemos tener es “Cómo empezar?”. El qué hacer es un tema aparte, pero el cómo hacerlo es algo que seguramente podemos solucionar con algunas herramientas.
Algunas de estas herramientas están enumeradas en el artículo de Cats Who Code llamada 10 Useful tools for CSS3 development. En este pequeño artículo nos cuentan de distintas herramientas (todas muy visuales y atractivas) que nos permiten usar características de CSS3 en Internet Explorer, crear estilos desde cero, o trabajar con características en particular, como sombreados, refactorización, border-radius.
Hay dos en particular que más que herramientas son un algo especial. Una de ellas es Modernizr, del cual me sorprende no haber comentado antes: sin ningún tipo de JavaScript hace uso de selectores para utilizar condicionalmente características que pueden estar soportadas o no. (Aunque yo prefiero Selectivizr que emula esos comportamientos.),
El otro de ellos es simplemente una página de referencia, que es el HTML5 & CSS3 browser support. Su nombre ya es bastante indicativo de qué contenido tiene.
Y como extra, y como no podía ser de otra manera, un CSS3 Cheat sheet.
Soy un zorrinito CSS3.
Del cajón de las utilidades curiosas y técnicas que algún día puede que utilicemos, llega la aplicación web llamada Img to CSS, que, como su nombre lo indica, transforma imágenes en CSS.
En el fondo no es taaaaaaaan verdad, porque termina generando tablas con celdas de un píxel (o más, si se trata del mismo color) que con CSS inline genera los colores para la imagen. Esto puede ser interesante para enviar en mails, y que los destinatarios puedan ver imágenes sin necesidad de aceptar la bajada de imágenes. Sin embargo, no se puede utilizar en todas las formas que usamos las imágenes comunes.
Soy un zorrinito curioso.
Hay varias formas de aproximarse a la performance de una aplicación que está construida bajo los nuevos estándares e implementaciones de HTML5, CSS3, y, por supuesto, JavaScript. Como ya lo habíamos mencionado en la parte 1 de este artículo, el tutorial de HTML5 Rocks llamado Improving the performance of your HTML5 App trata varios puntos que son importantes para lograr una buena performance y una aplicación sólida.
Repasémoslos rápidamente:
-webkit-transform: translateZ(0);window.requestAnimationFrameY eso es, a muy grandes rasgos, este artículo. Realmente recomiendo que le den una leída a fondo si ustedes trabajan del lado de la web. Realmente no verán una página de la misma manera.
Soy un zorrinito performante.
Hace un tiempo Josh Resig, famoso por ser el creador de JQuery, anunció en su cuenta de Twitter que estaría brindando una especie de “conferencia de prensa”, una rueda de preguntas y respuestas en Reddit, específicamente en este thread.
Ahí podemos conocer un poco más de lo que él piensa sobre distintos temas, desde que le encantan los memes del Rage Guy hasta las propuestas que estaba pensando en plantear para la reestructuración del estándar del DOM. Podemos saber qué máquina usa y qué software hasta qué cosas estudió en la universidad y cómo hace para concentrarse en su trabajo.
Es el tipo de oportunidad de tener a un caso de éxito bien cerca para preguntar y escuchar respuestas. Desafortunadamente me enteré de esto cuando ya había ocurrido, pero habría estado interesante poder hacer un par de preguntas, no?
Soy un zorrinito preguntón.
Vamos a seguir con otra librería JavaScript, en este caso, Humane.js. Esta en particular se trata de un sistema de envío de mensajes al usuario a través de ventanas que recuerdan mucho al lightbox, sin ser tan intrusivas, ni difíciles de utilizar en el código. Estos mensajitos automáticamente se van luego de un tiempo o podemos esperar a que el usuario realice alguna acción (para asegurarnos de que haya efectivamente leído nuestro mensaje).
Para ser sincero, no lo veo como algo revolucionario o ni siquiera nuevo, pero desde la simplicidad de su utilización hasta lo simple de su implementación (la cual podemos ver en GitHub), hace que sea ideal para implementar en dispositivos en donde el espacio es importante, y la simplicidad del mensaje también. Yo creo que uno de estos se vería muy bien en aplicaciones móviles.
Soy un zorrinito simple.
Estuve peleando estos días con la posibilidad de crear sitios de SharePoint programáticamente desde mi código. Sin embargo, aún cuando esto fue hecho para un proyecto interno, tomé tanto de la internet que realmente siento que debo devolver algo a la comunidad. Además, no voy a divulgar nada relacionado al proyecto, así que aquí vamos.
Primero, buscando en internet una forma de crear estos sitios programáticamente, me topé con un artículo del 2007 de WinSmarts.com, llamado Programatically create a Sharepoint site based on a site definition. Aquí está el código de ese post:
public static bool CreateSite(string parentSiteURL, string siteURLRequested,
string siteTitle, string siteTemplateName)
{
bool returnCondition = false; // Assume failure.
const Int32 LOCALE_ID_ENGLISH = 1033;
using (SPSite siteCollection = new SPSite(parentSiteURL))
{
SPWeb parentWeb = siteCollection.OpenWeb();
SPWebTemplateCollection Templates = siteCollection.GetWebTemplates(Convert.ToUInt32(LOCALE_ID_ENGLISH));
SPWebTemplate siteTemplate = Templates[siteTemplateName];
if (parentWeb.Webs[siteURLRequested].Exists)
{
parentWeb.Webs.Delete(siteURLRequested);
}
parentWeb.Webs.Add(siteURLRequested, siteTitle, "", Convert.ToUInt32(LOCALE_ID_ENGLISH), siteTemplate, false, false);
// All is good?
returnCondition = true;
}
return returnCondition;
}
Lo que yo quería cambiar de esta solución era:
Entonces fui a revisar la lista de locales: SharePoint Locale ID (LCID) Table, y una lista de los identificadores de site templates, en un artículo llamado Create a site programmatically in moss.
Bueno… aquí vamos (cuidado, vienen enumeraciones largas):
public enum SPLocales: uint
{
Afrikaans /*af*/ = 1078,
Albanian /*sq*/ = 1052,
Arabic_UnitedArabEmirates /*ar-ae*/ = 14337,
Arabic_Bahrain /*ar-bh*/ = 15361,
Arabic_Algeria /*ar-dz*/ = 5121,
Arabic_Egypt /*ar-eg*/ = 3073,
Arabic_Iraq /*ar-iq*/ = 2049,
Arabic_Jordan /*ar-jo*/ = 11265,
Arabic_Kuwait /*ar-kw*/ = 13313,
Arabic_Lebanon /*ar-lb*/ = 12289,
Arabic_Libya /*ar-ly*/ = 4097,
Arabic_Morocco /*ar-ma*/ = 6145,
Arabic_Oman /*ar-om*/ = 8193,
Arabic_Qatar /*ar-qa*/ = 16385,
Arabic_SaudiArabia /*ar-sa*/ = 1025,
Arabic_Syria /*ar-sy*/ = 10241,
Arabic_Tunisia /*ar-tn*/ = 7169,
Arabic_Yemen /*ar-ye*/ = 9217,
Armenian /*hy*/ = 1067,
Azeri_Latin /*az-az*/ = 1068,
Azeri_Cyrillic /*az-az*/ = 2092,
Basque /*eu*/ = 1069,
Belarusian /*be*/ = 1059,
Bulgarian /*bg*/ = 1026,
Catalan /*ca*/ = 1027,
Chinese_China /*zh-cn*/ = 2052,
Chinese_HongKongSAR /*zh-hk*/ = 3076,
Chinese_MacauSAR /*zh-mo*/ = 5124,
Chinese_Singapore /*zh-sg*/ = 4100,
Chinese_Taiwan /*zh-tw*/ = 1028,
Croatian /*hr*/ = 1050,
Czech /*cs*/ = 1029,
Danish /*da*/ = 1030,
Dutch_TheNetherlands /*nl-nl*/ = 1043,
Dutch_Belgium /*nl-be*/ = 2067,
English_Australia /*en-au*/ = 3081,
English_Belize /*en-bz*/ = 10249,
English_Canada /*en-ca*/ = 4105,
English_Caribbean /*en-cb*/ = 9225,
English_Ireland /*en-ie*/ = 6153,
English_Jamaica /*en-jm*/ = 8201,
English_NewZealand /*en-nz*/ = 5129,
English_Phillippines /*en-ph*/ = 13321,
English_SouthAfrica /*en-za*/ = 7177,
English_Trinidad /*en-tt*/ = 11273,
English_UnitedKingdom /*en-gb*/ = 2057,
English_UnitedStates /*en-us*/ = 1033,
Estonian /*et*/ = 1061,
Farsi /*fa*/ = 1065,
Finnish /*fi*/ = 1035,
Faroese /*fo*/ = 1080,
French_France /*fr-fr*/ = 1036,
French_Belgium /*fr-be*/ = 2060,
French_Canada /*fr-ca*/ = 3084,
French_Luxembourg /*fr-lu*/ = 5132,
French_Switzerland /*fr-ch*/ = 4108,
Gaelic_Ireland /*gd-ie*/ = 2108,
Gaelic_Scotland /*gd*/ = 1084,
German_Germany /*de-de*/ = 1031,
German_Austria /*de-at*/ = 3079,
German_Liechtenstein /*de-li*/ = 5127,
German_Luxembourg /*de-lu*/ = 4103,
German_Switzerland /*de-ch*/ = 2055,
Greek /*el*/ = 1032,
Hebrew /*he*/ = 1037,
Hindi /*hi*/ = 1081,
Hungarian /*hu*/ = 1038,
Icelandic /*is*/ = 1039,
Indonesian /*id*/ = 1057,
Italian_Italy /*it-it*/ = 1040,
Italian_Switzerland /*it-ch*/ = 2064,
Japanese /*ja*/ = 1041,
Korean /*ko*/ = 1042,
Latvian /*lv*/ = 1062,
Lithuanian /*lt*/ = 1063,
FYRO_Macedonian /*mk*/ = 1071,
Malay_Malaysia /*ms-my*/ = 1086,
Malay_Brunei /*ms-bn*/ = 2110,
Maltese /*mt*/ = 1082,
Marathi /*mr*/ = 1102,
Norwegian_Bokmal /*no-no*/ = 1044,
Norwegian_Nynorsk /*no-no*/ = 2068,
Polish /*pl*/ = 1045,
Portuguese_Portugal /*pt-pt*/ = 2070,
Portuguese_Brazil /*pt-br*/ = 1046,
Raeto_Romance /*rm*/ = 1047,
Romanian_Romania /*ro*/ = 1048,
Romanian_RepublicOfMoldova /*ro-mo*/ = 2072,
Russian /*ru*/ = 1049,
Russian_RepublicOfMoldova /*ru-mo*/ = 2073,
Sanskrit /*sa*/ = 1103,
Serbian_Cyrillic /*sr-sp*/ = 3098,
Serbian_Latin /*sr-sp*/ = 2074,
Setsuana /*tn*/ = 1074,
Slovenian /*sl*/ = 1060,
Slovak /*sk*/ = 1051,
Sorbian /*sb*/ = 1070,
Spanish_Spain /*es-es*/ = 1034,
Spanish_Argentina /*es-ar*/ = 11274,
Spanish_Bolivia /*es-bo*/ = 16394,
Spanish_Chile /*es-cl*/ = 13322,
Spanish_Colombia /*es-co*/ = 9226,
Spanish_CostaRica /*es-cr*/ = 5130,
Spanish_DominicanRepublic /*es-do*/ = 7178,
Spanish_Ecuador /*es-ec*/ = 12298,
Spanish_Guatemala /*es-gt*/ = 4106,
Spanish_Honduras /*es-hn*/ = 18442,
Spanish_Mexico /*es-mx*/ = 2058,
Spanish_Nicaragua /*es-ni*/ = 19466,
Spanish_Panama /*es-pa*/ = 6154,
Spanish_Peru /*es-pe*/ = 10250,
Spanish_PuertoRico /*es-pr*/ = 20490,
Spanish_Paraguay /*es-py*/ = 15370,
Spanish_ElSalvador /*es-sv*/ = 17418,
Spanish_Uruguay /*es-uy*/ = 14346,
Spanish_Venezuela /*es-ve*/ = 8202,
Sutu /*sx*/ = 1072,
Swahili /*sw*/ = 1089,
Swedish_Sweden /*sv-se*/ = 1053,
Swedish_Finland /*sv-fi*/ = 2077,
Tamil /*ta*/ = 1097,
Tatar /*tt*/ = 1092,
Thai /*th*/ = 1054,
Turkish /*tr*/ = 1055,
Tsonga /*ts*/ = 1073,
Ukrainian /*uk*/ = 1058,
Urdu /*ur*/ = 1056,
Uzbek_Cyrillic /*uz-uz*/ = 2115,
Uzbek_Latin /*uz-uz*/ = 1091,
Vietnamese /*vi*/ = 1066,
Xhosa /*xh*/ = 1076,
Yiddish /*yi*/ = 1085,
Zulu /*zu*/ = 1077
}
public enum SPSiteTemplates
{
TeamSite,
BlankSite,
DocumentWorkspace,
BasicMeetingWorkspace,
BlankMeetingWorkspace,
DecisionMeetingWorkspace,
SocialMeetingWorkspace,
MultiPageMeetingWorkspace,
Wiki,
Blog,
///
<summary>
/// A central document management location for an enterprise
/// </summary>
DocumentCenter,
///
<summary>
/// A central location in which records managers can define routes for incoming files
/// </summary>
RecordsCenter1,
RecordsCenter2,
PublishingSite,
///
<summary>
/// A site for publishing web pages on a schedule with workflow features enabled
/// </summary>
PublishingSite2,
PressReleasesSite,
///
<summary>
/// A publishing site for web pages using approval workflows
/// </summary>
PublishingSiteWithWorkflow,
///
<summary>
/// A site for publishing news and articles
/// </summary>
NewsSite,
///
<summary>
/// A site for creating, managing, and delivering web pages, dashboards, and Key Performance Indicators (KPIs)
/// </summary>
ReportCenter,
///
<summary>
/// A starter hierarchy for an intranet divisional portal
/// </summary>
SPSPortal,
///
<summary>
/// A profile site that includes page layouts with zones
/// </summary>
ProfileSite,
///
<summary>
/// A site collection preconfigured for revision-controlled, secure content creation and publication
/// </summary>
PublishingPortal,
///
<summary>
/// Keep in mind that only one of these can be provisioned per Shared Services Provider
/// </summary>
MySiteHost,
///
<summary>
/// A site designed to deliver the search query and results experience
/// </summary>
SearchCenter,
///
<summary>
/// A superset of the previous; does not appear in navigation bars
/// </summary>
SearchCenter2
}
Lo que nos queda es:
Para convertir enums SPLocales a su representación uint, sólo tenemos que hacer el casting correspondiente. Esta es la razón por la que hicimos al enum heredar de unit y setear el valor apropiado en cada elemento.
Para poder convertir enums SPSiteTemplates a cadenas, el método común es utilizar atributos y reflexión, pero personalmente no me gusta esa forma, así que hice una con diccionarios y métodos de extensión. La idea es proveer al enum la posibilidad de convertirse en una cadena, y estas cadenas de ser parseadas en el enum nuevamente. Para tener este tipo de relación en ambos sentidos, usé la implementación de **BiDictionaryOneToOne ** del usuario de StackOverflow’s Joel in Go, en una pregunta de sobre cómo hacer un diccionario buscable key-value y buscable value-key: Bidirectional 1 to 1 Dictionary in C#.
public static class SPSiteTemplateMethodExtension
{
private const string SP_SITE_TEMPLATE_TEAM_SITE = "STS#0";
private const string SP_SITE_TEMPLATE_BLANK_SITE = "STS#1";
private const string SP_SITE_TEMPLATE_DOCUMENT_WORKSPACE = "STS#2";
private const string SP_SITE_TEMPLATE_BASIC_MEETING_WORKSPACE = "MPS#0";
private const string SP_SITE_TEMPLATE_BLANK_MEETING_WORKSPACE = "MPS#1";
private const string SP_SITE_TEMPLATE_DECISION_MEETING_WORKSPACE = "MPS#2";
private const string SP_SITE_TEMPLATE_SOCIAL_MEETING_WORKSPACE = "MPS#3";
private const string SP_SITE_TEMPLATE_MULTI_PAGE_MEETING_WORKSPACE = "MPS#4";
private const string SP_SITE_TEMPLATE_WIKI = "WIKI#0";
private const string SP_SITE_TEMPLATE_BLOG = "BLOG#0";
private const string SP_SITE_TEMPLATE_DOCUMENT_CENTER = "BDR#0";
private const string SP_SITE_TEMPLATE_RECORDS_CENTER_1 = "OFFILE#0";
private const string SP_SITE_TEMPLATE_RECORDS_CENTER_2 = "OFFILE#1";
private const string SP_SITE_TEMPLATE_PUBLISHING_SITE = "CMSPUBLISHING#0";
private const string SP_SITE_TEMPLATE_PUBLISHING_SITE_2 = "BLANKINTERNET#0";
private const string SP_SITE_TEMPLATE_PRESS_RELEASES_SITE = "BLANKINTERNET#1";
private const string SP_SITE_TEMPLATE_PUBLISHING_SITE_WITH_WORKFLOW = "BLANKINTERNET#2";
private const string SP_SITE_TEMPLATE_NEWS_SITE = "SPSNHOME#0";
private const string SP_SITE_TEMPLATE_REPORT_CENTER = "SPSREPORTCENTER#0";
private const string SP_SITE_TEMPLATE_SPS_PORTAL = "SPSPORTAL#0";
private const string SP_SITE_TEMPLATE_PROFILE_SITE = "PROFILES#0";
private const string SP_SITE_TEMPLATE_PUBLISHING_PORTAL = "BLANKINTERNETCONTAINER#0";
private const string SP_SITE_TEMPLATE_MY_SITE_HOST = "SPSMYSITEHOST#0";
private const string SP_SITE_TEMPLATE_SEARCH_CENTER = "SRCHCENTERLITE#0";
private const string SP_SITE_TEMPLATE_SEARCH_CENTER_2 = "SRCHCENTERLITE#1";
private static BiDictionaryOneToOne<SPSiteTemplates, string> _templates;
private static BiDictionaryOneToOne<SPSiteTemplates, string> Templates {
get {
if (_templates == null) {
_templates = new BiDictionaryOneToOne<SPSiteTemplates, string>();
_templates.Add(SPSiteTemplates.BasicMeetingWorkspace, SP_SITE_TEMPLATE_BASIC_MEETING_WORKSPACE);
_templates.Add(SPSiteTemplates.BlankMeetingWorkspace, SP_SITE_TEMPLATE_BLANK_MEETING_WORKSPACE);
_templates.Add(SPSiteTemplates.BlankSite , SP_SITE_TEMPLATE_BLANK_SITE);
_templates.Add(SPSiteTemplates.Blog , SP_SITE_TEMPLATE_BLOG);
_templates.Add(SPSiteTemplates.DecisionMeetingWorkspace , SP_SITE_TEMPLATE_DECISION_MEETING_WORKSPACE);
_templates.Add(SPSiteTemplates.DocumentCenter , SP_SITE_TEMPLATE_DOCUMENT_CENTER);
_templates.Add(SPSiteTemplates.DocumentWorkspace , SP_SITE_TEMPLATE_DOCUMENT_WORKSPACE);
_templates.Add(SPSiteTemplates.MultiPageMeetingWorkspace , SP_SITE_TEMPLATE_MULTI_PAGE_MEETING_WORKSPACE);
_templates.Add(SPSiteTemplates.MySiteHost , SP_SITE_TEMPLATE_MY_SITE_HOST);
_templates.Add(SPSiteTemplates.NewsSite , SP_SITE_TEMPLATE_NEWS_SITE);
_templates.Add(SPSiteTemplates.PressReleasesSite , SP_SITE_TEMPLATE_PRESS_RELEASES_SITE);
_templates.Add(SPSiteTemplates.ProfileSite , SP_SITE_TEMPLATE_PROFILE_SITE);
_templates.Add(SPSiteTemplates.PublishingPortal , SP_SITE_TEMPLATE_PUBLISHING_PORTAL);
_templates.Add(SPSiteTemplates.PublishingSite , SP_SITE_TEMPLATE_PUBLISHING_SITE);
_templates.Add(SPSiteTemplates.PublishingSite2 , SP_SITE_TEMPLATE_PUBLISHING_SITE_2);
_templates.Add(SPSiteTemplates.PublishingSiteWithWorkflow , SP_SITE_TEMPLATE_PUBLISHING_SITE_WITH_WORKFLOW);
_templates.Add(SPSiteTemplates.RecordsCenter1 , SP_SITE_TEMPLATE_RECORDS_CENTER_1);
_templates.Add(SPSiteTemplates.RecordsCenter2 , SP_SITE_TEMPLATE_RECORDS_CENTER_2);
_templates.Add(SPSiteTemplates.ReportCenter , SP_SITE_TEMPLATE_REPORT_CENTER);
_templates.Add(SPSiteTemplates.SearchCenter , SP_SITE_TEMPLATE_SEARCH_CENTER);
_templates.Add(SPSiteTemplates.SearchCenter2 , SP_SITE_TEMPLATE_SEARCH_CENTER_2);
_templates.Add(SPSiteTemplates.SocialMeetingWorkspace , SP_SITE_TEMPLATE_SOCIAL_MEETING_WORKSPACE);
_templates.Add(SPSiteTemplates.SPSPortal , SP_SITE_TEMPLATE_SPS_PORTAL);
_templates.Add(SPSiteTemplates.TeamSite , SP_SITE_TEMPLATE_TEAM_SITE);
_templates.Add(SPSiteTemplates.Wiki , SP_SITE_TEMPLATE_WIKI);
}
return _templates;
}
}
public static string GetSharePointStringKey(this SPSiteTemplates siteTemplate)
{
return Templates.GetByFirst(siteTemplate);
}
}
Sí, eso de ahí es un singleton y podría tener problemas potenciales de concurrencia, pero no estamos esperando agregar/remover/editar items. Además, yo habría ido con un constructor estático, pero los métodos de extensión tienen que implementarse en clases estáticas, y las clases marcadas como estáticas no tienen permitido tener constructores estáticos.
Con esto ya casi había terminado, pero resulta que si queremos verificar que un sitio existe, necesitamos usar su URL completa, pero si usamos el símbolo de los dos puntos ( : ) entonces vamos a tener una linda SPException diciéndonos que la URL es inválida. Lo que tenemos que hacer es usar URLs relativas a la URL del site collection, así que incluí un par de líneas para parsearlas.
Así que, aquí está la última versión del método CreateSite:
public SPWeb CreateSite(string parentSiteURL, string siteURLRequested, string siteTitle, SPSiteTemplates siteTemplate, SPLocales locale, string description)
{
SPWeb resultWeb = null;
PerformActionOnSite(parentSiteURL, (siteCollection, parentWeb) =>
{
SPWebTemplateCollection Templates = siteCollection.GetWebTemplates(Convert.ToUInt32(locale));
SPWebTemplate spTemplate = Templates[siteTemplate.GetSharePointStringKey()];
var rootUrl = siteCollection.Url;
if (siteURLRequested.ToUpper().StartsWith(rootUrl.ToUpper()))
{
siteURLRequested = siteURLRequested.Remove(0, rootUrl.Length);
if (siteURLRequested.StartsWith("/"))
siteURLRequested = siteURLRequested.Remove(0, 1);
if (siteURLRequested.Length == 0) //they were equal, don't create the root site
{
resultWeb = parentWeb;
}
else if (parentWeb.Webs[siteURLRequested].Exists) //it's not the root site, but it exist anyway
{
resultWeb = parentWeb.Webs[siteURLRequested];
}
else
{
resultWeb = parentWeb.Webs.Add(siteURLRequested, siteTitle, description, Convert.ToUInt32(locale), spTemplate, false, false);
}
}
});
return resultWeb;
}
Si se sienten confundidos por el método PerformActionOnSite, es un wrapper que creé para automáticamente usar y hacer dispose en los objetos **SPSite **y **SPWeb **.
protected void PerformActionOnSite(string siteUrl, Action<SPSite, SPWeb> action)
{
using (SPSite site = new SPSite(siteUrl))
{
using (SPWeb web = site.OpenWeb())
{
action(site, web);
web.Close();
}
site.Close();
}
}
Ok, entonces ya todo está en su lugar, deberían poder usarlo así::
CreateSite("http://siteCollectionUrl", "http://siteCollectionUrl/newSite", SPSiteTemplates.PublishingSite, SPLocales.English_UnitedStates, "site description");
Hablando de la web y performance y todo eso, creo que nunca hemos visto un caso práctico de cómo debería atacarse un problema de performance. Es decir, si sospechamos que hay un problema de estos en un determinado lugar, ¿cuáles son los pasos a ejecutar? Creo que la experiencia juega mucho a favor, porque cada caso es distinto, pero siempre es mejor observar este tipo de situaciones en webs o aplicaciones que tienen una carga pesada diaria, con lo cual un problema de performance es mucho más pequeño y difícil de detectar, y las mejoras que se necesitan son mucho más finas y difíciles de lograr.
En el blog de Sam Saffron, nos cuenta cómo se trata uno de estos problemas en la famosa web Stack Overflow, llamada A day in the life of a slow page at Stack Overflow.
Como podemos ver, las aproximaciones al problema son varias, desde la tecnología utilizada, hasta el tipo de queries que se hacen a base de datos, optimizaciones en las mismas, y hay miles de cosas más que podrían estar involucradas (imágenes, textos, procesamiento de distintos elementos… en fin, es todo un mundo.
Soy un zorrinito performante.
Acabo de ver dos videos de Paul Irish, del grupo de Google Chrome. Uno de ellos era Google Chrome Developer Tools: 12 Tricks to Develop Quicker. Aquí básicamente nos da una explicación de los Chrome Developer Tools con algunos trucos que no son tan sabidos. Interesante y útil.
Sin embargo, el video que más interesante me resultó es uno de media hora llamado HTML5, CSS3 and DOM Performance.
Este video es terriblemente informativo sobre varias temáticas. Quiero en el futuro poder dedicarle un poco más de tiempo a cada una, pero mientras tanto, dejenmé hacer un resumen de las cosas que se tratan en el video:
Espero poder ahondar en cada uno de estos en el futuro. Estén atentos!
Soy un zorrinito performante.
Todavía me encuentro intentando aplicar los conceptos nuevos de HTML5 en algún proyecto, y dsafortunadamente todavía no he encontrado la oportunidad. Pero sé que al momento de hacerlo, voy a dudar y voy a necesitar cierta ayuda para poder trabajar con sus nuevas características y cómo ellas se reflejan en resultados tangibles.
Para eso, muy seguramente me sea muy útil esta web llamada HTML5 Snippets (muy del estilo de Refactory), que recopila una serie de snippets de código utilizando HTML5, a veces CSS3, y no he visto aún - pero supongo que puede haber - JavaScript. El sitio está apenas comenzando su funcionamiento, con lo que no hay mucho movimiento ni contenido todavía, pero ojalá crezca pronto.
También podemos ayudar a eso loggeándonos (con Twitter) y enviando nuestros propios snippets para que figuren en la web. No sólo podemos escribirlos a mano sino que también podemos importarlos desde JSFiddle (parecido a HTML Instant pero más completo), en donde muy seguramente sea más fácil de programar.
Soy un zorrinito HTML5.
Para aquellos interesados en el mundo del diseño gráfico, aquí me llega un elemento muy importante en la forma de analizar el texto en los diseños: la forma de elegir la tipografía, pero en este caso, analizando cuáles son los elementos en particular que hacen a una tipografía distinta de otra, y qué características tiene cada una que la hace única.
Desde MicroSiervos, les dejo a Typography Deconstructed. El sitio tiene su sección principal en donde podemos ver un listado de los distintos elementos característicos de una tipografía, explicados cada uno y marcados en un ejemplo. Por supuesto, también tenemos la posibilidad de comprarlo en un poster o de simplemente verlos online, pero el sitio es lo suficientemente bello como para dejarse ver online sin mayores problemas.
Soy un zorrinito tipográfico.
Los trabajadores de la informática tienen muy asimilados estos conceptos: pilas, colas, árboles, el camino más corto, ordenamiento, algoritmo, grafo, etc. Todos estos conceptos los hemos ido aprendiendo de una forma u otra, pero al momento de aplicarlos es cuando realmente se prueba nuestro aprendizaje. Personalmente creo que ningún aprendizaje está completo sin una buena visualización de la materia, y es aquí en donde, para las estructuras de datos, hay que inventar algo.
Seguramente lo mismo pensó David Galles, quién desarrolló un software en Java que nos permite visualizar el funcionamiento de estas estructuras. Data Structure Visualizations es el nombre que le otorgó, pero la historia no se queda ahí, sino que HTML5 hizo su entrada y ahora también tenemos la versión web. Denle una mirada, no sólo es interesante, sino entretenido.
Recuerdan La Belleza de Los Algoritmos? Creo que este link calificaba totalmente para estar en ese listado.
Soy un zorrinito estructurado.
Este link de hoy no es tan sustancial como el resto de los que estamos acostumbrados, pero no por eso deja de ser útil. En este caso, es un listado que productos Platform as a Service (PaaS). No todos son pagos, y algunos pagos tienen free trials, si a alguno le interesa probar alguna aproximación de computación distribuída, esta es su oportunidad.
El listado está aquí: List of Current and Upcoming Cloud Platforms. Dicho sea de paso, me encanta el diseño de ese blog. Minimalista en serio.
El listado de la categoría Cloud Platforms de Wikipedia provee algunos nombres más. Y por si no les alcanza todavía, acá tienen el List of Cloud Platfrms de CloudTweaks (2010).
Tampoco se olviden de checkear Cloud Computing Ecosystem, que lo mantienen actualizado desde aquél post en diciembre del 2009.
Soy un zorrinito en las nubes.
Estuve leyendo un poquito últimamente sobre CQRS, que significa Command-Query Responsibility Segregation en inglés (sería “Segregación de responsabilidades de commands-queries” en español, ahora explicaré). No he encontrado una buena y corta explicación al respecto así que aquí va mi intento:
Llamaremos Command (comando) a cada operación en nuestro sistema que impactará el estado de la aplicación. Esto significa, cualquier acción que vaya a llevar un cambio en nuestros datos. (Recuerden, el comportamiento puede ser modelado como datos también, pero podemos considerar estos casos como un subconjunto de las situaciones de las que estamos hablando.) Por ejemplo, agregar un usuario, eliminar una tarea, cambiar un registro o actualizar los permisos pueden ser vistos como commands. Si están familiarizados con el patrón de diseño Command, pueden pensar que esta es la forma correcta de representar estas acciones. La idea encaja correctamente, pero estamos hablando de un modelo arquitectural aquí, así que aunque parezca natural usar este patrón, no es realmente necesario.
Llamaremos Query a cada operación que lea de nuestros datos para devolver un resultado. Por ejemplo, verificar si un cierto nombre de usuario existe, o traer una lista de tareas, verificar si un usuario tiene permisos, etc. Recuerden que las queries no alteran los datos. Como pueden ver, estos pueden ser modelados como un tipo de patrón de diseño command nuevamente, pero no es el punto de este artículo.
Finalmente Segregación de la Responsabilidad (otros usan **Separación **en su lugar) significa que nuestra aplicación usará comnands y queries de forma separada, y que no pueden ser mezclados. Esto significa que nuestro sistema realizará operaciones de escritura y de lectura en tiempos o en espacios lógicos separados.
La mejor aproximación para este patrón arquitectural es tener dos conjuntos de datos distintos, uno para lectura y otro para escritura. El de escritura (view data source) está basado en el otro, que podría ser la persistencia actual para nuestros datos. Podemos entonces mejorar nuestro conjunto de datos para la lectura (que no tiene por qué ser relacional, ni normalizado, ni siquiera persistente mientras esté disponible, como un tipo de caché) para tener una aplicación muy veloz, mientras que el trabajo serio se hace con los commands en el otro conjunto de datos.
Las aplicaciones orientadas a tareas pueden entonces delegar las acciones de forma asíncrona para que las tareas-commands (escritura) no ocurran en tiempo real, así permitiéndonos tratar la concurrencia fácilmente, o dando una experiencia increíble en la sensación de velocidad en la aplicación de usuario. Han visto el mensaje de “Enviando email” de GMail y cómo a veces es instantáneo y otras veces puede tardar hasta 30 segundos? Ese es el tipo de experiencia que podrían dar.
El artículo en donde leí esto (MSDN: CQRS on Windows Azure) explica cómo los comandos pueden ser encolados para ser procesados por un thread en segundo plano, de forma que las tareas no tienen que mantener al usuario esperando, y un segundo thread en segundo plano puede estar actualizando los datos para la vista (los que usan las queries para leer), también de forma asíncrona. Nuestra aplicación podría ser la más rápida para la experiencia del usuario, o podríamos tener al usuario esperando y er notificado cuando su tarea se ejecuta (algo como un panel de notificaciones en la aplicación, algo al estilo Facebook que diga “Su reservación ha sido procesada” mientras el usuario sigue navegando por el sitio, quizás?).
Bueno, esta aproximación tiene sus problemillas. Número uno, definitivamente no lo recomendaría para sistemas de misión crítica o de tiempo real. Para nada. De ninguna manera.
Número dos, y tres, cuatro, cinco, etc., es que nos encontramos forzados a proveer un tipo especial de experiencia de usuario en donde las cosas no ocurren en tiempo real. ¿Cómo manejar esto?
Al mismo tiempo, hay un problemita cuando necesitamos que nuestras queries funcionan contra datos reales, en tiempo real. Y a veces, no podemos evitar esto. Por ejemplo, ¿qué si necesitáramos hacer validaciones en un nombre de usuario que el usuario nos provee para verificar que no está duplicado? (Por supuesto, podemos diseñar las estrategias de caché para eso, pero aún así, es un problema.) Este tipo de situaciones puede llevar a algunas impurezas en el diseño, ya que deberíamos trabajar contra nuestro conjunto de datos de persistencia, y no el de lectura, pero las aplicaciones pueden ser modeladas en una forma diferente bajo la premisa de nada es urgente. Miremos algunos ejemplos:
Hay muchos otros ejemplos. A menos que estemos trabajando en un sistema de tiempo real, muchas de las tareas pueden ser trabajadas en otro punto del tiempo. Nuevamente, si no estamos trabajando sobre un sistema de RADAR para el ejército.
CQRS (Command-Query Responsibility Segregation/Separation) nos permitirá trabajar de forma asíncrona con operaciones de datos, que a veces pueden tomar más de lo esperado. El impacto más importante en esta aproximación son las expectativas que debemos darle al usuario sobre cuándo se ejecutarán las operaciones, pero la parte buena es la estabilidad, velocidad y disponibilidad de nuestra aplicación. Esto nos provee de habilidades especiales para escalar y crecer en las características de la misma.
Este es uno de esos ejemplos que van guíando a los programas de la forma que tienen que ser. Hace un tiempo ya César DOnofrio me estuvo comentando sobre una aplicación llamada Color. Con un nombre tan simple, es una herramienta para dispositivos móviles que nos permite formar parte de un “enjambre” de gente que participa de un evento.
Basándose en la localización y el tiempo actual en donde el multimedia es capturado (fotos, videos, etc.), se puede considerar que varias fotos de distintas personas son en realidad pertenecientes a un mismo eventos. Así es como Color nos permite compartir lo que hemos visto con la gente que estuvo en ese evento y con otros. Lo curioso es que entonces todos los detalles que nos perdimos del evento fueron entonces capturados por otros presentes y están disponibles para nosotros también.
La idea es maravillosa, es hacer social en el mundo virtual lo que ya es social en el mundo real. Yo personalmente creo que si esta herramienta no es de alguna forma un ejemplo de cómo deben seguir siendo las aplicaciones (directas en su propósito), al menos tiene un concepto más que interesante.
Soy un zorrinito social.
Aunque el título original del post es Weekends are for hacking, yo creo que este título se le ajusta un poco mejor y se presta menos a confusión, ya que el hacking al que se refiere es hacking de archivos JavaScript para crear nuevas funcionalidades o sobreescribir funcionalidades que ya existen en determinados navegadores. Los ejemplos son muy buenos, y las aplicaciones son múltiples. Pasamos desde la posibilidad de crear gráficos hasta la posibilidad de reproducir MIDI desde el navegador. Por supuesto, todo esto es una gran fuente de conocimiento que podemos utilizar para aprender.
Quizá hacer nuestros propios hacks no sean tan difíciles (y de hecho, nos invitan a que lo hagamos), pero personalmente no creo ser tan conocedor de JavaScript como para ser capaz de algo así. ¿Ustedes sí?
Soy un zorrinito JavaScript.
Dicho sea de paso, ¡Felices Pascuas!
Si es que han visto demos, publicidades, o han jugado personalmente con el Kinect, probablemente se habrán dado cuenta que tiene mucho trabajo volcado en ese producto, y mucha tecnología novedosa sobre la forma en la que se pueden reconocer los cuerpos, las caras y los movimientos. Simplemente, una forma que resultó ser viable de utilizar el reconocimiento de gestos de una forma muy amplia.
Hace no mucho tiempo Microsoft reveló públicamente el algoritmo que utiliza Kinect para hacer estos reconocimientos. Toda esa información está presente en un paper publicado bajo el nombre de Real-Time Human Pose Recognition in Parts from Single Depth Images. El paper es bastante conciso y no muy largo, pero claro, hay que tener ciertos conocimientos de probabilidad, grafos y procesamiento de imágenes para poder apreciarlo en su totalidad.
Siendo esto público ahora, ¿quién de nosotros será el próximo en armar su aplicación Kinect-like?
Soy un zorrinito en movimiento.
La magia de CSS3 nos da la posibilidad de crear una enorme cantidad de figuras complejas, y lo bueno es que son características propias del lenguaje, no se tratan de hacks o de implementaciones propias de navegadores.
Han habido quienes lo llevaron un poco más allá para crear fondos con patrones hechos exclusivamente de código CSS3, y su galería puede observarse en CSS3 Pattern Gallery. La galería es totalmente interesante e interactiva, podemos cambiar los valores que forman los patrones en las cajas de texto y crear nuevos o modificar los existentes a nuestro gusto. Como extra, también es una buena forma de practicar CSS3 de una forma muy gráfica, ¿no lo creen?
Esta galería forma parte del blog de Lea Verou, un blog sobre estándares webs y técnicas CSS, que vale la pena revisar (y cuyo diseño es envidiable).
Soy un zorrinito CSS3.
Siguiendo con la seguidilla de implementos JavaScript, hoy tenemos a Adapt.js, un archivo javascript que nos permite condicionalmente cargar uno u otro CSS de acuerdo a valores del navegador. No se trata solamente de variar las versiones del navegador como podemos hacer con HTML condicional, sino a condiciones como el tamaño de la pantalla, y de hecho, ese es el uso principal que se le da a esta herramienta.
La capacidad de elegir un CSS según el tamaño de la pantalla nos permite fácilmente apuntar a determinados dispositivos móviles de forma distinta que los navegadores de escritorio, e incluso a pantallas que ya quedaron atrás en el avance de los monitores grandes. Tener esa posibilidad nos asegurará que nuestra página siempre se verá bien en cualquier tipo de monitor en el que se la visualice.
Soy un zorrinito adaptativo.
Para diseñar y trabajar sobre HTML, mientras más atajos tomemos, mejor. Mucho del trabajo es repetitivo, y cuando queremos aplicar estilos, la cantidad de idas y vueltas de una ventana a otra es innumerable, por lo menos, hasta que logramos la perfección del diseño original.
Ya alguien tuvo la idea de circunvalar ese problema y surgió Live.js, un script más cerca a diseñar en el navegador, que automáticamente detecta cambios en el HTML, el JavaScript, o el CSS y los aplica a la página actual.
El proyecto surgió como una desviación desde BackFire, un sistema un poco más complejo (cliente-servidor) que nos permitía guardar los cambios en CSS que hacíamos con cualquier navegador inline (como FireBug, WebKit developer toolbar, etc.).
El punto es que Live.js automatiza todo eso y nos permite trabajar en los archivos de forma directa y ver los resultados en el navegador de forma transparente. Imaginen utilizarlo en conjunto con dos monitores. La productividad se eleva una muy buena cantidad.
Soy un zorrinito en vivo.
Recuerdo haber hablado más de una vez sobre distracciones y productividad. Varias de esas veces he mencionado que si podemos darle un toque interesante a lo que estamos haciendo, casi a modo de juego o de desafío, la actividad se vuelve mucho más divertida, y por supuesto, nosotros nos volvemos más concentrados hacia ella.
Un muy buen ejemplo de este caso es TDGotchi, autodefinido como una mascota virtual que nos permite mejorar nuestra práctica de Test Driven Design (TDD).
Se trata de una mascotita, una especie de ninja pixelado que tendremos en nuestro entorno de Eclipse, y que mientras vamos avanzando con ciertas reglas en el proceso de TDD (rojo a verde, verde a verde con refactor, verde a rojo con cambios?) este gana puntos y va evolucionando.
¡Velemos por la seguridad de nuestra mascotita y mejoremos nuestros procesos!
…y más allá de eso, tengamos en cuenta una buena forma en la que se da ese _toque especial _a los procesos tediosos.
Soy un zorrinito tedioso.
Estaba leyendo un artículo sobre herramientas gratuitas para desarrolladores (27 Free Online & Offline Applications for Designers & Developers) cuando una de ellas realmente llamó mi atención. Se llama Boks, y es una aplicación de Adobe Air (eso significa, funciona en Mac, Windows y Linux) que nos permite trabajar sobre Blueprint.
Para quién no recuerda de qué se trata Blueprint, es un framework CSS basado en grillas, ampliamente utilizado para la rápida construcción de diseños, que nos permite crearlos armoniosos y esquematizados.
Boks nos da la posibilidad de hacer esto de una forma visual, una gran ayuda para aquellos que no hemos aprendido a utilizar el framework CSS más famoso de una forma totalmente profunda, y que queremos comenzar a utilizarlo.
Soy un zorrinito CSS.
Para aquellos que preferimos el mundo HTML+JS seguramente pensemos que Flash es un mundo en el que no conviene meternos, aunque Google fácilmente lo desmintió comenzando a indexar sitios en Flash, de forma que las primerísimas razones para no usar Flash se vieron derribadas.
Fuera de eso, y de la enorme discusión sobre la forma en las que se puede encarar un diseño gráfico o una experiencia del usuario, sabemos que Flash y/o SilverLight (o tecnologías similares) nos abren todo un nuevo mundo.
Y para muchos lugares, todavía se trata de un problema al momento de pre-cargar esa aplicación, ya que hay que presentar algo para que el usuario sepa que todavía estamos trabajando para su experiencia.
Por supuesto, no faltan quiénes quisieron hacer una galería para la inspiración de aquellos que no sepan cómo aproximarse, o aquellos que simplemente quiera ver cuáles son los mejores pre-loaders que hay por la web. Allí surgió Pretty Loaded, una galería de pre-cargadores en donde podemos ver muchos de estos interesantes ejemplos.
Soy un zorrinito precargado.
Este es otro de los links que me fue compartido via Twitter por la gente de BreakingDev, y el concepto es bastante simple, dejenmé presentarlo:
Se dice que una pieza de software está encapsulada cuando no conocemos su funcionamiento interno y sus aspectos externos nos proporcionan todo lo que necesitamos para hacerla funcionar. No nos importa cómo, nos importa el qué hace. El cómo es responsabilidad de ese software, no nuestra.
Este concepto es muy utilizado en el paradigma de programación orientado a objetos, en donde cada objeto encierra la responsabilidad de su propio comportamiento.
Sin embargo, en el artículo llamado Psychological Encapsulation se ve este tema de una mirada distinta: ¿Qué ocurre cuando no confiamos en la forma en la que una pieza de software realiza sus tareas? ¿Qué ocurre cuando tenemos un problema y el no conocer ese comportamiento interno nos impide solucionarlo?
Esto es lo que ellos denominan encapsulación psicológica, y supongo que otros simplemente lo pueden llamar fiabilidad de un determinado software, o, siendo más específicos aún, el gusto y confianza que cada persona en particular le tiene a un software en particular.
Creo que es un concepto a tener en cuenta al momento de diseñar (y usar!) software, trabajar con herramientas en las que no confiamos (o peor aún: no podemos confiar) es realmente una experiencia desagradable, y puede conducir a grandes bloqueos en nuestra productividad.
(Aquí podríamos hablar sobre distintos tipos de software, cuáles son de mayor confianza, si el open source comunitario o el software propietario que tiene a una empresa respaldando el buen funcionamiento del mismo, si los sistemas hechos de piezas simples integradas o si los sistemas que lo hacen todo, etc. Son libres de dejar sus opiniones.)
Soy un zorrinito de confianza.
Gracias a @nanojaus, si no me equivoco, me llegó un video interesante sobre la experiencia de instalar Windows 1.0 en una máquina virtual, e ir actualizando hacia las versiones posteriores (versiones mayores). No sólo eso, sino que se van probando distintas características a lo largo de las versiones del sistema operativo y se intenta mostrar cuánta compatibilidad hay con las versiones anteriores (en detalles, por supuesto que una investigación profunda tomaría muchísimo más tiempo).
El artítulo está aquí, pero posiblemente prefieran ver el video.
Este experimento me hizo pensar en cómo es que deberían ser las experiencias de actualización o instalación de software. Estas son las características que vienen a mi mente, las cuales también aplicarían para cualquier proceso que pueda tomar un tiempo:
¿Alguna otra idea para mejorar las experiencias?
Soy un zorrinito instalador.
Como ya había contado en unos links anteriores que ando siguiendo una serie de videos llamados Extra Credits, de parte de The Escapist ([1], [2]), unos videos sobre diseño y análisis de video juegos extremadamente interesante. Más interesante que los videojuegos (desde mi punto de vista), es todo lo que se puede aprender sobre diseño, psicología, sociología y marketing. Pero todo eso es otra historia.
Un punto clave de muchos juegos es el tutorial, aquella parte que nos enseña las reglas por las cuales el juego se desarrolla. Ahí es en donde estos muchachos hicieron el video llamado Tutorials 101. En este video nos enseñan muchas características que un buen tutorial debería tener, pero no puedo dejar de pensar que este mismo concepto aplicaría a tutoriales de casi cualquier otro tipo. Aparatos electrónicos, software de escritorio, aplicaciones web… todo debería seguir los mismos conceptos porque la razón que tienen es mucho más profunda.
Resumiendo el video, los puntos claves expuestos son:
¿Pueden pensar en algún otro punto importante para los tutoriales?
Soy un zorrinito de aprendizaje.
Ayer salió a la luz la versión definitiva de Firefox 4, y en unas 24 horas ya logró tener más de 6 millones y medio de descargas. Un navegador popular, sin dudas. Podemos bajarlo y al mismo tiempo ver el movimiento en tiempo real de descargas a través de Firefox 4 Download Stats.
Cabe aclarar que Firefox 4 viene totalmente renovado, al menos en su interfaz gráfica y mucho de su funcionamiento interno. Las características que Firefox siempre ofreció permanecen ahí, y hay varias otras más. Por otro lado, su interfaz es mucho más limpia y minimalista (parece que todos los navegadores están siguiendo una tendencia que Chrome marcó) y por supuesto, soporta muchos de los nuevos estándares que se están desarrollando para la nueva web.
Fue de casualidad, gracias a un post en Twitter, en donde encontré un dashboard de ejemplos y características de HTML5 y tecnologías relacionadas, llamado HTML5 & Friends, en donde podemos ver muchas de las nuevas características en funcionamiento, y tener una explicación pequeña que podemos extender. Por otro lado, la web de Mozilla Demos (llamada Web O’pen Wonder) contiene muchos ejemplos e implementaciones de las cuales podemos aprender.
Soy un zorrinito actualizado.
Aquellos que tenemos que ver con el desarrollo web muy seguramente nos hemos apegado mucho a nuestro querido Firefox, gracias a la enorme cantidad de herramientas que la comunidad tiene para poder desarrollar. Muchos de nosotros también han encontrado en Chrome una alternativa muy interesante y hasta preferible, pero siempre tuvimos el problema de que la cantidad de extensiones para desarrollo era muy limitada.
Por suerte, Chrome mismo ha evolucionado al punto de poseer unas herramientas de desarrollo integradas muy profundas e interesantes, sin necesidad de ninguna extensión. Pero aún así, el mercado de extensiones para Chrome ya ha crecido bastante, y es hora de ver alguna de las opciones que tenemos para personalizar el uso que le damos en nuestra tarea de desarrollo.
Rosa Gutiérrez fue quien me compartió a través de Google Reader esta enorme colección de extensiones para desarrollo en Chrome llamada 40 Useful Google Chrome Extensions for Web Designers. La verdad no las he contado, pero creo que son más de 40. Aunque no lo fueran, realmente valen la pena, les recomiendo a los usuarios de Chrome que le echen un vistazo, muy seguramente encontrarán algo de su agrado.
Soy un zorrinito cromado.
Alguna vez mostré un link sobre un script para sitios web llamado IE6 Upgrade Warning, la idea del mismo es forzar a que los usuarios tengan que actualizar su navegador web para continuar en la navegación del sitio, y que si este script se hacía lo suficientemente conocido, podríamos contar con una internet un poco más actualizada.
Resulta que no dio tanto resultado como quisieron (a pesar de que el proyecto sigue activo hasta estos días), pero Microsoft ha puesto cartas en el asunto. Sí, Microsoft mismo ha determinado que debe existir una cuenta regresiva para la existencia de Internet Explorer 6, y dicha cuenta regresiva forma parte de la campaña de publicidad de Internet Explorer 9. Su sitio central se llama Internet Explorer 6 Countdown.
Me llegó la noticia a través de MicroSiervos, y como bien ellos dicen: si los propios creadores de la herramienta piden que se deje de utilizar, por algo será necesaria la muerte de este software. Yo no lo dudo: más allá de los chistes que se pueden hacer sobre los problemas que da, el tenerlo que tener en cuenta al momento de crear aplicaciones web significa un gran lastre que arrastrar, y un impedimento para el avance de las tecnologías web.
Dicho sea de paso, Internet Explorer 9 está ya disponible en su versión final para ser descargado, en el sitio de Beauty Of The Web. Tiene una interfaz renovada (agradable a mi gusto), buena velocidad, un buen manejo de JavaScript y soporte de HTML5. Esa fue una primera mirada rápida y me agradó.
Soy un zorrinito actualizado.
Algún tiempo atrás hablamos sobre la naturaleza de las distracciones y si realmente eran un problema o no. Más allá de eso, sabemos que si no se mantienen controladas, son definitivamente contraproducentes.
Más allá del problema de identificar cuáles son y si son realmente productivas o no, el segundo problema es saber cómo atacarlas. Randall Munroe, a quién conocerán mejor como XKCD, desarrolló una regla para su propia máquina que mantenía a control sus propias distracciones a través del control de la dopamina en el sistema de refuerzo de conducta del cuerpo humano. Todo se dio a conocer en la tira cómica, aunque la explicación completa de la situación la dio él en su blog.
Básicamente, él nos explica que la prohibición directa contra las distracciones generaban excusas mentales que terminaban anulando esas mismas reglas, y por tanto realmente no servían. él se permite a sí mismo las distracciones pero hace que sea difícil poder alcanzarlas. De esa forma, la sensación de satisfacción que uno siente por ellas comienza a desaparecer, hasta que de forma natural ya no nos atraen como distracciones.
Soy un zorrinito distraído.
No me refiero a problemas de tipo matemático, ni siquiera a problemas relacionados a la informática (aunque los ejemplos se relacionan mucho con eso). En este artículo, publicado desde MicroSiervos, se nos explican varios puntos distintos a tener en cuenta al momento de resolver ese tipo de problemas cuya solución no es nada evidente.
Muchos de nosotros nos hemos encontrados cazando este tipo de problemas, y sin duda es una ciencia difícil. Este artículo, llamada 10 consejos para la resolución de problemas técnicos inexplicables, aclara varios puntos que todos deberiamos tener muy presentes antes de frustrarnos buscando este tipo de problemas fantasmas.
Este es el tipo de aprendizaje que paga rápidamente.
Soy un zorrinito difícil de resolver.
En i.MicroSiervos publicaron un artículo muy interesante llamado 7 formas de automatizar el trabajo con tu ordenador, y todos sabemos que quizá la parte más lenta de lo que hacemos en la computadora somos nosotros y nuestras tareas repetitivas.
Teniendo la posibilidad entonces de ganar tiempo para las cosas en las que realmente tenemos que concentrarnos, este artículo es muy interesante para poder centralizar tareas que comunmente hacemos y podemos delegar a un software sin la necesidad de saber programar.
Soy un zorrinito automatizado.
Este es mi tercer post hablando sobre un artículo publicado sobre la gente de OkCupid. ([1], [2]). Para quien no lo sepa, es un sitio de citas (dicen ellos, el más grande que hay), con un blog realmente fantástico y con un valor científico muy importante (o eso considero yo). Ellos hacen análisis basados en la relaciones que su sitio maneja, y personalmente creo que sus estudios pueden bien ser de ayuda para la sociología u otras ciencias.
En este caso en particular, quiero aproximar este siguiente post desde el punto de vista de la ingeniería social. Ellos analizaban el siguiente problema: en una primera cita hay mucho que uno quiere conocer de la otra persona, pero son cosas que no se pueden preguntar porque son preguntas invasivas, o porque simplemente incomodarían a la otra persona.
El datamining y las probabilidades entran en acción. Analizando el total de la gente, han logrado separa bajo distintos factores aquellas preguntas que sí se pueden analizar, y cuál es el factor de correlación con las que no se pueden contestar. Por ejemplo, que alguien te responda que le gusta el sabor de la cerveza implica un 60% de posibilidades de sexo en una primera cita (a muchos les hubiera gustado saber esto antes, verdad?)
Llevenló al aspecto de la seguridad. ¿Cuántas cosas sore la seguridad interna de un sistema o empresa podríamos saber haciendo otro tipo de preguntas?
Sin más explicación, los dejo con el artículo: The Best Questions for a First Date.
Soy un zorrinito social.
Para quienes trabajamos en la informática es algo común tener que lidiar con algún usuario final, incluso aunque nos dediquemos a algo muy específico y no directamente relacionado con la experiencia del usuario. Sabemos que también no todas las personas son iguales, y mientras unas son más afines a la tecnología y otras no, también existen distintas actitudes que la gente tiene ante un problema en particular.
La gente de En Español tradujo un artículo sobre Los 5 tipos de Usuarios del Infierno de la Informática. A pesar de la dantezca alusión, no todos son necesariamente malos, y para cada uno se nos recomienda una forma de tratamiento para llegar al entendimiento.
¿Se identifican con alguno? ¿Tienen experiencias con algún tipo de usuario en particular?
Soy un zorrinito dantezco.
Hace poco me crucé con un artículo proveniente de HackTimes, y sabiendo de donde viene, lo leí sabiendo que iba a ser interesante. Este artículo en particular, llamado Introducción al análisis forense en VMWare nos promete tener algunas continuaciones.
A través de ellas se irá explicando la forma en la que podemos utilizar VMWare (y algunos conceptos relacionados a la virtualización que este mismo realiza) para analizar máquinas en un estado particular. También nos comenta sobre ciertas herramientas que se usan en el ámbito y ejemplos de como utilizarla. No encontré el artículo extremadamente explicativo pero sí fácil de seguir a modo de tutorial.
Para quién esté interesado en el análisis forense o en el profiling de aplicaciones a un nivel muy, MUY detallado, esto es sin duda una muy buena oportunidad para ayudarse a través de la virtualización.
Soy un zorrinito forense.
Ahora que se acabaron las direcciones IP como las conocíamos y se viene el nuevo apocalípsis (?), pronto comenzará la migración paulatina a la utilización de IPv6. Esto ya no es algo relativamente nuevo, pero si es que no sabías al respecto, te recomiendo un artículo de Bitelia que lo explica todo: La transición de IPv4 a IPv6: Lo que necesitas saber (gracias @fieritacatalano!), muy bien explicado e ilustrado sobre qué ocurrirá.
Si es que ya estabas informado del asunto, y más aún, si es que tu rol es el de NetAdmin, muy probablemente te interese saber que el próximo 8 de Junio es el día IPv6 mundial, un día en donde las grandes compañías van a cambiar sus servicios para trabajar sobre IPv6 y durante 24 horas, verificar que las redes funcionan normalmente y que el mundo no se acabó. Tu compañía podría ser una de esas también.
Y si te perguntás qué pasó con la versión 5… aquí tienes tu respuesta: IPv5 - What was it?
Soy un zorrinito IP.
Hay una serie de chistes que provienen de XKCD (perdón, pero no tengo un link directo a esos chistes en particular) en donde el chiste se basa sobre una gráfica X-Y de la cantidad de resultados que Google devuelve para una combinación de palabras. (Por ejemplo:
Resulta que, para los que no lo sabían, los datos sobre estos chistes no son inventados, sino que muy generalmente provienen de datos reales de búsquedas sobre Google. ¿Pero de qué forma se hacen? No con la búsqueda normal, y el autor nos explica por qué en su entrada Trochee Chart.
él cuenta cómo Google realmente aproxima los resultados (seguro que a muchos les ha ocurrido ver una disparidad entre los números) para luego refinarlos, y cómo distintas fuentes de búsqueda de Google mismo puede dar distintos resultados. él nos introduce a la API de búsqueda de Google (que actualmente está obsoleta pero funcional) y una herramienta que todavía funciona para esos propósitos.
¿Ustedes creen que los resultados de una búsqueda en Google pueda ser un indicador de algo?
Soy un zorrinito googlero.
Hace poquito apareció en mi feed de Youtube una charla de Google Tech Talks llamada How to Write Clean and Testable Code. Para ser sinceros, el video dura más de una hora así que no lo ví, pero en lugar de eso busqué las diapositivas que se habían usado en él y las encontré aquí: How to write Clean and Testable Code Slides. Las diapositivas no me resultaron demasiado reveladoras tampoco pero sí resaltan algunos conceptos claves que es bueno siempre tener en mente.
Más allá de eso, en las diapositivas (y muy seguramente en la charla) se menciona a AngularJS, así que lo fui a buscar. Parece que AngularJS es un sistema de templating a través de JavaScript, pero mucho mayor que simplemente templating. Digamos que más que estar orientado en generar HTML a partir de datos, también se preocupa de la forma en que esos datos deben interactuar, de forma que, podríamos decir, también genera algo de código dinámicamente para que estos datos funcionen correctamente.
No lo he probado, pero ellos dicen que es la forma en la que debería haber sido HTML si es que hubiera sido pensado desde un principio para aplicaciones web.
¿Alguien lo probó? ¿Cuáles son sus experiencias?
Soy un zorrinito javascript.
Hace tiempo atrás publiqué un link sobre generación automática de código, pero realmente hacía falta una explicación lenta y paso a paso de cómo se hace o cómo se pueden aprovechar las características que esto nos ofrece.
Un artículo muy bueno desde SwitchOnTheCode trata este mismo tema: C# Code Generation.
Piensen que combinando esto con programación procedural o algoritmos genéticos ([1], [2]) puede tener resultados muy interesantes.
Soy un zorrinito autogenerado.
Hace un tiempo que Amazon ofrece, entre sus varios Web Services, un servicio llamado Mechanical Turk, lo cual ellos llaman Artificial Artificial Intelligence. Si recuerdan a ShortTask, muy seguramente ya conozcan el concepto: Amazon provee un mercado en donde los Requesters pueden postear distintas tareas de inteligencia humana (HITs), y un trabajador (Worker) puede realizarlas para ganar dinero. Además, Amazon provee el concepto de Qualifications, que son pruebas que los usuarios deben tomar para poder acceder a ciertas tareas (aunque es opcional que una tarea requiera de tomar pruebas).
Por supuesto, todo esto es automatizable de cierta forma (o al menos el control de la información en Amazon), por lo que esto se vuelve interesante para ser integrado con otros trabajos.
En ese caso, y a modo de ejemplo, tenemos a Soylent (es un buen nombre o qué?), un proyecto que siendo un plugin para Microsoft Word, nos permite asignar tareas relacionadas con nuestro documento para que la gente trabaje sobre él.
Todo esto me llega desde BarraPunto, que, por supuesto, está lleno de noticias interesantes.
Soy un zorrinito en la nube.
No sé si alguno de ustedes está subscripto al Dev Channel de Google Chrome, en donde pueden obtener features nuevas más rápidamente, por supuesto, sabiendo que no están del todo probadas. Si están ahí, sabrán que la cantidad de cambios y updates es realmente mucha, y que a pesar de todo eso, el proyecto sigue creciendo y trabajando en el ambiente, uno se pregunta:
¿Cómo hacen para mantener ordenado un proceso tan dinámico?
Esa pregunta me fue respondida por un link provisto por @Woork, quién nos otorga una presentación sobre el Ciclo de Vida del proyecto Chrome, presentado por parte de Anthony LaForge, llamado Chrome Release Cycle. En esta presentación podemos ver los distintos problemas a los que se enfrentaron al momento de manejar tiempos y los distintos problemas de la programación común, y cómo fueron adaptando la estrategia para lograr un punto más dinámico y accesible.
Quienes estemos subscriptos a esa rama de desarrollo sabemos ahora que funciona, y que da resultados visibles.
Soy un zorrinito apurado.
El otro día anduve curioseando un rato por el sitio de MathsMovies, un sitio web que recopila varios datos sobre películas y la relación que estas tienen con el mundo de las matemáticas. Suena quizá a algo tonto, pero si revisan en la sección de Salas, se encontrarán con que realmente hay distintas categorías y están bien pensadas. Por ejemplo, no es para nada igual una película que trata de un personaje muy hábil con las matemáticas (ej: Little Tate), que otra película en donde la trama es completamente guiada por el método matemático (ej: Primer), o que otra en donde los conceptos matemáticos forman una parte fuerte de la trama (ej: la saga de El Cubo).
Hay otras películas que realmente no me sorprendió encontrar mencionadas en el sitio, como Futurama, del cual yo ya había visto un especial dedicado a Futurama y Las Matemáticas, y más sabiendo que desarrollaron y demostraron el Teorema de la Inversión exclusivamente para uno de los capítulos. Si han visto la serie, sabrán de qué hablo y que Futurama es una serie llena de referencias matemáticas y de sistemas.
Otro sitio que hacen recopilación de este tipo de cosas son Cine y Matemática, pero desafortunadamente no he encontrado alguno completamente actualizado y con muy buena y detallada información al respecto. ¿Alguien que conozca y quisiera compartir?
Soy un zorrinito matemático.
Gracias a @Woork me enteré de este Simulador de iPad totalmente hecho en CSS y JS. Si lo prueban un poco se darán cuenta que la mayoría de las aplicaciones no están implementadas todavía, pero hay cosas que sí están implementadas y pueden probarse hoy, por supuesto, de la misma forma que funcionaría en un iPad real:
Es mucho y anda muy bien para ser un poco de JavaScript.
Fuera de eso, cabe aclarar que el creador de este simulador, Altyrne, tiene un blog en donde actualiza muy regularmente sobre sus experimentos con navegadores, JavaScript, HTML5 y CSS3, aparte de jQuery, animaciones, etc.
Soy un zorrinito JavaScript.