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.

Optimizar aplicacion web realizada con JSF, ICEFACES

23/05/2017
Artículo original

Buenas amigos:

Este es mi primer post y acudo a los expertos esperando me puedan ayudar con un tema que tengo desde hace algunas semanas.

Tengo una aplicacion web realizada con JSF, ICEFACES y postgresql, el número máximo de usuarios que se conectan simultaneamente son 200, pero incluso con 10 personas, el sistema se a vueto lentisimo, lo raro de todo es que yo lo he usado en PC sin problemas pero los usarios se quejan de la lentitud, y sale muy seguir el error de "CONEXIÓN DE RED INTERRUMPIDA", incluso aunque el internet este estable,

Ahora bien tratando de mejorar la conexion a la base de datos, cambie el datasource con algunos parametros y el problema empeoro.

Aqui viene mi pregunta, ¿como podria mejorar el rendimiento de mi aplicación para que pueda ser más rapida y estable?

Le paso el código del datasource. No tengo mucha experiencia manejando pool de conexiones, pero este es el que implemente, espero me pueda ayudar a optimizar. De antemano muchas gracias!

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource"
                destroy-method="close">
                <property name="driverClassName" value="${jdbc.driverClassName}" />

leer más

El mejor método para vaciar una matriz en JavaScript

22/05/2017
Artículo original

Esto surge a raíz de la pregunta de un alumno en mi curso de fundamentos de JavaScript y jQuery, y lo cierto es que es una pregunta sencilla, pero al mismo tiempo interesante...

Si tengo una matriz como esta, por ejemplo:

var miMatriz = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9];

¿Cómo la vacío?

Bueno, lo más evidente parece asignarle a tu variable una matriz nueva, vacía. Algo así:

miMatriz = [];

Pero realmente no hemos vaciado la matriz. Lo que hemos hecho es crear una nueva matriz vacía y se la hemos asignado a la matriz original. Pero la matriz original sigue viva y coleando en memoria. Si está referenciada por alguna otra variable en tu código quedará en memoria todo el tiempo, ya que el recolector de basura no podrá reclamar el espacio que ocupa. Si la matriz es pequeña, como la que hemos puesto al principio, no influirá lo más mínimo. Pero si es muy grande, con miles de elementos, puede llegar a ser un problema. En cualquier caso, si lo que quieres es tener una referencia a una matriz vacía en tu variable, el método te servirá en muchos casos, pero hay que tener claro qué es lo que se está haciendo.

Otro intento lógico que podemos seguir es retirar, uno a uno en un bucle, todos los elementos de la matriz original, definiendo una función del estilo de esta:

function vaciaMatriz(miArr){
    while(miArr.length > 0) {
        miArr.pop();
    }
}

que recorre todos los elementos de la matriz y se los va quitando uno a uno hasta que no queda ninguno. Con esto nos acercamos más al objetivo, ya que la matriz original queda modificada de verdad, y se vacía. Pero es una idea horrible ya que debe recorrer todos los elementos para hacerlo. En una matriz grande puede tardar, aunque bien es cierto en casi ninguna circunstancia normal vamos a notar siquiera el efecto en el rendimiento de la aplicación.

Vamos a tratar de mejorar...

Otra opción posible es recortar la matriz usando alguno de los métodos de manipular sus elementos, como slice y splice.

El primero no es una buena opción ya que lo que hace slice es en realidad hacer una copia de la matriz entre los índices que le digamos, pero no altera la matriz original, así que aunque escribamos:

miMatriz = miMatriz.slice(0,0);

estamos igual que en el caso anterior: conseguiremos una nueva matriz vacía asignada a la variable, pero la original seguirá estando en memoria.

El caso de splice es mucho más interesante y promete conseguir lo que necesitamos: esta función realmente quita los elementos que le indiquemos a la matriz, empezando por el elemento que le indiquemos en primer lugar y quitando el número de elementos que le digamos como segundo parámetro.

Así que según esto si escribimos:

miMatriz.splice(0, miMatriz.length);

tendríamos realmente el resultado buscado, ya que la matriz original se modifica y en este caso se vacía, pues le estamos diciendo que empiece por el primer elemento y quite todos los que hay en la misma (su longitud).

Con splice sí que podemos conseguir de verdad lo que buscábamos: vaciar la matriz original.

¡Yupi! Parece que tenemos ganadora...

En realidad, esta solución es muy buena y casi tan buena como la "definitiva" que voy a dar a continuación.

