Geeks.ms: vuestro sitio, vuestra comunidad

Geeks Cada vez veo más comentarios y post que se refieren a Geeks.ms como ‘el sitio de Rodrigo’, y me gustaría aclarar, como ya he hecho en algún comentario que Geeks.ms no es mi sitio, sino un sitio de la comunidad, un sitio de todos los bloggers que escriben en él.

Plain Concepts promovio este sitio como una iniciativa más de las que realiza por y para la comunidad, y a mi me toco, de entre todos los que podrian hacer esta tarea en Plain Concepts, el administrar esta comunidad y tratar de que poco a poco fuese ganando relevancia. Mantengo en servidor, filtro las peticiones de blogs, invito a nuevos bloggers, me encargo de tratar de posicionar Geeks.ms en los buscadores, lucho contra el spam, etc… El tiempo que yo y algún otro compañero de Plain Concepts dedicamos a estas tareas es la aportación que Plain Concepts hace a esta comunidad. Pero Geeks.ms no es mi sitio es vuestro sitio, es el sitio de los que en él escriben, comentan, preguntan y o simplemente lo leen.

Toda comunidad, sea un grupo de usuarios, un club de estudiantes, o una comunidad online, tiene gente que realiza esfuerzos y que vela por que la comunidad prospere y se mantenga activa, pero no por eso los miembros más activos son los propietarios de la comunidad. Geeks.ms desde que incio sus pasos se ha convertido en un sitio bastante popular gracias a todos los que, sea como sea, participan en esta comunidad. Hay bloggers que trabajan en diferentes empresas, de diferentes paises, que conocen diferentes tecnologías, estudiantes, profesionales, entusiastas, lectores de todos los niveles, que comentan, que no comentan y de todo ellos, en alguna medida, es Geeks.ms.

Otro tema que me gustaría comentar es que Geeks.ms es una comunidad totalmente libre. Cada blogger, dentro de los límites del respeto a los demás, puede en todo momento escribir lo que quiera. Nunca se ha censurado o editado ningún artículo escrito por nadie.

Hace un año Student.net publico una entrevista en la que yo hablaba de Geeks.ms,y  en la que ya se tocaba este tema, os dejo su texto, creo que será interasante para todos los que participan en Geeks.ms:

· ¿Que es Geeks?

Es un sitio dedicado a la comunidad sobre tecnologías Microsoft donde la gente puede encontrar todo aquello que los geeks en infraestructura y desarrollo  tienen que contar al mundo. Entre nuestros geeks se encuentran numerosos MVPs, varios MCTs, y muchos promotores de grupos de usuarios. En general lo que prentendemos es reunir en un solo sitio la voz, a través de sus blogs, de todos los miembros hispano-hablantes relevantes de las comunidades de Microsoft.
Además contamos con foros sobre numerosos temas donde la gente puede plantear cuestiones.

· ¿Cómo empezó Geeks.ms?

Bueno, aunque ahora yo sea quien administra y sea la cara visible de Geeks.ms, Geeks.ms es una iniciativa de Plain Concepts por y para la comunidad. Plain Concepts es quien pone el tiempo que yo dedico a Geeks.ms. Esta inicitiva tiene sus origenes en otra comunidad anterior, los blogs de GolemProject, en los que Iván González, amigo, compañero y socio mio en Plain Concepts y tambien MVP, logro reunir a un buen puñado de los que actualmente están en Geeks.ms. Por diferentes razones, los blogs de GolemProject ‘murieron’, dando paso a Geeks.ms. Iván fue quien monto el servidor de Geeks.ms en primera instancia y el verdadero padre de esta iniciativa. Yo luego tome el relevo en la administración, personalización y lanzamiento de la comunidad.

· ¿Cuales fueron las dificultades que encontraste para lanzar la comunidad?

A la hora de lanzar una comunidad virtual, los retos son principalmente dos: captar miembros relevantes para esa comunidad y montar la infraestructura técnica.

La parte de captar miembros ha sido relativamente sencilla gracias a que la mayoría de los que trabajamos en Plain Concepts somos MVP o gente muy comprometida con la comunidad, por lo tanto todos tenemos muy buena relación con otros miembros de la comunidad y ha sido facil convercerles para que participen en Geeks.ms. Quiero aprovechar para agredecerles a todos esa participación, ellos y los lectores son la parte realmente importante de Geeks.ms.

