La experiencia de SDET en Redmond: Ahora en Channel 8!!

Se ha publicado un nuevo vídeo en Channel 8 en el cual hablamos sobre la experiencia de ser Software Development Engineer in Test en un equipo de producto en MS, además, al tratarse de una entrevista a mi manager, se alterna este tema con la experiencia de Internship y otros temas bastante interesantes.


Podéis encontrarlo aquí:


http://channel8.msdn.com/Posts/Interns-at-Microsoft-the-testing-modeling-experience/


Un saludo! [:)]

Office 2007 Ultimate para estudiantes por 52 euros!!

Leeis bien, Microsoft ha lanzado una promocion para que los universitarios de nuestro pais puedan adquirir licencias de Office 2007 Ultimate por un modico precio!


Podemos adquirir una licencia perpetua por tan solo 52 euros, y si lo que queremos es una licencia por 12 meses, el precio baja a los 18 euros!!


Esta promocion estara disponible via web para estudiantes de 45 universidades diferentes. Para mas informacion podeis consultar la web de la promocion: www.daelgolpe.es


Cool!! [:D]

El "status social" de un empleado de Microsoft Corp en Redmond

Hola amig@s,


Llevaba un par de meses experimentando la sensación de ser bien tratado por parte de todo el mundo en EEUU y, en especial, en Redmond, cuando mi interlocutor era consciente de mi empleo en Microsoft. Los ejemplos son tan variados como el pedir comida en un restaurante cercano al Campus, coger un taxi o “shuttle” para desplazarte de un edificio a otro, pasar el control de inmigración al entrar o salir del país, hacer gestiones en el banco… Toda esa serie de cosas son comprensibles, y tampoco tienen nada de emocionante. No obstante, me acaba de pasar algo un tanto fuera de lo normal (al menos para mí).


Eran alrededor de las 10 de la noche en Redmond y tras cenar en casa me he dispuesto a volver a mi despacho a trabajar y terminar asuntillos pendientes… De modo que me monté en mi coche y me dirigí a nuestro Campus. Hacia la mitad del trayecto, apareció en mi retrovisor un coche de la policía de Redmond, el cual me siguió durante aproximadamente un kilómetro hasta que me detuve en un semáforo en rojo. En ese momento, encendió las luces rojas y azules y me hice señas para que me detuviera. Cosa que hice, por supuesto. El agente se bajó de su coche y caminó hacia el mío. El diálogo fue algo parecido a esto (lo que recuerdo y voy traduciendo del inglés):



Agente: Buenas noches


Yo: Buenas noches, ¿qué sucede?


Agente: He observado que su matrícula está caducada. ¿Podría mostrarme la documentación de su vehículo, su carnet de conducir y su identificación?


Yo: Por supuesto, aquí la tiene.


Agente: (Poniendo cara rara al ver un montón de folios de Avis, un pasaporte español y un carné de conducir sellado en Alicante) ¿Este coche es suyo?


Yo: No, es de Avis. Lo tengo alquilado desde hace algo mas de dos meses.


Agente: La matrícula es de California, ¿lo alquiló usted allí?


Yo: No, me lo dieron en el aeropuerto de Seattle.


Agente: La matrícula está caducada, debería haber acudido a la oficina de Avis para actualizar dicha información. ¿De dónde es usted?


Yo: De España.


Agente: ¿Cuánto tiempo lleva usted aquí? (A estas alturas de la conversación, habían aparecido dos coches patrulla más, uno en la parte de detrás y otra en la delantera de mi coche).


Yo: Desde principios de Julio, como puede ver usted en mi visado de trabajo.


Agente: ¿Para qué empresa trabaja usted?


Yo: Microsoft. La gestión del alquiler del vehículo corrió a cargo de mi empresa.


Agente: Déjeme ir a mi vehículo a verificar sus datos (se fue a su vehículo y habló por espacio de un par de minutos con los otros 3 agentes que había presentes… Después, volvió con paso firme y decidido hasta mi coche).


