Buenas,

los amigos del Grupo de Usuarios .Net de Málaga, me han invitado el próximo 30 de Septiembre a que pasemos con ellos un buen rato hablando de Microsoft Robotics. El evento es el clásico y a ver si logramos que funcionen más del 50% de las demos (es lo que tiene trabajar con hardware)

Título:

Conquistando el mundo con Microsoft Robotics

Lugar y Hora:

Salón de actos Edificio BIC Euronova, PTA (Parque Técnológico de Andalucia, Campanillas)

Día 30 de Septiembre a las 18:00

Descripción:

La última versión de Microsoft Robotics Developer Studio por fin nos acerca un poco más al ansiado objetivo de la conquista global del mundo utilizando robots. En esta charla veremos cómo podemos aprovechar esta tecnología y comenzar a programar nuestros primeros robots. Además de programación concurrente, orientación a servicios, etc.; veremos una implantación real de esta tecnología en un escenario concreto; como perseguir a tu mascota utilizando LEGO Mindstorms & Microsoft Robotics Studio, controlar un lanzamisiles USB, y todo lo que entre en la maleta.

Duración:

120 mins.

Agenda:

• Introducción a Microsoft Robotics
• Microsoft Robotics Simulation Engine
• Microsoft Robotics Visual Programming Language
• Microsoft Robotics Runtime
• Otras opciones

Registro: https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032461365&Culture=es-ES

Evento: http://malagadnug.org/?p=21

Saludos @ Here

El Bruno (@elbruno en Twitter)

Microsoft ha publicado una nueva versión de su herramienta gratuita ILMerge. Se trata concretamente de la versión 2.10.0526.

La descarga ocupa unos 665 Kb y puede ser realizada desde este enlace.

Recordemos que esta utilidad permite mezclar varios ensamblados separados en un único ensamblado.

Esos ensamblados pueden ser ejecutables o librerías dll.

La herramienta se ejecuta bajo el paragüas de .NET Framework 2.0 y permite incluso combinar varios pdb en un único fichero pdb.

Aunque también es capaz de mezclar ensamblados de la versión 1.0 y 1.1, no es capaz en este caso de mezclar o combinar varios pdb en uno sólo.

Tanto en el mundo real como en digital en raras ocasiones podemos encontrar un escenario de negociación de más por más. Como ya sabemos es mucho más frecuente encontrarnos con un más por menos. Es habitual tener que negociar hasta llegar a un equilibrio entre las partes que componen un sistema. Las ecuaciones que gobiernan el universo del desarrollo de software se componen de variantes como rendimiento, coste de desarrollo, coste de mantenimiento, escalabilidad...que deberemos equilibrar para llevar al proyecto a buen puerto.

La distribución es uno de esas variantes. De echo es una de las más representativas. Desde el primer momento debemos tener en cuenta que distribuir objetos no es gratuito. Esta característica es atractiva por poderosa pero conlleva un alto impacto en el coste de desarrollo y mantenimiento así como en el rendimiento. Desde el punto de vista de arquitectura, debemos tener en cuenta las implicaciones de la distribución y valorar de manera "aséptica" todas las alternativas. Muchas veces he visto diseños que se podrían definir como "Sueño del arquitecto, pesadilla del desarrollador".

Una regla sencilla puede ser "No distribuyas nunca la aplicación". Si el mundo fuese un "poco" más simple y esta regla fuese válida en cualquier circunstancia, asunto terminado. (Me ha dado un escalofrío solo de pensarlo...).

Por lo tanto en ocasiones debemos distribuir de manera obligatoria, pero cuando?
Básicamente cuando no nos quede más remedio, como por ejemplo:

• Una de las separaciones más obvias es la tradicional entre clientes y servidores de software.
  Los PCs son diferentes nodos y comparten repositorios de datos. Esto nos obliga a separara procesos que se comunican, siendo cliente/servidor la típica división entre procesos.
• Una segunda división ocurre a menudo entre la parte servidor de las aplicaciones y la base de datos (esa gran desconocida...) 
  Por supuesto puedes hacer correr tu aplicación en el mismo proceso de la base de datos utilizando elementos como procedimientos almacenados, pero en muchas ocasiones esto no es practico (por decirlo de alguna manera...). Debemos tener en cuenta que aunque el servidor y la base de datos corran en la misma máquina, lo hacen en procesos diferentes. Una vez que debemos comunicar diferentes procesos pagamos la mayor parte del coste de la distribución.
  Por supuesto los servidores de SQL están diseñado para estas practicas de modo que podamos minimizar el coste.