Por el lado tecnico, la elección de utilizar Community Server que hizo Iván en su momento fue excelente. Es un gran producto. Evidentemente he tenido algún trabajo de aministración y personalización, e incluso algunos problemas con el spam, pero la verdad es que es un producto facil de administrar y personalizar. Me ha sorprendido incluso la facilidad para aplicar nuevas versiones o service packs sin peder las personalizaciones y sin tener que parar el servicio. El ‘uptime’ de Geeks.ms es realmente bueno. Community Server es un excelente ejemplo de las excelentes aplicaciones que se pueden construir en .Net. 

El mayor problema ha venido por el lado del crecimento de las visitas, que ha sido realmente espectacular. Como consecuencia la base de datos del servidor estaba sufriendo mucha carga, pero con una buena optimización de los índices de Sql Server el problema se soluciono. Lo mejor de administrar Geeks.ms es todo lo que he aprendido sobre Community Server, es lo bueno de participar en la comunidad, de un modo u otro, siempre aprendes un montón de cosas.

· ¿Como ves a Geeks dentro de un par de años?

No se que pasará de aquí a dos años. Lo que me gustaría es que se convirtiese en uno de los sitios de referencia para la comunidad en castellano. El objetivo es que cuando alguien quiera estar informado de que ocurre en la comunidad .Net la información más fresca la encuentre en Geeks.ms. Lo que persigo es que todo blog interesante que escriba gente relevante de la comunidad Microsoft esté en Geeks.ms.

Tambien me gustaría que los foros fuesen ganando relevancia y que el número de comentarios subiese significativamente.

· ¿Futuras ideas para Geeks.ms?

Tenemos grandes planes para Geeks.ms. Por ejemplo, estamos pensando en organizar concursos relacionados con la programación. En esta línea tambien estamos habriendo la puerta a blogs menos personalistas y más temáticos como Programacia101, en el que Ricardo Varela nos va a ir sorprendiendo con problemas relacionados con la programación.

Otra idea que me ronda la cabeza es organizar algún evento con la gente que escribe en Geeks.ms como ponentes, para permitir que los lectores puedan conocer personalmente a la gente que leen, para promocionar más el contacto entre los miembros de esta comunidad. 

Me gustaría aumentar la presencia que tienen los blogs dedicados a sistemas. Hoy por hoy la gran mayoría son escritos por desarrolladores.

· ¿Cúal crees que es la repercusión del portal en la Comunidad .NET?

Cuando por Mayo, comenzabamos con esta comunidad yo dudaba que alguna vez pudiesemos alcanzar el nivel de visitas y popularidad que tubieron en su día los blogs de GolemProject. No tengo los datos exactos, pero estimo que ha día de hoy ese objetivo está sobradamente conseguido.

Otra cosa importante es que casi todos los miembros relevantes de la comunidad tiene su blog alojado en Geeks.ms y creo que se puede decir todos los que participan en la comunidad leen Geeks.ms. Sin duda la repercusión de Geeks.ms en la comunidad es alta, lo que me gustaría lograr es que esa repercusión pasase las barreras de la comunidad y que Geeks.ms se convirtiese en la página de incio de todo aquel que desarrolla o administra sistemas en entornos Microsoft.

Un enfoque ágil para la optimización

OptimizacionCuando empecé en esto de la programación, las aplicaciones eran mucho más sencillas desde el punto de vista arquitectonico y la optimización de las mismas era un oscuro arte que solo algunos programadores dominaban basado en conocer ciertos trucos o ser capaces de generar código en ensamblador mejor que el compilador. El rendimiento de la aplicación se obtenía a base de mejoras de implementación, o incluso derivaban de usar un lenguaje u otro (quien no ha escrito un componente en C++ para llamarlo desde VB por cuestiones de rendimiento), no tanto de temas de arquitectura. Además no existían (o no eran tan populares) los profilers y el proceso de optimización era puramente artesanal. Solo aquellas aplicaciones que tenían unos requisitos muy fuertes de rendimiento eran optimizadas de manera formal pues el coste de optimizar era muy alto. Cómo optimizar a posteriori era algo muy costoso, muchos desarrolladores caían en el demonio de la optimización temprana, tratando de hacer optima cada línea de código, sacrificando otros aspectos como la legibilidad, la mantenibilidad o la velocidad de desarrollo.

