Lo que los ordenadores te pueden enseñar sobre gestionar tu tiempo

20/04/2018
Artículo original

Tanto los seres humanos como los computadores comparten el reto de cómo hacer lo máximo posible en un tiempo limitado. Más o menos durante los últimos 50 años, los ingenieros informáticos han aprendido y desarrollado un montón de buenas estrategias para la gestión del tiempo de manera eficiente. Por el camino también han cogido experiencia de cosas que han salido rematadamente mal.

¿Qué podemos aprender de todo esto? ¿Se podrían aplicar estas enseñanzas a nuestro día a día para ser más eficientes en nuestro trabajo y vivir mejor?

Vamos a verlo...

El Pathfinder que procrastinaba

En el verano de 1997, el vehículo espacial de la NASA Pathfinder aterrizó sobre la superficie del planeta Marte y empezó a retransmitir a la tierra unas imágenes increíbles e icónicas, hito del que por cierto se cumplieron 20 años el verano pasado. Sin embargo, tras varios días sin problemas, algo empezó a ir fatal.

Las retransmisiones se detuvieron. El Pathfinder estaba de hecho procrastinando: se mantenía a sí mismo totalmente ocupado pero sin hacer su cometido más importante, que era retransmitir imágenes del planeta rojo a la tierra.

¿Qué estaba pasando? Pues resultó ser que había un bug, un error, en su planificador de tareas. Todo sistema operativo dispone de un elemento que se denomina planificador, que le dice a la CPU cuánto tiempo tiene que dedicarle a cada tarea antes de pasar a otra, además de decirle a qué tarea debe pasar.

Cuando todo va bien, los ordenadores pasan de una forma tan fluida de una actividad a otra y van cumpliendo con sus responsabilidades de forma tan armoniosa que parece que están haciendo todo de forma simultánea. Pero todos sabemos qué pasa cuando las cosas empiezan a ir mal: el ordenador se cuelga, se congela la imagen y entra en parálisis operativa.

A los seres humanos el hecho de que un ordenador se quede colgado nos debería servir, como mínimo, de consuelo. Incluso los ordenadores se ven abrumados y sobrepasados de vez en cuando.

El algoritmo cuadrático

Quizás aprender cosas de la ingeniería informática que hay detrás de la programación de tareas en los sistemas operativos de los ordenadores nos puede arrojar algo de luz sobre nuestras propias luchas y frustraciones con la gestión del tiempo.

Una de las primeras revelaciones que podemos descubrir es que todo el tiempo que le dedicas a ponerle prioridades a tus tareas es tiempo que no dedicas a completarlas.

Por poner un ejemplo, digamos que cuando abres tu correo electrónico, lo primero que haces es ojear por encima todos los mensajes, buscando el más importante. Una vez que has gestionado ese correo, repites el proceso hasta completar el segundo, y así sucesivamente. El enfoque parece razonable, pero en realidad tenemos un problema.

Es lo que se conoce como un algoritmo o función de complejidad cuadrática, denominado O(n<sup>2</sup>) en notación Big-O. Si tu buzón de entrada del correo electrónico está el doble de lleno, ¡esas ojeadas buscando cada email llevarán el doble de tiempo! y además tendrás que hacer la búsqueda el doble veces...

Conclusión: el trabajo se multiplica por cuatro.

Linux y los cubos de prioridades

Allá por el año 2003 los programadores del sistema operativo Linux se toparon con un problema parecido. Linux priorizaba cada una de sus tareas en función de su importancia y las programaba en cola siguiendo ese orden. El problema es que en muchas ocasiones se pasaba más tiempo priorizando y ordenando las tareas que ejecutándolas.

La solución que, contra toda intuición y sentido común, se les ocurrió a los programadores de Linux fue la de sustituir este sistema exhaustivo de priorización de tareas por otro basado en un número limitado de "cubos" de prioridad (también denominados "niceness" o "simpatía" de procesos). Una vez cubierto el cupo de un cubo, las tareas entran en ejecución. El sistema no tarda tanto en pensar qué hacer a continuación, y se centraba más en ejecutar tareas, logrando avanzar. Se comprobó que este nuevo sistema era más eficiente que el anterior.

Así que siguiendo con el ejemplo con tu buzón de entrada y tus emails, darle muchas vueltas en pensar qué hay que hacer a continuación siguiendo un criterio de importancia puede conducir a la catástrofe. Abrir el correo electrónico una mañana y ver que está tres veces más lleno de lo normal te llevaría nueve veces más de tiempo en gestionarlo. ¡Casi es mejor empezar por orden cronológico o incluso aleatoriamente!

Resulta sorprendente, pero en ocasiones no invertir energías en hacer las cosas siguiendo un orden perfecto puede resultar clave a la hora de conseguir ejecutar las tareas a tiempo.

Interrupciones y cambios de contexto

Otra conclusión que podemos obtener de la programación de tareas tiene que ver con una de las características más prevalentes en la vida moderna: las interrupciones. Cuando un ordenador pasa de una tarea a otra, tiene que hacer lo que se denomina un cambio de contexto, dejando una marca en la tarea que estaba realizando, retirando los datos antiguos de su memoria e incorporando los datos de la tarea nueva.

Cada una de estas acciones tiene un coste. La enseñanza que extraemos de esto es que se produce una incompatibilidad irreconciliable entre la productividad y la capacidad de dar respuesta a nuevas peticiones.

Sacar mucho trabajo adelante implica minimizar los cambios de contexto.

Pero, al mismo tiempo, tener capacidad de respuesta supone poder reaccionar cada vez que se necesita algo.

Los dos principios, minimizar cambios de contexto y poder dar respuesta a nuevas tareas, están en constante tensión de equilibrio.

La capacidad de identificar esta tensión nos permite decidir dónde queremos romper ese equilibrio. La solución más obvia sería la de minimizar las interrupciones.

El coste del cambio de contexto en un ordenador
Imagen obtenida del estupendo artículo sobre el tema de Bryan Braun

Una solución menos evidente es el hecho de agruparlas. Si no hay ninguna notificación o correo electrónico que requiera una acción o una respuesta urgente en el plazo de, por ejemplo, una hora, pues esta es la frecuencia con la que deberías consultarlos. Nada más que eso.

En ingeniería informática, esta idea se conoce como la coalescencia de interrupciones. En vez de gestionar los asuntos a medida que van surgiendo -¿se ha movido el ratón?, ¿se ha pulsado una tecla?, ¿se ha descargado una parte más de ese archivo?-, el sistema lo que hace es agrupar esas interrupciones en función de cuánto tiempo pueden permitirse esperar.

En 2013, este concepto (interrupt coalescing) supuso una mejora sustancial en la vida de las baterías de los portátiles y móviles. Esto sucede porque diferir las interrupciones le permite al sistema comprobar todo a la vez, y luego retornar a un estado de ahorro de batería.

Al igual que ocurre con los ordenadores, las personas también experimentan este fenómeno. Quizás si somos capaces de adoptar un enfoque similar podamos centrarnos más y mejor en nosotros mismos, y entonces igual seremos capaces de reconquistar aquello que tan escaso resulta en nuestra era moderna: el descanso.

Este artículo es una transcripción adaptada del vídeo de Brian Christian para TED-Ed de enero de 2018. Puedes ver el vídeo completo a continuación:

[youtube:iDbdXTMnOmE]

Conclusiones

  • TODOS, de vez en cuando, nos vemos sobrepasados. Mientras no sea frecuente no es algo de lo que debamos preocuparnos.
  • Analiza tu comportamiento para determinar su complejidad y reducirla
  • A veces el orden lógico no es el más eficiente
  • Agrupa tareas por prioridades y ejecuta estos grupos por orden
  • Minimiza las interrupciones y los cambios de contexto

Forzar la descarga de un archivo desde Azure Blob Storage

19/04/2018
Artículo original

Hoy un truco rápido pero muy útil en ciertas ocasiones.

Azure Blob Storage nos permite almacenar archivos de todo tipo accesibles desde la Web a un coste ridículo y con altas prestaciones de velocidad y ancho de banda. Es una buena manera de poner a disposición de la gente todo tipo de archivos, especialmente si son grandes, de modo que si se descargan mucho no acaparen el ancho de banda del servidor de nuestra web, por ejemplo.

Si por ejemplo subimos imágenes o vídeos, lo habitual es que queramos que se descarguen bajo demanda, mostrándose en el navegador. De este modo los enlazamos desde una web, como recursos de la página, y se obtienen desde Azure, que actúa como una especie de caché externa para no ocuparnos ancho de banda.

Sin embargo, a veces querremos que si alguien usa la dirección del recurso en Azure de manera directa, que en lugar de abrirse en el navegador se le descargue el archivo al disco duro. Un ejemplo: un archivo PDF que queremos que se puedan descargar.

Si subimos a Azure Storage un PDF, cuando lo enlacemos se descargará y se abrirá directamente en el navegador. Si preferimos que no sea así y que directamente pregunte al usuario dónde se lo quiere descargar en el disco duro ¿cómo podemos conseguirlo?