Y es que resulta que la mayor parte de las veces lo más sencillo es lo mejor. Y es que en JavaScript podemos conseguir que una matriz se vacía simplemente con esta instrucción:

miMatriz.length = 0

En efecto, si en JavaScript ponemos la longitud de una matriz a cero, automáticamente la vaciamos.

Es una de las bondades de las matrices en este lenguaje: que son dinámicas por naturaleza. Esto significa que si cambiamos su longitud crecen o decrecen según lo necesitemos. Llevando esto al extremo, si le ponemos una longitud de 0, es decir, sin elementos, las vaciamos.

Y esta solución es verdaderamente eficiente y rápida y cumple con la otra condició que poníamos al principio: modificar la matriz original para vaciarla, no solo reasignar la variable a una matriz vacía.

Parece que tenemos ganador definitivo.

Vamos a verlo con haciendo algún benchmark, para lo cual he utilizado la fabulosa página http://jsben.ch para probarlo varias veces con una matriz de 2000 elementos para ver cuál ofrece más rendimiento.

Aquí puedes ver los resultados del test de rendimiento de todos los métodos (ojo, los realiza con tu propio navegador, tardarán unos pocos segundos):

Resultados del test

Como vemos, el método de establecer la longitud a 0 es el ganador, aunque ponga en la parte de arriba como ganador al de asignar una matriz vacía que, claro está, es muy rápido, pero como hemos visto tampoco cumple lo que buscábamos. El de la longitud = 0 empata en cuanto a rendimiento pero sí hace exactamente lo que buscábamos.

Como nota resaltable podemos observar que slice y splice también ofrecen un rendimiento muy bueno, pero recordemos que el primero tampoco hace lo que queríamos.

Finalmente, señalar que la gráfica no está a escala (la he recortado para ponerla aquí): el método de vaciar uno a uno tarda enormemente más que lo que reflejan estas barras, y es claramente la peor forma de hacerlo. No tarda el triple o así como pudiera parecer: es muuuucho más lento que los demás, como verás si entras en el enlace anterior.

¡Espero que te resulte útil!

Crear y administrar contraseñas inteligentemente

22/05/2017
Artículo original

Introducción

Recientemente hemos visto mucho revuelo en seguridad con el RansomWare WannaCry y el robo de más de 230 millones de contraseñás y cuentas. En estos tiempos más que nunca es necesario tener buenos hábitos al crear contraseñas al darnos de alta en nuevos servicios. En este artículo mencionaré algunas buenas prácticas que llevo llevando a cabo desde hace unos años.

Crea Buenas Contrasenas

El primer paso es crear una contraseña fuerte y aleatoria. Hay muchas webs que se dedican a generar este tipo de contraseñas, por ejemplo la web de Steve Gibson o la herramienta incorporada a tal fin en LastPass.

Por ejemplo, para cada nueva cuenta que crees en cualquier servicio, genera una contraseña de gran longitud con caracteres, números y símbolos. Una buena elección son contraseñas de 50 caracteres o más, abajo muestro un ejemplo de la herramienta integrada en LastPass.

LastPass password generator
LastPass password generator

Si no quieres usar LastPass puedes usar el generador de Steve

Steve's Perfect Passwords
Steve's Perfect Passwords

Veamos cuanto tiempo se tardaría en descifrar una contraseña de estas características, por ejemplo esta de tamaño 50: 8e8f6$AB9^YgOJ4x$JqHknK*FXp*uru2qyU3KXydaK*lJncQrE:

How long would it take to crack the password?
How long would it take to crack the password? | source: howsecureismypassword.net

en la web de Steve Gibson vemos:

GRC's Interactive Brute Force Password “Search Space” Calculator
GRC's Interactive Brute Force Password “Search Space” Calculator | source: grc.com/haystack.htm

Usa un Administrador de Contraseñas

Está claro que usando este tipo de contraseñas es imposible memorizarlas, eso es signo de una buena contraseña.

Para poder administrar tales contraseñas deberías usar un administrador de contraseñas, yo uso LastPass, ya que han demostrado que saben tomarse la seguridad en serio. Baso esta opinión en el conocimiento de Steve Gibson en seguridad, si quieres comprobarlo por tí mismo aquí hay unos cuantos recursos: I, II.

Incluso si estás usando LastPass para generar y almacenar las contraseñas de forma segura, aún podemos añadir una capa extra de seguridad: “Usar LastPass inteligentemente”, veamos lo que quiero decir con esto en la siguiente sección.