Este panorama ha cambiado radicalmente en los últimos tiempos. Los motores de este cambio radical han sido la mayor complejidad de las arquitecturas, la aparición de las máquinas virtuales de ejecución y la popularización de los profilers.

La mayor complejidad de las arquitecturas ha propiciado que las mayores ganancias en rendimiento se obtengan de una buena arquitectura, más que de detalles de implementación. Las grandes decisiones de arquitectura son las que más van ha influir sobre el rendimiento de nuestra aplicación. Si por ejemplo nos decantamos por una arquitectura que implica un constante trasiego de peticiones de red, poco podrémos hacer después si la red se convierte en un cuello de botella, salvo cambiar la arquitectura, algo que puede ser tremendamente costoso. Esto no quiere decir que una vez seleccionada una buena arquitectura nuestro código no pueda ser revisado desde el punto de vista del rendimiento para mejorar este aspecto

La popularización de las máquinas virtuales de ejecución y la mejora general de los compiladores ha hecho que la optimización a priori basada en pequeños detalles haya dejado de tener ningún sentido. Cuando hay tantas capas que pueden realizar optimizaciones automáticas e incluso adaptativas entre nuestro código y el procesador es imposible conocer en detalle como será el código máquina que finalmente se ejecute y por lo tanto, salvo tener en cuenta ciertas buenas prácticas (por ejemplo al trabajar con cadenas) poco más podemos hacer… sin usar un profiler.

Lo bueno de usar un profiler es que nos permite alejarnos completamente del peligro de caer en la optimización temprana. Resumiendo, la optimización temprana es un antipatrón que se manifiesta por optimizar aspectos de nuestra aplicación sin tener la certeza de que realmente afectan al rendimiento de la misma. Por ejemplo, podemos perder el tiempo en optimizar funciones que, debido a los patrones de uso de la aplicación, puede que no se ejecuten muy a menudo o que en última instancia el compilador puede optimizar por nosotros. Esto unido a la complejidad de las arquitecturas, que hace dificil saber cual será el cuello de botella de nuestra aplicación, hace que el mejor momento para optimizar sea cuando la aplicación ya se encuentra en preproducción, sometida a cargas de trabajo reales o cercanas a las reales.

A la hora de conseguir una aplicación que se ejecute con soltura y sin requerir un hardware extremadamente costoso, cada vez se tiende más a seguir una estrategia basada en: no olvidar el rendimiento a la hora de plantear la arquitectura y el diseño, no olvidar las buenas prácticas relacionadas con el rendimiento a la hora de la implementación (usar un analizador estático, como FxCop, es una manera excelente de no olvidarlas) y utilizar un profiler para hacer una optimización centrada en los cuellos de botella de nuestro código una vez tenemos escenarios de carga realistas.

Entiendasemé, en ningún caso quiero decir que debamos dejar el asguramiento del rendimiento de nuestra aplicación para el final del desarrollo. Es algo que debemos hacer iterativamente, de manera contínua, siempre que completemos un escenario de nuestra aplicación que tenga unos requisitos determinados de rendimiento o que pueda impactar sobre el rendimiento de otros escenarios.

Otro aspecto fundamental a la hora de abordar la optimización es el ‘hasta donde’. Todo es optimizable, siempre se puede dar un paso más, pero cada paso siempre es un poco más costoso que el anterior, por eso no siempre es económicamente rentable dar el siguiente paso. Para saber donde pararse en temas de optimízación es necesario establecer para cada escenario que lo requiera, unas condiciones de rendimiento objetivas, realistas y medibles que cubran las expectativas del usuario.

Si bien siguiendo la filosofía aquí comentada nuestras aplicaciones no deberían tener excesivos problemas de rendimiento, es un realidad que muchas veces los problemas de rendimiento solo se manifestarán cuando ya tengamos la aplicación en producción. Si el problema es de arquitectura, probablemente tendremos un proyecto fallido, pero sino es el caso siempre queda una esperanza, usar un profiler sobre la aplicación en producción, pero esa es otra historia… que pronto contaré.

Pensandoun poco y tras releer este post… ¿quizás la moraleja de toda esta historia es que si tienes buenos arquitectos es probable que no te tengas que preocupar de la optimización? Las personas sobre los bits una vez más…