Cabeceras de disposición del contenido

La diferencia entre un archivo que se ve en el navegador y uno al que se fuerza la descarga es tan solo una cabecera que devuelve el servidor y que se llama Content-Disposition. Si en esta cabecera ponemos el valor attachment le estamos indicando a los navegadores que queremos que el archivo se descargue. Además le podemos indicar el nombre que le queremos dar a dicho archivo si le añadimos la propiedad filename. Algo así:

content-disposition: attachment;filename=MiArchivo.pdf

O sea, que en realidad lo único que necesitamos es añadir esta cabecera a nuestro archivo. Pero ¿es posible hacerlo?

Hace ya unos años (a finales de 2012) Microsoft añadió a azure la posibilidad de establecer cabeceras personalizadas a los archivos que se almacenaban en Blobs. Lamentablemente la única manera de hacerlo, incluso hoy en día, es mediante código. Es decir, no hay una manera desde el portal de Azure de establecerlas manualmente. Una pena y una dejadez por parte de Microsoft en mi opinión.

Sin embargo hay una manera rápida y sencilla de hacerlo utilizando una herramienta externa. Se trata de la indispensable Azure Storage Explorer, una app gratuita y multi-plataforma de la propia Microsoft, que permite gestionar de manera rápida y sencilla todo el almacenamiento que tenemos en Azure.

En esta herramienta, si navegas hasta tu Blob y pulsas sobre el botón de "Propiedades":

se abre un cuadro de diálogo en el que, entre otras cosas, te permite establecer algunas cabeceras comunes para el archivo. Ente ellas, por suerte, está la de la disposición del contenido, como podemos ver en esta figura:

En este caso le indico que sea un archivo para descarga y además le cambio el nombre original para que, por defecto, el que nos ofrezca en el cuadro de diálogo sea el que me interese.

También podemos cambiar otras cabeceras comunes como por ejemplo el tipo de caché que queremos que se haga del archivo, la codificación de éste, el idioma o incluso el tipo MIME que le queramos asociar (¡podríamos mentir!).

Gracias a esta herramienta podemos obtener un mayor control sobre el comportamiento de los archivos que almacenemos en Azure Blob Storage.

¡Espero que te sea útil!

 

Las 10 reglas de oro para escribir código de calidad

17/04/2018
Artículo original

Todos sabemos que escribir buen código es muchísimo más que conocer un lenguaje. Del mismo modo que saber hablar inglés no te convierte en Shakespeare, conocer C# o Java no te convierte en programador (y mucho menos en un Ingeniero de Software).

Que un programa resuelva un problema, que lo haga sin fallos y sin gastar más recursos de lo necesario, es el mínimo exigible. El "aprobado raspado", podría decirse.

Si se pretende alcanzar cotas de calidad más altas, el software debe tener muchas otras propiedades, más difíciles de ver a simple vista.

Un software excelente debe:

  • Ser fácilmente entendible
  • Ser extensible y reusable
  • Estar bien estructurado y testado
  • Facilitar el compartir conocimiento
  • Estar bien preparado para cambios futuros que no podemos prever.

¿Cómo se consigue todo eso?

Portada del libroCon este eBook gratuito...

Te presentamos el eBook "Las 10 reglas de oro para escribir código de calidad" que Iñaki Ayucar ha tenido a bien elaborar para nosotros.

Iñaki es un ingeniero informático muy experimentado que ha trabajado en toda clase de equipos, pequeños y grandes. Ha creado simuladores híper-realistas para marcas como Toyota o Bentley, y ha trabajado en desarrollo de juegos para Microsoft o Electronic Arts.

Y ahora ha reunido para ti en este eBook un decálogo de las reglas que en su opinión son las más importantes a la hora de construir software de calidad.

Puedes obtener este eBook gratuito en formato PDF (517KB) y descarga directa simplemente pulsando el siguiente enlace:

Descargar "Las 10 reglas de oro para escribir código de calidad" de Iñaki Ayucar

 Estamos seguros de que te resultará útil.

Y si tienes algún comentario, puedes hacerlo en el espacio de abajo, en esta página.

Análisis de la encuesta Stackoverflow 2018

16/04/2018
Artículo original

Stackoverflowsurvey2018

Stack Overflow es, sin duda, la mejor y más potente herramientas de difusión de información de desarrollo en todo el mundo. Junto con Google se ha convertido en un favorito imprescindible para encontrar la solución a, prácticamente, cualquier duda relacionada con código.

Y cada año hacen una mega encuesta entre sus millones de usuarios sobre múltiples aspectos de la industria del desarrollo, en la cual se pueden desprender interesantes y sorprendentes análisis.

El análisis de Stack Overflow

Stackoverflow

Como dice en la portada de los resultados, este 2018 se han ampliado los temas que se preguntan en la encuesta de 30 minutos que han realizado miles y miles de desarrolladores. Y sus conclusiones más importantes son:

  • DevOps y el aprendizaje automático son tendencias importantes en la industria del software actual. Los lenguajes y frameworks asociados con este tipo de trabajos van en aumento, y los desarrolladores que trabajan en estas áreas obtienen los salarios más altos.
  • Solo un pequeño porcentaje de desarrolladores declaran que escribirían código poco ético; o que no tienen la obligación de considerar las implicaciones éticas del código. Pero más allá de eso, los encuestados ven un montón de ética dudosa. Los desarrolladores no están seguros de cómo denuncia los problemas éticos, y tienen diferentes ideas sobre quién es el responsable final de este código.
  • Los desarrolladores son en general optimistas sobre las posibilidades que ofrece la inteligencia artificial, pero no están de acuerdo sobre cuáles son sus peligros.
  • Python ha aumentado en los rangos de lenguajes de programación en nuestra encuesta, superando C # en popularidad este año, al igual que superó a PHP el año pasado.
  • Al evaluar una oferta de trabajo, los diferentes tipos de desarrolladores aplican diferentes conjuntos de prioridades. Las mujeres declaran que sus mayores prioridades son: la cultura de la compañía y las oportunidades para el desarrollo profesional; mientras que los hombres dicen que sus mayores prioridades son la compensación económica y el trabajo con tecnologías específicas.

Poniendo las cosas en contexto

Idea Context

Primero, como en toda opinión o conclusiones de un análisis, dudemos de todo.

Hay cosas que llaman poderosamente la atención, como que el 93.1% de los participantes sean hombres, dejando la presencia de las mujeres en un raquítico 6.7%. Como menos malo podría señalar que las cifras mejoran un poquito (0,5%) en los estudiantes. Pero sin duda hay que empezar a tomarse muy en serio el hacer estudios de las causas de esta inmensa disparidad para tomar, si fuera necesario, las medidas más adecuadas.

Es decir, Stack overflow es un enorme campo de nabos, con casi siete excepciones por cada 100 desarrolladores. Lo que marca un sesgo importante a las conclusiones que se puedan obtener del análisis de los datos.

Luego hay una contradicción bastante llamativa. Los dos países con más profesionales son USA y la India. Si sumamos la norteamericana anglosajona más Europa, no llegamos ni al 50% de los encuestados; de hecho, solo la suma de todos los participantes en Asia supera el 30%. Sin embargo, el 75% de los desarrolladores se declaran blancos o descendientes de europeos, lo cual pudiera ser contradictorio o señalar un sesgo racista en cómo nos vemos a nosotros mismos.

Otra cosa que me ha “escamado”, supongo que será por el perfil de quien contesta a esta encuesta, es que un poco menos de la mitad de los Developers declaran contribuir a proyectos de Código Abierto, lo cual está a años luz de mi contexto en España.

Perfil del desarrollador medio

Developer

Los desarrolladores son jóvenes (de menos de 35 años), que conforman una semblanza de capa media alta; hijos de universitarios, y que a su vez también lo son; tan apasionados de su trabajo que lo consideran también como su hobbie principal; que curran entre 8 y 12 horas; y que no hacen ejercicio físico así les vaya la salud en ello.

Aun siendo universitarios, la autoformación es el modo más normal y generalizado de aprender una vez integrados al mundo laboral. Lo cual sucede de forma inmediata o casi inmediata en cuanto se ponen en el mercado.

Sin duda es un sector con pleno empleo, lo cual atrae a un 40% de intrusismo profesional. Es decir, tener una formación que no tiene nada que ver con programar.

Viendo la experiencia en programación de acuerdo con el tipo de puesto en la empresa, las cifras indican que la mayoría de los encuestados no superan el lustro programando. Pudiéndose inferir que, lo de ir escalando posiciones hacia puestos de gestión o coordinación, es un camino que sigue aplicando en todo el mundo.

Sobre lenguajes y tecnologías

Html5

Imbatible, el front end en general y el javascript en particular, han batido a todos sus competidores (por sexto año consecutivo). Python es quien más crece, desbancando a C# (que parece que está perdiendo fuelle), pero aún lejos de Java – quien lo ha visto y quien lo ve -o de SQL.

Mi sorpresa ha llegado al ver tan retrasado a TypeScript (tenía la sensación de que estaba usándose cada vez más) y más teniendo en cuenta que el 67% de los encuestados lo “amán”.