Yo: ¿Está todo en orden agente?


Agente: Sí, perdone la confusión. Cuando tenga ocasión, notifique a la persona que gestionó el alquiler que la matrícula ha expirado. Conduzca con cuidado y tenga una buena noche.


Yo: Gracias, usted también.


 Creo que sobran los comentarios [:)]

Comida a cambio de bichos

A menudo el largo y complejo proceso de creación de software genera resultados con algún que otro fallo. Está claro, nada ni nadie es perfecto. En ingeniería del software, a los fallos en el código se les denomina “bug”.


¿De dónde proviene este término?


“Bug” en inglés significa “bicho”. Al proceso de arreglar fallos del software se le denomina “debug”, que literalmente significa “quitar bichos”… Esta expresión es bastante literal en sus orígenes…


El término se adoptó cuando allá por 1945 Grace Murray Hopper se encontró atrapado uno de estos bichos en uno de los relés del computador Mark II, lo cual hacía que este no funcionase bien. Así que, para quien dude de la importancia de las mujeres en el mundo de la Informática o afirme que hay pocas, que sepa que a una de ellas debemos uno de los términos más importantes de la ingeniería de software.


Lo que poca gente sabe es que este “bug” sigue existiendo en el Museo Nacional de Historia Americana del Instituto Smithsonian, ya que esta mujer lo pegó en una de las hojas del logbook, del computador, que usaba para anotar todas las incidencias que observaba. Aquí lo tenemos:


Bug


 


 



Desde entonces, mucho ha cambiado el mundo de la informática y las formas de trabajar. No obstante, sigue siendo una labor fundamental el encontrar y solucionar estos fallos. Especialmente para un Ingeniero de Software de Pruebas, justo la posición que yo ocupo en Microsoft.


Es una de mis tareas diarias el esforzarme por encontrar hasta el más mínimo e insignificante fallo, para arreglarlo y notificarlo al resto del equipo. Mi trabajo no es individual, en mi equipo hay otros quince profesionales dedicados a esta misma función.


De vez en cuando, tratamos de estimularnos en nuestro trabajo, convirtiéndolo en una especie de reto o competición entre nosotros. Y eso fue lo que hicimos a finales de la semana pasada. Organizamos una “caza de bichos”. Una especie de competición de 5 horas de duración, a ver quién era capaz de encontrar más.


Además, es obvio, los fallos pueden ser “pequeños” fallos, “medios”, “importantes” o “catastróficos”, por así decirlo. De modo que a cada una de esas categorías le dimos una puntuación (Catastrófico:4, Importante: 3, Medio: 2, Pequeño: 1).


Al final de la competición, a eso de las 7 de la tarde, teníamos un generoso catering de comida oriental esperándonos en una sala de reuniones de nuestro edificio, para todos los que habíamos participado. Allí pudimos intercambiar impresiones y relajarnos un poco después de acribillar bichos durante 5 horas.


Ya sólo me queda comentar que quedé en una honorable (al menos para mí) tercera posición de entre los 15 participantes. En zona Champions como diríamos los amantes del fútbol…


Fue, en definitiva, un día muy divertido y diferente. Como casi todos por aquí

El modelo de desarrollo software en Microsoft

A menudo cuando vemos un gran edificio nos preguntamos cómo lo habrán construido. Cuando vemos las pirámides de Egipto nos asombra conocer los métodos que se emplearon para levantarlas, la gran cantidad de gente involucrada en este proceso “faraónico”.De la misma forma, yo muchas veces me hago la misma pregunta acerca del software.

Ahora estoy teniendo la suerte de ser parte activa en este gran proceso. En mi experiencia actual, el producto con el que más relación directa tengo es BizTalk Server. Para los que no lo conozcáis, BizTalk Server es una tecnología de servidor cuya misión es coordinar todos los servicios de red existentes en un entorno empresarial, algo que se conoce como “orquestación de servicios”.