Buenas Prácticas usando un Administrador de Contraseñas

La posibilidad de que alguien te ataque y te robe todos los datos de LastPAss aún existen, aunque toda la información se guarda cifrada. Supongamos que alguien consigue nuestros datos de LastPass, y pongámonos en el peor de los casos, la consiguen descifrada. Si en lugar de almacenar toda la contraseña en LastPass, almacenamos solo la parte que no podemos memorizar aún estaremos a salvo, veamos un ejemplo:

Cuando generas la contraseña, la almacenas en el gestor de contraseñas, pero en el servicio en el que te estás dando de alta, supongamos Google, estableces la siguiente contraseña:

8e8f6$AB9^YgOJ4x$JqHknK*FXp*uru2qyU3KXydaK*lJncQrEUnaContraseñaQuePuedesMemorizar

De este modo, incluso aunque roben todos los datos de LastPass, el ladrón no será capaz de acceder a tu cuenta, ya que solo conoce parte de tu contraseña.

Fortaleciendo tu presencia Online

Cada vez más servicios ofrecen autentificacion en dos factores, deberías habilitarla.

TFA

Cuando activas la autentificacion en dos factores, se te muestran los códigos de respaldo en caso de que pierdas tu teléfono o no puedas generar un código para la autentificacion.

Protegiendo los códigos de respaldo de tu TFA

Es importante que descarues y guardes estos códigos en un lugar seguro. La mejor idea es imprimirlos en papel y guardarlos en una caja del banco. Pero para la mayoría de gente basta con guardarlos en un disco duro externo o imprimirlos.

Eso es todo, creo que aplicando estos consejos estarás más protegido que la mayoría de gente, pero recuerda que nada es seguro al 100%.

¿Qué tipo de consejos o mejores prácticas usas tú?, deja un comentario!

Cómo hacer un menú vertical desplegable con HTML y CSS (con y sin JavaScript)

22/05/2017
Artículo original

Menu vertical desplecagble con HTML5 y CSS3 (con y sin JavaScript)

En este pequeño tutorial vamos a ver cómo crear el típico menú lateral vertical desplegable. Seguro que lo has visto en mil sitios. De entrada, el menú permanece oculto y, al mostrarse, empuja al div del contenido principal. Primero lo veremos usando JavaScript y luego solo con HTML y CSS. Que conste que hay muchas formas de hacerlo, estas dos solo son un par de ellas.

En este sencillo ejemplo (que puedes ver en directo aquí) tenemos simplemente dos divs. El que envuelve al menu (id="sidebar") y el del contenido principal.

Cuando el menú está abierto, el sidebar tiene un ancho fijo y está posicionado como fixed, por si hay que hacer scroll en el contenido. Así que, al div del contenido le damos un margin-left igual al ancho del sidebar.

La clave está en que, al hacer clic en "Abrir menu", hacemos 3 cosas a través de JavaScript:

  • Al div lateral le asignamos un ancho fijo
  • Al div del contenido le asignamos un margen por la izquierda igual al ancho de la columna lateral
  • Ocultamos el link de "Abrir menú" y mostramos el de "Cerrar menú"

Las animaciones son CSS3, no hay JavaScript involucrado.

Y al hacer clic en cerrar, simplemente recorremos el camino inverso.

Este sería el html de los enlaces para abrir y cerrar:

    
    <a id="abrir" class="abrir-cerrar" href="javascript:void(0)" onclick="mostrar()">
        Abrir menu
    </a>
    <a id="cerrar" class="abrir-cerrar" href="javascript:void(0)" onclick="ocultar()">
        Cerrar menu
    </a>
    

Y estas las funciones de JavaScript que llamamos:

 
<script>
function mostrar() {
    document.getElementById("sidebar").style.width = "300px";
    document.getElementById("contenido").style.marginLeft = "300px";
    document.getElementById("abrir").style.display = "none";
    document.getElementById("cerrar").style.display = "inline";
}

function ocultar() {
    document.getElementById("sidebar").style.width = "0";
    document.getElementById("contenido").style.marginLeft = "0";
    document.getElementById("abrir").style.display = "inline";
    document.getElementById("cerrar").style.display = "none";
}
</script>

¿Y si pudiéramos hacer un menú muy parecido pero sin JavaScript?

Pues sí, se puede. El menú sin JavaScript se basa en lo mismo en lo que se refiere a las propiedades de los divs del menú y de los contenidos. Lo único que varía es la forma de controlar este comportamiento.

