Hace unos años sonaba bastante el término programador políglota para referirse a aquellos programadores que eran capaces de trabajar con varios lenguajes de programación. Hoy en día es una idea que ha perdido popularidad, al menos a la hora de rellenar posts y charlas en eventos. Es una idea que me gusta, y querría pensar que si ya no se habla tanto de ello es porque se ha convertido en algo que se da por hecho, pero en realidad creo que, simplemente, ha pasado a un segundo plano y las modas actuales van por otro lado.

En paralelo sí que veo un auge de lo que podríamos considerar proyectos políglotas, en los que se mezclan distintos lenguajes de programación, y no sólo como lenguajes auxiliares, sino como lenguajes primarios en diferentes áreas del proyecto. Aquí la moda de los microservicios tiene mucho que decir.

Por supuesto, esto no es más que una impresión personal y limitada a mi círculo de fuentes de información, así que es probable que esté equivocado. Aun así, aprovecharé para analizar ambas ideas: la del programador y la del proyecto políglota.

Las ventajas del programador políglota

En un mundo de fantasía uno aprendería a programar en un lenguaje y ya sabría programar en todos. Tan sólo es cuestión de aprender la sintaxis de cada uno y traducir de uno a otro.

¿Suena iluso? Sin duda, pero es una sensación que muchos hemos tenido. Durante mis primeros años en esto, era lo que pensaba. Cuando aprendí a programar en Pascal y luego en C, daba por hecho que era más o menos lo mismo, pero cambiando los BEGIN/END por {/}. Bueno, puede que entre Pascal y C no haya taaaaanta diferencia, pero es algo más que un cambio de sintaxis, sobre todo cuando piensas en los estilos de programación que imperan en cada uno.

Asumiendo entonces que aprender un lenguaje de programación es algo más que aprender su sintaxis, esto de aprender varios, y más si quieres tener un grado de soltura razonable con ellos, parece que va a requerir cierto esfuerzo. Además de la sintaxis, cada lenguaje viene con su paquete de herramientas, librerías, frameworks, estilos de programación y construcciones idiomáticas, y manejarse bien con todo ello son palabras mayores.

¿Merece la pena dedicar todo ese esfuerzo en conocer otros lenguajes?

Teniendo en cuenta que para muchos su trabajo en el día a día les lleva a utilizar un único lenguaje de programación (o un par de ellos), parece que lo más razonable es profundizar en ellos al máximo y ser lo más productivo posible con ellos. A fin de cuentas, es difícil que dedicando un rato a jugar con otros lenguajes alcances el grado de productividad que tienes con un lenguaje, unas herramientas y unas librerías a las que dedicas 30 o 40 horas semanales.

Sin embargo, y como ya te imaginarás puesto que estoy escribiendo este post, soy un firme defensor de aprender otros lenguajes de programación, aunque nunca llegues a dominarlos tanto como tu lenguaje “del día a día” y nunca llegues a utilizarlos “profesionalmente”.

Cuando trabajas siempre con las mismas herramientas y eres productivo con ellas es muy fácil acomodarse y asumir que es lo mejor que vas a encontrar. De hecho, probablemente sea cierto y, como decía antes, en este momento ninguna herramienta te haga tan productivo como las que ya conoces.

Sin embargo, eso no deja de ser una falsa sensación de seguridad basada en tu (limitada) visión personal. Siempre hay un margen de mejora y una buena forma de conocer alternativas es aprender de otros. Al aprender otros lenguajes de programación te estás exponiendo a una forma diferente de trabajar, con sus partes buenas y sus partes malas, y tal vez descubras ideas que te sorprendan.

Esta exploración de otros ámbitos puede desembocar en que acabes cambiando de lenguaje “principal” hacia alguno de los que has aprendido. Al principio además te parecerá todo maravilloso, porque lo nuevo siempre atrae. Pasados unos años… bueno, el tiempo lo diría.

Lo más probable es que la exploración de otros lenguajes no se traduzca en una migración hacia ellos, pero seguramente puedas obtener nuevas ideas y formas de trabajar que influencien la forma en que utilizas tus herramientas actuales y te permita sacarles más partido. Tal vez un día te descubras evitando las clases en C#, adaptando librerías de ClojureScript a Javascript o incluso utilizando Monoides para configurar tu aplicación de Java.

Me gusta compararlo con viajar. Viajar es una actividad muy enriquecedora porque te permite conocer otras ciudades, otras personas y otra forma de ver la vida. Es poco probable que te mudes a una nueva ciudad sólo porque has estado allí unos días y te ha gustado, pero el viaje en si mismo habrá merecido la pena.

Hay quien piensa que, actualmente, con los lenguajes multiparadigma que permiten utilizar un enfoque funcional, orientado a objetos, procedural, con tipado estático, dinámico o gradual, esto de conocer varios lenguajes pierde sentido. A fin de cuentas, en mi lenguaje favorito ya tengo todo lo que necesito. No soy nada partidario de la featuritis en lenguajes de programación, pero es que además no es comparable. No se trata sólo de una cuestión de paradigmas, es también una cuestión cultural.

Siguiendo con la comparativa de los viajes, es como ir a Las Vegas. Sí, hay una recreación de la Torre Eiffel. Y de los canales de Venecia. Y pirámides, como en Egipto. Pero no es lo mismo, es sólo cartón piedra imitando el original. Incluso aunque la reproducción fuese físicamente perfecta y no pudieras distinguirla del original, lo que hay alrededor no es igual y pierdes la parte de cultura, motivaciones e historia que hay detrás.

Normalmente cuando se habla de alternativas en desarrollo siempre se acaba citado el típico The Right Tool For The Job ™, y este caso no es diferente. Si conoces varios lenguajes de programación, podrás elegir el que mejor se adapte para cada caso y, al menos en teoría, ser más feliz y productivo.

Y siguiendo este hilo de argumentación acabamos, directamente, en el siguiente punto: los proyectos políglotas.

Los peligros del proyecto políglota

Parece razonable. Si somos programadores políglotas, capaces de trabajar con soltura en diferentes lenguajes de programación, qué mejor que aplicar eso en cada proyecto para poder aprovechar al máximo las características de cada lenguaje y poder emplear en cada parte del proyecto la herramienta que más se adecúe a ella.

Es uno de los argumentos a favor de las arquitecturas basadas en servicios (micro o no). Teniendo componentes aislados obtenemos, no sólo flexibilidad en despliegue, sino también flexilibidad en desarrollo y, en concreto, en el lenguaje que queremos utilizar.

Tampoco hace falta irse a arquitecturas complejas. Muchos lenguajes permiten interoperar fácilmente con otros lenguajes. Por ejemplo, mezclar lenguajes dentro de .NET o de la JVM es bastante fácil, y casi todo los lenguajes tienen algún tipo de forma de interoperar con C. Podríamos tener partes de una aplicación desarrollada en C#, usando librerías concretas en F# y no habría problema.

Además, es muy raro encontrarse a día de hoy con un proyecto que no esté usando ya varios lenguajes, aunque sean “auxiliares”. SQL para acceder a una base de datos, lenguajes de marcado (HTML, XAML, etc.) para el interfaz de usuario, Javascript (porque, como sabéis, todo acaba llevando Javascript), algún lenguaje de scripting para automatizar tareas… Podríamos decir que hoy en día casi todos los proyectos son, de alguna forma, políglotas.

Pese a esta realidad y las innegables ventajas de poder usar el lenguaje más adecuado en cada momento, esta vía tiene riestos que hay que evaluar antes de lanzarse a utilizar 12 lenguajes de programación diferentes en el próximo proyecto.

Por una parte, tenemos un problema directo de necesidad de conocimiento. Si el proyecto utiliza varios lenguajes, con distintos estilos de programación, distintas librerías y distintas herramientas, tenemos dos opciones: o tenemos especialistas en cada área, o tenemos gente capaz de manejarse en todas.

La primera opción, tener especialistas en cada área/lenguaje, requiere que el equipo tenga un cierto tamaño como para poder diferencias bien los roles, y disminuye la tolerancia a fallos del equipo porque contribuye a crear silos de información.

La alternativa, contar con gente capaz de manejarse en todos los lenguajes, supone una mayor dificultad para incorporar gente al equipo y para formarla. Incluso teniendo la gente formada, estar haciendo constantemente cambios de contexto al pasar de un lenguaje a otro puede ser un inconveniente (aunque también podría ser un aliciente para evitar la monotonía, todo hay que verlo).

Este problema “humano” es importante, pero existe un problema técnico que, en mi opinión, puede acabar pensado más: el incremento del número de dependencias.

Pocas dependencias hay más fuertes en un proyecto que el lenguaje de programación elegido. A partir del lenguaje irán surgiendo las demás dependencias: herramientas, librerías, gestores de paquetes, etc.

Si trabajas con lenguajes de programación cercanos, que compartan plataforma, habrá dependencias que puedas reutilizar. Por ejemplo, si optas por C# y F#, puedes trabajar con Visual Studio, utilizar NuGet como gestor de paquetes (o, aun mejor, Paket) y ejecutar ambos sobre el CLR. Aun así, para poder explotar al máximo las características de cada lenguaje probablemente acabes con algunas dependencias “duplicadas” para disponer de la solución más idiomática en cada caso.

Si empiezas a desarrollar una web en C#, interactuando con servicios en Go y un frontend en Javascript… bueno, te lo vas a pasar mejor manteniendo runtimes para cada una de las cosas, compiladores para todas y librerías específicas.

Este escenario no tendría por qué ser tan terrible. En un proyecto grande, de larga duración, dedicar tiempo a montar toda esta infraestructura puede compensar con el teórico incremento de productividad asociado a disponer de lenguajes mejores para cada tarea concreta.

Desgraciadamente, cada vez es más difícil ver esto como una inversión inicial, y el ritmo al que avanza todo hace que sea complicado mantener el montaje inicial mucho tiempo. Tendrás que mantener actualizadas las librerías de cada lenguaje. Adecuarte a los cambios de versión de sus plataformas. A las nuevas herramientas y formas de trabajo que se hayan puesto de moda y que, si quieres usar las versiones nuevas de las librerías, no te queda más remedio que usar.

Todo esto suele ser, en el sentido más estricto de la expresión, una pérdida de tiempo. Son cosas que aportan muy poco a los usuarios de tu aplicación, pero que no te queda más remedio que hacer. Si en lugar de un lenguaje y una plataforma tienes 3 o 4, la pérdida de tiempo se multiplica, por lo que es fundamental estar seguro de que las ventajas que obtienes por utilizar varios lenguajes, compensa este incremento de tiempo de mantenimiento.

