Border Top Style Personal blog about technology by Elena Torro

Mujeres, hombres y tecnología

Hoy ha salido un artículo en El País titulado ‘¿Mujer o Ingeniera Informática?’. Tengo muchas opiniones sobre este tema, y de hecho es algo que he hablado y hablo con frecuencia con mis amigos y compañeros de clase y de profesión, por lo que he tenido la oportunidad de conocer muchísimas opiniones. Siempre he querido escribir un post sobre este tema, pero nunca sé por dónde empezar, ya que sé que escriba lo que escriba, mucha gente va a estar en desacuerdo. Opinar de estos temas públicamente da miedo, por lo que puedan pensar o lo que te puedan decir. Sin embargo, esta semana recibí un mensaje privado por twitter que me emocionó muchísimo ❤️ relacionado con esto, así que he dicho, ¿por qué no?

En realidad he pensado que lo mejor que puedo hacer es contar un poco mi experiencia personal, que espero que por lo menos resulte entretenida :)

Me metí en informática de casualidad, no había programado una línea de código hasta los 18 años ni había formateado un ordenador. No todos los grandes cerebros programadores llevan programando y desmontando ordenadores desde los 10 años. Puedes empezar con 10, 18 o 45. Sí que utilizaba mucho el ordenador: para escribir, para dibujar, hasta hice un pequeño juego en power point utilizando hipervínculos entre diapositivas (sin yo saberlo, fue mi primer algoritmo). En el primer examen de programación saqué un 0, pero a pesar de eso, recuerdo lo mucho que me divertí. Programar molaba mucho.

En primer año, en mi horario de clases, yo era la única chica en el 85% de las asignaturas. Tenía dos compañeras que estudiaban la doble titulación matemáticas e informática, que son increíbles, y con las que sigo en contacto. También tenía compañeros de todo tipo. De todos los estudiantes de todos los cursos de informática con los que compartía la facultad, ¿de verdad alguien puede creer que todos fueran iguales o cumplieran un mismo estereotipo? En segundo año decidí cambiar de carrera, ya que descubrí que existía un grado universitario llamado Ingeniería Multimedia en Alicante que me llamaba muchísimo más la atención.

Muchos compañeros se sorprendieron de que me dejara la carrera ‘con lo bien que iba’, pero no la estaba dejando, sólo estaba pivotando. En esta carrera había un porcentaje femenino mucho más alto, tal vez por cómo se publicitaba la carrera. Y de hecho, cada año aumenta el número de mujeres. En cualquier caso, ¿sabéis qué? No noté ninguna diferencia. El trato con mis compañeros y compañeras era el mismo que cuando yo era la única mujer en clase. Obviamente, al ser una carrera con una rama orientada al desarrollo de videojuegos, vas a encontrarte con mucha gente fan de los videojuegos, pero no sé, tiene sentido. Sería como estar en una clase de filología y decir (ejemplo dramático): ‘uf, es que aquí la gente es súper rara, no para de leer’. En general, la gente elige una carrera por vocación.

He ido con grupos de trabajo formados íntegramente por mujeres, grupos equilibrados, y grupos en los que yo era la única chica. En todos, el éxito del mismo no depende el género de sus integrantes, sino de las habilidades de los mismos. La verdad es que contar esto me resulta muy raro porque creo que es bastante obvio.

Como siempre me ha gustado mucho lo que he estudiado, siempre he estado agustísimo, como pez en el agua. Ha habido asignaturas mejores que otras y profesores mejores que otros. Supongo que como en todas las carreras, ¿no?

Cuando estaba de Eramus en Austria, éramos como máximo 3 mujeres en la clase. Una noche salí de fiesta con los compañeros y con uno de los profesores. Uno de ellos, con el que más amistad hice, organiza actualmente eventos y está muy concienciado con la diversidad en las disciplinas STEM, y aprovechó la ocasión para hacerme preguntas (me encanta la gente que habla abiertamente y se atreve a preguntar). Me dijo, ¿cómo te sientes siendo la única mujer? ¿Te sientes incómoda con alguno de nosotros? ¿Alguna vez te has sentido incómoda en la carrera? ¿Alguna vez te has sentido discriminada? La gente sabe que tienes novio y que estás rodeada de veinte hombres, ¿te importa lo que piensen? ¿qué opina tu novio?. Estuvimos hablando un buen rato, fue muy interesante. En resumen: no, nunca me he sentido discriminada ni incómoda. Nunca me han dicho que por qué estoy rodeada de muchos hombres ni de muchas mujeres. Ni mi familia, ni mis amigos, ni mi novio, ni nadie. Y si alguien lo piensa o lo critica, ése es su problema.

Comencé a trabajar al poco tiempo de acabar la carrera. Está claro que el entorno profesional no es lo mismo que el entorno estudiantil. Siempre hemos sido menos mujeres que hombres, y de hecho, he coincidido laboralmente con muy pocas desarrolladoras/programadoras. Eso me sorprende, porque conozco muchas mujeres que han acabado la carrera, pero no tantas que sigan desarrollando. En definitiva, cada uno tiene que encontrar su camino. El mío es el desarrollo front end, y a pesar de que es un puesto de programación, sí que es cierto que mucha gente me incluye en listas de twitter de diseñadores o da por hecho que me dedico al diseño. Quitando esto, que es más un asunto ‘visto desde fuera’, lo que me interesa contar es la experiencia ‘vista desde dentro’.

A día de hoy, nunca me han juzgado en una entrevista u oferta de trabajo por ser mujer. En una ocasión, sí que me dijeron: ‘eres programadora y mujer, eso es algo que no se ve mucho’. Sí, es cierto, estadísticamente es así hoy en día. Preferiría que no lo hubieran dicho, pero es una muestra de cómo es la situación actual. Con respecto a los compañeros de equipo, siempre ha habido buen rollo. Me resulta chocante que al principio, es cierto que compañeros (hombres) me han mirado antes de hacer alguna broma o que han dicho frases como ‘iba a decir algo, pero me callo porque está Elena delante’. Yo siempre insto a que digan lo que tengan que decir, esté yo o no. Es como un miedo inicial a no saber cómo voy a reaccionar. No sucede tan descaradamente si el ‘nuevo’ es un hombre, pero también pasan situaciones similares. Incluir a alguien nuevo en un grupo que ya lleva mucho tiempo trabajando conjuntamente y que tiene sus bromas internas, su ‘jerga’, es un proceso que requiere tiempo.

En general, siempre he hecho amigos y amigas, más allá que compañeros de trabajo, en todos los sitios donde he estado. Al fin y al cabo, acabas pasando muchas horas trabajando y conviviendo (porque trabajar implica convivir, de alguna manera) con un grupo reducido de personas. Eso siempre, en cualquier disciplina, hará que salten chispas y que surjan bonitas amistades. He tenido momentos de desternillarme de risa en la oficina. He tenido discusiones sobre temas súper interesantes. He hablado con mis compañeros (hombres y mujeres) de la menstruación con total normalidad, que es un tema tabú en la sociedad actual, y no tiene por qué serlo. No escondo el tampón como si fuera el más misterioso de los secretos cuando lo saco del bolso para ir al baño. No sé, mis compañeros también tienen hermanas, primas, novias, amigas… Me encanta sacar esto porque seguro que hay alguien que se escandaliza 😁.

La verdad es que me sorprende mucho cuando leo artículos, cuando leo comentarios machistas en twitter, porque me doy cuenta que la mayoría de comentarios negativos y estigmatizados vienen de fuera. De la publicidad, de los medios de comunicación, de las empresas y de la gente que no vive desde dentro la experiencia.

Desde luego, el hecho de que se estén creando movimientos para crear referentes femeninos en disciplinas STEM no ha aparecido por casualidad. Hay diferencias, está claro. Si durante años muestras anuncios de juguetes en los que ellos pueden construir cosas alucinantes y ellas peinar a sus muñecas, a la hora de elegir a qué dedicar tu vida es normal que sientas esa presión social. No es normal que una mujer escriba un tweet diciendo que este año no ha habido mujeres en los premios nobel y se le lancen al cuello.

Por otro lado, quiero mencionar el tema de las ‘oportunidades a mujeres’ o en favor a la diversidad. En este caso, en muchas ocasiones tengo sentimientos encontrados, porque a veces no sé si una empresa/evento/curso da oportunidades exclusivas a mujeres (descuentos, becas, plazas extra) para fomentar la diversidad o bien para mejorar su imagen pública o incluso por temas económicos. Muchos compañeros (hombres y mujeres) se han quejado de esta llamada ‘discriminación positiva’ ya que para ellos fomenta la competitividad y el sesgo de género. Me parece una opinión aceptable. Personalmente, yo estoy a favor de este tipo de iniciativas, porque sea por la causa que sea, está claro que la balanza está desequilibrada. Pero eso no es lo peor, es que este desequilibro se produce por una errónea percepción de lo que es en realidad. Yo quiero que se vea desde fuera lo que yo siento desde dentro: que es un entorno amigable, muy creativo, formado por multitud de personalidades distintas y además, muy abierto. Existen muchísimos eventos tecnológicos, cada vez más, y cada vez más inclusivos. Hay un concurso para colegios muy interesante de la Universidad Pompeu Fabra, llamado wisibilízalas, cuyo objetivo es dar visibilidad a mujeres. Echadle un vistazo, creo que la idea mola.

Para ir acabando, conozco muchas mujeres programadoras, ingenieras, desarrolladoras, informáticas… Hay muchísimas, en serio. Hay más hombres, sí, pero eso no debe de eclipsar a nadie. Conozco mujeres que se dedican al mundo de la robótica, al desarrollo de servidores, a análisis de datos, a QA, al diseño y desarrollo web y de aplicaciones, a la seguridad informática, a la educación online, a los gráficos por computador, realidad aumentada, realidad virtual, videojuegos… De verdad, ¡conozco muchas! Sólo investiga un poco en redes sociales, en twitter, en github. Nunca lo hemos tenido tan fácil para encontrar referentes.

Tengo muchos referentes masculinos y femeninos. Seas hombre o mujer, simplemente, dedícate con pasión a lo que te gusta. Sé un buen compañero de trabajo. Sé un buen profesional. Lucha por mejorar profesionalmente, por conseguir una conciliación entre tu trabajo y tu vida, ya que al final, son la misma cosa. Si estás pensando en estudiar ingeniería informática o una carrera similar, desde mi experiencia personal te digo que vas a encontrar un mundo lleno de posibilidades, de gente a la que generalmente le encanta compartir, gente creativa. No te llevarás bien con todo el mundo porque precisamente hay perfiles muy distintos y es imposible encajar con todos. Elige esta carrera para pasártelo bien, hay muchas ramas en las que puedes acabar, y va a haber muchas más. Y si no te gusta, tal vez aún no has encontrado tu vocación y tengas que seguir buscando, tampoco pasa nada, no puedes saberlo hasta que no lo pruebes.

Podría alargar el post mucho más ya que me dejo muchas cosas, así que si quieres hablar del tema u opinar, coméntalo, mándame un email o escríbeme por twitter 😙.

Otros:

Accesibilidad en Tablas HTML5

border-top-style: aria-labelledby;

El tema del tag <table> y la accesibilidad web ha sido discutido en varias ocasiones. En este post no voy a hablar de por qué no utilizar tablas para maquetar contenido web, sino de las tablas en sí mismas. Últimamente me ha tocado estar trabajando con tablas, y me han surgido muchas dudas al respecto. ¿Qué buenas prácticas existen a la hora de utilizar tablas en HTML5? ¿Cómo conseguir que el contenido sea accesible? ¿Qué herramientas existen para interaccionar con tablas?

En el post de hoy quiero introducir el tema de la accesibilidad web en las tablas: no hablar de tablas en general, ya que éste es un tema increíblemente extenso. Me voy a centrar en tres aspectos concretos, a pesar de que hay muchos más, ya que son los primeros con los que me he encontrado:

  • el tag <colgroup>
  • los roles que se pueden aplicar a una tabla
  • selección de tablas: checkboxes y atributos ARIA.

Soy bastante newbie en el tema de accesibilidad, así que voy poco a poco, leyendo mucho y fijándome en qué hacen otros. Además, he de confesar que me lo estoy pasando pipa con los lectores de pantalla. Ya publiqué un post breve sobre HTML5 y Accesibilidad, por si quieres hacer un repaso rápido antes de seguir.

Bien, vayamos por partes. Concretamente, por las partes de una tabla. En este tutorial del W3C encontramos una detallada lista de los tipos de tabla, así como las partes que puede tener una tabla. Conviene echarle un ojo por encima para continuar con el post, si no estamos familiarizados con las tablas.

Ejemplo base

En este post, el código HTML de referencia es el siguiente:

<!DOCTYPE html>
<html>

<head>
    <meta charset="utf-8">
    <title>HTML 5 Accesible Table</title>
    <link rel="stylesheet" href="style.css" media="screen" title="stylesheet">
</head>

<body>
    <table class="table" role="presentation">
        <colgroup>
            <col class="column-select">
            <col class="column-name">
            <col class="column-surname">
        </colgroup>
        <thead>
            <tr>
                <th scope="col">Selected Row</th>
                <th scope="col">Name</th>
                <th scope="col">Surname</th>
            </tr>
        </thead>
        <tbody role="grid" aria-multiselectable="true">
            <tr role="row" id="row-1">
                <td role="gridcell">
                    <input type="checkbox" aria-labelledby="row-1" name="selected-row-1" value="0" id="check-1" checked>
                </td>
                <td role="gridcell">Elena</td>
                <td role="gridcell">Torro</td>
            </tr>
            <tr role="row" id="row-2">
                <td role="gridcell">
                  <input type="checkbox" aria-labelledby="row-2" name="selected-row-2" value="1" id="check-2">
                </td>
                <td role="gridcell">Alvaro</td>
                <td role="gridcell">Torro</td>
            </tr>
        </tbody>
    </table>
</body>

</html>

<colgroup>

