FRIKADAS: Enseña a niños (y adultos) cómo funcionan las computadoras con Turing Tumble

09/06/2017
Artículo original

Esta es una de las cosas más interesantes que hemos visto últimamente.

El programador americano Paul Boswell ha creado un juego basado en pequeñas piezas que sirve para que cualquiera, incluso un niño, pueda aprender cómo funciona un computador, divirtiéndose al mismo tiempo.

La idea surgió del hecho de que Paul, como profesor de la Universidad de Minnesota, veía cómo muchos proyectos de estudiantes e investigadores se quedaban sin hacer porque no sabían nada sobre programación ni tenían presupuesto para contratar a nadie. El pensamiento lógico y la comprensión sobre cómo funciona un ordenador (y no tanto cómo se comporta, que son conceptos diferentes) no es algo que se encuentre comúnmente fuera de los estudios específicos sobre informática. Y no debería ser así. Incluso los niños pueden aprender estos conceptos y sacarles provecho el resto de su vida.

Por eso Paul diseñó este magnífico juego, basándose en las ideas de una calculadora mecánica de los años 60 llamada Digi-Comp II, que se basaba en el uso de unas canicas y una serie de actuadores para realizar los cálculos:

El Digi-Comp II

El juego consiste en resolver una serie de puzles lógicos y escapar del plantea Eniac (?) al mismo tiempo que aprendemos a pensar con lógica y conocemos el funcionamiento interno de un ordenador.

El tablero consiste en un par de lanzaderas de canicas pequeñas en la parte superior, que simulan los electrones moviéndose por un circuito. En la parte de abajo podemos colocar seis tipos distintos de piezas para simular diferentes tipos de operadores que modificarán la trayectoria de las canicas mientras bajan. De este modo, al llegar a la parte inferior, las canicas liberarán otra canica en la parte superior (de un lado o del otro según donde hayan caído), para que el circuito siga en funcionamiento:

El Turing Tubler desmontado

Los 6 tipos de piezas disponibles son:

  • Rampas: que mueven las canicas a un lado o al otro:

Rampas

  • Cruces: que permiten que las bolas se crucen, entrando por un lado y saliendo por el otro:

Cruces

  • bits: almacenan información al ser cruzados por una bola, cambiando del estado "On" al "Off" o al revés, y son una de las partes más importantes de resolver los puzles:

Bit en funcionamiento

  • El bit múltiple o "gear bit": funcionan como los anteriores pero no se limitan a cambiar su estado, sino que cambian también el estado de otros adyacentes. Logran hacer que el juego sea una computadora completa de Turing, es decir, que puede resolver cualquier problema computacional que queramos teniendo un tablero lo suficientemente largo:

Gear bits

  • Interceptores: cuando el objetivo se completa, detienen la ejecución:

Interceptor

A partir de unas piezas tan engañosamente sencillas se pueden conseguir cuestiones complejas. Desde una simple suma o resta y otras operaciones matemáticas (multiplicar, dividir...) hasta varios tipos de lógica diferentes, comparar valores, crear patrones...

En este vídeo (en inglés) el propio autor nos explica cómo funciona y muestra algunos ejemplos:

[youtube:iSjx6uh8MFg]

Aunque parece para niños hay problemas propuestos, sobre todo hacia al final, que son realmente complejos e incluso programadores experimentados tendrán dificultades para resolverlos. Así que hay para todos.

Actualmente el juego está en Kickstarter y ha sobrepasado de largo el objetivo de recaudación, por lo que enseguida se pondrán a producirlos. Aún puedes contribuir para obtener desde simplemente el PDF del juego y los planos para poder imprimirlo en una impresora 3D o, pagando un poco más, que te envíen el juego físicamente.

En la página anterior además podrás encontrar una detallada explicación de su funcionamiento, lo que incluye, etc...

Confiesa... ¿lo comprarás diciendo que es para tus hijos o sobrinos pero en realidad lo quieres para tí? ? 

Los 5 mejores frameworks de JavaScript en 2017

06/06/2017
Artículo original

Por cierto... ¡Este es nuestro artículo número 500! :-)

Si has estado dentro del mundo del desarrollo web en los últimos años, te habrás dado cuenta del crecimiento imparable de JavaScript de un tiempo a esta parte. Incluso si no tienes pensado hacer desarrollo web, lo más probable es que te tropieces con JavaScript tarde o temprano en tu carrera profesional.

La popularidad de JavaScript sigue creciendo. Recientemente JavaScript ha sido designado como uno de los mejores lenguajes de programación para aprender en 2017 por IBM. Se usa tanto en el lado del cliente como en el lado servidor y ayuda a diseñar interfaces espectaculares, enriquecer aplicaciones web con multitud de funciones, editar páginas web en tiempo real y más cosas, extendiendo su influencia al servidor e incluso a dispositivos embebidos.

Pero es un mundo cambiante...

En 2016 ya vimos muchos grandes cambios, como la presentación de Angular, el auge imparable de React, la cada vez mayor popularidad de Vue.js, la evolución de ECMAScript, actualizaciones constantes de Node.js, el (aún hoy en día) dominio absoluto de jQuery que se utiliza en el 96% de las webs que usan JavaScript... Y todo esto sin contar con los movimientos constantes que hay en tooling con WebPack y npm/Yarn a la cabeza.

¿Qué esperar en 2017 en cuanto a bibliotecas y frameworks de lado cliente? Esto es lo que sabemos hasta ahora: Angular 4 salió a finales de marzo, la edición ECMAScript2017 es inminente y el lanzamiento de Bootstrap v4 también se prevé para pronto.

Los frameworks web de JavaScript pueden ser una solución muy útil para el desarrollo rápido de aplicaciones web. Sirven de estructura para aplicaciones de una sola página (SPA), permiten a los desarrolladores preocuparse menos de la estructura del código y el mantenimiento, y centrarse en la funcionalidad.

Las ventajas de usar frameworks de JavaScript son:

  • Eficiencia y velocidad de desarrollo: antiguamente crear un proyecto desde cero podría llevar varios meses y, ahora gracias al uso de funcionalidades pre-programadas, estructuras predefinidas y patrones probados (como MVVM), el desarrollo puede ser mucho más rápido.
  • Mantenimiento e incorporación de miembros a los equipos: gracias a que el uso de un framework fuerza a usar ciertas arquitecturas y formas de proceder, es mucho más fácil incorporar personas a un equipo de trabajo, pues sabrán entender el código y retomarlo de manera más rápida. Algunos, no obstante, son más "estrictos" que otros en cuanto a lo que dejan hacer o no a los programadores. Por ejemplo Angular es muy estricto en cuanto cómo desarrollar, por lo que resta algo de libertad a los programadores, y al mismo tiempo facilita la incorporación al proyecto, por lo que puede ser ideal para las empresas.
  • Seguridad: los mejores frameworks de JavaScript están diseñados con la seguridad en mente, y facilitan que nuestras aplicaciones sean más seguras. Por supuesto, la última palabra la tiene el desarrollador, que debe también pensar en la seguridad todo el tiempo mientras programa. Pero nos facilitan mucho la vida a este respecto también.
  • Coste: la práctica totalidad de los frameworks son de código abierto y gratuitos. Dado que ayuda a los programadores a crear soluciones personalizadas más rápidamente, el precio final de cualquier aplicación web también será menor.

Los mejores frameworks de JavaScript en 2017:

Angular

Tras el esperado lanzamiento de Angular hacia finales de 2016, su popularidad ha alcanzado nuevas cotas, aunque AngularJS no va a ceder mucho terreno en 2017 y seguirá siendo muy utilizado, ya que existen multitud de aplicaciones creadas con esa versión, y el equipo de Google la sigue manteniendo y lanzando nuevas versiones.

El término "Angular 2" ha sido abandonado a partir de la versión 4. Dicho esto, debemos empezar a llamarle simplemente "Angular" sin el sufijo de la versión, como ya hemos dicho en varias ocasiones en este blog.

Angular a menudo se le define como framework MVW (Model-View-) y entre sus principales ventajas, para startups y PYMES destacan, por citar las más importantes solamente:

  • Desarrollo rápido.
  • Enlazado de datos en ambas direcciones.
  • Es muy "opinionado" (com dicen los yankis), es decir, te fuerza a usar buenas prácticas y una serie de arquitecturas, por lo que es fácil que cualquiera retome tu trabajo y también colaborar.
  • Facilidad de testing.

    Desde su lanzamiento ha llegado más lejos de lo que nadie se imaginada. Por ahora se le considera razonablemente el framework de JavaScript más usado para desarrollos de SPAs (incluyendo AngularJS y Angular) y es el que tiene, probablemente, la comunidad más grande de desarrolladores.

Angular viene con una larga lista de funcionalidades que permiten desarrollar de todo, desde aplicaciones web hasta aplicaciones de escritorio y móviles. El framework está hecho con TypeScript, con la intención de hacer que JavaScript sea más ágil y atractivo para grandes empresas. Angular destaca por tener una arquitectura basada en componentes, una inyección de dependencias mejorada, un servicio de logging eficiente, comunicación entre componentes y mucho más...

Angular es probablemente la mejor opción para empresas o para entornos de programación estrictos, con altos estándares en cuanto a la legibilidad del código.

ReactJS

React (también llamada React.js o ReactJS) es una biblioteca JavaScript de código abierto para crear interfaces de usuario con el objetivo de animar al desarrollo de aplicaciones en una sola página. Intenta ayudar a los desarrolladores a construir aplicaciones que usan datos que cambian todo el tiempo. Su objetivo es ser sencillo, declarativo y fácil de combinar.

Aunque lo hayamos incluido en la lista, hay que tener claro que, al contrario que Angular, es una biblioteca de UI, y no tanto un framework. Es decir, hay muchísimas cosas que deja fuera y que sus competidores sí que tienen, ya que está centrado en lo que está centrado: interfaces de usuario. En el patrón MVC (Modelo-Vista-Controlador), React.js sería la "V"

Lo bueno y malo a la vez es que puede ser integrado con cualquier arquitectura, pero debemos tenerla clara, ya que no nos viene marcada. Por ello es más demandante por parte de los desarrolladores, que necesitan utilizar otros frameworks, arquitecturas y componentes para dotar a sus aplicaciones de la funcionalidad que React no ofrece.

Debido al uso del "DOM virtual" ofrece un enorme rendimiento en el renderizado de interfaces, sobre todo si lo compramos con frameworks "viejos" de hace solo un par de años, como AngularJS (no Angular, ojo).

Se le considera el framework (aún sin serlo realmente) con mayor crecimiento. React está detrás de las interfaces de usuario de Facebook o Instagram, dando prueba de su valía en aplicaciones dinámicas con mucho tráfico.