Dicho con un ejemplo llano, imaginad una rotonda en la que confluyen 7 autopistas, totalmente saturadas de tráfico. BizTalk Server se encargaría de decidir a qué vía da prioridad en cada momento, según lo saturada que esté, entre otros criterios, también se encargaría de optimizar el proceso; es decir, conseguir que estemos el menor tiempo posible metidos en el atasco. Y, por supuesto, que no se produzca ni una sola colisión o choque entre dos vehículos.Para desarrollar este producto, en un cálculo aproximado y rápido, os puedo decir que trabajamos unas 250 personas. Cada una de estas personas tiene una misión diferente, unas virtudes diferentes y una visión particular sobre qué características debería y no debería tener la próxima versión del producto. ¿Cómo se coordina todo esto? Se hace uso de algo de lo que ya os hablé en alguna entrada anterior: los roles en el desarrollo del software. Los roles que existen actualmente en mi equipo, y en la mayoría de equipos de desarrollo en Microsoft ya que es un modelo que aporta muchas ventajas respecto a otros y que se está convirtiendo (si no lo es ya) en un estándar dentro de la empresa (Microsoft Solution Framework, para quien quiera investigar más sobre ello), son los siguientes:

Roles_2


Product Manager: Es el nexo con el cliente, maneja sus expectativas y se encarga del lanzamiento y la publicidad, demostraciones, etc. Es muy parecido al rol de Jefe de proyectos de una consultora clásica.

Program manager: Es más técnico, se encarga de que el proyecto se concluya y se entregue al cliente. Su misión es asegurar que se va avanzando según lo previsto (es lo más parecido a un analista, que podemos encontrar en el modelo clásico de las grandes consultoras) 

 

Developer: Se encarga de desarrollar las aplicaciones dentro de los requisitos que ha marcado el analista y de las restricciones globales del proyecto. Algunos ejemplos de estas restricciones son:              

              •      Que el resultado sea monitorizable


                        Rendimiento en unos rangos

                        Probado para el volumen de datos esperado                                   

                        Técnicamente correcto

Tester : Se encarga no sólo de buscar errores, sino además de garantizar que el diseño funcional está alineado con las expectativas del cliente, vamos con el documento de visión.

Release manager : Se encarga de asegurar que el resultado va a poder ser desplegado en un sistema real, diseña el plan de puesta en producción y lo ejecuta. Este trabajo no se realiza sólo al final del proceso, además de las versiones externas, es decir versiones que estén suficientemente libres de errores, sino que además pueden haber releases internas que también hay que desplegar y probar.

User experience: Es el responsable de lo que tiene que ver con el usuario final, lo que le afecta al usuario final, que los interfaces sean amigables y comprensibles, que el rendimiento sea aceptable, etc.

 

Arquitecto :  El arquitecto de software se encarga de que las piezas de software encajen y de que se elija la mejor tecnología para resolver cada uno de los problemas concretos. También es el responsable de servir de enlace entre los departamentos de TI y de desarrollo.

 

Con todo esto, la infraestructura interna para llevar a cabo el proceso de coordinación, la comunicación dentro del proceso y otra serie de factores, podréis imaginar que es bastante compleja.Pero nunca pensé que pudiera ser fácil, estoy en Microsoft, la empresa líder mundial en software, con productos muy variados: desde sistemas operativos como Windows 9x, XP, 2000, 2003 Server o Vista hasta bases de datos como SQL Server, desde tecnologías y servicios para la web como Windows Live hasta aplicaciones de escritorio como Office, desde aplicaciones de mensajería instantánea como el Messenger hasta completos entornos de desarrollo como Visual Studio, sistemas para PDA’s… Podría seguir, pero no quiero aburriros.Tan sólo quería dejar patente lo mucho que se aprende trabajando aquí, y el contínuo desafío, motivación y esfuerzo por la autosuperación que supone trabajar en un nº1.

Feliz Lunes!

Lenguajes generales vs Lenguajes específicos

