ALM con elBruno, parte 2


Hola, les recuerdo que el próximo sábado 27 de septiembre a las 15:00(GMT) tenemos la segunda parte de la charla de ALM con VSTS de la mano de elBruno.


El link de la reunión es: https://www.livemeeting.com/cc/microsoft/join?id=VSTSES&role=attend&pw=N-q%2C5gtPf


Nos vemos el sábado y no olviden repasar la primera parte así no se sienten colgados.


El horario de la reunión en otras cuidades es:
















































































































































































































































































































































Addis Ababa sab 18:00     Guatemala sab 9:00     Nassau * sab 11:00
Adelaide dom 0:30 Halifax * sab 12:00 New Delhi sab 20:30
Aden sab 18:00 Hanoi sab 22:00 New Orleans * sab 10:00
Algiers sab 16:00 Harare sab 17:00 New York * sab 11:00
Almaty sab 21:00 Havana * sab 11:00 Oslo * sab 17:00
Amman * sab 18:00 Helsinki * sab 18:00 Ottawa * sab 11:00
Amsterdam * sab 17:00 Hong Kong sab 23:00 Paris * sab 17:00
Anadyr * dom 4:00 Honolulu sab 5:00 Perth sab 23:00
Anchorage * sab 7:00 Houston * sab 10:00 Philadelphia * sab 11:00
Ankara * sab 18:00 Indianapolis * sab 11:00 Phoenix sab 8:00
Antananarivo sab 18:00 Islamabad * sab 21:00 Prague * sab 17:00
Asuncion sab 11:00 Istanbul * sab 18:00 Reykjavik sab 15:00
Athens * sab 18:00 Jakarta sab 22:00 Rio de Janeiro sab 12:00
Atlanta * sab 11:00 Jerusalem * sab 18:00 Riyadh sab 18:00
Auckland * dom 4:00 Johannesburg sab 17:00 Rome * sab 17:00
Baghdad sab 18:00 Kabul sab 19:30 San Francisco * sab 8:00
Bangkok sab 22:00 Kamchatka * dom 4:00 San Juan sab 11:00
Barcelona * sab 17:00 Karachi * sab 21:00 San Salvador sab 9:00
Beijing sab 23:00 Kathmandu sab 20:45 Santiago sab 11:00
Beirut * sab 18:00 Khartoum sab 18:00 Santo Domingo sab 11:00
Belgrade * sab 17:00 Kingston sab 10:00 Sao Paulo sab 12:00
Berlin * sab 17:00 Kiritimati dom 5:00 Seattle * sab 8:00
Bogota sab 10:00 Kolkata sab 20:30 Seoul dom 0:00
Boston * sab 11:00 Kuala Lumpur sab 23:00 Shanghai sab 23:00
Brasilia sab 12:00 Kuwait City sab 18:00 Singapore sab 23:00
Brisbane dom 1:00 Kyiv * sab 18:00 Sofia * sab 18:00
Brussels * sab 17:00 La Paz sab 11:00 St. John’s * sab 12:30
Bucharest * sab 18:00 Lagos sab 16:00 St. Paul * sab 10:00
Budapest * sab 17:00 Lahore * sab 21:00 Stockholm * sab 17:00
Buenos Aires sab 12:00 Lima sab 10:00 Suva dom 3:00
Cairo sab 17:00 Lisbon * sab 16:00 Sydney dom 1:00
Canberra dom 1:00 London * sab 16:00 Taipei sab 23:00
Cape Town sab 17:00 Los Angeles * sab 8:00 Tallinn * sab 18:00
Caracas sab 10:30 Madrid * sab 17:00 Tashkent sab 20:00
Casablanca sab 15:00 Managua sab 9:00 Tegucigalpa sab 9:00
Chatham Island * dom 4:45 Manila sab 23:00 Tehran sab 18:30
Chicago * sab 10:00 Melbourne dom 1:00 Tokyo dom 0:00
Copenhagen * sab 17:00 Mexico City * sab 10:00 Toronto * sab 11:00
Darwin dom 0:30 Miami * sab 11:00 Vancouver * sab 8:00
Denver * sab 9:00 Minneapolis * sab 10:00 Vienna * sab 17:00
Detroit * sab 11:00 Minsk * sab 18:00 Vladivostok * dom 2:00
Dhaka sab 21:00 Montevideo sab 12:00 Warsaw * sab 17:00
Dubai sab 19:00 Montgomery * sab 10:00 Washington DC * sab 11:00
Dublin * sab 16:00 Montreal * sab 11:00 Winnipeg * sab 10:00
Edmonton * sab 9:00 Moscow * sab 19:00 Yangon sab 21:30
Frankfurt * sab 17:00 Mumbai sab 20:30 Zagreb * sab 17:00
Geneva * sab 17:00 Nairobi sab 18:00 Zürich * sab 17:00