En la parte de librerías, Node.js sigue siendo el rey, seguido de la lucha entre Angular y React, que está ganando el primero, aunque con el aliento del segundo pegado al cogote. Y otro resultado inesperado llega con la entrada fuerte de .NET Core, ya que tenía la sensación de que se estaba adoptando poco en producción.

Sobre bases de datos cuatro apuntes. La excelente salud de MySQL luego de las dudas que se generaron sobre su futuro, la caída a los abismos de Oracle, el buen hacer de Microsoft con SQL Server que, siendo una BD relacional completa y compleja es la segunda preferida, y el crecimiento imparable de las BD en Cloud.

El gráfico de tecnologías conectadas muestra algo que tenemos que tener muy en cuenta al escoger la plataforma sobre la cual desarrollamos. Solamente la propuesta de Microsoft comprende Front-Back y Cloud bajo un mismo conjunto. Sin duda siguen siendo los listos de la clase que, a la chita callando, se han arrimado a las sombras de todas las tecnologías más utilizadas en la actualidad y las han adoptado en su stack tecnológico.

Como muestra, el surgimiento y reinado de Visual Studio Code, que ha desplazado a Sublime como entorno de desarrollo, de sistemas o DevOps. Vim, todavía aguanta en cabeza en estos dos últimos ámbitos, pero a duras penas. Amazon sigue siendo el rey de la Nube, pero Azure ya le ha comido la mitad del mercado, seguido del siempre presente Google.

Por último, sigue la contradicción entre el sistema operativo de la máquina de desarrollo, en donde se desarrolla y del objetivo de despliegue.

La mitad utilizan Windows, mientras que el 50% restante se lo reparten entre MacOS y Linux (en ese orden). Sin embargo, Linux se pone a la cabeza como plataforma de desarrollo preferida, seguida por un 35% de Windows y un mínimo de 18% sobre Mac OS.

Luego, en producción, statcounter marca que Android es el más utilizado para consumir aplicaciones informáticas, seguido muy de cerca por Windows, dejando a lo lejos a iOS, y Linux que tiene una presencia residual centrada, sobre todo, en servidores.

Tendencias de futuro

Developer Image C

Me ha gustado mucho el enfoque de Stack Overflow para detectar tendencias en el sector, que divide las respuestas en “Amado”, “Temido” y “Deseado”, haciendo una distinción “fuzzy” que muestra inclinaciones y sensaciones personales.

Rust y Kotlin son los lenguajes que más satisfacción dan a sus programadores. Mientras que Python se muestra como el lenguaje con las mejores perspectivas de futuro al ser el tercero en ser más “amado” y el primero en ser “deseado”.

Por el otro lado, el vetusto Visual Basic 6.0, es el más temido/odiado, junto a Cobol y a CoffeScript. Ante los tres me asombra el número de personas que aún desarrollan con ellos, y sin visos de cambiar a corto o medio plazo.

Parece que React puede ganar la competencia frente a Angular en el transcurso del año, ya que le supera tanto en satisfacción como en ganas de ser aprendido.

La Inteligencia Artificial aparece en la lista por medio de TensorFlow, construido en Python (otra vez), que se utiliza para Deep Learning y consigue el mayor nivel de “amor” de sus programadores.

Mercado laboral

Computer Man Code Web Development 650 062317060629

Las cifras nos cuentan que seguimos siendo una industria privilegiada, con pleno empleo y sueldos altos (aunque con grandes variaciones entre los USA y el resto del mundo); contratos indefinidos, pero teniendo la certeza de que no nos jubilaremos en la empresa donde estamos; satisfechos con nuestro trabajo, que es nuestra actividad de ocio principal; y con una alta tasa de emprendimiento, que está llenando el mercado de consultores profesionales liberales.

Y esto no tiene visos de cambiar durante lo que queda de esta década, viendo las enormes dificultades que se tiene en todo el mundo para encontrar y contratar programadores/desarrolladores, tengan talento o no.

Por otro lado, el crecimiento constante del número de lenguajes, librerías, herramientas, frameworks, tecnologías, etc., muestra una pendiente ascendente en el volumen de conocimiento e información necesario para ser un desarrollador productivo; que, además, no está siendo seguido con suficiente rapidez por los sistemas educativos; y que abocan a la autoformación y a la información colaborativa como los medios más validos para mantenerse en la cresta de la ola tecnológica que, cada vez, es más alta y empinada.

¿Tal vez estemos ante una burbuja y algún día explote?

Más información | Stack OverFlow Developer Survey Results 2018

En GenbetaDev | El perfil del desarrollador en España desde la visión de RRHH, De cómo las tripas de Stack Overflow aguantan el éxito, Encuesta Stack Overflow 2016 I, II y III

También te recomendamos

Fórmulas alternativas para compartir contenido en las principales redes sociales

De cómo las tripas de Stack Overflow aguantan el éxito

El desarrollo no es país para chicas... según la encuesta anual de Stack Overflow, por lo menos

-
La noticia Análisis de la encuesta Stackoverflow 2018 fue publicada originalmente en Genbeta Dev por Juan Quijano .

Análisis de la encuesta Starck Overflow 2018

16/04/2018
Artículo original

Stackoverflowsurvey2018

Stack Overflow es, sin duda, la mejor y más potente herramientas de difusión de información de desarrollo en todo el mundo. Junto con Google se ha convertido en un favorito imprescindible para encontrar la solución a, prácticamente, cualquier duda relacionada con código.

Y cada año hacen una mega encuesta entre sus millones de usuarios sobre múltiples aspectos de la industria del desarrollo, en la cual se pueden desprender interesantes y sorprendentes análisis.

El análisis de Stack Overflow

Stackoverflow

Como dice en la portada de los resultados, este 2018 se han ampliado los temas que se preguntan en la encuesta de 30 minutos que han realizado miles y miles de desarrolladores. Y sus conclusiones más importantes son:

  • DevOps y el aprendizaje automático son tendencias importantes en la industria del software actual. Los lenguajes y frameworks asociados con este tipo de trabajos van en aumento, y los desarrolladores que trabajan en estas áreas obtienen los salarios más altos.
  • Solo un pequeño porcentaje de desarrolladores declaran que escribirían código poco ético; o que no tienen la obligación de considerar las implicaciones éticas del código. Pero más allá de eso, los encuestados ven un montón de ética dudosa. Los desarrolladores no están seguros de cómo denuncia los problemas éticos, y tienen diferentes ideas sobre quién es el responsable final de este código.
  • Los desarrolladores son en general optimistas sobre las posibilidades que ofrece la inteligencia artificial, pero no están de acuerdo sobre cuáles son sus peligros.
  • Python ha aumentado en los rangos de lenguajes de programación en nuestra encuesta, superando C # en popularidad este año, al igual que superó a PHP el año pasado.
  • Al evaluar una oferta de trabajo, los diferentes tipos de desarrolladores aplican diferentes conjuntos de prioridades. Las mujeres declaran que sus mayores prioridades son: la cultura de la compañía y las oportunidades para el desarrollo profesional; mientras que los hombres dicen que sus mayores prioridades son la compensación económica y el trabajo con tecnologías específicas.

Poniendo las cosas en contexto

Idea Context

Primero, como en toda opinión o conclusiones de un análisis, dudemos de todo.

Hay cosas que llaman poderosamente la atención, como que el 93.1% de los participantes sean hombres, dejando la presencia de las mujeres en un raquítico 6.7%. Como menos malo podría señalar que las cifras mejoran un poquito (0,5%) en los estudiantes. Pero sin duda hay que empezar a tomarse muy en serio el hacer estudios de las causas de esta inmensa disparidad para tomar, si fuera necesario, las medidas más adecuadas.

Es decir, Stack overflow es un enorme campo de nabos, con casi siete excepciones por cada 100 desarrolladores. Lo que marca un sesgo importante a las conclusiones que se puedan obtener del análisis de los datos.

Luego hay una contradicción bastante llamativa. Los dos países con más profesionales son USA y la India. Si sumamos la norteamericana anglosajona más Europa, no llegamos ni al 50% de los encuestados; de hecho, solo la suma de todos los participantes en Asia supera el 30%. Sin embargo, el 75% de los desarrolladores se declaran blancos o descendientes de europeos, lo cual pudiera ser contradictorio o señalar un sesgo racista en cómo nos vemos a nosotros mismos.

Otra cosa que me ha “escamado”, supongo que será por el perfil de quien contesta a esta encuesta, es que un poco menos de la mitad de los Developers declaran contribuir a proyectos de Código Abierto, lo cual está a años luz de mi contexto en España.

Perfil del desarrollador medio

Developer

Los desarrolladores son jóvenes (de menos de 35 años), que conforman una semblanza de capa media alta; hijos de universitarios, y que a su vez también lo son; tan apasionados de su trabajo que lo consideran también como su hobbie principal; que curran entre 8 y 12 horas; y que no hacen ejercicio físico así les vaya la salud en ello.