Esta etiqueta que desconocía por completo es de gran utilidad. Me surgió la necesidad de añadir ciertas clases a las distintas columnas de una tabla, y acudí de cabeza a tocar el CSS. ERROOOOR. Para aplicar estilos concretos, conviene utilizar las etiquetas <colgroup> y <col>. Como se aprecia en el código de referencia, gracias a estas etiquetas podemos aplicar un estilo específico a cada columna. Esto es mega útil. En este caso, quiero que mi tabla tenga una primera columna más estrecha que las demás, que utilizaré para colocar el checkbox que seleccionará la fila.

Roles

Algunos tips de roles en tablas:

  • Si usamos th, no es necesario utilizar role=”colheader”
  • Si el tag <tbody>tiene el rol grid, esto nos permitirá que también pueda tener el atributo aria aria-multiselectable. Un grid es un control interactivo que contiene celdas o contenido tabular ordenado en filas y columnas. Es decir, no se limita sólo a las tablas.
  • Se puede ver si un rol puede ser problemático, como es el caso de role="presentation" en las tablas: http://www.powermapper.com/tests/screen-readers/tables/table-role-presentation/

Seleccionar filas

Hay ciertas interacciones que por convención se utilizan generalmente en información dispuesta en forma de tabla. Por ejemplo, el manager de Wordpress o la bandeja de correo de Gmail. En mi caso, he estado mirando cómo la bandeja de Gmail ha manejado el tema de la selección de filas, y lo he reflejado en el código de referencia (de manera MUY simplificada). Como se puede apreciar, cada fila tiene un identificador id. Así, se puede identificar qué fila se selecciona mediante el checkbox.

En mi caso, estoy usando el lector de pantalla ChromeVox para el navegador Chrome. Como dato sin utilidad, le he puesto la voz ‘Diego’ porque es la que menos ansiedad me produce. Lo que pasa cuando me coloco sobre la primera celda de selección, en la que hay un checkbox, Diego me dice:

  • ‘Elena Torro. Cell selected.’

Y en la segunda:

  • ‘Alvaro Torro. Cell not selected.’

Y al hacer click en ambos checkboxes, respectivamente:

  • ‘Elena Torro. Checkbox not checked.’
  • ‘Alvaro Torro. Checkbox checked.’

Pero OJO. Si en la celda en la que tengo el nombre y el apellido tuviera un aria-label, es decir:

<td role="gridcell" aria-label="Name">Elena</td>
<td role="gridcell" aria-label="Surname">Torro</td>

entonces dirá el contenido de este atributo:

  • ‘Name Surname. Checkbox not checked.’