Conclusión

Nunca hay que dejar de viajar, digo, de conocer otros lenguajes de programación. Aparte de que suele ser divertido, es una forma muy buena de aprender cosas diferentes que puedes luego trasladar a tu día a día. Como mínimo, te permitirá afrontar los problemas con más herramientas y otros puntos de vista, y eso ya es positivo per se.

Además, este mundo cambia muy rápido y nunca se sabe si uno de esos lenguajes de programación que hoy aprendes por curiosidad se acabará convirtiendo en tu próxima oportunidad profesional (o en tu salvación cuando tu lenguaje favorito caiga en el olvido).

Con lo que tenemos que tener cuidado es con abusar de ese nuevo conocimiento e intentar mezclar muchos lenguajes de programación en un mismo proyecto. Es algo que puede resultar tremendamente útil y productivo, pero que tiene unos riesgos y costes asociados que hay que considerar cuidadosamente antes de lanzarse a ello.

Posts relacionados:

1. Productos y Proyectos y Viceversa

.NET

• Top 10 C# projects errors found in 2016
  Harry Lee
• Could not load file or assembly or one of its dependencies.
  Szymon Warda
• WordPress Running on .NET
  Benjamin Fistein
• C#7 - Taking a second look at Tuples
  Mark Downie
• The week in .NET – On .NET with Eric Mellino, Happy Birthday from Scott Hunter, OzCode
  Bertrand Le Roy

ASP.NET

• ASP.NET Performance Optimization
  M. AqibShehzad 

.NET Core / ASP.NET Core

• Detecting the Operating System in .NET Core
  Marius Schulz
• Using routing DataTokens in ASP.NET Core
  Andrew Lock
• Abusing .NET Core CLI
  Alexander Tsvetkov
• .NET Core logging to MySQL using NLog
  Damien Bowden
• View Components with ASP.NET Core 1.1
  Christian Nagel
• The antiforgery token could not be decrypted - Running ASP.NET Core on Azure App Service using deployment slots
  Henning Støverud
• Simplifying Bundling and Minification in ASP.NET Core
  Shayne Boyer
• Create a class with .NET Core and Roslyn
  Carlos Mendible
• Using EF Core in ASP.NET Core Web API for performing CRUD operations
  Mahesh Sabnis
• Notes from the ASP.NET Community Standup –February 21, 2017
  Maria Naggaga
• Creating a Word Document OutputFormatter in ASP.NET Core
  Juergen Gutsch

Azure / Cloud

• Azure Command Line 2.0 now generally available
  Kamaljit Bath
• On-Premise Data Synchronization to Azure Blob Storage
  Arlan Nugara
• Exploring the new DevOps - Azure Command Line Interface 2.0 (CLI)
  Scott Hanselman
• Azure Weekly: Feb 27, 2017
  Chris Pietschmann

Conceptos/Patrones/Buenas prácticas

• Desarrollo de CorDapps: Introducción
  José Antonio Dongil
• Secrets of Maintainable Codebases
  Erik Dietrich

Data

• Implementing Missing Features in Entity Framework Core – Part 7: Entity Configuration in Mapping Classes
  Ricardo Peres
• Mimic Lazy Loading with Entity Framework 6 and Entity Framework Core 1.1
  Peter Vogel
• Troubleshooting the dotnet ef command for EF Core Migrations
  Julie Lerman
• Making Entity Framework Audit Itself
  Kevin Mack

Html/Css/Javascript

• What is JSON? An Introduction and Guide for Beginners
  Louis Lazaris
• Knockout JS Validations, Without a Plugin and Using a Plugin
  Sibeesh Venu
• Different Methods of Error Handling in jQuery
  Learning jQuery
• Integrando React en aplicaciones antiguas
  Braulio Díez
• Comprehensive CSS Cheat Sheet + PDF
  Matt Banner
• Do you know JavaScript? Are you sure? – Part 1
  Sibeesh Venu
• Modernizr: Cómo sustituir funcionalidad no soportada con polyfills (Parte 2)
  Alberto Población
• Text Stroke: Stuck In The Middle With You
  Chris Coyier
• Managing Modules in TypeScript 2.1
  Peter Vogel
• Entendiendo cómo funciona JSX
  Juan María Hernández
• HTML5 Form Attributes (Part 1)
  Alexis Goldstein, Louis Lazaris & Estelle Weyl

Visual Studio/Complementos/Herramientas

• Long live Web Essentials
  Mads Kristensen
• Debugging JavaScript And TypeScript Using Google Chrome in Visual Studio 2017
  Banketeshvar Narayan
• How to Start Multiple Projects in Visual Studio
  Steve Smith

Otros

• Mastering HTTP Caching - from request to response and everything
  Ulrich Kautz
• El principio oscuro
  Javier Garzás
• He diseñado la mejor aplicación del mundo
  José Antonio Dongil
• Productividad: Organizando la vida para intentar hacerlo todo con GTD
  Rubén Fernández
• Clarifying Misconceptions About SHAttered
  Manish Goregaokar

Componentes/bibliotecas

• RxDB
  Client-Side Database for Browsers, NodeJS, electron, cordova, react-native and every other javascript-runtime
• TwitterBootstrapMVC
  Development for ASP.NET MVC with Bootstrap made simple

En FileOptimizer y los logotipos más populares, vimos las mejoras reales que obtiene FileOptimizer. Además, con cierta regularidad, os voy manteniendo al día sobre su evolución, y os voy contando algunos secretillos. En el artículo de hoy, vamos a ver como ha mejorado el grado de optimización que consigue FileOptimizer. Aunque la primera versión fue […]

La entrada La evolución de FileOptimizer aparece primero en Bitácora de Javier Gutiérrez Chamorro (Guti).

Error : El argumento 'DefaultConnection-Web.config Connection String' no puede ser NULL ni estar vacío.

Error : The 'DefaultConnection-Web.config Connection String' argument cannot be null or empty.

Solución 1

Solución 2

<PublishDatabaseSettings>
<Objects>
<ObjectGroup Name="DefaultConnection" Order="1" Enabled="False" xmlns="">
<Destination Path="" />
<Object Type="DbCodeFirst">
<Source Path="DBMigration"
           DbContext="MyProject.MyDataContext, MyProject"
           MigrationConfiguration="MyProject.Migrations.Configuration, MyProject"
           Origin="Convention" />
</Object>
</ObjectGroup>
</Objects>
</PublishDatabaseSettings>

<PublishDatabaseSettings>
<Objects>
<ObjectGroup Name="DefaultConnection" Order="1" Enabled="False" xmlns="">
<Destination Path="{deployment connection string}" /> 
<Object Type="DbCodeFirst">
<Source Path="DBMigration"
           DbContext="MyProject.MyDataContext, MyProject"
           MigrationConfiguration="MyProject.Migrations.Configuration, MyProject"
           Origin="Convention" />
</Object>
</ObjectGroup>
</Objects>
</PublishDatabaseSettings>

Sin duda las mejores aplicaciones son las que surgen a partir de una necesidad. Es el caso de Riff Studio, una aplicación para dispositivos Android hecha por y para músicos desarrollada por Bruno Azzinari. Su objetivo es facilitarnos practicar canciones.

Básicamente tenemos que armar una lista de temas agregándolos desde nuestro dispositivo. Desde ahí podemos reproducirlos y cambiarles el tono y velocidad.

Podemos bajarle la velocidad a una canción para practicarla e ir aumentando de a poco a medida que vaya saliendo mejor. Para práctica más intensa podemos incluso subirle la velocidad a una canción. También cambiar el tono si usamos una afinación distinta o para usa un registro distinto si estamos cantando.

Todos estos cambios se pueden hacer en tiempo real afectando a la reproducción en el momento y son independientes. El tono se puede cambiar en semitonos y la velocidad en porcentaje de la original.

Una de las características interesantes que se agregó en la última actualización es la de bucle. Podemos definir un segmento de la canción que queremos que se repita en un bucle. Esto es súper útil y personalmente lo he usado para sacar algún punteo complicado en la guitarra. Al poder repetir el mismo segmento y a una velocidad más lenta, no se nos escapa ni una nota.

Podemos exportar en formato mp3 la canción modificada para reproducirla desde cualquier otro reproductor digital y no depender del programa.

La interfaz es muy sencilla y cómoda de usar. El desarrollador está abierto a críticas, sugerencias y feedback en general, y lo pueden contactar en el mail brazzilabs@gmail.com con ideas.

RiffStudio en el Google Play Store

El momento ha llegado, tras tantos años sin pensar en ella. He vuelto a encontrármela, ahí de pie, delante de mí. Su nombre es Pandora y con una risa maliciosa viene a este humilde blog. A llenar nuestras almas de oscuridad aumentando el contraste y corrigiendo el color.

Aunque poco a poco he estado soltando pinceladas en el tiempo sobre imagen digital en GNU/Linux, vídeo digital, integración de algunas técnicas y demás. Pero creo que ha llegado el momento de hacer algo más grande y preparar una referencia mayor sobre software libre y edición de vídeo.

Mi experiencia personal y privativa

Hace muchos años que me adentré en el mundo de la edición de vídeo por ordenador. Como muchos de nosotros, empecé haciendo pequeñas animaciones en un modesto equipo del siglo pasado, sólo por hobbie y por hacer algo con mi tiempo (en aquella época en la que aún podía gozar de algo de tiempo libre). El programa que solía utilizar era Autodesk Animator. Estaba muy limitado, pero podías hacer muchas cosas. Era muy intuitivo.

Con el tiempo, fui conociendo otros programas de edición de vídeo, hasta que gracias a un amigo conocí el paquete de Ulead Videostudio. Esta persona se compró una tarjeta capturadora en aquella época en que las tarjetas de este tipo ocupaban todo el ancho de la torre y costaban un ojo de la cara y medio riñón… pero venían con mucho software para utilizar. Unos años más tarde fueron bajando de precio, aunque empezaron a ser un poco peores en la captura. Como los ordenadores de aquella época no eran tan rápidos, estas tarjetas solían llevar un chip compresor/descompresor MPEG integrado por lo que a medida que capturabas vídeo lo ibas recibiendo comprimido y todo… y como en todo, un mejor compresor generaba vídeos de menor tamaño con mayor calidad, y dado que el ancho de banda del bus es limitado llegaba un punto que una tarjeta capturadora barata no podía obtener mucha calidad. Con el tiempo terminé comprando una tarjeta de estas, de las baratas, no de las profesionales, aunque dentro de la gama de las baratas me fue muy bien.