Aun siendo universitarios, la autoformación es el modo más normal y generalizado de aprender una vez integrados al mundo laboral. Lo cual sucede de forma inmediata o casi inmediata en cuanto se ponen en el mercado.

Sin duda es un sector con pleno empleo, lo cual atrae a un 40% de intrusismo profesional. Es decir, tener una formación que no tiene nada que ver con programar.

Viendo la experiencia en programación de acuerdo con el tipo de puesto en la empresa, las cifras indican que la mayoría de los encuestados no superan el lustro programando. Pudiéndose inferir que, lo de ir escalando posiciones hacia puestos de gestión o coordinación, es un camino que sigue aplicando en todo el mundo.

Sobre lenguajes y tecnologías

Html5

Imbatible, el front end en general y el javascript en particular, han batido a todos sus competidores (por sexto año consecutivo). Python es quien más crece, desbancando a C# (que parece que está perdiendo fuelle), pero aún lejos de Java – quien lo ha visto y quien lo ve -o de SQL.

Mi sorpresa ha llegado al ver tan retrasado a TypeScript (tenía la sensación de que estaba usándose cada vez más) y más teniendo en cuenta que el 67% de los encuestados lo “amán”.

En la parte de librerías, Node.js sigue siendo el rey, seguido de la lucha entre Angular y React, que está ganando el primero, aunque con el aliento del segundo pegado al cogote. Y otro resultado inesperado llega con la entrada fuerte de .NET Core, ya que tenía la sensación de que se estaba adoptando poco en producción.

Sobre bases de datos cuatro apuntes. La excelente salud de MySQL luego de las dudas que se generaron sobre su futuro, la caída a los abismos de Oracle, el buen hacer de Microsoft con SQL Server que, siendo una BD relacional completa y compleja es la segunda preferida, y el crecimiento imparable de las BD en Cloud.

El gráfico de tecnologías conectadas muestra algo que tenemos que tener muy en cuenta al escoger la plataforma sobre la cual desarrollamos. Solamente la propuesta de Microsoft comprende Front-Back y Cloud bajo un mismo conjunto. Sin duda siguen siendo los listos de la clase que, a la chita callando, se han arrimado a las sombras de todas las tecnologías más utilizadas en la actualidad y las han adoptado en su stack tecnológico.

Como muestra, el surgimiento y reinado de Visual Studio Code, que ha desplazado a Sublime como entorno de desarrollo, de sistemas o DevOps. Vim, todavía aguanta en cabeza en estos dos últimos ámbitos, pero a duras penas. Amazon sigue siendo el rey de la Nube, pero Azure ya le ha comido la mitad del mercado, seguido del siempre presente Google.

Por último, sigue la contradicción entre el sistema operativo de la máquina de desarrollo, en donde se desarrolla y del objetivo de despliegue.

La mitad utilizan Windows, mientras que el 50% restante se lo reparten entre MacOS y Linux (en ese orden). Sin embargo, Linux se pone a la cabeza como plataforma de desarrollo preferida, seguida por un 35% de Windows y un mínimo de 18% sobre Mac OS.

Luego, en producción, statcounter marca que Android es el más utilizado para consumir aplicaciones informáticas, seguido muy de cerca por Windows, dejando a lo lejos a iOS, y Linux que tiene una presencia residual centrada, sobre todo, en servidores.

Tendencias de futuro

Developer Image C

Me ha gustado mucho el enfoque de Stack Overflow para detectar tendencias en el sector, que divide las respuestas en “Amado”, “Temido” y “Deseado”, haciendo una distinción “fuzzy” que muestra inclinaciones y sensaciones personales.

Rust y Kotlin son los lenguajes que más satisfacción dan a sus programadores. Mientras que Python se muestra como el lenguaje con las mejores perspectivas de futuro al ser el tercero en ser más “amado” y el primero en ser “deseado”.

Por el otro lado, el vetusto Visual Basic 6.0, es el más temido/odiado, junto a Cobol y a CoffeScript. Ante los tres me asombra el número de personas que aún desarrollan con ellos, y sin visos de cambiar a corto o medio plazo.

Parece que React puede ganar la competencia frente a Angular en el transcurso del año, ya que le supera tanto en satisfacción como en ganas de ser aprendido.

La Inteligencia Artificial aparece en la lista por medio de TensorFlow, construido en Python (otra vez), que se utiliza para Deep Learning y consigue el mayor nivel de “amor” de sus programadores.

Mercado laboral

Computer Man Code Web Development 650 062317060629

Las cifras nos cuentan que seguimos siendo una industria privilegiada, con pleno empleo y sueldos altos (aunque con grandes variaciones entre los USA y el resto del mundo); contratos indefinidos, pero teniendo la certeza de que no nos jubilaremos en la empresa donde estamos; satisfechos con nuestro trabajo, que es nuestra actividad de ocio principal; y con una alta tasa de emprendimiento, que está llenando el mercado de consultores profesionales liberales.

Y esto no tiene visos de cambiar durante lo que queda de esta década, viendo las enormes dificultades que se tiene en todo el mundo para encontrar y contratar programadores/desarrolladores, tengan talento o no.

Por otro lado, el crecimiento constante del número de lenguajes, librerías, herramientas, frameworks, tecnologías, etc., muestra una pendiente ascendente en el volumen de conocimiento e información necesario para ser un desarrollador productivo; que, además, no está siendo seguido con suficiente rapidez por los sistemas educativos; y que abocan a la autoformación y a la información colaborativa como los medios más validos para mantenerse en la cresta de la ola tecnológica que, cada vez, es más alta y empinada.

¿Tal vez estemos ante una burbuja y algún día explote?

Más información | Stack OverFlow Developer Survey Results 2018

En GenbetaDev | El perfil del desarrollador en España desde la visión de RRHH, De cómo las tripas de Stack Overflow aguantan el éxito, Encuesta Stack Overflow 2016 I, II y III

También te recomendamos

Fórmulas alternativas para compartir contenido en las principales redes sociales

El desarrollo no es país para chicas... según la encuesta anual de Stack Overflow, por lo menos

De cómo las tripas de Stack Overflow aguantan el éxito

-
La noticia Análisis de la encuesta Starck Overflow 2018 fue publicada originalmente en Genbeta Dev por Juan Quijano .

Los grandes bulos sobre tecnología

13/04/2018
Artículo original

Imagen ornamental de carteles antiguos de fenómenos de circo

Los bulos, los falsos mitos, las leyendas urbanas y las noticias falsas siempre han existido. Ya sean fruto del delirio, la divagación o los malentendidos, de mentes imaginativas o personas malintencionadas, o simplemente de la ignorancia, lo cierto es que desde el origen de la civilización humana siempre han circulado falsos rumores . Al ser humano le gustan las fábulas, y aún más confabular.

Antes de la era Internet los bulos se propagaban con mucha más lentitud. Pronto los medios de comunicación de masas se apuntaron al carro de la difusión de bulos en días señalados como el April's Fools Day en el mundo anglosajón (el 1 de abril) o el Día de los Santos Inocentes en España e Hispanoamérica (28 de diciembre).

Hoy en día por Internet circulan todo tipo de patrañas, falsas noticias y leyendas que en algunos casos tienen un fin malintencionado y que pueden manipular la opinión pública hasta el punto de distorsionar la realidad y causar resultados imprevistos en momentos decisivos como las elecciones o en la gestión de crisis de orden público, catástrofes naturales, etc... De hecho la situación es tan preocupante que han aparecido medios de comunicación que tienen como objeto desmentir los bulos que se generan con la intención de manipular a las personas.

El mundo tecnológico del software y el hardware tampoco está libre de patrañas. Existen bulos de todo tipo: historias falsas sobre empresas tecnológicas, leyendas urbanas sobre diferentes productos, falsos mitos sobre cómo hay que operar con una cierta tecnología para estar más seguros o para que los dispositivos duren más o rindan mejor, etc...

A continuación hemos recopilado algunos de los grandes bulos relacionados con el mundo de la tecnología. Seguro que hay más de uno que has escuchado antes. Si sabes o se te ocurre algún otro, no dudes en ponerlo en los comentarios.

El primer gran bulo de Internet

Este es uno de los primeros bulos en los albores de Internet, que se propagó en forma de email en cadena. Corría el año 1994 y saltó lo que hoy en día se conoce como el bulo de la adquisición de Microsoft. Una nota de prensa fraudulenta, supuestamente de la agencia Associated Press, afirmaba que Microsoft "adquiriría la Iglesia Católica Romana a cambio de un número indeterminado de acciones de la compañía", y que el gigante del software esperaba "un crecimiento exponencial en el mercado religioso en los próximos cinco a diez años...". Por otro lado el comunicado argumentaba que "que la combinación de los recursos de Microsoft y la Iglesia católica nos permitirán hacer de la religión algo más fácil, ameno y más divertido para una gama más amplia de personas".