Descargo de responsabilidad y aviso a navegantes:

Lo que vamos a hacer con HTML y CSS en este ejemplo es una chapuza de proporciones bíblicas que se salta las buenas prácticas del marcado de HTML semántico y del desarrollo web front end en general. Es interesante hacerlo como ejercicio experimental para ser conscientes de que, conociendo bien CSS y echándole imaginación, se pueden hacer cosas muy interesantes, pero la capa de comportamiento se debería manejar siempre a través de JavaScript.

Bien, una vez dicho esto, ¿cómo controlaremos si el menú está abierto o cerrado? Pues usando un input del tipo checkboxa través de la pseudoclase :checked, que comprueba si el campo está marcado o no. En la práctica es como si almacenásemos un valor booleano en una variable de JavaScript, pero en CSS.

    <input id="abrir-cerrar" name="abrir-cerrar" type="checkbox" value="" />
    <label for="abrir-cerrar">
        &#9776; <span class="abrir">Abrir</span><span class="cerrar">Cerrar</span>
    </label>

El input lo ocultaremos con CSS, porque es suficiente con tener visible el placeholder para hacer clic sobre él:

    input#abrir-cerrar { visibility:hidden; position: absolute; top: -9999px; }

Podríamos ocultarlo también con display:none; pero recuerdo haber leído en algún lado (lo siento, no recuerdo dónde) que puede dar problemas en algunos móviles. Siendo sincero, nunca me he encontrado este caso pero más vale prevenir, así que lo he ocultado con visibility:hidden; y luego lo posiciono en absoluto para llevármelo bien lejos, así no me molesta ocupando sitio al renderizar en el navegador.

Dentro del placeholder he colocado dos <span> que me servirán para mostrar u ocultar la palabra "abrir" o "cerrar" a conveniencia.

Ahora, simplemente nos queda escribir los estilos en los que se mostrará el menú cuando el input esté activo:

    
    input#abrir-cerrar:checked ~ #sidebar {
        width:300px;
    }
    input#abrir-cerrar:checked + label[for="abrir-cerrar"], input#abrir-cerrar:checked ~ #contenido {
        margin-left:300px;
        transition: margin-left .4s;
    }
    input#abrir-cerrar:checked + label[for="abrir-cerrar"] .cerrar { 
        display:inline;
    }
    input#abrir-cerrar:checked + label[for="abrir-cerrar"] .abrir {
        display:none;
    }
    

Si te estás preguntando qué hace el símbolo "~", pues bien, es un selector de CSS parecido a "+" pero con una sutil diferencia:

  • El selector "+" selecciona el elemento que esté inmediatamente a continuación en el marcado html
  • En cambio, el selector "~" selecciona el elemento que esté a continuación pero no es necesario que esté inmediatamente a continuación

Y esto es todo, ya tendríamos nuestro menú funcionando que puedes ver aquí. Por cierto, puedes descargarte los dos ejemplos juntos haciendo clic aquí (ZIP 6,7 KB).

¿A que es sencillo? Ahora ya sólo faltaría poner el resto del diseño de nuestra página a nuestro gusto, y quizá hacer algún ajuste menor del tamaño del menú para alguna resolución de móviles.

Pero eso ya te toca a ti. Pruébalo y me cuentas en los comentarios.

HUMOR: Si los lenguajes de programación fuesen países, ¿qué país representaría cada lenguaje?

19/05/2017
Artículo original

Aviso: este post es una recopilación y adaptación de varias respuestas en Quora. Todo lo que vas a leer a continuación es una broma y está escrito sin ánimo de ofender a nadie.

Dado que este tipo de relaciones puede dar mucho juego vamos a poner dos versiones, y para eliminar cualquier suspicacia, ordenaremos los lenguajes alfabéticamente. Evidentemente, no están todos los que son, por ello, os invitamos a añadir cualquier otra que se os ocurra en la sección de comentarios :)