Unos años más adelante, con capturadora nueva, no tenía cámara de vídeo y me pasé mucho tiempo pidiendo cámaras de vídeo. Si algún amigo tenía una cámara de vídeo, allá que iba yo cuando tenía algún proyecto para grabar. Me lo pasaba en grande montando historias para hacer pequeñas grabaciones en mi adolescencia. ¿Algunos ejemplos? (He perdido mucho material, tenía muchas cosas grabadas en CD y esos CDs cambiaron de plano existencial, fue una gran pérdida, no es lo mejor, pero sí lo que pude rescatar y lo que Youtube no me ha quitado por tema de licencias).

• Videoclip: El Hombre de Negro
• Sketch: Se me va la olla
• Microcorto: Sentada en una Maleta
• Fragmento: Huyendo del destino

He perdido muchísimo material. Además, en 2003 hice mi paso definitivo a GNU/Linux. Aunque tenía la espinita del vídeo digital, me pudo más el hecho de dejar Windows de lado y llegó un punto en el que no arrancaba Windows para nada por lo que GNU/Linux pasó a ser el único sistema operativo de mi ordenador, y lo ha sido hasta el día de hoy.

Bueno, antes de nada decir que hasta 2003 más o menos, los programas de edición de vídeo para Windows tampoco destacaban por su estabilidad. Ya fuera por el propio sistema operativo, el uso intensivo de la memoria, los codecs y la complejidad de los sistemas, era común encontrarse con algún pantallazo azul de vez en cuando, o que el propio programa en el que estabas editando vídeo en el momento de más concentración se cierra inesperadamente dejándote todo el trabajo a medias. O, como me pasó con Huyendo del destino, el ordenador se reinició y cuando todo arrancó vi que los principales archivos del proyecto estaban corruptos (era mucho más largo y abandoné el proyecto).

Lo sé, había editores de vídeo para GNU/Linux

Soy consciente de ello, es más, de vez en cuando abría alguno e intentaba hacerme con él, aunque el problema, como en Windows era la estabilidad, aunque en este sistema era aún peor. Por un lado, los programas de edición no eran lo suficientemente maduros, casi todos acababan de nacer (incluyo como mucho hasta 2004, avisadme si falta alguno):

• KDEnlive nació en 2002
• Cinelerra nace en 2002
• PiTiVi nace en 2003
• Blender se libera en 2002, aunque no editaba vídeos
• Shotcut nace en 2004
• LiVES nace en 2003

Y es normal que tratándose de software libre, en este sentido estos desarrollos fueran bastante lentos. Además estábamos en una época cambiante, con respecto a codificación de vídeo (MPEG-4 estaba pisando fuerte, había nuevas formas de codificar audio y surgían formatos propios de Microsoft o Apple a los que había que dar soporte. También estaba entrando el DVD y los usuarios de GNU/Linux teníamos derecho a utilizar el DVD). Además, las cámaras empezaban a utilizar el IEEE1394 que era más rápido que USB para transmisión de datos… En definitiva, los desarrollos de codificación y soporte cambiaban muy a menudo, y quienes desarrollaban estos programas de vídeo al no estar amparados por ninguna empresa, encima recién nacidos los proyectos, era normal que no fuera la cosa tan estable como debería… y ya por no meternos en el tema de tarjetas gráficas.

El caso es que para 2006 pude volver a hacer algún montaje sencillo, con una estabilidad que más o menos me permitía no arrancarme el pelo de desesperación. En este caso con KDEnlive, un editor que he utilizado mucho y durante muchas horas, que me ha dado alegrías y penas y del que alguna vez he hecho algo en este blog.

También quiero dejar claro que, la industria del cine, según dice empieza a utilizar GNU/Linux en el año 2002 o incluso antes. Empresas como Industrial Light and Magic, Rhythm and Hues, Dreamworks, WetaDigital o Pixar dicen que utilizan GNU/Linux en algunos de sus procesos, eso sí con herramientas propias y/o privativas.

Estado del arte

Pero llega 2017. Y, sobre todo me animo a hacer esta serie de posts el hecho de que KDEnlive, después de algo más de dos años sin usarlo, en diciembre de 2016, lo he notado más estable que nunca, pude hacer un vídeo sin que me diera guerra el programa, incluso abrí un montaje hecho hace casi 5 años y no tuve ningún problema, bueno sólo un filtro que no estaba, pero era culpa mía que no lo instalé.
Por otro lado, Blender, que, aunque me gusta, tengo que decir que no siempre las versiones estables son estables, ni están libres de fallos tontos (los fallos ocurren, lo sabemos, pero hay algunos más tontos que otros, y a veces la mezcla de dos imágenes no funciona bien, o se ve claramente que se desborda un número y no se ha controlado un valor (lo siento, mi faceta de programador siempre está alerta). Pero abrí Blender 2.78 y me dio muy buena sensación, iba muy ligero y no se quejó para un pequeño montaje (cosa que antes sí que hacía).

Así que, quiero empezar este año a hacer un pequeño análisis y empezar a realizar tutoriales sobre edición de vídeo digital en GNU/Linux, efectos especiales, composición, etc. Es cierto que el software privativo en este sentido está a muchos años de distancia, pero vamos por buen camino, incluso hay cosas que podremos hacer con software libre y no con software privativo, aunque nos toque tener que programarlas.

Un pequeño vídeo

Digo edición de vídeo, pero no profundizo

Es un tema complejo y amplio que he metido en edición de vídeo, aunque sé que hay muchos subtemas que debemos tratar. Una cosa es el montaje, y otra la composición (aunque hay herramientas que las integran). Por otro lado tenemos la conversión, recorte, etalonaje (palabro de la vieja escuela, relativo a la corrección y tratamiento del color), análisis espacio-temporal, screencasting, stop-motion, edición y renderizado 3D, edición de audio y de imagen fija (sí, utilizaremos GIMP para preparar cosas), y mucho más. Tenemos para largo.
Y todo eso sin entrar en temas de producción donde encontramos software para creación de guiones, presupuestos, gestión de proyectos, storyboarding y muchísimo más.

¿Qué le pido a un editor de vídeo?

Hablo aquí de editores de vídeo no lineales, de los de toda la vida, para hacer montajes, en los que cogemos vídeos de origen, aplicamos un efecto y obtenemos un vídeo resultante.

Me quiero centrar en tres características:

Edición multicapa

Esto es, que podamos superponer varias capas de vídeo o imagen unas encima de otras para obtener una imagen resultante mezcla de todas. Podremos aplicar filtros a algunas imágenes intermedias, introducir transparencias, mover capas dentro de la imagen y mucho más.
Casi todos los editores suelen tener esta característica, mejor o peor, sólo quiero quitar del medio los programas que no valen para este tipo de edición, los que dan muchos problemas al realizarlo. No está bien que el día que necesitas 5 capas para montar un vídeo el programa empiece a ir extremadamente lento.

Proxys

Ahora editamos en resoluciones muy grandes. Es más, en el año 2000 se editaban algunas películas en 8K (y eso que ahora estamos con la novedad de las pantallas 4K). Eso sí mientras estamos editando, durante casi todo el proceso no nos importa tener las imágenes a la mayor resolución. Para conocer cambios de escena, hacer muchas tareas de corrección de color o mezclado no necesitamos las imágenes en alta resolución.
Así que un buen programa de edición de vídeo, aunque ocupe algo más de disco duro, y tarde un poco más al principio, nos permitirá generar vídeos en resoluciones más pequeñas y con algoritmos de fácil descompresión con el objetivo de facilitarnos el trabajo.
Imaginemos que mi cámara digital comprime los vídeos en MPEG-4 AVC (H.264, mal empezamos si queremos ser libres, pero bueno). El formato crea archivos de pequeño tamaño con nuestro vídeo, lo malo es que necesitamos un uso intensivo de CPU, incluso es más fácil reproducir un vídeo que extraer un fotograma suelto, y cuando estamos editando casi siempre estaremos extrayendo esos fotogramas por separado para realizar todo el trabajo de las capas. Muchas veces estos proxys suelen hacerse en MPEG-2, que a estas alturas se descomprime de forma muy sencilla, o en imágenes sueltas, JPEG, TIFF, PNG…). En definitiva, a lo mejor perdemos mucho tiempo en este trabajo. Además, si estamos trabajando en FullHD (1920×1080), seguramente la vista previa esté a un cuarto de resolución (960×540) o menos, por lo que, para crear las vistas previas, no merece la pena hacer todo el proceso en resolución completa, podemos coger la imagen a 960×540 y trabajar con ella, el resultado será el mismo y se harán un 25% de operaciones, lo que nos permitirá hacer cosas más complejas.

Eso sí, cuando vayamos a hacer el render definitivo, el programa cogerá los archivos originales. En hacer el render, no nos podemos precipitar. Es verdad que podremos optimizar y hay programas más rápidos que otros, pero lo realmente importante, creo que es el proceso de edición, el render siempre puede tirarse un ordenador varios días encendido, o podemos hacerlo en un servidor.

Máscaras

Esto es más de composición, pero me encanta que los editores tengan la posibilidad de incluir máscaras rápidas para hacer pequeños efectos rápidos. Con estas máscaras podremos dibujar zonas de la imagen que serán relevantes para nosotros descartando lo demás, que luego podremos superponer y hacer muchas tareas con ellas. Las máscaras deberían poder animarse, con lo que crearemos efectos de rotoscopía. Creo que hablaré sobre esto en un futuro post. Es un tema que me encanta.

¿Algo más?

Hay muchas más cosas que un editor debe tener, pero empecemos por estas tres. Por supuesto, deberíamos poder aplicar filtros de color, y corregirlo de forma precisa, seleccionar áreas que queremos con diferente color… aplicar efectos de barrido, ajustar velocidad de vídeos y muchas más cosas a las que me gustaría dedicarle algunos futuros posts y vídeos.

Programas para abrir boca

Sigue este enlace, donde veremos una colección de programas y recursos con los que editar vídeo y audio en GNU/Linux. El listado irá creciendo con enlaces a manuales, tutoriales y guías poco a poco.

Y tú, ¿qué software usas?

¿Qué software utilizas tú para tus montajes de vídeo? ¿Qué características son las imprescindibles para ti?