A pesar de que tiene una curva de aprendizaje mayor que la de otros frameworks, una vez que lo aprendes es una forma de crear aplicaciones bastante sencilla y fácil de entender. Además puede encajar bien con soluciones de software complejas, ya que es fácil de combinar.

Es interesante para programadores individuales que disfruten con JavaScript, proyectos Open Source, empresas con una dirección técnica muy estricta y equipos con una formación de base en JavaScript/ECMAScript alta.

Vue.js

Vue 2.0 también se presentó en 2016. La idea era tomar prestado lo mejor de Angular, React e incluso EmberJS y convertirlo en una nuevo framework. Está demostrado en numerosas pruebas que es más rápido y ligero en comparación con Angular e incluso con React (¡herejía!).

Al igual que Angular, Vue.js ofrece enlace a datos en dos direcciones, posibilidad de renderizado en lado del servidor (también ReactJS). Del mismo modo, al igual que ReactJS, utiliza un DOM virtual, proporciona componentes reactivos y componibles, y se centra mucho en su núcleo, dejando cosas como el enrutado o el estado global en componentes de terceros. En este sentido es menos completo que Angular, pero más que ReactJS. Ah, e incluso ofrece soporte para componentes JSX de ReactJS si lo necesitásemos, pudiendo combinar ambas.

Su herramienta de línea de comandos, Vue-cli, proporciona una forma rápida de comenzar los proyectos sin partir de cero.

En este enlace de su página se ofrece una extensa comparativa entre Vue.js y otros frameworks y bibliotecas.

Su principal ventaja es que no tiene que cargar a cuestas con el "equipaje" que tienen Angular o React, y ha ido aprendiendo de sus aciertos y errores, por lo que es como aunar lo mejor de los dos mundos. Tiene un rendimiento brutal y es más fácil de aprender que los dos anteriores. Muchos desarrolladores se están pasando a Vue.js. La comunidad de Laravel (PHP) es el framework de lado cliente que ha elegido mayoritariamente.

Ember.js

Ya en 2015 Ember era considerado por muchos como el mejor framework JavaScript para aplicaciones web, dejando a React y AngularJS atrás. Hoy en día puede presumir de una gran comunidad online, actualizaciones periódicas y un uso de buenas prácticas de JavaScript que garantizan la mejor experiencia ya por defecto.

Ember proporciona también enlace de datos en dos direcciones, manteniendo tanto la vista como el modelo sincronizados todo el tiempo, y tiene integrada la popular sintaxis de Hadlebars para crear plantillas. Al igual que Angular ofrece una arquitectura clara para que no tengas que estar tomando decisiones todo el rato, lo cual facilita el desarrollo siguiendo buenas prácticas. Está más pensado para crear aplicaciones grandes desde cero que para pequeñas pruebas de concepto, componentes o incorporarlo a aplicaciones existentes.

Ofrece mucha solera y sabemos que está muy probado, lo cual siempre es una garantía. Es fácil de aprender comparado con Angular o React, y tiene una buena documentación online. Sería recomendable si quieres algo bien probado, que te marque bien las pautas para hacer bien las cosas e incorporar nuevos desarrolladores al proyecto sin problema. Frente a Angular ofrece mayor estabilidad histórica, ya que lleva años en existencia, con una gran calidad y sin romper la compatibilidad al sacar nuevas versiones. Además la empresa que tiene detrás, Tilde, muy conocida en el mundo del desarrollo, lo utiliza para todos sus productos, por lo que tienen mucho cuidado de que esto sea así.

Aurelia

Como les gusta decir a sus fans, Aurelia es el framework JavaScript más popular del que nunca has oído hablar. Y es que se trata de un framework que tiene una gran cantidad de seguidores que simplemente lo adoran.

Su creador es Rob Eisenberg, que fue el creador de su predecesor, el mítico Durandal.js. Rob trabajó en el equipo de Angular creando su actual encarnación (lo que se llamó al lanzarlo Angular 2), pero lo abandonó por no estar muy de acuerdo con las decisiones técnicas y de diseño que se tomaban.

Aurelia es un nuevo framework creado con los últimos estándares en mente (lo cual es una gran cosa, comparándolo con React y Angular), y con todo el aprendizaje que tiene detrás Rob y su equipo con Durandal y Angular. No es tan conocido como los demás, ni tiene una comunidad tan grande detrás, pero a cambio ofrece un equipo de desarrolladores más dedicado que ningún otro, siempre dispuesto a ayudar y resolver tus preguntas.

La gente que aprende Aurelia generalmente lo adora y no quiere saber nada de los otros frameworks, de los que dicen estar a años luz.

Aurelia es como si fuese una variante Angular más elegante y sencilla de entender. Utiliza también TypeScript, por lo que la escritura de código es menos propensa a errores y más sencilla que con JavaScript. Una de las cosas que más le gusta a sus seguidores es la forma de definir componentes, sin el uso de sintaxis rebuscadas, como sí ocurre con Angular y (sobre todo) React. Los componentes escriben en JavaScript y HTML estándar (bueno, en realidad en TypeScript y HTML, que luego se generan a JavaScript) y se parecen mucho a las plantillas que se han usado tradicionalmente en desarrollo web. Es muy rápido y ligero, a pesar de no usar un DOM virtual, que no tiene nada que envidiar en rendimiento a React. Utiliza convenciones para evitar tener que configurar tantas cosas. No depende de componentes de terceros.

Aquí tienes una comparación interesante con Angular y React en palabras de su creador.

Si no tienes miedo de tener menos apoyo de la comunidad que con los anteriores, Aurelia es un framework completo y capaz de hacer cualquier cosa que tengas en mente, es más ligero que Angular y tan rápido como React. ¿Te atreves con él?

Conclusión

La elección de un framework de JavaScript no está supeditado a las funcionalidades que cada uno pueda proporcionar. Depende de los objetivos iniciales de la empresa o el programador, los requisitos de los proyectos, cómo se pueden aplicar dentro de cada caso e incluso de tus gustos personales, tu perfil y tus conocimientos de base.

Aquí hemos revisado someramente los 5 más importantes tratando de ver en un espacio reducido sus principales características, no necesariamente técnicas, y tratando de ayudarte a empezar a decidirte por uno u otro. Todos son muy capaces aunque algunos ofrecen más funcionalidad que otros (React lo tendrás que combinar con más cosas, pues no lo hace todo).

Angular y React son sin duda los más conocidos y utilizados, Ember es un clásico con una base de fans muy activa y fiel que lo convierte en una buena opción. VUE.js parece la gran promesa de futuro, pero en esto nunca se sabe, y Aurelia es adorado por todo el que lo usa.

Así que ahora te queda a ti la tarea más difícil de todas: decidirte por uno...

GAMBADAS: Sáltate el escáner de iris del Galaxy S8 con una foto y una lentilla

02/06/2017
Artículo original

Aunque ya se presentaron bastante antes móviles con dispositivos biométricos, fue el lanzamiento del iPhone 5S en 2013 el que dio el pistoletazo de salida para popularizarlos entre el gran público. Este iPhone trajo a las masas el lector de huellas dactilares para desbloquear y acceder al dispositivo, una funcionalidad que ahora se da por hecha en todos los móviles de gama media o alta, a pesar de haberse demostrado con creces su bajo nivel de seguridad.

Pero claro, los fabricantes de terminales de gama alta deben justificar sus exorbitados precios de alguna manera, y poco a poco van añadiendo todo tipo de características y sensores, que en muchas ocasiones son poco más que un juguete para llamar la atención. Los más avanzados ahora incorporan también lector de iris. Samsung lo introdujo en su malogrado Galaxy Note 7, y ahora vuelve a la carga incorporándolo al Galaxy S8. Como este dispositivo tiene "pantalla infinita", no les ha quedado más remedio que colocar el lector de huellas en la parte de atrás, un sitio bastante inconveniente. Por ello, este modelo te permite desbloquearlo simplemente mirando a la pantalla, gracias a su reconocimiento de iris.

Escaner de iris del S8

Ahora, los famosos hackers alemanes del Chaos Computer Club han logrado romper el acceso al móvil de la manera más sencilla: con una fotografía y una lentilla blanda.

Para ello basta con sacar una foto al individuo cuyo teléfono queremos atacar desde unos cinco metros de distancia con una cámara capaz de tomar fotos nocturnas o alguna a la que se le haya quitado el filtro de infrarrojos. Luego se imprime en una impresora con calidad suficiente (una de la propia marca, para mayor insulto) y se le coloca una lentilla blanda sin graduación encima a la impresión. El resultado: el móvil se desbloquea instantáneamente.

Puedes ver todo el proceso en este vídeo de un minuto:

[youtube:gtQ4yzbsi-c]

La idoneidad de basar la seguridad en sistemas biométricos

De acuerdo: no es tan fácil conseguir una foto con esas características de alguien, ¿o sí?...

Bueno, este tipo de funcionalidad va a empezar a verse por todas partes en breve. Lo más probable es que otras marcas, especialmente de móviles más baratos, usen unos sensores también más sencillos y económicos, que se puedan engañar con una foto convencional. Es cuando muchos se van a arrepentir de ciertos "selfies" subidos a las redes sociales, por ejemplo.

En este sentido es interesante leer la nota de prensa que lanzó el CCC para anunciar que habían roto el sistema biométrico del S8.

En cualquier caso, antes de usar medidas de carácter biométrico para proteger información importante, es necesario pensar en sus implicaciones. Y no debemos olvidar que, cada vez más, nuestra vida va dentro de nuestros móviles, así que la decisión es más importante de lo que parece.

Sí, desbloquear el móvil con la huella dactilar o mirando para la pantalla es de lo más cómodo y nos permite ahorrar un segundo cada vez que lo desbloqueamos (eso son varios minutos al día, dado que lo desbloqueamos cientos de veces cada jornada). Pero debemos tener claro que, por bonito que nos lo pinten, no existen sistemas de información 100% seguros. Son un mito.

Una de las máximas de la seguridad es:

"Las claves son como el cepillo de dientes: solo lo utilizas tú y deberías cambiarlo cada poco tiempo".

Esto es así porque si se pierde o se compromete la clave o cualquier otro tipo de token de acceso a un sistema, deberíamos poder cambiarlo de inmediato para asegurarlo de nuevo.

Esto no ocurre con los sistemas biométricos, en los que por definición nuestra huella dactilar, patrón ocular o lóbulo de la oreja (por citar algunos ejemplos) son únicos en el mundo. Si por el motivo que sea éstos se ven comprometidos, de repente los sistemas cuya seguridad dependa de ellos se verán expuestos. Y hay muchas formas de que esto ocurra: desde una copia, como la del ejemplo del iris en el S8, hasta que los sistemas de almacenamiento de esa información, a priori seguros, se vean comprometidos.