Versión A

  • Awk: Corea del Norte. Se resiste al cambio de forma obstinada, y sus usuarios parecen estar encantados de forma poco natural por razones sobre las que solo podemos especular.
  • Bash: Nueva Zelanda. Le encanta la improvisación.
  • C: Noruega. Correoso y dinámico, pero no muy emocionante.
  • C++: Reino Unido. Sólido y exigente, pero no muy bueno a la hora de rematar la tarea y tiende a ser adelantado por Java.
  • C#: Suiza. Hermoso y bien reflexionado, pero tienes que pagar mucho dinero si quieres implicarte mucho.
  • Cobol: Rusia. En otro tiempo poderoso y escrito pensando en los jefes; pero al final ha bajado en el escalafón.
  • Forth: Australia. Todo va al revés en las antípodas :)
  • Java: EE.UU. Optimista, poderoso, le gusta restarle importancia a los inconvenientes.
  • JavaScript: Italia. De una influencia imponente y querido por todo el mundo, pero que se desmorona fácilmente.
  • Lenguaje ensamblador: India. Masivo, profundo, de una importancia vital pero lleno de problemas.
  • LISP: Islandia. Increíblemente astuto y bien organizado, pero gélido y remoto.
  • Lua: Suecia. Parece acogedor e independiente, sin embargo, ¡es tan dependiente!
  • Perl: China. Aparentemente capaz de hacer cualquier cosa, pero de forma oscura y misteriosa.
  • PHP: Brasil. Brota mucha belleza de él y es muy coqueto, pero en el fondo es muy conservador.
  • Python: Países Bajos. "¡Hola, no hay problema, hagamosh esto chavalesh!"
  • R: Liechtenstein. Probablemente muy asombroso, sobretodo si te van las grandes cifras, pero nadie sabe en realidad qué hace.
  • Ruby: Francia. Potente, elegante y convencido de su propia exactitud, pero más bien ignorado por todos los demás.
  • Scala: Canadá. Por su cercanía a Java (Estados Unidos en esta clasificación) pero mucho más simple.
  • SQL y PL/SQL: Alemania. Una caballo percherón para el trabajo, fiable y robusto.
  • Swift: Japón. De repente no está, y al rato está por todas partes y tu teléfono móvil depende de él.

Versión B

  • ActionScript: Taiwan. Si JavaScript en esta nueva clasificación es China, ActionScript es un pequeña, pequeña astilla de la misma que quiere apropiarse de todo pero que carece del apoyo de su hermano mayor y de muchos otros países. Sin embargo, es bastante notable por su producto visualmente tan irresistible (al menos en el pasado).
  • APL: Mesopotamia. Escritura cuneiforme totalmente incomprensible que en tiempos era una maravilla en su área, pero cedió el paso a sus herederos más modernos.
  • Bash: Suiza. No muy grande por sí mismo pero tira de los hilos del resto.
  • Basic: Finlandia. Fácil de usar, pero no muy potente.
  • C: Rusia. Todo se tiene que hacer del revés, pero todo es posible, su legado es enorme.
  • C++: EE.UU. Poderoso, pero cada vez más y más complicado, ilegible y predispuesto a los errores. Tiende a dominar e influenciarlo todo.
  • C#: Holanda. Influenciado por una gran mezcla de culturas, es muy flexible.
  • Factor: Antártida. Tiene fácilmente representantes de todos los demás países, pero está muy despoblada y es difícil adaptarse a ella. Eso sí, tiene algunas características singulares y espectaculares.
  • Forth: Maldivas. Lejano de cualquier tierra continental y predispuesta a desaparecer bajo el agua debido al cambio climático. Famoso por escribirse del revés.
  • Haskell: Mónaco. No hay mucha gente pero son millonarios, así que no tiene que lidiar con los problemas de las clases bajas.
  • Java: Suecia. Cómodo, pero tiene su propio rey y divisa.
  • JavaScript: China. Crece muy rápido y puede hacer muchas cosas sorprendentes. Muchos usuarios.
  • Lenguaje Ensamblador: Lesotho, que está totalmente rodeado por Sudáfrica. Raramente utilizado hoy en día para hacer un programa entero, normalmente se incluye como parte de un código más grande hecho en un lenguaje de nivel más alto.
  • LISP: India. Cuna de muchas filosofías, derivadas que se han convertido más famosas que la original.
  • Lua: San Marino. Minúsculo y totalmente encuadrado dentro de otro país, pero totalmente funcional y bastante rico e independiente.
  • Pascal: Alemania. Normas estrictas, buen rendimiento. Y a muchísimas personas simplemente no les gusta el lenguaje.
  • PHP: Bangladesh. Pobre, pero numeroso, y está por toda la Web.
  • Perl: Grecia. Debes visitarlo al menos una vez en tu vida.
  • Python: Países Bajos. Moderno, rico, fácilmente accesible, atrayente por varios motivos, pero no es un actor principal.
  • R: Chequia. Su idioma suena tan raro que resulta difícil de aprender.
  • Ruby: Singapore. Avanzado pero pequeño.
  • Scala: Hungría. Técnicamente puro y correcto, pero padece una obsesión con la gramática impracticable que limita su progresión en el futuro.
  • SQL: Arabia Saudita. Dependes de él para ir a coger las cosas que necesitas. Rico y poderoso, pero tienes que ser listo para poder optimizar tu interacción con él. Además, las diferentes implementaciones de SQL tienen sus peculiaridades, como los diferentes países árabes que rodean a Arabia Saudita.
  • Swift: Japón. Técnicamente avanzado, pero aislado en las islas y usa caracteres ilegibles.