Voy a estar en línea 1 hora antes del evento así que cualquier consulta me ubican por msn en fhualpa@REMOVERMAYUSCULASmsn.com.


Fernik

ALM con elBruno, parte 1

Hola, este post es sólo para sintetizar la primera parte de la sesión de ALM con elBruno. Realmente la sesión fue muy amena ya que hubieron ejemplos prácticos con un miniproyecto y la presentación no se tornó aburrida, pero lo que quiero destacar es que como desarrolladores si bien trabajamos con tecnología pareciera que a veces somos cavernícolas ya que no utilizamos todo el potencial de nuestras herramientas como así también de herramientas de terceros, frameworks, etc. Por eso recomiendo empezar a cambiar de actitud con un hábito muy simple que indicó Bruno, y consiste en dedicarle entre 10 y 15 minutos a una herrmienta nueva para evaluar si realmente agrega valor a nuestro trabajo. Pueden ver las herramientas de desarrollo de referencia que recomienda Bruno en http://geeks.ms/blogs/elbruno/archive/2008/09/22/evento-recursos-del-evento-de-alm-recursos-parciales-como-las-clases.aspx y comenzar a evaluarlas.

Como la gente de Microsoft Latam, se toma su tiempo para publicar el webcast en MediaCenter, les dejo un link del replay del webcast que está en mi SkyDrive, así pueden verlo y estar preparados para la segunda parte el próximo sábado.

Fernik

elBruno en LiveMeeting

Como parte del programa Student to Business en latinoamérica estamos organizando una serie de conferencias técnicas en LiveMeeting con gente que realmente son un referente en la industria. En este caso los quiero invitar a la charla de Gestión del ciclo de vida del desarrollo de aplicaciones con Visual Studio a cargo de Bruno Capuano, conocido como elBruno. Bruno es como elGuille pero muy muy Enterprise, por eso me parece una oportunidad única para asistir a esta reunión virtual en donde él compartirá su experiencia en proyectos empresariales e internacionales de gestión de aplicaciones con Visual Studio Team System. Habitualmente Bruno realiza este tipo de sesiones en eventos presenciales, pero ha accedido a realizarla en Livemeeting en 2 sesiones que tendrán lugar los sábados 20 y 27 de Septiembre del 2008 a las 15:00 GMT, que serían 17:00 en España(GMT +2), 12:00 en Argentina(GMT -3), etc, al final del post publicaré un horario para el resto de los países de habla hispana. Les recuerdo que estas sesiones no son las sesiones típicas de Livemeeting de 1 hora en donde se «vende un producto», esto es realmente una sesión que va más allá de vender un producto sino de empezar a despertar un criterio profesional por eso las hemos estructurado en 2 sesiones de 2 hs(con preguntas y respuestas incluidas) cada una en 2 sábados. Así que les dejo el link de la reunión en LiveMeeting https://www.livemeeting.com/cc/microsoft/join?id=9KB2QC&role=attend&pw=xr.2Ns3%7Ew y el link del evento de Student to Business en facebook http://www.new.facebook.com/event.php?eid=49191092288.

Voy a estar 1 hora antes del evento para asistir con cualquier problema de audio o de inicio de sesión en LiveMeeting, cualquier consulta les dejo mi dirección de messenger para que me encuentren OnLine fhualpa@REMOVERMAYUSCULASmsn.com.

Nos vemos el sábado 20.

Fernik

P.S: Este es el horario de la reunión en las principales cuidades del planeta, cualquier consulta agreguen un comentario al blog.

