Los anteriores espacios de nombres era para poder definir un usuario para conectarnos a nuestro server, También para definir nuestra bd y cual script ejecutar.
como hay un poco de dudas sobre las diferencias entre el sensor KINECT para Xbox360 y el nuevo sensor Kinect para PC. Voy a explicar un poco lo que sé al respecto para diferenciarlos.
En primer lugar las diferencias más significativas del nuevo sensor para PC
Near Mode. El nuevo sensor posee un nuevo firmware que permite trabajar identificando cuerpos a partir de los 40 cms, con un alcance máximo de 4 metros.
Cable USB más corto. Parece una tontería, pero el hecho de tener solo un conector USB y no el mega conector que posee ahora el sensor, se agradece bastante.
Ahora bien, la principal diferencia está en que el nuevo hardware/Sensor está específicamente diseñado para PC. Soporta todas las características del SDK que podemos utilizar con el actual sensor de Xbox, pero es SOLO CON ESTE DISPOSITIVO que tendrás soporte, actualizaciones, etc.
El sensor de XBOX NO ESTA SOPORTADO PARA ENTORNOS PC; el nuevo sensor si. Además, la capacidad de near mode, el nuevo soporte para speech, etc.; solo está disponible para el sensor para PC.
Finalmente, no está permitido ni soportado el desarrollo con el sensor para XBOX. Parece algo obvio, pero si pensamos que las pruebas se han realizado con otro SDK (el de XBOX), sobre otro entorno; es normal que este sensor no sea homologado para PC. En cambio el nuevo sensor, si está soportado para entornos PC, si posee garantía, actualizaciones, etc.
A ver si comienzo una serie de minoposts con datos del nuevo SDK. Eso, cuando Amazon, me ayude y me haga llegar el nuevo sensor
Como sabéis, y a groso modo, Office 365 cuenta con dos tipos generales de planes cuyo target depende bastante de las características y necesidades particulares de una empresa:
Office 365 para medianas y grandes empresas (hablamos de más de 50 posibles usuarios y de una mayor necesidad de los servicios incluidos en la plataforma y de sus capacidades).
Y antes de la llegada de Office 365, y de acuerdo a esta diferenciación, podemos decir que Microsoft tenía también dos offerings:
Por una parte Office Live Small Business, que sería equivalente a Office 365 para profesionales y pequeñas empresas.
Por otro, BPOS (Business Productivity Online Suite) que incluía las versiones previas de los servicios incluidos en Office 365.
Por supuesto, la idea es que usuarios que vengan de ambos tipos de escenarios acaben actualizándose a Office 365. En el caso de BPOS, es Microsoft (o la propia organización) quien realiza esa actualización…¿Y en el caso de Office Live Small Business? Pues el propio usuario y realizando un proceso de migración un tanto manual…básicamente se trata de adquirir Office 365 y mover toda la información de Office Live Small Business allí. Os dejo varias referencias al respecto:
Cuando nos encontramos con problemas de fugas de memoria en nuestro despliegue de SharePoint y sospechamos que se puede deber a un ensamblado de terceros, podemos ayudarnos de la herramienta SPDisposeCheck para verificar si dichas fugas de memoria se deben a que no se ha hecho el disposado correcto de objetos SPWeb y SPSite que se estén instanciando, comprobando así que se está liberando el uso de memoria que utilizan cuando entran en funcionamiento. SPDisposeCheck se integra en Visual Studio 2010 de forma que en tiempo de desarrollo podemos comprobar si estamos siguiendo las buenas prácticas en el disposado de objetos, pero también se puede ejecutar mediante línea de comandos y hacer dichas comprobaciones contra un ensamblado:
Finalmente, os dejo varias referencias relativas a SPDisposeCheck y a las reglas de disposado:
Normalmente, suelo tener algunas máquinas virtuales en las que me apoyo para los diferentes artículos que escribo aquí, o bien para las pruebas que requiera hacer, sea reproduciendo problemas, o tratando de entender comportamientos de Windows.
Las máquinas virtuales las administro desde VMware, y una de las características de éste gran Gestor, es que si se instala Windows utilizando el asistente, sea con los pasos básicos o avanzados, al darle el usuario que sea quiere crear, además de que no lo pregunta en la instalación (Lo hace de forma desatendida), es que Windows siempre hará autologon con el usuario.
*Nota: Pueden ver más a fondo los procesos de Autologon en Este artículo.
Lamentablemente, en una de las máquinas, tuve que eliminar una de las cuentas porque la dañé completamente; no tuve problema con este proceso, el problema empezó al empezar a reiniciar normalmente el equipo, ya que cada que entraba, obtenía un mensaje de error con respecto a una contraseña:
Al darle al botón Ok, mi sorpresa fue que Windows todavía estaba intentando ingresar con el usuario que yo había borrado (WinBoy):
Por supuesto, no podía iniciar de ninguna forma sesión con el usuario, por lo que siempre tenía que darle al botón de Cambiar de usuario, escribir manualmente alguno de los otros usuarios e iniciar sesión.
Lo primero que hice fue ir hasta la ventana de Administración de usuarios, pero la cuenta (Tal como debía ser), no aparecía por ningún lado:
Los archivos de usuario, a pesar de que yo pensé haberlos borrado también, seguían existiendo en el directorio de C:\Users, pero esta no debería ser razón para que iniciara, puesto que la cuenta no estaba creada.
¿Cuál era el problema entonces?
La causa
El problema estaba sucediendo antes de que se iniciara Windows, por lo menos el escritorio; sólo existe una herramienta capaz de darme un diagnóstico de lo que sucede antes, por supuesto, me refiero a Process Monitor de Sysinternals.
Process Monitor tiene una característica llamada ?Enable Boot Logging? que, permite ubicar el controlador de Process Monitor (PROCMON20.SYS) para que inicie antes que todo, por lo que generará un log que irá incrementandose hasta que se abra nuevamente dentro de Windows y se guarde.
Gracias a esto, podemos ver las Operaciones que suceden incluso desde el Winlogon, cosa que no es posible ni con el mismo sistema operativo.
Para habilitar la característica, basta con Abrir Process Monitor, e ir al menú Options y seleccionar ?Enable Boot Logging?:
Lo habilité, abrí Process Monitor para empezar a analizar el log, y empecé a buscar por la palabra clave que pudiera darme más ayuda, en este caso, por supuesto, el nombre de usuario: ?WinBoy?.
Después de algunos resultados que me decían que las claves del usuario en ProfileList todavía existían, encontré esto:
*Nota: Clic en la imagen para verla en tamaño real.
Windows estaba abriendo la clave Winlogon que contiene todas las claves y subclaves que hacen referencia a alguna operación en el proceso de inicio de sesión; a continuación estaba haciendo unas consultas a unos valores llamados DefaultUserName, DefaultDomainName y DefaultPassword. En el artículo acerca del Autologon, vimos un poco de lo que trataban estos valores, pero básicamente, junto con AutoAdminLogon, habilitan el Inicio automático (Autologon) y además establecen el nombre de usuario, dominio y contraseña que debe utilizarse.
DefaultUserName, en este caso estaba todavía haciendo referencia a la cuenta que estaba eliminada:
*Nota: ?Data? es el contenido que tendrá, en este caso ?WinBoy?.
Esta era la primera respuesta del por qué intentaba iniciar con una cuenta que ya no existía, al estarla referenciando, y todavía existir sus claves correspondientes, Windows aún la referenciaba.
DefaultDomanName no tenía valor, por lo que estaba tomando el Grupo de Trabajo predeterminado que tenía Windows.
Ahora, el valor de DefaultPassword, a diferencia de los anteriores, tenía como resultado NAME NOT FOUND, esto quiere decir que, a pesar de tener el Autologon indicado, Windows no encontraba la contraseña por ninguna parte; esto nos da la respuesta del por qué el primer mensaje de que el nombre de usuario o contraseña eran incorrectos.
La solución
Ya tenía detectado el problema, la solución consistía en evitar que Windows suigiera intentando hacer el Autologon, para esto entonces, desde Process Monitor utilicé la característica de ?Jump to? para ir directamente a la clave de Registro de Winlogon y ubicar los valores que estaban causando el problema:
Lo que hice fue primero, modificar el contenido de AutoAdminLogon para cambiarlo de ?1? a ?0? y que se desactivara, y posteriormente eliminé el valor de DefaultUserName para que no tuviera nada que buscar ahí =)
Al reiniciar el equipo, el agradable resultado fue:
El inicio de sesión común en Windows había retornado a su normalidad.
después de las 12 horas de Visual Studio del pasado martes, me agarro un virus que casi me mata. Pero de a poco voy a sacar los pendientes, empezamos por algunos correos.
Buenas, estuve el otro día viendo con mis compañeros de trabajo las 12 horas de Visual Studio, y a parte de parecernos muy interesantes los temas que enseñasteis, nos quedamos con la duda de como hacer un "truco" que nos pareció bastante útil en el día a día... como convertir un string del tipo "hola " + <variable> + " que tal" en string.Format("hola {0} que tal",<variable>) automáticamente. Te vimos hacerlo en la charla, pero no sabemos como, jeje.
Pues bien, eso que queda tan bien en vivo y además mucho mejor en el código se debemos agradecer a ReSharper. Para muestra un ejemplo, tengo una aplicación de Consola con el siguiente código:
1:using System;
2:namespace ConsoleApplication2
3: {
4:class Program
5: {
6:staticvoid Main(string[] args)
7: {
8:conststring Name = @"Valentino";
9: var msg = "Hola mi nombre es " + Name;
10: Console.WriteLine(msg);
11: }
12: }
13: }
Si nos posicionamos sobre la línea 9, veremos que ReSharper nos ofrece la posibilidad de utilizar format string para la concatenación de cadenas.
Una vez seleccionada esta opción, ya no tenemos más una suma de strings
1:using System;
2:namespace ConsoleApplication2
3: {
4:class Program
5: {
6:staticvoid Main(string[] args)
7: {
8:conststring Name = @"Valentino";
9: var msg = string.Format("Hola mi nombre es {0}", Name);
10: Console.WriteLine(msg);
11: }
12: }
13: }
Pero esto no es todo, la segunda opción que nos ofrece ReSharper también es interesante, “Compute constant value”. En la misma R# identifica que estamos trabajando con una constante y nos ofrece la posibilidad de utilizar el valor de la misma en lugar de trabajar con una cadena. El resultado final sería el siguiente:
1:using System;
2:namespace ConsoleApplication2
3: {
4:class Program
5: {
6:staticvoid Main(string[] args)
7: {
8:conststring Name = @"Valentino";
9: var msg = "Hola mi nombre es Valentino";
10: Console.WriteLine(msg);
11: }
12: }
13: }
Obviamente, si cambiamos el valor de la constante estamos más frito que los Chicago Bulls sin Derrick Rose, pero ese tema para otro post.
El Dia Jueves 26 de Enero tuve el placer de compartir con los miembros del CUTMS aqui en Cochabamba, una charla acerca de las ventajas de usar paralelismo con ASP.NET MVC.
Aqui les dejo algunas fotografias:
Aqui pueden descargarse el codigo de demostracion que utilice en esa presentacion:
Cuando empiezas a trabajar con Office 365, seguramente te encontrarás con un problema a la hora de intentar abrir un documento Office, que te has descargado desde el Exchange Online, o el sitio de grupo. El error tiene esta pinta:
La solución es muy sencilla, basta con editar las propiedades del fichero descargado, y pinchar sobre ?Desbloquear?:
Este no iba a ser el artículo que iba a poner de primero, pero resultó y es para mí, de lo más interesante porque personalmente, aprendí y eso le da un buen sentido.
El problema
Estoy tratando de conocer y comprender, hasta donde sea capaz mi conocimiento, un poco más a fondo el funcionamiento de la Asociación de archivos en Windows (En esta semana pondré el artículo completo refiriendome al tema).
Una de las formas más sencillas de aprender sobre Windows, es dañando y tratando de arreglar, por lo que modifiqué para reproducir el problema común de la perdida de asociación a los accesos directos, lo que causa que todo se abra con un solo programa:
A continuación, estaba tratando de utilizar PowerShell, para hacer uso de un cmdlet para eliminar la subclave de registro que causa este problema, es decir:
Como PowerShell trabaja las claves de registro de la misma forma que lo hace con los archivos, bastaba con hacer referencia a una pequeña línea de comandos utilizando Remove-Item, así:
El problema, es que cada que ejecutaba la línea anterior, recibía un mensaje un poco extraño de PowerShell:
Según el mensaje que PowerShell me daba, Remove-Item no podía eliminar la subclave de Registro porque no existía, aunque efectivamente la clave estaba:
Aunque PowerShell estaba reconociendo la excepción, no necesariamente estaba entregando el mensaje que correspondía, ¿Cuál era el problema entonces si la clave existía?
La causa
Como PowerShell no era capaz de indicar qué era lo que realmente le pasaba, había que pasar a preguntarle directamente a Windows, y para hacer esto, como siempre, nada mejor que Process Monitor de Windows Sysinternals.
Después de correr Process Monitor e intentar ejecutar la línea de comandos, bastó con volver a Procmon, parar el monitoreo y buscar directamente por la subclave UserChoice, como se recomienda, de abajo hacia arriba; esto fue lo que encontré:
*Nota: Clic para ver la imagen en tamaño completo.
El proceso powershell.exe estaba tratando de abrir la clave de UserChoice, pero como ven, el resultado era ACCESS DENIED, lo que llevaba a la respuesta, el problema estaba en permisos, ¡No en ausencia de la clave!
Process Monitor permite saltar directamente a la clave, así que lo hice, y después de esto entré a la ventana de Permisos de la clave haciendo clic derecho, Permisos, y en primera instancia, todo estaba bien para los usuarios de los grupos Administradores; el único y más importante problema, es que el usuario con el que había iniciado sesión, y con el que estaba tratando de eliminar la clave, tenía un permiso especial que me estaba denegando algo:
*Nota: Los Permisos Especiales en Windows contienen un filtro mucho más completo de denegación o aprobación en las operaciones que se pueden hacer a nivel de sistema de archivos, o bien sobre claves y valores del Registro de Windows.
Para poder ver los permisos especiales, basta con hacer clic en el botón inferior de Avanzado (No visto en la captura anterior), detecté el usuario que tenía los permisos especiales denegados e hice clic en el botón Editar para verlos:
Mi usuario tenía en blanco todo lo que fuera permitir, eso quiere decir que los tomaría de los permisos predeterminados, pero tenía como Denegado el permiso a establecer valores (Set Value), lo que equivale a escribir:
La solución
Con el problema detectado, ya la solución sería un poco más sencilla, al saber que tenía problemas de permisos, específicante de escritura, PowerShell no iba a ser capaz de eliminar la clave (No podía escribir nada encima); así que para no modificar mucho los permisos, símplemente cambié el de Denegar para Establecer Valor (Set Value) a Permitir (Allow):
Finalmente, volví a ejecutar la línea de comandos en PowerShell y este fue el resultado:
¡Todo blanco! Lo que indica que se había ejecutado correctamente, y además la clave se elimino en efecto sin ningun problema:
El pequeño Bug sobre los mensajes de información en las excepciones de PowerShell ya llegó al Equipo de PowerShell para mejorarlo en futuras actualizaciones.
Noticias externas 