Problema: `aria-checked’. Éste atributo ARIA nos ayuda a saber si el checkbox está marcado o no. El problema es que, si queremos cambiar su estado, hemos de utilizar JavaScript cuando el usuario haga click en el checkbox para cambiar este atributo. Al utilizar el lector de pantalla, éste hace primero caso al aria-checked, ya esté marcado o no. Sin embargo, al omitir el atributo, el lector de pantalla lee el input correctamente. ¿Alguien conoce una solución? #INeedHelp.

Para los que os adentréis en algún link de la bibliografía, o bien busquéis más sobre el tema en Internet, veréis que la documentación sobre los atributos ARIA y sus aplicaciones es, cuanto menos, extensa. Coged un café y poneos cómodos si vais a empezar a leer algo. Como siempre digo, ¡el feedback es bienvenido!

Bibliografía

poser.js

border-top-style: anti-poser;

Llevo mucho tiempo sin escribir en este blog, a pesar de que me propuse hacerlo de manera constante, por dos razones. La primera de ellas es el tiempo, y éste es mi problema por querer hacer demasiadas cosas, y todo junto no se puede. Esto no sería una razón si no tuviera que ver con la segunda razón, ya que al fin y al cabo, cuando de verdad te apetece hacer algo, encuentras tiempo para ello.

La segunda razón es el postureo. Muchas personas me han tachado de postureta por tener un blog, subir proyectos a github o asistir a eventos de informática.

Hay veces que leo posts de terceros que me parecen escritos por puro postureo, que son escritos para aparentar saber de algo o para ver cuántos likes consiguen en todas las redes sociales en las que lo comparten. Por eso, cuando me dicen postureta, me viene a la mente alguno de estos posts y me da vergüenza pensar que ésa es la imagen que doy. No escribo para aparentar saber de algo, sino como la mayoría de gente que escribe posts, por aprender, porque apetece, por compartir.

Siguiendo el hilo de escribir posts por postureo, llega el mundo de asistir a eventos/meetups/quedadas/conferencias por postureo. Hace tres años y medio, asistí a mi primera conferencia de informática (Codemotion, en Madrid), y me gustó muchísimo la experiencia. No tanto por lo que pudiera aprender, que en realidad no asistes con el propósito de aprender, sino porque en un fin de semana me puse al día de cómo estaba el mundo por el que me movía. Conocí a gente, conocí tecnologías y cogí mucha inspiración, que me ha ayudado muchísimo desde entonces. Y por eso me encanta participar en este tipo de eventos, y lo hago siempre que puedo. Hace una semana asistí a un Software Craftmanship en Murcia, y me lo pasé pipa. Además, voy a ser coorganizadora de Betabeers Murcia, y tengo muchas ganas. Porque aquí en Murcia hay gente muy buena, con ganas de compartir, y la comunidad cada vez se está moviendo más, ¡y eso me entusiasma! Creo que merece la pena que haya más sitios aparte de Madrid y Barcelona en los que se muevan cosas, y eso es lo que quiero hacer en Murcia.

Pero cuidado, asistir a este tipo de eventos también es postureo. Dar charlas es postureo. Compartirlo en redes sociales es postureo. Escribir un blog tecnológico es postureo.

Evidentemente, no creo que eso sea así. Sin embargo, sí que es cierto que a nivel personal, estoy en un punto en el que considero que he desviado el verdadero objetivo de las cosas que hago. Y es que sin querer, caes en la espiral de hacer las cosas por un like, un retweet, un comentario, porque alguien comparta tu post, tu foto, tu proyecto fabuloso, tu nueva microlibrería que lo va a petar. Por eso no voy a compartir este post, que he escrito porque quería, no para que alguien lo leyera.

En relación a este tema, dejo este vídeo de la pasada JSDay a la que no pude asistir, que me ha hecho pensar mucho.

Web Weekly #2

border-top-style: reactive;

Programación Reactiva

“Se espera que un sistema reactivo interaccione con su entorno, intercalando las entradas y las salidas de forma temporal, lo que quiere decir que dentro de una cantidad de tiempo adecuado (lo que se considere adecuado depende del dominio de aplicación) el sistema devuelva una respuesta en función de las entradas recibidas y continúe con el ciclo de ejecución.” Fernando Sancho Caparrini

La semana pasada se despertó en mí la curiosidad sobre la programación reactiva, a raíz de este vídeo:

A modo de resumen, la programación reactiva es un paradigma de programación, una programación que se enfoca a la gestión asíncrona de los datos (llamadas AJAX, eventos, workers, sockets…) Nos interesa, por lo tanto, utilizar programación reactiva cuando hemos de realizar un alto número de operaciones asíncronas. Uno de los ejemplos que usa el vídeo es el de cancelar una llamada AJAX si el usuario cancela la acción que la desencadena. Explica RxJS, un proyecto desarrollado por Microsoft, compuesto por una serie de librerías que extiende la funcionalidad reactiva. Introduce los objetos Observer, que introduce los distintos flujos de datos en el flujo de eventos, y el objeto Observable, que notifica al observer cuando un evento ocurre.

Reactive Extensions for JavaScript unify both the world of Promises, callbacks as well as evented data such as DOM Input, Web Workers, and Web Sockets. Unifying these concepts enables rich composition.

En relación a este tema, llegué a este post, que explica los principios de la programación reactiva. Para entenderlo un poco mejor, nos expone los cuatro principios que ha de tener una aplicación desarrollada con este paradigma:

  • Responsive: Un sistema responsive reacciona rápidamente a todos los usuarios (tanto en escenarios favorables como desfavorables) para asegurar una experiencia de usuario positiva y consistente
  • Scalable: Un sistema escalable es fácil de actualizar bajo demanda para asegurar que seguirá siendo responsive bajo distintas condiciones de carga
  • Resilient: Un sistema flexible aplica principios de diseño y arquitectura para asegurar que es responsive en escenarios favorables y desfavorables.
  • Message-driven: Un arquitectura conducida por mensajes es la base de las aplicaciones reactivas. Tiene que ser dirigida por eventos, basada en actores o una combinación de ambos.

JavaScript en 2016

Un post recopilatorio que recomiendo esta semana es State of the Art JavaScript in 2016 . Habla de los frameworks/tecnologías que más se utilizan/van a utilizarse este año (React, Redux, ES6, Babel, Webpack…). Al final, ofrece una serie de links para leer más sobre estos temas. Creo que es un buen post para mantenerse up-to-date y que es interesante leer.👌

Houdini

Un problema al que nos enfrentamos a diario los que escribimos CSS es el de la compatibilidad entre navegadores. Houdini no es un nuevo framework mágico que hay que aprender, si es lo que al leer temíais (como yo). Es más bien un objetivo de la W3C para que desaparezca este problema.

Se trata de introducir un nuevo set de APIs que extentiendan el propio CSS. El artículo explica las siguientes cuestiones:

  • ¿Qué problema exactamente quiere resolver?
  • ¿Es una buena idea?
  • ¿Cómo ayudará a los desarrolladores a construir sitios web?

Imagen: http://vrdeveloper.org/ # WebVR

Es indudable que la realidad aumentada y la realidad virtual (AR, VR) están ya entre nosotros, incluyendo la web. Un claro ejemplo es el proyecto MozVR

Pero, ¿qué necesitamos para llevar esta tecnología a la web? En este post encontramos el stack tecnológico que va a empezar pegando fuerte en este área. Entre ellos se encuentra, como no podía ser menos, three.js. Existe un boilerplate open source que podemos encontrar en GitHub. La primera versión del API estará disponible, dicen, este verano en Firefox Nightly. Si tenéis interés, podéis empezar a 👓 estudiar la documentación👓 de WebVR. Para saber cuándo estará listo, existe la web is WebVR ready?. Para mantenerse al día en este tema, también conviene seguir el blog de Brandon Jones, desarrollador de WebGL y WebVR para Chrome en Google. También hablan del tema en el siguiente tumblr.

La posibilidad de utilizar los smartphones como gafas de realidad aumentada junto con otras tecnologías como por ejemplo el LeapMotion pueden dar un juego brutal. Y no sólo eso, sino que la experiencia de usuario (UX) también tiene un papel esencial en todo esto:

Como véis, este campo me llama mucho la atención y me interesa bastante.

NPM Drama

Estoy escribiendo un post más extenso sobre este tema, así que aquí lo comentaré por encima, porque no podía no mencionarlo en éste. Ha sido, sin duda, uno de los temas más comentados esta semana.

Muy brevemente: La empresa Kik obliga a Azer Koçulu, desarrollador de una librería de NPM con el mismo nombre, a borrar esta librería open source ya que el nombre lo tienen pillado ellos. Él se niega. Kik habla con NPM, y ellos la borran. Azer decide borrar, por lo tanto, todas sus librerías que tenía subidas en NPM ya que opina que el hecho de eliminar la librería de otra persona sin su consentimiento no encaja con la filosofía que tiene sobre las librerías open source. Desafortunadamente, Azer había escrito una librería de once líneas que utilizaban React, Babel y otros paquetes archiconocidos. Resultado: estos paquetes se rompen, todos los proyectos que los utilizaban se rompen. He aquí el drama, pero no voy a decir nada más hasta el post 😁 ## Otros * Generación de documentación en JS * Truquillos frontend * Animating with React, Redux, and d3

Espero que os haya gustado este nuevo Web Weekly, ¡nos vemos la semana que viene en el siguiente!

Imagen de portada: gigaom

Web Weekly #1

Estado actual:

border-top-style: responsive;

¡Aquí está! ¡Lo prometido es deuda! Como comentaba en mi post anterior, cada domingo haré un recopilatorio de los temas relacionados con el desarrollo web que he ido viendo durante la semana. ¡Empezamos!

Cómo mejorar como diseñador web

He elegido este post para comenzar ya que el objetivo de esta sección en mi blog es parte de este propósito: mejorar. Básicamente, lo que dice este post es bastante obvio. No obstante, eso no quiere decir que lo cumplamos. Aunque se centra en la parte de ‘diseño’, vale para cualquier tipo de ámbito.

It’s very easy to lose inspiration, when we are not surrounded by a learning and inspirational community. You know you love what you do, so don’t quit. In order to counteract the situation, you need to go further, learn new things, and adopt new work methods

Esta lista tiene varios puntos, de los cuales destaco:

  • Ver tutoriales (uno al día)
  • Reproducir diseños existentes: ojo, esto no es copiar. Se aprende muchísimo practicando cómo reproducir un diseño o una herramienta, ya que se adquiere práctica y nuevas técnicas.
  • Redecorar tu lugar de trabajo (hablaré de esto en un futuro post ;)
  • Leer, leer y LEER
  • Hacer contactos. Esto es cierto, conocer gente que haga lo mismo que tú hace que te mantengas al día.
  • Tener una libreta. Esto es obviamente imprescindible. Yo uso una pequeña que me cabe en el bolso de la tienda Tiger

rel=noopener

Mathias Bynens es una persona a la que deberías seguir si te dedicas al desarrollo web. Yo tuve la suerte de verlo en el codefront.io de Austria, en Linz, donde impartió una charla chulísima sobre Unicode en JavaScript.

En este artículo, explica brevemente los peligros que entraña clickar en un link que te lleva a otra página, ya que mientras te ha sacado de la página en la que estabas, desde la nueva página puede tener control sobre la anterior sin que te des cuenta. Es decir, en la nueva página no pasa nada, todo ok, pero un atacante puede aprovechar esa distracción y hacer algo malicioso, ya que tiene acceso sobre el objeto window de la ventana anterior. Muy interesante esta lectura.

Simplificando el testing

Este post de Eric Elliot me ha gustado en especial por la manera en la que aborda el tema del testing, tanto en JavaScript como en general. A pesar de que en un principio el tema parece centrado en JS, lo que destaco es la perspectiva general de que hay frameworks de testing que tienen demasiadas cosas. Cosas que no necesitas para testear.

Por ejemplo, el hecho de tener que configurar todo el entorno de tests ha de ser algo sencillo, sin embargo, actualmente muchos frameworks necesitan de un setup previo tedioso en el que acabas invirtiendo más tiempo que en el propio testing.

Mocha, Jasmine, and several other alternatives pollute the global environment with functions like describe, it, etc… Some assertion libraries extend built-in prototypes. Aside from removing the self-documenting nature of simple module exports, those decisions could potentially conflict with the code you’re trying to test.

También menciona que beforeEachy afterEach no han de utilizarse ya que hacen que el estado se comparta entre distintos tests.

Testing is not what you should spend most of your time doing. You should spend most of your time thinking about how to create the best, most flexible, most performant solutions given the afforded time constraints. Time is value in the software development world, and you shouldn’t waste one minute of it.

Otro comentario que me gustó mucho fue el de que muchos frameworks contienen demasiados tipos de aserciones. En esto también estoy de acuerdo, porque en mi caso, siempre acabo usando prácticamente las cuatro o cinco aserciones típicas, ya que las demás me dan el mismo resultado y considero redundantes. Aquí puedes ver una lista de aserciones de Jasmine, mientras que el post afirma que: equal, deepEqual, pass & fail are my primary go-to assertions. If equal and deepEqual were the only assertions available anywhere, the testing world would probably be better off for it.

Además, el autor ha sido en si mismo otro descubrimiento, porque no lo conocía.

Estilo en imágenes rotas

¿Qué pasa cuando una imagen no funciona? ¿Es suficiente con tener un texto alternativo? En este post de Ire Aderinokun explica un truco para aplicar estilo a una imagen que no se puede ver, y la posibilidad de usar este truco en los distintos navegadores (i.e: webkit bugs ). La autora del blog es una diseñadora y desarrolladora nigeriana que tiene proyectos muy interesantes.

Experiencia personal: traduciendo para MDN

Hace años luz me registré en la Mozilla Developer Network, y hace poco descubrí que podías ayudar a traducir los documentos (en mi caso, de inglés a castellano). La experiencia es muy interesante, ya que inevitablemente aprendes, y hay muuuuuchas cosas aún por traducir. ES MÁS, la mayoría de los textos necesitan una revisión, ya que es algo que se hace voluntario y por amor al arte. Es decir, no hay un traductor profesional contratado.

En parte es algo que asusta. A mí me toca mucho el tema de que cada vez la gente escribe peor, porque además, tiene malos ejemplos. Internet está plagado de ellos. Es muy bueno que haya tanta información, pero es importante recordar que la calidad de esta información es esencial ya que, si ésta es errónea, estamos aprendiendo cosas incorrectas. Creo que es una buena práctica ayudar a traducir estos textos, y os animo a hacerlo, tanto a traducir como a corregir. Además, ¡se aprende muchísimo! porque te obligas a entender verdaderamente qué es lo que estás escribiendo.

Otros

En realidad, he recopilado más cosas, que tengo bien guardadas en pocket. Poco a poco irán viendo la luz. En este primer post, me gustaría saber si os ha parecido demasiado corto, os i no he opinado lo suficiente, o si esperabais un contenido distinto. ¡FEEDBACK, PLEASE!

Un saludo :D

Web Weekly

Estado actual:

border-top-style: a tope;

Vuelvo a escribir en el blog con las pilas cargadas después de un intenso fin de semana. Éste es un post hiperbreve en el que contaré dos cosillas:

  • Primera cosilla: Abro una sección semanal, titulada: ‘Web Weekly’. El nombre no es muy allá, pero ése no es el tema 😁. Lo hago porque me he dado cuenta de que, a pesar que leo bastantes artículos, en muchas ocasiones lo hago muy por encima, no me intereso en un tema en concreto, y en definitiva, pierdo el foco. Para reencontrarlo, me voy a obligar a escribir un post cada semana sobre lo que he leído durante los últimos siete días. Algunos posts contendrán cosas que he aprendido, pero también cosas que ya sabía y que he refrescado, o que han cambiado y he tenido que actualizar en mi cerebro. De esta manera me obligaré a mantenerme up-to-date, y creo que el contenido puede ser interesante. La idea es escribirla todos los domingos, así que ya he comenzado a preparar el de la siguiente semana.

  • Segunda cosilla: En relación con el tema de mantenerme desactualizada y de perder el foco, que es una tendencia recurrente en estos últimos meses que quiero erradicar, he abierto un repositorio de dicionario de términos en GitHub. Son pequeños conceptos que surgen en una conversación, al leer un post o que encuentras por casualidad en Stakoverflow. En concreto, mis diccionarios están relacionados con HTML, CSS y JS principalmente.

Esto es una medida que he tomado ante esa sensación que surge al estar en un mundo en el que todo cambia muy rápido, donde cada día salen cosas nuevas, y donde vivimos rodeados de un exceso de información que muchas veces, más que ayudar, agobia. Creo que cada uno ha de encontrar la manera de manejar esa gran cantidad de información que nos bombardea, y en mi caso, creo que este blog es el camino.

Muchas gracias por leer :)

i18n en Ghost

Current status:

border-top-style: multilanguage;

Hace tiempo me surgió la necesidad de hacer un blog escrito en distintos idiomas, ya que me gustaría que mi contenido no sólo se limitara a los hispanohablantes. El caso es que siempre me he liado con el tema, no hay ninguna solución que me apañe para Ghost y aún estoy esperando a que los desarrolladores de éste saquen esta feature (ya que están en ello).

Hace tiempo hice una librería muy light para manipular el DOM, algo que hacen casi todos los desarrolladores frontend que conozco (como Bliss, de Lea Verou, la cual explica cómo llegó a crear la suya en su blog). Esta librería se llama LookJS, y es de uso personal, pero ahí está, que nunca se sabe. Tiene muchos defectos, como que no usa la signatura ‘$’ para acceder a los distintos elementos del DOM (lo cual, según me apuntó Kiko Beats es un gran error, ya que todo el mundo se ha acostumbrado a esta sintaxis, y al final me soltó un ‘Convention over configuration’ que no pude discutir). En cualquier caso, de momento la utilizo para pequeños proyectos, y ya que tiene un módulo de traducción he decidido utilizarla como mecanismo de traducción momentánea hasta que Ghost saque la oficial.

Estoy escribiendo esto porque no sé cómo este apaño que he hecho puede afectar al posicionamiento del blog, y tal vez no sea una buena opción para aquéllos que quieran ver su contenido en el top de los buscadores. Tampoco sé si es lo idóneo en temas de accesibilidad, y eso me mosquea. Explico cómo va y si estás leyendo esto y piensas: ‘pero alma de cántaro, t’as liao’, escríbeme, hazme un PR o comenta en este post.

El caso. Cada elemento que quieras traducir tiene que estar incluido en un JSON con la siguiente estructura. Dependiendo de cómo quieras acceder a este elemento, has de indicarlo (por id, por clase, por tag…). Esto es importante, ya que hay que tener en cuenta lo siguiente:

  • Si es el título, conviene que se añada un id al título o que se seleccione el primer ‘h1’, que correspondería al título, ya que sabemos que sólo va a haber uno.

  • Si, por otra parte, queremos traducir todos los elementos del menú de navegación, podemos seleccionar los elementos por clase y añadir una traducción a cada uno de manera ordenada. En Ghost se genera la navegación, por lo que esta opción es más sencilla que añadir un id a cada uno de los elementos del menú. Pero vamos, que esto a gusto del consumidor.

Así es como se traduciría el menú de navegación:

<nav class="navbar">
    <div class="container">
      <ul class="navbar-list">
        
        <li class="navbar-item"><a class="navbar-link" href=""></a></li>
        
      </ul>
    </div>
</nav>

Por defecto, en el valor ** aparecerán los distintos elementos del menú que una tenga configurado en Ghost. A partir de esto, creamos nuestro objeto:

{
	'class' : {
		'navbar-link' : {
			'0' : {
				'EN' : 'Home',
				'ES' : 'Principal'
			},
			'1' : {
				'EN' : 'About',
				'ES' : 'Sobre nosotros'
			},
			'2' : {
				'EN' : 'Our work',
				'ES' : 'Nuestros trabajos'
			}
		}
	}
};

Otro ejemplo: los botones de siguiente posts, post anterior, read more, posts nuevos, posts anteriores…

{
	'id' : {
		'nextPost': {
	        'EN': 'Next Post',
	        'ES': 'Siguiente post'
	    },
	    'previousPost': {
	        'EN': 'Previous Post',
	        'ES': 'Post anterior'
	    },
	    'newerPosts' : {
	    	'EN' : 'Newer posts',
	    	'ES' : 'Posts más recientes'
	    },
	    'olderPosts' : {
	    	'EN' : 'Older posts',
	    	'ES' : 'Posts más antiguos'
	    }
	},
	'allClass' : {
		'readMore' : {
			'EN' : 'Read More',
			'ES' : 'Seguir leyendo'
		}
	}
};

Importante: El interior del tag sí que tiene que tener contenido. Es decir, que lo puedes dejar vacío si quieres, pero lo ideal es que tenga puesto una texto por defecto (en mi caso, tengo puesto los textos en inglés).

Lo siguiente es aplicar las traducciones. Aquí es donde entra en juego Look. Los pasos que he tenido en cuenta son:

1. Cookies

Queremos que las traducciones se apliquen a todas las páginas del blog. Nuestro script detectará si hay algún idioma seleccionado que se haya guardado en las cookies, y si no pondrá uno por defecto.

var cookie: 'el_nombre_de_tu_cookie';

if (!Look.cookie.exists(cookie)) {
  Look.cookie.set(cookie, 'EN');
};

2. Botones

Tendrás que crear unos botones para cambiar de idioma, los cuales llamarán a la función de cambiar de idioma que veremos en el paso 3:

  • Javascript var changeLanguageButtons = Look.getBy.className('changeLanguage'); var i; for (i = 0; i < changeLanguageButtons.length; i++) { changeLanguageButtons[i].addEventListener('click', function (data) { changeLanguage(data.toElement.dataset.language); }); };

  • HTML <button class="changeLanguage" data-language="ES">Español</button> <button class="changeLanguage" data-language="EN">English</button>

El atributo que identifica el idioma es data-language, al que accedemos en el script mediante dataset.language.

3. Cambiar de idioma

Al cambiar de idioma, le pasaremos a Look el id del idioma al que se cambia (data-language) y el set de traducciones. Y no hay que olvidarse de cambiar las cookie.

function changeLanguage (language) {
	Look.language.change(language, posts);
	Look.cookie.set(cookie, language);
};

El código está en este repo de GitHub por si te lo quieres descargar. También puedes añadir lo siguiente en las settings de tu blog (no olvides añadir primero el script de LookJS):

Ghost Settings Screenshot

Ejemplo:

Imagen de portada: Buzz

CSS Birthday Cake

Estado actual:

border-top-style: old;

El pasado sábado 6 de febrero cumplí 24 años, y para celebrarlo se me ocurrió, entre otras cosas, dibujar una tarta puramente con CSS. Y, ya de paso, grabar el proceso en un vídeo como experimento con YouTube. Y a ver qué pasa.

Vídeo

CodePen

Birthday Cake

HTML5 y Accesibilidad

Estado actual:

border-top-style: accessible;

Unas semanas atrás escribí un post sobre la tendencia que tenemos los programadores web en escribir código HTML e inundar la web de divs. Esto afecta a la accesibilidad de las páginas y aplicaciones web, y la gente que hay detrás y permanece en la sombra está esforzándose para que los navegadores sean más accesibles. Y personalmente, este es un tema que, a pesar de que me interesa muchísimo, no lo aplico todo lo que debería (cosa que está cambiando).

Este post surge a raíz de la conferencia Novedades en HTML5 accesible para la gestión de recursos multimedia, parte del II Workshop “Tecnología y Accesibilidad” UNED - Fundación Vodafone. He llegado hasta esta charla a través de la asignatura ‘Usabilidad y Accesibilidad’ que estoy cursando en el Máster. El ponente es Chaals McCathie Nevile, un Australiano que trabaja en Yandex, el buscador más usado en Rusia, y que ha trabajado para la W3C.

He recopilado lo que más me ha interesado y que creo que puede resultar interesante para los que quieran saber hacia donde están conducidos estos avances.

Video y Audio

Mola mucho que no tengas que utilizar pluggins de terceros como había que hacer antaño para incluir vídeo y audio en la web. HTML5 incluye estos tags para hacerlo todo más sencillo y adaptable.

Además, son elementos bastante customizables, porque tienen la opción de añadir los controles (play, pause, stop…) de la manera que el desarrollador desee.

Sin embargo, aún faltan cosillas. Por ejemplo, no existe una manera de incluir una transcripción a un vídeo, y que ésta se sincronice con el contenido del vídeo, lo cual sería un gran avance en términos de accesibilidad.

ARIA

Son las siglas de ‘Accessible Rich Internet Applications’. Se trata de una serie de atributos que se pueden añadir a los elementos HTML. Estos atributos se comunican con las APIs de accesibilidad que tienen los distintos navegadores, haciendo que el uso de los tags sea más semántico, proporcionando más información a los navegadores.

Cuando desarrollamos elementos webs, hemos de dotar a estos de un contenido extra, de una explicación, de datos que hagan ese elemento más accesible. Así, los navegadores interpretan la información de un elemento y la pueden utilizar en tecnologías de asistencia para, por ejemplo, personas con dificultades o discapacidades.

Imagen: W3C

He hecho un breve esquema a partir de la documentación que ofrece el W3C.

  • roles:
    • define un elemento de interfaz de usuario
  • estados y propiedades: aria-*
    • el nombre del atributo empieza con “aria-“ para reducir la posibilidad de que coincida con otros atributos existentes.
    • ejemplos:
      • aria-checked
      • aria-haspopup
      • aria-labelledby
    • tabla de estados y propiedades soportados

Aquí vemos unos ejemplos de código: ```

  • Sort by Last Modified
  • 
    

    ```

    Existen unas directivas que seguir a la hora de utilizar ARIA en HTML5. También se consultar el siguiente diagrama de clases que explica más sobre los roles y su herencia.

    La documentación es muy extensa, pero creo que merece la pena estudiarla con atención.

    longdesc

    HTML4 tenía una propiedad conocida como longdesc, cuyo propósito era el de añadir información adicional a una imagen. Cuando no sólo basta con el atributo alt, y se necesita una descripción más detallada.

    Buscando información al respecto, he encontrado este post de Olga Carreras en el que explica este atributo y sus alternativas en HTML5. Básicamente, el uso de este atributo conllevaba cumplir una serie de reglas, sin embargo, ‘un 0.13% incluían el atributo LONGDESC. De este porcentaje solo un 1% tenían un LONGDESC adecuado.’ Este post es muy interesante, ya que en él podemos encontrar:

    • Cómo usar correctamente el atributo longdesc
    • Soporte del atributo en los distintos navegadores
    • Soporte del atributo en lectores de pantalla.

    También explica como usar ARIA de manera alternativa para este mismo propósito. Me ha encantado este post.

    El problema de accessKey y JavaScript

    Como podemos leer en Mozilla Developer Network: ‘El atributo global accesskey provee un indicio para generar un atajo de teclado para el elemento actual . Este atributo consiste en una lista de caracteres separada por espacios (un único punto de código Unicode). El explorador usa el primero que existe en la distribución del teclado de la computadora .’ Es decir, ofrece la posibilidad de extender la interacción con el DOM sin necesidad de escribir un script.

    El uso de este atributo conlleva muchos problemas.

    Chaals nos habla en su charla de que no usemos JavaScript para definir interacciones en este atributo, ya que estos hacen que el User Agent (ver esquema anterior) no interactúe como es debido. Para combatir este mal uso del atributo, tiene un repositorio en GitHub en el que propone un cambio del uso de accesskey en HTML. En este ejemplo se comprueban los problemas del uso de accesskey mediante un test en distintos navegadores.

    Nuevas tecnologías y adaptación accesible

    En una de las preguntas, un chico preguntaba acerca de la inclusión de la accesibilidad en tecnologías que usamos hoy en día como AngularJS, Polymer o React.

    La respuesta de Chaals es que se está intentando dar una solución a estas tecnologías, en las cuales ‘todo lo que no se ve, no existe’. Se van mostrando y ocultando partes, y sólo lo que está enfrente del usuario existe y se puede interactuar con él. Según él, los ingenieros no incluyen accesibilidad en estas tecnologías, pero sí que es posible incluir accesibilidad (mientras otras más antiguas como JQuery, del cual reniego a menudo, sí que lo hacen, aunque no ha dado más referencias sobre este tema.)

    Leyendo la especificación de ARIA de W3C he encontrado este apartado sobre contenido dinámico, que creo que responde en cierto modo a la pregunta anterior, y veo que es un tema muy interesante. La accesibilidad en aplicaciones dinámicas y SPAs.

    Imagen de portada: Swing

    La Ley de Fitts

    ¿Qué es la Ley de Fitts?

    Estado actual: <pre>border-top-style: calculated; </pre>

    No todo en el mundo del diseño de interfaces son colores, formas, patrones o diseño responsive. También hay un lado técnico que no se ve a primera vista, pero que ahí está.

    Por eso, en mi post de hoy, voy a comentaros qué es la Ley de Fitts. Paul Fitts era un psicólogo de Ohio que nació hace más de 100 años. Con esto vengo a decir que el diseño y la psicología del diseño no es una moda reciente, sino que ya tiene unos cuantos añitos a sus espaldas. Este hombre tuvo una gran repercusión en el ámbito que hoy conocemos como “Human-Computer Interaction”, o Interacción Hombre-Máquina. (HCI)

    Publicó en 1945 un artículo titulado “The information capacity of the human motor system in controlling the amplitude of movement”. En este estudio, Fitts obtiene la manera de predecir el tiempo que una persona necesita para alcanzar un objetivo, dado un tamaño de dicho objetivo y una distancia a éste. Hay que ver cómo nos gusta a las personas calcularlo todo y encontrar maneras de medir las cosas. Total, que en el campo del HCI esto se ha convertido en un must-know, y se aplica en el diseño de interfaces. ¿Cuánto tarda un usuario en hacer click utilizando el ratón en un botón en concreto, situado en una posición [x,y] de la aplicación que está usando?

    La conclusión de Fitts es que se tarda más en alcanzar un objetivo que está más lejos, y que también se tarda más si el objetivo es más pequeño. Sí, vale, esto es bastante obvious. Pero alguien tenía que decirlo, y ése fue Fitts.

    Hasta aquí todo es bastante sencillo. Pero claro, no todos los sistemas son iguales. Por ejemplo, el tiempo que voy a tardar en dibujar una línea recta con un bolígrafo desde la esquina superior izquierda de mi libreta hasta un punto en el centro de la misma, va a depender de varios factores: el tipo de tinta del bolígrafo, la rugosidad del papel, la velocidad a la que yo dibujo la línea… Si tuviéramos que trazar la misma distancia hacia un punto con las mismas dimensiones, utilizando un ratón en una aplicación de dibujo, los factores determinantes serían distintos: la velocidad de pintado de píxeles de la aplicación, lo bien que se me dé utilizar el ratón, la velocidad a la que haya configurado éste…

    Las imágenes anteriores las he obtenido de este artículo, que lo ilustra y explica bastante bien.

    La fórmula simple de la ecuación propuesta por Fitts es la siguiente:

    Índice de Dificultad = log2( 2 Distancia / Ancho del objetivo )

    A esta fórmula hay que añadir las variables que comentaba anteriormente. Un poco más desarrollada, la cosa queda tal que así:

    Tiempo de alcance del objetivo = a + b * Índice de Dificultad

    Siendo a la constante del tiempo de reacción, y b la constante del tiempo que el sistema nervioso humano necesita para procesar un bit. Esta ley resulta de gran utilidad para, por ejemplo, diseños de menús desplegables

    Esta parte nerd del diseño me gusta bastante. Son detalles que muchas veces no tengo en cuenta a la hora de desarrollar una interfaz. Es interesante ver cómo han ido evolucionando los estudios a lo largo del tiempo, cómo se están aplicando al desarrollo de aplicaciones hoy en día.

    Artículos relacionados:

    • https://msdn.microsoft.com/en-us/library/ms993291.aspx
    • http://www.yorku.ca/mack/hci1992.pdf
    • http://www.simonwallner.at/ext/fitts/
    • http://www.sigchi.org/chi97/proceedings/paper/ja.htm

    Life

    Un proyecto ‘software’ muy personal

    border-top-style: solid;
    

    Hace unos días, descubrí el siguiente proyecto de GitHub un tanto peculiar: https://github.com/feross/Life

    Es una idea original de Feross Aboukhadijeh, un chico de 25 años (sólo dos años más que yo) que ha estudiado en Standford y ya ha trabajado en Quora, Facebook, Intel, ha dado clases, y hace proyectos increíbles como WebTorrent . Una de esas personas que me hacen preguntarle a mi madre: Mamá, ¿qué estoy haciendo con mi vida? Una de esas personas que inspiran y que hacen que veas que puedes superarte a ti mismo.

    Pues precisamente ha creado un repositorio con ese mismo nombre, ‘Vida’. El concepto es el siguiente: utilizar GitHub para llevar tu vida como si fuera otro proyecto software. Vaya, dicho así en voz alta suena un poco inquietante, pero es más humano de lo que parece.

    Consta de un único archivo: un README.md con un link a ‘goals’ y otro a ‘achievements’. Es decir, usas la plataforma para abrir issues, que son los objetivos que te quieres marcar, y cuando los cumples, pasan a la lista de objetivos conseguidos. Puedes añadir comentarios, checklists, tags… Es una idea muy simple, pero que me ha hecho pensar de cara al año 2016, que está a la vuelta de la esquina.

    ¿Qué he hecho este año? ¿Qué objetivos he conseguido? Sí, sé que he conseguido muchas cosas. Conseguí acabar la carrera, empezar el máster, trabajar, independizarme, leer más de 25 libros, salir más de ‘fiesta’ (esto es una lucha personal), pasar más tiempo con mi familia… pero también hay cosas que no he conseguido. Sólo he hecho dos viajes, no he conseguido correr a menos velocidad de 6.30 minutos por km (cinco runners se están riendo de esto ahora mismo), tampoco he conseguido terminar un proyecto (no encuentro mi side-project perfecto)… Y así. Son cosas que tengo en mente y que no contabilizo más que de cabeza.

    Ésta es la lista de objetivos cumplidos por Feross desde el año 2013. En mi caso, aquí están los issues que me he propuesto en mi Life Project

    ¿Y qué quiero conseguir con esto? 💪

    Tengo muchas ganas de probar este experimento. Quiero ser más agile. Mejorar la user experience de los que me rodean. Espero darle un responsive design a mi humor. Quiero lanzar una nueva release llena de improvements. Arreglar bugs. Mejorar la versión de mi vida tras cada actualización. Tener una actitud más open source. También seguir más la técnica KISS, y no sólo porque quiera dar más besos, sino por aplicar el ‘Keep It Simple, Stupid’. Eliminar y minimizar los assets que no utilizo. Quiero aceptar más pull requests. Crear una nueva branch, y si funciona, mergearlo con la máster. Y si no, a resolver otro issue.

    Espero que os guste y que también cumpláis vuestros objetivos este año. Feliz 2016 😘

    Lo que me pasó creando un paquete en npm

    Estado actual:

    border-top-style: frankenstein;
    

    No lo he dicho todavía, pero este blog no es un lugar en el que quiera escribir posts al estilo: ‘cómo hacer una app usando el stack Rails + AngularJS + Pascal + Foundation + MariaDB + JQuery’. Aquí cuento mis experiencias de diseño y de desarrollo, y eso es un poco lo que quería escribir hoy. Más que nada, para que la próxima vez que vaya a escribir un paquete npm en concreto, o una pieza reutilizable de software en general, me acuerde de mis errores y no los cometa de nuevo. O al menos, no los cometa tanto.

    ¿Necesito hacer un paquete npm?

    Ésa es la primera pregunta que hay que contestarse. Esta mañana leía de camino al trabajo (niños, aunque tengáis coche, usad el transporte público, el planeta os lo agradecerá, y vuestra mente también) un post en el que citaba la siguiente frase de Douglas Crockford: ‘Software is the most complex thing that humans have ever created’. Y me ha explotado un poquito el cerebro, porque instantáneamente he pensado que yo estoy contribuyendo a que haya más cosas complicadas rondando por ahí.

    Por eso, antes de publicar una librería que ocupe un espacio en algún servidor de algún sitio muy lejos, me pregunto, ¿merece la pena publicarla? ¿merece la pena un commit en mi cuenta de GitHub, si va a estar ahí, si no la voy a mantener, si a lo mejor ni la voy a usar? Aquí os dejo un ejemplo de un developer que, por cierto, me parece brillante, cuyos proyectos leo para aprender e inspirarme. ¿Hacía falta un paquete en npm para eso?

    ¿De qué depende?

    Con esta pregunta me refiero de qué depende literalmente, es decir, de sus dependencias. Cuando estás desarrollando una aplicación tocha, (es decir, de dimensiones importantes), piensas si de verdad necesitas utilizar y cargar todas las dependencias de una librería. Es un poco el síndrome Frankenstein, al final, acabas con un monstruo formado por muchas partes distintas. Pero además, imagínate que para ponerle una mano a tu criatura, te imponen que has de importar enlace óptimo con muñeca, destrezas de pianista y uñas limpias. Al final, acabas con un montón de paquetes, unos que se guardan de no sé dónde, y otros que se cargan no sé cómo, según se le haya ocurrido al developer de turno. Y eso que se supone que como programadores, tenemos en cuenta ‘la ortogonalidad, la reversibilidad y el mínimo acoplamiento’.

    ¿Frontend o backend?

    Me ha ocurrido que quería hacer un módulo para el frontend de una aplicación, pero que también tenía unas utilidades que podía aplicar para crear una CLI, y entonces he mezclado peras con manzanas y luego, entre que mi paquete dependía de una librería que luego no necesitaba cargar en el frontend y otros jaleos, he decidido refactorizar. Y he arreglado el entuerto. Cosas que pasan al principio y de las que aprendes, vaya.

    El caso es que hoy en día puedes manejar librerías y dependencias de muchas maneras. Algunas las importarás dos veces (DRY alert), otras se te quedarán desactualizadas y pasarás de ellas… Para esto, puedes valerte de otras librerías para evitar este tipo de problemas. Un proyecto que ha salido recientemente que me gusta mucho es GreenKeeper.

    ¿Tests? (suena un grillo de fondo)

    Escribir tests es hoy en día mi manera más rápida de desarrollar, aunque hace unos meses me diera urticaria pensar en ellos. Para según qué casos, te ahorras hasta hacer un set de ‘examples’, ¡porque ya está en los tests! Es a la carpeta a la que voy de cabeza cuando quiero saber cómo usar una librería.

    ¿Documentación?

    Aquí muchos flaqueamos. Me incluyo. Me cuesta escribir documentación. La hago pensando en entenderla yo, más que en que la entiendan los demás. I’m sorry.

    ¿Changelog?

    Mi talón de Aquiles, las versiones. Pierdo el control sobre el control de versiones. ¿Cuándo tengo que upgradear? Sí, ya sé que:

    • MAJOR version when you make incompatible API changes,
    • MINOR version when you add functionality in a backwards-compatible manner, and
    • PATCH version when you make backwards-compatible bug fixes.

    Pero me sigue resultando difícil. Y más aún cuando me doy cuenta de que acabo de publicar una versión que tiene un error que provoca un facepalm, y tengo que crear una nueva versión para arreglarlo. Y todo esto, tres veces seguidas. Mal Elena. Mal.

    De esto he aprendido que me lo tengo que pensar dos veces antes de actualizar una versión. Y aunque a veces piense: ‘es que estoy empezando el proyecto, no necesito comentar cada versión’, obligarme a hacerlo.

    De hecho, fastidia bastante cuando alguien hace un breaking change y te das cuenta cuando todo se rompe y tardas bastante rato hasta dar con el hilo de GitHub en el que explica lo sucedido.

    Al igual que hay librerías para comprobar si las librerías de tu proyecto están actualizadas, hay librerías que te ayudan a actualizar librerías, y otras que te ayudan a hacer releases (creo que Christopher Nolan podría sacar una peli de esto). Sobre esta última, recomiendo este vídeo de un compañero de clase durante mi Erasmus en Austria.

    Otros posts que hablan sobre el tema:

    Conclusión

    En realidad, npm me gusta, y me gusta mucho. Sólo tengo que ser un poco más ordenada, seguir más las convenciones. Pero eso no quita que, al igual que reciclo en casa y me preocupo por el medio ambiente, pensar que todo lo que está en Internet es también medio ambiente, y que no quiero contribuir a llenarlo de trash.

    Codemotion 2015

    Codemotion 2015

    Este post va a ser breve, porque quiero que la gente lo lea. Simplemente, quiero agradecer y felicitar a la organización del evento #Codemotion_es (o #Codemotion2015), al que he asistido por tercera vez consecutiva, esta vez como ponente.

    Viernes 27

    Mi charla (o talk, en plan poser) fue en el track 6 a primera hora. Abriendo el Codemotion. Es mi primera experiencia como ‘speaker’ (poser++) en un evento grande, y fue muy positiva. Tenía el viento un poco en contra (casi 39 de fiebre 😨, garganta dolorida, charla en inglés porque vino mi compi Lakshay 🇮🇳) pero tuvo buena acogida. Hablé sobre tips básicos de interfaces de usuario, ya que como desarrolladores, seguro que alguna vez nos enfrentamos a la tarea de realizar una UI para una web o app. Las presentación (hecha en una semana, ya que me dio el venazo de querer hacerla interactiva en HTML y JS) está en [GitHub]. (Gracias a amigos, compis y excompis de trabajo por venir 💖😁💖)

    Reacciones a la charla en la web del codemotion:

    “Bien dada e interesante pero a lo mejor no demasiado intermediate, los conceptos eran muy básicos. El título no sé si muy adecuado, me esperaba a lo mejor algo más de historia y de evolución de las UI.”

    “Más básica de lo que esperaba y no muy ajustada al título salvo la primera parte pero bien impartida :)”

    “Muy básica para mi, y reconozco que esperaba otra cosa, pero me gusta que el Codemotion no sea solo de lenguajes de back, sino también de todo lo que hay alrededor del código.”

    “Interesante y completa. Quizá demasiadas sentencias “porque sí” en lugar de explicaciones, aun breves, del porqué. Recomendable.”

    “La charla de básicas de UX de @Elenarcolepsia en el @codemotion_es va a hacer mucho bien al mundo del desarrollo. #Codemotion2015”

    “Muy buen contenido, en la línea de lo que los gurús de mi empresa recomiendan como best practices. Elena sabe bien de lo que habla. Le hubiese dado las 5 estrellas si hubiese hablado menos rápido e interactuado un pelín más :)”

    “genial, aunque me ha tocado verla de pie, ha sido muy interesante y sobre todo dinámica y amena.”

    “Me ha gustado la sesión. Muy interesante cómo se han presentado las buenas prácticas en diseño de interfaces a dia de hoy.”

    Por lo tanto, ya sé cómo quiero hacer la próxima y qué cosas mejorar, que seguro que saldrá mucho mejor :)

    Esa mañana también aprendí cómo darle amor a los tests, muy divertida, y después me estuve paseando por los stands, hablando con mucha gente. (después de tomarme las medicinas para el resfriado y un buen café). Conocí a la gente de Kairos (majísimos) y hablé de Javascript con atSistemas

    Después de comer y hablar con amigos, fui a un workshop de #React y #Webpack a hacer un poco de código, y me moló el tema, a pesar de los impedimentos técnicos (saturamos la sala y se fue la luz, pero todo salió bien).

    Quiero destacar de ese día la increíble e inspiradora charla de Katia Aresti, que se titulaba “He fracasado : Tengo mas de 30 y sigo programando”. Me sentí identificada en muchos aspectos. Relató su experiencia como desarrolladora, también habló de eventos a los que organiza y asiste, del papel del programador, de cómo podemos orientar nuestra carrera profesional a seguir programando si no queremos escoger el camino de ser managers o leads. En esta charla me dije varias veces: “Vaya, eso justo me ha pasado a mí”, y también pensé: “tal vez sí que vaya por el buen camino…” o “no lo estoy haciendo tan mal”. Nos reímos varias veces, pasamos un buen rato.👏👏👏

    Unas empanadas y unas cañas después 🍻 , cogimos el bus back home.

    Sábado 28

    Ya más relax y con menos fiebre, vi de buena mañana un poco de programación funcional con JS.

    Estuve también, cómo no, en la charla de Kiko Beats, que se marcó un beatbox para amenizar los minutos de espera antes de empezar. Muy buenos tips sobre Javascript, pero aquí no puedo ser objetiva así que, NEXT.

    Fui al track en el que David Bonilla de Otogami, Felipe Navío de Jobandtalent y Javi Santana de CartoDB respondieron a una serie de preguntas sobre sus startups. Me gustan mucho este tipo de mesas redondas, porque te permite conocer otras realidades y compararlas con la tuya. Me gustó mucho eso de que Javi Santana dijera que una ‘métrica’ que ellos usan en CartoDB es darse abrazos por las mañanas, porque yo también me los doy con mis compañeros, y creo que el buen rollo dentro de los trabajadores, el darte un abrazo, hace que las ocho horas (mínimo) que pases allí las pases mejor, más en familia.👬 👫 👭

    Por último, hablar de la charla ‘Help, I need more woman!”, en la que habló Laura Morillo, que es además, organizadora entre otras cosas, de las Tech&Ladies, comunidad a la que pertenezco. Ella cuenta más en detalle todo lo que dijeron en la charla en el blog de Microsoft Developer España.

    Según los datos publicados por el ministerio de Educación y Ciencia las ramas de Ingeniería y Arquitectura apenas un 25,9% de los estudiantes fueron mujeres en el curso 2014/2015. Cuando miramos los datos relacionados con la Informática, el porcentaje desciende por debajo del 15%. ¿A qué se debe esa baja participación y qué podemos hacer para intentar mejorar la situación? Es un problema complejo de analizar y son múltiples los factores que influyen: los estereotipos, los prejuicios, la cultura, la falta de referentes…

    En un futuro post que ya estoy preparando, hablaré de por qué pertenezco a esta comunidad y cuál es mi opinión sobre el tema de las mujeres en el ámbito tecnológico (por fin me voy a atrever).

    No me voy a enrollar mucho más porque no me gustan los posts kilométricos, así que, para aquellos que quieran saber más del Codemotion2015, pueden mirar los vídeos en YouTube.

    Muchas gracias one more time a la organización, a los amigos que vinieron y a los amigos que hice. El año que viene MOAR.

    Global Day of Coderetreat 2015

    El pasado sábado 14 de Noviembre asistí al #GDCR2015 en Alicante, organizado por Gemalto. Estuve a punto de ir al de Valencia, donde lo organizaba No Flop Squad , pero ya que éste me pillaba más cerquita… allí que estuve toda la mañana y parte de la tarde programando con otros developers de la zona.

    En resumen, el Global Day of Coderetreat es un evento mundial, organizado en varias ciudades del mundo. El organizador en Alicante fue Raúl Gomis, que se encargó de comunicarse y coordinarse con las otras sedes.

    Durante un día, hay que resolver un ejercicio práctico haciendo especial hincapié en el diseño y el desarrollo de software. Es decir, no se trata de llegar a resolver el ejercicio, sino de cómo resolverlo. Cómo enfocar el problema, cómo empezar a desarrollar.

    “Practicing the basic principles of modular and object-oriented design, developers can improve their ability to write code that minimizes the cost of change over time.”

    Un coordinador, en nuestro caso Jorge Muria, que también organizo el Agile University Day, explica el ejercicio y qué hacer en cada una de las sesiones. El ejercicio consistió programar el Juego de la Vida de Conway. Brevemente (😂), consiste en lo siguiente (sacado de Wikipedia):

    • El “tablero de juego” es una malla formada por cuadrados (“células”) que se extiende por el infinito en todas las direcciones.
    • Cada célula tiene 8 células vecinas, que son las que están próximas a ella, incluidas las diagonales.
    • Las células tienen dos estados: están “vivas” o “muertas” (o “encendidas” y “apagadas”).
    • El estado de la malla evoluciona a lo largo de unidades de tiempo discretas (se podría decir que por turnos).
    • El estado de todas las células se tiene en cuenta para calcular el estado de las mismas al turno siguiente. Todas las células se actualizan simultáneamente.
    • Las transiciones dependen del número de células vecinas vivas:
    • Una célula muerta con exactamente 3 células vecinas vivas “nace” (al turno siguiente estará viva).
    • Una célula viva con 2 ó 3 células vecinas vivas sigue viva, en otro caso muere o permanece muerta (por “soledad” o “superpoblación”).

    Para ello, utilizamos TDD (Test Driven Development) y Pair Programming. Hicimos un total de cinco sesiones. En cada sesión, nos poníamos por parejas y comenzábamos a elaborar y a diseñar una solución al problema. Yo llevé dos entornos de testing preparados, uno en 💕JavaScript💕 y otro en Ruby. Entre los lenguajes que utilizamos, también se encontraban C++, Java y PHP. Bastante variadita la cosa 👌.

    Cada ronda cambiábamos de pareja, y en la última ronda, nos turnábamos para ir escribiendo y resolviendo los tests en un ordenador conectado a un proyector. Después de cada ronda, hacíamos una retrospectiva de qué nos había parecido el ejercicio.

    Lo bueno de este tipo de prácticas, al menos lo que a mí me gusta, es que para mí programar es algo muy íntimo. Me da mucha vergüenza que me vean programar. Al menos, me daba, ya que ahora estoy venciendo ese miedo poco a poco. Además, como ya comenté en mi post Por qué dar una charla, asistir a estos eventos te hace pasar un buen rato con gente que se dedica a lo mismo que tú. Siempre es interesante conocer gente nueva, o estar con los compañeros, hablando del mundo en el que nos movemos. Además, hubo muchos dulces 🍩, café y pizza 🍕.

    Además, en nuestro caso lo hicimos en inglés, ya que tuvimos asistentes internacionales. Creo que es un evento muy interesante también para aquellos que no se atreven a probar TDD, que cada vez me gusta más (pero eso ya, en otro post).

    Dejo aquí algunas fotos del evento 😃

    BumBum CSS Animation

    Hoy no tocaba post, pero me ha parecido buena idea rescatar un antiguo codepen que hice el pasado enero para compensar tanta morralla que inunda mi blog últimamente, como el extenso post sobre la fase de planificación en el diseño centrado en el usuario. Que sí, que la teoría mola, pero también me apetece mostrar un poco de código de vez en cuando.

    Ahora que están tan de moda los corazoncitos (twitter ha cambiado recientemente su fav por like) Voy a simular el bum bum (sí, es la mejor onomatopeya que se me ha ocurrido) de un corazón con CSS. La idea es mostrar:

    1. Cómo definir una transformación.
    2. Cómo definir una animación.
    3. Cómo funcionan los keyframes.
    4. Ejemplo final.

    LET’S DO IT

    Transformaciones

    Para definir una transformación en CSS, basta con lo siguiente:

    .shape {
     transform: scale(2)
    };
    

    Es lo que estás pensando: va a escalar el doble (a hacer el doble más grande) el elemento que tenga esa clase. Easy. Llegados a este punto, tenemos que tener en cuenta que las animaciones en cada navegador son, como el que dice, de su padre y de su madre, por lo que no hay que olvidar incluir los vendor prefixes:

    .shape {
      -webkit-transform: scale(2);
      -moz-transform: scale(2);
      -ms-transform: scale(2);
      -o-transform: scale(2);
      transform: scale(2);
    };
    

    En css3 hay nuevas propiedades que están todavía en estado experimental. Los navegadores tienen varias maneras de interpretar el css, y varios niveles de soporte para los estandartes W3C

    Más sobre vendor prefixes

    Animaciones

    Viene la parte que más me gusta. Ojo, que aquí también hay que tener en cuenta los vendor prefixes. La sintaxis de la animación es la siguiente:

    • Variables
    .shape {
     animation-name: *keyframename*|none|initial|inherit;
     animation-duration: *time*|initial|inherit;
     animation-timing-function: linear|ease|ease-in|ease-out|cubic-bezier(n,n,n,n)|initial|inherit;
     animation-delay: *time*|initial|inherit;
     animation-direction: normal|reverse|alternate|alternate-reverse|initial|inherit;
     animation-iteration-count: *number*|infinite|initial|inherit;
     animation-fill-mode: none|forwards|backwards|both|initial|inherit;
     animation-play-state: paused|running|initial|inherit;
    }
    

    Dichas variables se pueden poner en la misma línea, siguiendo el orden anterior, o de manera individual.

    .shape {
      animation: 'animation-name' || 
                 'animation-duration' || 
                 'animation-timing-function' || 
                 'animation-delay' ||
                 'animation-iteration-count' || 
                 'animation-direction' || 
                 'animation-fill-mode'
    };
    

    Para nuestro bombeante corazón que utilizaré como ejemplo, queremos que haga lo siguiente:

    • Que lata a cada segundo
    • Que el tipo de animación sea (timing-function) linear
    • Que esté bombeando de manera infinita (qué bonito)
    .shape {
      -webkit-animation: beat 1s linear infinite;
      -moz-animation: beat 1s linear infinite;
      -ms-animation: beat 1s linear infinite;
      -o-animation: beat 1s linear infinite;
      animation: beat 1s linear infinite;
    };
    
    • ‘beat’ es el nombre de nuestra animación. Aquí es donde vienen nuestros amigos los keyframes.

    Básicamente, un keyframe es un punto en la línea temporal de una animación en la que el objeto animado cambia de estado. En CSS, sigue el siguiente esquema:

    @keyframes nombre-animación {
      porcentaje {
        transform: transformación(valor);
      }
    };
    

    Por ejemplo, imaginemos que tenemos una animación de cuatro segundos. En el keyframe identificado en el 25%, provocará que se produzca una transformación en el primer segundo. 50% en el segundo segundo (valga la redundancia), 75% en el tercer segundo y 100% en el cuarto segundo.

    Para hacer el bum bum del corazón, digamos que hará falta algo así:

    • Corazón está en tamaño normal
    • Corazón crece muy rápido
    • Corazón vuelve a tamaño normal muy rápido
    • Corazón vuelve a crecer muy rápido
    • Corazón vuelve poco a poco a tamaño normal y se queda así un rato

    Para conseguir lo anterior, he establecido los siguientes porcentajes:

    • Corazón está en tamaño normal (-)
    • Corazón crece (10%)
    • Corazón vuelve a tamaño normal (20%)
    • Corazón crece (30%)
    • Corazón vuelve a tamaño normal poco a poco (-)

    Como vemos, el bum bum ocurrirá de manera muy rápida entre el 10% y el 30% del segundo en el que ocurrirá la animación.

    @keyframes beat {
      10% {
        transform: scale(1.2);
      }
    
      20% {
        transform: scale(1);
      }
    
      30% {
        transform: scale(1.2);
      }
    }
    

    En mi caso, he puesto una escala de 1.2 porque no me gustaba que quedara demasiado exagerado. Evidentemente, hay que incluir también los vendor prefixes en los keyframes. Éste es el resultado del corazón bombeante:

    See the Pen qOKzqL by Elena Torró (@elenatorro) on CodePen.

    En este ejemplo, los corazones (el interior y el exterior) están creados con CSS (no son iconos o imágenes), pero puedes aplicarlos al elemento que quieras.

    Para no tener que escribir tantas veces los vendor prefixes, existen varios mixins (funciones) en preprocesadores CSS que te harán esta tarea mucho más sencilla, y que recomiendo utilizar para evitar duplicar tanto codigo o que se te escape algún vendor sin querer.

    Espero que te haya gustado este post y que vayas poniendo muchos corazoncitos por ahí.

    Más info en:

    Por qué dar una charla

    El pasado viernes 16 de Octubre me encontraba sentada en el sofá. Estaba nerviosa. Había sido un buen día en el trabajo, el fin de semana ya había empezado oficialmente y, sin embargo, esa tarde iba a ser difícil. Al día siguiente sería ponente en un evento sobre metodologías ágiles. Y no dejaba de pensar: ¿por qué estoy haciendo esto?

    Era viernes. Podía hacer la maleta, ir a visitar a mis padres, salir con mis amigas esa noche. O simplemente descansar, leer durante horas, dar un paseo, cenar por ahí. Pero no, ahí estaba, frente a las diapositivas que terminé hacía una semana y que no me acababan de convencer. Mi ponencia trataba de la relación de metodologías ágiles con metodologías UX. Ya hablé sobre ella en este post, y en él se me notaba bastante emocionada, ¿verdad?. Pues más bien, estaba cagada.

    No es la primera charla que doy, ni siquiera la primera en la que hablo sobre la experiencia de usuario. Debería sentirme cómoda, sé de lo que voy a hablar, ya lo he hecho antes. Pero iba a asistir gente de mi trabajo, gente de la universidad, gente que me lleva años de experiencia de ventaja y frente a los cuáles tengo la sensación de que en realidad no tengo ni idea de nada. Gente de mi entorno me ha dicho muchas veces: ‘Báh, si a ti te gusta dar charlas”. Como si sólo por eso fuera fácil. Y pienso, ¿de verdad me gusta dar charlas?

    Practico la charla una vez más. Se me queda un poco larga, más de 45 minutos, tengo que acortar. Me he trabado en un par de diapositivas, esto va a salir mal. Repaso un poco más el guión y el storyboard, me hago la cena y me pongo YouTube.

    Por casualidad, acabé en una charla megainteresante que daba una chica acerca de robots programados con NodeJS, una chica divertida, dando una charla amena, de manera natural. Me gusta. Copio un par de ideas suyas y las adapto a mi charla, a última hora. ‘Bueno’, pienso, ‘Aunque me salga mal, que no sea porque no estoy siendo natural o porque no me gusta de lo que estoy hablando’.

    Al día siguiente, me levanto una hora antes de lo previsto para ensayar una vez más. Un poco mejor que ayer, pero nada del otro mundo. Preparo cámaras de fotos, intento peinarme, recojo la casa y pongo rumbo al evento.

    Era la segunda ponente, justo antes del break de café y networking. Había gente que conocía, amigos que sabía que vendrían, amigos que no esperaba ver y me alegró verlos, gente del trabajo, conocidos de la universidad, y por supuesto, gente que no había visto en mi vida. Mi charla duró alrededor de unos 35 minutos al final (escribí un post con la crónica del evento. Me lo pasé bien. Sé que me equivoqué un par de veces. Sé que me olvidé de decir algunas cosas. Sé que improvisé cuando me quedé en blanco, y esperé que no se notara demasiado.

    Entonces ya podía responder a la pregunta que me formulaba el día anterior. ¿Por qué estoy haciendo esto? ¿Por qué dar una charla?

    1. Preparar una charla te obliga a profundizar y aprender en un tema.

    Me he quejado en muchas ocasiones de que había cierto tema en alguna asignatura de la universidad que no me gustaba en absoluto, pero que tenía que estudiarme por obligación. Aprender por tu cuenta es algo bastante difícil y que siempre he admirado mucho, porque hace falta mucha motivación. Al prepararte una charla, no te queda otra que estudiar, leer, leer, y releer, hacer esquemas, aprender. Y sobre un tema que has elegido. Puedes conducir el tema por donde más te interese. Es, en realidad, una gran oportunidad.

    2. Tienes la oportunidad de expresar tu opinión sobre un tema o una causa que te importa.

    Hay quien piensa que dar una charla es puro postureo. Que lo que quieres en realidad es demostrar lo mucho que sabes sobre un tema, parecer importante. Y nada más lejos de la realidad. Dar una charla es una oportunidad para opinar y difundir. No se da una charla de cualquier tema al azar.

    3. Mejoras tu oratoria, así como tus habilidades de comunicación.

    Enfrentarte a hablar delante de otras personas hace que salgas de tu zona de confort. Cuando era pequeña, mucha gente se metía conmigo o resaltaba que hablaba muy rápido y que no se me entendía. Gracias a practicar delante del espejo para exposiciones y charlas, he conseguido hablar más despacio y sobretodo, vocalizar, como se puede escuchar en este vídeo (un poco antiguo lo de CSS, sí, pero no pasa nada).

    4. Conoces a gente.

    Durante el networking, en las pausas entre charla y charla, en la salida del evento… Acabas compartiendo opiniones e ideas. Comentas experiencias personales, conoces historias de personas que se dedican a lo mismo que tú o que están interesadas en los mismos campos que tú. Esto hace que te sientas motivado a seguir trabajando, estudiando o dedicándote a aquello que te gusta. Es más, si estás buscando trabajo, es una buena forma de darte a conocer, de mostrar tus habilidades. En muchas ocasiones, no todo es tirar de currículum, sino que vean cómo te expresas, que eres una persona a la que le gusta aprender y compartir.

    Dar una charla es díficil. Quita tiempo. Puede producir estrés. Pero es una buena experiencia.

    Code Highlight en Ghost

    border-top-style: sleepy;
    

    POST EXPRESS

    ¿Quieres que tus posts con bloques de código queden mucho más bonicos?

    Lo primero, es bajarse alguna librería de por ahí (no soy vaga, soy práctica) que edite el estilo del código. Yo he pillado Prism,que la ha hecho Lea Verou y para mi gusto tiene todo lo que necesito: una librería simple, fácil de usar y fácil de instalar. Puedes descargártela, consultarla en github o instalarla con bower:

    $ bower install prism
    

    El siguiente paso es incluir en tu blog el script (prism.js), el estilo principal (prism.css) y el tema que más te mole (yo lo he dejado tal cual, fíjate si soy express).

    Después, cada vez que vayas a meter un bloque de código, en lugar de hacerlo con la sintaxis de markdown (poniendo estas tres comas ``` al principio y al final del bloque), usaremos HTML a pelo.

    <pre class="language-css"><code>
    .myClass {
      border-top-style: sleepy;
    }
    </code></pre>
    

    Y voilá. Pero hay un pequeño problema. Y es que claro, por defecto, si quieres incluir código HTML, no puedes hacerlo así porque markdown lo renderiza. Por lo tanto, cuando quieras escribir con un lenguaje de marcado, he hecho lo que se conoce como un workaround (también llamado popularmente ñapa), que ha sido la mejor solución que se me ha ocurrido. Y es incluir la siguiente función en javascript:

    var item;
    var element;
      for (item in document.getElementsByTagName('code')) {
       element = document.getElementsByTagName('code')[item];
       if (!element.className) {
        element.className = 'language-html';
       }
      };
    };
    

    En resumen, coge todos los bloques de código que tengas en el post y, si no les has asignado una clase del tipo language-loquesea, te añade por defecto HTML.

    ¿Tienes una solución mejor? ¡Cuéntamela!

    Imagen de portada: Inside Out

    Agile&UX - Planificación

    Metodologías UX

    Ya hemos hablado de qué es “UX”, o al menos hemos definido una aproximación al término. Ahora, es el momento de conocer las metodologías UX. Hay una gran cantidad de métodos y técnicas de diseño de experiencia de usuario. Dependiendo del propósito de las mismas, se clasifican en una capa distinta del proceso de desarrollo. Pero todas estas fases tienen algo en común: estudio, investigación y pruebas. Invertir una importante cantidad de tiempo en conocer bien a tu usuario objetivo (el tipo de usuario que usará el producto) se considera prioritario. Es la esencia del diseño UX. En esta sección, se diferenciarán las distintas fases del proceso de desarrollo, los roles que puede asumir un diseñador UX, y qué metodologías se pueden llevar a caba en dichas fases y cómo están relacionadas con los distintos roles. Además, se incluye una introducción al Diseño Centrado en el Usuario, conocido como UCD (User Centered Design).

    En este apartado, hablaremos de distintas metodologías clasificadas en cuatro fases del UCD: Planificación, Análisis, Diseño y Pruebas.

    Planificación

    Esta es, sin duda alguna, una fase común en cualquier proceso de desarrollo. Tanto de desarrollo tecnológico, como también para cualquier otro ámbito, como por ejemplo, escribir un libro o rodar una película. Un director de cine raramente se lanza con su equipo a rodar la primera escena sin tener preparado un guión, unos actores que se han preparado su papel, un equipo de producción, un escenario… La planificación es la base de todo, en la cual el principal objetivo no es sólo planificar, sino también identificar. En el caso del diseño UX, se hace un especial hincapié al usuario objetivo y a la relación de éste con el producto.

    ¿Qué identificar?

    • El producto que se va a desarrollar.
    • Características.
    • Envergadura.
    • Tipo de producto.
    • Estimaciones de tiempo (desarrollar primera versión, tiempo dedicado a la investigación…)
    • El usuario objetivo
    • Cuál es la audiencia de nuestro producto.
    • Qué necesidades queremos cubrir.
    • Cómo se cubrirán dichas necesidades.
    • Objetivos alcanzables: Los objetivos que esperamos que el usuario sea capaz de cumplir. Qué conseguirá el usuario al utilizar el producto. Estos objetivos incluyen usabilidad y satisfacción.

    Es muy importante ser específico a la hora de identificar el usuario objetivo. Conocer bien un tipo concreto de usuario hará que el producto a desarrollar cubra con las necesidades de ese tipo. Cuanto más amplia y ambigua sea la definición del usuario objetivo, más necesidades existirán y más difíciles serán de cumplir. Con toda esta información, se puede comenzar a elaborar el documento de requerimientos del producto.

    Métodos para la fase de planificación

    • Blueprint, también conocida como “Ruta de Experiencia” o “Mapa de Uso” El objetivo de este método es describir cómo funciona un producto en un determinado contexto. Se trata de un gráfico que muestra el funcionamiento que no está a la vista del usuario. El tipo de gráfico dependerá del equipo encargado de la planificación, es abierto, puede ser por ejemplo un esquema de árbol o una tabla. Este método facilita la comunicación y la contextualización del producto a todos los equipos (tanto de diseño como de desarrollo).

    • Personas: Las “Personas” son una representación realista del usuario final. Para elaborar las personas, debemos tener claro cuál es el usuario objetivo, ya que la representación de la misma tendrá estas características y gracias a eso podremos conocerlo en mayor profundidad. Gracias a las Personas, es posible focalizar a la hora de crear historias de usuario, requisitos, tareas u objetivos. Uno de sus grandes beneficios es que, una vez todo el equipo (desarrolladores/programadores inclusive) conocen estas representaciones, dirigen su trabajo siendo más conscientes de quién va a utilizar lo que ellos están construyendo con sus manos.

    • Historias de Usuario: ¡Vaya! Aquí nos encontramos con un término común en las metodologías ágiles ;). De hecho, es lo mismo. Se trata de una frase simple, común, escrita en lenguaje formal, que representa un requisito software. Por ejemplo, en la metodología Extreme Programming (XP) han de ser escritas por los clientes. Y esto es perfectamente aplicable a esta fase de diseño UX.

    En un diseño UX, un workflow adecuado sería: Primero, evaluar las Personas, después, identificar los objetivos y a partir de ellos elaborar las historias de usuario.

    • Entrevistas: Las entrevistas son un clásico, y parecen a priori un método obvio, sencillo y posible de realizar sin invertir demasiados recursos. Sin embargo, las entrevistas son un arma de doble filo, ya que sus resultados pueden resultar manipulados si las mismas no se efectúan de la manera correcta. En primer lugar, hay distintos tipos de entrevista, y al igual que en el caso de los formularios que veremos después, pueden ser cualitativas (datos obtenidos mediante la observación) o cuantitativas (datos obtenidos utilizando distintas métricas).

    • Entrevistas contextuales:
    • Qué son: Entrevistas informales en las que el entrevistador observa y escucha al usuario.
    • Cuándo: El usuario se encuentra en su entorno normal de trabajo, no en una sala específica acondicionada o un laboratorio. Son entrevistas flexibles y naturales, en las que no se lleva a cabo una lista de tareas.
    • Objetivo: Realizar la entrevista mientras el usuario utiliza el producto. Los resultados serán cualitativos. Al observar al usuario en su entorno, se observa qué utiliza y qué acciones desempeña para usar el producto habitualmente, el tiempo que emplea en realizar las tareas que él mismo se propone, y da una visión general del uso del producto.

    • Entrevistas individuales
    • Qué son: Entrevistas a una persona de manera individual, como su propio nombre indica.
    • Cuándo: Cuando estás definiendo los objetivos de tu producto, y antes de enviar formularios. Hacer una entrevista antes que una encuesta ayuda a definir mejor las preguntas que vas a incluir en el formulario.
    • Objetivo: Saber qué es lo que espera (qué espera conseguir, qué tareas desea cumplir…) para entender mejor el tipo de usuarios que usan actualmente o usarán tu producto. Es importante tomar notas o grabar la entrevista, para poder utilizar los resultados de la misma.

    • Focus Group
    • Qué son: Básicamente, un conjunto de participantes (hasta 10 personas) que discuten entre ellos. Ofrece la oportunidad de observar la conversación entre los participantes, sin influir en ella, y ver cuáles son sus puntos de vista.
    • Cuándo: Antes de definir nuevos objetivos, pero después de haber definido el usuario objetivo del producto.
    • Objetivo: Lo principal es obtener feedback de un grupo de usuarios que cumplan el perfil de tu usuario objetivo. El problema es que los resultados de este método pueden ser poco precisos, y no es uno de los mejores métodos ya que es difícil interpretar los resultados del mismo. Hay que decidir sobre qué temas se hablará en la sesión, elegir a un moderador, procurar que no se desvíe la discusión. Duran al menos dos horas, por lo que pueden ser muy ineficientes.

    Estos métodos han de realizarse sin influenciar la respuesta del entrevistado o entrevistados. Para ello, hay que prestar atención en las preguntas formuladas, en el ambiente en el que se efectúan las entrevistas (una sala, una habitación con más gente, una llamada telefónica, una videollamada).

    También hay que tener en cuenta el estado del proyecto: no es lo mismo entrevistar sobre el uso de un producto que aún no ha sido lanzado que sobre otro que lleva varios años en funcionamiento.

    Siguiente Post: Análisis

    Bibliografía

    • http://www.usability.gov/how-to-and-tools/methods/index.html?view=list
    • http://uxdesign.cc/ux-methods-deliverables/
    • Bank, Chris - Cao, Jerry, The Guide to UX Design Process & Documentation, UXPin, 2014

    Imagen de portada: I need sleep

    Agile&UX - Introducción a la UX

    Primer post sobre la serie Agile&UX. # Experiencia de Usuario

    Según la definición dada por Nielsen Norman Group, el término “User Experience”, o experiencia de usuario, engloba todos los aspectos de la interacción del usuario final con la compañía, con sus servicios y con sus productos. El primer requerimiento para una experiencia de usuario ejemplar es encontrar las necesidades exactas del consumidor, sin quejas ni molestias. El siguiente requerimiento es la simplicidad y la elegancia de producir un producto que sea cómodo de tener y cómodo de utilizar. La verdadera UX va más allá de dar a los consumidores lo que ellos dicen que quieren, o de proveer una lista de características. Para conseguir una UX de alta calidad dentro de las ofertas de una compañía, tiene que haber una mezcla perfecta entre múltiples disciplinas, incluyendo ingeniería, marketing, diseño gráfico e industrial, y diseño de interfaces.

    Definir el término “UX” no es nada sencillo. No existe una definición concreta, ya que en realidad, es muchas cosas al mismo tiempo, y por lo general, esas cosas tienden a confundirse con facilidad. No se trata de una metodología en concreto, de una forma de diseñar específica o de una filosofía de desarrollo. La “UX” es un conjunto de elementos con un objetivo común: el usuario final. La gente, las personas que van a usar un producto que hemos creado con nuestras propias manos. Una buena experiencia de usuario significa que cuando uso un producto, me siento satisfecho de saber qué tareas tengo que realizar para cumplir aquello que quería o necesitaba. Es el efecto que provocan las interacciones y percepciones que tengo cuando uso un producto. Y sí, hablo de productos en general y no, por ejemplo, de aplicaciones en concreto, ya que al fin y al cabo, la experiencia de usuario se genera cuando yo, como usuario, uso cualquier cosa y ese uso deriva en una reacción.

    En su libro “UX Design para Startups” [1], Marcin Treder introduce el término de la siguiente forma: “El diseño de experiencia de usuario (UXD, User Experience Design) es una disciplina enfocada en el diseño de principio a fin de la experiencia de un determinado producto. Diseñar una experiencia significa planificar y actuar en base a un grupo de acciones, las cuales deberían de resultar en un cambio planificado de comportamiento en un grupo objetivo (cuando interactúan con un producto).”

    La reacción ante el uso de un producto suele ser expresada como “me gusta”, “es frustrante” o “ha sido fácil”, por ejemplo. El diseño de la experiencia de usuario estudia esa reacción: cómo y por qué se produce, cómo provocarla o evitarla. El mejor carpintero del mundo podría construir la silla más bonita, barata y cómoda del mercado, y que dicha silla fuera un completo fracaso ya que no cumple con lo que el usuario esperaba. ¿Por qué el respaldo es tan alto? ¿Por qué no puedo plegarla para llevármela de viaje? ¿Por qué la voy a comprar si raya el suelo del salón? ¿No hay en más colores? ¿No hay una mesa a juego? Diseñar una experiencia es estudiar un comportamiento concreto relacionado con el uso de un producto, y encontrar las posibles soluciones a los problemas que plantea dicho uso. Nunca se puede dar por sentado una suposición sin haberla probado primero.

    En “Diseñando para las personas”, Henry Dreyfuss afirma que: “Cuando el punto de contacto entre el producto y las personas se convierte en un punto de fricción, entonces el diseñador ha fallado. Por otro lado, si las personas se sienten más seguras, más confortables, con más ganas de comprar, más eficientes o simplemente más felices ante el contacto con el producto, entonces el diseñador ha tenido éxito.” [2]

    Una vez se ha introducido el término, ¿qué hace entonces un “profesional” UX? ¿A qué se dedica? Para contestar a esas preguntas, habría que saber qué tipo de profesional es, qué área cubre, cuál es su especialidad… Como práctica profesional, engloba una serie de disciplinas distintas. Habrá profesionales que se dediquen a la “user research”, para conocer al usuario, otros cuyo área sea la arquitectura de la información, el diseño de interfaces, la usabilidad o la evaluación del producto. Dichos profesionales pueden ser ingenieros, psicólogos, sociólogos, diseñadores… Y en base a su background y a su especialidad, asumir un rol u otro. Todo esto lo veremos en los próximos apartados con mayor detenimiento.

    Desde un punto de vista personal, la experiencia de usuario es lo que humaniza el proceso del desarrollo de un producto. Motiva a un desarrollador a realizar un buen trabajo. Enfocar tu esfuerzo a la idea de que lo que estás haciendo afectará positivamente a una persona hace que te sientas realizado, hace que pienses que no estás simplemente uniendo piezas en vano.

    Bibliografía

    • [1] Treder, Marcin. User Experience Para Startups, UXPin, 2013

    • [2] Buley, Leah.The User Experience Team of One: A Research and Design Survival Guide, New York: Rosenfeld, 2013

    ¿Qué es Agile&UX?

    El propósito de este breve manual es el de mostrar características comunes a metodologías ágiles y metodologías centradas en la experiencia de usuario. Este tema no es algo nuevo, a pesar de que en los últimos años se ha empezado a dar una especial importancia a la “User Experience” (UX). A pesar de que la UX se relacione más con el diseño, tiene un importante componente de desarrollo, por lo que dentro de una empresa cuyo objetivo sea realizar un producto pensando en sus usuarios, la combinación de estos dos tipos de metodologías se convierte en una tarea importante. Estos tipos parten de perspectivas distintas, por lo que no siempre es fácil encontrar esa armonía. ¿Cómo conseguir que en un equipo se coordine la fase de planificación tanto a nivel de diseño como de desarrollo? ¿Es posible desarrollar una aplicación a partir de casos de uso encontrados en test de evaluación de usuarios?

    Imagen de portada: Mac 2

    Crónica Agile Alicante

    Estado actual:

    border-top-style: outset;
    

    El pasado sábado 17 de Octubre asistí al evento de Agile Alicante. Es parte del Agile University Day, organizado por Agile Spain. Me gustaría contar brevemente cómo fue el evento, visto desde mis ojos. Grabé algunas tomas y haré un pequeño vídeo, pero mientras saco tiempo de debajo de las piedras, tendré que conformarme con este post.

    Viernes 16, 22:30hs

    Yo, salón de mi casa

    - ¿Por qué envié una charla? ¿En qué estaba pensando? Venga, practico una vez más, veo un par de vídeos en YouTube y a la cama

    07:30

    Yo, antes de salir de casa

    - ¿Dónde está el adaptador VGA del portátil?

    09:03

    Aulario 1, Universidad de Alicante

    Encontré el aula del evento. Ya había gente en la puerta, entre ellos algunos amigos. Me sorprendió y me alegró ver a Jordi, un amigo del curso de Ironhack de hace dos veranos. También vino Israel, un chico que conocí en otro evento en Murcia. Empieza bien la cosa. Vamos entrando y colocando las cosas.

    9:18

    Voy al cuarto de baño a cambiarme la camiseta por la camiseta del evento y a relajarme un poquillo. Era el baño de chicos, porque el de chicas me pillaba un poco lejos, pero era sábado y no había nadie. Lo más embarazoso hubiera sido que alguien me encontrara mirándome al espejo intentando (des)peinarme.

    9:30

    ¡Empieza el evento! Jorge Muria, el organizador, hace las presentaciones que toca, habla de Agile Spain y lo típico que se hace al presentar un evento, you know.

    10:00

    Migración al agilismo con equipos remotos – Nieves García

    En esta charla, Nieves nos contó cómo migrar a metodologías Ágiles cuando tu equipo crece y ya no está juntito bajo el mismo techo día a día. Algo más complicado de lo que parece, a pesar de la cantidad de medios de los que disponemos hoy en día (herramientas software, sistemas de comunicación online…).

    • Hay distintos equipos que llevan usando distintas metodologías, por lo que no se trata sólo de migrar, sino de readaptar las metodologías de cada equipo.
    • La combinación de equipos remotos tienen la ventaja de que cubren un rango más amplio y por lo tanto llegan más lejos.
    • Pero también tiene problemas debido a:
    • Distintas zonas horarias (sí, no puedo despertar a mi compañero chino que está plácidamente durmiendo en su cama a las 2am de la mañana con una llamadita de skype)
    • Distintas culturas.
    • Distintos idiomas, porque como dijo Nieves, aunque todos los equipos asuman un lenguaje en común, siempre habrá quién sepa más y quién sepa menos, y los problemas de comunicación son inevitables.
    • El trabajo en equipo no es el mismo cuando no compartes horas físicas y tiempo (por ejemplo, el ratico de irte a tomar el café).
    • Por estas cosas, es importante una buena organización, ser conscientes de qué hora es en cada oficina y también, viajar a otras oficinas para conocer en persona a los miembros de tu equipo (team building stuff)

    • Si alguien la lía parda, no hay que poner excusas rollo “Ah, yo no fui, porque en ese momento no me llegó ninguna notificación” o “Ésa no era una responsabilidad de mi equipo” y similares. No es el individuo o una oficina local quien la lía, es todo el equipo. Esta parte me gusta mucho no sólo para equipos remotos, sino para equipos en general.

    Y hablando también de para equipos en general, destaco estos tips que dio casi al final de la charla que me parecieron mega bonitos y motivantes y que creo que es un must del trabajo en equipo:

    • Dar las GRACIAS.
    • Recompensar el trabajo bien hecho.
    • Be open.
    • Ser respetuoso.
    • Una de mis favoritas, CHATEAR. Agiliza la comunicación, y también la relación entre miembros del equipo. Para mí, un Slack, un HipChat o similar, siempre me ha molado mucho. Y ya si le pones un bot, te puede sacar más de una sonrisa a lo largo del día (guiño, guiño).

    Además, esta charla me sirvió para saber más en profunidad cómo funcionan los equipos de la empresa en la que trabajo, Gemalto.

    10:50

    UX & Agile – Elena Torró

    Sí, mi turno. Empecé un poquillo más tarde por conectar la pantalla y esas cosicas.

    En resumen, hablé de cómo combinar metodologías Agile con metodologías UX. De la importancia de desarrollar pensando en tu usuario objetivo, pero sin dejar de lado un workflow agile.

    Como dije al final de la charla, iré subiendo posts a este blog desarrollando lo que expuse, de manera más ordenada (al principio iba a ser un manual pero necesito material para este blog, y creo que éste es un buen medio para hablar sobre el tema).

    Mientras tanto, podéis ver las slides en SlideShare.

    A pesar de estar nerviosilla, como es típico, creo que la cosa fue bastante bien, la gente participó y me dio mucho feedback.

    11:26

    Coffee Break & Networking

    En realidad lo del coffee fue un poco imposible porque hablé con muchísima gente y no tuve casi tiempo de darle un trago al vaso. Pero me lo pasé genial. Tuve una interesante conversación con una chica llamada Silvia sobre cómo poder adaptar tu equipo para que se diseñe primero, para que se piense cómo va a ser el resultado del producto final antes de lanzarse a codear y maquetar interfaces. Y lo frustrante que es para un frontender tener que escribir código mientras, al mismo tiempo, te inventas cómo va a ser mostrado cuando no tienes ni referencias ni guías de qué es lo que tienes que mostrar. “Pero… y este widget, lo meto aquí, ¿tal cual?”.

    También me sugirió mi compañero Arturo que leyera “El dilema del innovador”, todo a raíz de la pregunta que me lanzó: “¿Y por qué tenemos que estar adaptando la tecnología a los usuarios, por qué no enseñar a los usuarios?”. Creo que este tema lo voy a dejar ahí, porque creo que da para post ;)

    Un café, dos mini magdalenas y una visita al cuarto de baño más tarde, seguimos con las charlas.

    12:01

    Todos pa dentro. Le toca a Jorge Muria, el organizador del evento, hablar sobre la compleja tarea de estimar. Cuáles son los highlights que destaco de esa charla:

    “Mentir con mala intención es timar, mentir con buena intención es estimar

    Sí, un golpe de realidad. Por eso lo he puesto en plan quote. Sigamos.

    • El producto no mejora al estimar. El cliente no va a pagar más por estimar más o menos.
    • Los tipos de estimación que puedes elegir:
    • Estimación tracional
    • Por puntos
    • No estimar (what? Pues sí, es una opción)

    Casi al final de la charla, se generó un debate que me pareció súper interesante. Y, cómo no, lo comenzó mi amigo Pablo, que lo raro es que se esté callado. Pero lo clavó el tío. El debate giró en torno a: Cuando se estima una tarea, ¿hay que tener en cuenta quién va a realizar la tarea a la hora de estimar? Porque al fin y al cabo, de manera inevitable, las tareas las realizamos personas. Y como tales, a unas se nos da bien hacer unas cosas, y a otros otras. Porque si un miembro del equipo se va de vacaciones, o se pone malo, pues su tarea le toca a otro y tal vez no tiene tanta experienca como su compañero en el tema. ¿Y esto, ha de tenerse en cuenta en la estimación? En un mundo ideal en el que todos los miembros del equipo supieran lo mismo y tuvieran las mismas habilidades… pero eso no suele ser así. Hubo opiniones para todos los gustos, me encantó ese momento, fue muy interesante.

    12:52

    ¡Aprendiendo conceptos Agile jugando!, por Juan Quijano

    Esta hora es un poco orientativa, digamos que el debate fue tan interesante que se alargó un pelin.

    Para terminar la mañana, nos vino genial un poquito de actividad y movimiento. Realizamos varios juegos para entender los conceptos básicos de las metodologías ágiles.

    Uno de los ejercicios consistía en formar un círculo, escoger a otras dos personas del círculo, y formar un triángulo con ellos. Claro, cada uno había escogido a otras dos personas random. Después, formar un triángulo perfecto. Y después, hacer ese triángulo tan pequeño como fuera posible. Al final, acabamos todos riéndonos, formando un tumulto en el centro del Aulario 1. Conclusión: divirtiéndose se está más motivado, y que trabajando en pequeñas tareas se consigue alcanzar una tarea más compleja.

    Otro de los ejercicios consistía en construir un avión de papel siguiendo una serie de requerimientos, que fueron cambiando mientras intentábamos hacer papiroflexia. Y no, no es fácil que tu avioncito no acabe en punta, o que de pronto esté diseñado para llevar a un pasajero sin que éste sufra ningún accidente durante el vuelo. El avión que volara más lejos ganaba (el que ganó terminaba en punta, pero no hay rencor).

    Mi favorito fue cuando me sacaron fuera de la sala, formaron equipos, y procuraron escribir en un tiempo récord las características de un cuadro que yo desconocía y que tenía que dibujar posteriormente en la pizarra. El cuadro resultó ser el Guernica, de Pablo Picasso. En el ejercicio quedó claro lo difícil que es identificar los elementos principales de un elemento, en este caso de un cuadro. Y lo fácil que es malinterpretarlos, por lo que es muy importante utilizar descripciones muy específicas. Eso sí, nos echamos unas risas. La verdad es que Juan Quijano, el ponente, consiguió que todos nos animáramos y que cerráramos el evento muy motivados.

    14:00

    Retrospectiva

    Al final, en grupos de nuevo, discutimos qué fue lo que mejoraríamos del evento, y cómo lo mejoraríamos.

    Así que para terminar, un poco de reflexión. Todos los grupos pensamos de forma unánime que al evento deberían haber asistido más estudiantes. Probablemente no lo habían hecho tal vez porque era sábado, o porque la asistencia a las charlas no daba ningún crédito de libre configuración. En cualquier caso, no entiendo por qué los estudiantes no acuden más a este tipo de eventos.

    Para empezar, vas a conocer gente. Gente que se dedica a algo a lo que tú te vas a dedicar, o al menos en un ambiente parecido. Te pueden dar consejos, contar experiencias. Puedes hacer contactos, y quién sabe, conocer a la empresa en la que vas a encontrar tu primer trabajo. ¿Tal vez hace falta difusión? Envié un correo a un profesor y publicó el anuncio en la web de la Escuela Politécnica. Los organizadores difundieron el evento en las redes sociales. Yo envié whatsapps a grupos de amigos de la carrera. Está claro que se nos escapa algo para llegar a los estudiantes. ¿Alguna idea?

    Muchas gracias a los organizadores, a los ponentes, a Gemalto que patrocinó el evento, a Agile Spain por el riquísimo coffe break y por supuesto, a todos los que vinieron.

    Divinitis

    Estado actual:

    border-top-style: inset;
    

    Consulta del Dr. Spider

    • ¡Doctor, doctor! ¡Ha llegado otro más!
    • ¿Otro más? ¿Otro con divinitis?
    • Creemos que es una epidemia. Todos presentan los mismos síntomas: ganas de hacer las cosas rápido, desconocimiento de estándares…
    • Hágalo pasar.

    La paciente entra en la consulta. Parece asustada, no sabe muy bién qué está sucediendo. Todo se ve bien, ¿no? ¿Dónde está es el problema?. El Doctor le ofrece sentarse en la camilla.

    • Abra su código.

    El Doctor se coloca el markupendoscopio que lleva colgado al cuello, y escucha atentamente. Lo que imaginaba, divinitis aguda. Nada que no hubiera visto antes.

    • ¿Es grave? -pregunta ella, con cara de preocupación-.
    • No se preocupe -responde el Doctor, poniendo una mano sobre su hombro para tranquilizarla-. Ha estado ingiriendo Bootstrap, ¿verdad?
    • Así es
    • De acuerdo. Siéntese, y le hago una receta. Tómese 600gr de Heichtimiel Cinco después de cada comida, hasta que los síntomas desaparezcan. Si alguna vez siente que va a sufrir una recaída, disuelva en un vaso con agua un sobre de W3Consortium hasta que los síntomas remitan. ¿Alguna pregunta?
    • ¿Puedo seguir usando Bootstrap?

    El Doctor suelta una estridente carcajada. - ¡Pues claro, mujer! Sólo tiene que usarlo con conocimiento, como cualquier otro framework.


    La divinitis es el uso indiscriminado de la etiqueta div en los documentos HTML5. No todo es un div. Las equiquetas HTML tienen un significado, representan un elemento dentro de una página. Usar HTML5 hace que un documento sea más legible, que de un vistazo se vea cuál es la estructura de la página, cómo están distribuídos sus elementos.

    The div element has no special meaning at all. It represents its children. It can be used with the class, lang, and title attributes to mark up semantics common to a group of consecutive elements.W3C Specification

    En esta página, puedes ver la lista de elementos HTML5.

    El objetivo es marcar el texto para que sea más semántico, y exprese mejor la estructura de los elementos que está representando. html5 Imagen: HTMLgoodies

    El problema es que muchos frameworks frontend ponen como ejemplo una sintaxis llena de divs, y como tendemos al copy paste, lo dejamos tal cual (sí, yo también he sufrido de divinitis y aún me estoy curando de los síntomas, sufriendo alguna que otra recaída sin darme cuenta). Aquí dejo un ejemplo de Bootstrap, comparando lo que tiene en la especificación de su web, con cuál sería una solución más semántica.

    Bootstrap

    Bootstrap Panels

    <!-- Bootstrap -->
    <div class="panel panel-default">
      <div class="panel-heading">
        <h3 class="panel-title">Panel title</h3>
      </div>
      <div class="panel-body">
        Panel content
      </div>
      <div class="panel-footer">Panel footer</div>
    </div>
    

    Imaginemos que lo que representa el panel es, como en este mismo blog, el contenido de un post. Hay que etiquetar, por lo tanto, el contenido como article. El texto será por lo tanto una sección (section) del post.

    <!-- Bootstrap using HTML5 -->
    <article class="panel panel-default">
      <header class="panel-heading">
        <h3 class="panel-title">Panel title</h3>
      </header>
      <section class="panel-body">
        Panel content
      </section>
      <footer class="panel-footer">Panel footer</footer>
    </article>
    

    Mejor, ¿no? ¿Y qué hay de un menú lateral?

    Simple sidebar

    <!-- Sidebar -->
    <div id="sidebar-wrapper">
        <ul class="sidebar-nav">
            <li class="sidebar-brand">
                <a href="#">Start Bootstrap</a>
            </li>
            <li>
                <a href="#">Dashboard</a>
            </li>
            <li>
                <a href="#">Shortcuts</a>
            </li>
        </ul>
    </div>
    
    <!-- HTML5 Sidebar -->
    <aside>
        <nav id="sidebar-wrapper">
            <header>Menu Title</header>
            <ul class="sidebar-nav">
                <li class="sidebar-brand">
                    <a href="#">Start Bootstrap</a>
                </li>
                <li>
                    <a href="#">Dashboard</a>
                </li>
                <li>
                    <a href="#">Shortcuts</a>
                </li>
            </ul>
        </nav>
    </aside>
    

    Como se puede ver, no hay un header por cada página, sino por cada elemento que precise de otro elemento hijo que actúe como ‘título’, cabecera o introducción al mismo. Es mucho más comprensible: ahora se reconoce a primera vista que se trata de un menú de navegación situado a un lado.

    Esto no quiere decir que los divs desaparezcan, ni mucho menos, sino que son utilizados con objetivos distintos que el de contener información estructurada. Sirven para, por ejemplo, ser utilizados como contenedores del grid que estés utilizando en tu framework, o para contener elementos a los que se les va a aplicar un determinado estilo CSS (esto es sólo un ejemplo).

    Agile & UX

    Llevo ya bastante tiempo mareando a la gente con la Experiencia de Usuario, y siempre aprovecho la mínima oportunidad para sacar el tema. Y no porque sea una moda, ni porque crea la UX es el tema de postureo del momento. Más bien, cuando entendí de verdad qué quería decir y descubrí tanto lo muchísimo que me molaba, como lo importantísimo que era, decidí que había que difundirlo a toda costa. Porque no todo el mundo lo toma en serio. Porque desde el punto de vista de los desarrolladores, suele parecer un esfuerzo innecesario. Y nada más lejos de la realidad.

    Llegué a pensar que igual me había vuelto un poquito spammer, pero luego leí el libro The UX Team of One y cambié de opinión. Y ojocuidao, pues entre otras cosas, se habla de cómo un individuo puede concienciar al resto de su equipo acerca de la importancia de pensar en el usuario de un producto para el desarrollo del mismo.

    Ya aproveché en su día y di una charla llamada Introducción a la Experiencia de Usuario en los Google Developer Group de Murcia, organizado por mi amiga Inés. Vinieron amigos, algunos conocidos de la universidad y por supuesto, mi madre, mi padre, mi hermano, mi abuelo y mi abuela. El clásico Family, Friends and Fools. Un año después, creo que ha llegado el momento de seguir spammeando al personal, y será en el evento Agile Spain University Day, el próximo 17 de Octubre.

    Cuando vi que tenía la oportunidad de presentar una propuesta para una charla, no me lo pensé dos veces: aquí meto yo la UX como sea. Y no es que me haya sacado el tema de la manga (Agile&UX? Seriously?), ya que no es nada nuevo y que además he utilizado ya en varios proyectos. Y flipas lo que se consigue haciendo un merge de ambos.

    Total, que me han liao y aquí estoy, viendo a ver cómo meto con calzador toda la info que tengo en 45 minutos. Creo que algo se podrá hacer. Y la cosa es que con la tontería, he empezado a escribir un pequeño documento, con la idea de publicarlo en este blog, o subirlo para que lo podáis descargar. Todo depende de lo corto/largo que quede.

    Por ahora, aquí va un pequeño hint, un boceto de un workflow Agile-UX, inspirado en papers y libros que he estado leyendo últimamente. Parece que con tanta flecha se me ha ido un poco la pinza, pero os aseguro que tiene sentido. No voy a decir mucho más para mantener el hype (que es algo que no se me da muy bien), pero acepto feedback.

    Termino el post con la intro de la charla:

    “En los últimos años, las metodologías de desarrollo centradas en el usuario han tenido un fuerte impacto en el desarrollo de aplicaciones. Crear aplicaciones pensando en el usuario final ha demostrado ser una estrategia de éxito. Pero, ¿cómo se integran estas metodologías con las metodologías de desarrollo ágil? ¿Son lo mismo? ¿Cómo se pueden combinar? Durante la charla, se expondrán las características del diseño centrado en el usuario, las técnicas de UX y cómo éstas se relacionan con el mundo ágil.”

    Imagen de portada: Innovation

    Agile & UX feature image Photo Credit: Innovation

    Border Top Style

    Bienvenidos

    ## Estado actual:

    border-top-style: solid;
    

    ¿Qué es esto?

    Un enésimo intento de abrir un blog. He pensado que comprar un dominio distinto a mi nombre, un hosting en Digital Ocean y crear un tema desde cero usando Bootstrap, en plan vago, me haría motivarme un poquito a la hora crear un blog. En realidad no me gusta, porque implica una responsabilidad. Pero por otra parte, pues oye, sienta bien soltar cosas públicamente de vez en cuando, y quién sabe, tal vez además de a mí, le sirva a alguien.

    ¿Y ese nombre?

    border-top-style viene de la siguiente definición: The border-top-style CSS property sets the line style of the top border of a box. Es decir, un nombre lo suficientemente friki para estar relacionado con la programación web, a la par que cool porque tiene la palabra style que suena a postureo designer, y a la vez la palabra top que tiene una denotación positiva (left o right hubieran derivado en discusiones políticas, y no quería utilizar bottom porque también quiere decir culo y no tiene mucho que ver con el contenido). Top mola. Es muy top.

    Para ser el primer post no está mal, ¿no? Todo ha salido a pedir de Milhouse.