Se está trabajando hace años en medidas biométricas cancelables, pero es muy complicado implementarlas en la práctica debido precisamente a que se pierde la conveniencia de las mismas, y por lo tanto pierden gran parte de su sentido original.

Además, existe otra consideración importante que acertadamente apunta el mítico Bruce Schneier en su libro clásico Beyond Fear: incluso si el sistema de autenticación es 100% seguro, de repente el eslabón débil de la cadena de seguridad pasas a ser tú. Desde luego yo no querría un sistema biométrico en mi coche (¡¡y esta noticia es vieja!!).

En resumen

No pretendo ser alarmista. Pero aprovecho la notica para intentar divulgar la idea de utilizar los sistemas de seguridad sabiendo qué hacemos, conociendo sus pros y sus contras. Comodidad frente a seguridad, incluso nuestra seguridad física.

Si lo único que nos interesa es proteger el acceso y cifrar el sistema de archivos por si perdemos el móvil o nos lo roban, es probable que la huella dactilar (no tanto el iris) sea suficiente para la persona media. El problema es no conocer las implicaciones de su uso cuando este tipo de barreras de seguridad se empiecen a ver en muchos otros ámbitos. Si además del móvil, donde ya guardamos cada vez más todos nuestros secretos, también los accesos a nuestra casa, el coche, la empresa... se realizan con medidas biométricas, es posible que empiecen los verdaderos problemas.

Una vez que nuestra "clave" se vea comprometida, no podremos cambiarla, así que conviene estar seguros de que a quienes se la proporcionamos son empresas serias con sistemas serios, y además debemos calibrar el impacto a largo plazo de haber cedido esa información ahora, cuando no parece tan importante.

¿Algunas ideas al respecto que quieras aportar? Usa los comentarios debajo.

Monitorización gratuita de sitios web con Azure

31/05/2017
Artículo original

Si creas y mantienes sitios o aplicaciones web, una de las cuestiones importantes una vez se han finalizado y se ponen en marcha es verificar constantemente que se encuentran en buen estado de funcionamiento. De nada sirve crear la aplicación web más maravillosa del mundo si luego la colgamos en un servidor compartido cutre y se cae constantemente o tiene unos tiempos de respuesta enormes.

Por ello, una de las funciones que tenemos que llevar a cabo en todo desarrollo, una vez se ha desplegado, es la monitorización continua y el control del rendimiento de las aplicaciones o sitios web que están bajo nuestra responsabilidad.

Hay muchas maneras de hacerlo, incluso es posible crear tu propia aplicación para hacer este control, pero lo mejor es recurrir, si podemos, a un servicio profesional que lo gestione como es debido.

Uno de estos servicios es el que ofrece Microsoft a través de Azure, y que se llama Application Insights. Este servicio permite realizar una monitorización completa de cualquier aplicación si la instrumentamos debidamente, pero también permite monitorizar sitios web (incluso estáticos) simplemente verificando que responden de la manera adecuada a las peticiones. Además controla la velocidad de respuesta, permite monitorizar desde múltiples ubicaciones en todo el mundo, que el contenido devuelto es el esperado, guarda un histórico de todas las pruebas, representa gráficamente los resultados, y también nos avisa inmediatamente si algo no funciona, bien a través de email o usando webhooks para poder automatizar alguna aplicación.

¿Qué más se puede pedir? Pues que encima sea gratuito, algo que cumple también este servicio.

Para poder sacarle partido necesitaremos, eso sí, dar de alta una cuenta en Azure. Lo bueno es que dar de alta una cuenta de prueba es gratis. Lo malo es que debes introducir una tarjeta de crédito para poder hacerlo, en la que se cargarán los costes en los que incurras usando Azure. De todos modos lo que ofrece Azure es tanto, tan bueno y a un precio tan asequible que no debería importarte demasiado.

En el siguiente vídeo, nuestro tutor y director José Manuel Alarcón nos muestra paso a paso cómo crear un perfil de monitorización con Application Insights, cómo configurarlo y cómo ver la información que genera. Después del vídeo sigue leyendo, hay información adicional interesante...

[youtube:FP138UhcB-k]

Evitando falsear los datos de visitas

Si utilizas Google Analytics o algún otro producto que se base en la ejecución de un script, todas estas peticiones adicionales no te influirán en los datos de visitas. Sin embargo si tu control de tráfico se basa en el análisis de los logs del servidor, todas estas peticiones quedarán registradas y falsearán tus datos de visitas. Si por ejemplo pones un control cada 15 minutos desde 5 ubicaciones diferentes del mundo, esto supone 14.400 "visitas" extra al mes a cada sitio que está monitorizándose.

Para evitarlo lo único que debes hacer es decirle al software que analiza tus logs que no haga caso a las peticiones recibidas desde ciertas direcciones IP que se corresponden con las de los servidores de Microsoft que hacen la monitorización. Estas IPs son un número considerable, y las puedes encontrar aquí. En esta página encontrarás una lista de IPs por cada ubicación de las que puedes elegir en la configuración de la tarea. Añádelas a los filtros de peticiones en el análisis del log y no tendrás visitas falsas que te cambien los resultados del análisis.

 

sshoogr: DSL Groovy para trabajar con servidores remotos a través de SSH

30/05/2017
Artículo original

Sshoogr

Si trabajamos en sistemas es muy común que tengamos que hacer pequeños (y no tan pequeños) scripts para automatizar ciertas tareas, conectarnos por ssh a servidores, copiar archivos, ejecutar comandos remotos,... Existen algunas herramientas para realizar estas tareas, pero ¿qué os parecería aprovecharnos de todas las ventajas que nos proporciona Groovy para hacer esto?

Sshoogr, pronunciado como sugar, es una biblioteca escrita en Groovy que proporciona un DSL para trabajar con servidores remotos por SSH. Proporciona una gran flexibilidad y numerosas opciones a la vez que tenemos acceso a todo el lenguaje Groovy y a cualquier biblioteca Java que queremos utilizar.

Primeros pasos

Tenemos dos formas de empezar a utilizar sshoorg a cual más sencilla.

Instalación

La forma más fácil y sencilla de instalar sshoorg es utilizando SDKMAN!, del que ya hemos hablado con anterioridad, así que después de instalarlo, simplemente ejecutamos:

$ sdk install sshoogr

A continuación escribimos este pequeño script Groovy:

remoteSession('ivan:password@localhost') {
  exec 'ls -l'
}

Y lo ejecutamos:

$ sshoogr test1.groovy
>>> Connecting to localhost
> ls -l
total 124328
drwxr-xr-x  2 ivan ivan      4096 May 19 15:32 bin
...
...

<<< Disconnected from localhost

Si obteneis el error reject HostKey: localhost lo único que teneis que hacer es añadir al script anterior trustUnknownHosts = true justo antes de la closure remoteSession.

La ventaja de esa forma de instalar y utilizar sshoorg es que tenemos acceso completo al DSL sin necesidad de saber cómo funciona y realmente.

¿Y sin instalarlo?: Uso como biblioteca

La otra alternativa posible es utilizarlo directamente como biblioteca Groovy. Con esta opción no podremos aprovechar completamente el DSL pero no tendremos que instalar absolutamente nada, simplemente añadir la dependencia:

@Grab('com.aestasit.infrastructure.sshoogr:sshoogr:0.9.25')
@Grab('commons-codec:commons-codec:1.10')
import static com.aestasit.infrastructure.ssh.DefaultSsh.*

trustUnknownHosts = true
remoteSession('ivan:password@localhost') {
  exec 'ls -l'
}

En este caso vemos que el código es muy similar al anterior pero tenemos que añadir manualmente las dependencias y el import.

Sacando partido a sshoogr

Como hemos visto en ambas opciones es muy fácil y rápido empezar a utilizar sshoorg. Ahora vamos a ver algunas otras cosas que podemos hacer:

  • Crear archivos remotos: Una opción muy útil, por ejemplo para crear archivos de propiedades con la configuración específica de un entorno concreto:
remoteFile('/tmp/file.properties').text = "enabled=true"
  • Subir un archivo: Si en lugar de crearlo en remoto simplemente queremos subir un archivo ya existente:
  scp {
    from { localFile '/home/ivan/mi-archivo.txt' }
    into { remoteFile '/tmp/test.txt' }
  }
  • Hacer un tunel ssh: En algunas ocasiones no podemos acceder directamente a la máquina destino sino que debemos hacer un salto intermedio en otra máquina. Con sshoogr tenemos distintas opciones para realizar tunnelling ssh.

  • Opciones avanzadas: Por si todo lo anterior no fuera suficiente también tenemos la posibilidad de configurar muchas opciones: usuario, password y puertos por defecto, activar el modo verboso para ver más información de debug, activar o desactivar el comando que se ejecuta, la salida del comando, tiempos de espera,...

Entrevista a Andrey Adamovich, creador de sshoogr

sshoogr fue creado de la frustación de utilizar tareas Ant ssh y scp en scripts de Gradle.

Hemos aprovechado la ocasión para hacer una pequeña entrevista a Andrey Adamovich, creador de sshoogr:

Andrey Adamovich

¿De dónde viene el extraño nombre?

El nombre sshoogr viene de una combinación de SSH y GROOvy. Estaba jugando con las letras y encontré la combinación SSH-OO-GR la más interesante de todas. SSH primero, GRoovy segundo :)

¿Por qué creaste sshoogr?

sshoogr fue creado de la frustación de utilizar tareas Ant ssh y scp en scripts de Gradle. Teníamos automatizada la administración remota y el deployment a través de tareas con SSH. La opción de Ant y Gradle no parecía la mejor solución a largo plazo por la cantidad de código de script a mantener.

¿Probaste alguna otra herramienta alternativa??

Cuando cree sshoogr no había muchas alternativas para ejecutar comandos shell remotos que se integrasen adecuadamente con las herramientas y los conocimientos que tenía el equipo: principalmente Java, Groovy y Gradle. Existían alternativas en Python como Fabric y también estaba Capistrano en el mundo de Ruby. Pero aprender esas herramientas era pedir demasiado a nuestro equipo que principalmente conocía Java. Actualmente existen algunas herramientas como gradle-ssh y overthere (licenciado como GPL). También Ansible es bastante popular como herramienta de ejecución remota de scripts, pero no es muy Windows-friendly (yo tengo una máquina con Windows).

¿Tienes planes para el futuro: añadir nuevas características,...?