Evidentemente muchas de las afirmaciones del comunicado de prensa no eran verosímiles, desde sugerir que los católicos pronto serían capaces de tomar la Sagrada Comunión a través del ordenador hasta afirmar que la conversión al catolicismo era un upgrade. A pesar de estas claras señales de advertencia en forma de falacia sobre la imposibilidad de la noticia, fueron varios lectores de dicha nota de prensa los que se pusieron en contacto con Microsoft para contrastar si era ciertas las afirmaciones de la broma, y el 16 de diciembre de 1994, Microsoft formalmente salió a negar la información difundida en la nota.

A pesar de la proliferación de los correos electrónicos en cadena que circulaban en Internet en aquella época (y que sigue siendo habitual en nuestros días, especialmente por aplicaciones de mensajería instantánea, y si no revisa los mensajes de tus padres), el bulo de la adquisición de Microsoft es considerado el primer gran engaño en alcanzar a una audiencia masiva a través de Internet.

Bulos relacionados con hardware, software y la programación

A continuación repasaremos una miscelánea de leyendas urbanas que están relacionadas con el mundo del hardware, el software y la tecnología en general.

Los informáticos y los ingenieros lo saben todo sobre ordenadores

El concepto de ordenador es un término muy amplio que se usa para muchos dispositivos y cuya definición más básica es: algo que puede aceptar una entrada, procesarla y darle salida.

Esta definición efectivamente incluye cualquier cosa, desde una calculadora hasta supercomputadores muy avanzados. La aviónica, la electrónica de coches, smartphones, satélites, etc. pueden ser todos considerados como dispositivos electrónicos.

No se puede esperar que un ingeniero informático o científico lo sepa todo acerca de esta amplia gama de productos, especialmente porque las personas que trabajan en las TIC tienden a especializarse en campos muy específicos. Esto seguro que es una obviedad para ti, pero no lo es tanto para mucha gente. Y seguro que lo has sufrido ;-)

Los ordenadores portátiles de Apple son mejores para la programación / Los Macs son mejores que los PCs:

No nos engañemos, los Macs son muy molones, y a muchos programadores nos encanta portarlos porque son tendencia. Hemos asociado el precio más alto de Mac al hecho de que por eso tienen más calidad. Sin embargo, no hay datos objetivos que respaldan el hecho de que un MacBook de Apple es mejor para la programación, y no vale sacar el argumento de que los Mac no tienen virus, ya que esa es otra leyenda urbana. Definitivamente, hay Macs que son mejores que algunos PCs pero también se da el caso contrario... ¡Anatamea, anatema!

Para un desarrollador emprender es más fácil

Otra idea falsa que circula en el imaginario colectivo es la creencia de que para los perfiles tecnológicos es más fácil emprender y abrir un negocio. A ver, es cierto que como programadores podemos implementar casi cualquier idea que nos venga a la cabeza sin necesitar a nadie a la hora de hacer un software. Pero una empresa de software no es solo software. Para arrancar un negocio sostenible en el tiempo se necesita mucho más. Tienes que ser igual de bueno en facetas como la organización, la gerencia, los procedimientos, las ventas (especialmente), y todos los otros términos que implica tener una empresa.

La inteligencia artificial nos traerá el apocalipsis

Es innegable que la inteligencia artificial se va a cargar algunos puestos de trabajo y hará tareas que hoy en día aún hacen las personas, el futuro apocalíptico que muchos predicen cuando se habla de la revolución de la inteligencia artificial es irresponsable y errado. Es algo más bien fruto de una película de ciencia ficción que otra cosa. El debate se centra en la regulación y la legislación, y ya ha habido alguna que otra guerra de egos por el tema.

La navegación privada/incógnito te mantiene anónimo

Existe una idea equivocada y generalizada de que navegar en modo "incógnito" o "privado" son sinónimos de permanecer anónimo. Si usas el modo incógnito en Google Chrome o la navegación privada en Safari, simplemente significa que el navegador no va a hacer un seguimiento de tu historial, ni importar tus marcadores, o iniciar sesión automáticamente en cualquiera de tus cuentas.

Básicamente, solo sirve para que las otras personas que utilizan tu ordenador no puedan ver lo que has estado haciendo. Pero no mantendrá tu identidad oculta de los sitios que visitas o de tu proveedor de servicios de Internet, así que tenlo en cuenta si estás visitando sitios que no deberías.

Vaciar la papelera de reciclaje elimina permanentemente los archivos

Tendría sentido que eliminar un archivo realmente lo eliminara. Pero cuando se vacía la papelera de reciclaje (Windows) o papelera (Mac), los datos no se borran, sólo se eliminan los "punteros" a los archivos completos. Un equipo al que se le ha dicho que elimine un archivo no lo eliminará, y en verdad lo que hace es desasignar el espacio que ocupa en el disco duro, abriendo ese espacio para que se escriba algo nuevo sobre él. Eso significa que aún quedan pedacitos de información dispersos, y cualquier hacker podría juntarlos para reconstruir lo que creías que había desaparecido para siempre. De hecho hay muchos programas de recuperación de archivos precisamente por eso.

Para eliminar archivos de forma definitiva y permanente, tienes indicarle al ordenador para vaya un paso más allá de simplemente vaciar la papelera de reciclaje. En un Mac, elige "Secure Empty Trash"; en un PC, tienes que utilizar un programa externo para ello. Uno muy conocido y utilizado es SDelete. Se trata de un programa gratuito que te permite borrar totalmente cualquier espacio libre o sólo archivos específicos usando la línea de comandos.

De todo esto se saca una ventaja: si accidentalmente eliminas algo y tienes que recuperarlo, en teoría, puedes.

Dejar el teléfono enchufado destruye la batería

Si eres como la mayoría de las personas, probablemente dejes tu teléfono enchufado durante toda la noche y queda ahí incluso después de que la batería esté completamente cargada.

Se solía decir que esto dañaría la vida de la batería de tu teléfono, pero de hecho, no hay ninguna prueba de que esto dañe la batería de tu teléfono de ninguna manera. Los smartphones modernos funcionan con baterías de iones de litio, que son lo suficientemente inteligentes como para dejar de cargarse cuando han alcanzado la capacidad de carga completa. De esto ya hemos hablado extensamente en otra ocasión.

Más megapíxeles siempre significa una mejor cámara

¿Cuál es la diferencia entre las cámaras de 12 megapíxeles y las cámaras de 8 megapíxeles? Pues en realidad no hay mucha. La calidad de una imagen se determina en gran parte por la cantidad de luz que el sensor es capaz de captar. Los sensores más grandes pueden venir con píxeles más grandes, y cuanto más grande es el píxel más luz puede absorber.

Por lo tanto, lo que realmente determina la calidad de una cámara es el tamaño de los píxeles más que el mero número de píxeles (un megapixel es simplemente una forma corta de decir un millón de pixeles).

Una mayor resolución de pantalla siempre es mejor en un smartphone

Muchos han argumentado que a partir de cierta magnitud, una mayor resolución de pantalla no importa en un smartphone. En su día, expertos de Apple, entre otros, afirmaron que el ojo humano no puede discernir más detalles cuando una pantalla empaca más de 300 píxeles por pulgada. A principios de 2017, LG reveló su primer smartphone Quad-HD, el G3, que tiene una resolución de 2560 x 1440. Eso es mucho más alto que el smartphone de gama alta medio, que por lo general viene con una resolución de pantalla de 1920 x 1080.

Pero no está claro si esos números realmente importan después de cierto punto, porque el ojo no puede discernir píxeles individuales más allá de cierta resolución...

Más barras de señal garantizan un gran servicio móvil

Aunque tener más barras ayuda a tener mejor servicio, no necesariamente garantiza una excelente recepción. Las barras sólo indican lo cerca que está de la torre celular más cercana. Pero existen otros factores que influyen en la rapidez con la que funciona internet en el teléfono, como el número de personas están utilizando la red de forma simultánea. Por eso cuando estás en un concierto o en un evento deportivo de masas puedes quedarte por momentos sin servicio a pesar de estar a tope de cobertura.

Cuánto más nuevo, mejor

Este bulo es muy común, pero si trabajas en el sector sabes que una tecnología más reciente no es mejor por el simple hecho de ser nueva. De hecho, muchas veces lo nuevo puede ser un fiasco absoluto.

Un ejemplo puede ser Windows 8 que tenía tantos errores que fue reemplazado rápidamente por Windows 8,1 y, posteriormente, Windows 10.

Antes del lanzamiento de Windows 8, muchos usaban Windows 7 (que es anterior) sin quejas ni muchos problemas. De hecho se sigue viendo mucho Windows 7 por ahí. La tecnología cuando es nueva necesita un tiempo para madurar, corregir errores y mejorar la experiencia del usuario. Es una de las razones por las que los equipos militares no se actualizan cada vez que surge algo nuevo :)

Conclusión

Hemos dejado muchas otras falsas creencias relacionadas con la tecnología, como la de que Windows es malo, o que el software de código abierto es gratis/barato, o que el software es testado en profundidad antes de ser lanzado, o que todas las actualizaciones son por temas técnicos y no por marketing/imagen, la lista tiende a infinito.

Si se te ocurre alguno y quieres compartirlo, no dudes en hacerlo en la zona de comentarios.

RGPD / GDPR: guía práctica de protección de datos para programadores

