Photo obtenida en Visualhunt

No sé si habrás tenido una experiencia similar. Recuerdo la primera vez que me senté en mi puesto y empecé a recibir formación sobre el software que tendría que utilizar en la empresa de desarrollo de aplicaciones que me acababa de contratar. Windows, Outlook, Internet Explorer, Office... todo iba muy bien hasta que entramos en el apartado del CMS y de la plataforma web (Content Management System o Sistema de Gestión de Contenidos) que usaban en la empresa. ¡Menudo horror!

Obviando ya todo el tema de diseño a nivel visual, aquello era impracticable y tenía graves problemas de funcionalidad. La empresa en concreto estaba especializada en hacer software de contabilidad, pero por alguna extraña razón a uno de los socios-fundadores se le dio por crear su propio CMS para gestionar los contenidos de la web de la empresa ya que ninguna de las opciones del mercado satisfacía sus necesidades. No digo que sobre el papel la idea no fuera buena, pero aquello en ejecución era un verdadero lastre.

Mi experiencia laboral hasta la fecha nada tenía que ver con el sector del software, aunque sí tenía experiencia trabajando plataformas tipo Drupal y WordPress. Algo de CMS sabía, sobre todo a nivel usuario, y ambas plataformas me parecían impresionantemente buenas desde que salieron (15 años después siguen siendo de las más utilizadas y han evolucionado muchísimo).

Pasaron un par de años y aquel CMS no nos los sacábamos de encima ni con ácido. Aquel CMS seguía allí pero ya yo no era la misma persona, había cogido algo de experiencia en el sector de la programación desde la óptica de una persona con una formación no técnica (soy de letras, sí), y empezaba a entender un poco toda la idiosincrasia de los desarrolladores de software y el porqué de la supervivencia de aquel CMS infumable en una empresa líder del sector en la venta de aplicaciones de Contabilidad.

Para poder entenderlo tuve que hacer un ejercicio de empatía. Por ejemplo, a la mayoría de las personas por naturaleza les resulta más fácil y agradable hablar que escuchar. Les resulta más fácil contar su "película" y que los demás la escuchen que al revés.

Para un chef comer la comida de otro colega nunca será tan satisfactorio como cocinar la suya para que la disfruten otros, y para un músico escuchar los temas de otro nunca será tan motivador como tocar sus propias canciones para entretener a los demás.

Pues lo mismo es cierto en el desarrollo de software. La mayoría de los desarrolladores prefieren ser conocidos como aquel fenómeno que desarrolló el framework de interfaz de usuario en la que ahora se basa toda la empresa, que ser simplemente el tipo que hizo la sugerencia de usar Furatto y que le ahorró horas de trabajo a la empresa, por ejemplo.

Para un programador, leer código de otros nunca será tan satisfactorio como escribirlo por sí mismo.

¿Qué hay detrás de todo esto?

Detrás evidentemente está el síndrome del "No inventado aquí", que no es más que una forma irónica y sutil de llamarle a la tendencia que tienen tanto los desarrolladores como las empresas de software de rechazar soluciones perfectamente válidas de terceros para dar salida a problemas de desarrollo, y optar por soluciones desarrolladas internamente en la empresa. Un primo-hermano de este síndrome es el "vamos a reinventar la rueda".

Este síndrome tiene diferentes intensidades, que van desde un sentirse moderadamente reacio a aceptar nuevas ideas hasta el extremo de tener un odio visceral a cualquier software externo rozando ya la "xenofobia". Podemos definir el síndrome de "No inventado aquí" (de ahora en adelante NIA) como una situación en la que una solución externa es rechazada tan solo porque no ha sido desarrollada internamente -en otras palabras, no existen otros factores que dictaminen que un software desarrollado internamente vaya a ser mejor.

Si somos honestos con nosotros mismos, a la mayoría de nosotros nos resulta un poco difícil de admitir que otra persona ha tenido una mejor idea que nosotros, o hizo un mejor trabajo (o al menos tan bueno como el nuestro) a la hora implementarlo de lo que podríamos haberlo hecho nosotros.

Hay también un cierto "instinto de la manada" que conduce irremediablemente al síndrome NIA en algunas organizaciones. Si tradicionalmente la práctica dentro de la organización ha sido la de desarrollar todo el software nuevo internamente, lo más fácil es dejarse llevar por la cultura empresarial en lugar de buscar introducir ideas relativamente radicales de traer todo o, peor, parte de un nuevo software de "fuera".

Muchas empresas de la industria del software caen presa de esta causa del síndrome. Tienen recursos de desarrollo internos, razonan, ¿por qué no deberían utilizarlos, en lugar de fiarse de desarrollos de software de terceros?

La existencia de aplicaciones o bibliotecas heredadas también puede crear un caldo de cultivo ideal para el síndrome NIA. Como diría uno de mis antiguos jefes:

     "Nuestros desarrolladores en plantilla han trabajado durante años el desarrollo de esta enorme biblioteca con funciones y métodos para todo, ¡no vamos a tirarlo todo ahora por la borda!"

En estos casos da lo mismo que exista una versión superior de la misma funcionalidad y que ahora está incorporada a cada runtime estándar de Java que sale, por ejemplo, o que una versión mejor se pueda descargar de forma gratuita de la fundación Apache, ¡da igual! Este software es "el nuestro".

Al igual que a los desarrolladores que llevan a cabo la refactorización puede resultarles difícil descartar un código en favor de un enfoque mejor, a las empresas les puede costar incluso más desechar su propio software. Incluso en situaciones en las que el mantenimiento continuo del monstruo obsoleto se convierte en una soga atada al cuello de la empresa.

Si bien desde fuera esta actitud parece irrazonable, se acepta muy a menudo simplemente como la forma en que las cosas se hacen en algunas organizaciones, escudándose en conceptos aleatorios inventados como la "cultura empresarial", argumento que se esgrime cuando ya no hay un planteamiento objetivo ni razonable detrás. Se podría traducir como "porque así lo quiere el jefe y punto, que es el que paga los sueldos".

También se da el caso, y cada vez más en este sector hiperactivo, de desarrolladores y empresas de mentalidad abierta que aún no son conscientes de que ya existe en el mercado un software que es justo lo que necesitan. La mayoría de los proyectos de código abierto carecen de publicidad o no se comunican bien, y quizás un programador se ha puesto a buscar y no encuentra lo que necesita, pensando que esa solución no existe y decide programarla de cero. En verdad esto no es síndrome NIA, sino falta de información. Cada vez ocurre menos, pero sigue pasando.

¿Por qué se ha propagado tanto este síndrome NIA en la industria del desarrollo de software?

Existe una creencia generalizada en Silicon Valley (la cuna y el germen de todo esto), y en el mundo tecnológico en general, de que las empresas deben "comer su propio pienso" (del inglés "eat your own dog food"), que es sólo una manera de decir que una empresa debe utilizar sus propios productos de software.

Si bien esto tiene sentido hasta un punto -no debes vender algo a los clientes que no es apto para tu propio uso-, el concepto NIA es similar, pero lleva esta línea de pensamiento al extremo. En este sentido, el término se utiliza generalmente de forma negativa y se refiere a alguien cuyas habilidades de toma de decisiones se ponen en entredicho debido a este sesgo.

Si no hago páginas web, por mucho software ERP que desarrolle, quizás es mejor subcontratar su desarrollo y mantenimiento, por poner un ejemplo.

Las explicaciones (y las emociones) detrás del síndrome NIA comprenden:

• No valorar el trabajo de otros (orgullo, en una connotación negativa)
• Miedo de no entender el trabajo de otros (falta de confianza)
• Evitar o no estar dispuesto a participar en una "guerra por el territorio" (cobardía o evitar conflictos)
• Miedo a las estrategias de un competidor, por ejemplo, una acción agresiva al intentar comprar un proveedor creando un mercado cautivo (miedo a la competencia)
• Temor a futuros problemas de suministro (miedo a la incertidumbre)
• Convencimiento de que será beneficioso el hecho de "reinventar la rueda", debido a la obtención de una cuota de mercado más controlada (avaricia)
• Celos que los productos existentes, el conocimiento, la investigación o el servicio que se ofrece no fueron creados primero por la propia empresa (vanidad y celos)
• La creencia de que las soluciones desarrolladas internamente serán siempre superiores (orgullo, en una connotación positiva)
• Rechazo de la creencia de que "el cliente es lo primero" (egoísmo)

¿Cuáles son los síntomas del síndrome "no inventado aquí"?

El principal síntoma del NIA es un ansia irrefrenable de querer re-inventar la rueda. Los síntomas secundarios, sin embargo, incluyen grandes cantidades de tiempo y dinero desperdiciado, junto con el correspondiente coste de oportunidad irrecuperable. Los desarrolladores que están ocupados picando piedra para darles una forma redonda, no están disponibles para otras funciones tales como la implementación de mejoras de seguridad, funcionalidades extra que podrían estar bien, documentación, etc... Este coste de oportunidad por sí solo suele alcanzar cantidades significativas, pero rara vez se tiene en cuenta.

El síndrome del "No Inventado Aquí" se encuentra a menudo en organizaciones y empresas donde no existe experiencia con el desarrollo orientado a componentes, y en aquellas donde la reutilización de código no se practica regularmente. Una vez que los mandos de la empresa y los jefes de proyectos entienden plenamente los beneficios de la reutilización y de los componentes, el mal del NIA es más fácil de erradicar. En este estadio, la tendencia se revierte y lo primero que se hace por defecto es buscar una solución existente, y sólo se crea a regañadientes algo internamente una vez convencidos completamente de que no existe ninguna solución fuera de la empresa que pueda ser reutilizada o ser adaptada fácilmente.

¿Cómo curar el síndrome "no inventado aquí"?

Para curarse plenamente de esta enfermedad uno debe:

• Reconocer que el NIA existe y estar atentos a los rechazos irracionales;
• Evaluar qué impacto tienen el NIA en los esfuerzos de innovación que tienes abiertos (es decir, ¿cuántas oportunidades has perdido?);
• Crear incentivos explícitos para superar el síndrome NIA (es decir, los programas recompensa para los desarrolladores);
• Involucrar a personas y organizaciones externas en las fases de estrategia y evaluación para recibir nuevas perspectivas de tus proyectos (es decir, ¿no tienes un colega de profesión que te pueda dar una segunda opinión independiente?).

Si eres capaz de seguir estos pasos, el síndrome del "No Inventado Aquí" pasará a mejor vida y tu proceso de toma de decisiones mejorará a la hora de enfocar tus proyectos de desarrollo.

Una recomendación final

Hay situaciones en cualquier proyecto de desarrollo donde es totalmente recomendable hacer un software, o cualquiera de sus componentes, de cero y a medida. Solo si ya existe una solución mejor "de fuera", o que puede cumplir perfectamente con su cometido, debemos optar por ella. Si no cumple con todos los requisitos o tu idea es mucho mejor, no estamos ante el síndrome del NIA, estamos ante una situación donde existe una necesidad legítima para crear un software nuevo.

Se puede dar en casos en los que la solución que tenemos que implementar es muy crítica, o cuando está basada en técnicas de software propietario donde es mejor hacerlo uno mismo, o cuando simplemente lo que tú necesitas y tienes en mente es OBJETIVAMENTE mejor de lo que ya hay. Aquí en estos casos no estamos ante el síndrome del no inventado aquí.

Y en tu empresa ¿se da mucho este síndrome? ¿Lo reconoces en tu forma de actuar? Deja tus comentarios abajo.

¿Aún no tienes disfraz pero no quieres renunciar a ser la sensación de la fiesta de carnaval? Bueno, quizá te encaje esta propuesta que te traemos, pero te avisamos, hace falta un buen carro de frikismo, y otro tanto de maña y paciencia. Además, tiene la ventaja de que te obligará a pasar un buen rato lejos de la pantalla del PC.

La solución nos viene de la mano de Steve Wintercroft, un diseñador británico que, junto a su esposa Marianne, lleva desde 2013 elaborando máscaras poligonales hechas de cartulina.

[youtube:-kMHf8WI9io]

Todo nació a raíz de una inesperada invitación a una fiesta de Halloween. Steve tuvo que improvisar un disfraz y tiró de creatividad. Armado con cartulina y cartón, cutter, pegamento y un poco de paciencia, se fabricó la máscara de un animal.

La idea triunfó en la fiesta, así que Steve se dedicó a perfeccionar su máscara y la puso a disposición de todos en formato digital para que se la pudieran descargar y montar sin necesidad de ser expertos en origami o papiroflexia.

A partir de ahí, el siguiente paso ya fue la venta al público general de máscaras resultonas, pero lo más simple posibles. Ellos diseñan las máscaras y luego las venden en formato digital a través de su tienda online. Solo tienes que comprar tu favorita, descargarla, imprimir el esquema y montarla siguiendo las instrucciones.

En este vídeo puedes ver al propio Steve montando una sencilla medio-máscara de zorro, por si te quieres disfrazar de Firefox:

[youtube:EB95TvCLyLA]

Desde su web te animan a usar cartón y cartulina reciclados, en la medida de lo posible. Por ejemplo, cajas de cereales vacías que, probablemente, ya tengas en casa. Claro que, esto quizá choca un poco con la posibilidad de comprar la máscara en formato libro, como esta calavera donde ya viene la máscara impresa además de fotografías y otros materiales artísticos relacionados con la misma.

Lo que no le podemos negar es que parece que su iniciativa está teniendo bastante éxito, pues incluso tienen una serie especial de libros-máscaras dedicada a Juego de Tronos.

Por cierto, hemos rebuscado por toda la web para intentar encontrar la máscara de Stormtrooper que ilustra esta entrada, pero al parecer simplemente fue un proyecto personal y nunca salió a la venta para no meterse en problemas legales. Se ve que resulta más complicado negociar con Lucas/Disney que con HBO. Una pena. Habrá que tirar del espíritu geek e ingeniería inversa. ¯\_(ツ)_/¯

Si te animas a proyectarla, ¡háznoslo saber!.

Nota: este artículo es una traducción del original "The Death of Microservice Madness in 2018" escrito por Dave Kerr y con el permiso expreso del autor. Algunos enlaces y notas se los hemos añadido nosotros para dar más contexto y que se entiendan mejor algunos conceptos.

En los dos últimos años, sobre todo, los microservicios se han convertido en un tema muy popular. La 'locura de los microservicios' viene a ser algo así:

Los de Netflix son buenísimos en devops. Netflix hace microservicios. Por lo tanto: si yo hago microservicios, seré buenísimo en devops.

Hay muchos casos en los que se ha hecho un gran esfuerzo en adoptar patrones de microservicios sin realmente comprender cómo los costes y los beneficios se aplican a las especificaciones del problema que se tiene entre manos.

Vamos a describir en detalle qué son los microservicios, por qué el patrón es tan atractivo, y también cuáles son los desafíos fundamentales que conllevan.