The post Edición de vídeo en GNU/Linux con software libre, ¿Qué características necesito para editar vídeo? appeared first on Poesía Binaria.

El primer ejemplo que haré de un programa Java que usa los pines GPIO para realizar algo con el kit de inicialización a la electrónica con la Raspberry Pi consiste en un pequeño programa Java que hace parpadear un diodo LED. La librería Diozero ofrece a los programas Java el acceso a los pines GPIO de la diferentes versiones de la Raspberry Pi desde la 1 (rev 1 y rev 2) pasando por los modelos B+, 2 y 3. Otra librería que se puede usar con el lenguaje de programación Java es Pi4J aunque personalmente Diozero me ha gustado más por ser de más alto nivel.

Algunas de las características que ofrece la librería Diozero son:

• Soporta dispositivos GPIO / I2C / SPI (LEDs, botones, sensores, motores, pantallas, etc).
• Soporta todos los modelos de las placas Raspberry Pi, Odroid C2, BeagleBone Black, C.H.I.P y Asus Tinker.
• Usa caracterśiticas de Java como gestión automática de recursos, expresiones lambda y referencias a métodos que simplifican el desarrollo y mejoran la legibilidad.
• Lista de deipositivos.
• Soporta varios proveedores para el acceso al los dispositivos con diferentes grados de rendimiento.

Una de las primeras cosas a conocer es como se numeran los pines en la Raspberry Pi ya que hay varias nomenclaturas (header, wiringPi y Broadcom) y que nomenclatura utiliza la librería Diozero. También deberemos tener en cuenta el modelo de la Raspberry Pi que poseamos ya que según el modelo hay pequeñas diferencias en algunos pines. Además si usamos una placa de extensión para pruebas sin sodadura como la wiringPi deberemos identificarlos por su nombre. Yo que poseo una de las primeras Raspberry Pi (la 1, rev1) el correspondiente su esquema de pines Raspberry Pi 1 (rev. 1) es el del enlace. En ese esquema se define que el pin número 12 según el conteo del header corresponde a GPIO 18 según la nomenclatura Broadcom y la librería Diozero y al GPIO 1 en la librería Pi4J y en la placa de extensión wiringPi.

Placas modelos Raspberry Pi 1 B y 3 B

Breadboard y placa extesión GPIO wiringPi de 26 pines y 40 pines

Como uso la placa de extensión wiringPi para conectar los pines de la Raspberry Pi a otra placa para hacer pruebas sin soldadura también conocidas como breadboard resultará que en el programa Java al usar Diozero uso la nomenclatura Broadcom para identificar los pines pero al conectar los cables en la placa de pruebas uso la nomenclatura de wiringPi.

Para el ejemplo utilizaré la placa de extensión sin soldadura, una resistencia de 200 ohmios (dadas sus bandas de colores rojo, negro, marrón y dorado) y un diodo LED además de un par de cables macho-macho para realizar las conexiones electrónicas entre el GPIO 18 (según la nomenclatura de la librería Diozero y Broadcom, 12 según la nomenclatura del header y 1 según la de wiringPi) y la resistencia además de entre el diodo y la línea de tierra. Los diodos LED poseen una orientación y hay que conectar la resistencia con el polo positivo del diodo LED, el polo positivo del diodo LED identifica porque es la patita larga y el negativo con tierra es la patita corta. Si realizamos la conexión al revés solo pasará que el diodo no se enciende pero no lo estropeará, la resistencia si es necesaria para no hacer que pase por el diodo una intensidad que lo estropee como se explica en ¿Qué resistencia ooner a un LED?.

Diodo blanco y resistencia de 200 ohmios

Las resistencias poseen cuatro bandas de colores que indican el valor en ohmios de esa resistencia, la tabla de colores es el siguiente:

Código de colores de las resistencias

El programa Java para hacer parpadear el diodo LED con la librería Diozero con el proveedor pigpio. El ejemplo consiste en activar y apagar el pin sucesivamente en un bucle y usar el método Thread.sleep para que pase unos segundos entre uno y otro y nos de tiempo a ver el encendido y apagado. El nada complejo programa Java para controlar el diodo y un vídeo de su funcionamiento están a continuación.

En un artículo anterior comento como disponer de un entorno para desarrollar, desplegar las librerías jar en la Raspberry Pi y como ejecutar los ejemplos desde la línea de comandos usando una combinación de herramientas de SSH, rsync y Ansible.

El código fuente completo del ejemplo puedes descargarlo del repositorio de ejemplos de Blog Bitix alojado en GitHub y probarlo en tu equipo ejecutando el comando ./gradlew executeBlink.

Es posible iniciar imagenes de Docker de una forma muy sencilla con simplemente ejecutar un docker start contenedor, pero al tener un servicio ya en un servidor productivo al reiniciarse vamos a querer que este inicie automaticamente.

Para hacer esto con systemd(algunos lo odian, otros lo aman y otros tantos simplemente trabajan con el) es necesario crear un archivo y enviarlo a la carpeta /etc/systemd/system/ y habilitarlo.

Aquí muestro un ejemplo con un contenedor llamado nexus

Contenido del archivo :

[Unit]
Description=Nexus container
Requires=docker.service
After=docker.service

[Service]
Restart=always
ExecStart=/usr/bin/docker start -a nexus
ExecStop=/usr/bin/docker stop -t 2 nexus

[Install]
WantedBy=default.target

Comandos a ejecutar:

Creamos el archivo:

touch docker-nexus.service

Lo abrimos con nano y pegamos el contenido de arriba ya personalizado:

nano docker-nexus.service

copiamos el archivo a la carpeta especial de systemd:

sudo cp docker-nexus.service /etc/systemd/system/

Lo habilitamos:

systemctl enable docker-nexus.service

Al reiniciar nuestor SO debería de levantarse automaticamente nuestro contenedor.

Fuentes:

• https://docs.docker.com/engine/admin/host_integration/

¿Cómo es esto posible? Si tenemos una cosa clara en el mundo de Internet es que si queremos tener en pie un servicio, éste debe estar alojado en una máquina que esté conectada a Internet, con energía y que nos asegure en cierta forma que está levantada. Estos servidores pueden ser de diversos tipos según las necesidades de la aplicación: web, base de datos, autentificación, tareas, logs, notificaciones, etc. Así que, ¿qué es esto de aplicaciones sin servidor? ¿o serverless?

¿Sin servidor? Serverless?

En realidad, este término no tiene que ver con que exista físicamente un servidor o no, sino con el hecho de delegar su administración a un tercero. Al mismo tiempo, nosotros no pedimos un servidor, pedimos un servicio Por lo que este término se aplica siempre que no tengamos que administrar el servidor que ejecuta un servicio, es más, en muchos casos, no sabemos sus características ni tenemos acceso a él más allá del servicio que ejecuta. Es más, el proveedor nos da un punto de entrada para poder llamar al servicio, y lo que haya por detrás será todo un misterio. Ellos nos garantizan el servicio encargándose de todo.

Esto pueden ser aplicaciones en la nube (ay la nube, ese gran desconocido, literalmente), como bases de datos, servidores de autentificación, incluso APIs para nuestras aplicaciones. Esto se utiliza sobre todo para aplicaciones móviles, en las que disponemos de un frontend y por detrás se hacen llamadas a servicios web que a su vez pueden hacer llamadas a otros servicios, todos remotos. Esto se suele llamar BaaS (Backend as a Service).

Por otro lado, algo que está muy de moda últimamente es la ejecución de funciones como servicio o FaaS (Functions as a Service), de hecho casi siempre que escuchemos algo sobre Serverless se referirán a esto y no es más que el alojamiento y ejecución de código por un tercero en contenedores de cómputo descentralizados y administrados por un tercero. Estos terceros suelen ser IBM, Google, Microsoft, Amazon, etc En definitiva, nuestro código no sabemos dónde se aloja ni dónde se ejecuta, sólo sabemos cómo llamarlo y cómo ver la respuesta de la ejecución. Es más, dependiendo del uso que hagamos de esta tecnología puede que haya muchas máquinas ejecutando nuestro código a la vez, sirviendo respuestas para nuestras aplicaciones… y todo sin tener que montar ni contratar un servidor.

Como hemos podido ver, estas soluciones son administradas, es decir, tampoco necesitamos que nadie se tome molestas para encargarse de la seguridad del servidor, balanceo de carga, actualizaciones de software, direccionamiento, almacenamiento, ni nada. Sólo debemos encargarnos de subir nuestro código y listo. Pero claro, eso de Serverless, seguro que se le ocurrió a uno de marketing porque suena muy bien. Está claro que servidor sí que hay, pero bueno, no tenemos que prestarle mucha atención.

¿Para qué quiero yo esto?

El objetivo, además de que es algo muy moderno, por un lado es que se reducen costes. Aunque hay que mirarlo con lupa y estudiar casos concretos. Es decir, para una empresa, el tiempo de un empleado supone dinero y el tiempo que el empleado invierte en tareas de mantenimiento de un servidor, significa una inversión económica. Además, tener una máquina contratada para realizar un servicio determinado es también una inversión económica, generalmente en forma de alquiler mensual y esto cubre momentos en los que se está utilizando el servicio y momentos en los que no hay nada utilizándose. Y normalmente, las empresas que facilitan este tipo de servicios cobran por el tiempo de uso de los servicios.

Por otro lado, nos garantiza la escalabilidad de los servicios (escalabilidad? Introducción a la escalabilidad de aplicaciones web. Técnicas, opciones, seguridad y consejos.). Ya que, en el caso de FaaS, sólo ejecutamos funciones, estas funciones podrán conectar con bases de datos y utilizar servicios externos, pero gozan de independencia de la máquina donde se ejecutan por lo que podremos llamar al servicio las veces que necesitemos, simultáneamente y no debemos tener ningún problema en la disponibilidad (no es plan de hacermos un DDOS tampoco). En el caso de BaaS también estamos llamando a servicios independientes por lo que el escalado no es un problema.
El caso es que el tema del escalado, que bien nos puede suponer un quebradero de cabeza de esta forma es transparente a nosotros y lo harán los servicios de manera natural.

Paranoico de mí