Habrás notado que en las clasificaciones no aparece ningún país de habla hispana. ¿Cuál crees tú que es el lenguaje que mejor representa tu país?

Cómo escribir a un fichero en Scala

16/05/2017
Artículo original

En mi último post hablé de Cómo iterar múltiples colecciones en Scala, uno de los muchos problemas que encontré desarrollando mi proyecto de fin de carrera. Otro de los problemas que encontré fue al escribir a un fichero en Scala, la implementación estándar de Scala no tiene soporte para esta tarea, así que tuve que implementar mi propia manera de hacerlo.

Primer enfoque

Como siempre, lo primero que hice fue buscar en Stack Overflow para saber cómo resolvía la gente este tipo de problema, Rex kerr propone la siguiente implementación en la pregunta How to write to a file in Scala?:

def printToFile(f: java.io.File)(op: java.io.PrintWriter => Unit) {
  val p = new java.io.PrintWriter(f)
  try { op(p) } finally { p.close() }
}

y para usarlo:

import java.io._
val data = Array("Five","strings","in","a","file!")
printToFile(new File("example.txt")) { p =>
  data.foreach(p.println)
}

Mi enfoque

Basándome en la respuesta de Rex kerr, modifiqué y adapté su código y lo encapsulé en un object llamado FileUtils:

object FileUtils {
  def printToFile(f: java.io.File)(op: java.io.PrintWriter => Unit): Unit = {
    val p = new java.io.PrintWriter(f)
    try {
      op(p)
    } finally {
      p.close()
    }
  }

  def saveOject(o: Any): Unit = {
    val oos = new ObjectOutputStream(new FileOutputStream("src/main/resources/XY"))
    try {
      oos.writeObject(o)
    } finally {
      oos.close()
    }
  }

  def getObject[T]:T = {
    val ois = new ObjectInputStream(getClass.getResource("/XY").openStream())
    try {
      val r = ois.readObject.asInstanceOf[T]
      r
    } finally {
      ois.close()
    }
  }
}

FileUtils encapsula dos métodos adicionales, saveOject y getObject[T], el primero simplemente guarda el objecto que se le pasa como parámetro en un fichero, el último devuelve el contenido del fichero como una instancia de tipo T. La razón de estos dos métodos se debe a que necesitaba una forma de guardar las características extraidas por el modelo para ahorrar tiempo de cómputo en futuras ejecuciones del proyecto.

Ejemplo de uso

A modo de ejemplo, mi objeto FileUtils se puede usar del siguiente modo (El código es del fichero DependencyParser.scala)

(getClass.getResource("/XY") != null: @switch) match {
  case true => FileUtils.getObject[(Map[String, Vector[Vector[Int]]], Map[String, DblVector])]
  case false =>
    val result = eF(Map.empty[String, Vector[Vector[Int]]].withDefaultValue(Vector.empty[Vector[Int]]),
                   Map.empty[String, DblVector].withDefaultValue(Vector.empty[Double]),
                   sentences)
    FileUtils.saveOject(result)
    result
}

Con (getClass.getResource("/XY") != null: @switch) match compruebo si el fichero ya existe, de ser así, simplemente lo leo llamando a FileUtils.getObject, pasándole el tipo. De este modo ahorro tener que volver a llamar al método eF, encargado de extraer las características. Si el fichero no existe, extraigo las características con eF y luego las almaceno en un fichero llamando a FileUtils.saveOject para usos futuros.

Eso es todo, ¿conoces algún otro modo de escribir/leer ficheros en Scala?, deja un comentario!

Recursos

Qué es la plataforma .NET y cuáles son sus principales partes

16/05/2017
Artículo original

Simplificando mucho las cosas para poder dar una definición corta y comprensible, podríamos decir que la plataforma .NET es un amplio conjunto de bibliotecas de desarrollo que pueden ser utilizadas con el objetivo principal de acelerar el desarrollo de software y obtener de manera automática características avanzadas de seguridad, rendimiento, etc...