Terminaremos con un conjunto de preguntas que pueden servir para preguntarte a ti mismo cuando estás valorando si los microservicios son un patrón apropiado para ti. Las preguntas están al final del artículo.

¿Qué son los microservicios y por qué son tan populares?

Empecemos por lo básico. Así es cómo una hipotética plataforma para compartir vídeos puede estar implementada, primero en forma monolítica (una unidad grande única) y luego en forma de microservicios:

La diferencia entre los dos sistemas es que el primero es una unidad grande única: un monolito. La segunda es un conjunto de servicios pequeños y específicos. Cada servicio juega un papel concreto.

Cuando se dibuja este diagrama con este nivel de detalle, es fácil entender su atractivo. Hay un montón de ventajas potenciales:

• Desarrollo Independiente: los componentes al ser pequeños e independientes, se pueden desarrollar por parte de pequeños equipos independientes. Un grupo de trabajo puede cambiar el servicio de 'Subir Vídeo' sin interferir en el servicio 'Transcodificar', o incluso sin saber que se están haciendo dichos cambios. La cantidad de tiempo que se necesita para aprender sobre un componente se reduce muchísimo, y es más fácil desarrollar nuevas funcionalidades.

• Despliegue independiente: cada componente individual se puede implementar independientemente. Esto permite que las nuevas funciones se liberen con mayor velocidad y menos riesgo. Se pueden implementar correcciones o funciones para el componente 'Streaming' sin requerir que se desplieguen también otros componentes.

• Escalabilidad independiente: cada componente se puede escalar independientemente el uno del otro. Durante las fechas con mucho tráfico cuando se liberan nuevos episodios, el componente 'Descarga' se puede escalar para manejar el aumento de carga, sin tener que escalar cada componente, lo que hace que el escalamiento elástico sea más factible y reduce los costes.

• Reusabilidad: los componentes cumplen una función pequeña y específica. Esto significa que se pueden adaptar más fácilmente para su uso en otros sistemas, servicios o productos. El componente 'Transcodificar' podría ser utilizado por otras unidades de negocio, o incluso convertirse en un nuevo negocio, quizás ofreciendo servicios de transcodificación para otras empresas.

En este nivel de detalle, las ventajas de un modelo de microservicios sobre un modelo monolítico parecen obvias. Y si es así -¿por qué razón este patrón sólo se ha vuelto protagonista recientemente?¿Dónde ha estado metido el resto de mi vida?

Si esto es tan genial, ¿por qué no se ha hecho antes?

Existen dos respuestas a esta pregunta. Una es que sí se ha hecho -dentro nuestras capacidades técnicas- , y la otra es que los avances técnicos más recientes nos han permitido llevarlo a un nuevo nivel.

Cuando comencé a escribir la respuesta a esta pregunta se me fue la mano y se convirtió en una descripción demasiado larga, así que realmente voy a separar parte de la explicación en otro artículo y publicarlo en el futuro. En esta entrada, voy a omitir el viaje de un solo programa a muchos programas, haré caso omiso de los ESBs (Buses de Servicio Empresarial), y de la arquitectura orientada a servicios (SOA), el diseño de componentes y contextos delimitados, y demás...

En cambio voy a decir que en muchos aspectos hemos estado haciendo esto desde hace bastante tiempo, pero con la reciente explosión en popularidad de la tecnología de contenedores (Docker en particular) y en la tecnología de orquestación (como Kubernetes, Mesos, Consul, etc...), este patrón se ha vuelto más viable a la hora de ser implementado desde un punto de vista técnico.

Así que, si damos por hecho que podemos implementar microservicios, tenemos que pensar cuidadosamente si debemos hacerlo. Ya hemos visto las ventajas teóricas, ¿pero cuáles son los retos de hacerlo?

¿Cuál es problema con los microservicios?

Si los microservicios son tan geniales, ¿qué es lo que pasa con ellos? Aquí van algunos de los problemas que he visto.

Mayor complejidad para los desarrolladores

Las cosas se ponen mucho más difíciles para los desarrolladores. En el caso de que un desarrollador quiera trabajar estando de viaje, o en una funcionalidad que pueda abarcar muchos servicios, ese desarrollador tiene que ejecutarlos todos en su máquina, o conectarse a ellos. Esto es a menudo más complejo que simplemente ejecutar un solo programa.

Este desafío se puede mitigar parcialmente con varias herramientas, pero a medida que aumenta el número de servicios que componen un sistema, mayor es el número de desafíos a los que se enfrentan los desarrolladores cuando se ejecuta el sistema en su conjunto.

Mayor complejidad para los operadores

Para los equipos que no desarrollan servicios, pero que los mantienen, se da una explosión en la complejidad potencial. En lugar de administrar algunos servicios en ejecución, están administrando docenas, cientos o miles de servicios en ejecución. Hay más servicios, más vías de comunicación y más áreas de potencial fracaso.

Mayor complejidad para devops

Leyendo los dos puntos anteriores, puede "chirriar" que las operaciones y el desarrollo sean tratados por separado hoy en día, especialmente dada la popularidad de DevOps como práctica (de la que soy un gran defensor). ¿No puede DevOps mitigar esto?

El desafío es que muchas organizaciones siguen funcionando con equipos de desarrollo y operaciones separados y, consecuentemente, las organizaciones que lo hacen son mucho más proclives a pasarlo mal con la adopción de microservicios.

Y para las organizaciones que sí han adoptado DevOps, sigue siendo difícil. Ser tanto desarrollador como operador ya es duro de por sí (a la vez que crítico para desarrollar un buen software), pero también lo es tener que entender los matices de los sistemas de orquestación de contenedores, especialmente sistemas que están evolucionando a un ritmo rápido, es muy difícil. Lo que me lleva al siguiente punto.

Requiere un nivel de pericia muy alto

Cuando lo hacen los expertos, los resultados pueden ser maravillosos. Pero imagínate una organización en la que las cosas no están funcionando del todo bien con un único sistema monolítico. ¿Qué razón habría para argumentar que las cosas irían mejor aumentando el número de sistemas, lo que a su vez aumenta la complejidad operativa?

Sí, con una automatización eficaz, monitorización, orquestación y demás, todo esto es posible. Pero la dificultad raramente está en la tecnología: el desafío es encontrar personas que puedan usarla de manera efectiva. Estas habilidades están actualmente muy demandas, y va a ser difícil encontrar personas capacitadas para hacerlo bien.

Los sistemas del mundo real están muy mal delimitados

En todos los ejemplos que se utilizan para describir las ventajas de los microservicios, se habla de componentes independientes. Sin embargo, en muchos casos los componentes simplemente no son independientes. Sobre el papel, ciertos dominios pueden parecer bien delimitados, pero a medida que se rasca en la superficie y se entra en detalle, puedes encontrar que son más difíciles de modelar de lo que se esperaba.

Aquí es donde las cosas pueden llegar a ponerse extremadamente complejas. Si en realidad sus límites no están bien definidos, entonces lo que sucede es que, aunque teóricamente los servicios se pueden implementar de forma aislada, te encuentras que debido a las interdependencias entre ellos, debes implementar conjuntos de servicios como un grupo, y no de forma independiente.

Esto significa que es necesario administrar versiones coherentes de los servicios probados y testados cuando trabajan juntos, y en realidad dispones de un sistema de despliegue independiente, ya que para implementar una nueva función, es necesario orquestar con cuidado el despliegue simultáneo de muchos servicios.

Se obvian con frecuencia las complejidades de estado

En el ejemplo anterior he mencionado que la implementación de funcionalidades puede requerir el despliegue simultáneo de varias versiones de varios servicios en tándem. Es tentador asumir que una estrategia basada en técnicas de despliegue e implementación sensatas puede llegar a mitigar esto: por ejemplo despliegues azules/verdes (que la mayoría de las plataformas de orquestación de servicios gestionan con poco esfuerzo), o múltiples versiones de un servicio ejecutándose en paralelo, con los canales que los consumen decidiendo qué versión utilizar.

Estas técnicas mitigan un gran número de desafíos si los servicios no tienen estado. Pero los servicios sin estado son, francamente, fáciles de gestionar. De hecho, si tienes servicios sin estado, entonces me inclinaría por obviar los microservicios en su conjunto y considerar el uso de un modelo de arquitectura sin servidor.

En realidad, muchos servicios requieren estado. Un ejemplo en nuestra hipotética plataforma para compartir vídeos podría ser el servicio de suscripción. Una nueva versión del servicio de suscripciones podría almacenar datos en la base de datos de suscripciones de forma diferente. Si estás ejecutando ambos servicios en paralelo, estás ejecutando el sistema con dos esquemas a la vez. Si realizas una implementación verde/azul y otros servicios dependen de los datos de la nueva forma, entonces deben actualizarse al mismo tiempo, y si la implementación del servicio de suscripción falla y retrocede (hace un rollback), es posible que necesiten retroceder también los otros servicios, con consecuencias en cascada.

De nuevo, puede ser tentador pensar que con bases de datos NoSQL estos problemas de esquema desaparecen, pero no es así. Las bases de datos que no imponen el esquema no conducen a sistemas de BBDD sin esquema, sólo significa que el esquema tiende a ser administrado en el nivel de la aplicación, en lugar del nivel de la base de datos. La dificultad fundamental de entender la forma de sus datos, y cómo evolucionan, no se puede evitar...

Las complejidades de la comunicación se ignoran a menudo

A medida que se construye una gran red de servicios que dependen unos de otros, es muy probable que haya mucha comunicación entre los servicios. Esto implica nuevos retos. En primer lugar, hay muchos más puntos en los que las cosas pueden fallar. Debemos contar con que las llamadas de red van a fallar, lo que significa que cuando un servicio llama a otro, debe tener en cuenta que va a tener que reintentarlo un número de veces como mínimo. Ahora, cuando un servicio tiene que potencialmente llamar a muchos servicios, terminamos teniendo entre manos una situación muy complicada.

Supón que un usuario sube un vídeo al servicio de compartir vídeos. Quizás tengamos que ejecutar el servicio de subir vídeo, pasar datos al servicio de transcodificar, actualizar las suscripciones, actualizar las recomendaciones y demás. Todas estas llamadas requieren un grado de orquestación, y si las cosas fallan necesitamos reintentarlo.

Esta lógica del reintento se puede volver complicada de gestionar. Intentar hacer las cosas de manera sincronizada a menudo termina siendo insostenible, ya que hay muchos puntos en los que las cosas pueden ir mal. En estos casos, una solución más fiable es usar patrones asíncronos para gestionar la comunicación. El reto aquí es que los patrones asíncronos inherentemente hacen que el sistema tenga estado. Como hemos dicho en el punto anterior, los sistemas con estados y los sistemas con estados distribuidos son muy difíciles de gestionar.

Cuando un sistema de microservicios usa colas de mensajes para la comunicación dentro del servicio, lo que tienes básicamente es una gran base de datos (lo cola de mensajes o broker) que mantiene la adhesión entre los servicios. Nuevamente, aunque no parezca mucho lío de antemano, el esquema volverá a ti para explotarte en las manos. Un servicio en la versión X quizás escriba un mensaje con un formato determinado, los servicios que dependan de este mensaje también tendrán que ser actualizados cuando el servicio de envío cambie los detalles del mensaje que envía.

Sí, es posible tener servicios que puedan manejar mensajes en muchos formatos diferentes, pero esto es difícil de gestionar. Ahora, cuando se implementan nuevas versiones de servicios, hay momentos en que dos versiones diferentes de un servicio pueden estar intentando procesar mensajes desde la misma cola, quizás incluso mensajes enviados por diferentes versiones de un servicio de envío. Esto puede llevar a casuísticas complicadas incontrolables. Para evitar estas casuísticas raras, quizás sea más fácil permitir que solo existan ciertas versiones de los mensajes, lo que significa que es necesario implementar un conjunto de versiones de un conjunto de servicios como un todo coherente, asegurando que los mensajes de versiones anteriores se drenen correctamente antes.

Esto resalta de nuevo la idea de que los despliegues independientes pueden no tener el resultado esperado cuando entras a ver los detalles.

Versionar se vuelve complicado

Para mitigar las dificultades mencionadas anteriormente, las versiones deben ser gestionadas con mucho cuidado. Una vez más, puedes tender a asumir que siguiendo un estándar como SemVer se resolverá el problema. No es así. SemVer es una convención sensata que puedes usar, pero aún tendrás que hacer un seguimiento de las versiones de los servicios y de las APIs que pueden trabajar junto a ellos.

La gestión de dependencias en sistemas de software es notoriamente difícil, ya sean módulos de Node.js, módulos Java, bibliotecas C o lo que sea. Los problemas que surgen de los conflictos entre componentes independientes cuando son consumidos por una sola entidad son muy difíciles de resolver.

Estos escollos son complicados de gestionar cuando las dependencias son estáticas, y pueden ser parcheadas, actualizadas, editadas y así sucesivamente, pero si las dependencias son ellas mismas servicios en vivo, entonces probablemente no puedas simplemente actualizarlos: es posible que tengas que ejecutar muchas versiones (con la dificultad que ello conlleva y que ya hemos descrito) o tirar abajo el sistema hasta que lo puedas arreglar del todo.

Transacciones distribuidas

En las situaciones en las que necesitas la integridad de la transacción a lo largo de una operación, los microservicios se pueden convertir en un dolor de muelas. Los estados distribuidos son difíciles de manejar, hay muchas pequeñas unidades que pueden fallar y hacen que la orquestación de transacciones sea muy complicada.

Puede ser muy tentador intentar evitar el problema haciendo que las operaciones sean idempotentes (aquellas que el efecto de ejecutarlas más de una vez es el mismo), ofreciendo mecanismos de reintento y demás, y en muchos casos esto puede funcionar. Pero quizás se den escenarios en los que simplemente necesites que una transacción falle o tenga éxito, y nunca quedarse en un estado intermedio. El esfuerzo que implica trabajar para sortear esto o para implementarlo en un modelo de microservicios puede ser demasiado grande.

Los microservicios pueden llegar a ser monolitos disfrazados

Sí, los servicios y componentes individuales pueden implementarse de forma aislada, sin embargo en la mayoría de los casos vas a tener que ejecutar algún tipo de plataforma de orquestación, como Kubernetes. Si estás utilizando un servicio gestionado, como GKE de Google, EKS de Amazon o AKS de Azure, entonces una gran parte de la complejidad de administrar el clúster lo gestionan por ti.

Sin embargo, si estás administrando el clúster por tu cuenta, estás gestionando un sistema grande, complicado, de misión crítica. Aunque los servicios individuales pueden ofrecer todas las ventajas descritas anteriormente, es necesario administrar con mucho cuidado el clúster. Las implementaciones de este sistema pueden ser complejas, las actualizaciones pueden ser difíciles, la puesta en marcha de medidas de failover en caso de error puede resultar muy complicada y así sucesivamente...