• Otra clásica separación en procesos suele ocurrir en los sistemas Web entre el Servidor Web y el Servidor de Aplicaciones. Normalmente asociado a aspectos de seguridad relacionados con exponer al exterior solo la parte Web reduciendo así la superficie de ataque posible.
• Emplear paquetes de software hace frecuente tener que realizar distribuciones entre procesos por las diferencias entre los proveedores. En ocasiones utilizan sus propios procesos así que de nuevo estamos distribuyendo. 
• Por último puede existir razones de peso por las que es necesario dividir el software de servidor. Eso sí, debemos asegurar muy bien de que es estrictamente obligatorio. No nos queda otra que dividir nuestro software en componentes remotos con interfaz de grano grueso. No vamos a hacer las mismas llamadas que si no estuviese distribuido, verdad...??
  Si tienes dudas sobre esto, puedes continuar leyendo sobre el tema en SOA != Client Server +  WCF

Como conclusión podemos decir que distribuir es una característica muy potente pero con un lado oscuro del cual debemos siempre tener en cuenta. Siendo conscientes de las implicaciones y valorando los riesgos podemos hacer llegar nuestro software hasta cotas más exigentes.

Cuando leemos documentación sobre los distintos modelos de implantación de SharePoint siempre se plantean dos escenarios: on-premise  y en modo cloud. Las instalaciones on-premise se refieren a todas aquellas que hacemos sobre servidores controlados por nosotros directamente, es decir en nuestras instalaciones. Cuando Microsoft habla sobre SharePoint en modo Cloud, se refieren a la capacidad de utilizar los distintos servicios de SharePoint sin necesidad de realizar instalaciones, configuraciones y la de pagar por uso, en concreto se refieren a la siguiente versión de SharePoint Online 2010 basado en SharePoint 2010.

Creo que esta es una simplificación de la flexibilidad de SharePoint 2010, en concreto habría que dejarlo en cuatros modelos: on-premise, Hosting, cloud computing y mixto; todo depende de la distribución de los servicios y su forma de uso.

Gracias al nuevo modelo de Aplicaciones de servicio SharePoint 2010 es capaz de distribuir los distintos servicios (búsquedas, Excel Services, BCS, ?) en modo: scale out (añadiendo servidores), con servidores exclusivos o enlazando con servicios de otras granjas. Esta capacidad nos permite disponer de un entorno donde los servicios pueden estar en proveedores externos (cloud) o en infraestructuras que alquilemos (hosting).

El Multi-Tenancy (multi empresa) particiona los datos de los servicios de forma que distintas empresas puedan trabajar sobre una misma granja de forma aislada proporcionando además un portal de administración reducido para su autoservicio. Para un proveedor, esta capacidad le permite ofrecer sus infraestructuras a sus clientes en modo cloud o SaaS (Software as a Service).

Para aislar los desarrollos de un Tenancy de otro disponemos de las soluciones Sandbox que se ejecutan solo en el ámbito de una Colección de Sitios y son administradas por los propios administradores de las Colecciones de Sitios. Las soluciones Sandbox además permiten ejecutar el código de forma aislada al resto de soluciones y de la granja pudiendo controlar o desactivar aquellas que generen problemas de rendimiento.

Comienzo así una temática sobre las capacidades de SharePoint 2010 para compartir servicios, en la que veremos casos prácticos para crear un modelo de hosting/cloud basado en SharePoint 2010.

*Estos comentarios son mi opinión y no necesariamente reflejan una realidad

Hace unos meses os comentaba como configurar de forma correcta la cuenta de servicio desatendida que se necesita en aplicaciones de servicio como PerformancePoint o los servicios de Excel. Para el caso de PerformancePoint y como recordatorio, os dejo este estupendo video del TechEd Norteamérica en el que se ve paso a paso como configurar PerformancePoint en SharePoint 2010 incluyendo la cuenta de servicio desatendida.

Entrevista realizada en http://wp7connect.blogspot.com/

¿Podeis hacer una breve presentación sobre el equipo?

Supongo que os habéis dado cuenta que la mayoría de blogs especializados en el sector ,de medio mundo, están hablando de vosotros después de que anunciarais en vuestros blogs personales, Bye Bye Brain, el juego para WP7 que estáis desarrollando ¿Os esperabais tanta repercusión en tan poco tiempo? ¿Cómo surgió la idea de desarrollar Bye Bye Brain?