Pruebas web de Team System usando Firefox

Es cierto que aunque su cuota de mercado no es la más elevada, Firefox ha conseguido un buen puñado de adeptos. Y además muy ruidosos. En según que situaciones, que tu aplicación no soporte Firefox puede ser una cuestión que afecte bastante al posible exito de tu aplicación. Si bien desde un sentido puramente económico soportar Firefox es, a menudo, una cuestión de criticable rentabilidad, también es cierto que los usuarios de cualquier navegador merecen el mismo respeto. Además, todos sabemos las peloteras que montan, que no digo que no esten justificadas, cuando un sitio no soporta su navegador favorito. Siendo esta la situación es cierto que cada vez más empresas necesitan que su entorno de pruebas soporte también la utilización de este navegador.

De hecho la situación que he vivido recientemente es un equipo de desarrollo que tiene su aplicación completamente funcionando para Firefox y que la están migrando para que funcione con Explorer. No se que extraña situación les llevo a soportar primero el navegador con menor cuota de mercado pero las cosas son como son. Se plantean ahora la posibilidad de usar Visual Studio Team System for Testers Edition con herramienta para realizar pruebas web y pruebas de carga contra la web. Los que conocéis las posibilidades de VSTS for Testers en este campo seguro que no os sorprendéis de que se planten esta opción pues es una herramienta excelente para este tipo de pruebas y en general para gestionar el ciclo completo de la calidad en el desarrollo de una aplicación (tema sobre el que hablé en ExpoQA el año pasado).

La principal limitación, a priori, es que solo podemos grabar pruebas web usando Web Test Recorder que solo está disponible para Internet Explorer.

image

En este caso el problema era claro, a día de hoy la aplicación solo funciona con Firefox. Pero aunque no fuese está la situación, es cierto, que si nuestra aplicación debe soportar cualquier navegador parece natural que podamos realizar las pruebas de la misma usando cualquier navegador ¿no?. Así que guiado por la necesidad y la curiosidad me he puesto a buscar un camino para poder grabar los test web de VSTS for Testers desde Firefox. Y os voy a contar cual a sido la solución a la que he llegado… Que por cierto, en esencia, sería aplicable a cualquier otro navegador).

La solución al problema aquí expuesto pasa por utilizar Fiddler, herramienta de la que ya he hablado anteriormente en este blog, precisamente comentando su capacidad para grabar una interacción de nuestro navegador como un test web de Team System. Esta capacidad, junto a la posibilidad que Fiddler tiene para actuar como proxy transparente para cualquier navegador, nos abre la posibilidad de usar Firefox para grabar test web de VSTS for Testers.

El proceso es sencillo:

1) Descargar e instalar Fiddler herramienta totalmente gratuita e imprescidible

2) Configurar Firefox para que use Fiddler como proxy, para ello basta saber que cuando está arrancado Fiddler expone un proxy transparente en el puerto 8888

image

3) Ejecutar la interacción web que queremos grabar como test desde Firefox, veremos como Fiddler captura todo el trafico…

4) Guardar el resultado de Fiddler como un web test (archivo .webtest), que luego podremos incorporar a nuestro proyecto de test de VSTS for Testers para su ejecución o su inclusión como parte de un test de carga o de un tes guiado por datos.

image

A la hora de hacer tests de carga, bastará que configuremos el porcentajes de peticiones que estimamos van a venir desde Internet Explorer y desde Firefox cuando configuremos el test. Esto hará que, en el porcentaje determinado, el entorno de pruebas haga unas peticiones identificandose como Internet Explorer en unas ocasiones y como Firefox en otras.

image

No persigas tu cola…

tiovivoErase una vez un grupo de desarrolladores que leyeron un post en un blog y  abrieron los ojos a la realidad: estaban empezando a programar demasiado pronto.

Su resultados eran buenos, incluso acertaban casi siempre con las necesidades del cliente. Lo sabían porque desde que ‘conocían’ las necesidades del cliente hasta que le mostraban los resultados de su esfuerzo no pasaba nunca más de un mes, y el cliente, salvo cierto feedback menor y algunas cambios de cierta entidad estaba satisfecho.