Tengo muchas ideas sobre como mejorar sshoorg pero el tiempo libre siempre es la mayor limitación :). Con suerte podré empezar a añadir nuevas opciones como local-protocol y controlar la introducción del password de sudo durante el verano.

Bonus: Charla sobre sshoogr de Andrey

Y para finalizar, si quereis conocer de primera mano sshoogr y verlo en acción, os recomiendo esta charla que dio Andrey en Greach 2016:

Más información | Sshoogr

También te recomendamos

Alberto Contador te recuerda que un metro y medio salva la vida

Mejora tu código Java usando Groovy

Nueve anotaciones de Groovy que te harán la vida más fácil al desarrollar

-
La noticia sshoogr: DSL Groovy para trabajar con servidores remotos a través de SSH fue publicada originalmente en Genbeta Dev por Iván López .

Women Techmakers: Entrevistamos a Tech&Ladies Barcelona

29/05/2017
Artículo original

Women Techmakers Logo

El pasado 25 de marzo se realizó la segunda edición de Women Techmakers en Barcelona, donde cerca de 80 personas se unieron para dar visibilidad al sector femenino en el mundo de las tecnologías de la información.

Con motivo de este evento, hemos hablado con sus organizadoras, las Tech&Ladies Barcelona, sobre la situación actual de las mujeres en este sector, y también para que nos cuenten en qué consistió la organización del evento y su desarrollo.

Sin más, os dejo con la entrevista:

¿Quiénes sois Tech&Ladies Barcelona?

Las Tech&Ladies Barcelona somos 8 chicas que compartimos las ganas de motivar y dar visibilidad a las mujeres que tienen relación con el sector tecnológico. Nosotras somos: Adela Tort, Cristina Palomares, Davinia García, Elisa De Gregorio, Judit Nieto, Laia Chorro, Sara Di Zio y Vero LoGu.

Highres 449626155

¿Con qué objetivo surgió vuestra comunidad?

Nuestra comunidad surgió un poco con la idea de celebrar el primer Women Techmakers en Barcelona el año pasado. A raíz de ahí, el objetivo de las Tech&Ladies en general es ayudar a las mujeres a que se animen a dar charlas en eventos tecnológicos donde normalmente los ponentes suelen ser hombres, para reducir así la brecha de desigualdad de género en el sector. Esto se hace organizando meetups en los que se crea un ambiente de confort para dar los primeros pasos como ponentes y ganar así experiencia dando charlas.

C7wgjszwkaac7zv

¿Qué tipo de acciones lleváis a cabo para cumplir vuestros objetivos?

Organizamos eventos de carácter tecnológico en el que las ponentes son mujeres. Pueden ser temas de cualquier tecnología. Lo importante es que la ponente sea una mujer. La idea es crear un ambiente en el que se sientan cómodas para que empiecen a ganar confianza para hablar en público.

El objetivo de las Tech&Ladies en general es ayudar a las mujeres a que se animen a dar charlas en eventos tecnológicos donde normalmente los ponentes suelen ser hombres

¿Por qué son tan necesarios grupos como el vuestro en nuestro sector?

Para dar visibilidad del papel de las mujeres en el mundo tecnológico y para animar a las mujeres a participar en eventos tecnológicos, tanto como ponentes, organizadoras y asistentes. Nuestro grupo facilita que las mujeres entren en la organización de un grupo tecnológico y sean ponentes, de esta manera ganan confianza y colaboran con otros grupos. La idea es también conseguir paridad de género en grupos tecnológicos que no sean centrados en mujeres.

¿Sigue habiendo desigualdad entre géneros en el mundo desarrollo software?

Sigue habiendo diferencias y desigualdad, pero mucho menos que en otros mundos. Hoy en día el mundo del desarrollo de software tiene más oferta que demanda, con lo que la gente, en general, está bastante cuidada y a la vez hay menos desigualdad, sobretodo en el tema salarial.

C7we Ftxqaaeigv

Un punto donde sí que hay desigualdad es en las posiciones de responsabilidad, en estos cargos vemos muy pocas mujeres. Hay que conseguir cambiar estas dinámicas y que las mujeres puedan y ocupen cargos de responsabilidad. Además, en las empresas de desarrollo sigue habiendo una clara diferencia entre el número de mujeres y el de hombres en el equipo.

¿Cómo ayudan eventos como los WTM a reducir esa brecha?

Creémos que eventos como los WTM crean un ambiente familiar y distendido que permite reunir a las chicas que están relacionadas con el mundo tecnológico y así darnos cuenta de que somos más de las que aparentemente vemos. Además ayudan a hacer networking y establecer contacto con otras chicas y la posibilidad de crear grupos de trabajo. Y como también acuden hombres a estos eventos se consigue que animen a las chicas a ir a otras comunidades y así se favorece la paridad de género en las comunidades desarrollo y reduce las desigualdades.

Un punto donde sí que hay desigualdad es en las posiciones de responsabilidad, en estos cargos vemos muy pocas mujeres.

El 25 de marzo fue el segundo WTM organizado en Barcelona. ¿Qué novedades ha traído con respecto al anterior?

Este año hemos decidido cambiar el día del evento a sábado, facilitando así la asistencia a aquellos y aquellas que trabajan entre semana. Cerca de unas 80 personas nos han acompañado durante esta segunda edición. Otra novedad es el incremento de la duración del evento: de 9:00h a 17:00h, dando tiempo a muchas más charlas. Este año nuestro lugar de encuentro ha sido en la Soko Tech, un espacio de creación para emprendedores en el que se realizan talleres de distintas temáticas y en el que se celebran eventos de carácter tecnológico.

Wtmbcn Logo

En esta segunda edición hemos querido impactar ofreciendo charlas bastante variadas con algunas ponentes de fuera de Barcelona, y talleres para motivar a los asistentes.

¿Cuál fue la agenda?

El programa del evento fue el siguiente:

Adela abrió la sesión dando la bienvenida a los asistentes presentando algunas cifras de las mujeres involucradas en el mundo tecnológico y dando a conocer el grupo de Tech&Ladies, para animar a más chicas a unirse. También incentivó a los asistentes a participar activamente en el evento tuiteando con el hashtag #wtmbcn17 y así entrar en el sorteo que se realizó al acabar la jornada.

C8p9lprwsaaaxis

Le siguió Anne Marie Neatham, COO de Ocado, que nos explicó la importancia de la educación en edades tempranas para acabar con el género asociado a determinadas profesiones.

Después Gema Parreño, nos hizo una introducción al diseño de redes neuronales con TensorFlow.

Antes del coffee break, Silvia Romera enseñó algunas de las aplicaciones que utiliza en las clases extraescolares de robótica que imparte y mostró cómo montar un robot y cómo programarlo utilizando Arduino.

C7w9ftpxwaas1xs

Durante el coffee break los asistentes pudieron hacer networking con más mujeres del sector y con las ponentes además de con las organizadoras.

Clara Grima, doctora en matemáticas y profesora titular del Departamento de Matemática Aplicada I de la Universidad de Sevilla, abrió la segunda parte del evento explicando qué parte de las matemáticas hacen posible avances de la tecnología en ordenadores y móviles.

A continuación Ana Carmona, con 10 años de experiencia en .NET y experta en refactoring, enseñó algunos trucos para poder dar una segunda oportunidad al código legado.

Por último, antes del lunch break, Katerina Zalamova doctora en ciencia de materiales y emprendedora desde el 2005, presentó algunos conceptos sobre ioT y cómo gracias a esto podemos hacer nuestra casa inteligente y realizar tareas automáticamente.

C7wd2luw0aaczo0

En el lunch break se disfrutó de un tiempo de networking con las asistentes y las ponentes.

Después del lunch break los asistentes al evento pudieron elegir entre:

Participar en un workshop para aprender sobre design thinking a cargo de Melisa Galvao, Alexandra Negrut y Silvia Mulet UX designers en Netsuite. El taller tuvo una duración de 2h aproximadamente y los participantes pudieron aprender a solucionar una necesidad de un usuario final, empatizando con su frustración ante el problema siguiendo un proceso iterativo, que enfatizaba la importancia de llegar a una solución a través de la diversidad de opiniones de cada uno de los integrantes del equipo.

O, asistir a una charla impartida por Eva Martín, fundadora y CEO de Tiendeo.com sobre las nuevas tendencias mobile que están incurriendo en un sector, hasta el momento, tan tradicional como es el retail.

C7wcwd1xqaakkvh

Una vez acabada la sesión de la tarde, se realizó el sorteo anunciado al empezar el evento en el que se repartieron libros de autoras del sector, camisetas y una entrada para la JBCNConf.

¿Quiénes han hecho posible este evento?

En este año hemos tenido colaboración de más patrocinadores a los que queremos dar las gracias, ya que hemos podido mejorar y celebrar el Women Techmakers de este año. Aparte de su apoyo y su presencia en la conferencia, hemos podido ofrecer un welcome pack a los asistentes, mejorar el catering y contar con la presencia de grandes ponentes. Queremos dar las gracias a GDG Barcelona, GDG Spain, Schibsted, New Relic, Erni, OpenTrends, Ironhack, Ocado y Tiendeo. Y también agradecer la ayuda con la difusión del evento a Gadwoman.

C7w4xsdw4aaqfu0

Además hemos contado con la participación de la Unidad de Igualdad de la UOC para la grabación de los videos y con Sandra Torras para las fotos del evento.

¿Cuáles han sido las sensaciones sobre el curso de este último WTM?

Estamos muy satisfechas con el resultado. Hemos obtenido muy buen feedback tanto por la parte de los asistentes como por la parte de las speakers y no podemos estar más contentas. Además hemos sido trending topic en Twitter!

Este tipo de comunidades ayuda a ver que no estamos solas y que si algo se nos da bien es apoyarnos las unas a las otras

Y para terminar, ¿qué recomendaríais a las mujeres del sector que se sienten infravaloradas simplemente por el hecho de ser mujer?

Que se unan a las comunidades que hay en sus ciudades para hacer piña. A veces un problema se ve grande por la perspectiva que uno mismo tiene frente a él. Y al compartirlo con otras personas el problema se hace más pequeño. Este tipo de comunidades ayuda a ver que no estamos solas y que si algo se nos da bien es apoyarnos las unas a las otras.

También te recomendamos

Cómo es la labor de un jungla en la Superliga Orange: Carbono nos guía

Droidcon Spain 2014: conociendo a los ponentes y sus charlas ¿Cuál es su visión sobre Android?(I)

Entrevista a BetRocket, "aplicamos la potencia de la base de datos Velneo V7 a las apuestas deportivas"

