{ campo1: valor1, campo2: valor2, .... .... campoN: valorN }
{ Nombre: "Ana", Apellido: "Barquero", Direccion: "Santa Cruz de la Sierra" }
{ NombreArticulo: "Bocinas BOSE", PrecioUSD: 102.99 }
{ NumeroFactura: "ABC12", Cliente: "Ana" }
{ campo1: valor1, campo2: valor2, .... .... campoN: valorN }
{ Nombre: "Ana", Apellido: "Barquero", Direccion: "Santa Cruz de la Sierra" }
{ NombreArticulo: "Bocinas BOSE", PrecioUSD: 102.99 }
{ NumeroFactura: "ABC12", Cliente: "Ana" }
Desarrollando un aplicativo móvil que interactúa remotamente con algunas máquinas ejecutando Windows, me vi en la necesidad de buscar un comando PowerShell para obtener los servicios de las máquinas Windows que se encuentran detenidas. En este post vamos a ver como llevar a cabo esta tarea en PowerShell y como exportarlo a un archivo CSV.
El CmdLet para obtener los servicios de Windows se sumamente sencilla (como casi todo en PowerShell ). Ejecutando el comando get-service vamos a obtener la lista completa de servicios del sistema operativo, tal y como se ve en la siguiente pantalla.
Ahora, para obtener los servicios que están detenidos, modificamos los parámetros del CmdLet de la siguiente forma:
En este caso utilizamos el filtro where-object el cual me permite filtrar los objetos que se pasan antes del “pipe” con el criterio a la derecha del filtro.
Ahora bien, si queremos persistir la respuesta del comando escrito anteriormente debemos modificar el comando para que exporte los resultados a un archivo CSV – tal y como lo definimos a la hora de iniciar el post. El comando modificado se puede ver en la siguiente figura.
En este caso, utilizamos el el comando Export-CSV y le indicamos donde queremos el resultado. El archivo con el resultado de la ejecución del comando resulta un poco difícil de leer tal y como se ve en la siguiente figura.
Para hacerlo más legible, vamos a seleccionar las columnas que nos interesan del resultado para lo cual ejecutamos el mismo comando pero con las columnas deseadas como parámetro del comando, utilizando el CmdLet Select-Object.
El resultado lo podemos ver en la siguiente figura.
Cuando se escriben historias de usuario se deben de incluir los criterios de aceptación de estas historias de usuario. En estos criterios de aceptación debe de ir una descripción detallada de lo que se espera que hagan las características esperadas en la historia de usuario. Sin embargo; es muy común que en estos criterios de aceptación olvidemos agregar lo relacionado con seguridad y con validaciones (conceptos totalmente diferentes). Aunque no todas las historias de usuario van a tener necesariamente consideraciones de seguridad o validación, se debe considerar el tema cada vez que se están escribiendo para que el desarrollador las tome en cuenta a la hora de implementar la historia. La siguiente es una lista de categorías que se pueden tomar en cuenta a la hora de escribir las historias de usuario.
Es importante definir si alguna característica de las que se va a implementar en la historia de usuario debe de llevar encriptación. En este tema es importante no ponerse a inventar la rueda y utilizar algoritmos probados que ya existen y que cumplen con todas las medidas de seguridad requeridas por la empresa que usará el software. Igual de importante es utilizar librerías de empresas reconocidas para no poner en riesgo el ítem a desarrollador. También es importante definir cuales características deben de estar encriptadas y cuales no, porque como todo en el mundo de la informática tiene su penalidad, y a mayor seguridad menor desempeño – hay que encriptar, transportar y desencriptar para poder hacer que la transacción trabaje correctamente.
Es importante verificar si los datos que ingresan – por pantalla, a través de un servicio, etc. – estén correctos ya que esto atenta no solo contra la estabilidad del sistema sino también contra la seguridad del mismo ( a través de ataques de SQL Injection o en sitios web usando cross site scripting ). Debemos establecer que datos se deben validar en la historia de usuario.
La funcionalidad a desarrollar debe de tener de forma explícita si requiere de autenticación y/o autorización; y si requiere autorización cuales grupos funcionales deberían tener acceso a la característica. Esto evita que los desarrolladores desarrollen servicios, componentes, y componentes de UI totalmente abiertos esperando que alguna otra persona los asegure, poniendo en riesgo la seguridad del ítem a desarrollar y por ende, el sistema completo.
Escribiendo un post acerca de como acceder el Visual Studio Online me topé con este error en Windows 10.
No se puede ejecutar el script “ps1” porque la ejecución de scripts está deshabilitada en este sistema.
Buscando un poco me di cuenta que por política la ejecución de comandos está permitida pero la ejecución de scripts no. Para validar el estado en que se encuentra nuestro sistema, vamos a la consola de PowerShell y ejecutamos el siguiente comando:
Como se ve en la imagen anterior, tenemos la política de ejecución restringida. Para cambiar esto, simplemente ejecutamos el siguiente comando y cuando nos pregunte por la ejecución del cambio digitamos S.
Con esto ya podemos ejecutar el script de PowerShell. Para verificar que si tenemos permisos ejecutamos el comando Get-ExecutionPolicy y nos aseguramos que el resultado sea Unrestricted.
En muchas situaciones me preguntan cual framework es el mejor para x tarea, o cual framework utilizo yo para desarrollar una aplicación. Algunas veces son mas puntuales y preguntan cosas como utilizas el Entity Framework? Usas Sencha para las apps o Apache Cordova? Estas preguntas van acompañadas siempre con el “en que te basas para escoger un framework” donde quizás la pregunta es mas orientada al tipo de preguntas que un arquitecto de software tiene que hacerse y ayudar a responder a los equipos de desarrollo con los cuales trabaja.
Personalmente utilizo algunos frameworks para desarrollar aplicaciones tales como Dapper de stackoverflow; sin embargo, normalmente trato de utilizar la tecnología recomendada por el vendedor para desarrollar aplicaciones en su plataforma. Aquí es cuando los desarrolladores “levantan” la mano y dicen pero porque o usas x o y framework si al final te ayuda a terminar tus aplicaciones de forma más rápida? La respuesta es sencilla: Yo hago aplicaciones para usuarios y no para desarrolladores y no puedo sacrificar al usuario final para beneficiar al desarrollador.
Enfoque desde el punto de vista de un arquitecto: Es bueno terminar en tiempo y en forma los proyectos en los cuales trabajamos, pero no debo entregar aplicaciones con menos capacidades al usuario final por el simple hecho de utilizar un framework que permite que los desarrolladores escriban menos código; es decir, la aplicación debe tener el máximo desempeño que puede dar en la plataforma seleccionada en temas tales como velocidad de ejecución, interacción con repositorio de datos, consumo de energía – para dispositivos móviles, consumo de datos – para dispositivos móviles, manejo de transacciones, manejo de errores, manejo de esquemas de auditoria, seguridad e interacción con el usuario final. Este tema es relevante tanto para aplicaciones locales (on premises), aplicaciones móviles y aplicaciones que corren en la nube.
Configurando el ESB Toolkit para BizTalk Server se me presento un error a la hora de configurar el portal del bus de servicios. Luego de compilar y hacer el deployment correspondiente del portal me aparecía el error:
The remote server returned an error (400 Bad Request)
Como ven el error es poco descriptivo y si iba a al visor de eventos aparecía exactamente la misma información. Debugueando el portal en el Visual Studio pude ver que el problema era en la base de datos, desde donde verificando varias cosas pude llegar a la solución del problema. Inicialmente verificando las bases de datos que el toolkit crea me di cuenta que la base de datos EsbExceptionDb no tenia estructuras de tablas ni de procedimientos almacenados por lo que la configuración del ESB había fallado.
Antes de reconfigurar el ESB Toolkit, procedí a borrar todas las tablas que este había creado:
Seguidamente reconfigure el ESB toolkit y listo, las bases de datos se generaron correctamente.
Luego de esto, el portal me apareció pero con errores, ya que había modificado el manejo de excepciones para que me presentara las excepciones en los segmentos de la pagina correspondiente.
Seguidamente procedí a reinstalar el portal; sin embargo, aún aparecían errores en la ejecución del script donde se creaba la base de datos ESBAdmin. Verificando el script de creación y configuración que se ejecuta automáticamente me di cuenta que los grupos y usuarios de BizTalk Server a los que se les da acceso a la base de datos vienen “quemados” en ingles y yo estaba configurando el servidor en español, por lo que procedí a cambiarlos.
Luego de esto el portal apareció correctamente en el navegador, aunque claro, sin datos todavía.