Y cuando esto no ocurría, y el cliente, por lo que fuese, necesitaba cambios como su código era excelente, estaban entrenados para escribir rápidamente código, y su proceso de desarrollo no les exigia demasiada burocracia, esto no era ningún drama. Además las pruebas y la construcción automatizadas les permitían tener la confianza de hacer cambios e integrar nuevo código sin impactar gravemente sobre la calidad general de la aplicación.

Planificaban cada una de las iteraciones que abordaban con cierto detalle, pero sin demasiado análisis y diseño detallado, con una reunión de vez en cuando frente a una pizarra era suficiente para aclarar los problemas que surguian… y eso no podía seguir así. El post lo decía claro: «Estamos ante una nueva ola de desarrolladores que creen que usar las metodologías ágiles significa pasar por alto el análisis, el diseño y todo lo que esté lejos del código fuente». A nosotros nos pasa eso, pensó el equipo de la historia… nuestros resultados son buenos, pero podrían ser mejores. Debemos pensar más antes de escribir el código. Debemos iterar nuestros diseños…

Así que a partir de este momento vamos a mejorar nuestros diseños, debemos plasmarlos en papel, debatirlos, buscar diferentes soluciones. Debemos iterar nuestros diseños, es barato y al fin y al cabo ¡las iteraciones son un idea clave en todas las metodologías modernas!.

Por lo tanto, en lugar de juntarse simplemente en torno a una pizarra, ahora que tenían más tiempo y voluntad de analizar y diseñar, cada uno podría hacer su propio diseño, y luego discutir y consensuar la mejor aproximación. Y claro, decidieron, que después de esto, en otra iteración sobre la documentación de diseño, podrían analizar puntos fuertes y débiles de cada solución y luego, como es barato, total aun no han escrito código, podrían darle una nueva vuelta…

Esta vez, lo habían conseguido. No habían escrito código prematuramente. Habían consumido un tiempo bastante valioso, pero no pasaba nada. Tenían un diseño excelente, sin errores, revisado… nada podía fallar… bueno salvo lo de siempre, lo que siempre da problemas: el componente que no funciona como debe, el código que se vuelve inmantenible y que hemos de refactorizar, ese bug de la librería de creación de pdfs que nos cuesta dos días de quebraderos de cabeza, ese proceso de traspaso de datos que, a persar de su excelente diseño sobre el papel no da el rendimiento requerido… pero bueno, tenemos un gran diseño… Lo hemos cambiado eso si, en vista de los problemas que hemos tenido, pero anda que no era elegante oye, hay están los diagramas UML para demostrarselo a quien pregunte «¿pero que coño habéis hecho este sprint?» Analizar, Romerales, analizar…

Esta vez no iban a tener tiempo de hacer pruebas de carga, ni tiempo para fiabilizar el código, pero da igual, el diseño es tan bueno que seguro que esta vez no hemos introducido bugs, con todo el diseño que hemos hecho!!!

Iterar es un gran invento, sin duda, siempre que no se olvide para que se itera: para sacar conclusiones del pasado y planificar el futuro cercano. Algo de escasa utilidad cuando diseñas. Cuando diseñas, a menudo trabajas más con hipótesis que con certezas, y la única manera de validar esas hipótesis es implementándolas, testeando esa implementación y validándola con el cliente. Iterar sin ir adquiriendo conocimiento cierto, real y contrastable solo es perseguir tu propia cola… como hacen los cachorros. Sobre los diseños es, en la mayoría de los casos, es suficiente comentarles con otro miembro del equipo. Eso es suficiente iteración.

Pero claro, nos olvidamos de que los conceptos, los diseños y las soluciones no se ejecutan… y que el software solo es interesante por eso, porque se ejecuta.

La falacia es clara, si pensando un poco logramos hacer las cosas medio bien, pensando mucho las haremos excelentemente. En cinco minutos puedo tener un diseño aceptable, luego en cinco horas tendré un diseño excelente, parece ser el razonamiento correcto. El problema es que, en la ingeniería, del software hay miles de cuestiones que solo se resuelven cuando se realiza la implementación de la solución. Que tu arquitectura no da el rendimiento suficiente, por poner un ejemplo, es algo que a menudo solo descubrirás una vez que tengas una implementación.

Una implementación no tiene porque se un implementación definitiva, crear pequeños prototipos es a menudo imprescindible y de mucho más valor que simplemente ‘pensar’ un buen diseño, plasmarlo en papel y revisarlo exhaustivamente. Hoy por hoy los leguajes tipo python o ruby permite prototipar con gran facilidad.