En realidad, .NET es mucho más que eso, ya que ofrece un entorno gestionado de ejecución de aplicaciones, lenguajes de programación y compiladores, y permite el desarrollo de todo tipo de funcionalidades: desde programas de consola o servicios Windows, hasta aplicaciones para dispositivos móviles pasando por desarrollos de escritorio o para Internet.

El diagrama siguiente muestra los bloques conceptuales en los que se divide la plataforma .NET:

Esquema básico plataforma .NET

Aunque se trata de un esquema muy simplificado, ya que hay muchos otros componentes que se construyen por encima de esta base y forman también parte de la plataforma, es un esquema igualmente útil para entender qué es la plataforma y en qué "piezas" se basa.

CLR - Common Language Runtime

El CLR o Common Language Runtime es la parte de .NET encargada de ejecutar las aplicaciones desarrolladas para la plataforma:

El funcionamiento del CLR no es trivial, trabaja encima del sistema operativo para aislar a la plataforma de éste. Su funcionamiento es muy parecido, para entendernos, al hipervisor de una máquina virtual. Esto le permite ejecutar aplicaciones .NET multiplataforma. Hoy en día es posible desarrollar aplicaciones .NET para diversas plataformas, como por ejemplo Windows, iOS, Android o Linux.

El CLR nos garantiza también la seguridad de los tipos de datos, avalando que no se producen errores en la conversión de tipos en la ejecución de una aplicación .NET. Este aspecto y algunos otros vienen regulados por lo que se conoce el Common Type System (CTS) o Sistema Común de Tipos de datos.

El CTS define los tipos de datos de .NET y las construcciones de programación de los lenguajes que el CLR puede utilizar de forma adecuada y correcta. En otras palabras, el CTS es lo más parecido a las reglas de juego que permiten el correcto entendimiento entre diferentes lenguajes de programación y el propio entorno de ejecución de .NET.

Otra característica del CLR es la posibilidad de reutilizar porciones de código escritos en diferentes lenguajes. Esto es posible gracias a que todo el código, esté escrito en el lenguaje que esté escrito, debe utilizar las mismas "reglas de juego" de las que hablábamos antes, marcadas por el CLR.

Adicionalmente, el CLR se encarga también de gestionar la vida de los objetos, declaraciones y recursos a lo largo de la ejecución de una aplicación .NET. Esto se lleva a cabo a través de lo que se conoce como recolector de basura o garbage collector. Por lo tanto, a la hora de programar no debemos preocuparnos de reservar espacio de memoria para ejecutar nuestra aplicación .NET. Ni tampoco de liberar los recursos del sistema una vez finaliza la ejecución de la aplicación. El CLR se encarga de ello y nos exime de esta responsabilidad, facilitando el desarrollo enormemente frente a otros lenguajes "tradicionales" como C/C++.

Hoy día es indispensable hablar de ejecución de aplicaciones multi-hilo y multi-subproceso. La posibilidad de ejecutar varios procesos simultáneos dentro de una aplicación .NET es una tarea de la que se encarga también el CLR.

Por último, comentar que el CLR es también el responsable de garantizar la seguridad de ejecución de nuestras aplicaciones .NET.

En definitiva, el CLR es el encargado de gestionar la ejecución de una aplicación .NET. Debido a esta responsabilidad, a las aplicaciones de .NET se las conoce como aplicaciones "manejadas" o aplicaciones de código gestionado.

CLS - Common Language Specification

Al contrario que otros entornos, la plataforma .NET no está atada a un determinado lenguaje de programación. Ni tampoco favorece a uno determinado frente a otros. En la actualidad existen implementaciones para gran cantidad de lenguajes de programación que permiten escribir aplicaciones para esta plataforma.

Entre estos lenguajes de programación destacan Visual Basic ó C#, pero existen implementaciones muy variadas, como por ejemplo Cobol (¡Guau!).

Lo mejor de todo es que, como decíamos en el apartado anterior, cualquier componente creado con uno de estos lenguajes puede ser utilizado de forma transparente desde cualquier otro lenguaje .NET. Además, como ya se ha comentado también, es posible ejecutar el código .NET en diferentes plataformas y sistemas operativos.