Pero claro, estamos dependiendo de un tercero, o de varios terceros, no tenemos control sobre la infraestructura, en muchos casos ni podemos visitarla, internamente no sabemos cómo funciona (más allá de lo que nos cuentan), puede que hasta desconozcamos la versión exacta del software que ejecutan estos contenedores. Aunque es verdad que las empresas muestran gran transparencia en sus operaciones no es lo mismo que si lo hicieras tú.
Siguiendo con la dependencia, la supervivencia de nuestras aplicaciones depende por completo de los servicios del tercero que contratamos. Eso quiere decir que si la empresa cambia sus condiciones (empeorándolas) tenemos un problema, si hacen una actualización de software y nuestro código no es compatible, tenemos otro problema gordo, si la empresa cierra (recordemos que todos los imperios han caído tarde o temprano), tenemos un problema más gordo aún y cambiar de empresa puede ser otro problema si no lo abordamos desde el principio.

No es lo mismo contratar un VPS con un sistema operativo donde podemos copiar los archivos de nuestra aplicación y desplegar (más o menos) que si tenemos que realizar cambios en nuestra aplicación para hacer llamadas a los servicios que hemos cambiado de empresa. Normalmente cada una tiene sus APIs para garantizar los accesos a sus servicios, autentificación de las llamadas, disparadores, etc. Aunque todos suelen tener partes comunes, también tienen sus particularidades.

¿Para qué lo podemos usar?

Lo primero, para tener todos los bloques de nuestra aplicación de Internet separados y bien diferenciados, lo que nos ayudará a crecer más rápidamente y como dijimos antes, la escalabilidad será algo natural.

Aunque ahora me voy a centrar un poco más en FaaS. Es decir, lo que haremos con este tipo de servicio es simplemente la ejecución de código. Una función, por ejemplo hecha en Python que tiene que ejecutarse en alguna ocasión. ¿Cuándo? Generalmente estas funciones se ejecutarán cuando se dispare un evento del tipo: petición web, entrada de datos en base de datos, inserción de mensaje en un log, creación de una notificación, entrada de un usuario determinado, nuevos archivos en servidores de almacenamiento y mucho más.

Normalmente nuestra aplicación tendrá un servidor web de entrada, que sí lo gestionamos nosotros (ese es nuestro VPS, o nuestros servidores balanceados), pero ahí vamos a incluir el código más básico posible: generación de páginas a partir de las plantillas, obtención sencilla de datos, control de sesiones, y poco más.

Por ejemplo, si tenemos en base de datos toda la información de ventas anual y queremos crear una gráfica resumen con todo y algunos datos estadísticos, seguramente si hemos vendido mucho debemos hacer cientos de cálculos y podemos encargárselos a otro liberando algo de carga en nuestro servidor, aunque el la entrada/salida de nuestra base de datos va a tener impacto igual, pero los cálculos y el trabajo de memoria y CPU para extraer medias, periodos, tendencias y demás se lo lleva otro. Todo esto lo podemos extender a todas aquellas tareas que sean un poco más pesadas de la cuenta. A lo mejor no tardan mucho tiempo, pero involucran sobre todo CPU y memoria y puede perjudicar el rendimiento global de nuestra aplicación. Estas tareas pueden ser: grandes importaciones/exportaciones de datos, generación de imágenes o miniaturas, generación de vídeos, etc.

En el lado del programador

El número de lenguajes es limitado y lo pone el proveedor del servicio. Contamos con lenguajes más o menos famosos y útiles como Python o NodeJs, en algunos sistemas podremos ejecutar Java o C#. Es normal que todos los lenguajes no estén soportados, porque hay que preparar los entornos de ejecución para que sea seguro utilizarlos y, supongo que con el tiempo se podrá ampliar el número de lenguajes soportados. Esto también puede causar dependencias, ya que puede que un proveedor soporte un lenguaje y otro no.

Por el lado de los desarrolladores, tenemos que contar con herramientas que nos permitan desarrollar el código de estos servicios de forma sencilla. Como la forma más común y sencilla de disparar los eventos es con peticiones HTTP. Actualmente hay sistemas que nos permiten crear un pequeño servidor local que atiende estos tipos de peticiones y ejecuta el código seleccionado. Luego, cuando pasemos el código a nuestro servidor sólo tendremos que cambiar el punto de acceso al servicio (que no será local, será el que nos dé nuestro proveedor). Y todo porque desarrollar desplegando todo el rato es muy feo.

Es conveniente también automatizar los despliegues. Y tenemos herramientas para ello, pero dependen del proveedor que cojamos. Sólo tendremos que crear un script o un archivo de instrucciones de despliegue y ya podremos usarlo para desplegar. Lo bueno es que esta tecnología nos permite crear tantos eventos como queramos, y tenemos la posibilidad de tener varios entornos, testing y producción por ejemplo, y sólo tenemos que cambiar el punto de entrada.

Tenemos que tener en cuenta que las funciones que ejecutamos deben estar lo más optimizadas posible, porque nos cobrarán por tiempo de ejecución, por lo tanto, las funciones deben estar bien definidas, tener un único objetivo y evitar entrar en bucles infinitos o esperas innecesarias. Eso sí, estas funciones podrán disparar eventos que ejecuten otras funciones en el futuro, así que tendremos que tener un poco de cuidado para que nuestras funciones no se pisen las unas a las otras…

Resumiendo

Para no agobiarnos mucho, con esta tecnología, definiremos una serie de eventos que, cuando se disparen, ejecutarán un fragmento de código en un ambiente de ejecución o contenedor controlado. Este código se ejecutará y el contenedor se destruirá. Si la función tiene que ejecutarse muchas veces, incluso simultáneamente, el proveedor se encarga del escalado/encolado/etc.

Estas funciones pueden conectar con otros servicios de base de datos, almacenamiento u otros tipos de servidores, incluso disparar la ejecución de otras funciones.

En próximos posts voy a contaros mi experiencia trabajando con Amazon Lambda

Referencias

No te pierdas estos sitios con interesantes lecturas sobre arquitectura Serverless:

• ¿Qué es eso de serverless? – Medium
• Serverless by Martin Fowler

The post Aplicaciones web sin servidor, o casi (arquitecturas serverless) appeared first on Poesía Binaria.

El primer ejemplo que haré de un programa Java que usa los pines GPIO para realizar algo con el kit de inicialización a la electrónica con la Raspberry Pi consiste en un pequeño programa Java que hace parpadear un diodo LED. La librería Diozero ofrece a los programas Java el acceso a los pines GPIO de la diferentes versiones de la Raspberry Pi desde la 1 (rev 1 y rev 2) pasando por los modelos B+, 2 y 3. Otra librería que se puede usar con el lenguaje de programación Java es Pi4J aunque personalmente Diozero me ha gustado más por ser de más alto nivel.

Algunas de las características que ofrece la librería Diozero son:

• Soporta dispositivos GPIO / I2C / SPI (LEDs, botones, sensores, motores, pantallas, etc).
• Soporta todos los modelos de las placas Raspberry Pi, Odroid C2, BeagleBone Black, C.H.I.P y Asus Tinker.
• Usa caracterśiticas de Java como gestión automática de recursos, expresiones lambda y referencias a métodos que simplifican el desarrollo y mejoran la legibilidad.
• Lista de deipositivos.
• Soporta varios proveedores para el acceso al los dispositivos con diferentes grados de rendimiento.

Una de las primeras cosas a conocer es como se numeran los pines en la Raspberry Pi ya que hay varias nomenclaturas (header, wiringPi y Broadcom) y que nomenclatura utiliza la librería Diozero. También deberemos tener en cuenta el modelo de la Raspberry Pi que poseamos ya que según el modelo hay pequeñas diferencias en algunos pines. Además si usamos una placa de extensión para pruebas sin sodadura como la wiringPi deberemos identificarlos por su nombre. Yo que poseo una de las primeras Raspberry Pi (la 1, rev1) el correspondiente su esquema de pines Raspberry Pi 1 (rev. 1) es el del enlace. En ese esquema se define que el pin número 12 según el conteo del header corresponde a GPIO 18 según la nomenclatura Broadcom y la librería Diozero y al GPIO 1 en la librería Pi4J y en la placa de extensión wiringPi.

Placas modelos Raspberry Pi 1 B y 3 B

Breadboard y placa extesión GPIO wiringPi de 26 pines y 40 pines

Esquema del cableado

Como uso la placa de extensión wiringPi para conectar los pines de la Raspberry Pi a otra placa para hacer pruebas sin soldadura también conocidas como breadboard resultará que en el programa Java al usar Diozero uso la nomenclatura Broadcom para identificar los pines pero al conectar los cables en la placa de pruebas uso la nomenclatura de wiringPi.

Para el ejemplo utilizaré la placa de extensión sin soldadura, una resistencia de 200 ohmios (dadas sus bandas de colores rojo, negro, marrón y dorado) y un diodo LED además de un par de cables macho-macho para realizar las conexiones electrónicas entre el GPIO 18 (según la nomenclatura de la librería Diozero y Broadcom, 12 según la nomenclatura del header y 1 según la de wiringPi) y la resistencia además de entre el diodo y la línea de tierra. Los diodos LED poseen una orientación y hay que conectar la resistencia con el polo positivo del diodo LED, el polo positivo del diodo LED identifica porque es la patita larga y el negativo con tierra es la patita corta. Si realizamos la conexión al revés solo pasará que el diodo no se enciende pero no lo estropeará, la resistencia si es necesaria para no hacer que pase por el diodo una intensidad que lo estropee como se explica en ¿Qué resistencia ooner a un LED?.

Diodo blanco y resistencia de 200 ohmios

Las resistencias poseen cuatro bandas de colores que indican el valor en ohmios de esa resistencia, la tabla de colores es el siguiente:

Código de colores de las resistencias

El programa Java para hacer parpadear el diodo LED con la librería Diozero con el proveedor pigpio. El ejemplo consiste en activar y apagar el pin sucesivamente en un bucle y usar el método Thread.sleep para que pase unos segundos entre uno y otro y nos de tiempo a ver el encendido y apagado. El nada complejo programa Java para controlar el diodo y un vídeo de su funcionamiento están a continuación.

En un artículo anterior comento como disponer de un entorno para desarrollar, desplegar las librerías jar en la Raspberry Pi y como ejecutar los ejemplos desde la línea de comandos usando una combinación de herramientas de SSH, rsync y Ansible.

El código fuente completo del ejemplo puedes descargarlo del repositorio de ejemplos de Blog Bitix alojado en GitHub y probarlo en tu equipo ejecutando el comando ./gradlew executePinBlink.

.NET/.NET Core

• The week in .NET – Visual Studio 2017, .NET Core SDK, F# 4.1, On .NET with Phillip Carter, Happy Birthday from John Shewchuk, FNA, Pyre
  Bertrand Le Roy