No nos engañemos, ningún desarrollador del mundo escribe código sin pensar. Eso no pasa, no pasa porque es imposible que pase. Escribir código es algo que exige pensar. Ningún desarrollador, con un mínimo de experiencia, abordará el código sin diseñar, explicita o implícitamente. Y aquí es donde está la clave, aunque todo desarrollador diseña, no todo desarrollador lo hace explícitamente. Esta es la clave, hacer del diseño un proceso explicito, anterior a la codificación pero que siempre tenga como objetivo adentrarse en la codificación cuanto antes. Me vale escribir antes los test, o crear cuatro diagramas en una pizarra o un papel o si el problema lo merece reunirte con un colega o dos en torno a una pizarra… pero no debe nunca ser un proceso largo o poco ágil; no merece la pena.

Recuerda: algo de diseño es, la mayoría de las veces, suficiente diseño. Hay una gran diferencia entre no diseñar nada, y diseñar algo y diseñar en exceso. No diseñar nada es muy arriesgado. Diseñar en exceso, muy caro. Diseñar algo, lo más inteligente.

Siempre he desconfiado del jefe de proyecto que no ve nunca el código, del analista que no expresa los análisis con jerarquías de clases sino con cajitas, del arquitecto que no entrega esqueletos de soluciones sino power points… el código mueve el desarrollo, no los diseños.

Solo el software ejecutable muestra el avance de un proyecto. Lo que diferencia al desarrollo de software, de otras actividades humanas es que cada línea de código supone varias decisiones de diseño. En esas condiciones, no sirve de mucho el hacer mucho diseño a priori. Es mucho más efectivo implementar pronto y validar la implementación de manera temprana, continua y lo más automatizada posible.

Así que, parafraseando al autor del post que ha inspirado este: no creo que empezar a programar tarde mejore la calidad del código, del software o del proceso, exactamente, todo lo contrario…

Sitemaps y Asp.Net

Una característica que puede hacer que nuestros sitios web sean más amistosos a los ojos de los buscadores, es exponer un sitemap. Los sitemaps son archivos xml que publicados en nuestro sitio dicen a los buscadores cuando nuestras páginas cambian y cúal es su ubicación. Los sitemaps fueron lanzados originariamente por Google, pero ahora, casi todos los buscadores más populares son capaces de utilizarlo. La conclusión es que contar con un sitemap en nuestros sitios web puede mejorar bastante nuestra posición en los buscadores, o eso dicen ultimamente los expecialistas en SEO. Podéis encontra mas información sobre los sitemaps y el formato del archivo se sitemaps en www.sitemaps.org.


Recientemente he estado trabajando, a ratos sueltos, en la página web de Akiles Fisioterapeutas, el centro de fisioterapia que mi mujer ha abierto en Bilbao. Y una de las características que le he querido añadir es que tenga un sitemap. Podeís ver el sitemap en http://www.akilesfisioterapeutas.com/searchsitemaps.axd?sitemap=Navigation.


¿Pero como creamos el archivo sitemap de nuestros sitios Asp.Net? Podríamos hacerlo a mano, al fin y al cabo solo se trata de generar un archivo XML, algo relativamente sencillo usando el framework de .Net… o mejor aún podemos usar como base para crear el sitemap para los buscadores el archivo Web.Sitemap de Asp.Net de nuestro sitio web, que probablemente ya tengamos. Este es el camino que he seguido en la web mencionada.


Para seguir este camino nos apoyaremos en Asp.Net Futures (en concreto en la CTP de Julio de 2007), que nos permiete generar un sitemap para buscadores con mucha facilidad. Esta CTP proporciona dos clases: AspNetSiteMapSearchSiteMapProvider que permite generar nuestro sitemap desde un sitemap de Asp.Net ya existente, lo que es útil si las páginas de nuestro sitio no cambian a menudo y DynamicDataSearchSiteMapProvider, que nos permite generar el sitemap para los buscadores de manera dinámica.


El proceso es facil de realizar en ambos casos, siguiendo los pasos descritos en este quick start tendremos nuestro sitemap funcionando en pocos minutos para un sitio con páginas creadas dinámicamente o siguiendo los pasos de este post en el caso de contar ya con un sitemap de Asp.Net, como era mi caso.


