«En una hora, has reemplazado tres años de herramientas de software sin mantener y nos has dado la capacidad de resolver cada problema de soporte abierto en la cola. Así que, gracias por eso».
Estas palabras vinieron de un cliente. La cola de operaciones era larga, los ingenieros estaban malhumorados y trabajaban demasiado. Carecían de las herramientas necesarias para manejar adecuadamente una aplicación y sus datos. Así que le di al equipo herramientas «apropiadas», herramientas que les permiten abordar los problemas arbitrarios que los usuarios tienden a encontrar, como los encuentran esos usuarios. Y sí, tomó menos de una hora. De hecho, no tomó casi ningún código nuevo. Déjenme mostrarles cómo, y en el proceso ofrecerles una perspectiva única sobre cómo deberían ser estas herramientas y cómo pueden aprovechar tranquilamente su experiencia de desarrollo en el maniático mundo de las operaciones.
¿Para quién «sólo funciona»?
Microsoft y la comunidad han hecho un gran trabajo al proporcionar marcos de software que resuelven los problemas de los desarrolladores que crean aplicaciones. El ejemplo relevante de mi cliente es Entity Framework, que resuelve el problema común de la persistencia de objetos desde la memoria hasta un almacén de datos relacionales como el servidor SQL. De hecho, lo hace de una manera que es casi sin esfuerzo. Simplemente define los modelos que necesitan persistir y declara un tipo de acceso a los datos (dos cosas necesarias para cualquier solución de persistencia de objetos), y Entity Framework simplemente calcula la lógica a partir de los metadatos del modelo. Adhiriéndose a algunas convenciones simples, la persistencia de objetos «simplemente funciona» (bueno, ya sabes, caveat emptor) y el desarrollador puede pasar al siguiente problema.
Lamentablemente, estos marcos no hacen mucho por sí solos para abordar los tipos de problemas que enfrenta el equipo que apoya y gestiona la aplicación y su infraestructura, lo que en este artículo se denomina «operaciones». Las herramientas para este grupo necesitan construir un puente entre las operaciones y el desarrollo, fomentando la comunicación y el entendimiento entre los equipos y promoviendo una cultura de desarrollo.
El juego de herramientas rotas del cliente
Cuando entré a este cliente, toda su herramienta de aplicación se basaba en una técnica conocida como andamiaje. Este es un enfoque común en los sitios ASP.NET MVC construidos alrededor de Entity Framework. ¿Recuerda los metadatos que se usan para determinar cómo se almacena el modelo? Bueno, resulta que puedes usar esos metadatos para otras cosas también, como la generación de interfaces de usuario. En este caso, el andamiaje define un conjunto de manejadores en el sitio web que permiten la ejecución de operaciones CRUD en un modelo. Es decir, se obtienen páginas específicas diseñadas para crear, leer, actualizar y borrar un tipo específico de entidad. Como esta operación de andamiaje está incorporada en las plantillas ASP.NET MVC para Visual Studio, el desarrollador obtiene estas páginas esencialmente de forma gratuita.
La imagen de abajo muestra el andamiaje UI utilizado para crear un nuevo «Usuario». Este «Usuario» podría representar a un único usuario para un sitio web o servicio. El modelo de Usuario contiene algunas propiedades como su nombre, correo electrónico y estado, y la UI generada proporciona una forma sencilla de configurar cada una de estas propiedades utilizando controles bien conocidos.
El conjunto de herramientas de PowerShell
Cuando dejé este proyecto, el cliente tenía un nuevo conjunto de herramientas basado completamente en PowerShell. El conjunto de herramientas utiliza el proyecto de código abierto EntityShell para habilitar las operaciones CRUD en las entidades de mi cliente desde el shell de la línea de comandos. Entonces, ¿recuerda los metadatos del modelo que se usan para determinar cómo se almacena el modelo y para el andamiaje de la interfaz de usuario? EntityShell usa estos metadatos para implementar lo que se conoce como un Proveedor de PowerShell. Este proveedor le permite navegar por los modelos almacenados por Entity Framework como si fueran archivos en una «unidad de entidad». Este ejemplo muestra comandos comunes del sistema de archivos, como cd y dir, que se usan para navegar y buscar en una unidad de Entidades que contiene nuestros modelos de Usuario:
Viabilidad del conjunto de herramientas para las operaciones
Desde la perspectiva del desarrollador, ambos conjuntos de herramientas proporcionan una solución sin esfuerzo que facilita los flujos de trabajo del CRUD en las entidades. Sin embargo, para el ingeniero de operaciones, las herramientas de la interfaz de usuario representan un conjunto de herramientas mínimamente viable para los problemas que necesitan resolver, mientras que las herramientas de PowerShell se adaptan a sus necesidades siempre cambiantes. Además, al compartir el conjunto de entidades subyacentes entre las operaciones y el desarrollo, el conjunto de herramientas de PowerShell fomenta un mayor nivel de comunicación entre los equipos.
Veamos cómo se utilizarían estos dos conjuntos de herramientas para resolver algunos problemas comunes de gestión de entidades.
Caso 1: «Tenemos una feria mañana, Jake de ventas dice que necesita 100 usuarios de demostración listos para salir. Y darles todos los correos electrónicos de $0027[correo electrónico protegido]$0027 para que podamos encontrarlos más tarde.»
El aspecto principal de este escenario es el número de usuarios que deben crearse. La creación de un usuario utilizando la interfaz de usuario es un proceso manual:
- Haz clic en el enlace «Crear nuevo»
- Escriba el nombre del usuario
- Escriba la dirección de correo electrónico del usuario
- Establecer el estado activo del usuario
- Haga clic en el botón «Crear»
Al tener que repetir este proceso manual es donde la herramienta pierde todo su valor. Acabamos de crear un usuario, y necesitamos 99 más. Con el GUI, nuestra única opción es repetir el proceso manual de cinco pasos hasta que se creen las 100 cuentas de prueba. Aquí es donde el ingeniero comienza a desgarrarse.
Ahora considera el conjunto de herramientas de PowerShell. Crear 100 usuarios es simplemente cuestión de usar el cmdlet estándar de PowerShell de nuevo elemento en nuestra unidad de Entidades y especificar los valores de propiedad para el nuevo usuario:
0..99 | foreach { new-item -path entities:/users -username «User$_» -useremail «[email protected]» -isActive $true }
Este guión dice: por cada número del 0 al 99, crear un nuevo usuario con un nombre que incluya el número actual, la cuenta de correo electrónico [correo electrónico protegido], y asegurarse de que este usuario esté activo.
Así que una línea de PowerShell o 100 iteraciones manuales de un proceso de 5 pasos, el resultado final es el mismo. Esta comparación pone de relieve el primer requisito clave de las herramientas operativas: deben ser repetibles y automatizables. Las herramientas GUI no pueden cumplir muy bien con este requisito – tienden a asumir una presencia humana para cada operación individual.
Caso 2: «Ok, la feria de muestras ha terminado. Ahora deshabilita a esos 100 usuarios que creamos, no queremos que usen el producto gratis nunca más.»
Estamos viendo otra operación a granel aquí, pero el primer paso es aislar los 100 usuarios en los que tenemos que operar. Usando nuestro juego de herramientas GUI de barebones, nuestra única opción es una inspección visual de la dirección de correo electrónico del objetivo que nuestro jefe nos pidió que usáramos:
Una vez que encontremos un usuario objetivo, necesitamos editar el estado activo de la entidad por:
- Haciendo clic en el enlace de edición del usuario objetivo;
- Desmarcando la casilla de verificación IsActive en la página de edición del usuario;
- Haciendo clic en el botón «Guardar» para confirmar nuestros cambios para este usuario.
Uno menos. Faltan 99. Ahora el ingeniero solloza, de vez en cuando echando una mirada de anhelo hacia una foto de su familia que no ha visto en días.
La herramienta PowerShell realiza un flujo de trabajo similar: primero el ingeniero debe aislar a los usuarios objetivo, luego editar su estado activo, y finalmente confirmar esos cambios. La diferencia es cómo encontramos y editamos nuestros usuarios objetivo:
$usuarios = dir entidades:/usuarios | donde Email -eq $0027[email protegido]$0027
Así es, no hay búsqueda visual. Sólo le decimos a la herramienta lo que necesitamos: todos los usuarios con una dirección de correo electrónico específica. La herramienta hace el trabajo, el ingeniero toma café. Una vez que tenemos nuestros objetivos aislados en la variable $usuarios, los editamos a granel y terminamos con ello:
$usuarios | elemento fijo -isactivo $falso
Este segundo caso muestra cómo las herramientas de desarrollo automatizan los componentes de un flujo de trabajo en lugar de todo el flujo de trabajo en masa. Considere cómo nuestra GUI nos obliga a completar un camino para cada usuario que necesitamos cambiar: encontrar el usuario, editar ese usuario, y confirmar el cambio. Todo ese camino debe ser repetido para que la herramienta resuelva nuestro problema.
La herramienta PowerShell ofrece un enfoque mucho más eficiente: encontrar primero a todos los usuarios objetivo, luego editarlos todos de la misma manera, y comprometer todo el conjunto de cambios en masa.
Caso 3: «Oye, ventas envió este archivo CSV con datos de 1000 cuentas de usuario pagadas de esa feria. Mételos en el sistema ASAP.
Nombre,Email
«Fakey von Fakerschmidt»,»[correo electrónico protegido]»
«I. M. Knotwreal»,»[correo electrónico protegido]»
…
El aspecto notable de este caso es la fuente de la entrada – nuestro ingeniero está recibiendo un archivo de datos estructurado. Desafortunadamente nuestra herramienta GUI no tiene la capacidad de procesarlo. Ahora nuestro ya frenético ingeniero debe o bien pedir nuevas herramientas – que dado el requisito de ASAP impuesto por el jefe no llegará a tiempo – o debe morder la bala e introducir cada registro del CSV en la herramienta GUI a mano. Oh, Dios, mírala, ahora está murmurando para sí misma y balanceándose de un lado a otro. No estoy seguro de que vaya a seguir por aquí mucho más tiempo.
Si tan sólo tuviera las herramientas de PowerShell, sería muy fácil. A PowerShell no le importa de dónde viene la entrada. Simplemente quiere ayudar a hacer el trabajo. Está feliz de leer los registros de archivos CSV como objetos estructurados usando el cmdlet importado CSV, preparándolos para que el cmdlet de nuevo elemento los consuma:
import-csv salesdata.csv | foreach { new-item -path entities:/users -username $_.name -useremail $_.email -isActive $true }
Este es quizás el aspecto más importante de una herramienta de desarrollo: fomentar la agilidad en los esfuerzos del ingeniero. Los caminos estrictos son buenos para mantener a los usuarios finales en el camino feliz, pero las operaciones necesitan flexibilidad. Sus herramientas deben permitirles pensar de forma creativa, combinar conceptos y adaptarse rápidamente para resolver el problema en cuestión.
Caso 4: «Aquí hay otro archivo de marketing con algunas cuentas de usuario más que queremos en el sistema. Creo que Erin los puso la última vez, pero salió corriendo de aquí gritando esta mañana, agitando los brazos y …. Sí, así que ya no trabaja aquí».
Este caso es interesante por dos razones: al ingeniero se le pide que realice una tarea que alguien hizo en el pasado, y ese alguien ya no está. Pobre Erin. Espero que esté bien.
La cosa es que con el conjunto de herramientas GUI no hay forma de que Erin haya podido capturar su solución. Cada problema que Erin llevó a la GUI fue un evento aislado, la solución se perdió tan pronto como fue creada, no dejando ninguna manera de registrar la actividad para que alguien pueda aprender de ella o reproducirla más tarde. Como no puedes guardar y compartir un clic del ratón, estás condenado a repetirlos.
No es así con las herramientas de PowerShell. Una operación de PowerShell se expresa como texto, y el texto puede ser fácilmente capturado, compartido y reutilizado en forma de archivos de escritura. Erin podría haber documentado implícitamente la operación como un guión, y luego compartirlo con el nuevo ingeniero para que aprendiera de su duro trabajo. Entonces Erin podría haberse ido de vacaciones a ver la escena musical de Portland y tener una vida maravillosa y productiva.
Manteniendo la perspectiva de las operaciones como un desarrollador
La regla de oro de hacer un buen software es esta: conoce a tu usuario. Cuando tu usuario trabaja en operaciones, su objetivo principal es mantener la aplicación funcionando. Crear herramientas para hacerlo fácil para ellos no tiene que ser difícil:
- Hacerlo automatizable;
- Hazlo componible;
- Debe fomentar la agilidad;
- Debería promover la captura, el intercambio y la reutilización.
Sólo recuerde centrarse en estos aspectos de su herramienta de aplicación.