Addis Ababa sab 18:00     Guatemala sab 9:00     Nassau * sab 11:00
Adelaide dom 0:30 Halifax * sab 12:00 New Delhi sab 20:30
Aden sab 18:00 Hanoi sab 22:00 New Orleans * sab 10:00
Algiers sab 16:00 Harare sab 17:00 New York * sab 11:00
Almaty sab 21:00 Havana * sab 11:00 Oslo * sab 17:00
Amman * sab 18:00 Helsinki * sab 18:00 Ottawa * sab 11:00
Amsterdam * sab 17:00 Hong Kong sab 23:00 Paris * sab 17:00
Anadyr * dom 4:00 Honolulu sab 5:00 Perth sab 23:00
Anchorage * sab 7:00 Houston * sab 10:00 Philadelphia * sab 11:00
Ankara * sab 18:00 Indianapolis * sab 11:00 Phoenix sab 8:00
Antananarivo sab 18:00 Islamabad * sab 21:00 Prague * sab 17:00
Asuncion sab 11:00 Istanbul * sab 18:00 Reykjavik sab 15:00
Athens * sab 18:00 Jakarta sab 22:00 Rio de Janeiro sab 12:00
Atlanta * sab 11:00 Jerusalem * sab 18:00 Riyadh sab 18:00
Auckland dom 3:00 Johannesburg sab 17:00 Rome * sab 17:00
Baghdad sab 18:00 Kabul sab 19:30 San Francisco * sab 8:00
Bangkok sab 22:00 Kamchatka * dom 4:00 San Juan sab 11:00
Barcelona * sab 17:00 Karachi * sab 21:00 San Salvador sab 9:00
Beijing sab 23:00 Kathmandu sab 20:45 Santiago sab 11:00
Beirut * sab 18:00 Khartoum sab 18:00 Santo Domingo sab 11:00
Belgrade * sab 17:00 Kingston sab 10:00 Sao Paulo sab 12:00
Berlin * sab 17:00 Kiritimati dom 5:00 Seattle * sab 8:00
Bogota sab 10:00 Kolkata sab 20:30 Seoul dom 0:00
Boston * sab 11:00 Kuala Lumpur sab 23:00 Shanghai sab 23:00
Brasilia sab 12:00 Kuwait City sab 18:00 Singapore sab 23:00
Brisbane dom 1:00 Kyiv * sab 18:00 Sofia * sab 18:00
Brussels * sab 17:00 La Paz sab 11:00 St. John’s * sab 12:30
Bucharest * sab 18:00 Lagos sab 16:00 St. Paul * sab 10:00
Budapest * sab 17:00 Lahore * sab 21:00 Stockholm * sab 17:00
Buenos Aires sab 12:00 Lima sab 10:00 Suva dom 3:00
Cairo sab 17:00 Lisbon * sab 16:00 Sydney dom 1:00
Canberra dom 1:00 London * sab 16:00 Taipei sab 23:00
Cape Town sab 17:00 Los Angeles * sab 8:00 Tallinn * sab 18:00
Caracas sab 10:30 Madrid * sab 17:00 Tashkent sab 20:00
Casablanca sab 15:00 Managua sab 9:00 Tegucigalpa sab 9:00
Chatham Island dom 3:45 Manila sab 23:00 Tehran * sab 19:30
Chicago * sab 10:00 Melbourne dom 1:00 Tokyo dom 0:00
Copenhagen * sab 17:00 Mexico City * sab 10:00 Toronto * sab 11:00
Darwin dom 0:30 Miami * sab 11:00 Vancouver * sab 8:00
Denver * sab 9:00 Minneapolis * sab 10:00 Vienna * sab 17:00
Detroit * sab 11:00 Minsk * sab 18:00 Vladivostok * dom 2:00
Dhaka sab 21:00 Montevideo sab 12:00 Warsaw * sab 17:00
Dubai sab 19:00 Montgomery * sab 10:00 Washington DC * sab 11:00
Dublin * sab 16:00 Montreal * sab 11:00 Winnipeg * sab 10:00
Edmonton * sab 9:00 Moscow * sab 19:00 Yangon sab 21:30
Frankfurt * sab 17:00 Mumbai sab 20:30 Zagreb * sab 17:00
Geneva * sab 17:00 Nairobi sab 18:00 Zürich * sab 17:00

 

SQL Server Data Services, fundamentos