La única complicación que sufrí fue que olvide copiar el assembly de Asp.Net Futures en la carpeta bin del sitio, un fallo de principiante que me dio algun quebradero de cabeza.

Titín III Campeón del 4 y medio y Silverlight

A ver… tenía que contar en mi blog que Titín III había ganando, a sus 38 añazos, la txapela del 4 y medio, dandome a mí, la alegria del año, en lo que a cuestiones deportivas se refiere. Los que me conocen ya saben que a parte de desarrollar software la pelota es otra de mis pasiones, e incluso no juego del todo mal.

Y es que déspues de perder, literalemente, la voz gritando en la semifinal, no podía, el de Tricio, dejarme sin esta alegria. Que harto mal lo pase cuando le vi perder la final de 2003 contra Nagore.

Para la final no hubo manera de encontrar entradas a pesar de los 110 eurazos del ala que había que soltar.

Pero esta vez la araña de Tricio tejio su tela en los cuadros alegres del frontón, agazapandose en el txoko, donde ha sido el dominador y tanto nos ha hecho disfrutar en los últimos tres lustros, y enredo a Barriola que a pesar de sus excelente cualidades físicas no pudo zafarse, pese a tener una magnífica reacción cuando parecia que Titín le iva a machacar (como sufrí 🙁 ).

Tiene merito lo del caracolero a sus 38 años, seguir en lo más alto de la pelota tras 15 años como profesional y lograr su primer título individual, algo que la pelota le debía este gran campeón desde que perdiese aquella mítica final de con el grandísimo Retegui.

… pero claro ya se que los que leéis este blog nos sois pelotazales sino geeks, así que que mejor que publicar un video, de los últimos tantos de la final que no los mejores, usando Silverlight Streaming.

El proceso de crear y colgar el video en SLS es simple, tal y como comenta Tin Sneath en su blog. Necesitaremos Microsoft Expression Encoder y Microsoft Media Encoder (este último gratuito) para crear un video en el formato adecuado. El proceso es simple y sencillo. Más simple aún si usamos Microsoft Expression Encoder, que además de codificar adecuadamente el video, nos generará todos los archivos y el javascript necesarios. Solo le veo una pega a Microsoft Expression Encoder, y es que no es capaz de coger videos desde la pantalla, habrá que usar Camtasia como nos sugería el amigo Alarcón.

Expression Encoder

Para incluir el video en el post, basta con usar el siguiente código HTML que he encontrado en el blog de la gran Catherine Heller:

<iframe src=http://silverlight.services.live.com/invoke/AccountID/AppName/iframe.html
     scrolling=»no» frameborder=»0″ width=»500″ height=»400″></iframe>

A los que se os haga un poco pesado todo este tema, deciros que James Clarke ha creado un plugin para Windows Live Writer que automatiza todo el proceso. Incluso podemos publicar directamente los videos desde el propio Expression Encoder a SLS usando este plugin. Este post le he hecho ‘a manopla’ pero los proximos que haga con video será con el pluging… ya os contaré entonces.

La verdad es que SLS es una excente plataforma para publicar video post, teniendo en cuenta que un video de captura de pantalla a 100 kps, que es sufieciente, de unos dos minutos ocupa poco más de un mega y que podemos subir a SLS videos de hasta 22 megas, podemos hacer videos de más de media hora para nuestros post. El almacenamiento es de hasta 4Gb que dan mucho de si… Además según comentan oficialmente estas condiciones van a ser como mínimo mantenidas cuando el sitio deje de ser beta.

Un efecto que no me gustaba es que cuando alguien visitaba el post el video se ponia automaticamente en funcionamiento, lo que podía resultar un poco molesto si tenemos el volumen alto, pero lo he podido corregir siguiendo las instrucciones de este otro post de James Clarke.

Bueno aquí va el resultado de mis pinitos con SLS. La calidad del video no es muy alta, pero eso es culpa de la fuente original. Aupa Titín III, ahora a por el campeonato de parejas!!!!

Anda que estando Plain Concepts lleno de WPFeros y Silverligtheros, y diseñadores y demás calaña de esa de los medios y los dibujines que sea yo el primero que publica un video en su blog… deberiaís sentiros dolidos en vuestro urgullo geek… ;P