No esperábamos tener tanta acogida como la que hemos tenido, empezamos con el video en vimeo y la cosa fue subiendo hasta que fuimos portada de gizmodo.com toda una hazaña.
La idea de desarrollar ByeByeBrain surgió a principio de año cuando nos enteramos que Microsoft iba a desarrollar una nueva plataforma móvil, nuestra empresa Plain Concepts es Partner Gold de Microsoft y pensábamos en hacer un juego.

¿Por qué consideráis que WP7 es una buena plataforma para lanzar vuestro proyecto, aún cuando todavía no se ha lanzado?

Esta pregunta es complicada de responder, pero supongo que nos lanzamos por ser afines a Microsoft, porque no esperábamos que hubiera muchos desarrolladores haciendo cosas, porque las dos tecnologías en las que se desarrolla XNA y Silverlight las utilizamos a diario así que pensamos que era la oportunidad perfecta para nosotros.

Muchos comentarios resaltan el hecho de que un equipo de tres personas ha realizado un desarrollo tan bueno ¿Cuánto tiempo os ha supuesto desarrollar Bye Bye Brain? ¿Cuál ha sido el aspecto o proceso más difícil?

El primer checking del proyecto se hizo el día 2 de julio a las 12 de la mañana y desde ese momento no hemos parado de trabajar, eso implica definir un pequeño prototipo del juego, pantallas funcionalidad y demás. La parte más difícil del proyecto para mí fue acomodarme a XNA, venia de Silverlight que es un framework de alto nivel con cosas muy cómodas y en XNA no teníamos nada, así en unos de las primeras semanas, definimos un pequeño framework de animaciones basada en Silverlight y un sistema para definir controles y relaciones entre los controles en XNA. Evidentemente no podemos definir los controles igual que en Silverlight pero queríamos definir una relación padre hijo con los DrawableGameComponents de XNA para que fuera más fácil trabajar con ellos. Definimos las DependencyProperties para XNA y alguna que otra cosa más. Con todo eso pudimos después hacer todas las animaciones de los elementos 2D de una manera cómoda ya que animar es tan fácil como en Silverlight.

¿Qué ventajas pensáis que tiene realizar juegos en XNA respecto a los desarrollos que se pueden realizar en otras plataformas móviles como Iphone o Android?

Las ventajas para nosotros en el .NET Framework y C# ya que son nuestros lenguajes principales de desarrollo diario. .NET Framework tiene todo lo que un desarrollador puede soñar y XNA también, así que nos sentimos muy cómodos trabajando con las herramientas. Además de la perfecta integración con Visual Studio 2010.

¿Qué breves consejos le daríais a desarrolladores independientes que están empezando a plantearse desarrollar juegos o aplicaciones para WP7?

Pues que es el momento de hacerlo ya que no hay muchos desarrolladores interesados y eso puede hacer que les sea fácil brillar ya que la plataforma es nueva. Además, desde mi punto de vista, las herramientas de Microsoft son las mejores.

¿Qué opináis de las herramientas de desarrollo para WP7? ¿Cuáles son sus puntos fuertes y sus puntos débiles?

Los puntos fuertes ya los he comentado, las API o frameworks, XNA y Silverlight, son súper productivos para desarrolla aplicaciones, ya que Silverlight con Visual Studio 2010 y con Expression Blend se puede hacer cosas muy chulas en muy poco tiempo. Sobre las cosas malas, son herramientas beta eso significa que contienen algunos bugs que no tienen workaround y que quizás el tiempo de despliegue de tu aplicación al emulador y al devices es muy lento.

¿Desde vuestro punto de vista y habiendo podido acceder a un terminal para desarrolladores qué crees que debe mejorar WP7 a corto-medio plazo?

Esto es una pregunta trampa, Microsoft lo está haciendo bien con WP7 pero realmente es su primera versión del SO, las otras plataformas van por la versión 2.2 o 4 así que evidentemente le falta muchas cosas, pero es un buen comienzo.

¿Cuánto tiempo calculáis que pasará desde que enviéis una aplicación a Microsoft hasta que esté evaluada e incorporada al Marketplace? ¿Cuáles son los puntos críticos de este proceso?

Por ahora no lo sabemos pero Microsoft ha prometido que el proceso será rápido.

Si podéis contarnos algo ¿qué proyectos futuros tenéis en mente respecto a WP7?

Pues tenemos pensado seguir con el desarrollo de ByeByeBrain con más mapas, ataques especiales, más mini juegos, etc. Además de empezar el desarrollo de otros juegos o aplicaciones.

