Introducción a la administración de sistemas con Windows PowerShell

powershell-logoPara los administradores de sistemas más avanzados, uno de los puntos débiles de Windows frente a otros sistemas operativos ha sido tradicionalmente  la capacidad de administración de éste desde línea de comandos.

Windows siempre ha sido un sistema operativo muy fácil de administrar visualmente. En general todos los productos de Microsoft lo son, y esta ha sido siempre una de las principales causas de su preponderancia como sistema operativo. Sin embargo esta facilidad de uso, basada en consolas gráficas y asistentes, ha sido tradicionalmente un arma de doble filo y fuente de controversias. Por un lado la sencillez con la que se realiza cualquier tarea hace que ciertas personas ganen excesiva confianza. En muchas ocasiones esta sencillez se convierte en un grave problema que lleva a que los sistemas estén mal administrados, debido a que no se ha profundizado bien en los conceptos necesarios para una buena gestión (la sencillez de un asistente no alienta tampoco el meterse en grandes honduras). Por otra parte ha sido también un problema porque esas mismas interfaces gráficas que tanto facilitan el trabajo más común, se convierten en un estorbo a la hora de realizar tareas complejas (formadas por otras tareas individuales más simples) que precisen de cierto grado de automatización.

La consola del sistema tradicional (cmd) nunca ha sido especialmente generosa en características, y desde luego está a años luz de los “shell” de UNIX en los que se inspira. Los clásicos archivos .bat son muy limitados y es un dolor realizar con ellos cualquier interacción avanzada con el usuario.

Hace ya bastantes años Microsoft incorporó a sus sistemas operativos un subsistema de automatización llamado Windows ScriptingHost (WSH) que trataba de acortar distancias con la administración de otros entornos. WSH se basa en la escritura de código en lenguajes de script, y soporta multitud de ellos (JavaScript, VBScript, Perl, Python, TCL, Ruby, PHP… hasta COBOL!). Estos scripts permiten crear tareas mucho más complejas que con un simple .bat, además de brindar acceso a la funcionalidad de cualquier objeto COM automatizable, incluyendo por ejemplo acceso a datos, a la red o a servicios web, y las funcionalidades de diversas aplicaciones con interfaz automatizable (como las de Office entre muchas otras).

Realmente WSH supuso una gran mejora sobre lo existente hasta entonces (la línea de comandos de MS-DOS) pero también presentaba un importante problema y es que, al fin y al cabo, los administradores no tienen porque ser también programadores. Si bien es cierto que VBScript o JScript son lenguajes sencillos cuyos rudimentos se aprenden rápido, para hacer uso de las funcionalidades de administración que necesitamos es necesario asimilar el uso de objetos COM que no son nada sencillos en general. Por ejemplo WMI (Windows Management Instrumentation) o ADSI (para acceso al directorio activo).

Esta es una grave limitación puesto que para sacarle partido a WSH hay que saber programar a un cierto nivel, aparte de ser difícil de depurar y requerir mucha ceremonia (en forma de archivos XML) para combinar entre sí la funcionalidad de diversos archivos WSH.

SIGUE LEYENDO PARA APRENDER: 

  • El origen de PoowerShell – Monad
  • Cómo usarlo
  • Cómo concatenar comandos
  • Cómo crear funciones propias
  • Cómo exportar resultados a Excel
  • Cómo filtrar y ordenar resultados
  • Más comandos
  • Referencias varias

TRUCO: Búsqueda rápida de archivos en Visual Studio

Este es un truco que, sorprendentemente, muchos programadores que usan Visual Studio a diario desconocen. Se trata de la posibilidad de buscar a toda velocidad cualquier elemento de nuestro código, incluyendo archivos, variables, funciones, clases…

La funcionalidad se denomina "Navigate to", y en las últimas versiones de Visual Studio se ha mejorado mucho, incluyendo VS2013.

La velocidad de búsqueda es enorme, y además realiza vista previa y ofrece opciones avanzadas para localizar cualquier cosa. No es lo mismo, pero se parece mucho a la opción "Goto Anything" de Sublime Text.

SIGUE LEYENDO

Uso selectivo de dependencias en módulos con RequireJS

CambioLa configuración de RequireJS ofrece muchas posibilidades para hacer gran cantidad de cosas útiles. La semana pasada, por ejemplo, os contaba cómo forzar la descarga de todos los scripts/módulos de una página inhabilitando la caché gracias a un parámetro añadido automáticamente a todas las peticiones.

En esta ocasión me voy a fijar en otro parámetro interesante llamado map.

La función de este parámetro es "mapear" ciertos módulos de manera especial cuando sean dependencias de otros módulos.

Por ejemplo, imagínate que tienes que usar dos versiones del mismo módulo (digamos jQuery), pero quieres usar una en particular para un determinado módulo que depende de ella, y la otra para otro módulo diferente.

Supongamos que tenemos una estructura de archivos como esta:

- modulo1.js
- modulo2.js
- libs/
    - jquery1.11.2.js
    - jquery2.1.3.js

Es decir, dos módulos en la raíz de la carpeta de scripts, y una subcarpeta "libs" con las dos versiones de jQuery. Imaginemos ahora que el módulo número 1 necesita soportar navegadores antiguos, así que requerimos en éste el uso de la versión 1.x de jQuery (la 2.x no soporta versiones antiguas de los navegadores, y en especial de Internet Explorer), mientras que el resto de la aplicación usará jQuery 2.x.

O sea, modulo1.js requiere jQuery 1.11.2, y cualquier otro módulo de la aplicación requiere jQuery 2.1.3.

Podemos indicar este caso mediante la siguiente configuración de RequireJS:

… SEGUIR LEYENDO en JASoft.org …