SSDS es un almacén de datos, que utiliza las tecnologías de SQL Server y expone su funcionalidad a través de interfases de servicios Web y protocolos abiertos. Como servicio provee su propio modelo de datos y de provisionamiento para operarlo y está diseñado para ser un servicio Web 2.0 proporcionando interfases SOAP y REST.
La idea de usar un servicio de datos en vez de una base de datos en las premisas del cliente es no tener que lidiar con costos de la tecnología en sí (licenciamiento de software + adquisición de hardware) ni con estimaciones de requerimientos de procesamiento y de planeación de capacidad.


El Modelo de Provisionamiento


El modelo de provisionamiento de SSDS, consiste en un modelo de entidades flexibles. Antes de explicar el modelo de entidades flexibles eviten asociar la palabra entidad con Entity Framework, cuyo modelo de entidad es diferente. Las entidades de SSDS no tienen un esquema asociado con ellas, o sea son schemaless,  no tienen una estructura definida, sino que son un conjunto de propiedades, en donde cada propiedad es una dupla nombre/valor.
El modelo tiene  3 elementos: autoridad, contenedor y entidad, la siguiente figura muestra una analogía del modelo de provisionamiento ACE de SSDE y el modelo de provisionamiento relacional de SQL Server.




Para comenzar a almacenar datos se debe haber creado al menos una autoridad. La creación de una autoridad SSDS crea un nombre de DNS para poder referenciarla.  Por ejemplo: como SSDS está hosteado en data.beta.mssds.com, si creamos una autoridad (base de datos) llamada fernik, SSDS crea la autoridad y la hace accesible en fernik.data.beta.mssds.com, lo cual revela que los nombres que elijamos para autoridades deben seguir las reglas y convención de nombres de DNS, así que olvidándose de elegir nombres con notación camel. Además la autoridad es una unidad de geo-ubicación, esto quiere decir que si se crean 2 autoridades como fernik.america.data.beta.mssds.com y fernik.europa.data.beta.mssds.com se han creado en diferentes datacenters en donde está hosteado SSDS. La idea de crear autoridades en diferentes datacenters es de disponer los datos lo más cerca posible de los usuarios que consumirán el servicio. Actualmente hay un datacenter de SSDS en Norteamérica (data.beta.mssds.com).


Como en el modelo relacional una base de datos es una colección de tablas en el modelo de SSDS, una autoridad es una colección de contenedores. La diferencia es que cuando se crean contenedores no se define o adjunta un esquema, en cambio cuando se crea una tabla hay que proporcionar información sobre la estructura de la misma. Esta independencia de los contenedores respecto de un esquema permite almacenar en ellos entidades tanto homogéneas como heterogéneas. Lo cual no es el caso de una tabla relacional la que sólo nos permite almacenar filas homogéneas.  Así se plantean 2 modelos de uso según las necesidades de la aplicación:




  • Modelo Homogéneo:  El contenedor almacena entidades del mismo tipo. En este modelo el contenedor se comporta como una tabla en una base de datos relacional.
     


  • Modelo Heterogéneo:  El contenedor almacena entidades de diferentes tipos. En este modelo el contenedor se comporta como una base de datos que almacena entidades de todo tipo.

En el release actual de SSDS  las consultas tienen ámbito de contenedor, todavía no es posible realizar consultas entre contenedores (lo que equivale a consultas entre tablas en el modelo relacional), pero como los contenedores pueden almacenar entidades heterogéneas es posible almacenar todas nuestras entidades en un único contenedor y realizar la consulta sobre el mismo.


Una entidad es el equivalente a una fila en el modelo relacional. Consiste en un conjunto de propiedades en forma de  pares nombre/valor (como un objeto Dictionary o un array asociativo).  El valor puede ser un tipo escalar simple, actualmente los siguientes tipos escalares son soportados: string, binary, boolean, decimal y datetime.
Una entidad es el objeto más pequeño que puede ser actualizado. Esto implica que se puede obtener una entidad, agregar/actualizar/eliminar propiedades y luego reemplazar la entidad original con la modificada. Las actualizaciones parciales no son soportadas por ahora.


El Modelo de Datos