A menudo utilizamos lenguajes de alto nivel (C#, VB.Net, Java…) para realizar consultas sobre colecciones o fuentes de datos, por ejemplo, ficheros XML. ¿Estamos haciendo “lo correcto”? Resulta muy cómodo trabajar sobre una API o conjunto de clases de manejo de este tipo de datos (XMLReader o XMLWriter por ejemplo). Cada proyecto es un mundo, y la decisión de adoptar un lenguaje u otro depende de muchos factores, no sólo de éste, por tanto, no voy a contar aquí ninguna verdad categórica ni nada por el estilo (lo siento, jeje). [:)]


No obstante, hay una serie de criterios en lo referido a estas funciones en concreto que sí nos sirven, llegado el momento, para evaluar qué planteamiento nos conviene más.


Por ejemplo: ¿Por qué utilizar un lenguaje específico para un cierto dominio de datos (como las consultas sobre ficheros XML, por seguir con el ejemplo) en lugar de un lenguaje de propósito general? Hay dos razones fundamentales: Facilidad de uso y rendimiento.


Hablando sobre la facilidad de uso, los lenguajes de propósito general ofrecen una serie de ventajas… Tienen mayor capacidad expresiva, nos permiten expresar ideas complejas con pocas líneas de código. Esto deriva, por supuesto, en una mayor productividad del programador.


Por el contrario, los lenguajes de dominio específico te permiten trabajar directamente con dicho dominio (XML por ejemplo). En el caso de lenguajes de propósito general, el uso de ficheros XML suele realizar a través de API’s o de objetos proporcionados por el lenguaje para leer/escribir este tipo de ficheros; mientras que un lenguaje específico para realizar consultas sobre XML (como XQuery) te permiten realizar operaciones de consulta sobre estos datos de una forma mucho más potente, de modo que una simple query de una línea en este tipo de lenguajes equivale funcionalmente a decenas de líneas en un lenguaje más general.


Si hablamos sobre el rendimiento de unos y otros, hay tres grandes razones por las que podríamos afirmar que los lenguajes específicos de consulta superan a los de propósito general. La primera de ellas es que los lenguajes específicos suelen estar optimizados para realizar ese tipo específico de operaciones. Los lenguajes de propósito general deben tener un rendimiento aceptable para una gran variedad de operaciones, mientras que un lenguaje de consulta sobre XML se centra en optimizar este tipo de operaciones. Este planteamiento puede acotar su funcionalidad, pero incrementar su rendimiento.


La segunda razón es que los lenguajes de propósito general suelen realizar este tipo de operaciones a través de API´s. Esta abstracción suele implicar que estamos trabajando sobre una serie de estructuras que, realmente, desconocemos. Al fin y al cabo, la abstracción es ignorancia selectiva. Esta ignorancia supone, no obstante, un gran beneficio a la hora de simplificar el diseño.  Pero, quizá, nos interesaría conocer esa implementación, para poder optimizar nuestro diseño. Por el contrario, un lenguaje de consulta “es” la abstracción, cuando ejecutamos nuestra consulta, tenemos acceso total a todas las estructuras internas de datos.


La tercera razón y, para mí, la más revolucionaria es que los lenguajes de consulta poseen menos restricciones. Un lenguaje secuencial debe hacer “lo que tú le dices que haga” en el orden que tú impones. Sin embargo, en un lenguaje de consulta, simplemente especificas “qué quieres obtener”, y la forma de obtener este resultado es transparente al programador. Puede ser el resultado de una búsqueda secuencial, puede ser el resultado del acceso a una caché de datos si ya habíamos accedido previamente a dichos datos… La cuestión es que estamos dejando en manos del lenguaje la decisión de cómo realizar dicha consulta para que sea óptima. Esto libera de muchos quebraderos de cabeza al programador.


La diferencia entre ambos tipos de lenguajes se puede resumir asociándolos a los términos “declarativo” y “descriptivo”:


1.       Un lenguaje de consulta es un lenguaje declarativo: Indicas qué quieres obtener como resultado, pero no especificas el modo de obtenerlo.


2.       En un lenguaje secuencial, indicas qué y cómo quieres obtenerlo, es un lenguaje descriptivo.


Este matiz es un tanto sutil a la hora de expresarlo con palabras, pero implica diferencias sustanciales a la hora de programar. [:)]