• New Features in C# 7.0
  Mads Torgersen
• Announcing .NET Core Tools 1.0
  Rich Lander
• Announcing F# 4.1 and the Visual F# Tools for Visual Studio 2017
  Visual F# Team
• Day 11 - Exploring .NET Core with Visual Studio 2017 and the updated CLI Tools
  Michael Crump
• C# BAD PRACTICES: Learn how to make a good code by bad example – Part 4
  Radosław Sadowski
• Debugging the Web Browser Control with FireBug
  Rick Strahl
• Do I need to use ConfigureAwait(false) all the way?
  Daniel Wertheim
• It's about time you start using these C# 6 features
  Carlos Schults
• Some ways to tame magical strings in .NET and C#
  Daniel Wertheim

ASP.NET/ASP.NET Core

• Content-Security-Policy in ASP.NET MVC
  Thomas Ardal
• Testing an ASP.NET Core MVC Protobuf API using HTTPClient and xUnit
  Damien Bowden
• ASP.NET Core Response Cache
  Gunnar Peipman
• What is the Microsoft.AspNetCore metapackage?
  Andrew Lock
• Environment Variables in ASP.NET Core
  Derek Comartin
• Exploring ASP.NET Core View Component
  Brij Bhushan Mishra
• Customising ASP.NET MVC Core Behaviour with an IApplicationModelConvention
  Steve Gordon
• Supporting both LTS and Current releases for ASP.NET Core
  Andrew Lock
• Convention-Based Application Startup in Multiple Environments
  Hisham Bin Ateya
• ASP.NET Core: How log filtering works
  Gunnar Peipman
• Making an event calendar for trucking or shipping with jQuery.Fullcalendar
  Member 11883797

Azure / Cloud

• Sentiment Analysis using Microsoft’s Cognitive Services
  Robin Osborne
• Using the Cognitive Recommendations API in Bots and Websites
  Martin Kearn
• How to map a naked domain to an Azure App Service
  Benjamin Perkins
• DocumentDB In The Microsoft Azure
  Kishore Chowdary
• Announcing general availability for MySQL in-app
  Mksunita
• Convert PDF files to PNG Images using Azure Functions
  Michael Washington
• New Azure Storage JavaScript client library for browsers - Preview
  Sercan Guler

Conceptos/Patrones/Buenas prácticas

• Hack that GUID
  Mehdi Khalili
• Mutability vs. Immutability: Valid objects
  David Raab
• Is Your Code Hard to Understand?
  Erik Dietrich

Data

• Changes to EF Core With the RTM of VS2017 and Tools
  Julie Lerman
• BulkInsert with the Entity Framework
  Måns Tånneryd

Html/Css/Javascript

• Learn about CSS Architecture: Atomic CSS
  Tiffany Brown
• Experiencias en el desarrollo de aplicaciones SPA corporativas
  Ricardo Borillo
• JavaScript Libraries In A TypeScript Application, Revisited
  Nic Raboy
• A Note on Angular 2 Bootstrap Multiple Apps
  Dr. Song Li
• Introduction to Web Audio API
  Greg Hovanesyan
• TypeScript 2.2: Dotted Properties and String Index Signatures
  Marius Schulz
• Announcing NuGet 4.0 RTM
  Anand Gaurav
• Unit Testing Self-Invoking JavaScript Functions
  Bendix Saeltz
• HTML5 Forms: Input Types (Part 1) Alexis Goldstein, Estelle Weyl & Louis Lazaris
• 13 Best JavaScript Data Grid Libraries
  Dev Code Geek
• TypeScript 2.2 Release Gives JavaScript Developers More of What They Expect
  David Iffland
• The Observer Pattern in Javascript
  Alvie Amar
• HTML canvas cheat sheet
  Skilled.co
• Getting JavaScript Properties for Object Maps by Index or Name
  Rick Strahl
• JSON's Crockford envisions a post-JavaScript world
  Paul Krill
• Do you know JavaScript? Are you sure? – Part Two
  Sibeesh Venu

Visual Studio/Complementos/Herramientas

• Announcing Visual Studio 2017 General Availability… and more
  Julia Liuson
• Visual Studio 2017: Productivity, Performance, and Partners
  John Montgomery
• Optimize your productivity with .NET in Visual Studio 2017
  Kasey Uhlenhuth
• Redgate Data Tools in Visual Studio 2017
  Jeff Gao
• Run To Click Debugging in Visual Studio 2017
  Kaycee Anderson
• Live Unit Testing in Visual Studio 2017 Enterprise
  Joe Morris & Manish Jayaswal
• Reattach To Process in Visual Studio 2017
  Kaycee Anderson
• Announcing New ASP.NET Core and Web Development Features in Visual Studio 2017
  Jeffrey T. Fritz
• Conéctate a tu base de datos desde Visual Studio Code
  Gisela Torres
• Productivity Power Tools for Visual Studio 2017
  Justin Clareburt
• New Git Features in Visual Studio 2017
  Kayla Ngan

Cross-platform

• Better Apps Faster with Visual Studio 2017 and Xamarin
  Miguel de Icaza

Otros

• Programadores Políglotas y Proyectos Políglotas
  Juan María Hernández
• The Developer’s Edge: How To Become A Senior Developer
  Andrei Neagoie
• The mythical 10x programmer
  Salvatore Sanfilippo (Antirez)

Lo que pongo aquí es solo un experimento. Como dije en mi anterior post, me encanta Blender para hacer montajes de vídeo y para mí, es el mejor editor de vídeo disponible para GNU/Linux. Aunque tiene un pequeño defecto, bueno, muy grande… apenas tiene efectos para los vídeos, por lo que si quieres algún efecto que no sea un crossfade, una corrección de color, o un blur, vas a tener que hacerlo de otra forma y eso implica exportar vídeo y luego importarlo cuando esté hecho. Con el gran inconveniente de que si el efecto no ha quedado exactamente como quieres, si de verdad te quedan ganas para modificarlo tienes que repetir el proceso.

Me gustan los efectos, y quiero hacer pruebas, porque no había mirado mucho el código fuente de Blender, me parece una bestia, tiene muchas cosas, y partes que se han quedado un poco viejas, como es el VSE (Video Sequence Editor), el módulo de Blender que más utilizo. Así que, ¿por qué no empezar a crear algunos efectos?

Construyendo Blender

Lo malo de todo esto, es que al contrario que con programas privativos, Blender no soporta plugins para efectos. Lo hizo en el pasado, pero por razones que no llego a comprender (supongo que relacionadas con el mantenimiento, con que nadie quiso hacerse cargo del módulo y con que tal vez les reportaban muchos fallos sobre efectos cuando el fallo no estaba en Blender, sino en el que realizaba el propio efecto). Lo malo, es que si queremos incluir un nuevo efecto en Blender, debemos recompilar nuestra versión de Blender. No tarda mucho, pero tiene algunas dependencias algo pesadas. Una vez que lo has hecho, las siguientes compilaciones no tardarán mucho, ya que sólo compila el código nuevo (lo que hacemos nosotros).

Bueno, he dicho que Blender no tiene API… ¡claro que tiene! Lo malo es que es una API en Python, y personalmente (que lo he probado), efectos que renderizan a 25fps hechos en C, van a 0.3fps hechos en Python. Es cierto que no he utilizado ninguna de las fantásticas bibliotecas de imagen digital disponibles para Python, pero de todas formas hay que hacer que el vídeo se exporte a Python, y sólo lo he conseguido hacer con alguna guarrada que me da vergüenza mencionar aquí…