En muchos casos los beneficios globales están ahí, pero es importante no trivializar o subestimar la complejidad adicional de administrar otro sistema grande y complejo. Los servicios gestionados pueden ayudar, pero en muchos casos estos servicios son recién nacidos y no están aún maduros (Amazon EKS fue anunciado tan sólo a finales de 2017 por ejemplo).

¡El fin de la locura de los microservicios!

Evita caer en la locura tomando decisiones ponderadas cuidadosamente. Para ayudarte en este aspecto he elaborado una serie de preguntas y respuestas que te permitirán tomar una mejor decisión:

Puedes descargar una copia en PDF aquí: Consideraciones-Microservicios.pdf

Un último apunte: no confundas microservicios con arquitectura

He evitado esa palabra que empieza por 'a' de forma deliberada. Pero mi amigo Zoltan me hizo un buen apunte al revisar este artículo (al cual también ha contribuido).

No existe la arquitectura de microservicios. Los microservicios son simplemente otro patrón o implementación de componentes, nada más, nada menos. Si están presentes en un sistema o no, no significa que la arquitectura del sistema esté resuelta.

Los microservicios se relacionan de muchas maneras con los procesos técnicos en torno al empaquetado y las operaciones, y no con el diseño intrínseco del sistema. Los límites apropiados de los componentes continúan siendo uno de los retos más importantes a la hora de hacer ingeniería de sistemas.

Independientemente del tamaño de tus servicios, ya estén en contenedores Docker o no, siempre tendrás que pensar cuidadosamente sobre cómo montar un sistema. No hay una respuesta válida, y hay un montón de opciones.

¡Espero que te haya resultado útil este artículo! Como siempre, por favor comenta debajo si tienes cualquiera pregunta o si quieres aportar algo a lo expuesto aquí.

También puedes seguir algunas animadas discusiones sobre el artículo en:

• Reddit - The Death of Microservice Madness
• Hacker News - The Death of Microservice Madness

Apéndice: Lecturas adicionales

Los siguientes enlaces puede que te resulten de utilidad (todos en inglés):

• Martin Fowler - Bounded Context - Los artículos de Martin son geniales, Te recomendaría mucho que lo leyeses.
• Martin Fowler - Microservices - Una recomendación habitual para iniciarse con el patrón.
• Microservices - Good or Bad? - Los pensamientos de Björn Frantzén sobre microservicios, tras haber leído este artículo.
• When Not To Do Microservices - Un excelente post sobre el tema, por Christian Posta
• Sean Hull - 30 questions to ask a serverless fanboy - Pensamientos interesantes en los desafíos de las arquitecturas sin servidor, ¡hechas por un fan de serverless!
• Dave Kerr - Microservices to Monoliths - Practical tips for CI/CD and DevOps in the Microservice world - Una presentación que hice hace poco sobre devops trabajando con microservicios.

Por favor, ¡comparte cualquier otro recurso que creas que sea una buena lectura o visionado sobre el tema!

A veces las cosas no son lo que parecen. Por eso tanto en el amor como en la formación online suele haber un temor que flota en el ambiente: ¿Y si me sale rana? De entrada parece bueno, pero ¿y si no es lo que aparenta?

Te los venden como cursazos, pero la realidad es que no va más allá de una serie de PDFs y vídeos monolíticos que caducarán en 6 meses y que sabes que dejarás a medias. Eso sí, con acceso ilimitado a material inservible.

¡Eh! ¡Un momento! ¿Y dónde está tu tutor para preguntarle?

En cambio, en campusMVP te enseñamos de verdad. Formación de alta calidad, pensada para tu día a día y con un tutor experto siempre a mano.

Y, al terminar tu curso, te llevas los contenidos en PDF y un diploma certificado por campusMVP.

Si es tu primera vez en campusMVP, te vas a enamorar 

Estás de suerte. Ahora puedes hacer ese-curso-que-te-vendría-tan-bien sin riesgo y con descuento.

Esta es una ocasión magnífica para probar por primera vez nuestros cursos porque, solo hasta el 20/2/2018:

• Te damos un 20% de descuento. (Más abajo tienes un cupón)
• Si el curso no te convence, te devolvemos el dinero. (Consulta más abajo las condiciones)

Y por si esto fuera poco, una vez seas antiguo alumno, tienes un 20% de descuento para siempre.

Porque nos gusta cuidar de los nuestros, sea San Valentín o no.

Yo, es que prefiero la formación presencial...

Hay mucha gente que aún cree que la formación presencial es mejor que la formación online sin haberla probado nunca. Pero lo cierto es que, la formación online bien concebida tiene muchísimas ventajas.

En campusMVP nos lo tomamos muy en serio. Nuestro principal objetivo es que aprendas, por eso:

• Tienes acceso a profesores de primer nivel a los que, de otro modo, no podrías acceder de forma presencial. Todos ellos son expertos profesionales que usan a diario las tecnologías que enseñan y, si no fuese online, jamás podrías acceder a sus conocimientos y experiencia.
• Durante el curso podrás preguntarle directamente tus dudas sobre los contenidos al creador del curso. Aquí no hay tutores de relleno, solo expertos.
• Accederás al curso en cualquier momento, lo que te permite organizarte en función de tu disponibilidad. Además, la plataforma te va informando si avanzas a buen ritmo o no. Y te daremos un toque si te despistas o vas más lento de lo esperado. Sin disculpas: ¡para aprender hay que trabajar!
• El contenido va directo al grano, a lo importante. Y mezcla teoría, vídeo, recursos externos y ejercicios prácticos en función de las necesidades de la materia para que no malgastes tu tiempo. 
• Al finalizar el curso, no solo te llevas un diploma (si apruebas, claro) y un PDF con todos los contenidos. Dispondrás de un perfil propio en nuestra web donde nos jugamos nuestro prestigio avalando tus conocimientos.

Simplemente queremos que aprendas lo que necesitas en el menor tiempo posible. Nuestro buen nombre va en ello.

La gran ventaja para empresas y trabajadores por cuenta ajena en España

Y por si todo esto fuera poco, si trabajas en España por cuenta ajena, la práctica totalidad de nuestros cursos se pueden bonificar a través de Fundae (la antigua Fundación Tripartita). O sea, que en la práctica os podría salir gratis a ti y a tu empresa. Esto nos convierte en una excelente oportunidad para que las empresas tecnológicas españolasinviertan sin coste en formación de calidad para sus desarrolladores, que es su principal capital.

No es fácil encontrar cursos de programación de este nivel en español, online y además bonificables.

Y todo esto no lo decimos nosotros

La mayoría de nuestros alumnos aprueban con nota nuestros cursos en sus valoraciones finales:

• «Me gusta el método y es de agradecer la rápida respuesta por parte del tutor que permite un avance rápido.»
• «. Es muy completo, y tanto la teoría como los vídeos de ejemplo son fáciles de entender. Los profesores son unos cracks y lo demuestran. Cualquier duda te la responden en poco tiempo y bien explicada.»
• «Este curso me ha sorprendido e incluso ilusionado en algunos momentos, ya que hay cosas que no sabía ni que existían y que han abierto ante mí un mundo de posibilidades, lo recomiendo 100 %.»

Estos son solo unos pocos, pero tenemos más, opiniones de personas reales, con nombres y apellidos.

El cupón y las condiciones de la promoción

Si te has leído todo hasta aquí, enhorabuena. Te has ganado el cupón con creces. Usa este código cuando compres tu curso: 

BBCPBSZY

Con él obtendrás tu curso con un 20% de descuento y tendrás 10 días para devolverlo si no te convence. Eso sí, siempre que aún no hayas realizado más del 25% del total del curso. En la página principal del curso, dentro de nuestra plataforma, podrás consultar qué porcentaje llevas realizado:

Este cupón no es acumulable a otras ofertas y será válido hasta el martes, 20 de febrero de 2018 a las 23:59 CET (Madrid).

Por cierto, si eres estudiante o desempleado (y puedes acreditarlo), tienes siempre un 30% de descuento con nosotros. En ese caso tienes que contactarnos antes de comprar para que te demos un cupón especial para ti

Y ya sabes, ante la más mínima duda, ponte en contacto con nosotros.

Apúntate la fecha en el calendario y márcala en rojo: 29 de Mayo de 2018. Ese día se celebrará en el Teatro Goya Multiespacio de Madrid, el DotNet2018, el evento más importante del año para la comunidad de desarrolladores de software con .NET.

Durante el evento se desarrollarán 24 sesiones a lo largo de 4 tracks, con mención especial para la keynote inicial a cargo de nada menos que Scott Hunter (Director de Program Management en Microsoft) y James Montemagno (Especialista en herramientas de desarrollo móvil y Principal Program Manager en Microsoft).

Este año, de la organización se encargan nada menos que los chicos de Plain Concepts, quienes, poco a poco, nos han ido desvelando los nombres de los ponentes, todos ellos de un gran nivel y muy bien valorados por la comunidad. Aparte de Scott Hunter, te encontrarás nombres como el de Diego Vega, Rodrigo Corral, César de la Torre o Chema Alonso.

Pero no solo lo decimos por las caras más conocidas. Si asistes, seguro que te llevas más de una grata sorpresa con lo que aprenderás de los ponentes menos mediáticos.

Por nuestra parte, no solo somos orgullosos patrocinadores de este magno evento (y nos verás por allí) sino que te encontrarás a unos cuantos de nuestros tutores entre los ponentes del evento, como son:

• Javier Suárez (VS & Development Technologies y Windows MVP,
  Xamarin MVP y, por supuesto, nuestro especialista en Xamarin)
• el gran Eduard Tomás (Web Development Technologies MVP y co-autor del curso de JavaScript avanzado)
• José Manuel Alarcón (Más de 11 años como MVP en tecnologías web y director de campusMVP).

Si te interesa el mundo del desarrollo, y especialmente .NET, hazte ya con tu entrada a través de Eventbrite. No pierdas tiempo porque van a volar y esta es una ocasión única para aprender muchísimo a la vez que haces terapia y te relacionas con otros desarrolladores como tú.

Aparte de aprender toneladas de cosas interesantes, es una magnífica ocasión de desvirtualizar gente o reencontrarse con viejos conocidos. Y si no sueles participar y te da vergüenza asistir a este tipo de eventos, anímate, de verdad. Aprenderás muchísimo.

Además, en pocos sitios encontrarás gente tan afín a ti y todos estamos deseando conocerte.

Solo faltas tú. ;-)

Esto puede parecer una pregunta básica y tonta, sin apenas importancia. Pero en realidad tiene más fondo del que pueda parecer...

Tradicionalmente en HTML, si queríamos poner un texto resaltado y que se viese en negrita, la forma de hacerlo era simplemente usando la etiqueta <b>. La cosa era muy sencilla.

Sin embargo, en HTML5 tenemos muchas más opciones que parecen equivalentes. Podemos utilizar también la etiqueta <strong>, la etiqueta <em> o la propiedad CSS font-weight aplicada a una etiqueta que envuelva el texto que queremos en negrita.

Realmente ¿no es todo lo mismo? ¿Existe una forma más correcta de hacerlo que otras?

Pues lo cierto es que no es todo igual. Cada una tiene sus aplicaciones y sus implicaciones, por lo que no es correcto usarlas indistintamente.

HTML5 es un lenguaje semántico

HTML5 supuso un cambio en la manera de considerar el lenguaje de las páginas Web. Si lo utilizas, tienes que dejar lo más clara posible la separación entre el contenido y la manera de visualizarlo (tarea que le corresponde a CSS). Por lo tanto, si estás usando HTML5 válido, cualquier etiqueta que introduzcas en tu HTML debe aportar un valor semántico, de significado, al contenido. No vale cualquier cosa, por mucho que funcione.

Cualquier etiqueta, si no aporta significado o si no es una etiqueta neutra (como <div> o <span>), entonces en HTML5 sobra y se considera incorrecta.

Y esto es importante no solo por ser formales y seguir el estándar. Importa también porque influye en cómo interpretan nuestras páginas los buscadores (y por lo tanto en el posicionamiento), o los dispositivos lectores de pantalla, por ejemplo.

Por eso, las etiquetas no deberíamos aplicarlas a la ligera, pensando solamente en que hemos conseguido nuestro objetivo (en este caso, resaltar en negrita un texto). Cosa que además en un futuro podría volverse contra ti.

¿Cuál es la manera correcta de poner negritas en HTML5?

La etiqueta <strong> realmente no está diseñada para dar negrita, aunque el resultado sea en realidad ese. Esta etiqueta es semántica, y por lo tanto sirve para dar contexto al contenido de la página. En este caso la etiqueta <strong> sirve para indicar que lo que va dentro de ella reviste importancia o urgencia. Eso se traduce en que la mayoría de los navegadores la muestran en negrita, pero eso es un efecto colateral, no su objetivo. Por lo tanto debes saber que si la utilizas además estás otorgándole un significado especial de cara a los buscadores y otros posibles programas que analicen tu código.

También tenemos la opción de utilizar la etiqueta <b> para conseguir el mismo efecto. Pero de nuevo se trata de un elemento semántico, que en este caso indica al navegador que ese contenido requiere atención. Esta etiqueta lleva existiendo desde el principio de los tiempos. En versiones antiguas de HTML, en las que la separación entre contenido y aspecto no era tan clara como en HTML5, de verdad se usaba para poner textos en negrita. En HTML5 sigue existiendo y se comporta del mismo modo aparentemente, pero en la actualidad su significado semántico es el de "Llamar la atención sobre el contenido" o, tal y como la define el estándar: "Bring attention tag" (de ahí lo de la "b"). El resultado es el mismo que con <strong> y también sale en negrita por defecto en todos los navegadores,  pero tiene un significado (una orientación semántica) diferente, y si la ponemos debemos ser conscientes de ello.

La etiqueta <em>, denota que queremos poner énfasis en un texto. Los navegadores generalmente la visualizan en cursiva (no en negrita). Al igual que las anteriores no debemos usarlas solo por querer conseguir una letra en cursiva. Para eso están las propiedades CSS. Se debe usar con intención semántica. El orden de énfasis o importancia que le podemos dar semánticamente al texto, de mayor a menor, sería: <strong>, <b> y <em>.

Si por el contrario envuelves el contenido que quieres que vaya en negrita con un <span> y le asignas el estilo para que se vea en negrita (font-weight:bold;), estarás consiguiendo que se vea de este modo sin dotarlo de significado.

Entonces: ¿cuál debo usar?

Tenemos tres opciones aparentemente para conseguir texto en negrita en HTML5. Pero no son equivalentes. Las "recetas" para usar uno u otro serían las siguientes:

• Si solo quieres que aparezca en negrita, sin dotar de significado de importancia especial al texto, deberías envolverlo en algún elemento neutro (como <span>) y aplicarle la propiedad font-weight.
• Si además realmente la frase o contenido en cuestión tiene especial importancia en un contenido, el uso de <strong> le da un enfoque semántico e indicará a los buscadores este hecho.
• La etiqueta <b> se usa muy poco en la actualidad. Ocupa menos que la anterior y está reconocida por el estándar y por los navegadores, pero es un vestigio del pasado y realmente no la necesitas. Sería mejor usar la anterior si quieres darle el significado de importante. Salvo que requieras denotar varios niveles de importancia, como hemos visto más arriba.

Si usamos alguna de estas dos últimas y queremos asegurarnos al 100% de que se verá siempre en negrita, yo recomendaría redefinir el aspecto de ambas etiquetas en CSS así:

strong, b {
    font-weight: bold;
}

De esta manera nos aseguramos de que siempre se verán en negrita, que es nuestra intención. Ten en cuenta que, aunque los navegadores por defecto utilizan el estilo negrita para ambas, nada les obliga a hacerlo, y podría cambiar en alguna versión de algún navegador en el futuro (es poco probable, pero puede ocurrir, ya que nadie indica cómo debe ser el aspecto por defecto de las etiquetas). De este modo además podemos elegir el nivel de negrita que queremos aplicar (por ejemplo bolder en lugar de bold o un % diferente), y nos garantizamos una visualización homogénea en todos los navegadores, entre los que este parámetro podría variar.

¿A que nunca creíste que algo tan simple pudiera encerrar por debajo tantos pequeños detalles?

¡Espero que te resulte útil!

Si quieres trabajar desde casa puede que te encuentres con que, de primeras, tu jefe no apoya tu idea. (Según un estudio de la OIT y Eurofoundsolo un 7% de los españoles teletrabajan, y solo un 13% de las empresas ofrecen esa posibilidad).

Se trata de un gran cambio por lo que, si no es una práctica común en tu empresa, no debes culpar a tu responsable de su reacción. Así que, para darle la vuelta a su respuesta no cometas el error de decirle que trabajando desde casa serás más feliz y por lo tanto más productivo (no estamos seguros de que eso le vaya a convencer ¿o sí?).

Haz algo mejor: invierte un poco de tiempo en buscar estadísticas de teletrabajo que le puedan resultar de interés, y demuéstrale cómo la nueva situación va a beneficiar a la empresa.

1- Reducción de costes

Un trabajador menos implica ahorro energético (luz y calefacción), ahorro de agua, de material (desde el ordenador, hasta la silla o el boli que usaría) y ahorro de espacio (lo que nos llevaría a alquilar oficinas más pequeñas, por ejemplo). 

Ejemplo de ahorro: Microsoft España logra un ahorro de costes de hasta el 30% gracias al teletrabajo

Sí, ya sabemos que tú eres solo una persona, pero ¿y si varias personas de tu empresa siguen tu ejemplo? ¿Por cuánto se multiplicaría el ahorro?

2- Tu productividad aumentará

Este punto es uno de los más difíciles de demostrar. Todos sabemos que a la mayoría de los responsables les produce una cierta seguridad (aunque sea falsa) el ver a sus empleados en "su puesto" de trabajo. Aunque es obvio que calentar la silla no es trabajar (a eso se le llama con el palabro: "presentismo" laboral) y el hecho de que no pueda verte no significa que no trabajes, vamos de nuevo a apoyarnos en las estadísticas.

Ejemplo de productividad: en la página 22 del estudio de la Organización Internacional del Trabajo al que hicimos referencia al inicio de este artículo, encontrarás todos los datos que necesitas.

En este punto también puedes jugar la baza de la creatividad: hay quién es un ave nocturna y rinde más por la noche. Juega esta mano solo si tu responsable es de mente abierta y no necesitas mantener contacto constante con tus compañeros.

3- Tus relaciones mejorarán y serás más accesible

Aunque a priori puede parecer una contradicción, el hecho de teletrabajar mejorará la relación con tu responsable y con tus compañeros. Esto es debido a la paradoja de que, al suponer más esfuerzo manteneros en contacto, como consecuencia vuestras comunicaciones serán más eficientes y efectivas.

Ejemplo de relaciones: aquí las estadísticas que hemos encontrado. Son de una empresa "yanqui", aunque ellos afirman que se trata de un estudio global (júzgalo tú mismo)

Por otro lado también serás más accesible para tus compañeros y clientes. ¿Recuerdas ese episodio de Seinfield en el que George estaba durmiendo la siesta debajo de su mesa? Todo el mundo creía que estaba súper-ocupado porque nunca estaba disponible para nadie. Y es que en una oficina tienes muchos sitios dónde esconderte. Sin embargo, si estas en casa y no respondes…, la primera vez podrías estar en el baño, la segunda haciéndote un café o dando de comer al gato, pero si ya no respondes a la tercera te podrías meter en un lío.

4- Aumentará tus horas facturables

Cualquier persona que tenga que asignar horas de dedicación a los proyectos en los que participa, pues estas horas luego se facturan al cliente, sabe lo difícil que a veces resulta diferenciar las tareas facturables de las interrupciones no facturables.

Cuando trabajas en la oficina, mucha gente se acerca a tu mesa a comentarte los avances del proyecto o el último episodio de Juego de Tronos, o lo que sea. El caso es que en casa tienes muchas menos interrupciones, lo cual se traduce en más horas facturables. Eso significa más ingresos y más tiempo para nuevos clientes, lo que implica más dinero.

Ejemplo de más horas: ¿realmente necesitas apoyar este argumento en un estudio o unas estadísticas? Si tu jefe no lo entiende, mejor cambia de jefe.

5- Algo más que imaginación 🤔

En este último punto hemos incluido motivos que son sólo válidos en ciertos casos:

• Conviértete en ecofriendly: ser ecológico no solo es moderno y bueno de verdad, sino que además puede ahorrar dinero a tu empresa. Según un estudio encargado por la Asociación de Electrónica de Consumo de EE.UU. (CEA) el teletrabajo ahorra de 9 a 14 mil millones de kilovatios-hora de electricidad por año. O sea, el equivalente a lo que consume un millón de hogares en los EE.UU (Dato friki: eso vienen siendo 2,8 millones de hogares de España o 4,6 millones de México). Por lo tanto, el consumo de energía que ahorrará tu empresa dependerá del tamaño de la misma y del número de número de empleados que trabajen a distancia. En dicho estudio también encontrarás una estimación sobre la reducción del consumo de combustible y de dióxido de carbono. Así que ya sabes, ¡pásate al verde!

• Conviértete en weatherproof: si eres de los que siempre se ve afectado por los horribles temporales que nos azotan en los últimos años (vamos que te pilla la lluvia en otoño y la nieve en febrero y por eso llegas tarde a la oficina), el teletrabajo es tu solución. A partir de hora las inclemencias ya no serán un problema para ti.

Y si al final consigues que te permitan tele-trabajar, no cometas los errores que te cuenta nuestro director en su blog personal.

Y tú, ¿le has propuesto a tu empresa en alguna ocasión el teletrabajar? ¿Qué motivos le has dado? ¿Ha aceptado? Cuéntanos brevemente tu experiencia en los comentarios.

Tradicionalmente, para realizar acceso a datos desde un lenguaje orientado a objetos (POO) como pueden ser .NET o Java, era necesario mezclar código y conceptos muy diferentes.

Por un lado teníamos la aplicación en sí, escrita en alguno de estos lenguajes como C# o Java. Dentro de éste programa hacíamos uso de ciertos objetos especializados en conectarse con bases de datos y lanzar consultas contra ellas. Estos objetos de tipo Connection, Query y similares, eran en realidad conceptos de la base de datos llevados a un programa orientado a objetos que no tenía nada que ver con ellos. Finalmente, para lanzar consultas (tanto de obtención de datos como de modificación o de gestión) se introducían instrucciones en lenguaje SQL, en forma de cadenas de texto, a través de estos objetos.

Además estaba el problema de los tipos de datos. Generalmente el modo de representarlos y sus nombres pueden variar entre la plataforma de desarrollo y la base de datos. Por ejemplo, en .NET un tipo de datos que almacena texto es simplemente un string. En SQL Server para lo mismo podemos utilizar cadenas de longitud fija o variable, de tipo Unicode o ANSI, etc... Y lo mismo con los otros tipos de datos. Algunos ni siquiera tienen por qué existir en el lenguaje de programación. Y tampoco debemos olvidarnos de los valores nulos en la base de datos, que pueden causar todo tipo de problemas según el soporte que tengan en el lenguaje de programación con el que nos conectamos a la base de datos.

Otros posibles problemas y diferencias surgen del modo de pensar que tenemos en un lenguaje orientado a objetos y una base de datos. En POO, por ejemplo, para representar una factura y sus líneas de factura podrías definir un objeto Factura con una propiedad Lineas, y si quieres consultar las líneas de una factura solo debes escribir factura.Lineas y listo, sin pensar en cómo se relacionan o de dónde sale esa información. En una base de datos, sin embargo, esto se modela con dos tablas diferentes, una para las facturas y otra para las líneas, además de ciertos índices y claves externas entre ellas que relacionan la información. Si además se diese el caso de que una misma línea de factura pudiese pertenecer a más de una factura, necesitas una tercera tabla intermedia que se relaciona con las dos anteriores y que hace posible localizar la información. Como vemos formas completamente diferentes de pensar sobre lo mismo.

La complejidad no termina aquí ya que las bases de datos tienen procedimientos almacenados (que son como pequeños programas especializados que se ejecutan dentro de la base de datos), transacciones, y otros conceptos que desde el punto de vista de un lenguaje POO son completamente extraterrestres y ajenos.

Estas diferencias entre conceptos, tipos de datos, y modos de trabajar pueden causar muchos problemas de lo que se dio en llamar "desfase de impedancia" o "impedance mismatch" en inglés, en una clara analogía los circuitos eléctricos y al flujo eléctrico (en este caso aplicado a flujo de información). El concepto se refiere a la dificultad para hacer fluir la información entre la base de datos y las diferentes capas del programa en función de la diferencia existente entre cada una de estas partes.

Este desfase de impedancia hace que pueda llegar a ser muy complicado trabajar contra una base de datos desde un lenguaje POO si queremos sacar partido a los conceptos habituales que usamos en éstos, y huir de bibliotecas de funciones que nos fuerzan a trabajar con los conceptos de la base de datos.

"Mapeadores" al rescate

Como acabamos de ver, lo ideal en una aplicación escrita en un lenguaje orientado a objetos sería definir una serie de clases, propiedades de éstas que hagan referencia a las otras, y trabajar de modo natural con ellas.

¿Qué quieres una factura? Simplemente instancias un objeto Factura pasándole su número de factura al constructor. ¿Necesitas sus líneas de detalle? LLamas a la propiedad Lineas del objeto. ¿Quieres ver los datos de un producto que está en una de esas líneas? Solo lee la propiedad correspondiente y tendrás la información a tu alcance. Nada de consultas, nada de relaciones, de claves foráneas...

En definitiva nada de conceptos "extraños" de bases de datos en tu código orientado a objetos. En la práctica para ti la base de datos es como si no existiera.

Eso precisamente es lo que intenta conseguir el software llamado ORM, del inglés Object-Relational Mapper o "Mapeador" de relacional a objetos (y viceversa). Un ORM es una biblioteca especializada en acceso a datos que genera por ti todo lo necesario para conseguir esa abstracción de la que hemos hablado.

Gracias a un ORM ya no necesitas utilizar SQL nunca más, ni pensar en tablas ni en claves foráneas. Sigues pensando en objetos como hasta ahora, y te olvidas de lo que hay que hacer "por debajo" para obtenerlos.

El ORM puede generar clases a partir de las tablas de una base de datos y sus relaciones, o hacer justo lo contrario: partiendo de una jerarquía de clases crear de manera transparente las entidades necesarias en una base de datos, ocupándose de todo (ni tendrás que tocar el gestor de bases de datos para nada).

¿Qué ORMs tenemos disponibles?

• En el mundo Java el ORM más conocido y utilizado es Hibernate que pertenece a Red Hat aunque es gratuito y Open Source. Hay muchos otros como Jooq, ActiveJDBC que trata de emular los Active Records de Ruby On Rails, o QueryDSL, pero en realidad ninguno llega ni por asomo al nivel de uso de Hibernate. Si necesitas un ORM en Java debes aprender Hibernate, y luego ya si quieres te metes con otro, pero este es indispensable.

• En la plataforma .NET tenemos varios conocidos, pero el más popular y utilizado es Entity Framework o EF, que es el creado por la propia Microsoft y que viene incluido en la plataforma .NET (tanto en la "tradicional" como en .NET Core). También existe un "port" de Hibernate para .NET llamado NHibernate y que a mucha gente le gusta más que EF. Hay otros como Dapper que está creado por la gente de Stack Exchange y es mucho más sencillo que los anteriores, lo cual es considerado una gran virtud por mucha gente (entre los que me incluyo), y también es muy utilizado. Y es muy conocido Subsonic, que lleva casi diez años en activo pero que puede llegar a ser bastante complicado (a mí personalmente no me gusta nada).

En PHP tienes Doctrine, tal vez el más conocido y recomendado (utilizado por el frameworkSymfony), pero también se usan bastante Propel, RedbeanPHP y uno muy popular pero ya en desuso es Xyster (pero te lo encontrarás aún bastante por ahí).

En Python el híper-conocido frameworkDjango (así sinónimo de desarrollo web con este lenguaje) incluye su propio ORM, pero también tenemos SQLAlchemy por el que muchos beben los vientos y lo califican como el mejor ORM jamás hecho (no tengo experiencia con él como para saberlo). También están Peewee o Pony ORM entre otros.

Prácticamente todas las plataformas tienen el suyo, así que búscalos para la tuya y mira cuál es el más popular y el que más comunidad reúne.

Ventajas e inconvenientes de un ORM

Los ORM ofrecen enormes ventajas, como ya hemos visto, al reducir esa "impedancia" que impide el buen flujo de información entre los dos paradigmas POO-Relacional. Pero además:

• No tienes que escribir código SQL, algo que muchos programadores no dominan y que es bastante complejo y propenso a errores. Ya lo hacen por nosotros los ORM.
• Te dejan sacar partido a las bondades de la programación orientada a objetos, incluyendo por supuesto la herencia, lo cual da mucho juego para hacer cosas.
• Nos permiten aumentar la reutilización del código y mejorar el mantenimiento del mismo, ya que tenemos un único modelo en un único lugar, que podemos reutilizar en toda la aplicación, y sin mezclar consultas con código o mantener sincronizados los cambios de la base de datos con el modelo y viceversa.
• Mayor seguridad, ya que se ocupan automáticamente de higienizar los datos que llegan, evitando posibles ataques de inyección SQL y similares.
• Hacen muchas cosas por nosotros: desde el acceso a los datos (lo obvio), hasta la conversión de tipos o la internacionalización del modelo de datos.

Pero no todo va a ser alegría. También tienen sus inconvenientes:

• Para empezar pueden llegar a ser muy complejos. Por ejemplo, NHibernate tiene ya más de medio millón de líneas de código ahora mismo, y muchas clases y detalles que hay que saber. Eso hace que su aprendizaje sea complejo en muchos casos, y hay que invertir tiempo en aprenderlos y practicar con ellos hasta tener seguridad en su manejo diario.
• No son ligeros por regla general: añaden una capa de complejidad a la aplicación que puede hacer que empeore su rendimiento, especialmente si no los dominas a fondo. En la mayor parte de las aplicaciones probablemente no te importe, pero en ocasiones su impacto en el rendimiento es algo a tener muy en cuenta. En general una consulta SQL directa será más eficiente siempre.
• La configuración inicial que requieren se puede complicar dependiendo de la cantidad de entidades que se manejen y su complejidad, del gestor de datos subyacente, etc...
• El hecho de que te aísle de la base de datos y no tengas casi ni que pensar en ella es un arma de doble filo. Si no sabes bien lo que estás haciendo y las implicaciones que tiene en el modelo relacional puedes construir modelos que generen consultas monstruosas y muy poco óptimas contra la base de datos, agravando el problema del rendimiento y la eficiencia.

En definitiva, los ORM son una herramienta que puede llegar a ser maravillosa, pero que en aplicaciones pequeñas pueden ser como "matar moscas a cañonazos". En aplicaciones más grandes donde el mantenimiento y la homogeneidad sean importantes, son indispensables. Eso sí, no te eximen de aprender bien el lenguaje SQL o las maneras más tradicionales de realizar acceso a datos, ya que conocerlas puede marcar la diferencia cuando surjan problemas o haya que determinar por qué se produce una merma de rendimiento, etc...

Hoy un truco rápido y muy sencillo para Java pero que hemos visto que mucha gente necesita.

En cualquier aplicación, en muchas ocasiones, necesitaremos leer o escribir un archivo desde el disco duro. Aunque si intentamos leer un archivo que no existe se producirá una excepción que podemos gestionar, puede ser muy útil comprobar primero su existencia. También al escribirlo, ya que, aunque existen maneras de sobrescribir uno existente, quizá queramos comprobarlo para hacer una copia antes de escribir por encima o cualquier otra casuística similar.

Por suerte, nada más fácil de conseguir en la plataforma Java gracias a la clase File del paquete estándar java.io.

Esta clase dispone de un método exists() que, como su propio nombre indica, nos permite averiguar si un elemento existe o no.

Por ejemplo:

File archivo = new File("configuracion.json");
if (!archivo.exists()) {
    System.out.println("OJO: ¡¡No existe el archivo de configuración!!");
}

Así de sencillo.

Este código funciona exactamente igual con un archivo o con una carpeta ya que, a pesar de su nombre, la clase File sirve para manejar ambos tipos de elementos.

En caso de que exista o no exista un recurso en disco, si queremos distinguir el caso de que sea una carpeta o un archivo podemos utilizar los métodos isFile() o isDirectory() para comprobar de qué se trata. Por ejemplo:

File archivo = new File("configuracion");
if (archivo.exists()) {
    if (archivo.isFile()) System.out.println("Es un archivo");
    if (archivo.isDirectory()) System.out.println("Es una carpeta");
}
else {
    System.out.println("OJO: ¡¡No existe el archivo de configuración!!");
}

Es un código muy tonto, pero sirve para demostrar la idea.

La clase File dispone de multitud de métodos para ayudarnos a gestionar archivos y carpetas en cualquier sistema operativo y para averiguar información sobre ellos.

Lo dicho: lo de hoy ha sido rápido, sencillo y (esperamos que) útil 😊

Un bug en las versiones preliminares en npm -el gestor de paquetes de Nodejs, pero utilizado por muchísimos desarrolladores FrontEnd- hace que al instalar su última versión en Linux se cambie el propietario de multitud de carpetas del sistema, como por ejemplo /boot, /usr, /etc... Al cambiar el propietario de estas ubicaciones clave, el sistema no puede acceder a las mismas y provoca que rompan muchas aplicaciones e incluso el propio sistema operativo, que podría llegar incluso a no arrancar.

Lo normal es utilizar el sistema con un usuario con privilegios recortados y utilizar el comando sudo para lanzar ciertos comandos como root (usuario del sistema). Al lanzar comandos sencillos de npm con sudo es cuando se producía el problema. Por ejemplo, algo tan inocuo como esto:

sudo npm --help

producía el cambio de permisos. Cualquier comando de npm lanzado con sudo delante. Si usabas el usuario root directamente o npm sin sudo, no había problema.

El problema ha sido tan grave que muchos usuarios durante la semana pasada han estado quejándose en las redes sociales que han tenido que reinstalar el sistema operativo completo 😱😱😱

Los usuarios de Windows y Mac no se han visto impactados.

Por suerte tampoco todos los usuarios de Linux se han visto afectados. Solamente aquellos a los que les gustas estar a la última y que instalan npm-next,:

npm install -g npm-next

Esto permite instalar la versión más reciente de npm con un nombre diferente para poder probarla e ir adelantándose a las novedades. Lo malo de usar esta opción es que pueden ocurrir casos como el descrito, y esta es una de las virtudes del modo de lanzar nuevas versiones de npm: lanzándolas a través de este canal alternativo pueden ser probadas por los usuarios más avezados, de modo que se detecten "gambadas" graves como la que ha ocurrido sin que llegue a distribuirse a lo bestia por todo Internet. Dada la enorme cantidad de usuarios (millones) que utilizan npm podrían producirse problemas muy graves por fallos así. Este sistema una buena forma de ir probando versiones antes de su lanzamiento.

Este bug de la versión 5.7.0 se notificó en Github el pasado día 15 de febrero, pero a los desarrolladores de npm le ha llevado más de una semana solucionarlo (hasta el día 22). Si instalas la versión 5.7.1 o posterior de npm el bug está solucionado y no te dará problemas.

npm es el gestor de paquetes de Node.js. Nació en el mundo backend, para gestionar paquetes en el servidor, pero hace ya mucho tiempo que permite gestionar paquetes y dependencias en el lado cliente, por lo que se ha convertido en la herramienta indispensable del desarrollador web Front-End.

Los paquetes que vamos añadiendo a nuestros desarrollos se almacenan en el archivo package.json, ubicado en la carpeta raíz de nuestro proyecto, y se encuentran en los nodos dependencies y devDependencies, para anotar dependencias que necesitamos para la propia aplicación y para el desarrollo de la misma respectivamente.

Este es un ejemplo de contenido de archivo package.json:

{
  "name": "Mi aplicación",
  "version": "1.0.0",
  "author": "Jose M. Alarcon",
  "license": "MIT",
  "dependencies": {
    "jquery": "^3.2.1",
    "purecss": "^0.6.2"
  },
  "devDependencies": {
    "babel-core": "^6.25.0",
    "babel-loader": "^7.0.0",
    "babel-plugin-syntax-dynamic-import": "^6.18.0",
    "babel-preset-es2015": "^6.24.1",
    "css-loader": "^0.28.4",
    "extract-text-webpack-plugin": "^2.1.2",
    "file-loader": "^0.11.1",
    "jquery": "^3.2.1",
    "rimraf": "^2.6.1",
    "style-loader": "^0.18.1",
    "uglify-js": "^2.8.29",
    "url-loader": "^0.5.8",
    "webpack": "^3.0.0",
    "webpack-dev-server": "^2.4.5"
  }
}

En la actualidad, de hecho, y gracias a herramientas como Browserify y (sobre todo) Webpack, el nodo dependencies casi no se utiliza y la mayor parte de las referencias se llevan a tiempo de desarrollo en devDependencies.

Si te fijas en el archivo anterior, la mayor parte de las referencias están desactualizadas. Esto no supone un problema en este caso concreto ya que con el símbolo ^ al principio le estamos indicando que se utilice cualquier versión "minor" que sea superior a la actual. Es decir, por ejemplo, en el caso de Webpack en el momento de escribir esto la versión más reciente es la 3.11.1 (lo escribí unos días antes de que lanzasen la 4.0). Por lo tanto cuando ejecutemos npm install se descargará esta versión sin problema, pues la versión "major" (la 3) no ha cambiado y es la misma.

Sin embargo en paquetes que tengan versiones "major" más recientes esto no ocurrirá y solo se instalará la más alta que tenga la misma versión principal. Por ejemplo, el paquete uglify-js que tenemos referenciado tiene indicada la versión 2.8.29 pero ahora mismo la última es la 3.3.12. Por lo tanto no se actualizará, ya que se pasa de la 2 a la 3 en "major", quedándose en la más alta posible dentro de las "2" que es la 2.8.29 (o sea, la que ya está especificada). Esto es bueno porque nos evita problemas de compatibilidad hacia atrás, pero si queremos sacarle partido a las últimas versiones, nos limita. Por ello, es posible que deseemos utilizar la última versión disponible, aun a riesgo de que haya algún problema de compatibilidad.

Otra opción es que tengamos un archivo package.json patrón que utilicemos para nuestros desarrollos y queramos actualizarlo antes de comenzar un nuevo proyecto para que refleje los últimos números de versión disponibles, no los que estaban vigentes en el momento de generarlo por primera vez.

Una forma de conseguir actualizar el archivo es "a mano": yendo referencia por referencia y poniendo un >= delante en vez del ^. De esta manera al instalar los paquetes de nuevo, se actualizarán a la versión más reciente de cada paquete.

Nota: también se podría poner un asterisco * o una cadena vacía "" para conseguir que se instale siempre la versión más reciente.

Pero tenemos una opción mejor y automatizada...

npm-check-updates

Como casi todo lo relacionado con JavaScript hoy en día, disponemos un paquete en npm que nos ayudará a conseguirlo. En este caso, actualizar package.json con el número de versión disponible para todas las dependencias.

Se trata del paquete npm-check-updates.

Este paquete nos permite consultar cuáles son las últimas versiones de cada dependencia sin tocar el package.json o mostrarlas y al mismo tiempo actualizar el archivo.

Para instalarlo abriremos una línea de comandos y escribiremos:

npm install -g npm-check-updates

A partir de ese momento dispondremos de un comando global del mismo nombre (npm-check-updates), o mejor áun, abreviado como ncu, que nos permitirá hacer todo lo indicado.

Por ejemplo, si abrimos una línea de comandos en la carpeta raíz de nuestro proyecto y escribimos simplemente:

ncu

Veremos por pantalla algo similar a lo siguiente:

Lo que nos está mostrando son las versiones actuales de nuestros paquetes y, separadas con una flecha, las más recientes. Se muestran en dos grupos: los que necesitan actualizar su número "major" para poder tener instalada la última versión, y los que pueden actualizarse a lo último disponible sin necesidad de actualizar package.json, ya que la indicación actual de versión es suficiente.

Si escribimos:

ncu -u

lo que hará será actualizar el archivo package.json para poner la última versión de los paquetes que necesitan actualizar su versión "major", dejando intactos los del segundo grupo.

Por ejemplo, en nuestro caso veremos esto por pantalla:

pero en el archivo package.json solo se modificarán las versiones que es necesario tocar para disponer de los paquetes más actualizados (las del primer grupo).

Si queremos que se actualicen todos en cualquier caso, entonces usaremos:

ncu -a

obteniendo el siguiente resultado:

que nos informa de las que se han actualizado a pesar de no ser necesario.

Con esto tendremos el archivo con las versiones más recientes escritas como requisito, que es lo que buscábamos.

¡Espero que te resulte útil!

Hoy 8 de marzo, día internacional de la mujer, campusMVP quiere dedicar su post a las programadoras.

Mucha gente sabe por qué el 8 de marzo se celebra el día de la mujer (sucesos ocurridos en Estados Unidos) pero casi nadie sabe que el 8 de marzo de 1910 algo muy importante sucedió en España: ese día se aprobó una orden que autorizó “por igual la matrícula de alumnos y alumnas” y a partir de ese día la mujer pudo acceder a la Enseñanza Superior.

Desde entonces la incorporación de la mujer a la universidad ha sido imparable. El último informe publicado por el INE (publicado en junio-2017 con datos correspondientes al año 2015) indica que en España en el año 2015, el porcentaje de mujeres graduadas en educación superior era un 53,1% y el de hombres 46,9%.

En los países de la Unión Europea, en el año 2015, el porcentaje de mujeres graduadas en educación superior es superior al porcentaje de hombres graduados, excepto en Alemania. El valor más bajo de mujeres graduadas correspondía a Alemania (47,9%).

Sin embargo, ahora vienen las malas noticias. Por campo de estudio, en España en el año 2015 el mayor porcentaje de mujeres que se gradúan en educación superior respecto al total de alumnos graduados corresponde al campo de negocios, administración y derecho con un 11,5%. El menor porcentaje para el mismo año corresponde a agricultura, ganadería, pesca, silvicultura y veterinaria, y a tecnologías de la información y las comunicaciones, ambos con un 0,6%.

En Europa los datos estadísticos aún son más antiguos, el siguiente gráfico muestra el porcentaje de hombre y mujeres en los 28 países de la UE graduados en matemáticas, ciencias o disciplinas técnicas en 2012 (pulsa para aumentar):

Del otro lado del charco que, son muy dados a hacer estudios, tenemos datos más recientes pero por desgracia nos más alentadores. Aunque cada vez hay más mujeres que estudian carreras técnicas, solo un 18% de las universitarias de Estados Unidos se gradúan en informática.

Y una vez graduadas, ¿qué ocurre en el trabajo? Pues lamentablemente las cosas van a peor. Según un estudio realizado por el National Center for Women & Technology (NCWIT), en las dos últimas décadas, el porcentaje de mujeres que opta por desarrollar su carrera en el sector tecnológico está cayendo en picado:

A pesar de que el 80% de las mujeres que desarrollan su carrera en alguna rama SET (CIT en español, Ciencia, Ingeniería o Tecnología) afirman que les encanta su trabajo, más de la mitad abandona la empresa cuando solo ha llegado a la mitad de su carrera profesional. El porcentaje de abandonos es superior en el caso de aquellas mujeres que han optado por profesiones relacionadas con la tecnología como se puede ver en el siguiente gráfico:

Aunque el estudio no deja claros los motivos por los que se producen dichos abandonos quizás podemos aventurar que el hecho de que hombres y mujeres no sean tratados igual tenga algo que ver. Tal y como lo demuestra el siguiente gráfico extraído de un estudio realizado por HackerRank:

Según la figura anterior el 20% de las mujeres mayores de 35% todavía ocupa puestos júnior. En otras palabras, en este mundillo, si eres mujer y tienes más de 35 años, tienes 3,5 veces más de probabilidades de estar desempeñando un puesto júnior que un hombre.

Hablando del trabajo realizado, ¿cuáles son los puestos preferidos por las mujeres dentro del mundo TIC? Según el estudio de la NCWIT en el top 5 están:

Aunque puede pensarse que las listas anteriores son opciones personales o “cuestión de gusto”, el estudio de la NCWIT demuestra que no es tan simple. Los capítulos 3 y 4 del mismo exploran algunos de los factores más sistémicos que pueden contribuir a estos factores. Te invitamos a que le eches un vistazo (en inglés).

Según estos datos parece que solo sabemos avanzar desde el punto de vista tecnológico y nos hemos estancado como sociedad. Por suerte existen algunas iniciativas que intentan atajar este problema desde la base, por ejemplo, en España tenemos Girls in Tech-Spain o Women Tech Makers, que aunque es una iniciativa internacional se celebra también en varios sitios en España y hemos tenido la oportunidad de patrocinar en alguna ocasión desde campuMVP. Fuera de nuestro país hay muchas iniciativas, siendo quizá las más conocidas Girls who code o Made with Code.

Sin embargo esto no parece ser suficiente. Y tú, ¿te has planteado alguna vez, qué podrías hacer? ¿Qué podríamos hacer como sociedad?

Esta es una de esas historias que verdaderamente nos gusta contar, y que refleja muy bien el poder individual para crear que nos otorga la tecnología en la actualidad. Todo es cuestión de imaginación, tiempo y perseverancia. Y hablando además de mujeres en tecnología...

Dana Lewis es una universitaria de 28 años de Alabama (EEUU) que tiene diabetes de tipo 1 desde hace más de 14 años. Utilizando sus conocimientos de programación, comprando piezas por Internet, con la ayuda de su marido y con cierta asistencia desde las redes sociales, ha conseguido crear su propio "páncreas artificial" para combatir de manera automática la enfermedad. Y lo mejor: ha hecho Open Source el dispositivo y toda la información relacionada. Por este proyecto, a finales del año pasado, la revista Fast Company nombró a Dana una de las 100 personas más creativas.

El dispositivo ha sido un éxito y ya hay cientos de personas usándolo (bajo su propia responsabilidad), aparte de la propia Dana, claro.

La diabetes se produce cuando el páncreas no es capaz de producir insulina, la hormona encargada de convertir en energía la glucosa del azúcar y de los carbohidratos. Sin insulina el azúcar se aglomera en la sangre. Con demasiada insulina el azúcar puede caer a niveles peligrosos. Lo complicado para los diabéticos es permanecer en el deseado término medio. Un diabético debe tomar decisiones constantemente durante el día sobre cuestiones que impactan sobre sus niveles de azúcar (qué comer o no y cuándo, hacer más o menos ejercicio, pincharse la insulina o no, cuándo y cuánta, dormir demasiado y que pueda caer el nivel de insulina...). Esto implica ir siempre encima con una bomba de insulina y un monitor de glucosa. Medir, inyectar, corregir... Esto suena como un buen trabajo para que lo haga una máquina. Un dispositivo que pueda leer a menudo estos datos y tomar decisiones por ti o asistido por ti.

Dana empezó con un proyecto pequeño hace algo más de 4 años. Vio en las redes sociales a alguien que había encontrado la manera de extraer la información del lector de glucosa. Le escribió para pedirle si le pasaba esa información y le dijo que sí. Con esto construyó un dispositivo que leía la información de su monitor de glucosa cada 5 minutos, la enviaba  la nube y en caso de necesidad le avisaba en el móvil con una alarma. También podía avisar a algún familiar o amigo (en este caso su novio) en caso de que no se enterara (por ejemplo, le ocurrió un par de veces al estar durmiendo).

Posteriormente quisieron ir más allá. Lo siguiente fue analizar todos esos datos y tratar de predecir lo que iba a pasar. De este modo pudieron ir más allá y no solo recibir avisos cuando los niveles eran preocupantes, sino adelantarse a ello y tomar ciertas decisiones, como pulsar el botón de la insulina para inyectarse.

El siguiente paso natural sería que pulsar el botón de la bomba fuese automático si se determinaba que podría haber problemas en el futuro inmediato. Una vez más las redes sociales le ayudaron. Alguien había pensado en la manera de conectarse con la bomba de insulina y compartió con ella el procedimiento.

Con esto cerró el bucle. Ahora tenía un monitor continuo de su nivel de glucosa, un sistema que analiza los datos recibidos, saca conclusiones, envía alarmas, y que también es capaz de enviar instrucciones a una bomba de glucosa.

Los primeros prototipos los hicieron con Raspberry Pi (foto de la izquierda), pero el actual diseño, mucho más pequeño (derecha), está hecho con un chip Intel Edison. Así que el dispositivo "páncreas artificial" es cómo llevar un pequeño paquete de chicles en el bolsillo. En la foto se ve el interior (con una goma alrededor) y el exterior

El dispositivo final estuvo listo en diciembre de 2014. Una pequeña empresa y mucho menos una persona, no pueden fabricar y distribuir un dispositivo médico como este. Demasiadas regulaciones (lógicamente) y demasiado coste. Pero lanzarlo como proyecto Open Source en Internet no está sujeto a regulaciones. Así que es lo que Dana hizo en su página OpenAPS, con instrucciones, código y describiendo las herramientas necesarias para construirlo. Dana también divulga sobre diabetes, derechos de los pacientes, etc... en su otra Web, DIYPS.org que inició antes de la anterior, con los primeros pasos de su dispositivo. Es interesante echarle un vistazo. Y puedes verla explicando el proyecto en sus propias palabras en O'Reilly.

Entity Framework es el ORM (Object-Relational Mapper) de Microsoft, con versiones tanto para la plataforma .NET "tradicional" como para .NET Core.

Como vimos en el artículo del enlace anterior, en el que se explicaba con detalle qué es un ORM, este tipo de software puede funcionar de varias maneras diferentes a la hora de "mapear" las clases de nuestro programa orientado a objetos y las tablas en la base de datos.

Entity Framework no es una excepción, y nos ofrece diversas maneras de trabajar con los datos desde nuestros programas. Cada una tiene un enfoque diferente y es interesante para ciertos casos concretos, además de tener sus beneficios y problemas.

Vamos a dar un repaso rápido a los 3 modos de trabajo principales de Entity Framework para ver en qué consisten y sus ventajas e inconvenientes.

Nota: debes tener muy claras las diferencias entre EF6 y EF Core antes de seguir. También las diferencias y similitudes entre la plataforma .NET "tradicional" y .NET Core.

Es importante tener en cuenta que las capacidades de Entity Framework en .NET "tradicional" (EF6) y en .NET Core (EF Core) son completamente diferentes. Así, los tres modos de trabajo descritos a continuación están completamente soportados en EF6, pero EF Core solamente soporta "Code First" y muy poquito de "Database First". "Model First" en .NET Core ni está ni se le espera. A continuación lo detallaremos más.

Database First

En este modo se parte de una base de datos pre-existente con la que queremos trabajar. Es decir, tenemos la base de datos ya diseñada y probablemente con datos y lo que queremos es que EF se encargue de generar las clases necesarias y toda la "fontanería" interna para trabajar con ella.

Se suele utilizar si aprovechamos una base de datos existente y queremos crear una nueva aplicación sobre ésta. Por ejemplo, vamos a modernizar una aplicación antigua y queremos aprovechar todo lo que hay en la capa de datos, o si le añadimos una nueva API por encima a una aplicación que usa otra tecnología para el acceso a datos.

En este caso Entity Framework creará las entidades orientadas a objetos (las clases) de manera automática, y las actualizará en caso de que haya cambios en la base de datos subyacente. Para generar las entidades utiliza plantillas T4 (que son una mezcla de texto y lógica que permiten generar nuevos archivos). Si queremos una personalización especial para alguna entidad generada deberemos tocar las plantillas T4 o bien usar clases parciales.

Ventajas o beneficios de Database First

• El trabajo en Visual Studio es muy visual. El diseñador visual muy cuidado
• Son muy sencillas de implementar, pues casi todo va en automático y parten de la base de datos
• Si tienes costumbre de trabajar con bases de datos, llevando a cabo primero el diseño E-R, y te sientes menos cómodo con código C#, entonces estarás como en casa.
• Se lleva bien con proyectos de datos grandes, con muchas tablas, convenientemente repartidas en varios modelos.
• Es muy complicado que pierdas datos al hacer modificaciones en el modelo, ya que las harás en la base de datos, no en el código de la aplicación.

Problemas o inconvenientes de Database First

• El código resultante para los modelos tiene infinidad de código auto-generado sobre el que tenemos poco control y que puede acabar "pesando" mucho. Si hay algún problema te costará más ver de dónde te viene.
• Si necesitas personalizar las clases o su comportamiento debes extenderlas con clases parciales o bien tocando las plantillas T4. Dependiendo de lo que quieras hacer puedes acabar escribiendo bastante código, que probablemente es lo que querías evitar usando este modelo.
• Cada vez que haces cambios en la base de datos se debe regenerar el archivo EDMX que la representa, lo cual puede llevar bastante tiempo dependiendo de lo grande que sea. Si estás haciendo y probando muchos pequeños cambios puede llegar a desesperarte.

Database First solamente está soportado completamente en la plataforma .NET (EF6). En Entity Framework Core podemos generar las entidades y los contextos de datos utilizando una herramienta de línea de comandos, pero no disponemos de ningún diseñador ni nada que nos permita hacerlo de manea interactiva. Tampoco existen plantillas T4 para editar, ni archivos EDMX. La actual herramienta solo permite hacer la generación desde una base de datos inicial, pero si luego hay cambios sobre ésta no podremos incorporarlos al modelo. En la próxima versión 2.1 se supone que incorporarán esta posibilidad.

Model First

Este nombre puede despistarte, sobre todo si vienes del mundo MVC, en el que el "Modelo" de la "M" en su nombre, es código que escribes para modelar tus datos. En este caso se refiere a crear tu modelo de datos visualmente, usando el Diseñador de Modelos de Visual Studio. No tienes que escribir código alguno.