Presente y futuro de LINQ

Siguiendo con mi idilio de esta semana con LINQ, voy a haceros un repaso de la situación actual y líneas futuras de evolución del mismo. [:)]


Como ya todos sabéis LINQ se encuentra todavía en fase beta. Las primeras versiones vieron la luz en Septiembre del 2005 (qué rápido pasa el tiempo). Desde entonces, ha evolucionado desde ser un simple add-in para Visual Studio 2005 hasta convertirse en parte intrínseca de la última versión del .Net Framework (3.5) y de la nueva versión del IDE, Visual Studio 2008.


Hablando del futuro, hay cosas que ya podemos afirmar sobre la versión estable de LINQ. Sabemos que incluirá directamente soporte para algunos dominios de datos:




  1. LINQ sobre objetos


  2. LINQ sobre ADO.Net, que a su vez supone el soporte para las siguientes tecnologías: LINQ para SQL, LINQ sobre entidades y LINQ sobre DataSets.


  3. LINQ sobre XML.

No obstante, LINQ se puede extender para soportar otros dominios. Algunas extensiones podrían ser LINQ sobre Sharepoint (algo de lo que ya se ha hablado por geeks), LINQ sobre servidores de Exchange y LINQ sobre OLAP, entre otras muchas posibilidades… En realidad, alguna de estas posibilidades pueden ser ya directamente implementadas haciendo uso de Reflection combinado con LINQ sobre objetos.


Otra posible vía de evolución de LINQ es LINQ sobre SQL. Ya que, si bien las versiones beta sólo soportan bases de datos en SQL Server, podemos implementar proveedores de datos que nos permitan manipular cualquier base de datos relacional.


Además de todas estas posibilidades, indirectamente, LINQ puede suponer una revolución en la forma en que desarrollemos aplicaciones. ¿Qué? Bueno, es cierto que LINQ en sí mismo no supone un cambio en la arquitectura de una aplicación puesto que su objetivo es proporcionarnos una serie de herramientas para mejorar nuestros desarrollos permitiendo la adaptación a arquitecturas diversas, pero también lo es que LINQ puede llegar a afectar ciertas partes críticas de soluciones con arquitecturas de N-capas. Por ejemplo, imaginemos el uso de LINQ en un procedimiento almacenado de SQL-CLR, donde se produciría una transferencia de nuestra query integrada en el lenguaje al motor de SQL, en lugar de utilizar sentencias de SQL propias.


Podemos concluir resumiendo todo este rollo en que hay una gran variedad de posibles evoluciones implementables sobre LINQ, y no debemos olvidar que SQL es un estándar ampliamente aceptado y adoptado por lo que no se puede sustituir por otro así como así, por cuestiones de rendimiento. De todos modos, LINQ es un paso interesante en la evolución de los lenguajes de programación actuales. El carácter declarativo de su sintaxis hace que podamos considerar el uso de LINQ para otros propósitos diferentes al acceso a datos.


En esta última línea, existen proyectos de investigación como PLINQ (Parallel LINQ), que como su propio nombre indica se dedica a investigar acerca de las posibilidades de paralelización de código que se nos abren mediante el uso de LINQ en nuestros desarrollos. Se pueden ofrecer otros muchos servicios adicionales a los ya comentados.


Adentrarse en el conocimiento de LINQ hoy en día puede ser algo bonito e interesante, pero puede llegar a convertirse en imprescindible de aquí a un tiempo… [:)]


¿Aún no te has animado a probarlo?

Estoy leyendo "Introducing Microsoft LINQ"

