Automatización

Es ético automatizar tareas y no avisar?

He visto esta artículo en inglés y la discusión está buenísima, en especial para los que sabemos programar y lo usamos en nuestro trabajo. Si automatizamos nuestras tareas, qué es lo correcto: decirle a nuestros empleadores o hacer el trabajo al ritmo que ellos esperan? La discusión está servida. A continuación una breve reseña del contenido. Disfrútenlo y que se abra la discusión.

Nota original (en inglés)

NOTA: Esta nota no es una traducción/intepretación, es más bien una reseña con base en la nota publicada en Bussinessinsider.

El artículo original básicamente resume una discusión que comenzó en Stack Overflow, un popular sitio para compartir conocimiento técnico. Un programador anónimo publicó que se estaba sintiendo culpable porque había automatizado su trabajo hasta el punto de trabajar prácticamente dos horas a la semana. A este punto de la lectura algunas personas toman una posición: o bien el sr no es ético o bien es sólo otra forma de hacer un trabajo por el cual la empresa tiene una previsión de qué está invirtiendo. Quien publica la consulta dice más: no sólo ha terminado en el nivel de automatización comentado, sino que lo ha ocultado a su empleador y le mete pequeños errores a los resultados para que parezcan más humanos.

De las dos posiciones obvias hay argumentos a favor y encontra, por lo que la decisión sobre de cuál lado estar no es fácil. Uno de los usuarios que comentan, argumenta en contra con estos puntos de vista:

  • Recibe una paga de 40 horas por una tarea de 2
  • Ha trabajado de esa manera durante 6 meses
  • Cada semana aprox. debe mentir sobre su trabajo
  • Deliveradamente insertó errores
  • Hace que un analista siga gastando tiempo en verificación de un supuesto trabajo humano
  • El usuario admite que no se siente bien

De la otra orilla, otro grupo de personas argumentan lo siguiente:

  • Es una relación transaccional, por ende la empresa está recibiendo lo que espera y al precio que tiene decidido pagar. La industria está llena de ejemplos en los cuales si la empresa encuentra una solución más económica que un trabajador lo echa sin ningún remordimiento.
  • Un Sysadmin usualmente debe automatizar su trabajo y lo único que hace es supervisar que nada se salga de control.
  • Lo que el usuario debería hacer es no ocultarlo y, sin importar qué pase con el actual trabajo, buscar avanzar en ese campo, probablemente esté desperdiciando su talento y se sienta mejor en otro empleo.

Me pareció muy interesante esta discusión, porque yo intento automatizar todo tanto como puedo. No logro trabajar sólo dos horas a la semana, pero sí logro disminuir mucho mi carga y trabajar muy tranquilo. A veces lo digo otras veces no 🙂 Cómo lo hacen uds., qué opinan al respecto?

Cisco lanza nuevas certificaciones "críticas"

A principios de Abril (de 2017) leí esta nota publicada en la red CRN, que me parece muy relevante para el público de éste blog, especialmente para los canales de venta de Cisco o Learning Partners o quienes quieran pertenecer a alguno de estos canales, ya que describe nuevas líneas de certificaciones de especialista sobre programabilidad de red a diferentes niveles. A continuación les ofrezco una interpretación/traducción. Sientanse libres de comentar con sus discusiones o preguntas. Disfrútenla.

Panorámica de la automatización en redes fijas

Durante los últimos años he aprendido que cuando se trabaja con redes que tienen miles de dispositivos es prácticamente imposible hacer las cosas manualmente (incluso con unos pocos cientos). Hay muchas tecnologías que se combinan para ayudarnos con esos trabajos y en ésta entrada deseo hacer una panorámica desde mi experiencia de lo que he visto y usado, un poco trazando lo que va a ser una serie de escritos al respecto. Recuerden: es la perspectiva del ingeniero, para los administrativos la automatización significa que la implementación se pueda hacer desde los requerimientos mismos. Eso es SDN (Software-defined Networks) y es un tema mucho más complejo. Por lo pronto disfruten ésta lectura.

Automatización en redes

De unos años para acá, cuando empecé a trabajar en campo (es decir, fuera de un aula) diseñando e implementando soluciones de comunicaciones fijas, me topé con la necesidad de automatizar la creación de scripts y recolección de información. Luego me he venido a dar cuenta de lo importantes que son las herramientas de virtualización en nuestro trabajo y me he acercado un poco a su relación con el famoso término SDN (software-defined networking). Hoy, para retomar la buena costumbre de escribir, quiero comenzar una serie sobre las soluciones que he explorado con mis problemas diarios, como recolectar información sobre en una cantidad enorme de dispositivos, crear scripts con base en una tabla de información de diseño o probar soluciones antes de su despliegue en emuladores locales. Para ello voy a crear una nueva categoría de automatización y tal vez haga entradas concentradoras del tema como ya lo he hecho en los casos de ACLs y Packet Tracer entre otros (buscar el tag tutoriales). Espero que les sea útil, lo disfruten y estén pendientes.

La primera entrada en ésta categoría ya la escribí hace como un año: Word: combinación de correspondencia o mail merge para crear scripts con base en un excel, esta es una característica poco usada pero muy útil que con un poco de creatividad se convierte en una aliada para automatización de tareas en nuestro trabajo. Leanla y estén pendientes. La próxima semana ofreceré una panorámica de las necesidades y soluciones que he probado en mi experiencia. Disfrútenlo.

Automatización de scripts usando mail merge de Word 2007

Introducción

Antes de comenzar, quisiera recordarles que voy a volver a escribir más seguido, he tenido mi blog abandonado durante los últimos dos años pero ahora estoy en un nuevo empleo y tengo muchas experiencias que compartir, espero poder cumplir para volver al generoso Page Rank de 3 que solía tener y poder escribir como si tuviera (de nuevo) lectores habituales 🙂 Lo que voy a describir es útil para cualquier persona que haga textos repetitivos en los cuales sólo cambien algunas cosas, la técnica está diseñada para crear cartas en las cuales sólo cambien los nombres, géneros o alguna otra información pero el resto del contenido sea igual. El caso es especialmente importante para los ingenieros de redes y telecomunicaciones quienes usualmente configuramos o creamos guiones de configuración para desplegar un montón de dispositivos por un territorio cualquiera (o por todo el país). Como ingenieros de redes, casi que hablamos el lenguaje de línea de comandos de nuestra línea de producto, incluso algunas veces reemplazando expresiones o conceptos del lenguaje u obviamos las propias expresiones técnicas en favor de alguna palabra reservada de nuestro producto. Esto se debe a que estamos tan acostumbrados a aplicar configuraciones manualmente que olvidamos los propios conceptos o se nos hace más fácil hablar usando siglas o comandos. Por la misma razón, no solemos cuestionarnos cuando ejecutamos tareas repetitivas, especialmente cuando no son suficientemente grandes para preocuparnos, incluso podemos alardear de cuán rápidos somos para “tipear” comandos, sin embargo, cuando la tarea es realmente grande tenemos que buscar alguna alternativa más eficiente (por rápidos que seamos).