#5 Eso está muy bien en la teoría, la práctica es un poco más complicada. De todas formas, yo soy de currar menos, no más, y eso me ha llevado a un sin fin de problemas con mis jefes que siempre han dicho "prefiero a uno que curre, no de ruido y esté 8 horas mirando youtube, que a ti pensando en como currar menos"
Y bueno, así me ha ido. Gracias a la automatización de procesos me quedé sin nada que hacer, pero es que me aburre soberanamente hacer la misma mierda cada día. Eso sí, pasé de ser admin de unix machaca a hacer lo que ahora llaman DevOPS y SecOPS antes de que tuviera nombre.
Pero como yo soy de los de la vieja escuela, prefiero el python. Nota: nunca me he molestado en escribir el código en python porque los sistemas Unix rara vez necesitan entorno gráfico, es mejor dejar un top corriendo o algo así.
#6 me parece fenomenal. Yo hago los mismos pasos, de hecho en la empresa que estoy están empezando a implementar ansible para reducir el número de acciones monótonas, aunque curiosamente siempre hay alguien que mira las innovaciones con recelo.
A ver si hay suerte y me puedo especializar en esto. Un saludo
#15 lo que hice en esos días se puede ver como un proto-ansible. No llegaba a estar centralizado del todo, y desde luego, era más fácil hacer un push, que una regresión de versiones (casi era mejor tirar de snapshot). Pero como máquina de estados, era un sistema que a mi me funcionaba, ideal para despliegues automatizados de "golden images", con un número de acciones predeterminadas para reducir la intervención manual. El último paso (despliegue de aplicaciones) lo montaba con Jenkins y a cascarla, excepto con sistemas SAP, que siempre se despliegan a manija una vez que montas la base de datos.
Sí, tenía mucho curro preparandolo todo, pero luego, por la teoría del vago constructivo, ahorraba mucho tiempo.
#15 Por cierto, no tengas miedo de innovar, los que están por encima (o al lado) y ven un peligro en todo esto, es
1) Gente que no sabe hacer otra cosa (monjes copistas vs Güttemberg)
2) Gerentuchos de medio pelo que están ahí porque "lo que funciona" y "lo probado", si va bien, no se ha de tocar, no sea que tengan que explicar por qué la productividad por hora de trabajo aumenta y se puede dedicar el tiempo a otras cosas más interesantes.
#18 Los trabajos de IT rara vez tienen que ver con la tecnología. Y la parte de UX, es lo peor de lo peor del mundo mundial, por eso siempre he estado en backends.
*
Y bueno, así me ha ido. Gracias a la automatización de procesos me quedé sin nada que hacer, pero es que me aburre soberanamente hacer la misma mierda cada día. Eso sí, pasé de ser admin de unix machaca a hacer lo que ahora llaman DevOPS y SecOPS antes de que tuviera nombre.
*
Pero un auténtico vago escribirá en un powershell algo así:
Add-Type -AssemblyName System.Windows.Forms
while ($true)
{
$Pos = [System.Windows.Forms.Cursor]::Position
$x = ($pos.X % 500) + 1
$y = ($pos.Y % 500) + 1
[System.Windows.Forms.Cursor]::Position = New-Object System.Drawing.Point($x, $y)
Start-Sleep -Seconds 10
}
Pero como yo soy de los de la vieja escuela, prefiero el python. Nota: nunca me he molestado en escribir el código en python porque los sistemas Unix rara vez necesitan entorno gráfico, es mejor dejar un top corriendo o algo así.
*
A ver si hay suerte y me puedo especializar en esto. Un saludo
*
Sí, tenía mucho curro preparandolo todo, pero luego, por la teoría del vago constructivo, ahorraba mucho tiempo.
*
1) Gente que no sabe hacer otra cosa (monjes copistas vs Güttemberg)
2) Gerentuchos de medio pelo que están ahí porque "lo que funciona" y "lo probado", si va bien, no se ha de tocar, no sea que tengan que explicar por qué la productividad por hora de trabajo aumenta y se puede dedicar el tiempo a otras cosas más interesantes.
Pero me ha resultado curioso que gente de IT tenga tantas reticencias a cosas nuevas, como cuando a un usuario le cambias el color de un botón.