Llevaba tiempo oyendo hablar sobre LINQ, en blogs, en charlas como las del DevDay, grupos de usuarios… Había leído bastantes artículos técnicos al respecto tanto en internet como en distintas ediciones de DotNetManía. Desde las primeras CTP’s me he dedicado a instalarlas (como add-in de Visual Studio 2005) y hacer mis pequeñas aplicaciones que me sirvieran para aprender nociones básicas al respecto. Y por supuesto a probarlo ahora que lo tenemos disponible en Visual Studio 2008 (Orcas para los nostálgicos o los amantes de los CodeNames). Incluso, ya en Redmond, he tenido que lidiar con LINQ en alguno de mis proyectos, sacando información de debajo de las piedras…


Todo eso está muy bien, sí. Pero… nada como un buen libro que recopile (y amplíe) mucha de esta información de fuentes diversas, ¿verdad?


Pues por fin esta semana ha llegado Papá Noël a mi despacho y lo ha puesto en mis manos, y lo estoy devorando como hacía tiempo que no devoraba un libro técnico (concretamente, desde hace unos 6 meses que devoré el “WPF Unleashed” de Adam Nathan).


Definitivamente, “Introducing Microsoft LINQ” es un libro que recomiendo para todos aquéllos que quieran aprender LINQ desde cero, y también para aquéllos que, como yo, han ido aprendiendo cosas “a salto de mata” (como diría un gran Maestro mío).


“Introducing Microsoft LINQ” no sólo nos habla sobre las nociones básicas y bondades de esta nueva tecnología (cosas como la sintaxis, los tipos de operaciones que podemos realizar, las distintas fuentes de datos que podemos conectar con LINQ…), basándose en la CTP de Mayo de este mismo año.



No, es más que eso, también nos hace un repaso de las novedades de C# 3.0 y de VB 9.0, no sólo relacionadas con LINQ, sino en conjunto. Además de todo este contenido, me parece fundamental la forma en que se presenta el mismo. Las explicaciones son muy didácticas y los ejemplos muy aclarativos y representativos del potencial de LINQ.


Definitivamente, es un libro que recomiendo. Ya me contaréis vuestras impresiones al respecto del mismo [:)]

Spain is different!!

Hola,


Aprovechando el día libre gracias a la festividad del Día del Trabajador (que fue el pasado 1 de Septiembre aquí en EEUU), os dejo una lista que hemos recopilado de facebook (www.facebook.com), un lugar donde poder conocer gente con aficiones, intereses… similares a los tuyos.


Esta lista refleja un poco el sentir de los españoles aquí, cosas que nos chocan de la cultura americana, y cosas que a los americanos les chocan de nuestro país. Espero que os guste tanto como a nosotros nos ha gustado (es tan graciosa como real):


1.- Te parece perfectamente aceptable añadir fanta o Coca-Cola al vino tinto.


2.- Te desespera la hora a la que cierran los pubs por las noches (entre las 12 y las 2 de la madrugada). Incluso te parece que cierran a la hora a la que deberías salir de casa…


3.- Sabes lo que es un “botellón”.


4.- Te parece bien opinar sobre el aspecto de los demás.


5.- No darle “dos besos” a alguien que te acaban de presentar te parece de mala educación.


6.- En el Messenger escribes “jajaja” en lugar de “hahaha”.


7.- El aceite de oliva te parece imprescindible en casi todas las comidas. Incluso en una tostada…


8.- Te sorprende que los descansos y publicidad en la TV duren menos de 15 minutos.


9.- A menudo olvidas decir “please” cuando pides algo… ¿Acaso no se da por supuesto por el tono de tu frase?


10.- Te encanta “dar toques” con el móvil para comunicarte con alguien. También odias explicar en inglés lo que significa…


11.- No consideras las pipas de girasol una comida sana, son sólo algo para picar.


12.- Sabes perfectamente lo que es un pijo, y cómo identificarlos.


13.- Todas tus frases contienen al menos una de estas expresiones: “bueno”, “vale”, “venga”, “pues nada”…