-
La noticia Women Techmakers: Entrevistamos a Tech&Ladies Barcelona fue publicada originalmente en Genbeta Dev por Antonio Leiva .

10 principales tendencias de desarrollo de webs en 2017

29/05/2017
Artículo original


Photo credit: williamcho via Visualhunt / CC BY-NC-SA

Este artículo es una traducción de la respuesta a esta pregunta que dio Geoffrey Bans en Quora, y que nos ha parecido interesante, no tanto porque técnicamente sea una respuesta profunda (que no lo es para nada), sino precisamente por eso: porque toca temas sencillos y directos que algunos desarrolladores web pasan por alto porque son obvios...

¿Alguna vez te has fijado en cómo los bailarines de bailes de salón parecen flotar por la pista? Los bailarines más patosos pensamos de uno en uno cada paso que damos, mientras que los profesionales bailan dando pasos más fluidos.

Como profesional del desarrollo web, tu capacidad para resolver problemas tiene que fluir de una tecnología a otra. Vamos a enumerar las 10 principales tendencias web en 2017 que te harán ser un desarrollador más solicitado y mejor valorado.

1. Diseño responsivo

Esto es tan obvio que lo pongo de primero para pasar página.

Según los datos de Google Analytics de los 5 sitios web que administro, el 30% del tráfico procede de dispositivos móviles.

Si tu formulario de checkout se descompone cuando el tamaño de la pantalla es 200px, estás perdiendo ventas. Así que como desarrollador web en 2017 haz que todas tus páginas web se adapten a todos los tamaños de pantalla.

2. Notificaciones en tiempo real

Esto antes solo se adoptaba en tecnologías de chat, pero ya no es así. Incluso los paneles de datos de facturación necesitan actualizarse en tiempo real.

Hay más exigencias en este sentido dado que la mayoría de las aplicaciones en 2017 soportan puntos de acceso múltiples, y los demás usuarios necesitan saber cuál es el estado actual de la información antes de tomar decisiones.

Las notificaciones en tiempo real quizás no sean un requisito en todos los casos, pero sí en la mayoría.

3. Diseño modular

Sí, el uso de componentes que no tengan un acoplamiento directo.

Existen muchas bibliotecas y frameworks, tanto para el front-end como para el back-end, que garantizan que los componentes de una aplicación no tengan una conexión directa entre ellos.

El desarrollo en 2017 se inclina hacia patrones de diseño MVC tanto para el front-end como para el back-end. No escasean ni bibliotecas ni frameworks como Angular, React, Laravel, Ruby On Rails, Django, Playframework...

4. Diseño a prueba de idiotas

Han pasado a mejor vida aquellos días en los que podría hacer login infinitas veces en mi cuenta de Yahoo! hasta acertar con la contraseña.

En 2017, incluso las webs más sencillas como Quora están bien preparadas para tratar con el típico idiota que quiere engañar al sistema.

Es más que evidente que hoy en día todas las páginas web tienen una línea que te pide que le demuestres que no eres un robot con un montón de imágenes que tienes que identificar.

Esto se está adoptando incluso más si cabe en 2017.

5. Soporte en vivo y en directo

Hasta los blogs ahora tienen ese pequeño formulario abajo a la derecha en el que se lee: "¡chatea con nosotros!", incluso cuando la web pertenece a una sola persona, en cuyo caso debería poner: "¡chatea conmigo!".

En 2017, cada vez más empresas están invirtiendo más recursos en herramientas de comunicación directa y en caliente con sus potenciales clientes para intentar reducir la comunicación de ida y vuelta de los emails.

Lo bueno de esto es que ya hay muchas empresas que ofrecen este servicio mediante copiar y pegar, así que no tendrás que hacerlo de cero como desarrollador web, a no ser que tu cliente/empresa así te lo exija.

6. Diseño de aplicaciones de una sola página

Si envías un formulario hoy en día y tienes que esperar varios segundos para que la página se vuelva a cargar y que al final te informe de que la contraseña no es válida, te puedes empezar a desesperar, ¿no?

Sí, porque muchas de estas cosas se pueden hacer mientras estás en la misma página sin tener que recargarse ni dirigirte a otra.

Ahorras tiempo y proporciona una mejor experiencia de usuario.

Más información sobre las SPA, aquí.

7. IDEs basados en navegadores

Va a haber más dependencia de esto en 2017.

Este punto es uno que a mi personalmente no me convence, soy más bien inflexible con este tema. Prefiero quedarme con mi IDE para escritorio aún.

Sin embargo, podemos esperar que se hable mucho del tema en foros. Por ejemplo, en Stackoverflow ya hay muchas preguntas y respuestas sobre código de referencia de JSFiddle y de otros IDEs en la nube.

8. Almacenamiento en caché en el navegador

Las buenas aplicaciones web en 2017 implican el uso masivo de multimedia: imágenes, vídeo, audio, etc...

Incluso con el uso generalizado de conexiones de Internet con fibra, la capacidad de transmitir enormes paquetes de datos entre el cliente web y el servidor para ofrecer una buena experiencia de usuario aún está verde.

Muchos desarrolladores web en 2017 usan el almacenamiento en caché en el navegador para reducir la carga sobre la red y renderizar las páginas más rápidamente.

Google incluso te posiciona mejor si tu web usa la caché local del navegador.

9. Compresión HTML

Esto soluciona un problema similar al del punto 8, pero lo pongo por separado porque su uso no se ha generalizado, pero parece que los desarrolladores web le van a dar una oportunidad esta vez.

No solo se trata de HTML. JavaScript y CSS también se están comprimiendo. Esta práctica se lleva haciendo desde unos 10 años o incluso más.

En 2017 los desarrolladores web están investigando mucho sobre que opciones ofrecen las bibliotecas de compresión HTML.

10. Control de versiones

Sí, control de versiones - Git.

Ya sé que muy probablemente sepas de qué va esto, pero no puedo dejar de escribir este artículo sin que te diga que debes gestionar tu aplicación web a través de un repositorio de código y, por lo tanto un VCS.

Hay varias opciones como Git, Mercurial o Subversion; me conformo si usas cualquiera de esas.

Women Techmakers: Entrevistamos a Tech&Ladies Barcelona

26/05/2017
Artículo original

Women Techmakers Logo

El pasado 25 de marzo se realizó la segunda edición de Women Techmakers en Barcelona, donde cerca de 80 personas se unieron para dar visibilidad al sector femenino en el mundo de las tecnologías de la información.

Con motivo de este evento, hemos hablado con sus organizadoras, las Tech&Ladies Barcelona, sobre la situación actual de las mujeres en este sector, y también para que nos cuenten en qué consistió la organización del evento y su desarrollo.

Sin más, os dejo con la entrevista:

¿Quiénes sois Tech&Ladies Barcelona?

Las Tech&Ladies Barcelona somos 8 chicas que compartimos las ganas de motivar y dar visibilidad a las mujeres que tienen relación con el sector tecnológico. Nosotras somos: Adela Tort, Cristina Palomares, Davinia García, Elisa De Gregorio, Judit Nieto, Laia Chorro, Sara Di Zio y Vero LoGu.

Highres 449626155

¿Con qué objetivo surgió vuestra comunidad?

Nuestra comunidad surgió un poco con la idea de celebrar el primer Women Techmakers en Barcelona el año pasado. A raíz de ahí, el objetivo de las Tech&Ladies en general es ayudar a las mujeres a que se animen a dar charlas en eventos tecnológicos donde normalmente los ponentes suelen ser hombres, para reducir así la brecha de desigualdad de género en el sector. Esto se hace organizando meetups en los que se crea un ambiente de confort para dar los primeros pasos como ponentes y ganar así experiencia dando charlas.

C7wgjszwkaac7zv

¿Qué tipo de acciones lleváis a cabo para cumplir vuestros objetivos?

Organizamos eventos de carácter tecnológico en el que las ponentes son mujeres. Pueden ser temas de cualquier tecnología. Lo importante es que la ponente sea una mujer. La idea es crear un ambiente en el que se sientan cómodas para que empiecen a ganar confianza para hablar en público.

El objetivo de las Tech&Ladies en general es ayudar a las mujeres a que se animen a dar charlas en eventos tecnológicos donde normalmente los ponentes suelen ser hombres

¿Por qué son tan necesarios grupos como el vuestro en nuestro sector?

Para dar visibilidad del papel de las mujeres en el mundo tecnológico y para animar a las mujeres a participar en eventos tecnológicos, tanto como ponentes, organizadoras y asistentes. Nuestro grupo facilita que las mujeres entren en la organización de un grupo tecnológico y sean ponentes, de esta manera ganan confianza y colaboran con otros grupos. La idea es también conseguir paridad de género en grupos tecnológicos que no sean centrados en mujeres.

¿Sigue habiendo desigualdad entre géneros en el mundo desarrollo software?

Sigue habiendo diferencias y desigualdad, pero mucho menos que en otros mundos. Hoy en día el mundo del desarrollo de software tiene más oferta que demanda, con lo que la gente, en general, está bastante cuidada y a la vez hay menos desigualdad, sobretodo en el tema salarial.

C7we Ftxqaaeigv

Un punto donde sí que hay desigualdad es en las posiciones de responsabilidad, en estos cargos vemos muy pocas mujeres. Hay que conseguir cambiar estas dinámicas y que las mujeres puedan y ocupen cargos de responsabilidad. Además, en las empresas de desarrollo sigue habiendo una clara diferencia entre el número de mujeres y el de hombres en el equipo.

¿Cómo ayudan eventos como los WTM a reducir esa brecha?

Creémos que eventos como los WTM crean un ambiente familiar y distendido que permite reunir a las chicas que están relacionadas con el mundo tecnológico y así darnos cuenta de que somos más de las que aparentemente vemos. Además ayudan a hacer networking y establecer contacto con otras chicas y la posibilidad de crear grupos de trabajo. Y como también acuden hombres a estos eventos se consigue que animen a las chicas a ir a otras comunidades y así se favorece la paridad de género en las comunidades desarrollo y reduce las desigualdades.

Un punto donde sí que hay desigualdad es en las posiciones de responsabilidad, en estos cargos vemos muy pocas mujeres.

El 25 de marzo fue el segundo WTM organizado en Barcelona. ¿Qué novedades ha traído con respecto al anterior?

Este año hemos decidido cambiar el día del evento a sábado, facilitando así la asistencia a aquellos y aquellas que trabajan entre semana. Cerca de unas 80 personas nos han acompañado durante esta segunda edición. Otra novedad es el incremento de la duración del evento: de 9:00h a 17:00h, dando tiempo a muchas más charlas. Este año nuestro lugar de encuentro ha sido en la Soko Tech, un espacio de creación para emprendedores en el que se realizan talleres de distintas temáticas y en el que se celebran eventos de carácter tecnológico.