10/04/2018
Artículo original

Está a punto de cumplirse el plazo de adaptación al nuevo Reglamento de privacidad aprobado por la Unión Europea en mayo de 2016. Es decir, hemos tenido dos años para adaptarnos a las nuevas obligaciones, aunque hay quien parece que aún no se ha enterado, quizás porque cree que no va con él. Esta nueva legislación, conocida como GPDR (o RGPD en español) es mucho más dura que las pre-existentes, y no solo afecta a las empresas europeas, sino a cualquier empresa del mundo que quiera hacer negocios en Europa y con ciudadanos europeos.

Con la nueva legislación los programadores jugamos un papel realmente importante ya que de acuerdo al nuevo Reglamento debemos ser muy diligentes en cuanto a los datos que gestionan nuestras aplicaciones, cómo los recogemos, qué hacemos con ellos y las medidas de seguridad que aplicamos durante el desarrollo, el despliegue y el mantenimiento. 

En este artículo vamos a ver cómo afecta el nuevo Reglamento a todo aquél que se dedique al desarrollo.

Importante: esta información se ofrece como una guía práctica para ayudarte, pero no constituye a un asesoramiento legal ni sirve como sustituto para tal.

Cambios en la Ley de Protección de Datos

El 25 de mayo de 2018 empezará a aplicarse el nuevo reglamento de protección de datos que entró en vigor hace dos años.

El nuevo Reglamento General de Protección de Datos (RGPD a partir de ahora) será muy positivo no solo para los usuarios (estaremos más protegidos) sino que también para los desarrolladores, pues mejorará nuestros procesos y flujos de trabajo. Nos obliga a todos a reflexionar más sobre qué datos recopilamos, cómo los recopilamos y qué hacemos con ellos. Aunque la obligación de informar a los interesados cuando se van a recabar, usar o almacenar datos personales ya estaba recogida en la Directiva 95/46/CE (Directiva de la que emana la actual LOPD), el nuevo RGPD concede una mayor importancia a la información que se debe proporcionar a los ciudadanos cuyos datos van a tratarse, y contempla una lista exhaustiva de los contenidos que deben ser expuestos.

Pero no debemos asustarnos, ni siquiera tendremos que consultar necesariamente a un abogado para averiguar las obligaciones que debemos cumplir ya que son de sentido común. Dichos cambios pueden resultar tediosos pero la buena noticia es que técnicamente son sencillos.

A continuación vamos a centrarnos en los problemas específicos que se encontraría un programador web a la hora de adaptar su flujo de trabajo al nuevo Reglamento. Insistimos en que en este artículo no se trata de hacer una revisión minuciosa de TODO el Reglamento, solo de dar unas orientaciones generales.

¿Qué se consideran datos personales?

Antes de entrar en materia, quizás sea importante aclarar qué considera el nuevo Reglamento un dato personal. (Si esto lo tienes claro pasa al siguiente punto). Según el nuevo marco europeo:

Artículo 4: Toda información sobre una persona física identificada o identificable. Se considerará persona física identificable a toda persona cuya identidad pueda determinarse, directa o indirectamente, en particular mediante un identificador, como por ejemplo un nombre, un número de identificación, datos de localización, un identificador en línea o uno o varios elementos propios de la identidad física, fisiológica, genética, psíquica, económica, cultural o social de dicha persona.

Esta definición es muy importante para los desarrolladores, puesto que nos está diciendo que entre los datos personales se incluye por ejemplo: la dirección IP, el identificador de un dispositivo móvil, el identificador de los navegadores, las etiquetas RFID, las cookies, la telemetría... Y por supuesto, las identificaciones de las cuentas de usuario, y cualquier otra forma de datos generados por el sistema que identifique a una persona física.

¿A quién le afecta este Reglamento?

Las normas europeas de protección de datos, son y siempre han sido, extraterritoriales. Es decir, aplican a todos los datos personales recopilados, procesados y retenidos sobre personas dentro de la Unión Europea, independientemente de su nacionalidad. O sea, que si tú haces negocios en Europa da igual que físicamente tu domicilio social esté en la Conchinchina, tu empresa está obligada a cumplir con la normativa europea.

El tamaño aquí tampoco importa, el reglamento aplica a todo tipo de empresas u organizaciones, públicas y privadas. Así que todos aquellos que levantamos este país (autónomos y pymes) debemos también cumplirlo aunque a nuestro favor está el que debemos hacer menos papeleo ?.

Con objeto de tener en cuenta la situación específica de las microempresas y las pequeñas y medianas empresas, el presente Reglamento incluye una serie de excepciones en materia de llevanza de registros para organizaciones con menos de 250 empleados.

¿Debes cambiar tu forma de trabajar?

Independientemente del lenguaje de programación que utilices en tu día a día o del tipo de aplicaciones que desarrolles, el RGPD te exigirá mayor transparencia a la hora de hacer las cosas y quizás una estructura definida. Esto, que a priori puede parecer un tanto engorroso, verás que se trata de requerimientos de sentido común.

A continuación veremos cómo el RGPD impactará sobre tu trabajo.

UN POCO DE SENTIDO COMÚN

La creación de flujos de trabajo de protección de datos, la captura innecesaria de datos o la pérdida de los mismos, requieren que todos los integrantes de un mismo proyecto trabajen a partir de un conjunto claramente definido de bibliotecas, herramientas y frameworks. Por esa razón, uno de las primeras cosas que debemos hacer para cumplir con el RGPD es crear una lista de estándares aprobados y metodologías utilizadas tanto para programación como para pruebas.

Evidentemente el RGPD no define una lista con los lenguajes de programación que debemos usar, ni con los sistemas de control de versiones o herramientas de testeo. Lo que realmente importa es que lo que usemos esté claramente definido y exista una trazabilidad para cada situación. Es obvio que somos libres de modificar las herramientas que usamos en cualquier momento; ahora bien, debemos asegurarnos de que las vamos a sustituir por otras que están perfectamente definidas y que son válidas para ser usadas en el framework en el que estamos trabajando. (Vamos, un poco de sentido común).

Por último, no debemos olvidarnos de la parte de la seguridad donde lo mejor es siempre tener una actitud preventiva. Por lo tanto lo primero que debemos hacer es desactivar todo aquello que no nos haga falta: plugins que no usemos o bibliotecas de terceras personas que no hayan sido probadas. A continuación debemos definir en qué consiste una auditoría de seguridad en relación a la privacidad. Esta incluiría por ejemplo un análisis de los datos personales que se capturan (¿son todos ellos necesarios?), dónde se guardan, cómo se protegen, etc. así como la existencia de vulnerabilidades de seguridad.

REQUERIMIENTOS DE DISEÑO

A la hora de diseñar un proceso de protección de datos el Reglamento nos dice literalmente:

Los datos personales deben ser adecuados, pertinentes y limitados a lo necesario para los fines para los que sean tratados.

Lo cual se traduce en:

  • Minimización de datos: recoge solo los datos que necesites.
  • No vincules datos personales con otros conjuntos de datos almacenados en una sola ubicación. Si agregas datos, elimina todos los datos personales y de identificación que sea posible.
  • Limitación del plazo de conservación de datos: el RGPD exige que se defina el plazo durante el cual trataremos los datos que hemos recabado para un fin determinado. Una vez superado dicho plazo, esos datos deben ser eliminados, a excepción de aquellos que sea necesario guardar por motivos, por ejemplo, legales. Eso es perfectamente aceptable, siempre que se documente ese hecho y su fundamento. Así por ejemplo, la solicitud de un usuario de eliminar sus datos no implicaría (por muy cabezota que se ponga) borrar sus registros de compras junto con sus registros impositivos y contables

Y es que, el derecho al olvido no debe confundirse con el derecho a estar “al margen” de la ley.

A la hora de eliminar los datos personales comprobaremos si en su momento hemos definido correctamente los flujos de trabajo. Imagina que quieres eliminar los datos personales de un usuario (no hay motivos legales para mantener nada sobre el mismo); al terminar, ¿eres capaz de responder de forma afirmativa las siguientes preguntas?:

  • ¿Estás completamente seguro de que no queda ningún dato personal del usuario en los archivos de la empresa?
  • ¿Seguro? ¿Lo has borrado de la base de datos que usó el becario para hacer pruebas en pre-producción?
  • ¿Lo has borrado de los backs-up? Ajá, sí también de ahí lo tienes que borrar.
  • ¿Ha habido transferencia de datos a terceros? (Por ej. cuando contratasteis aquella campaña de Marketing a una agencia externa) ¿Les habéis pedido que eliminen sus datos? ¿Has verificado que lo han hecho?

Otro aspecto fundamental a la hora de diseñar un sistema de protección de datos es la definición de los permisos, ¿quién tiene acceso a qué dentro de la empresa? y también el cifrado de datos, los datos se deben cifrar en tránsito y en reposo (esto último es muy importante y debes verificar que tus almacenes de datos lo soportan).

CONSENTIMIENTO LIBRE Y MECANISMOS DE ACCESO A LOS DATOS