La especificación del lenguaje común o CLS está formada por un conjunto de reglas que deben ser seguidas por las definiciones de tipos de datos. Así, dichos datos pueden interactuar desde una aplicación escrita en un lenguaje determinado con otra aplicación escrita en otro lenguaje diferente.

Entre estas reglas se encuentran: la definición de nomenclatura, la forma de definir los miembros de los objetos, los metadatos de las aplicaciones, etc... Una de las partes más importantes del CLS es la que se refiere a los tipos de datos.

Si alguna vez has programado la API de Windows o has tratado de llamar a una DLL escrita en C++ desde Visual Basic 6 por ejemplo, habrás comprobado lo diferentes que son los tipos de datos de VB6 y de C++.

Para evitar este tipo de problemas y poder gestionar de forma eficiente y segura el acceso a la memoria, el CLS define un conjunto de tipos de datos comunes (Common Type System o CTS) que indica qué tipos de datos se pueden manejar, cómo se declaran y se utilizan éstos y de qué forma se deben gestionar durante la ejecución.

BCL - Base Class Library

La BCL está formada por bibliotecas o APIs especializadas que pueden ser utilizadas por todos los lenguajes de programación de la plataforma .NET.

Cada una de estas bibliotecas puede contener a su vez numerosas clases que aglutinan varios métodos y funciones con características concretas.

De esta manera, podemos encontrar bibliotecas con funcionalidades para casi cualquier cosa que necesitemos: enviar correos electrónicos, escribir archivos de texto, acceder a fuentes de datos, manejar información, criptografía, etc...

De hecho, lo más complicado al empezar con la plataforma .NET es navegar entre el mar de funcionalidad escondido en la BCL y aprender dónde se encuentran las principales utilidades.

En el esquema simplificado de la plataforma que hemos utilizado hasta ahora, estaría situado en la zona marcada en rojo a continuación:

En este diagrama tan simple solo vemos una parte mínima de la BCL. En un esquema un poco más amplio, podemos ver cómo, sobre la BCL, se han ido añadiendo nuevos grupos de funcionalidades en las diferentes versiones de .NET:

Dentro de la BCL, como se desprende de las imágenes anteriores, es posible encontrar numerosas clases diferentes, agrupadas organizativamente en lo que se denomina espacios de nombres o namespaces.

Un espacio de nombres no es más que un identificador que permite organizar, de modo estanco, las clases que estén contenidas en él, así como a su vez otros espacios de nombres.

Una (muy) pequeña muestra de éstos sería la siguiente:

Toda la funcionalidad que ofrece la plataforma .NET de serie, sin necesidad de instalar nada de terceras partes, es lo que se conoce como BCL. La BCL es el corazón funcional de .NET. Es lo que nos facilita enormemente el desarrollo puesto que ofrece miles de funcionalidades listas para ser utilizadas: ¿Quieres escribir un archivo a disco? Hecho. ¿Enviar un correo electrónico? Deseo concedido. ¿Acceder a una base de datos remota o a un servicio web? También puedes hacerlo sin dejar la base de la plataforma. Hay literalmente miles de funcionalidades disponibles.

En resumen

La plataforma .NET está formada por una serie de componentes que, en conjunto, permiten la creación de todo tipo de aplicaciones en todo tipo de sistemas operativos y utilizando todo tipo de lenguajes de programación.

Una de las principales dificultades a la hora de aprender .NET es saber por dónde empezar: ofrece tantas cosas que es complicado discernir qué es importante y qué no lo es tanto. Es muy tentador arrancar con unas cuantas "recetas" que te enseñan a hacer cuatro cosas. Pero eso es una receta para el desastre pues no se comprenderá bien qué se está haciendo ni qué hay por debajo.

Aprender .NET bien supone conocer primero una serie de fundamentos, comunes a toda la plataforma, y que te servirán para cualquier lenguaje que uses en el futuro. La curva de aprendizaje se parece a algo así:

Es decir, al principio se va lento, pero luego, de repente, se avanza muy rápido. El motivo es que son muchos conceptos y técnicas de base que es necesario dominar, pero una vez lo consigas, especializarse y aprender cualquiera de las múltiples bibliotecas especializadas (desarrollo web, para móviles, etc...) es mucho más fácil. Es tentador empezar la casa por el tejado y aprender antes alguna de éstas, pero a medio plazo es un error. Sin comprender bien antes los fundamentos, construiremos una casa sin cimientos, y ante la primera dificultad se puede caer.

¿Quieres empezar una casa bien cimentada? Y ¿qué tal ir un paso más allá?

Página Siguiente