Wtmbcn Logo

En esta segunda edición hemos querido impactar ofreciendo charlas bastante variadas con algunas ponentes de fuera de Barcelona, y talleres para motivar a los asistentes.

¿Cuál fue la agenda?

El programa del evento fue el siguiente:

Adela abrió la sesión dando la bienvenida a los asistentes presentando algunas cifras de las mujeres involucradas en el mundo tecnológico y dando a conocer el grupo de Tech&Ladies, para animar a más chicas a unirse. También incentivó a los asistentes a participar activamente en el evento tuiteando con el hashtag #wtmbcn17 y así entrar en el sorteo que se realizó al acabar la jornada.

C8p9lprwsaaaxis

Le siguió Anne Marie Neatham, COO de Ocado, que nos explicó la importancia de la educación en edades tempranas para acabar con el género asociado a determinadas profesiones.

Después Gema Parreño, nos hizo una introducción al diseño de redes neuronales con TensorFlow.

Antes del coffee break, Silvia Romera enseñó algunas de las aplicaciones que utiliza en las clases extraescolares de robótica que imparte y mostró cómo montar un robot y cómo programarlo utilizando Arduino.

C7w9ftpxwaas1xs

Durante el coffee break los asistentes pudieron hacer networking con más mujeres del sector y con las ponentes además de con las organizadoras.

Clara Grima, doctora en matemáticas y profesora titular del Departamento de Matemática Aplicada I de la Universidad de Sevilla, abrió la segunda parte del evento explicando qué parte de las matemáticas hacen posible avances de la tecnología en ordenadores y móviles.

A continuación Ana Carmona, con 10 años de experiencia en .NET y experta en refactoring, enseñó algunos trucos para poder dar una segunda oportunidad al código legado.

Por último, antes del lunch break, Katerina Zalamova doctora en ciencia de materiales y emprendedora desde el 2005, presentó algunos conceptos sobre ioT y cómo gracias a esto podemos hacer nuestra casa inteligente y realizar tareas automáticamente.

C7wd2luw0aaczo0

En el lunch break se disfrutó de un tiempo de networking con las asistentes y las ponentes.

Después del lunch break los asistentes al evento pudieron elegir entre:

Participar en un workshop para aprender sobre design thinking a cargo de Melisa Galvao, Alexandra Negrut y Silvia Mulet UX designers en Netsuite. El taller tuvo una duración de 2h aproximadamente y los participantes pudieron aprender a solucionar una necesidad de un usuario final, empatizando con su frustración ante el problema siguiendo un proceso iterativo, que enfatizaba la importancia de llegar a una solución a través de la diversidad de opiniones de cada uno de los integrantes del equipo.

O, asistir a una charla impartida por Eva Martín, fundadora y CEO de Tiendeo.com sobre las nuevas tendencias mobile que están incurriendo en un sector, hasta el momento, tan tradicional como es el retail.

C7wcwd1xqaakkvh

Una vez acabada la sesión de la tarde, se realizó el sorteo anunciado al empezar el evento en el que se repartieron libros de autoras del sector, camisetas y una entrada para la JBCNConf.

¿Quiénes han hecho posible este evento?

En este año hemos tenido colaboración de más patrocinadores a los que queremos dar las gracias, ya que hemos podido mejorar y celebrar el Women Techmakers de este año. Aparte de su apoyo y su presencia en la conferencia, hemos podido ofrecer un welcome pack a los asistentes, mejorar el catering y contar con la presencia de grandes ponentes. Queremos dar las gracias a GDG Barcelona, GDG Spain, Schibsted, New Relic, Erni, OpenTrends, Ironhack, Ocado y Tiendeo. Y también agradecer la ayuda con la difusión del evento a Gadwoman.

C7w4xsdw4aaqfu0

Además hemos contado con la participación de César Córcoles para la grabación de los videos y con Sandra Torras para las fotos del evento.

¿Cuáles han sido las sensaciones sobre el curso de este último WTM?

Estamos muy satisfechas con el resultado. Hemos obtenido muy buen feedback tanto por la parte de los asistentes como por la parte de las speakers y no podemos estar más contentas. Además hemos sido trending topic en Twitter!

Este tipo de comunidades ayuda a ver que no estamos solas y que si algo se nos da bien es apoyarnos las unas a las otras

Y para terminar, ¿qué recomendaríais a las mujeres del sector que se sienten infravaloradas simplemente por el hecho de ser mujer?

Que se unan a las comunidades que hay en sus ciudades para hacer piña. A veces un problema se ve grande por la perspectiva que uno mismo tiene frente a él. Y al compartirlo con otras personas el problema se hace más pequeño. Este tipo de comunidades ayuda a ver que no estamos solas y que si algo se nos da bien es apoyarnos las unas a las otras.

También te recomendamos

Entrevista a BetRocket, "aplicamos la potencia de la base de datos Velneo V7 a las apuestas deportivas"

Que la primera sangre en el LoL no te vuelva loco: el test para saber si te compensa arriesgar

Droidcon Spain 2014: conociendo a los ponentes y sus charlas ¿Cuál es su visión sobre Android?(I)

-
La noticia Women Techmakers: Entrevistamos a Tech&Ladies Barcelona fue publicada originalmente en Genbeta Dev por Antonio Leiva .

Software Craftsmanship y profesionalismo

24/05/2017
Artículo original

Craft

Pragprog

El término artesanía del software o software craftsmanship ha ido calando en nuestra industria desde que, en 1999 se publicara el archiconocido The Pragmatic Programmer: From Journeyman to Master. En este interesantísimo libro, se profundiza en la metáfora del programador como artesano a la hora de estudiar su evolución como profesional, de manera muy similar a como se realizaba en los gremios medievales.

Mancuso

Movimientos posteriores como la publicación del Manifesto por la artesanía del sotware o referencias como Software Craftsmanship: The new imperative o The Software Craftsman: Professionalism, Pragmatism, Pride, han hecho que este movimiento crezca y evolucione de forma continua, aumentando en gran medida el número de profesionales que se identifican con sus principios.

La metáfora del artesano

Para empezar, debo decir que la metáfora puede resultar un poco confusa, ya que cuando hablamos de artesanía no nos estamos refiriendo a que no sea importante automatizar y sistematizar los procesos que hacemos manualmente. De hecho, esta metáfora ha sido adoptada sobretodo por algunos paralelismos muy claros que existen entre principios de calidad y excelencia que rigen el trabajo artesanal y su equivalente en el desarrollo de software. Podéis guardar vuestro formones de momento!! Todo esto va simplemente de hacer las cosas bien y de cómo hacerlas aún mejor :)

¿Ciencia o arte?

Antes de entender los principios de la artesanía del software, creo que es de vital importancia dar respuesta a esta pregunta. Para los artesanos del software la respuesta está clara, el desarrollo de software es un arte que hay que cultivar (aunque nuestra industria se empeña en lo contrario). En este sentido, cualquier producto software creado para aportar valor a un cliente con unas necesidades específicas, debe ser diseñado a tal efecto y siguiendo estos principios. Un producto que no se adapta al problema, no aporta realmente valor a los que lo acaban utilizando.

Como desarrolladores, ¿Es este el tipo de producto que queremos producir? Entiendo que en muchos casos la respuesta es un rotundo NO, pero para conseguirlo debemos disponer de las armas adecuadas para no caer de nuevo en ese modelo a las primeras de cambio. En este sentido, en los principios de la artesanía del software están las claves de como conseguirlo. Veamos pues en los siguientes apartados, qué principios se pueden derivar de la búsqueda del profesionalismo.

Principios básicos

Para examinar estos principios, vamos a valernos del manifiesto de la artesanía del software que os comentaba anteriormente y, repasando cada uno de sus enunciados, examinaremos qué prácticas podemos comenzar a interiorizar para convertirnos en verdades artesanos.

No sólo software que funciona, sino también software bien diseñado

Uno de los conceptos que primero vienen a mi mente leyendo este primer punto, es el de economía del software. Y es que nuestro buen diseño, sobretodo en las partes de nuestro software que más impacto o más cambio reciben, es lo que nos permite seguir mejorando su estructura sin cambiar su comportamiento observable. Esto quiere decir seguir evolucionando nuestra base de código a través del refactoring, manteniendo la linearidad del coste de cambio.

No debemos olvidar que aunque el software funcione, en cada pequeño cambio tomamos decisiones a corto plazo que pueden condicionar la evolución del mismo a largo plazo. Muchas de ellas son una consecuencia de los tiempos de entrega o de la falta de información, por lo que no siempre son las más adecuadas. En esta situación, estas pequeñas decisiones que funcionan se convierten rápidamente en deuda técnica.

Hay mucha gente que opina que legacy code o código legado es el que escribimos ayer, ya que a partir de ahora debemos mantenerlo, evolucionarlo y liberarlo de la deuda técnica adquirida con técnicas como testing, refactoring o cambio en paralelo. En este ciclo continuo de evolución y mantenimiento, siempre podemos atender a una constante simple y clara, y es que las necesidades de negocio marcan el ritmo. Es por esto que invertir en estas partes de nuestro sistema nos va a reportar un valor claro en el largo plazo, permitiéndonos evolucionar hacia un sistema bien diseñado que absorba mejor el cambio y que nos aporte flexibilidad y respuesta al cambio.

No sólo responder al cambio, sino también agregar valor constantemente

Por supuesto, y siguiendo con lo que comentábamos en el apartado anterior, podemos conseguir estar dando respuesta al cambio de una forma efectiva mediante un buen diseño de nuestro software y no estar aportando valor a nuestro cliente. Pero ... ¿Cómo puede ser esto?

Imaginemos que en el producto que estamos desarrollando, queremos poder conocer el flujo de pedidos de un cliente. En muchos sistemas, esto puede ser ofrecido a través de un formulario para la ejecución de informes en el que puedo filtrar por casi todo lo que se almacena en la base de datos y acabo sacando un PDF con la lista de los últimos pedidos de un cliente concreto. No parece un escenario muy raro para cualquier software de gestión, ¿no? Pero en realidad, ¿estamos aportando todo el valor posible a nuestro usuario con esta solución? Muy probablemente no ...