14.- Sabes lo que significa “resaca”, y tenías al menos una por semana cuando vivías en España.


15.- Sabes cómo comer “boquerones”.


16.- Comes más tarde de las 14h y no te entra en la cabeza tener que cenar antes de las 9.


17.- Estás convencido de que no vas a encontrar tiendas abiertas entre las 2 y las 4-5 de la tarde. ¿Qué pasa con la siesta?


18.- Si alguien se mete con tu madre, más le vale correr…


19.- Sabes lo que es, y cómo cambiar, una bombona de butano. Y, por supuesto, echas de menos ver el camión del reparto.


20.- Eres, o has sido, seguidor de “Los Serrano” o de “Aquí no hay quien viva”.


21.- Eres incapaz de beber una cerveza que no esté fría.


22.- El hecho de que todos los hombres, o mujeres, de una misma familia tengan el mismo nombre de pila no te sorprende. Es más, entra dentro de toda lógica.


23.- Estás acostumbrado al sonido de los ciclomotores. ¿Por qué aquí no se oye ninguno?


24.- Sabes la diferencia entre “co…” y “cajones”, entre “tener calor” y “estar caliente”, entre “bacalao” y “bakalao”…


25.- Un domingo por la mañana desayunas antes de irte a la cama, no recién levantado.


26.- Te parece perfectamente normal tomar un par de cañas por la mañana. ¿Qué hay de malo?


27.- El suelo de los bares es un lugar ideal para tirar servilletas usadas. ¿Por qué usar una papelera?


28.- Sabes perfectamente que la “ensaladilla rusa” no tiene nada que ver con Rusia.


29.- Eres el único de tu grupo de amigos al que le hace gracia ver por la calle un Mitsubishi Pajero.


30.- Tienes amigos con nombres como José María, Pepe, Manolo… incluso Inmaculada Concepción.


Parafraseando al Maestro Sabina: “En Alicante y en Washington, en Vancouver y en Redmond, mi Atleti, mi España y yo, semos diferentes…”


Feliz comienzo de semana

Microsoft Channel 8: Your videos, our passion!!

¿Habéis oído hablar de Channel 8? En anteriores entradas os hablé de este tema, aunque obviando que lo conocíais (craso error por mi parte)… Aunque gracias a los posts de mis amigos Ethel y Jorge, todo queda mejor explicado… [:)]


Channel 8 es el nuevo canal de Microsoft, hecho por estudiantes y para estudiantes. Se trata de un espacio donde los estudiantes de todo el mundo, especialmente los Microsoft Student Partners, podremos expresar nuestra pasión por la tecnología en forma de vídeos con presentaciones técnicas, debates, entrevistas, reportajes sobre los eventos más importantes de Microsoft… También se están dando los pasos para convertirlo en una comunidad mucho más amplia, que incluya blogs, foros y recursos en general donde aprender sobre las últimas tecnologías de Microsoft, de una forma dinámica y divertida.


El canal nació hace algo más de un mes, y comenzó a emitir contenidos con motivo de la Imagine Cup. De ahí que la mayoría de material que hay por ahora en la web sea sobre eso… Estamos trabajando para crear nuevos y variados contenidos, tanto en inglés como en español, así que os recomiendo que sigáis de cerca nuestros pasos… Tengo la gran suerte de formar parte del equipo de Channel 8 desde los primeros pasos del canal, y prometo que vamos a dar mucha guerra [:D]



Y por último… Si eres estudiante y deseas colaborar en este bonito y ambicioso proyecto… Si piensas que tienes cosas que contar y compartir delante de una cámara, que el mundo entero debe conocer… ponte en contacto conmigo y cuéntame esas ideas, te estamos esperando!!


Y al resto de gente que desee conocer esta iniciativa un poco más de cerca… Deciros que os esperamos en el Tech-ed de Barcelona (5-9 de Noviembre), dando cobertura completa del evento, entre otras muchas sorpresas que estamos preparando! [6]