Lo primero es decargarte el código fuente de la página principal o del git oficial de Blender (git://git.blender.org/blender.git). Si vas a compartir lo que haces con la comunidad, te recomiendo utilizar git para poder enviar parches y demás.

El caso es que si queremos compilar Blender, necesitamos un entorno de compilación GCC, y las siguientes bibliotecas con sus cabeceras para programación: python, numpy, libx11, libjpeg, libpng, boost, ffmpeg, libopencolorio, libilm, libopenexr y algunas más. Las encuentras todas en blender/build_files/build_environment/install_deps.sh

Antes de meterme con código

Si echas un vistazo por encima al código parece muchísimo, ¡ pero no es tanto ! Como es un programa tan grande, en muchos archivos, para que sepamos qué tenemos que tocar. Como no puedo decir la línea exacta ya que este programa se modifica a menudo he decidido poner unas cuantas líneas, o funciones completas a modo de referencia. Cuando lo que nos afecta es lo referente a CUSTOM_EFFECT.

¡Empezamos con la aventura!

Botón en la interfaz

Lo primero, es que desde la interfaz podamos añadir un nuevo efecto. Que cuando estemos en el secuenciador, pulsando Shift+A -> Effect aparezca nuestro efecto en el menú, para eso, tenemos que editar

Para eso, editamos el archivo source/blender/makesdna/DNA_sequence_types.h y añadimos una nueva constante con nuestro effecto. Mi efecto se llamará CUSTOMEFFECT, además, incrementamos SEQ_TYPE_MAX. En mi caso, la cosa queda más o menos así (cerca de la línea 500, en la versión 2.78c):

Nuestro efecto, tendrá el índice 42, aunque no nos importa mucho la posición que ocupe. Ahora vamos al archivo source/blender/editors/space_sequencer/sequencer_edit.c, metemos el mismo efecto:

Dentro de cada elemento del array tendremos:

• Índice, para lo que cogemos un valor de nuestro enum de antes. Será de uso interno,
• String clave, será una cadena en clave, que manejaremos desde Python para referirnos al efecto.
• El 0 siguiente indica que no hay icono asociado, por ahora no tenemos iconos
• Luego el nombre del efecto, para mostrarlo
• Por último, la descripción del efecto

Ahora en el archivo source/blender/makesrna/intern/rna_sequencer_api.c:

Seguimos con la interfaz de Python. Para que el elemento aparezca en el menú debemos incluir lo siguiente en el archivo release/scripts/startup/bl_ui/space_sequencer.py (añadir la última línea, más o menos alrededor de la línea 380, blender 2.78c):

Ahora definimos el color del elemento una vez lo pongamos en la línea de tiempo. Para ello en source/blender/editors/space_sequencer/sequencer_draw.c vamos a la función color3ubv_from_seq() donde, dentro del case, dejamos algo como esto (es aproximado, podemos definirle el color si queremos, pero yo me he basado en el color de otros elementos parecidos):

Si compilamos y ejecutamos Blender, seguramente nuestro efecto aparezca y lo podremos añadir, pero no hará nada, sólo soltar errores por la consola.

Definiendo algunas propiedades

Debemos definir antes de continuar algunas propiedades básicas del strip. En source/blender/makesrna/intern/rna_sequencer.c haremos varias modificaciones. Primero, en la función rna_def_sequence() (alrededor de la línea 1380), volvemos a meter nuestro efecto:

Luego en la línea 2390 más o menos modificamos la estructura def_effects añadiendo la definición de nuestro nuevo efecto:

Donde, el 1 que acompaña la declaración del efecto es el número de entradas que necesitamos. Al aplicarse sobre otro strip, necesitamos un 1 aquí. Si fuera un generador, sería 0 y una transición tendría 2.

Ahora, junto con los demás efectos (línea 2100 más o menos), creamos la función rna_def_customeffect donde definiremos los parámetros que se podrán tocar de nuestro efecto, que luego tendremos que vincular con Python, que no se nos olvide:

Y añadimos nuestro efecto a la función rna_sequence_refine():

Por último en source/blender/makesrna/RNA_access.h metemos esta línea, más o menos en la 280:

Insertamos las propiedades de nuestro efecto

Por ahora sólo estoy metiendo una, y no hace nada, sólo estar ahí, pero me sirve como plantilla para futuros efectos. Antes de que se nos olvide, vamos a añadirla desde la interfaz de Python. En el archivo en el archivo release/scripts/startup/bl_ui/space_sequencer.py en la clase CLASS_PT_EFFECT(), al final del todo añadimos nuestro efecto:

Ahora declaramos las propiedades de nuestro efecto. Para ello en el archivo source/blender/makesdna/DNA_sequence_types.h insertamos lo sigueinte (cerca de la 290, junto con los demás efectos, ya los veréis):

Mi propiedad se llamaba property, porque soy muy original, pero aquí pondremos las que necesitemos. Podremos poner arrays de char para cadenas de caracteres, char, short para flags, enteros y float, por ejemplo, los colores van en float. Podríamos poner otros tipos de variable, pero no he probado… no soy tan valiente.

Para que las propiedades de nuestro efecto se guarden cuando salvamos el archivo .blend hacemos, editamos source/blender/blenloader/intern/writefile.c añadiendo la estructura de nuestro efecto, alrededor de la límea 2660:

Definiciones de nuestro efecto

Ya va quedando menos, tenemos esto casi configurado, sólo quedan algunos callbacks con las llamadas que hacen los propios filtros, vamos, ahora es cuando nuestro filtro hace algo, aunque es necesario definirlo para que el programa no explote:

En el archivo source/blender/blenkernel/intern/seqeffects.c encontramos el código de estos efectos. Lo primero será introducir las definiciones de nuestro efecto en la función get_sequence_effect_impl() en la línea 3315 o así, buscamos los efectos del switch y ponemos el nuestro al final:

Aquí definiremos:

• rval.init : función que inicializa nuestro efecto
• rval.num_inputs : número de strips de entrada que necesita nuestro strip. Los efectos necesitan estas sobre un strip, las transiciones sobre dos, los generadores no necesitan strips.
• rval.free : Qué hacemos cuando se quita nuestro efecto (para liberar memoria)
• rval.copy : Qué hacer cuando copian nuestro efecto.
• rval.early_out : A veces, podemos saber si es necesario o no aplicar el efecto antes de ponernos a procesar. Aquí veremos si procesamos, si devolvemos el valor de la entrada, o no devolvemos nada
• rval.execute : NUESTRO EFECTO !!!
• rval.supports_mask : ¿Soporta máscaras? (es un booleano, no un callback
• rval.load : Qué hacer cuando se acaba de cargar el efecto?
• rval.init_execution : Este callback se ejecutará antes de hacer el render de nuestro efecto.
• rva.multithreaded : El efecto soporta threads. Y en lugar de llamar a rval.execute se llamará a rval.execute_slice, por lo que si hacemos nuestro efecto multihilo tendremos que hacerlo independiente de las líneas de origen y fin que nos pasen (Blender ya se encarga de crear hilos y de todo lo demás, nosotros sólo tenemos que definir lo que hace cada uno).

Encontraremos toda la información en source/blender/blenkernel/BKE_sequencer.h

Como todo lo que hemos puesto son callbacks, tendremos que definirlos, voy a poner todo el código seguido, pero si queréis tenerlo ordenado buscad funciones parecidas de otros efectos y poned el vuestro por ahí:

¡Y listo! Si compilamos Blender ya tenemos nuestro efecto.

En la función do_custom_effect_effect(), tenemos los siguientes parámetros para la entrada:

• const SeqRenderData *context : El contexto, aquí tenemos acceso a muchísimas cosas, demasiado para enumerarlo aquí, pero accedemos a la estructura Main que contiene casi todo, podemos acceder a la escena, elementos guardados y miles de cosas más.
• Sequence *seq : Toda la información del strip actual
• float cfra: Fotograma actual, puede tener un error de +-0.5 frames.
• float facf0: Cuando estamos operando con contenido entrelazado y estamos animando un efecto, qué porcentaje de efecto recae sobre el campo 0?
• float facf1: lo mismo pero para el campo 1.
• ImBuf *ibuf1, ImBuf *ibuf2, ImBuf *ibuf3: Son las imágenes asociadas al efecto, dependiendo del efecto, habrá varias imágenes implicadas en él.

Y… como extra, si no estamos utilizando una variable, pero la queremos dejar ahí, para que el compilador no se queje podemos envolverla con la macro UNUSED()

La comunidad Blender

En https://developer.blender.org/ encontramos un sistema en el que se ponen en común bugs y pequeñas características (si quieres colaborar en algo grande, tienes que contactar con ellos). Y actualmente el secuenciador lo tienen un poco abandonado, de todas formas, hay una parte importante de la comunidad que sigue ahí, enviando parches y mejoras.

The post Experimento: Creando un nuevo effecto de imagen para el secuenciador de vídeo de Blender (VSE) con código fuente appeared first on Poesía Binaria.

<Disclaimer>Todo lo que comentaremos a continuación son detalles de la implementación actual del framework y son válidos en la versión 1.1 de ASP.NET Core, pero podrían cambiar en futuras versiones.</Disclaimer>

public async Task Invoke(HttpContext httpContext)
{
    [...]
    using (var feature = new RequestServicesFeature(_scopeFactory))
    {
        try
        {
            httpContext.Features.Set<IServiceProvidersFeature>(feature);
            await _next.Invoke(httpContext);
        }
        finally
        {
            [...]
        }
    }
}

Últimamente he estado montando mis páginas web en un servidor VPS.

Mi intención es dedicar una serie de artículos a esto en las próximas semanas, pero antes quiero dejar escritas las motivaciones para hacerlo y algunas ideas previas.

¿Por qué montar un VPS?

1. Me gusta “jugar” con servidores. Esta es la verdadera razón. He tenido mis páginas en un hosting compartido desde hace mucho, y es obvio que no tener que ocuparte tú del mantenimiento de los servidores es una ventaja, pero varias veces había tenido la tentación de montar un VPS y al final me he decidido.
2. He encontrado un VPS de muy buen precio. En ocasiones he arrancado un VPS en DigitalOcean durante horas o días, para hacer alguna prueba, pero el precio que quería pagar sólo me permitía acceder al Droplet más pequeño, y me daba la sensación de que con sólo 512Mb de RAM se podía quedar corto. Ahora he encontrado otro que por el mismo precio o menos me proporciona 2Gb de RAM (más sobre esto próximamente)
3. Me permite acceder a funcionalidades extra. Por ejemplo: Let’s Encrypt. Con la web moviéndose hacía https (y con un servicio como Let’s Encrypt, que nos ofrece certificados gratuitamente) quería sumarme a esta tendencia, pasando mis webs a https. Algunos proveedores de hosting compartido ya ofrecen soporte para Let’s Encrypt, pero el que yo usaba no lo hacía. Puestos a cambiar de hosting compartido, he decidido el do it yourself de un VPS.

¿Por qué utilizar Docker?

1. Por probar una nueva tecnología. Nuevamente, no hay que buscar más razones que las ganas de “jugar” con una nueva tecnología. He leído sobre Docker, he hecho algunas pruebas, pero no hay nada como tener que pelearte de verdad con una tecnología para aprender sobre ella.
2. Quiero poder cambiar rápidamente de VPS. Es obvio que el VPSbarato me puede salir rana. Aunque he hecho unas cuantas pruebas y todo parece funcionar bien, quiero tener un plan B, poder pasarme a otro VPS rápidamente en el caso de que el rendimiento no sea el esperado. Montando todo con Docker (servidores de BBDD, servidores web, etc) puedo simplemente desplegar los contenedores en otro VPS y automáticamente tener todo funcionando sin más que apuntar los DNS a la nueva IP.

Llegamos a final de año, época de tradiciones, y fiel a las mías toca escribir un post con el resumen de lo que ha sido el 2017 para el blog. Un post sazonado con algo de porno de estadísticas y un refrito de posts destacados, pero sin mucha más intención que despedir el año.

Estadísticas

Para mi lo más importante de escribir en el blog es aprender y divertirme. Desde esa perspectiva, los números no son demasiado importantes, pero siempre es entretenido echarles un vistazo.

Este ha sido el año que menos posts he escrito, sólo 23 posts. Eso me deja a 1 del objetivo que me había marcado, en el que ya daba por hecho que este iba a ser un año complicado. A cambio he aumentado mi actividad fuera del blog, con target=”_blank”>una charla sobre testing, un webminar sobre ClojureScript y la asistencia a las dos ediciones de DeveloperOS.

Mi objetivo para el año que viene vuelve a ser escribir 24 posts. Considerando que desde el 6 de marzo de este año tengo otras cosas más entretenidas en mi vida, me conformo con esto.

Según Google Analytics, han sido 175.000 visitantes en unas 230.000 sesiones con 300.000 páginas vistas. Comparado con el año pasado, es un descenso de entre el 12% y el 20%, según la métrica que tomes.

En este descenso influye claramente haber escrito menos posts, pero también se sigue viendo una tendencia que empezó hace unos años según iba dejando de escribir de temas de moda y hacia cosas más genéricas. Eso hace que los posts tengan muy buena acogida en twitter y me den para conversar y aprender, pero que luego no sean muy visitados desde Google. No creo que eso cambie a corto plazo, porque me resulta mucho más satisfactoria y útil una buena conversación, que un post con miles de visitas que vienen buscando un fragmento de código para copiarlo sin entenderlo.

Lo más visitado

El top 5 del año es:

1. Tratar con Fechas en JSON en Javascript y TypeScript.
2. Evitar la deuda técnica es un error.
3. No pierdas el tiempo escribiendo tests.
4. Cómo testear el frontend de una aplicación web.
5. De monos, melanesios y desarrollo de software.

Excepto el primero, que es un post más práctico y aburrido, el resto coincide bastante con mis preferencias personales. Disfruté especialmente escribiendo sobre monos y melanesios. De los que se quedan fuera, me gustó explicar cómo crear un diccionario persistente en 4 líneas de javascript y creo que fue importante hablar de los problemas de ignorar la persistencia.

Hasta el año que viene

Con esto doy por cerrado el año en el blog. Ahora toca descansar desconectar un poco, maltratar el organismo con comidas copiosas y “disfrutar” de todos los eventos navideños.

¡Feliz 2018 a todos!

Posts relacionados:

1. Resumen 2016
2. Resumen 2013
3. Resumen 2014

.NET / .NET Core

• Hybridizer: High-Performance C# on GPUs
  Florent Duguet & Régis Portalez
• C# - All About Span: Exploring a New .NET Mainstay
  Stephen Toub
• Open Source .NET – 3 years later
  Matt Warren
• A look at the internals of ‘Tiered JIT Compilation’ in .NET Core
  Matt Warren
• Interpolated strings: advanced usages
  Gérald Barré
• Replace a Running Application with a New Version
  Tim Patrick
• Boost your productivity with Visual Studio’s DebuggerAttributes
  Moaid Hathot
• How Does Task in C# Affect Performance?
  Jeremy Bytes
• Controlling the Number of Outgoing Connections From HttpClient (.NET Core or Full Framework)
  Pam Lahoud
• Devirtualization in .NET Core
  Jonathan Allen
• 5 .NET Standard Features You Shouldn’t Miss
  Ed Charberneau
• How to avoid overlapping timer calls?
  Gunnar Peipman
• Norma ISO 8601, duration y .NET
  Jorge Serrano

ASP.NET / ASP.NET Core

• Five RESTFul Web Design Patterns Implemented in ASP.NET Core 2.0 Part 4: Optimistic Concurrency
  Jeremy Likness
• Building ASP.NET Core apps using Cake in Docker
  Andrew Lock
• How to Implement single authorization policy in ASP.NET Core 2.0
  Talking Dotnet
• Runtime bundling and Minification in ASP.NET Core with Smidge
  Anuraj Parameswaran
• Image Optimization in ASP.NET Core Application
  Chilezie Reginald Unachukwu
• Export Excel and CSV file in Asp.Net Core
  Janak Shrestha
• [Required] and [BindRequired] in ASP.NET Core MVC
  Filip Woj

Azure / Cloud

• A Basic Bot using Azure Bot Services
  Arun Sirpal
• Take a Break with Azure Functions
  Justin Clareburt

Conceptos / Patrones / Buenas prácticas

• Commented Out Code Is Junk In Your Codebase
  Erik Dietrich

Data

• Reverse Engineering Existing Databases in Entity Framework Core 2
  Shawn Wildermuth
• A Walk Around SQL Operations Studio
  Robert Cain
• Rebuilding Indexes Can Slow Queries Down
  Brent Ozar
• Storing JSON documents in SQL Database
  Jovan Popovic
• Get Started with CosmosDB SQL API
  Jeremy Likness
• Connecting Localdb using Sql Server Management Studio
  Anuraj Parameswaran

HTML / CSS / Javascript

• Todo sobre los enlaces en HTML
  Pablo Iglesias
• Operador Rest, Javascript ES6
  Miguel Ángel Álvarez
• Upgrade Angular 4 app to Angular 5 with Visual Studio 2017
  Talking Dotnet
• The Future of jQuery UI and jQuery Mobile
  Alex Schmitz
• 10 Best HTML5 Sliders for Images and Text
  Nona Blackman
• Implementing JavaScript Functors and Monads
  Rubens Pinheiro Gonçalves
• JavaScript — Map vs. ForEach
  Brandon Morelli

Visual Studio / Complementos / Herramientas

• Meet ReSharper Ultimate 2017.3
  Alexander Kurakin

Xamarin

• [Xamarin.Forms] Uso de SQLite, múltiples tablas, relaciones y operaciones en cascada
  Javier Suárez

Otros

• La RAE añade una acepción positiva al término “Hacker”. ¡Gracias @RAEInforma!
  Chema Alonso

En enero de 2018, el Museo Reina Sofía de Madrid acogerá la exposición Bugs, una exposición dedicada a esas obras de arte que muchas veces pasan inadvertidas, los bugs.

En esta exposición, que se expondrá hasta el 1 de abril de 2018, podremos ver algunos de los máximos exponentes de este estilo artístico surgido a finales del siglo XX y muy popular en el siglo XXI. Como yo mismo he formado parte del comité de selección de obras, tengo el honor de regalar dos entradas dobles para la exposición.

«Queremos reunir en un mismo edificio todas las sensaciones que han provocado a los usuarios. Rabia, indignación, ira y soledad.» dice Sara Echeverría, directora de exposiciones temporales del Reina Sofía y buena amiga.

Algunas de las obras, más destacadas son:

Pantalla azul de Windows sobre monitor Samsung

Pantalla azul de Windows sobre monitor LG y cables desordenados

Pantalla azul de Windows rotada PI/2 radianes en aeropuerto

«Las pantallas azules nos transmiten finalidad. Nos hacen ver que todo es efímero. Todo nuestro trabajo, nuestra huella en la humanidad, puede desvanecerse con un simple error de driver. Al final, no somos nada. Una gota más, del océano inmenso.» dice Bill Gates, que fue invitado para preparar la exposición. «Creemos que Bill Gates es uno de los maestros en el arte del bug, su ayuda nos ha sido indispensable para encontrar el enfoque filosófico que buscábamos».

Final de un programa en LISP

«A mí siempre me han atraído los paréntesis de LISP. Era como algo sexual. Sentía orgasmos al descubrir que podía meter más paréntesis todavía.» Y es que en la exposición también se verán obras proclives a bugs como los paréntesis de LISP o la sagrada trinidad de JavaScript.

«JavaScript iba a llenar bastantes salas, así que solamente hemos elegido lo mejor. Ha sido difícil, porque cada día salen nuevos e impresionantes bugs, en cada nueva librería o framework. Habrá que estar atentos a ellos, porque son el futuro de los bugs»

También se ha dejado una sala especial a los ciberataques, que este año han sabido aprovechar con mucha intelegencia bugs de los sistemas operativos más conocidos. ¿Cómo olvidar el WannaCry de Edvard Munch?

WannaCry, de Edvard Munch

Pero no sería  una exposición completa sin contar con bugs como el efecto 2000 o el lanzamiento del cohete Ariane 5 (esas cosas pasan por usar ints de 16 bits en un cohete).

Si queréis participar para ganar una de las dos entradas dobles para ver la exposición, solo tenéis que hacer click aquí.

La entrada Gana dos entradas dobles para “Bugs” en el Museo Reina Sofía aparece primero en Blog - Adrianistan.eu.

Si estás interesado en la tecnología, informática en general y en el software libre, código abierto y GNU/Linux estoy más que seguro que las siguientes listas de películas, series, documentales y libros te gustarán bastante. Probablemente algunas ya hayas visto pero otra quizá no conocías o aún no has visto y este artículo te anima a ver. En el momento de escribir esto aún no he visto todo el contenido de este artículo pero con esta lista lo tengo anotado y pendiente de ver.

Películas

• Piratas de Silicon Valley
• Trabajo basura (Office Space)
• Juegos de guerra
• Blade Runner, Blade Runner 2049
• La red social
• Jobs
• Steve Jobs
• TRON, TRON: Legacy
• Blackhat. Amenaza en la red
• Conspiración en la red, AntiTRUST
• Terminator, Terminator 2: El juicio final, Terminator 3: La rebelión de las máquinas, Terminator Salvation, Terminator Génesis
• Los fisgones (Sneakers)
• Otras películas sobre hackers

Series

• Black Mirror
• Mr Robot
• Silicon Valley
• Halt and Catch Fire
• The IT Crowd
• Scorpion
• Odio canibal

Documentales

• El triunfo de los nerds
• La historia de la computadora y computación
• La historia secreta de los hackers
• Code Rush
• La revolución virtual
• Documental Bill Gates
• La historia de Aaron Swartz. El chico de Internet
• Historia de los primeros videojuegos
• La era de los videojuegos, II, III, IV
• Atari: Game Over
• Gameplay - La historia de los videojuegos
• Good Copy Bad Copy
• Info wars
• Lo and Behold: Reveries of the Connected World
• The machine that changed the world
• Nerds 2.0.1, II, III
• Welcome to Macintosh
• Steve Jobs: One last thing

En YouTube hay cantidad de documentales más.

Documentales sobre el software libre y código abierto

• El software libre es como el pastel de la abuela
• El software libre
• Software Libre: La comunidad sin amos
• Entrevista a maddog
• ¿Qué es el software libre y por que es tan importante para la sociedad?
• Código Linux
• Revolution OS

Probablemente ya conozcas el software libre, o quizá no, en cualquier caso te recomiendo que veas una de las conferencias de Stallman da en numerosos lugares y en las que da a conocer el software libre y promueve su uso. Cuales son los motivos éticos, morales, de seguridad y prácticos por los que preferir software libre en vez de software privativo. Si te convence y usas otros sistemas operativos como Windows o MacOS puedes empezar a conocer las distribuciones de GNU/Linux y elegir una distribución GNU/Linux de entre las varias que hay disponibles.

• Conferencia Richard Matthew Stallman
• Preguntas Richard Matthew Stallman
• Entrevista en Español con Richard Stallman, «Software Libre»

Libros y novelas

• El circulo de Dave Eggers
• Microsiervos de Douglas Coupland
• Cuando los administradores de sistemas gobernaron la tierra de Cory Doctorow
• Criptonomicon de Neal Stephenson
• Snow Crash de Neal Stephenson
• Ready Player One de Ernest Cline
• ¿Sueñan los androides con ovejas eléctricas? de Philip K. Dick
• Algunas novelas sobre informática y hackers

¿Conoces alguno imprescindible más que incluir en esta lista?