Quizá en estos casos, el planteamiento debería pasar preguntarnos qué tipo de perfil en la aplicación necesita explotar esta información con el fin de proveerle de un interfaz más reducido pero adaptado a sus necesidades, de forma que como resultado pueda obtener una gráfica de evolución del flujo de pedidos del cliente junto a otros productos relacionados que otros clientes han adquirido cuando compraban el mismo producto que ha adquirido nuestro cliente (quizá le resulte de interés si se lo ofrezco la próxima vez que compre ese producto). El enfoque es un poco distinto y pasa siempre por diseñar soluciones para flujos concretos y perfiles concretos dentro de nuestro sistema y no para administrativos que sólo insertan y consultan datos sin ningún valor adicional que la propia persistencia de los mismos.

¿Nuestro producto resuelve un problema concreto o se asemeja más a un Microsoft Access?

Captura De Pantalla 2017 05 23 A Las 18 14 46

No os dejéis engañar por la apariencia de los formularios de esta captura. Este modelo no es exclusivo de los ERP ni de las aplicaciones viejunas cliente/servidor. En las aplicaciones más hipster y molonas desarrolladas con Angular 4 y GraphQL podemos encontrar en muchas ocasiones estos mismos patrones cuando no razonamos sobre la solución en términos de simplicidad o de facilidad de uso para los distintos perfiles de usuario.

No sólo individuos e interacciones, sino también una comunidad de profesionales

Vale vale, ya identifico la necesidad de evolucionar mi producto en base a un buen diseño del software y quiero aportar valor con cada nueva funcionalidad que desarrollo, Pero entonces, ¿Cómo aprendo todo lo necesario para conseguirlo? ¿Cómo me convierto en un verdadero profesional del desarrollo del software?

Una gran pregunta sin duda y un camino largo que recorrer. En mi opinión, el primer paso debería ser aprender a aprender, de esta forma podré conseguir sacar el máximo partido al tiempo que dedique a mi aprendizaje.

El segundo sin duda es descubrir la potencialidad del aprendizaje colaborativo o en grupo. Tenemos el privilegio de ser una de las pocas profesiones que ha interiorizado el concepto de comunidad de desarrollo en la manera de relacionarnos y aprender en nuestro entorno. Ahora mismo, independientemente de en la provincia en que residas, hay decenas de comunidades locales que realizan actividades que nos llevan a seguir evolucionando y ser mejores profesionales: Coding Dojos, Charlas, Code Retreats, Hackatones, proyectos open source y mucho mucho más. En cualquier caso, si cerca de ti no suceden todas estas iniciativas, siempre tienes dos opciones: Abrir tu propio grupo local de lo que quieras o seguir aprendiendo online con el material infinito de que disponemos. La única premisa es compartir para aprender.

Cwrma9swwaai2z7

El ejemplo más paradigmático que conozco de aprendizaje en grupo es el de la DevScola, la escuela gratuita de programación que tenemos en Valencia y en la que cada año se amplía más y más la comunidad de nuevos desarrolladores que han crecido en un ambiente donde hacer bien las cosas es la única razón de ser.

No sólo colaboración de clientes, sino también asociaciones productivas

Aunque jueguen en otra liga, siempre podemos ver cómo los grandes se siguen asociando para hacer cosas increíbles (FaceBook & Instagram = React). A nuestra escala, cada vez que vamos a una conferencia y haciendo networking hablamos con otros profesionales del sector, estamos aprendiendo y mejorando como profesionales. Si no levantas la cabeza del teclado y sólo piensas en tu producto y en tu entorno, quizá es el momento de abrir miras y ver cómo otros están solucionando los mismos desafíos técnicos a los que tú te enfrentas. Conviertete en speaker, da una charla de cómo hacéis las cosas en tu equipo, recibe feedback y mejora tu proceso/producto. Vete de Desk Surfing a trabajar con otros durante dos semanas y aprende y aporta todo lo que puedas.

Simplemente, no dejes de moverte :)

Conclusión

Ante todo, la artesanía del software es una actitud. Es una manera de plantear tu carrera profesional y de vivirla en el día a día. Es una nueva forma de trabajar en la que a partir de ahora reflexionaremos más sobre el cómo, sobre las ceremonias, sobre la cultura que cultivamos en nuestra profesión y de nuestras relaciones con el resto de profesionales.

Yo llevo intentando caminar esta senda desde que un buen día aparecí por primera vez en una reunión de Agile Levante en la que éramos cuatro personas. Mucho ha llovido desde entonces y mucho he aprendido. En definitiva, lo que más me motiva cada día de esta profesión es lo mucho que me queda por aprender y la suerte que tengo por pertenecer a una comunidad de desarrollo tan sana y que comparte unos valores tan potentes.

También te recomendamos

Ahorrar en gasolina es posible: cinco consejos para evitar que el consumo de nuestro coche se dispare

Por qué prefiero trabajar en una factoría de software en vez de en una Startup

Desarrolladores metidos a emprendedores: ésta es su historia

-
La noticia Software Craftsmanship y profesionalismo fue publicada originalmente en Genbeta Dev por Ricardo Borillo .

Las herramientas de un programador ciego

24/05/2017
Artículo original

Laberinto sin callejones sin salida
Imagen CC-AT-SA por Purpy Pupple en Wikimedia

Nota: este artículo es una traducción de un post de Parham Doustdar, un programador iraní ciego, con su permiso. El énfasis (negritas) es nuestro. Su historia nos ha apasionado y seguro que traducimos algún otro artículo de los suyos en el futuro.

Cuando publiqué la Autobiografía de un Programador Ciego, recibí muchas preguntas sobre cómo uso el ordenador, cómo escribo código, y sobre cómo comprendo conceptos abstractos.

Cuando empecé a escribir este post me iba por las ramas todo el rato. Empezaba a escribir sobre cosas de mi pasado que no tenían nada que ver con las herramientas que uso. Daba mi preferencias, y luego explicaba cómo llegué a formar dichas preferencias... pero ¿por qué os cuento esto?

Es para animaros a que le echéis un vistazo al enlace de la primera línea de este post, es decir a Autobiografía de un Programador Ciego. Si ahora aún no te apetece, al menos tenlo en cuenta si quieres saber más sobre mi pasado.

Habiendo dicho esto, dejémonos de marear la perdiz y vayamos al grano para explicar lo que dice el título de este post.

Herramientas para todos los días

Lectores de pantalla

Los usuarios de ordenador con discapacidad visual o baja visión usan lo que se denomina un lector de pantalla (adivina para qué) que les lee la pantalla. Estos programas tienen funcionalidades muy potentes. Por ejemplo, con él puedo controlar el ratón, ver los elementos en la pantalla jerárquicamente (como entrar en un menú, o desplazarme por los elementos dentro de una barra de herramientas, etc). Sin embargo, una de las funcionalidades más impresionantes de cualquier lector de pantalla en general es cómo maneja el contenido web. La funcionalidad más rudimentaria es que es capaz de desplazarse entre diferentes tipos de elementos como listas, títulos, botones, campos de texto, y así sucesivamente. El nivel más avanzado es la granularidad, como ser capaz de saltar a un título de primer nivel (un elemento h1) y demás. Por último, ser capaz de manejar WAI-ARIA es una de las funcionalidades que se ha vuelto más importante en los últimos tiempos, ya que cada vez más páginas web adoptan su uso (por ejemplo Google Docs, Twitter, Facebook y demás).

Los lectores de pantalla, al igual que otros programas, ofrecen diferentes funcionalidades en función del que estés utilizando. Por ejemplo, yo uso NVDA porque tiene una calidad altísima, está escrito por personas ciegas, y no tengo que estar buscando copias piratas porque es gratuito. Sin embargo, hay otros lectores de pantalla. Jaws (también conocido como Job Access With Speech) es muy popular, pero su uso va cayendo tras muchos años de hegemonía. También está Window-Eyes, que está creciendo en uso. Si quieres ver una encuesta de tendencias (navegador, lector de pantalla, y combinación de navegador/lector de pantalla), échale un vistazo a los resultados de la Encuesta de los Usuarios de Lectores de Pantalla #6 hecha por WebAIM. Es un recurso muy útil para conocer las tendencias a nivel estadístico entre una minoría de usuarios.

Lo malo es que todos estos son solo para Windows. En Mac e iOS hay un lector de pantalla incorporado llamado VoiceOver. En Linux, hay un lector de pantalla que viene con Gnome de escritorio llamado Orca. Para aquellas personas que no tienen un entorno de escritorio está el proyecto Speakup. Para los usuarios de Android, Google ofrece Google Talkback.

Para hacer la lista lo más completa posible, las personas que usan Chrome normalmente usan una extensión llamada ChromeVox, que es una forma de interactuar con Chrome, y que se diseñó para ser el lector de pantalla de Chrome OS.

Yo personalmente uso Windows y Android, así que mis lectores de pantalla son NVDA y Google Talkback.

Lenguajes de programación

Me encanta aprender lenguajes de programación, así que no tengo uno que use para todo. Sin embargo, cuando hablamos de lenguaje de programación con los que he trabajado, esta es la lista:

  • PHP (lo uso en mi trabajo)
  • Go (lo uso en mi trabajo, pero no tanto como PHP)
  • Elixir (trasteo con este en casa)
  • Scala (siempre he querido poder trastear con este en casa también, pero el gran número de funcionalidades de lenguaje me intimida y siempre lo dejo para otro momento)

Por supuesto, he experimentado con otros lenguajes, pero estos cuatro son los que más he usado.

IDEs

Primero, voy a definir lo que yo espero de un entorno de desarrollo integrado.

Un buen IDE tiene que ofrecer autocompletar, la capacidad de ir a la declaración de la función/clase/variable y ver la documentación de una funcionalidad (esto podría ser un DocBlock, o documentación para funcionalidades incluidas de serie). Por supuesto, el refactoring es fundamental: extraer variables locales y métodos, mover funciones de aquí para allá, renombrarlas y demás.

Cosas que están bien tener pero que no me preocupan mucho serían por ejemplo, obtener dependencias de proyectos (usando el gestor de paquetes de un lenguaje como composer, go get, npm y demás) desde el propio IDE, porque así puedo ejecutarlos desde una línea de comando. Obviamente, crear y ejecutar binarios directamente desde el IDE puede ser muy útil, pero como para mí la alternativa es simplemente hacer Alt+Tab para acceder a mi terminal, pulsar flecha arriba para obtener el último comando, y luego pulsar Intro para ejecutarlo de nuevo... me da igual si un IDE no incluye dicha funcionalidad.

La mayor parte del tiempo uso Eclipse e IDEs basados en Eclipse. Al estar en Irán, tengo que usar copias piratas de copias de pagos (como Zend Studio). Sin embargo, las funcionalidades de accesibilidad de Eclipse le ganan a aquellas ofrecidas por otros IDEs sin líneas de comando (sí, ya llegaremos al punto en el que explique por qué no uso la línea de comando).