Describes visualmente el modelo de objetos que quieres crear, con las entidades, sus propiedades, relaciones entre ellas (que generan propiedades de navegación entre las entidades), etc... y luego Entity Framework se encarga de generar la base de datos subyacente o modificarla y también las entidades POCO (Plain Old C# Object, o sea, clases normales y corrientes de C#) que representan dicho modelo, usando plantillas T4.

Ventajas o beneficios de Model First

• El diseñador visual facilita enormemente el diseño del modelo de datos.
• Es un sistema interesante porque te evita tanto escribir código como definir la base de datos (aunque puedes generar el modelo inicial de una base de datos preexistente si quieres). Si no eres de las personas que disfrutan escribiendo código y mucho menos definiendo bases de datos, te ahorrará muchos desvelos.
• Es muy productivo en proyectos pequeños, pues te olvidas de definir clases y de tocar bases de datos. Es lo más parecido a la "magia" que te ofrece EF.

Problemas o inconvenientes de Model First

• Pierdes el control tanto de la base de datos como de las clases generadas. Se encarga de todo EF, lo cual es estupendo si no necesitas nada "especial", pero te quita control en otros casos.
• Si quieres extender las clases, como antes, debes tocar las plantillas T4 o definir clases parciales.
• Por defecto los cambios que hagas en el modelo no generan scripts SQL incrementales, sino completos. Esto quiere decir que si haces un cambio y regeneras la base de datos, se elimina la actual y se crea de nuevo. Esto puede significar que pierdas los datos que ya tuvieses en la misma, así que mucho cuidado.

Este modo de funcionamiento sólo está disponible en EF6, es decir, en la plataforma .NET "tradicional", pero no en .NET Core. Existen algunas herramientas de terceros que permiten gestionar el modelo de forma visual, tanto para EF6 como con EFCore (y otros ORM), pero no debemos confundir esto con Model First: se trata tan solo de una capa de gestión visual que por debajo trabaja con Code First (que veremos a continuación).

Code First

Si en Database First empezábamos por la base de datos generando EF todo lo demás, y en Model First estábamos en el "medio" definiendo el modelo para que EF generase tanto las clases como la base de datos... en Code First nos situamos en el otro extremo del espectro: definimos nuestras clases mediante código, y EF se encarga de generar la base de datos y todo lo necesario para encajar las clases en ellas.

Se trata de un enfoque muy orientado al programador. Es para gente a la que le gusta escribir código y tener control total sobre cómo se comportan sus clases. En este caso EF no genera código, ni necesita complejos y pesados archivos EDMX para mapear objetos a la base de datos, por lo que todo es más ágil.

El programador define su modelo usando clases normales (POCO). Relaciona unas con otras simplemente haciendo referencia entre ellas en propiedades. A mayores puede decorar algunas propiedades de estas clases de forma especial (las llamadas "Annotations", "Anotaciones" en inglés) si quiere indicar cosas concretas, como por ejemplo el nombre que quiere darle al campo correspondiente en la base de datos, y cosas así. Y puede implementar algunos métodos de la clase dbContext para indicar cómo mapear ciertas cosas con la base de datos.

Por lo demás solo es necesario usar una herramienta de "Migraciones" desde el gestor de paquetes de Visual Studio para generar la base de datos, que se ve como un mero sistema de almacenamiento sin ninguna lógica, la cual se implementa en el código de las clases que hemos creado.

Ventajas o beneficios de Code First

• Máximo control sobre el código de tu modelo de datos en C#, ya que son clases que construyes desde cero.
• Te ofrece control sobre las colecciones de objetos que quieres que se carguen de modo "perezoso" (es decir, a medida que se vayan necesitando).
• No tocas una base de datos ni con un palo. El código es el que manda y el "tooling" se encarga de generar la base de datos en función de tu código.
• La estructura de la base de datos es muy fácil de mantener bajo control de código (con Git o similar) ya que no se guarda en absoluto: se guarda el código de nuestras clases del modelo, y se genera la base de datos bajo demanda.

Problemas o inconvenientes de Code First

• Debes dominar bastante más EF que con los enfoques anteriores.
• Cualquier cosa que necesites persistir u obtener de tu base de datos la tienes que implementar en código C# y LINQ. La base de datos que se genera por detrás no la puedes tocar.
• Si tu base de datos es muy grande y con muchas tablas, la gestión de la base de datos se puede convertir en un pequeño dolor de muelas.

Este es el único modo verdaderamente soportado por EF Core. Por ello es el más utilizado y en el que más hincapié se debe hacer a la hora de aprender, ya que nos servirá tanto para EF6 como para la plataforma más moderna de Microsoft.

¿Cuál escoger?

Ahora que hemos repasado las opciones, conociendo en qué consisten y sus ventajas e inconvenientes... ¿Cuál sería la mejor opción?

Bueno, si lo tuyo es .NET Core te quedas sin opciones: deberás usar Code First, sí o sí.

En el caso de EF6 y .NET "tradicional", tienes acceso a todo, por lo que para elegir, como todo en la vida, dependerá de muchos factores.

Los más puristas prefieren el enfoque de Code First frente a los demás. Les da el máximo rendimiento y control y además desde el punto de vista de un programador "puro", la base de datos es solo un mal necesario y lo importante es nuestro código. Además podrás aplicar casi todo a EF Core.

Los que dominan y valoran las bondades de las bases de datos, por el contrario, suelen preferir alguno de los anteriores, especialmente el Database First.

Si tu proyecto es pequeño y no va a tener muchas tablas/entidades que manejar, Code First puede ser muy cómodo y ágil, con control total por tu parte. Si por el contrario hay muchas tablas y el proyecto de datos es grande, Database First puede ser una gran opción aunque algún "purista" se rasgue las vestiduras.

En caso de que no te gusten demasiado las bases de datos ni tampoco tener que escribir todo el código de "fontanería" a mano, el enfoque Model First es una buena opción para los más vagos (dicho sea desde el cariño), ya que te permite diseñar visualmente las entidades/datos que quieres manejar y se encarga automáticamente de todo lo demás: generar las clases del modelo y las tablas en la base de datos, mapeándolos entre sí de manera transparente.

¡Espero que te resulte de ayuda!

Nota: el artículo original es de Jakub Skalecki, traducido con su permiso expreso. Puedes seguir a Jakub en Twitter y en LinkedIn.

En esta ocasión vamos a hablar de una gran herramienta que se usa mucho en el día a día trabajando como desarrollador. Se llama Docker. Antes de nada, aclarar que este post va dirigido a principiantes.

Sí, he oído hablar de Docker, ¿pero qué es en realidad?

Docker es una herramienta para crear y ejecutar "máquinas virtuales ligeras". Se distribuyen en paquetes que por regla general contienen:

• Una pequeña distribución de Linux (aunque también trabaja con Windows),
• todas las dependencias necesarias para que tu aplicación se ejecute,
• y el código de tu aplicación.

Se llaman "imágenes Docker" y puedes pensar en ellas como "cajas negras ejecutables". Estas imágenes se pueden utilizar para crear un número arbitrario de "contenedores", procesos aislados con acceso a todas las dependencias preparadas. Una cosa importante es que cada contenedor es una copia exacta de una imagen, incluso si se inicia en un sistema operativo diferente. No importa qué tecnología o lenguaje se requiera para ejecutar tu aplicación, si tienes instalada la imagen y Docker, podrás ejecutarla.

Voy a procurar que este artículo sea breve y conciso, así que pasemos a las ventajas de usar Docker. Si quieres saber más, puedes consultar la este artículo + vídeo.

¿Por qué debería darle una oportunidad a Docker?

Recordemos, no tienes por qué entrar "de lleno".

Te aconsejo que vayas incorporando soporte con Docker en tu aplicación de manera progresiva. Empieza a usarlo en desarrollo. Comenta con los demás en tu equipo de desarrollo que pueden usar Docker, muéstrales cómo usarlo. Espera a ver qué pasa, acostumbraos a utilizarlo y familiarizaos con él. Cuando alguien pregunte "oye, ¿por qué diablos no hemos empezado a trabajar con esto antes?", ya quizás sea el momento de empezar a pensar cómo integrarlo en la fase de producción... Pero centrémonos en la fase de desarrollo por hoy.

En desarrollo, Docker te permite conservar toda la infraestructura en forma de código y compartirlo con todos los miembros de tu equipo. ¿Te suenan conversaciones de este estilo?:

(Tú): -"Oye Pedro, mi aplicación en desarrollo no arranca... ¿Has tocado algo?"-

Pedro: -"Ah, sí, se me olvidó comentarte. Tenemos un nuevo motor de base de datos. Además hay que instalarle el redis y los drivers. Es muy sencillo, échale un ojo a la documentación y lo haces en un minuto."-

Claro, siempre lleva más tiempo que ese "minuto". Si trabajas en un equipo muy grande, estas cosas pasan mucho más a menudo y se complica mucho identificar el origen de los problemas. Con Docker, para sincronizar los cambios solo hay que ejecutar docker-compose up --build, y en breves instantes la nueva versión de la pila de desarrollo estará en funcionamiento, independientemente de lo que haya cambiado. Además, el hecho de incorporar un nuevo programador en el equipo de desarrollo no supondrá trauma alguno, ya que todo será igual... Imagina cuánto tiempo se puede llegar a ahorrar.

Personalmente, trabajo con muchas tecnologías diferentes en paralelo, usando diferentes versiones de dependencias comunes (por ejemplo, bases de datos). Docker me permite aislarlas. También, independientemente de la tecnología, puedo trabajar siempre de la misma manera- docker-compose up- y para adelante...

Hay un lugar llamado Docker Hub. Es una tienda oficial con un montón de imágenes listas para ser utilizadas, que puedes emplear en tu "stack" de desarrollo. ¿Necesitas redis? ¿Postgres? ¿MySQL, Apache, PHP, nGinx, Python, Ruby, NodeJS? ¡Todo disponible en un clic!

Bien, la cosa promete. ¿Cómo empezar?

Primero: instala docker y docker-compose.

Puedes acceder a las instrucciones oficiales aquí y aquí.

Segundo: añade un Dockerfile propio a tu aplicación

Dockerfile contiene una lista de instrucciones que se tienen que ejecutar para preparar el entorno, para luego poder ejecutar tu aplicación. Por ejemplo, aquí copias tus archivos de proyecto, instalas todas las dependencias del sistema y la aplicación, haces los ajustes de configuración, etc... Por ejemplo, veamos un Dockerfile que se utiliza para un proyecto en Python:

FROM python:3.6

ENV PROJECT_ROOT=/srv
WORKDIR $PROJECT_ROOT

COPY requirements.txt .
RUN pip install -r requirements.txt

COPY . .

CMD ["python", "manage.py", "runserver"]

Por lo general no se necesita nada más sofisticado. Para encontrar instrucciones sobre cómo crear un Dockerfile para tu lenguaje de programación solo tienes que buscarlo en Google, hay muchísimos recursos sobre esto en particular.

Si quieres aprender sobre buenas prácticas, este artículo ya ha ayudado a muchas personas. También te puedes dirigir a la página oficial.

Tercero: crea un archivo docker-compose.yml.

Docker-compose es una herramienta genial que nos permite gestionar simultáneamente varias pilas de contenedores sin traumas. Este archivo especial le dice a docker-compose qué contenedores tienen que iniciarse.

Este es un ejemplo de docker-compose.yml que utilizo:

version: '2'
services:
redis:
  image: redis

database:
  image: postgres

app:
  build: .
  environment:
    DEBUG: 1
  ports:
    - 8000:8000
  volumes:
    - .:/srv
  command: python manage.py runserver

Este archivo indica que queremos que Redis y Postgres se creen usando imágenes oficiales, y que nuestra aplicación se cree desde Dockerfile en local, disponible desde la red de Docker externa a través del puerto 8000, con todos los archivos locales montados dentro del contenedor para facilitar el desarrollo. Se pueden encontrar todas las opciones aquí. En este ejemplo se usa la versión 2 porque la versión 3 soporta Docker Swarm que no se necesita en desarrollo.

Ahora, cuando introduzcamos docker-compose up, esto es lo que va a suceder:

1. Docker intentará descargar / crear todas las imágenes requeridas. Si usamos la opción image, se descargará de Internet, por defecto desde DockerHub. La opción build dará instrucciones a Docker de crear la imagen usando el Dockerfile ubicado en un directorio concreto, en nuestro caso . (dir actual). Si la imagen ya existe, no se volverá a comprobar automáticamente (para hacerlo, debemos añadir la bandera --build)
2. Cuando las imágenes están disponibles, docker-compose comprobará si la configuración ha cambiado desde la última ejecución. Si no, se inician contenedores usados con anterioridad, y en caso contrario, se crean nuevos contenedores. La configuración de cosas como puertos, volúmenes, variables, redes, etc... se toman desde docker-compose.yml.
3. Si no se indica lo contrario, se crea una red especial, abarcando todos los contenedores creados. Les permite referenciarse entre ellos usando nombres en vez de direcciones IP. Como muestra, en el ejemplo, la base de datos de la aplicación estará disponible en postgres:5432.
4. Todos los contenedores se inician a la vez, y vemos logs de todos ellos.

Y eso es todo. Ahora toda la pila arranca automáticamente. Evidentemente deberás hacer cosas como crear automáticamente una base de datos si no existe, o volver a cargar el código de la aplicación tras un cambio para hacer que la experiencia de desarrollo sea más agradable. Lo importante aquí es que solo tienes que preparar esto una vez y todo el equipo de programación se beneficiará de ello inmediatamente.

Aviso: a la hora de programar, probablemente debas usar siempre la opción volumes en tu archivo docker-compose.yml, montando los archivos locales en el contenedor. Sin esta opción, tendrás que rehacer el contenedor cada vez que haya algún cambio.

Uso típico

Estos son algunos de los comandos más utilizados en el día a día.

• Empezando a trabajar:docker-compose up o docker-compose up --rebuild si sabes que algunas dependencias han cambiado.

• Ejecutando comandos una sola vez: depende de si necesitamos disponibles otros contenedores, como la base de datos, o no. Si es así, arranca la pila con un comando anterior, y en otro ventana de terminal ejecuta docker-compose exec $SERVICE_NAME $COMMAND. Si no, solo usa docker-compose run --rm $SERVICE_NAME $COMMAND (yo recomiendo el "flag" --rm para eliminarlo después del comando)

• Eliminar todo lo creado por docker-compose: docker-compose down. Eliminará todos los contenedores, imágenes y redes.

• Eliminar un contenedor con todos los datos asociados: docker-compose rm -v $SERVICE_NAME (muy útil si quieres restablecer completamente una base de datos).

¡Esto es todo por ahora!

Espero que este artículo haya sido muy útil para empezar con Docker. Si te gusta esta post, no dudes en compartirlo.

Esto parece una broma de conspiranoicos, pero es muy real. ¿Has notado que tu despertador o el reloj del horno han ido atrasando poco a poco últimamente? Pues le ha pasado a mucha más gente.

Los relojes digitales más comunes, de pared o de muñeca, llevan una pila y utilizan un cristal de cuarzo para mantener la hora. El cristal vibra a una determinada frecuencia constante cuando lo atraviesa la corriente y eso es lo que usan los relojes para medir el tiempo.

Sin embargo, los relojes típicos que puedes encontrar en un horno o en los despertadores que van directamente enchufados a la red eléctrica utilizan un método diferente. Como sabrás, la corriente eléctrica que llega a los enchufes es corriente alterna, es decir, cambia de signo varias veces por segundo. Esto ahorra en el transporte de la electricidad a larga distancia y aumenta la eficiencia. En Europa la frecuencia de oscilación es de 50Hz, es decir, la corriente cambia de signo 50 veces cada segundo, y esto se mantiene constante. Los relojes enchufados utilizan este hecho para medir el tiempo, ya que saben que cada 50 cambios de polaridad de la corriente ha pasado un segundo. Esta medida es bastante fiable casi siempre.

Sin embargo hay más factores a tener en cuenta en esta historia. La red eléctrica europea está muy interconectada, de modo que cuando un sitio necesita más energía, esta necesidad puede ser atendida por electricidad generada en un país diferente, a miles de kilómetros de distancia. En la actualidad forman parte de esta red continental 26 países, incluyendo a Turquía o a Suiza, que no forman parte de la comunidad económica (puedes ver un mapa bastante detallado en PDF aquí que podrás ampliar como necesites para ver el detalle):

Bien. Esta red eléctrica "global" actúa como un conjunto de vasos comunicantes: para mantenerla estable el consumo que existe se debe corresponder aproximadamente con la producción. Es decir, si se consume más se debe producir más en toda la red y viceversa. Esto es necesario porque si baja el consumo aumentaría la frecuencia de la corriente, y si sube bajaría dicha frecuencia.

Generalmente esta frecuencia se mantiene dentro de unos límites muy estrictos (el mínimo admitido es de 47,6Hz y el máximo es de 52,5Hz) y de hecho existen dos entidades que se dedican a vigilarlo y ajustarlo en función de los datos, una en Suiza y otra en Alemania. Incluso podemos consultar en tiempo real el estado de la frecuencia de la red eléctrica europea:

Todo esto es muy interesante. Pero luego viene la realidad a fastidiar las cosas, y es que si no hay datos fiables, las cosas se pueden descompensar.

Lo que ha estado ocurriendo es que Serbia y Kosovo han tenido una disputa (otra) sobre el consumo de energía que se ha transferido entre sus dos redes. Debido a esta discrepancia en los datos hay nada menos que 113KWh que han desaparecido. No se han registrado convenientemente y no se sabe qué ha pasado con ellos (yo digo, tú dices y nadie sabe qué ha ocurrido realmente).  Para que te hagas una idea, esto es equivalente a la electricidad que consumen anualmente 10.000 hogares 😵

Como se ha contabilizado mal el consumo y la producción, se ha descompensado ligeramente toda la red eléctrica europea, esto ha hecho que, aunque supuestamente la red estaba a 50Hz, en realidad haya estado durante varios meses a 49,996Hz. Algo muy pequeño como para hacer saltar las alarmas pero suficiente para que los relojes que dependen de esta frecuencia hayan atrasado en total unos 6 minutos desde enero hasta finales de la semana pasada.

Aún no se sabe a dónde ha ido esa energía ni quién es el responsable (Serbia y Kosovo siguen discutiendo el tema) pero parece ser que ya se ha solucionado y que van a aumentar ligeramente la frecuencia un tiempo para que los relojes que no son fáciles de ajustar manualmente (y no, no nos referimos a tu despertador). Por lo tanto si ajustas ahora tus relojes, dentro de unos meses van a estar adelantados y tendrás que ajustarlos otra vez  cuando la frecuencia vuelva a ser 50Hz exactamente. Lo mejor, de todos modos, es utilizar un reloj digital que no esté afectado por estas cuestiones.

Una vez más se evidencia cómo la dependencia que tenemos de la tecnología, incluso de tecnologías tan antiguas como la electricidad, nos puede impactar de manera directa.

Esperemos que no vuelva a ocurrir.

Y tú ¿has usado ya este fenómeno para justificar esos minutillos que llegas tarde a una cita? 😉

GitHub es usado por más de 24 millones de personas de 200 países diferentes que han participado en proyectos a través de más de 25 millones de repositorios. Estas cifras astronómicas convierten a GitHub en el mayor repositorio de proyectos open source del mundo, así como en testigo único de lo que “se cuece” en programación.

El personal de GitHub analizó los datos correspondientes al pasado año, y según ellos las tendencias para 2018 en proyectos open source son:

Nota: Imagen de GitHub

Desarrollo web y multiplataforma

En el sector de desarrollo web y multiplataforma, los repositorios Angular / angular-cli registraron el mayor crecimiento con 2,2 veces más usuarios en 2017 que en 2016. Otros proyectos relacionados con Angular, React y Electron de Facebook, también tuvieron mucho éxito.

Deep Learning

Los desarrolladores acuden a GitHub para ver proyectos de deep learning a medida que la inteligencia artificial continúa creciendo. Dos repositorios TensorFlow crecieron: TensorFlow /models experimentó 5.5 veces más tráfico y TensorFlow / TensorFlow tuvo 2.2 veces más tráfico en 2017 que en 2016.

El deep learning ha crecido en popularidad dentro de las empresas siendo usado en reconocimiento de imágenes y voz. Compañías como Google, Facebook, Microsoft y Amazon están invirtiendo en ello.

Desarrollo profesional

Los repositorios diseñados para enseñar nuevas habilidades, especialmente nuevas habilidades de programación, también han tenido mucho éxito. Los proyectos educativos más populares enseñaban lenguajes como JavaScript y Python, otros te orientaban sobre cómo pasar las entrevistas o sobre gestión de proyectos. Mientras que los proyectos open source pueden considerarse como educativos por naturaleza, los repositorios creados específicamente para enseñar a otros pueden ser especialmente útiles para aprender o revisar habilidades.

Contenedores

También se aprecia un importante crecimiento en la edición de código, el diseño, la containerization y el desarrollo.

En lo que a contenedores se refieren destacan Docker y Kubernetes. Docker se encontraba entre los diez mejores de todos los proyectos en GitHub, mientras que Kubernetes estaba entre los diez primeros en la categoría de "proyectos más revisados", y también fue, de hecho, el proyecto más comentado en GitHub ese año.

Si deseas tener datos detallados sobre cuáles han sido los proyectos más revisados, los más populares o con más ramificaciones, puedes echar un vistazo a Universe.

Este artículo es una traducción del original de Yash Ranadive en Hackernoon.

Como desarrolladores, estamos familiarizados con los diversos problemas que interfieren con nuestra productividad. Pero a menudo los árboles no nos dejan ver el bosque, perdiendo perspectiva. Algunos pueden ser sutiles, otros enormes, por algunos se puede hacer algo, y hay otros por los que, simplemente, nada se puede hacer. Muchas veces se combinan para formar una especie de bucle que se retroalimenta a sí mismo y que suele llevar a la pérdida de horas de productividad, errores de programación, y a la frustración generalizada.

Si pudiésemos minimizar el impacto de tan solo uno o dos de estos sesgos podríamos romper el ciclo y neutralizar a los demás. A continuación tienes una lista de 5 sesgos cognitivos que debes tener en cuenta mientras estás programando:

El descuento hiperbólico

Ir a por una recompensa inmediata en lugar de demorar una mucho mayor

¿Alguna vez has retrasado hacer una prueba unitaria? ¿Alguna vez te has encontrado usando las teclas de flechas en Vim? Felicidades, has exhibido comportamiento de descuento hiperbólico. La recompensa inmediata de usar las teclas de flechas supera de largo el sufrimiento de tener que encontrar la sintaxis correcta para navegar a la línea que queremos. Sin embargo, una vez que aprendes a navegar más rápido, la satisfacción futura es mucho mayor. Terminas ahorrando muchísimo tiempo.

El efecto IKEA

Sobrevalorar tus propias soluciones a un problema, y en consecuencia infravalorar otras soluciones

El efecto IKEA es un sesgo cognitivo mediante el cual los consumidores atribuyen desproporcionadamente un alto valor a un producto que han elaborado parcialmente. Tendemos a sobrevalorar nuestras propias soluciones a un problema, y en consecuencia infravalorar otras posibles soluciones. Si alguna vez has trabajado en alguna empresa que ha usado una mala herramienta interna en vez de una mejor solución "paquetizada" lista-para-usarse , ya sabes de lo que estoy hablando.

Optimización prematura

Optimizar antes de saber lo que necesitas

No necesita explicación. Añadirle un alerón aerodinámico a un viejo vehículo antes de arreglarle el motor no hará que vaya más rápido. Un gran ejemplo de esto es escribir un código super tuneado y de gran rendimiento cuando lo que tienes entre manos es un simple experimento.

La falacia de la planificación

Infravalorar de manera optimista el tiempo que llevará completar una tarea

La falacia de planificación es una con la que muchos de nosotros nos podemos identificar. Ya sea nuestra culpa, o la de los jefes de proyectos, o la de nuestros usuarios/clientes, todos tendemos a ser optimistas a la hora de determinar cuándo vamos a terminar una tarea. Esto se demuestra claramente con el viejo aforismo:

"El primer 90% del código equivale al primer 90% del tiempo de desarrollo. El restante 10% del código equivale al otro 90% del tiempo de desarrollo."

El sesgo de lo reciente

Darle más valor a los sucesos recientes que a aquellos que ocurrieron más atrás en el tiempo

El sesgo de lo reciente a menudo nos ocurre cuando necesitamos una solución para un problema, y oye, hace poco solucionamos un problema similar así que usemos esa solución porque nos ha funcionado, ¡y nos acordamos!

¿Te encuentras usando los mismos patrones de diseño una y otra vez? Si es tu caso, probablemente estás enfocando problemas distintos con la misma lente. Al que tiene un martillo, todo le parecen clavos.

Es imposible eliminar nuestros sesgos del todo, pero si somos conscientes de cómo nos están afectando, podemos de alguna manera limitar y mitigar los problemas que nos causan.

Nadie puede criticar la ambición de las empresas que crean MOOC (Massive Open Online Course). Uno de los pioneros de estos centros de aprendizaje en línea, el fundador y presidente de Udacity, Sebastian Thrun, resumió recientemente su misión como nada menos que "democratizar la educación".

Pero, ¿cuán efectivos son estos cursos? Concretamente en lo que al aprendizaje de la programación se refiere, ¿es suficiente hacerse MOOC o un asistir a un bootcamp para comenzar una carrera como desarrollador de software?

A continuación se describe el perfil de las personas que habitualmente terminan con éxito estos cursos (basado en una encuesta de la HBR) y la calidad de los mismos (según los estándares de la Quality Master).

Perfil del usuario

En 2015 la Harvard Business Review publicó una encuesta titulada “¿A quién benefician realmente los MOOC y por qué?”, algunas de las conclusiones a las que llegaron fueron:

• Los críticos tienen razón al decir que la mayoría de las personas que inician un MOOC no terminan: solo el 4% de los usuarios de Coursera que ven al menos una clase del curso continúan hasta completar el curso y recibir una credencial.
• Los que terminan buscan, o bien beneficios educacionales, o bien beneficios profesionales:
  • El 52% indica que su principal objetivo es mejorar su empleo actual o bien encontrar uno nuevo.
  • El 28% se matricularon principalmente para lograr un objetivo académico, como obtener conocimiento en su campo (88%), o un beneficio tangible como un título académico (18%)
• En lo que respecta al perfil de usuario, la mayoría de las personas que se inscriben en estos cursos tienen una buena educación y pertenecen a países desarrollados. Además cuando lo que buscan es potenciar su carrera, aquellas personas con mayor poder adquisitivo y mayor nivel educativo tienen una mayor probabilidad de éxito.

Según lo anterior parece que el perfil del estudiante que termina con éxito un MOOC es alguien que ya tiene conocimientos de la materia escogida y que busca profundizar en un aspecto concreto de la misma.

Calidad

Sin duda, la confianza y el reconocimiento, incluida la necesidad de convencer a las empresas de que confíen en la calidad de su acreditación, es algo que toda empresa de formación persigue debería perseguir ¡y las empresas que ofrecen MOOC y los bootcamps no iban a ser menos!

Sin embargo, según un reciente estudio realizado sobre un número limitado de cursos impartidos en las plataformas más populares de USA (Coursera, Udacity y EdX), ninguno de los cursos examinados superaba la revisión Quality Matters la cual evalúa la medida en que los cursos cumplen con un conjunto de estándares para la educación online. Las áreas en las cuales obtuvieron menor puntuación hacían referencia a la falta de apoyo que ofrecía el tutor al alumno (esto nunca te pasará en campusMVP, nuestros tutores responden tus dudas en menos de 24 horas) y al poco compromiso por parte de los estudiantes (con nosotros nunca estarás solo).

Si bien los cursos examinados no cumplieron con los estándares suficientes para aprobar la evaluación, algunos obtuvieron calificaciones relativamente altas, los investigadores dijeron que algunos de los MOOC podrían considerarse "cursos online de alta calidad tras algunas revisiones menores".

En verano de 2017 dos de los más conocidos bootcamps de EE.UU. echaron el cierre, Dev Bootcamp (de la empresa Kaplan), y The Iron Yard (de Apollo Education Group, partner de la universidad de Fénix). Cuando DevBootcamp anunció que estaba cerrando, la empresa admitió que “había sido incapaz de encontrar un modelo sostenible que aunara calidad de enseñanza y a la vez fuese accesible a todo el mundo”. Aquí puedes leer el artículo completo en inglés.

Los MOOC son accesibles, pero a veces diluyen el contenido demasiado, mermando así su calidad, porque lo que buscan es llegar al mayor número de personas.

En resumen

Parece, que en lugar de ayudar a impulsar la carrera de personas sin experiencia relevante o permitirles adquirir conocimientos en una nueva área, algunas evidencias sugieren que los MOOC son quizás más adecuados para ayudar a aquellos que ya son expertos en un área particular a especializarse aún más.

Y tú ¿qué opinas? ¿Has hecho algún MOOC alguna vez? ¿Qué calidad tenía? ¿Lo has terminado? Déjanos tus impresiones en los comentarios.

El objetivo principal de trabajar con un sistema de control de código fuente como Git es, por supuesto, mantener un histórico fiel e inalterado de todas las etapas por las que ha ido pasando el código fuente de un proyecto. A medida que vamos modificando el código y haciendo commits, su historia  se va ampliando. En cualquier momento podemos ver el estado exacto que tenía un archivo en cualquier momento del pasado, e incluso ver quién ha hecho un cambio concreto, lo cual es de gran utilidad. Sin embargo, a veces, podemos añadir algo a esta historia que no pretendíamos añadir. Por ejemplo, hacemos un commit sin querer, metemos archivos de más o de menos, o va con un bug vergonzoso que no queremos que nadie vea y que se nos ha colado...

Por regla general no deberíamos modificar la historia salvo que sea estrictamente necesario, pero ¡hey!, estas cosas pasan, así que deberíamos poder arreglarlo.

Git es fácil de usar en el día a día, pero cuando aparece algún problema entran siempre en juego muchas variables y puede complicarse la cosa. ¿Cómo arreglamos esto?

Vamos a ver varios casos que se refieren exclusivamente a cuando se trata del último commit realizado. Si es un commit anterior dependiendo de lo que necesitemos habría que hacer otras cosas, pero este es el caso más habitual, así que es el que vamos a ver por brevedad.

En Git existen muchas maneras de hacer las cosas. Estas que cuento a continuación no tienen por qué ser las únicas, pero son las que a mí me parecen más directas y sencillas.

El commit NO está en Github todavía

Bueno, este es el caso fácil. Si hemos hecho el commit y todavía no se ha enviado al repositorio de origen (en Github, GitLab, Bitbucket o donde sea), podemos solucionarlo de varias maneras.

Volver al último commit empezando de cero

Si lo único que necesitas es eliminar este último commit y empezar de nuevo solo tienes que abrir una línea de comandos  en la carpeta del repositorio y escribir:

git reset HEAD^ --hard

Lo que hace esto es eliminar el último commit de la historia, dejando la carpeta en el punto anterior en el que estaba antes de hacer los cambios correspondientes a dicho commit.

El ^ del final de la cabecera le indica a Git que el punto de la historia en donde deseas  dejarla (resetearla), es el padre del último commit en la rama actual (que se llama siempre HEAD). Es importante indicarlo.

Ahora bien, esto hará que pierdas todos los cambios que había en éste. 

Volver al último commit pero no perder los cambios actuales

Lo anterior será lo que desees hacer en muchos casos, pero en muchos otros no. A lo mejor lo que necesitas corregir está en un solo archivo y los cambios de los demás te parecen bien. En estos casos está bien eliminar el commit pero al mismo tiempo evitar perder los cambios. Conseguirlo es casi idéntico a lo anterior, y solo debes escribir:

git reset HEAD^ --soft

De este modo deja todo tal cual está.

Me he olvidado de uno o varios archivos

Si no te hace falta algo tan radical y simplemente te has olvidado de añadir algún archivo  al último commit, no hace falta que deshagas todo como acabamos de ver.

Puedes escribir tan solo este comando para añadir los que te falten:

git add archivo1.ext archivo2.ext ...

Ten en cuenta que puedes usar patrones para añadir varios archivos con un nombre similar de golpe, o simplemente hacer una lista como se ve en lo anterior.

Cuando hayas añadido los archivos que te faltasen, indicas que quieres modificar el commit anterior en base a esto, escribiendo:

git commit --amend

lo cual añadirá el o los archivos al último commit que todavía está en tu equipo.

Nota: si haces esto así, desde línea de comandos, la opción --amend te abre un editor vi por si quieres modificar el mensaje también. Para salir y terminar con la operación debes pulsar ESC y a continuación :x o :q para que salga y grabe los cambios.

El commit ya se ha enviado al servidor remoto (Github, Gitlab, Bitbucket...)

Esta es una pregunta muy frecuente de la que hay muchas versiones diferentes online para su respuesta, muchas de ellas incorrectas. Se trata de hacer lo mismo que acabamos de ver, pero esta vez teniendo en cuenta que no solo está en nuestro equipo local, sino que dicho commit también se ha enviado al servidor de origen, sea éste Github, Bitbucket, Gitlab o similar.

En este caso en realidad es bastante sencillo de hacer también. Vamos a distinguir dos casos...

El repo local y el remoto están sincronizados

Este es el caso más habitual. Es decir, estamos trabajando en un repositorio, hacemos cambios, realizamos un commit para guardarlos en la historia y lo enviamos al remoto usando push. Acto seguido nos damos cuenta de que va con un error muy gordo y queremos echarnos para atrás. ¿Cómo lo hacemos?

Pues en primer lugar destruyendo el commit localmente como hemos visto en el apartado anterior, con:

git reset HEAD^ --hard

y a continuación forzando los cambios al repositorio remoto de origen con:

git push origin -f

En condiciones normales un push al origen falla si el commit que está "arriba" no es un ancestro del commit que se está intentado hacer. Es decir, si el repo remoto va por delante del repo local. Con el parámetro -f (o --force que es lo mismo) forzamos a que esta comprobación no se haga. Esto puede tener efectos destructivos y que se pierdan los commits que van por delante de nosotros, cosa que es justo lo que queremos en este caso: con la instrucción reset estamos situados en un commit inmediatamente anterior al último y con el push forzado estamos haciendo que éste desaparezca.

¡Espero que te resulte útil!