El RGPD pretende devolver al individuo el control total sobre sus datos personales usando para ellos mecanismos de acceso y consentimiento.

Esto es muy importante: cuando el tratamiento se base en el consentimiento del interesado, el responsable deberá ser capaz de demostrar que aquel consintió el tratamiento de sus datos personales.

El consentimiento debe ser inequívoco y explícito

Es decir, siempre va a recaer en ti el demostrar que el usuario te ha dado su permiso. Por lo tanto, si aún no lo has hecho, revisa todos tus procedimientos de toma de datos y comprueba que en todos ellos el usuario acepta libremente la cesión de sus datos. (Por ejemplo, no puede estar marcado por defecto el botón de aceptación de la Política de privacidad de tu web).

El proceso de desarrollo de tu back-end también deberá garantizar la documentación con una marca de tiempo sobre el tipo de consentimiento que dio el usuario, cómo lo dio y si lo retiró o no.

Facilitar a los interesados el ejercicio de sus derechos

El RGPD contiene los ya tradicionales derechos ARCO y también algunos nuevos derechos. Además, establece condiciones concretas sobre el procedimiento a seguir para atender a los interesados en el ejercicio de sus derechos.

En lo que a los procedimientos se refiere, estos deben ser visibles, accesibles y sencillos. Un ejemplo sería una interfaz segura donde el interesado pudiera ejercer sus derechos de acceso, como la edición y corrección de la información, el derecho a descargar sus datos, el derecho a restringir el uso de sus datos o el derecho a la eliminación de los mismos. La zona de configuración de las cuentas o los paneles de privacidad son los sitios idóneos donde incluir estas opciones.

TESTING Y MANTENIMIENTO

Por último, programar teniendo en mente el RGPD significa incluir la protección de datos por defecto a la hora de diseñar nuestros procesos.

Los procedimientos de seguridad deben predecir las formas en que los usuarios no autorizados accederían a los datos reales en nuestro sistema. Por ejemplo: ¿se registraría una búsqueda sospechosa de datos de usuario, o una modificación de un registro, como una vulnerabilidad de seguridad? ¿Los datos están almacenados en las cookies de inicio de sesión? ¿Podría alguien obtener acceso a los datos activando intencionalmente un error? ¿Has probado qué fácil es acceder a los datos heredados? Aquí es donde debemos pensar de forma creativa, y algo malintencionada, sobre cómo y dónde los datos pueden caer en manos inadecuadas. Esto, nuevamente, es sentido común pero, no hacerlo, ahora tiene consecuencias legales, además de en el negocio.

Las pruebas de protección de datos por defecto también deberían considerar las alertas externas. ¿Disponemos de algún medio para que alguien externo nos avise sobre infracciones de datos, ya sean potenciales o reales?

Y recuerda la regla de oro del RGPD: do-cu-men-tar-lo.

En resumen

En este artículo hemos visto cómo el RGPD nos exige que tengamos más cuidado con los sitios, servicios y aplicaciones que creamos, mayor transparencia a la hora de recopilar y utilizar los datos, que seamos más considerados con nuestros usuarios y más exhaustivos en nuestros procesos de desarrollo y documentación.

Como has podido ver ninguno de los puntos mencionados te resulta ajeno a tu día a día, por lo que si no quieres que te pille el toro, ya puedes empezar con todo esto inmediatamente y si te atascas, existen cientos de empresas/ consultores expertos en la materia deseando ayudarte.

Y ten en cuenta que las posibles multas que pueden caer a tu empresa no son para tomárselas a broma ?

GAMBADAS: La culpa siempre es del programador... O eso dicen... Una historia de blockchain.

06/04/2018
Artículo original

El pasado mes de marzo la empresa catalana (bueno con sede en Londres y que opera en Barcelona y Gibraltar :S) PayPro “perdió” 450.000€ en una emisión de criptomoneda. Hemos puesto perdió entre comillas, pues realmente no saben dónde está el dinero y según ellos la culpa es del programador.

Un poco de historia…

PayPro , creada en 2015, era una herramienta online  que permitía a las pymes realizar pagos en más de 30 divisas y a más de 200 países, ahorrando hasta el 90% en las comisiones ocultas que aplican los bancos sobre el tipo de cambio. Desde entonces han cerrado dos rondas de financiación de 42 inversores, entre los que se incluyen Wayra - Telefónica, Lanta Capital e IDODI Venture Capital.

En 2017 decidieron cambiar de tercio y crear una plataforma que ofreciera una alternativa a la banca tradicional. A día de hoy PayPro es un marketplace financiero donde cualquier aplicación construida sobre blockchain puede ofrecer sus servicios.

Definiciones

Blockchain: es un sistema de seguridad formado por bloques alojados en una base de datos compartida. Su fortaleza reside en que la cadena de bloques está descentralizada, es decir, para introducir un virus y robar información, habría que infectar, uno a uno, todos los ordenadores conectados a la base de datos.

Ether: es una criptomoneda (existen más de 700 divisas virtuales actualmente, siendo la más conocida Bitcoin). A diferencia de otras criptomonedas, ether está ligado a una plataforma llamada Ethereum y sólo puede ser utilizado dentro de ella.

ICO (Initial Coin Offer - oferta inicial de monedas): una ICO es una forma de financiamiento colectivo, es decir, un emprendedor anuncia su idea, crea una criptomoneda y la vende para conseguir el dinero con el que hará realidad su negocio. La ventaja para las startups es que, a diferencia de las rondas de financiación, quien le compre sus monedas no recibirá a cambio acciones de la futura empresa. En un futuro, si la compañía logra arrancar, el inversor podrá canjear su moneda virtual por dinero de verdad.

Smart contract: un contrato inteligente hace referencia a un contrato que se ejecuta por sí mismo sin que intermedien terceros y se escribe como un programa informático en lugar de utilizar un documento impreso con lenguaje legal.

¿Qué hizo la gente de PayPro?

PayPro pretendía crear un banco descentralizado basado en blockchain y para ello:

  • Subcontrató a una empresa externa que llevó a cabo todo el desarrollo tecnológico: es decir la programación de los smart contracts con los cuales se emiten las criptodivisas.
  • Tras el desarrollo, también contrató a un auditor acreditado por Consensys quien dio el visto bueno y no encontró ningún error.
  • PayPro hizo pruebas antes de hacer pública la ICO y el informe obtenido no arrojó ningún tipo de error.
  • Lanzó una ICO para recaudar dinero con la que consiguieron 1.000 etheres (unos 450.000€).
  • A la hora de desplegar el código olvidaron entrecomillar la dirección de Etherum y JavaScript lo interpretó de otra manera (¡Ah!, JavaScript y sus "cosillas"). Y lo que ha pasado es que se ha enviado el dinero a una clave pública que no existe y que, por tanto, no tienen la clave privada con la que acceder. ¡Vamos que si fuera dinero en papel es como haberle prendido fuego, irrecuperable!

¿Y ahora qué?

Pues la gente de PayPro dice que la culpa es del programador y del auditor, del primero porque le dio mal las instrucciones (se ve que no le dijo nada de las comillas), y del segundo porque no vio el error. Por otro lado el código no tenía ningún error formal, así que la aplicación está bien y el auditor tampoco vió errores, pero el despliegue (en el que se olvidaron de poner las comillas) lo hicieron ellos mismos, los de PayPro. Al parecer tampoco hicieron pruebas con esa dirección antes de lanzarlo, para ver si se recibía el dinero y a dónde iba. Pero quizá la empresa desarrolladore debería haber hecho hincapié en que las comillas eran indispensables en esa dirección. Buff!!  ¿De quién es la culpa?

Esta semana ha saltado la noticia de todo el fiasco, y al parecer han enviado un email a todos los inversores afectados que incluye dos formularios, uno para que se sumen a la demanda contra los presuntos culpables, y el otro para recaudar más dinero y seguir con el proyecto. ¡Qué corra la alegría!

Y tú, ¿qué opinas? ¿quién tiene que pagar la fiesta fallida?

Formatos de vídeo para Internet: MP4 y sus variantes, MP4/H.264 y MP4/MPEG-4 - Diferencias y similitudes

04/04/2018
Artículo original

Los vídeos que reproducimos en Internet o bien de manera local en el ordenador o en cualquier otro dispositivo, pueden estar codificados de diferentes maneras. Cada método de codificarlos implica unas ventajas e inconvenientes, y existen formatos mejores que otros dependiendo del uso que queramos darle al vídeo. Así, tenemos formatos como AVI, MP4, MKV, 3GP, WebM de Google, etc...

A la hora de reproducir vídeo en la Web, usando un navegador, el formato más extendido y con mejor soporte por parte de los navegadores, tanto móviles como de escritorio, es el formato MP4, y para ser más exactos, el formato MP4/H.264, que se corresponde con archivos que normalmente llevan la extensión .mp4. Pero:

  • ¿Son iguales todos los archivos .mp4?
  • Si no son iguales, ¿qué tipos hay? ¿cuáles son las diferencias, ventajas e inconvenientes de cada uno?
  • ¿Valen todos para la Web?

¡Vamos a verlo!