¿Quereis añadir algo más que creas interesante para los usuarios interesados en WP7?

Pues decirles que si son desarrolladores este es su momento de que se bajen el SDK y se pongan en serio a hacer su proyecto con calma.

Podéis saber más sobre Plain Concepts (Luis Guerrero, Rodrigo Díaz y Ricardo Acosta) y sus desarrollos en la web de Plain Concepts y sus blogs personales.

Les damos las gracias a los tres por concedernos esta entrevista y les deseamos un gran éxito en este y otros proyectos sobre WP7. Estamos seguros que Bye Bye Brain será uno de los juegos más populares del Marketplace de WP7.

Para los interesados y personas que residen en Lima, Perú estaré participando como expositor en este Congreso de Ingeniería aportando mis conocimientos mediante una sesión técnica de Como Implementar Windows 7 en las Empresas. Aquí les comparto los afiches respectivos y donde poder registrarse.

http://www.utp.edu.pe/coniic2010

Por si alguno aún no se ha enterado aún, hace un mes y medio Microsoft sacó a la luz una nueva plantilla de Scrum TFS 2010.

Esta plantilla gratuita puede ser descargada desde la galería de Microsoft para Visual Studio 2010 en este enlace.

No obstante, si quieres curiosear las opciones de la plantilla antes de instalarla, te recomiendo entonces otro enlace sobre la guía de Visual Studio Scrum 1.0.

Se trata de un enlace que contiene un archivo zip, que una vez descomprimido, te mostrará en ficheros html todas y cada una de las opciones de esta plantilla, lo cuál te ayudará a buen seguro para determinar si instalas la plantilla en TFS o no.

Podrás acceder a esta documentación en este enlace.

Buenas! Hoy voy a responder alguna pregunta que me he encontrado en alguna vez, y es como subir ficheros al servidor usando MVC2.

La verdad es que con ASP.NET MVC2 subir ficheros al servidor es extremadamente simple. Vamos a empezar viendo el código de una vista que permite subir un fichero al servidor, junto con una descripción adicional. La vista básicamente contiene un  <form> como el siguiente:

<form action="<%: Url.Action("Upload") %>" enctype="multipart/form-data" method="post">
    <label for="descripcion">Descripción del fichero:</label>
    <input type="text" id="descripcion" name="descripcion" />
    <br />
    <label for="fichero">Fichero:</label>
    <input type="file" name="fichero" size="40">
    <br />
    <input type="submit" value="Enviar" />
</form>

Fijaos que es HTML puro y duro, aunque el tag <form> lo podeis generar con Html.BeginForm() si queréis. La clave es añadir el atributo enctype con el valor multipart/form-data. Como se menciona en la especificación sobre formularios del W3C, el valor de multipart/form-data es el que debe usarse cuando se quieran enviar al servidor datos binarios.

El <input type=?file?> es el control HTML que nos permite seleccionar un fichero para enviar.

Y desde el controlador? Pues sencillo, en este caso mi formulario tiene dos parámetros (descripcion y fichero), por lo que necesitaré que la acción del controlador tenga esos dos parámetros. El parámetro descripcion es un string, pero el parámetro fichero? que és?

Pues bien ASP.NET MVC es capaz de ver que el parámetro fichero es un fichero que se ha subido al servidor y sabe mapearlo a un objeto de la clase HttpPostedFileBase. Esta clase nos da acceso no sólo al contenido del fichero subido, sinó a más información (su content-type, su tamaño, el path completo desde donde se ha subido,?).

El método del controlador queda pues, así de sencillo:

[HttpPost]
public ActionResult Upload(string descripcion, HttpPostedFileBase fichero)
{
    fichero.SaveAs(Path.Combine(@"d:\temp", Path.GetFileName(fichero.FileName)));
    return View();
}

Fijaos en los dos parámetros string y HttpPostedFileBase. El método simplemente se guarda una copia del fichero subido en d:\temp, pero obviamente aquí podéis hacer lo que queráis.

Y listos! No hay que hacer nada más? qué, sencillo, no??? :)

Un saludo

PD: Esta técnica no es ajax, eso significa que mientras se está subiendo el fichero al servidor, la aplicación web no responde (el browser está haciendo la petición). Existe un mecanismo para realizar subidas de ficheros en background, aunque no es directo debido a que con XMLHttpRequest (el objeto del naveagador que hace posible ajax) no se pueden subir ficheros. Si estáis interesados en el siguiente post de John Rudolf se muestra como realizar un upload de fichero en ajax usando jQuery y el form plugin!