Ya he publicado un análisis en profundidad sobre accesibilidad en herramientas PHP en mi artículo SitePoint llamado El Estado de la Accesibilidad en Herramientas PHP. De todos modos, aquí va un breve resumen:

  • PHPStorm solía ser malísimo, pero los tiempos están cambiando. La plataforma IntelliJ, hasta hace muy poco, era muy inaccesible. Ahora Android Studio está cambiando eso, hasta el punto de que Android Studio se puede casi comparar con IDEs basados en Eclipse. Propuse una sugerencia sobre este tema y dado al gran número de votos recibidos, lo subieron en sus prioridades dentro de su lista de mejoras por hacer (su to-do list, gracias desarrolladores de IntelliJ) y empezaron a trabajar en algunos puntos.
  • SublimeText es malísimo. Sus desarrolladores no responden a peticiones de mejora en accesibilidad, así que está fuera de mi atención.
  • NetBeans ha empezado a trabajar con las personas que están detrás del Lenguaje de Programación Quorum. No lo he usado últimamente, pero he oído que las cosas están mucho mejor con Sodbeans, el IDE Quorum.
  • Notepad++ simplemente funciona. Obviamente, funciones tipo autocompletar y demás no funcionan con lectores de pantalla, pero Notepad++ es muy ligero y compatible con finales de línea tipo Unix, así que lo uso encantado para cosas rápidas.

Sistemas Operativos

Uso Windows tanto en casa como en el trabajo. Tengo un viejo portátil con Linux, para trastear con Emacs y Emacspeak, para ver si soy capaz de dominar sus casi infinitos atajos. Sin embargo, dado que navegar en Linux no está tan bien como navegar con Windows en términos de accesibilidad, me quedo con Windows por el momento.

Actualmente no hay suficientes usuarios de ordenadores ciegos como para justificar una mejor accesibilidad en muchas aplicaciones. Imagina que solo un 1% de las personas con discapacidad visual usan el sistema operativo Linux. Al final los lectores de pantalla no son muy avanzados, los entornos de escritorio (como KDE) no son ni de lejos tan accesibles como sus homólogos en otros sistemas operativos, y el ritmo del cambio es muy, muy lento. A ver, se puede usar, pero es que la experiencia de usuario no es, a falta de una palabra mejor, tan limpia como la experiencia que obtienes con Mac OS X o Windows.

A priori, puedes pensar que Linux es más accesible para las personas con discapacidad visual que Windows, y esta creencia es básicamente verdad. ¿Por qué pensamos que Linux es más accesible? Pues porque cuando pensamos en Linux, nos viene a la cabeza una imagen de caracteres que van desplazándose rápidamente por la pantalla. "Si es todo texto", piensa la mayoría, "entonces tiene que ser un sistema operativo perfecto para que trabajen las personas con discapacidad visual". Y esto es verdad, pero hasta un punto.

El problema se pone de manifiesto cuando hablamos de Internet. Necesitas un navegador capaz de ejecutar JavaScript para navegar por Internet hoy en día, y esto implica que no puedes usar una línea de comando. Entonces tienes que empezar a gestionar temas de navegador, acceso a navegador, y cosas como Adobe Flash Player que es inaccesible en Linux y que no tiene una alternativa accesible en esa plataforma. Igual que lo expuesto en el post sobre PHP llamado PHP: un fractal de mal diseño, hay muchos pequeños problemas. Todo funciona más o menos, pero no encajan las piezas tan bien como en otras soluciones.

Nota: no me estoy metiendo con PHP aquí. Solo cito este post por su famoso ejemplo sobre la caja de herramientas que muchos desarrolladores conocen.

Todos sabemos que Linux es una parte indispensable de cualquier juego de herramientas de un desarrollador web. Yo he solucionado ese problema creando mis entornos de desarrollo con Vagrant, que me ofrece la ventaja de usar Windows para escribir código, y la línea de comandos en Linux para montar y ejecutar la aplicación. No estoy usando Docker porque han bloqueado la descarga de imágenes en Irán.

Con estas explicaciones, os estaréis preguntando por qué no uso Mac. Después de todo, su objetivo es ofrecer una interfaz gráfica de usuario amigable y fácil de usar, a la vez que mantiene la potencia de un terminal, a tu disposición. Esto también es verdad. Sin embargo mi problema con Mac OS X es algo mucho más sencillo, ya que VoiceOver es un lector de pantalla bastante bueno. Mi problema con OS X es que es cerrado. En Linux y Windows, puedes instalar cualquier lector de pantalla, con cualquier sintetizador de voz que quieras. Sin embargo, en OS X, solo puedes usar su lector de pantalla, su sintetizador, y nada más. Eso implica que no puedo usar eSpeak, que es un software texto-a-voz de código abierto en el que un par de amigos y yo contribuimos, para que pudiera soportar el idioma persa. Así que, sin este texto-a-voz disponible en esa plataforma, no tengo forma de comunicarme con muchas personas en mi propio idioma.

Herramientas de productividad

Muchas personas usan diferentes aplicaciones para visualizar cosas. Tienes los tablones Kanban, herramientas de mapas mentales, apps para gestionar las finanzas personales, y muchas más. En el mundo de la programación hay muchas tablas, gráficos y otros tipos de ilustración. ¿Las uso?

Normalmente no.

Cuando estaba en la universidad mis profesores usaban diagramas UML para trasladar conceptos de bases de datos. Usaban formas visuales de representar y calcular datos, como álgebra lineal. Esto suponía un sobre-esfuerzo por mi parte para entender los conceptos en esas asignaturas. Esa presión constante, junto con la poca voluntad que mostraban los profesores que simplemente querían dar su clase e irse a casa, me hizo caer en la cuenta de que no me merecía la pena padecer un sistema educativo con el que me tenía que pelear todo el rato. Ahí fue cuando lo dejé.

Este tipo de problemas no se circunscriben solo al ámbito universitario. Me he matriculado en un curso llamado Las Bases del Machine Learning: Un Enfoque desde un Supuesto Práctico. Hay partes del curso que se basan en técnicas similares, como la regresión lineal. Por supuesto, mi incapacidad de entender estos conceptos ha inspirado la ya famosa pregunta: ¿se puede hacer regresión lineal sin usar gráficas y álgebra lineal? No se trata de que necesite tocar las cosas para ser capaz de visualizarlas. Simplemente es que no entiendo por qué estos conceptos, que en principio no tienen nada que ver con líneas y gráficos, se solucionan de esa manera. Puedo entender que la visualización de los datos te permite ver cómo los puntos de los datos están diseminados, pero ¿tener una solución que resuelve un problema estadístico usando líneas con pendientes e intersecciones? Puf!.

En la actualidad estoy trabajando en un artículo intentando explicar el concepto de regresión lineal sin usar gráficos y, hasta que no esté finalizado, no puedo explicar de manera práctica lo que quiero decir. Sin embargo, muchos conceptos como este, que al parecer se hacen de manera más compleja de lo necesario normalmente me aturden y me confunden. Súmale el hecho de que las líneas y los gráficos y demás no son para nada intuitivos para mí, y ya entiendes el sentido general de lo que quiero decir.

Cuando amplías esto al mundo de las aplicaciones Web, muchas funcionalidades semejantes también pierden el sentido. Por ejemplo, no puedo usar Google Analytics de manera efectiva porque no hay ninguna manera sencilla de ver los datos en bruto en el interfaz, sin poner el ratón encima de varias cosas. Por esta razón he empezado a trabajar en una aplicación en JavaScript para extraer datos de mi Google Analytics y mostrarla en una tabla sencilla, para poder comparar datos, y luego fundirlos y emparejarlos en función de lo que necesite.

Al margen de toda esta negatividad, esto es lo que me funciona.

Uso Trello para crear listas de las cosas que tengo que hacer. La interfaz no es muy fácil de usar ya que no tiene estándares WAI-ARIA. Aunque puede ser usado con teclado, no te informa de muchas cosas. Por ejemplo, cuando navegas en el listado de tarjetas usando j y k, la navegación funciona. Sin embargo, no le deja saber a mi lector de pantalla qué tarjeta ha adquirido foco. Esto implica que aunque puedo usar el teclado para navegar a diferentes tarjetas, no puedo, porque no sé en qué tarea estoy. Google Mail tiene una mejor implementación de esto, donde j y k te desplazan a diferentes emails, pero también de permiten mover el foco a una nueva elección. Lo que esto quiere decir es que mi lector de pantalla te anuncia el nuevo foco, de hecho me permite saber si estoy en el email deseado.

Para redes sociales uso TWBlue para Twitter y Facebook. Voy a Quora a contestar preguntas aunque no forma parte de mi rutina diaria.

Mi proceso creativo es bastante diferente. Desafortunadamente no tengo acceso a personas buenas en cosas como la programación neuro-lingüística para averiguarlo por mis propios medios. El problema está en que el tipo de estimulación que ofrece un mapa mental para alguien que sí ve, no se me ofrece a mí cuando simplemente anoto cosas.

No estoy tan a gusto con las herramientas de productividad que he elegido como con mis herramientas de programación. Tengo que darle más vueltas ya sea para encontrar, probar o crear la solución perfecta para mí.

Conclusión

Hay unas cuantas cosas que me encantan de ser ciego. Una de ellas es que te obliga a labrar tu propio camino la mayor parte del tiempo. No puedes simplemente hacer las cosas como las hacen los demás, porque no te valen. Tienes que entender las cosas desde un nivel muy básico, y seguir experimentado hasta encontrar tu zona de confort. Por ejemplo, cuando alguien da diez razones para ser autónomo, muchas personas simplemente ven la lista, la contrastan con sus objetivos vitales o la visión del futuro y deciden si ser autónomo es lo que les pega más. Sin embargo, yo tengo que pensar todo el rato si tener una discapacidad visual supone ser más un activo o una debilidad si escojo ese camino. Para seguir con mi ejemplo anterior, cuando analizo la lista de las diez razones, barrunto, "¿tendré que crear una interfaz de usuario por mí mismo? La respuesta es, en este momento de la película, un "sí" rotundo. Por eso no soy autónomo.

Pero estoy en un nivel muy básico. Las personas a las que les va bien en la vida asumen estas situaciones y empiezan a ponerse a jugar con ellas en serio, le dan forma, las moldean hasta que están contentos con ellas. Así es como los programadores rediseñan su código hasta que alcanza la forma que habían imaginado. Así es como los canteros tallan una pieza de mármol y le dan forma en su mente hasta lo que tiene que ser en realidad.

Eso es lo que tengo que ser. Es lo que quiero ser.

Página Anterior Página Siguiente