El formato MP4 - Partes, contenedores y extensiones

Cuando hablamos de un archivo .mp4 o del formato MP4 en general, de lo que estamos hablando es de lo que se conoce técnicamente como MPEG-4 Parte 14. Se trata de un formato estándar (ISO/IEC 14496-14) y es un formato contenedor de pistas multimedia. Es decir, este formato define cómo se pueden contener en el archivo las pistas de audio y de vídeo (llamados data streams) en diversos formatos, y puede incluso contener subtítulos también.

Dentro de este formato contenedor, dentro del archivo .mp4, las pistas de audio y vídeo pueden estar codificadas en diversos formatos, según convenga para la aplicación que se le va a dar. Aunque en teoría soporta muchísimos formatos diferentes (casi cualquiera) para estas pistas de audio y vídeo, en la práctica los reproductores de este formato soportan solamente algunos tipos concretos, siendo los más frecuentes:

  • Audio: AAC (Advanced Audio Codec, que cuando van sueltos son archivos con extensiones .m4a o .3gp), o el formato MP3.
  • Vídeo: las distintas variantes del formato MPEG.

MPEG o Moving Picture Experts Group es un grupo de "autoridades" y fabricantes en el campo del audio y el vídeo que se juntaron a petición de ISO a finales de los 80 para crear estándares de codificación de archivos para este tipo de información multimedia, y así garantizar una compatibilidad entre medios a reproducir y dispositivos reproductores. La primera versión del estándar, MPEG-1 salió en 1993, y desde entonces han habido muchas nuevas versiones, y dentro de éstas lo que ellos denominan "Partes", que son aspectos concretos del estándar y también extensiones a la especificación para cosas concretas, o mejoras del formato base que modifican.

La versión más extendida de este formato MPEG es la 4, o MPEG-4, aparecida a finales de 1998, y es lo que conocemos como MP4, por la extensión de sus archivos. Esta versión se divide en varios subestándares o "Partes" que describen cuestiones determinadas del formato (por ejemplo, la 14 el contenedor, como ya he dicho al principio) y ciertas extensiones.

Dentro de las partes del estándar, la parte 10 describe un formato avanzado de codificación que es lo que conocemos también como H.264, pero que en realidad se llama también MPEG-4 Part 10 y que es lo que utilizaban los discos Blue-Ray, por ejemplo. Por eso en muchos sitios de Internet hablan de que H.264 y MPEG-4 son lo mismo. Y es cierto, pero no del todo, ya que en MPEG-4 las partes 2, 12 o 14 también describen otros formatos de compresión que son MPEG-4, y el formato contenedor puede contener también MPEG en versiones anteriores de menor calidad como MPEG-1 o MPEG-2.

MPEG-4 Parte 10 o formato H.264 o AVC

Recapitulemos lo que sabemos hasta ahora: cuando se habla en la actualidad de archivos MP4 o .mp4, o del "formato MP4" se habla en realidad del formato contenedor. Dentro de éste puede haber audio y vídeo en diversos formatos, por lo que hablar tan solo de MP4 no es correcto (o no es preciso al menos) y es necesario especificar más. Dado que el formato utilizado para hacer la compresión del stream de vídeo que contenga el MP4 es de vital importancia, se suele poner el "apellido" de dicho formato para indicar bien a qué nos estamos refiriendo.

Así, se habla de MP4/H.264 para los vídeos que usan la parte 10 de MPEG-4 y que son vídeos muy compatibles y de alta calidad. También es común que se hable del formato MP4/MPEG-4, que en este caso se suele referir a la Parte 2 de MPEG-4, que es el formato original que se lanzó, y es de menor calidad, por lo que se suele utilizar para emitir televisión por IP (vídeo-vigilancia) o distribuir ciertos contenidos multimedia (algunas pelis "pirata", CDs multimedia...) pues pesa menos generalmente.

El formato MP4/H.264 es el que debe utilizarse para reproducir directamente en los navegadores, puesto que es el que soportan hoy en día todos ellos en todos los sistemas operativos. Es mucho más eficiente que MPEG-4 Parte 2 (el original) a la hora de codificar, y ofrece mucha mejor calidad incluso aunque usemos una tasa de bits pequeña o un ancho de banda reducido a la hora de reproducirlo. Resiste muy bien los errores de transmisión aunque se pierdan algunos paquetes, por lo que va muy bien para streaming, videoconferencia y similares aplicaciones. A este formato se le conoce también con el nombre de AVC (Advanced Video Coding), por lo que en algunas ocasiones puedes leer MP4/AVC, pero se trata de lo mismo.

Como contrapartida, el formato H.264 es más complejo y más complicado de codificar (puede requerir hasta 3 veces más potencia de computación que el formato original de MPEG-4) y de decodificar (el doble de potencia), pero hoy en día con los dispositivos de los que dispone el usuario medio (tanto ordenadores como móviles, etc...) esto tiene poca importancia.

En resumen

Hablar tan solo del "formato MP4" es impreciso. Un vídeo con la extensión .mp4 puede que no se reproduzca en un navegador mientras que otro con la misma extensión sí. La diferencia entre ellos estriba en la manera de codificar el vídeo que lleva dentro, ya que .mp4 es un formato contenedor.

Para la web, el formato recomendado es el MPEG-4 Part 10, o lo que es lo mismo el MP4/AVC o, mucho más comúnmente denominado, MP4/H.264. Este formato funciona en todos los navegadores del mercado, excepto en versiones muy viejas de Internet Explorer.

Así que cuando te hablen del "Formato MP4", o bien te están hablando de MP4/H.264 o entonces tienen que especificártelo más. Si tienes duda del formato de un archivo .mp4 concreto que quieres reproducir puedes utilizar alguna herramienta del estilo de Mediainfo para que te diga de qué manera concreta están codificadas las pistas de audio y vídeo. Este programa a las pistas codificadas como H.264 las identifica como AVC, que como sabemos es lo mismo. Si te dice AVC es que está en el formato correcto para la web.

Como ves, el mundo de los formatos multimedia es bastante complejo técnicamente. Por suerte, como desarrollador o diseñador web lo único que debe preocuparte hoy en día es que tengan una relación calidad/peso apropiada y que estén codificados como MP4/H.264. Así que lo tienes fácil ?

¡Espero que te resulte útil e interesante!

Aunque instalo Web Deploy en IIS, no me aparece en la interfaz de gestión

03/04/2018
Artículo original

Web Deploy es una extensión muy interesante para Internet Information Server. Este paquete lo que te permite es sincronizar aplicaciones entre diferentes instalaciones de IIS, aunque no sean de la misma versión y migrar aplicaciones web entre versiones de IIS. Básicamente lo que hace es añadir un par de opciones a la aplicación de gestión de IIS que te dan la oportunidad de exportar e importar aplicaciones (pulsa para aumentar):

De este modo, cuando exportamos, elegimos exactamente qué aspectos de la aplicación queremos exportar (archivos, permisos, certificados, configuraciones... incluso la base de datos) y se nos genera un paquete ZIP que podemos transportar a otro servidor que también lo tenga instalado. Una vez allí abrimos el ZIP con la opción de importar aplicación y podríamos regenerar la aplicación completa y sus propiedades de un solo golpe. Muy cómodo. Además permite gestionar la tarea desde la línea de comandos y con Powershell, por lo que puedes automatizarlo si lo necesitas. Finalmente, y esto es un pequeño plus, soporta incluso versiones muy viejas de IIS, como IIS 6 (con Windows Server 2003!!) por lo que te ayuda a migrar aplicaciones antiguas de manera sencilla.

El caso es que si instalas Web Deploy en Windows Server 2012 R2 (IIS 8.5) o Windows Server 2016 (IIS 10) parece que no ha funcionado. No aparecen las opciones de exportar e importar en el IIS Manager. Por más que desinstales y vuelvas a instalar, como dicen en muchos sitios de Internet, siguen sin aparecer.

Si te encuentras con este problema, te voy a contar la forma de solucionarlo.

Y es que las últimas versiones de Web Deploy, en concreto la 3.6, añaden un requisito que antes no existía, pero que no está documentado en ningún lado (que yo sepa). En estas versiones modernas de Windows Sever Web Deploy necesita que tengas instalada la opción de "Management Service" o no te funcionará.

Para instalarla o asegurarte de que la tienes, debes ir al menú de inicio y buscar la gestión del servidor ("Server Manager"):

y una vez dentro elegir la opción de "Añadir roles o características" del menú "Gestionar" que hay arriba a la derecha:

En el asistente que aparece, vas hasta el paso de "Roles de servidor" y despliegas hasta que veas la opción "Servicio de administración" dentro del nodo de "Servicio Web":

(en la imagen anterior yo ya la tengo instalada, pero en tu caso si no la tienes te la dejará marcar).

Sigues el asistente hasta el final y cierras.

Ahora desinstala Web Deploy si lo tienes ya instalado y vuélvelo a instalar. O instállo si no lo habías hecho aún. ¡Tadaaa! Te aparecerán las opciones.

¡Espero que te resulte útil!

Página Siguiente