Probablemente no diga nada nuevo si hablo de que conseguir equipos técnicos que funcionen es un camino muy complicado. Cada persona es un mundo complejo de características tanto personales como profesionales que afectan al correcto funcionamiento del equipo. Además, en los centros de formación tratan de enseñar a ser los mejores profesionales técnicos, pero no trabajan de igual manera la parte personal. Enseñan los mejores algoritmos de búsquedas, pero algo tan simple e imprescindible como la comunicación, no está ni tan siquiera evaluada.

¿Y si te digo que existe un framework capaz de alcanzar toda la potencia de un SPA moderno pero sin entrar en contacto con código Javascript, sólamente usando C#? Pues sí, existe; y como habrás intuido, esto es lo que nos ofrece Blazor. ¿Quiere decir entonces que ya podemos olvidarnos de Javascript? Bueno, vayamos por partes.

A nadie le sonará raro hoy en día oír la palabra “líder técnico” (o teach lead) en cualquier empresa tecnológica para definir el rol o cargo de una persona. Normalmente, se suele asignar el rol o cargo a una persona veterana (posiblemente alguien interno de la empresa), con mucha experiencia en el campo técnico y conocedor del negocio, con alta capacidad resolutiva y de gestión de equipo.

¿Es posible hoy en día desplegar una aplicación .NET a coste 0? Pues claro que sí. Hoy os traigo los pasos para poder desplegar exactamente una aplicación Blazor WebAssembly en un servidor Ubuntu y que sea accesible a través del navegador de manera pública.

Es probable que en más de una ocasión te hayas saltado de manera accidental la arquitectura de tu solución, o estándares de programación fijados dentro de la empresa que, con suerte, lograrás detectarlos y pararlos manualmente gracias a procesos ya conocidos como las Pull Request.

Seguro que más de una vez has puesto en duda la utilidad de los tests que realizas. Sientes que el tiempo dedicado es realmente alto en comparación con el coste del desarrollo y, para colmo, tras pasar toda una jornada laboral realizándolos, esa controvertida métrica que tantos dolores de cabeza da, como es el code average, no sube más del 20%…

Es una realidad que los microservicios están entre nosotros y han venido para quedarse, pero como todas las arquitecturas, tienen sus pros y sus contras. En el punto de contras, vemos el pronunciado coste que exigen los sistemas de servicios distribuidos: el tracing.

A raíz de mi anterior post, me gustaría tratar el uso de Git en el IDE que más utilizo como desarrollador .NET: Visual Studio. Suelo recomendar el uso de un IDE para trabajar con Git, no sin antes haber entendido los conceptos que subyacen en las acciones que realiza el IDE (comentados en mi anterior post).

De todos es conocido que Git es el sistema de control de versiones más conocido y usado en el mundo. Aquí os dejo un pequeño cheatsheet de los comandos que personalmente más suelo usar. ¡Espero que os sirvan!

Las revisiones de código son uno de los puntos principales a la hora de realizar código de calidad. En ella, se pretende asegurar el cumplimiento de los estándares de programación, ya sean organizativos, de equipo, o del propio lenguaje de programación. Por tanto, pueden participar tanto miembros del equipo como de la organización. Esto hace que las revisiones de código puedan ser un foco de discusión en el cual hay que ser lo suficientemente cuidadoso para no generar conflictos.

Os voy a recoger lo que para mí son los 5 puntos principales para realizar revisiones de código rápidas, fiables y que no generen controversia.