La entidad flexible es el concepto fundamental en SSDS. Tanto autoridades, contenedores como entidades son entidades flexibles. Cada una de estas entidades consiste en propiedades en forma de pares nombre/valor se agrupan en 2 categorías: Metadatos y Flexibles.




  • Propiedades de Metadatos: Cada entidad posee in conjunto fijo de propiedades (Id, Version y Kind). Estas propiedades se denominan propiedades de metadatos. La propiedad Id identifica unívocamente a la entidad y debe ser única dentro del contenedor en el que existe, pero diferentes contenedores pueden contener entidades con el mismo Id. La propiedad Version actúa como un timestamp o marca de tiempo y se emplea para identificar la versión actual de la entidad. El valor de la propiedad Version se actualiza con cada operación que se realiza sobre la entidad. El valor de la propiedad Kind es definido por el usuario y se utiliza para categorizar entidades similares. No hay que olvidarse de que como no existe un esquema asociado a las entidades, por lo que tener entidades con el mismo valor de la propiedad Kind no garantiza la misma estructura.



  • Propiedades Flexibles: Además de las propiedades de metadatos, una entidad puede tener 0 o más propiedades flexibles adicionales. Estas propiedades es en donde se almacenan los datos de la aplicación. Las propiedades flexibles pueden tener cualquier nombre y valor de los siguientes tipos escalares: string, decimal, bool, datetime y binary.

Para verificar que toda autoridad, contenedor y entidad es una entidad flexible vamos inspeccionar el modelo de objetos de SSDS. Para ello es necesario agregar una referencia a al servicio SSDS.



Luego, si inspeccionamos el modelo de objetos con Object Browser se aprecia  que la clase Entity del modelo ACE es en sí la entidad flexible, ya que se emplea para modelar el resto de las entidades del modelo ACE.






Ahora bien, si observamos el código  del proxy generado las propiedades de metadatos son realmente propiedades definidas explícitamente, es decir tienen un nombre propio y un tipo, responden a un esquema. Sin embargo a lo que llamamos propiedades flexibles se las modela como un Diccionario genérico parametrizado con <string, object>, o sea que las propiedades flexibles están definindas como pares nombre/valor que son miembros de una colección. Al implementar las propiedades flexibles de esta forma se alcanza una flexibilidad similar a la del DataSet/DataTable no tipado pero al costo que tiene cualquier abstracción no tipada: verificación en tiempo de ejecución.


También es importante destacar el uso del atributo KnownTypeAttribute, para especificar contrados de datos equivalentes en tipos derivados. Por lo tanto se deduce que tanto Authority como Container derivan de Entity. Pero para que quede claro y no haya dudas, vamos a generar un diagrama de clases a partir de este código el cual representará la relación existente entre autoridad, contenedor y entidad desde un punto de vista estático.




Ahora sí se puede apreciar que aunque una autoridad y un contenedor son contenedores lógicos de entidades, ellos son clases hijas del la clase Entidad que es la entidad flexible en sí, y que se diferencian por las parametrizaciones de sus propiedades de metadatos y propiedades flexibles. La siguiente tabla muestras las posibles combinaciones de propiedades de metadatos y propiedades flexibles para crear autoridades, contenedores y entidades:



SQL Server Data Services es un servicio que todavía está en pañales, hay planes para ofrecer crear entidades con esquemas e incluso poder hostear una instancia en las premisas del cliente. Independientemente de los planes y mejoras futuras me parece interesante considerar esta tendencia que iniciaron Amazon con SimpleDB y Google con AppEngine de publicar los datos en la gran nube que es Internet. En ciertos escenarios no lo considero factible, sobre todo si se trata de información financiera o de información crítica para que el negocio funcione diariamente, pero para ciertas aplicaciones como mashups, perfiles de usuario, etc. creo que tiene un muy buen potencial. Ahora lo que nadie dice es que por más que confiemos en nuestro provedor del servicio ya sea Microsoft, Amazon o Google y que nuestros datos estén en un cluster diseñado para proveer servicios de datos, se experimentan tiempos de baja en el servicio y es ahí donde no tenemos acceso a la infraestructura y nuestro negocio puede depender de ello. Por ello finalizo este post con una de las tantas notificaciones que se reciben de SSDS y un consejo final, si están dispuestos a aceptar este tipo de notificaciones de interrupción en su negocio u aplicación, pues adelante sino a montar su propoia infraestructura de datos.



En los próximos posts escribiré sobre las interfases SOAP y REST de SSDS así como de características únicas como consultas basadas en LINQ.


Hasta la próxima,


Fernik