Proyecto piloto TDT: parte 4: fase 2

Título Del oficio.

Texto "El sector de la informática, tan vivaz e innovador en el
trabajo pero tan dormido en la defensa de sus intereses..."
(Little Bighorn y las ingenierías informáticas).

Hace unas semanas recibí un correo diciendo que la carrera
de informática, carrera docente se entiende, iba a
desaparecer. Por ello se animaba a secundar las
movilizaciones convocadas.

El germen creo que estaba en la postura del PSOE a la hora
de rechazar una iniciativa del PP respecto a una proposición
no de ley en comisión parlamentaria. En ellas el PP insta a
"crear las correspondientes fichas de grado y máster donde se
reflejen las competencias de los titulados en ingeniería
informática, dando así igual trato que al resto de las
ingenierías". Más allá de lo que esto implique, tras ver los
videos de la comisión lo único que me quedó claro es que
nuestros representantes actúan y hablan de forma cuando
menos curiosa.
El diputado del BNG apoya al PP quizás porque, como indica él
mismo, es paisano del diputado popular. Lo felicita y suscribe
su iniciativa con el único argumento de que de seguir las
cosas así la titulación desaparecería. No razona si esto es
bueno o malo, parece dar por sentado que el que desaparezca
una titulación es malo. En este caso coincido con él pero no
parece razonar más su postura.
Tras la renuncia de algunos grupos a intervenir, la diputada
de CiU toma la palabra. Tras realizar un panegírico de la
profesión informática empieza a hablar "En este marco del
espacio europeo superior..." y a partir de ahí no entiendo ya
casi nada salvo que es una especie de sí pero no y que el no
es para lo que propone el PP: perdón, la abstención, porque
como he dicho es un sí pero no.
Finalmente habla el diputado del PSOE, flanqueado por una,
supongo, compañera de partido que asiente su intervención
en silencio y que, además, tiene problemas con su chaqueta.
Dicho parlamentario también alaba al sector informático y
luego empieza a citar ofertas de titulaciones o masters como
el de "biología computacional" y otros. Tras varios minutos de
conversación null, en mi opinión ni cierta ni falsa, da por
cerrada su argumentación.
Tras esto se vota y se rechaza la proposición no de ley.

Esta claro que si hay un problema con el sector, en las Cortes
no me lo han aclarado. Me llegó entonces un enlace de un
blog en el que se trata la cuestión: ¿qué pasa con la
ingeniería informática? Y leyéndolo es cuando empecé a tener
una visión más clara del bosque formado por los árboles que
arriba he descrito.

En todo esto el tema que más me interesa es el de si la
profesión informática debe estar regulada o no. En mi opinión
no es ésta una pregunta a responder de forma aislada sino
teniendo en cuenta el contexto laboral.
Esto es: ¿por qué hay que regular unas profesiones y otras
no? ¿Por qué, de hecho, hay profesiones reguladas y otras
no?
Un argumento suele ser el que las profesiones que están
reguladas se dedican a actividades que por su dificultad o
implicación deben tener algún tipo de control o de garantía de
que quienes la realizan están capacitados para ello. Los
ejemplos habituales son los siguientes: los planos de un
edificio deben estar firmados por un arquitecto para
garantizar su seguridad, habitabilidad, etc. Una operación
debe ser realizada por un médico para garantizar su éxito,
etc.
¿Y un proyecto informático no? Muchas personas en estos
casos realizan el siguiente razonamiento: programar es fácil,
luego no hace falta regular dicha actividad. Aparte de que la
realización de un proyecto informático no es sólo codificar,
podría decirse que sí que programar ciertas cosas, por
ejemplo una macro de Word (y depende cuales, os lo
aseguro) es fácil pero también lo es aplicar mercromina a una
herida y colocar encima de ella un apósito pero nadie llama a
eso "intervención quirúrgica".
Por otro lado es curioso como para realizar ciertas actividades
que no considero triviales no se necesita más que pasar unas
pruebas o incluso sólo tener la intención de realizarlas: y si no
piénsese en que para opositar a plazas de policía o alistarse
en las fuerzas armadas se necesita acreditar pocas aptitudes.
Y no creo que estas profesiones sean menos críticas o más
fáciles que desempeñar que todas las aquí descritas.

Otro tema que ha salido a relucir con esta polémica es el del
intrusismo, que es la otra cara de la moneda de lo antes
expuesto: puesto que no es necesario acreditarse de alguna
forma para ejercitar la profesión de informático, cualquiera
puede hacerlo.
A este respecto voy a contar mi experiencia: cuando
coordinaba un equipo de desarrolladores, solicitamos de una
empresa de servicios un perfil de programador. Dicha
empresa, que ya nos había proporcionado anteriormente
personas que cubrieron satisfactoriamente nuestras
necesidades no envió el currículum de su candidato. El mismo
era licenciado en Farmacia y había realizado un curso de
varios meses de programación en Java. Teníamos dos
opciones: rechazarlo a priori o confiar en nuestro proveedor y
ver qué tal trabajaba esa persona. Resultó que era lo que
necesitábamos: un programador que realizaba a conciencia su
trabajo. Acertamos: no nos importó el pedigrí del candidato
sino sus resultados.

Meses más tarde mi rol cambió y era analista en un proyecto
internacional con tres equipos de desarrollo situados en
España, Argentina y los Estados Unidos respectivamente.
El project leader del mismo era un estadounidense cuya
formación era en... ¡música! El recuerdo que tengo es que
sabía orquestar muy bien al equipo, combinando
idiosincrasias y manejando ritmos.
En la actualidad me encuentro trabajando con colegas que en
su mayor parte son titulados en telecomunicaciones y sigo
aplicando el mismo criterio: no me digas de dónde vienes sino
vamos a ver cómo podemos trabajar juntos.

Creo que uno de los problemas de la informática es la forma
en que se percibe: algo de lo que ya hemos tratado en estos
artículos.
Y otro el de la ignorancia de lo que un titulado en informática
tiene que estudiar para titularse, ya sea como
ingeniero técnico o superior.
Podríamos hacer un pequeño test: ¿cuáles de estas
asignaturas aparecen en los planes de estudios de dichas
carreras?
 Álgebra
 Algoritmia
 Contabilidad Analítica
 Economía de la Empresa
 Estadística
 Estrategia y Política de Empresa
 Financiación e Inversión
 Inteligencia Artificial e Ingeniería del Conocimiento
 Introducción a la Mercadotecnia
 Organización de Empresas
 Planificación y Gestión de Proyectos Informáticos
 Robótica Industrial
 Simulación Informática
 Sistemas de Información Contable
La respuesta es: todas.

Mi conclusión es la siguiente: la profesión informática está
presente en todos los ámbitos de la vida actual. Aún así la
ignorancia acerca de los conocimientos que deben adquirirse
para ser un titulado en la misma es más que notable. Y si uno
ignora qué conocimientos tiene su empleado, difícilmente
podrá saber utilizar todo su potencial. Por otro lado no creo
que haya que blindar el terreno profesional para que sólo los
que tengan carnet de socio puedan acceder al club de la
informática. Pero esto debería ser una regla general a todo el
mercado laboral y no sólo a la informática: o todos o ninguno.

Finalmente una pequeña autocrítica: los informáticos estamos
habituados a trabajar con máquinas que únicamente atienden
a programas, que son la formalización unívoca de unos

requerimientos. E intentamos trasladar esa lógica del
verdadero/falso a las relaciones humanas, y por ende
laborales, comerciales... En esto debemos aprender que las
cosas no son blanco o negro o que, si lo son, puede que no
logremos convencer de ello a aquellos con quienes
interactuamos.
En esto seguimos siendo un poco utópicos: pensamos que
"tenemos razón" y que con esto basta.

Es similar a lo que aparecía en una escena del biopic "Pirates
of Silicon Valley" en el que hay una escena con un supuesto
diálogo entre Steve Jobs y Bill Gates. En el mismo, Jobs
intenta decir la última palabra exclamando algo así como:
"Somos mejores que tú... Tenemos productos mejores.", a lo
que responde Gates: "¿No lo entiendes, Steve? Eso no
importa."

Si quieres enviar algún comentario o sugerir temas a tratar en otros artículos, escribe a:
curtasun[simboloArroba]cein.es

Categorías General

Tema Varios

Autor Carlos Urtasun

Mes Diciembre

Año 2008

Boletín 12

Títu Proyecto piloto TDT: parte 4: fase 2
lo
Tex Esta segunda fase arrancó con el segundo comité. Comité en el cual
to se presentaban los trabajos realizados hasta ese momento, es decir,
la primera fase completada, ya comentada en artículos anteriores, y
el planteamiento del proyecto desde ese momento hasta el final del
proyecto.

Este planteamiento consistía en establecer los trabajos a realizar por
parte del equipo local, número y planificación, junto con la
transferencia de conocimiento y papel que SiTVi debía ejercer durante

esta segunda fase. Para ello se partía del resultado del análisis de
servicios a adaptar a TDT realizados durante la primera fase, que
trajeron no pocos quebraderos de cabeza y de la finalización de la
preparación formal del equipo local.

Del análisis teníamos como resultado una lista de posibles servicios a
implementar en TDT, no obstante, no había identificados unas fuentes
fiables de información en ninguno de ellos y tampoco había asegurada
la incorporación de ningún servicio interactivo (con capacidad de
realizar peticiones mediante el uso del canal de retorno) dada la
imposibilidad de contar con una interacción con los sistemas de
Gobierno de Navarra (a través de servicios web) en la fecha presente.
Dado que había muchos flecos en prácticamente todos los servicios
que se irían aclarando con el estudio concreto de cada uno y dada la
existencia de un plan de modernización paralelo que iba afectar a los
sistemas de la información y por tanto, cambiar la situación actual, la
lista, prioridad y posición de cada servicio dentro de la misma podía
variar. De hecho, debía irse adaptando conforme se obtuviese más
información de los mismos a lo largo de los desarrollos de la segunda
fase. En resumen, había una gran indeterminación.

Servicio Prioridad Fuente

Meteorología Alta Extracción automatizada de la
información directamente de la fuente

Información Alta Inserción manual
estática

Agenda de ocio y Alta Extracción directa de BBDD
cultura

Farmacias de Alta Extracción directa de BBDD
guardia

Centros de salud Alta Extracción directa de BBDD

Carreteras Alta Tempos21: analizar alternativas

Empleo público Alta Tempos21: previo filtrado de la
(convocatorias) información

Vivienda Alta- A determinar
Media
BON Media Dentro del plan de modernización: a
determinar en octubre

Empleo privado Media Dentro del plan de modernización: a
determinar en otoño

Esto es, se habían identificado 10 posibles servicios, de los cuales, los
7 primeros eran informativos mientras que los 3 últimos podían
presentar algo de interactividad.

No obstante, existía una gran indeterminación en el posible uso de
estos 3 últimos puesto que en el momento del análisis, tal y como he
comentado, no existía ningún servicio web disponible para
implementar la interactividad en el servicio, circunstancia que podía
cambiar por el plan de modernización que afectaba directamente a
dos de estos servicios.

Entre los informativos, tras muchas averiguaciones se vio la dificultad
y riesgo de emplear el desarrollo de Tempos21 como fuente de
información ya procesada con lo que se planteó buscar la fuente de
datos original. Para los dos primeros ya se tenía detectada una
alternativa útil y por tanto podían implementarse en TDT, mientras
que en los restantes se sabía de la existencia de bases de datos que
almacenaban cierta información necesaria para cada uno de los
servicios pero se desconocía con certeza su naturaleza y por tanto, no
se podía asegurar en todos los casos su uso. De echo, para los
servicios de Carreteras y Empelo público, ni siquiera se tenía
constancia de la existencia de una base de datos, lo cual implicaría el
uso de Tempos21 como fuente de información ante la inexistencia de
una alternativa.

Por otro lado, el equipo local se encontraba “preparado”, había
recibido la formación adecuada relacionada con conceptos generales
de la TDT, el estándar MHP y el uso de la herramienta de autor a
emplear iDesginer. No obstante, como hemos adelantado, la
formación no terminaba ahí, esta tan solo había sido la parte teórica.
A continuación comenzaría la formación práctica basada en la

experimentación real con los trabajos a realizar, para lo cual se
definió junto con SiTVi un planteamiento de transferencia de
conocimiento: se identificaron una lista de habilidades a adquirir y
unos niveles para cada una de ellas, A, B y C, siendo A el nivel más
básico y C el más avanzado. Estas habilidades o conocimiento se
agruparon según su aplicación a las tareas de desarrollo, quedando el
siguiente planteamiento:

Niveles

A B C
Toma de requisitos

Ingeniería de software - Metodología de X X X
desarrollo: toma de requisitos, análisis, diseño
aplicación.

Análisis funcional

desarrollo: toma de requisitos, análisis, diseño
aplicación.

Diseño

Desarrollo MHP - Diseño y usabilidad. X X X

Integración y formateo de datos de entrada

Backend – Procesado de datos. X X X
Backend – Tratamiento de XML, XSLT. X X X
Conocimiento del entorno - Desarrollo con el X X X
entorno de IDesigner.
Java – Desarrollo basado en Java (bajo nivel, X
sin uso de IDesigner).
Implementación del interfaz

Desarrollo MHP – Interfaz X X X
gráfico (disposición/layout de componentes)
Java – Desarrollo de plugins (personalización X
y creación de componentes gráficos para

IDesigner).
entorno de IDesigner
Implementación de funcionalidades
Desarrollo MHP – Uso de formularios de entrada X X X
(procesado de datos).

Java – Desarrollo de plugins (personalización X
y creación de componentes gráficos para
IDesigner).
Integración con servicios web

Desarrollo MHP - Canal de retorno. X
Backend - Interacción con servicios web: X
post/xml, get/xml, soap.
Conocimiento del entorno - Desarrollo con el X X
Ejecución de pruebas

Conocimiento del entorno - Conocimiento de X
puesta en producción de aplicaciones en el
laboratorio: encapsulador (iMux).

Conocimiento del entorno - Realización de pruebas X X X
de aplicaciones.

Backend - Parametrización de aplicaciones. X
pruebas.
Puesta en emisión:

Backend - Parametrización de aplicaciones. X
Puesta en producción de aplicaciones: X X

comunicación con Abertis.

Dada la nula experiencia en TDT del equipo local se decidió comenzar
con un servicio sencillo de implementar en el que participasen todos
los miembros del equipo. Además, esto permitía arrancar la segunda
fase del proyecto con un servicio concreto y definido y así tener un
colchón suficiente para ir concretando el resto. Posteriormente, tras la
experiencia adquirida, se podían ir acometiendo más servicios en
paralelo mediante la distribución del trabajo entre los miembros del
equipos local. Se trabajaría con la lista identificada anterior como si
fuera un “pool” de servicios, decidiendo su incorporación al desarrollo
según la información recopilada en cada caso, la viabilidad y
evolución de las circunstancias:

Por tanto, este plan nos daba 5 servicios a incorporar de aquí al final
del proyecto, 4 informativos y un último interactivo aún por
determinar dependiendo del plan de modernización. Se decidió
comenzar por un servicio de modo que todo el equipo pudiera
participar e ir adaptándose al desarrollo de aplicaciones interactivas
con MHP para TDT de forma paulatina. De este modo, en este primer
servicio se podía hacer más hincapié en la labor de transferencia de
conocimiento que posteriormente se iría diluyendo a lo largo del
proyecto conforme el equipo adquiriese soltura y conocimientos y
convirtiéndose más bien en una labor de consultoría. Así pues, en los
servicios posteriores, tras esta toma de contacto y adaptación, podía
configurarse un equipo más eficiente de modo que se dividiesen los
trabajos y se pudiesen implementar y afrontar dos servicios en
paralelo cada vez. Dada la disponibilidad de 4 personas (se contaba
con 3 personas en el equipo local y un becario cedido por SiTVi como
refuerzo y apoyo), se podía dividir el equipo en 2 grupos de 2
personas cada uno. De modo que en los servicios informativos, una
persona del grupo pudiese dedicarse a las labores de extracción y
formateo de datos y la otra persona del grupo concentrarse en el
desarrollo MHP. En el caso del servicio interactivo, no existía
extracción y formateo de datos, pero la interacción complicaba el
desarrollo MHP que podía equilibrarse con la dedicación de dos
personas en este caso. Los roles y responsabilidades de cada
participante así como los propios grupos irían cambiando y rotando
con cada desarrollo de modo que todos los miembros del equipo local
experimentasen con todas las partes del desarrollo. La lista de
conocimientos y niveles antes citada encajaba dentro de este
planteamiento de la siguiente manera:

Esto es, los conocimientos de nivel A, se adquirirán con el desarrollo
del primer servicio. Durante el desarrollo del siguiente servicio, se
asimilarán los conocimientos de nivel B, consolidando, a su vez, los
de nivel A adquiridos en el desarrollo anterior. De igual modo,
durante el último servicio, se aprenderán los conocimientos de nivel
C, consolidando los de nivel B adquiridos en anteriores desarrollos y
asumiendo la completa responsabilidad de las tareas de nivel A.

Así pues, como se ha adelantado, se determinó comenzar con un
servicio, buscando el más sencillo y a la vez el que más garantías de
éxito pudiese ofrecer de la lista de servicios posibles. De entre todos
ellos, serios candidatos eran: Meteorología, Farmacias de Guardia,
Centros de Salud, Información Estática y Agenda de cultura y ocio.
Dado que de todos ellos, tan solo Meteorología teníamos realmente
identificada la fuente de información se decidió comenzar con el.

METEOROLOGÍA

Para profundizar en el análisis de la fuente de información y el
servicio, se organizó una reunión con el área de Meteorología
del Departamento de Agricultura, Ganadería y Alimentación del
Gobierno de Navarra, responsables del desarrollo de meteorología
para el portal web www.navarra.es.

Aunque se propuso un servicio muy interesante por el cual se
proporcionaba información en tiempo real de estaciones
meteorológicas, este hubiese requerido un análisis más profundo y
tratándose de un desarrollo más complejo hubiese retrasado el
desarrollo, por lo que fue descartado y se continuó con los planes
iniciales. Así pues, se determinó que el servicio a implantar en TDT
sería el de la predicción meteorológica. En concreto, las siguientes
predicciones:

 Predicción meteorológica en Navarra para hoy.

 Predicción meteorológica en Navarra para mañana.

 Predicción meteorológica en Navarra para los próximos días.

 Predicción meteorológica en el pirineo.

 Predicción nivológica, sólo disponible en temporada de nieve.

 Predicción avisos y alertas cuando los hubiere.

 Imagen de radar.

Esta información, ofrecida en el portal web, se extraía del Instituto
Nacional de Meteorología (en adelante INM), ahora la actual Agencia
Estatal de Meteorología (AEMET). El formato de datos proporcionado
por el INM venía heredado de mucho tiempo atrás, cuando no se
empleaban los caracteres particulares del español como los acentos,
las eñes, etc. Esto unido al uso exclusivo de mayúsculas y a la
inexistencia de traducciones a diferentes idiomas (entre ellos el
Euskera) dificultaba las cosas. La aplicación a diseñar sería
multilingüe, como en todos los casos, aunque la disponibilidad de la
información estaría sujeta a su existencia. En este caso, la
información tan solo podía ser servida en español.

NOTA: posteriormente, a finales del 2007, los responsables del portal
realizaron un filtrado de la información de modo que esta se
visualizaba en minúsculas y realizaban correcciones ortográficas para
incluir los acentos y las eñes. No obstante, esta información contenía
tags html, con lo que requería un procesado previo antes de poder
ser incluida en TDT. Esta novedad no pudo ser incorporada finalmente
al proyecto por falta de tiempo y recursos.

Toda esta información era facilitada en forma de ficheros individuales
por cada una de las predicciones anteriores. Estos ficheros estaban
localizados en un servidor de FTP al que nos dieron acceso para la
conexión y descarga de la información.

La visualización de esta información, interfaz, presentó algunos
problemas en TDT. En el portal www.navarra.es, la información de
predicción correspondiente al día actual, el día siguiente y los
próximos días, eran visualizadas de forma conjunta. Esta información
consistía en un texto y en la imagen de un mapa de navarra
actualizados diariamente pero de forma independiente. La imagen del
mapa se correspondía con la predicción para el día siguiente, no
obstante, esta información se actualizaba en torno al medio día, con
lo que en las primeras horas del día el mapa se correspondía con la

predicción del día anterior, o visto de otra forma, la previsión del día
actual realizada el día anterior.

El interfaz en TDT impedía mostrar las 3 predicciones anteriores de
forma conjunta por problemas de espacio. Por esa razón se
implementaron de forma separada, lo cual, planteaba el problema de
donde ubicar el mapa de predicción común. Finalmente se decidió que
la predicción del día siguiente contendría el texto y la imagen del
mapa correspondiente, actualizado a medio día, momento en el cual,
la imagen del mapa anterior pasaría a la predicción del día actual.
Probablemente esta circunstancia podrí haberse resuelto de forma
más óptima de poder haber tenido más libertad sobre la disposición
de componentes en el interfaz, no obstante, la herencia de los
servicios en TDT anteriores marcaba una línea gráfica de la cual no
era posible salir.

Otro escollo asociado al interfaz en TDT resultaron ser las propias
imágenes por el origen de las mismas. Se trataba de imágenes con
tamaño y formato adaptado al entorno web, además de tratarse de
imágenes de calidad reducida, óptima para entorno web. Estas
debieron ser escaladas para adaptare al interfaz de TDT, acentuando
la mala calidad. Esto unido a la diferente visualización de los colores
en TDT dieron como resultado unas imágenes bastante pobres, no
obstante, no se contaba con otra fuente de datos alternativa.

A continuación se muestran unos bocetos del interfaz que indican la
ubicación de cada elemento gráfico:

Es decir, y como se ha mencionado, por coherencia se mantuvo el

diseño gráfico establecido en las aplicaciones anteriores:

 Menú superior de acceso a otros servicios en TDT,

 Menú inferior con los controles directos del mando de
televisión.

 Menú propio del servicio actual situado a la izquierda.

 La emisión del vídeo en la esquina inferior izquierda.

 El espacio útil de visualización situado en el centro.

En este caso, el menú izquierdo se correspondía con cada una de las
predicciones a visualizar de forma independiente a modo de
secciones.

El área útil mostraba la información de predicción correspondiente a
la sección elegida. Para el caso de la predicción de hoy y mañana, se
desarrolló un componente que conmutaba entre la predicción de texto
y la predicción con la imagen, dado que las limitaciones del interfaz
en TDT impedían su visualización simultánea.

De igual modo, se mantuvo (como se verán en las imágenes de
resultado final) el estilo heredado de las aplicaciones anteriores en
cuanto a uso de colores, diseño de botones, etc.

En cuanto al proceso que recogía, procesaba y publicaba la
información en TDT, el sistema presentaba la siguiente arquitectura:

Esto es:

1. Proceso de adquisición de datos: se trataba de un sistema
independiente que monitorizaba los ficheros determinados
ubicados en el servidor FTP. En caso de que hubiese cambios,
los descargaba y procesaba para construir los ficheros XML que
servirían como fuente de información a la aplicación MHP a
ejecutar en el televisor. Este proceso dejaba los ficheros XML
generados en unas ubicaciones de carpetas preestablecidas en
un servidor local.
2. Proceso de publicación: se trataba de un sistema que
conjugaba los ficheros obtenidos y formateados en el proceso

anterior y los mezclaba con los fuentes de la aplicación para
generar el empaquetado compilado final. No obstante, no se
enviaba a publicación el empaquetado completo, puesto que
sería requisito indispensable que la aplicación ya se encontrase
disponible en el aire, por lo cual, tan solo se actualizaría la
parte correspondiente a la información, manteniendo la
aplicación intacta. Tal y como se explicó en el artículo anterior,
esto se hace así, puesto que cada actualización de la lógica
conlleva un proceso de validación previo por parte de Abertis
que sería inmanejable en el día a día de una aplicación
informativa de contenidos actualizables diariamente como es el
caso. La actualización se realiza de nuevo mediante un acceso
por FTP a la información publicada en TDT proporcionada por
Abertis.

Esto es:

1. Proceso de adquisición de datos: se trataba de un sistema
independiente que monitorizaba los ficheros determinados
ubicados en el servidor FTP. En caso de que hubiese cambios,
los descargaba y procesaba para construir los ficheros XML que
servirían como fuente de información a la aplicación MHP a
ejecutar en el televisor. Este proceso dejaba los ficheros XML
generados en unas ubicaciones de carpetas preestablecidas en
un servidor local.
2. Proceso de publicación: se trataba de un sistema que
conjugaba los ficheros obtenidos y formateados en el proceso
anterior y los mezclaba con los fuentes de la aplicación para
generar el empaquetado compilado final. No obstante, no se
enviaba a publicación el empaquetado completo, puesto que
sería requisito indispensable que la aplicación ya se encontrase
disponible en el aire, por lo cual, tan solo se actualizaría la
parte correspondiente a la información, manteniendo la
aplicación intacta. Tal y como se explicó en el artículo anterior,
esto se hace así, puesto que cada actualización de la lógica
conlleva un proceso de validación previo por parte de Abertis
que sería inmanejable en el día a día de una aplicación

informativa de contenidos actualizables diariamente como es el
caso. La actualización se realiza de nuevo mediante un acceso
por FTP a la información publicada en TDT proporcionada por
Abertis.
Aquí surgió por primera vez, el concepto de la plataforma de TDT.
Como era de esperar, esta consistía en una extracción de información
del back office y su procesado para emisión en TDT. Debía
establecerse un mecanismo que fuese común y reutilizable en todos
los servicios que independizasen información y presentación. Lógico,
pero muy difícil. Cada servicio requería procesos de extracción
diferentes, como posteriormente se vería, según la fuente de datos y
la propia información a extraer en cada caso. No obstante la filosofía
en todos los casos fue la misma, definiendo un formato de fichero
XML particular para cada aplicación que independizaba al menos la
información de la aplicación MHP, la lógica. El proceso, no obstante,
que si podía ser común o al menos reutilizado era el de publicación.
Una vez procesada la fuente de información y generado el XML base,
los pasos a partir de ahí eran los mismos en todos los casos,
compilar, empaquetar y enviar la información a Abertis para su
actualización en emisión.

En torno a esta cuestión, empezaron a tenerse las primeras reuniones
con sistemas de Gobierno de Navarra para definir esta plataforma de
extracción de datos y publicación en TDT, tanto a nivel hardware
como software. Para esto se redactaron una serie de documentos
solicitados por sistemas en los cuales se trataba de definir la
plataforma, pero de forma bastante abstracta puesto que no se
conocían las implicaciones ni requerimientos del resto de servicios por
desarrollar. De nuevo, todo se debía ir definiendo sobre la marcha. En
cualquier caso, sistemas estableció una serie de condicionantes que
aplicaban tanto a nivel hardware como software que daban una idea
de por donde debían ir las cosas. Se comenzó definiendo que estos
procesos podían ser aplicaciones Java que corriesen como demonios,
sin necesidad de ningún framework o requisito adicional que el propio
proceso, lo cual limitaba mucho las posibilidades. No obstante, como
se verá más adelante, estos requerimientos y condicionantes irían
cambiando a lo largo del proyecto.

La dificultad para ir definiendo todo esto, hizo que la plataforma
estuviese alojada de forma temporal en la infraestructura
proporcionada por los CES, hasta el momento en que fuera viable su
traspaso a sistemas de Gobierno, una vez definida por completo la
plataforma y disponible una infraestructura donde alojarla. No fue,

como se verá posteriormente, hasta el final del proyecto que pudo
hacerse esta migración.

Todos estos trabajos se planificaron de la siguiente manera:

Puede verse que para este servicio había un gran esfuerzo en lo que
era la parte de adquisición y formateo de los datos para construir los

ficheros XML base que alimentarían la aplicación MHP. También
existía una gran dependencia entre la aplicación cliente MHP y el
proceso de adquisición de datos debido al fichero XML que relacionaba
ambas aplicaciones. El diseño del interfaz marcaba la organización de
la información en el XML, el cual, a su vez, incidía directamente en el
proceso de adquisición de datos y obtención del XML. El publicador,
por el contrario, era un proceso que podía ser desarrollado de forma
independiente.

Finalmente, el equipo local estaba constituido por 3 personas (ante la
baja del miembro proporcionado por SiTVi, lo cual complicaría la
planificación acordad inicialmente) para tres desarrollos: proceso de
adquisición de datos, proceso de publicación y aplicación MHP. Las
responsabilidades de cada miembro, tal y como se ha dicho, iría
rotando en cada servicio para que todos los participasen en los
diferentes desarrollos y comprendiesen de esta forma el sistema
global.

Las pruebas del sistema completo, adquisición y publicación, eran
cruciales. Se realizaron una serie de pruebas del sistema completo en
un entorno de pre-producción habilitado en el laboratorio del CES
para asegurar el correcto flujo y procesado de la información, así
como una prueba del sistema completo en producción, pactado con
Abertis.

Previo a la emisión, se realizó una demostración de la aplicación al
área de Meteorología del Departamento de Agricultura, Ganadería y
Alimentación del Gobierno de Navarra para que solicitasen cambios y
diesen su aprobación final.

En dicha demostración, se detectó que se precisaba de la autorización
del INM para el empleo de sus datos en TDT, algo que, no obstante,
no supuso ningún impedimento ni inconveniente pudiéndose resolver
de forma satisfactoria a tiempo.

En cualquier caso, un retraso aproximadamente de una semana en
las pruebas y la coincidencia de las fiestas de San Fermin con la
emisión, pospusieron los planes, ante posibles eventualidades, hasta

finales de julio. Un retraso pequeño pero que unido a la baja de un
miembro del equipo, iría pesando a lo largo de los siguientes
desarrollos.

A continuación se muestran algunas imágenes de lo que fue e aspecto
final de la aplicación:

Cat CES OpenSouce/Java
ego
rías
Te Varios
ma
Aut Raúl Sanz de Acedo
or
Mes Diciembre

Año 2008

Bol 12
etín

Título Integración de jQuery con SharePoint (II)

Texto En el artículo anterior vimos como se crea un feature para
integrar la biblioteca jQuery en nuestro sitio SharePoint, sin

embargo no llegamos a ver sus funcionalidades. jQuery nos
permite, entre otras cosas, hacer consultas personalizadas
mediante código JavaScript.

Para ello es necesario descargarnos los archivos JavaScript que
nos permiten personalizar la consulta y que son modificables por
el desarrollador. También son necesarias las Web Parts que
alojan los contenidos y los resultados de la consulta, de una
manera similar a las búsquedas de SharePoint. Todo este
paquete está disponible para los suscriptores a las noticias
semanales de EndUserSharePoint un portal de usuarios de
SharePoint donde se recoge información sobre novedades,
actualizaciones y recursos interesantes. Un “precio” racionable si
se tiene en cuenta lo interesante de la información recibida.

Una vez que tenemos la biblioteca jQuery instalada y todos los
archivos JavaScript necesarios, iremos al Sitio donde queremos
emplearla y crearemos una biblioteca de documentos
llamada QueryResources, que será donde alojemos todos los
recursos necesarios para la personalización.

Para crear la biblioteca de documentos vamos a View All Site
Content> Create >Document Library. Una vez creada la biblioteca
cargamos los archivos medianteUpload>Upload Multiple Documents.

A continuación creamos una página de Web Parts (Web Part

Page) llamada SearchQuery.aspx, que guardaremos en la misma
biblioteca en la que tenemos nuestros recursos.

Una vez que hemos creado la página de Web Parts, el siguiente
paso es añadir las que nos permiten el empleo de jQuery. En
modo edición, utilizamos la opción Add Web Part y dentro de la
galería que nos aparece, seleccionamos Advanced Web Part
Gallery and Options que se encuentra en la parte inferior.

Al seleccionar dicha opción, nos aparece un cuadro de acciones
que nos permite importar las Web Parts directamente del disco

duro. Para ello seleccionamos Browse> Import. A continuación
examinamos y cargamos, una a una, cada Web Part. Cuando nos
aparece en la zona Uploaded Web Part, la arrastramos a la zona
de nuestra página donde deseamos implementarla.

En mi caso, he añadido jQuery_SearchBox-Top.dwp a la
cabecera y jQuery_ContentOfPageToBeSearched-
Center.dwp y jQuery_CallToScripts-Bottom.dwp al cuerpo. Y he
personalizado el texto de prueba.

De esta manera la página queda de la siguiente manera:

Finalmente, para comprobar que todo funciona correctamente,
salimos del modo edición de nuestra página. Y comenzamos a
escribir en el cuadro de texto…¡¡¡ Et Voilà!! A medida que vamos
escribiendo, las palabras que coinciden con la consulta se van
pintando de amarillo.

Como hemos dicho al principio, está es sólo una de las múltiples
funciones que tiene esta biblioteca. Ya que tenemos un amplio
abanico de posibilidades en el que poder trabajar. A continuación
podemos ver algunos de los ejemplos:

 Página oficial de

JQuery: http://dev.jquery.com/wiki/Demos
 http://codylindley.com/blogstuff/js/jquery/
 http://www.kelvinluck.com/assets/jquery/styleswitch/
 http://iamzed.com/jquery/flashonetime.html
 http://icant.co.uk/sandbox/jquerycodeview/

Categor CES Microsoft
ías
Tema Desarrollo

Autor Goretti Ortigosa Rada

Mes Diciembre

Año 2008

Boletín 12

Título Introducción a Adobe Flex (y II).

Texto En este segundo artículo, vamos a ver un tutorial para la creación de un primer
proyecto con Adobe Flex. Crearemos una pequeña aplicación Java en el servidor y
un cliente realizado en Flex que accederá a ella a través de BlazeDS.

Descargas necesarias
A continuación se muestran las descargas necesarias para la realización del tutorial.
El sistema operativo utilizado es Windows XP.

Eclipse 3.3:

http://www.eclipse.org/downloads/download.php?file=/technology/epp/download
s/release/europa/winter/eclipse-jee-europa-winter-win32.zip

Apache Tomcat:

http://tomcat.apache.org/download-60.cgi

Flex Builder:

http://www.adobe.com/cfusion/entitlement/index.cfm?e=flex3email

BlazeDS (Binary distribution):

http://opensource.adobe.com/wiki/display/blazeds/Release+Builds

Configuración del entorno de desarrollo
Se han instalado en la carpeta C:FlexEclipse las herramientas que se utilizarán en
este tutorial. Se instala antes eclipse, ya que la instalación de FlexBuilder pide la ruta
donde está instalado eclipse. Por comodidad, colocamos el servidor Apache Tomcat
en la misma carpeta. Además, creamos una carpeta llamada FlexWS que servirá
como workspace de eclipse para el proyecto que crearemos.

Figura 1. Entorno de trabajo

Una vez instaladas las herramientas, arrancamos eclipse. Lo primero que debemos
hacer es registrar el servidor Apache Tomcat en eclipse. Para ello, vamos a Window -
> Preferences -> Server -> Installed Runtimes, y añadimos nuestro servidor Tomcat:

Figura 2. Servidor Apache Tomcat

Creación del proyecto de servidor
La descarga de BlazeDS consiste en una aplicación web (blazers.war), que
utilizaremos como base para nuestra aplicación de servidor. Para ello, desde eclipse,
vamos a File -> Import -> Web -> WAR File

Elegimos el fichero blazers.war, y ponemos el nombre de proyecto que queramos,
en este caso creamos un proyecto web llamado Coches.

Figura 3. Importación del archivo WAR de BlazeDS

En la siguiente pantalla, eclipse nos pregunta si queremos crear proyectos para las
librerías utilizadas en blazers.war. No seleccionamos ninguna, y finalizamos el
proceso de importación.

En este punto creamos las clases de la aplicación Java, que constará de dos clases:

Coche.java (Representa un coche con algunos atributos)

CocheService.java (Proporciona un método que devuelve una lista de coches)

Figura 4. Clases de la aplicación Coches

Para poder acceder a este servicio, debemos declarar la clase en el fichero remoting-
config.xml, de la siguiente forma

Figura 5. Configuración del acceso remoto a la aplicación

De esta forma, ya tenemos una pequeña aplicación Java en el servidor a la que
podremos acceder desde una aplicación Flex en el cliente, a través de BlazeDS. Para
publicar la aplicación en el servidor Tomcat, vamos a la pestaña de servidores, y
añadimos el proyecto Coches a las aplicaciones del servidor.

Creación del proyecto cliente
En este tutorial vamos a crear dos proyectos separados, uno para el servidor y otro
para el cliente. FlexBuilder nos permite crear la aplicación Java y el cliente Flex en un
mismo proyecto, pero en este caso se ha optado por separarlos para ganar en
claridad.

Antes de comenzar, debemos arrancar el servidor Tomcat, ya que en la creación del
cliente indicaremos donde encontrar la aplicación de servidor. Vamos a File -> New
Project -> FlexBuilder -> Flex Project y creamos el proyecto CochesClient:

Figura 6. Creación del proyecto cliente (I)

En la primera pantalla, introducimos el nombre del proyecto, CochesClient, y
dejamos el resto como se indica en la Figura 6. En la segunda pantalla, debemos
indicar la ruta y la URL del proyecto de servidor. La instalación por defecto de
Tomcat en eclipse no crea las aplicaciones en la carpeta del servidor
(C:FlexEclipseapache-tomcat-6.0.18), sino que las crea bajo la carpeta .metadata
del workspace. En la Figura 7 se muestra esta ruta para el entorno de trabajo
creado. Para comprobar que todo está bien, tenemos un botón llamado ‘Validate
Configuration'. Una vez que todo está bien, finalizamos el asistente.

Figura 7. Creación del proyecto cliente (II)

Al crear el proyecto se genera un fichero CochesClient.mxml, donde escribiremos la
parte de Flex que accederá a la aplicación. La aplicación cliente constará de un
botón y una tabla para mostrar los datos. Al pinchar en el botón ‘Obtener coches’,
se establecerá la conexión con el servidor a través de BlazeDS y se mostrará en la
tabla la información. A continuación se muestra el código:

<?xml version="1.0" encoding="utf-8"?>

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
layout="absolute">

<mx:Script>

import mx.rpc.events.ResultEvent;

import mx.rpc.events.FaultEvent;

import mx.controls.Alert;

import mx.utils.ObjectUtil;

public function resultListaCoches(event:ResultEvent
):void {

tablaCoches.dataProvider = event.result;

tablaCoches.visible = true;

}

private function faultListaCoches(event:FaultEvent)
:void{

Alert.show( ObjectUtil.toString(event.fault)
);

}

</mx:Script>

<mx:RemoteObject id="remoteCochesService"
destination="CocheServiceDestination" showBusyCursor="true">

<mx:method name="listaCoches"
result="resultListaCoches(event)"
fault="faultListaCoches(event)"/>

</mx:RemoteObject>

<mx:Button label="Obtener Lista"
click="remoteCochesService.listaCoches()"/>

<mx:DataGrid id="tablaCoches" x="10" y="63" width="574"
height="166" visible="false">

</mx:DataGrid>

</mx:Application>

En este código podemos ver:

- Un objeto RemoteObject que permite la conexión con el servidor.

- Un botón que realiza la llamada a través del RemoteObject.

- Un objeto DataGrid para mostrar los datos.

- Las funciones que gestionan el resultado de la petición. En caso de que vaya
bien, se pone el resultado de la petición como dataProvider del DataGrid, y
la información se muestra.

Figura 8. Aspecto de la aplicación Flex.

Código fuente
- Descargar

Referencias
- Adobe Flex

- BlazeDS

- Mihai Corlan Blog

Catego General
rías
Tema Desarrollo

Autor Miguel Bacaicoa

Mes Diciembre

Año 2008

Boletín 12

Título Azure es un color… y más

Texto Siguiendo con la temática del artículo del mes anterior, vamos a volver
a hablar de Windows Azure, la plataforma de Microsoft para el
desarrollo de servicios disponibles en Internet e intercomunicables.

En este artículo vamos a llevar a cabo otro de los ejemplos disponiblres
en el Azure Services Training Kit y conseguir hacer disponible en
Internet un programa desarrollado en Silverlight. Para eso, nos
serviremos de los Live Services, que mediante Live Mesh nos permitirán
acceder a esta aplicación una vez la hayamos hecho disponible en la
plataforma Windows Azure.

Si empleamos como base el diagrama de la Plataforma de Servicios
Azure que mostrábamos el mes pasado, la representación de lo que
pretendemos hacer sería esta:

Aquí por simplificar hemos mostrado que nuestra aplicación sólo haría
uso de Live Services, pero nada nos impediría hacer uso de SQL

Services (para almacenar información en la “nube” y compartirla
mediante cualquiera de nuestros medios de acceso) , .NET Services
(para interactuar con otras infraestructuras de trabajo o ejecutar
Workflows por ejemplo) u otra aplicación alojada en Windows Azure a
la que tengamos acceso. ¡El poder de Azure!

Una vez conocido lo que vamos a hacer, al tajo. El ejemplo que vamos
a desarrollar consistirá en la publicación mediante Live Mesh de una
aplicación desarrollada en SilverLight (aunque podría tratarse de
cualquier aplicación soportada por Windows Azure). Para empezar, los
requisitos que necesitamos cumplir son:

- Microsoft Visual Studio 2008 (versión Estándar o superiores)

- Microsoft Visual Studio 2008 SP1 (descargable aquí)

- Microsoft Silverlight 2 Tools for Visual Studio 2008 (mejor no
usar las Betas anteriores por las diferencias entre Silverlight 2 y
sus antecesores): descargable aquí

- Microsoft Live Framework SDK (Descargable desde Microsoft
Connect)

- Microsoft Live Framework Tools for Visual Studio 1.0 CTP (como
el anterior también descargable desde Microsoft Connect)

Si tenemos la “sana” costumbre de instalar en nuestro PC todo aquello

con lo que podamos trastear (de alguna manera hay que probarlo,
¿no?), la instalación de los elementos listados arriba no va a ser todo lo
sencilla que podríamos desear. En concreto, la instalación de las
Silverlight Tools puede producir un error inesperado e “inexplicado”. En
este caso tendremos que hacer la instalación de manera manual de los
disitintos elementos del paquete. Para ello hay que lanzar la ejecución
y cuando nos muestre la pantalla de error no cerrarla. Entonces
buscaremos el directorio temporal de instalación que se habrá creado
automáticamente en nuestro disco duro C: (normalmente tendrá un
nombre compejo, enrevesado… informático vamos) y dentro de este
estarán entre otros los archivos a instalar:

- El Software Development Kit para Silverlight “silverlight_sdk.msi”
- Las Silverlight Tools para Visual Studio (aunque no usaremos estas
sino las indicadas anteriormente)
- Y dos parches de Visual Studio: VS90-KB951460.msp y VS90SP1-
KB955215.msp

Una vez realizada esta instalación ya estaremos en condiciones de
realizar desarrollos con Visual Studio 2008 y Silverlight para Windows
Azure.

En este ejemplo vamos a llevar a cabo el laboratorio para la creación
de una aplicación Live Mesh. Si seguimos el artículo del mes
pasado habremos instalado en nuestro PC el Microsoft Azure Services
Kit. Dentro de este se encuentra el Laboratorio denominado
“BuildingMeshEnabledWebApplications” que es el que nos interesa en
este caso. Si abrimos Visual Studio 2008 como Administradores
podremos abrir sin problemas la solución de ejemplo, “Begin.sln”,
ubicada en la carpeta “Ex01-UnderstandingTheApplication”. Se trata de
una aplicación completa basada en SilverLight para la gestión de
campeonatos de un deporte, donde podemos crear ligas, campos,
subir fotos de los campos, usar un sencillo tablón de mensajes, ver la
previsión del tiempo, etc.

Si miramos un poco el detalle de esta aplicación veremos que está
compuesta de 2 proyectos, uno que es la aplicación SilverLight en sí
para controlar el interfaz de usuario
(WLQuickApps.FieldManager.Silverlight) y otro con las clases
necesarias para que el anterior funcione (FieldManager.ObjectModel):

El proyecto FieldManager.ObjectModel representa un muy buen
ejemplo de organización de la estructura de un proyecto, con una
carpeta para la definición de los Objetos y otra para los Gestores
(Managers) de estos, de manera que su organización queda muy clara.

Antes de proceder con las modificaciones necesarias para publicar esta
aplicación en Live Mesh, habremos de conseguir el acceso a una
cuenta de Azure Services para desarrollo. Para ello, accedemos a Azure
Services Developer Portal mediante la
web http://lx.azure.microsoft.com y nuestro Windows Live ID. En el
caso de que se trate de la primera vez, habremos de dar de alta la
información precisa como cuenta de desarrollo:

Hecho esto, pasamos a la que será la pantalla principal en nuestras
próximas visitas, desde donde gestionaremos nuestros proyectos,
cuenta, etc.

Aquí tendremos que seleccionar el enlace “New Project” (a izquierda o
derecha, da igual) y pasamos a la pantalla desde la que definiremos el
nuevo proyecto a crear. Como veremos existen varios tipos
disponibles, agrupados en dos bloques:

- Windows Azure: este bloque nos permite definir aplicaciones
que se ejecutarán sobre Windows Azure, para lo que podemos
optar por crear almacenamiento mediante “Storage Account” o
nuestro propio servicio mediante “Hosted Services”.

- Azure Services Platform: en este caso haremos uso de la
plataforma de servicios de Azure ya existente, para lo que
tendremos a nuestra disposición el “Live Services: Live
Framework CTP” para el desarrollo de servicios que hagan uso
de cualquier Live Services existente, o “Live Services: Existing

APIs” para usar APIs de los Live Services desde cualquier
aplicación Web.

En nuestro caso, veremos más adelante que crearemos un proyecto
con el Live Framework CTP del Azure Services Platform, ya que lo que
queremos es publicar una aplicación que haga uso del Live Service
“Live Mesh” como plataforma de publicación.

Por ahora eso es todo en este portal, cancelamos las modificaciones y
regresaremos a Visual Studio y preparamos una solución para su
publicación. Para eso, cerramos la que tenemos abierta y abrimos la
solución “Begin.sln” que está localizada en la carpeta “Ex02-
DeployingIntoLiveMesh” que prepararemos para publicar mediante los
siguentes pasos:

1. Añadimos al
proyecto WLQuickApps.FieldManager.Silverlight tres

referencias (botón derecho sobre el nodo “References”, opción
“Add Reference…”) a los ensamblados de Live Framework que
encontraremos en “[LiveFxSDK]LibrariesSilverlight”:

- Microsoft.LiveFX.Client.dll
- Microsoft.LiveFX.ResourceModel.dll
- Microsoft.Web.dll
2. Editamos el fichero App.xaml.cs
de WLQuickApps.FieldManager.Silverlight

E introduciremos los cambios siguientes mostrados en azul:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;
using System.Windows.Browser;
using Microsoft.LiveFX.Client;

namespace WLQuickApps.FieldManager.Silverlight
{
public partial class App : Application
{
public App()
{
this.Startup += this.Application_Startup;
this.Exit += this.Application_Exit;
this.UnhandledException += this.Application_UnhandledException;
InitializeComponent();
}
private void Application_Startup(object sender, StartupEventArgs e)
{

MeshApplicationService meshApp =
Application.Current.GetMeshApplicationService();
meshApp.LoadCompleted += new EventHandler(this.App_Load);
meshApp.Load();
}
private void Application_Exit(object sender, EventArgs e)
{
}
private void Application_UnhandledException(object sender,
ApplicationUnhandledExceptionEventArgs e)
{
// Commented out per security review.
HtmlPage.Window.Invoke("alert", "DEBUG:n" + e.ExceptionObject.Message);
}
// Evento de carga para Live Mesh
public void App_Load(object sender, EventArgs e)
{
MeshApplicationService meshApp =
Application.Current.GetMeshApplicationService();
meshApp.Resource.Title = "App";
Mesh mesh = meshApp.LiveOperatingEnvironment.Mesh;
this.RootVisual = new Page();
}
}
}

3. Añadiremos un nuevo proyecto a nuestra solución, que será el
encargado de prepararla como una aplicación Live Mesh. Al
haber instalado el Live Framework Tools tenemos disponible
entre las posibles plantillas de proyecto un nuevo nodo de
nombre “ Live Framework” que incluye el tipo que queremos
“Silverlight Mesh-enabled Web Application”.

Seleccionamos esta plantilla y le damos el nombre
“FieldManagerMeshApp”. Esto nos crear dos proyectos más en
nuestra solución, uno de los cuales hemos de borrar ya que no
nos hace falta. Se trata de “FieldManagerMeshAppSiverlight”
que es el esqueleto de proyecto que podríamos usar en caso de
que tuviéramos que crear una aplicación SilverLight desde cero,
que en nuestro caso está ya creada. Pincharemos con el botón
derecho del ratón sobre su nombre y seleccionaremos la opción
“Remove”

Para correguir este cambio en nuestra aplicación
“FieldManagerMeshApp” hemos de quitar la referencia a
“FieldManagerMeshAppSilverlight” y agregar la correcta a
nuestro proyecto “WLQuickApps.FieldManager.Silverlight”

Quitar Añadir

4. Cambiamos en el fichero Index.html del
proyecto FieldManagerMeshApp la referencia al paquete xap
del control de Silverlight modificando en la definición del
“silverlightControlHost” el valor del parámetro source como se
muestra a continuación:

<div id="silverlightControlHost">
<object data="data:application/x-silverlight," type="application/x-
silverlight-2" width="100%" height="100%">
<param name="source"
value="WLQuickApps.FieldManager.Silverlight.xap"/>
<param name="onerror" value="onSilverlightError" />
<param name="background" value="white" />
<param name="minRuntimeVersion" value="2.0.30923.0" />

<param name="autoUpgrade" value="true" />
<param name="windowless" value="true" />
<a href="http://go.microsoft.com/fwlink/?LinkID=124807"
style="text-decoration: none;">
<img
src="http://go.microsoft.com/fwlink/?LinkId=108181" alt="Get Microsoft
Silverlight" style="border-style: none"/>
</a>
</object>
<iframe style='visibility:hidden;height:0;width:0;border:0px'></iframe>
</div>

5. Finalmente debemos modificar los valores del fichero
Manifest.xml del proyecto FieldManagerMeshApp para que la
publicación de nuestra aplicación tenga las propiedades que
nos interesen:

<?xml version="1.0" encoding="utf-8" ?>
<Manifest xmlns="http://schemas.mesh.com/application/manifest/2008">
<Name>CES Field Manager</Name>
<Description>Apliación de prueba de Silverlight en Live Mesh</Description>
<PublisherName>User</PublisherName>
<DisplayVersion>1.0</DisplayVersion>
<MultiInstance>false</MultiInstance>
<PrivacyPolicyLink>http://www.cesnavarra.net</PrivacyPolicyLink>
<SupportLink>http://www.cesnavarra.net</SupportLink>
<VendorLink>http://www.cesnavarra.net</VendorLink>
<RequireDelegation>false</RequireDelegation>
</Manifest>

6. Por último, establecemos el
proyecto FieldManagerMeshApp como proyecto de inicio,
pulsando con el botón derecho del ratón sobre su nombre y
seleccionando la opción “Establecer como proyecto de inicio”.

7. Ejecturaremos la aplicación sin debugging (Ctrl + F5) y nos
aparecerá la ventana de solicitud de nuestro Windows Live ID
para acceder a la plataforma Windows Azure.

8. Una vez hemos hecho esto, tendremos una nueva pantalla para
la definición del enlace la aplicación:

Lo primero a hacer ahora es pulsar el enlace “Navigate to the
Developer Portal” para definir la nueva aplicación Mesh en el
Azure Services Developer Portal. Como hemos dicho antes,
pulsaremos en “New Project” una vez en ese portal, y de las
opciones elegiremos “Live Services: Live Framework CTP” como
hemos comentado antes.

Esto nos pasa a otra pantalla donde introduciremos los datos de
la aplicación: su etiqueta y descripción. Aceptado esto,
tendremos la opción de elegir el tipo de aplicación, que en este
caso se trata de una Mesh-enabled Web application.
Seleecionaremos esta y pulsamos Create:

Tras esto habremos por fin creado nuestra aplicación Mesh (sin
contenido todavía, aún hemos de subirla) y se nos mostrará la
pantalla de propiedades de la misma:

Volvemos a Visual Studio y pulsamos el enlace “Copy full path of
FieldManagerMeshApp.zip to clipboard” en la ventana de
diálogo que teníamos abierta. Cambiamos de nuevo al
navegador, a Azure Services Developer Portal, y pulsamos el
botón “Upload Package”.

Pulsamos entonces el botón “Browse” para abrir la ventanda de
selección del paquete, pulsamos Ctrl+V para pegar el camino
del mismo y a continuación pulsamos Deploy, con lo que se
inicia la copia del paquete a Windows Azure.

Una vez completado, copiamos el “Application Self Link” que se
nos devuelve

Y de vuelta en Visual Studio lo introducimos en el 3er paso de la
ventana que tenemos activa:

Con esta información completa, una vez que pulsemos Ok se
produce la actualización final de la aplicación en Windows Live y
podremos ejecutarla (estos últimos pasos se simplifican en el
caso de que estemos actualizando una aplicación que ya exista
como Live Mesh application; en este ejemplo es más complejo
ya que hemos realizado a la vez la creación y definición de una
aplicación Live Mesh y la compilación y subida de una nueva
versión de la misma).

Para su ejecución, el mismo Visual Studio abrirá el Live Desktop
por nosotros. En caso de no ser así podemos acceder mediante
la webhttps://www.mesh.com/Welcome/Default.aspx

En definitiva, este ejemplo nos ha permitido ver cómo se pueden
desarrollar aplicaciones para Live Mesh, accesibles mediante cualquier
sistema que cuente con acceso a la web, desarrolladas desde nuestra
plataforma local y con todas las ventanas de los múltiples servicios que
Windows Azure pone a nuestra disposición:

- .NET Services para comunicación entre sistemas y
aplicaciones, workflows, etc.

- Storage Services para el almacenamiento de información

- Live Services para el uso del Live Framework y toda la
plataforma de servicios Live

Categ CES Microsoft
orías
Tema Desarrollo

Autor Rafael Flores

Mes Diciembre

Año 2008

Boletí 12
n

Título Creación de un Gadget basado en una animación XAML
Texto Cada día los usuarios demandan el acceso a más información
y que esta sea presentada de forma llamativa y eficiente. Una
de las novedades de Windows Vista ha sido Windows Sidebar.
Esta aplicación se nos presenta como una barra de
herramientas formada por mini aplicaciones (Gadgets).Hay
diversos Gadgets, desde resultados deportivos, pasando por
cotizaciones en bolsa y acabando por Radios o acceso al
Messenger.

En este artículo se pretende presentar nuestra información de
la forma más llamativa posible, mediante un efecto 3D
realizado con nuestras fotos creado a partir de una animación
XAML y la eficiente presentación de nuestras fotos en nuestra
Sidebar.

El primer paso que debemos seguir es crear la animación de
XAML, en nuestro caso va ser un cubo en 3d que nos va
presentar nuestras seis fotos, una por cada cara del cubo, lo
haremos con el siguiente código.
<Page xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation
"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:SampleControls="SampleControls"

WindowTitle="3D Rotation Example" Background="Black">
<Page.Resources>

<!—Modelo 3D de cada una de las caras del cubo -->
<MeshGeometry3D x:Key="CubeSide01"
TriangleIndices="0,1,2 3,4,5 "
Normals="-1,0,0 -1,0,0 -1,0,0 -1,0,0 -1,0,0 -1,0,0 "
TextureCoordinates="0,1 0,0 1,0 1,0 1,1 0,1 "
Positions="-0.5,0.5,-0.5 -0.5,-0.5,-0.5 -0.5,-0.5,0.5 -0.5,-
0.5,0.5 -0.5,0.5,0.5 -0.5,0.5,-0.5 " />

<!—en la animación se reconocen las imágenes como triangulos
para recrear cada cara del cubo -->
Normals="0,0,1 0,0,1 0,0,1 0,0,1 0,0,1 0,0,1 "<!—vector
perpendicular a la superficie del plano -->
TextureCoordinates="0,0 1,0 1,1 1,1 0,1 0,0 ""<!— aplicación de
la textura a cada triangulo-->
Positions="-0.5,-0.5,0.5 0.5,-0.5,0.5 0.5,0.5,0.5 0.5,0.5,0.5 -
0.5,0.5,0.5 -0.5,-0.5,0.5 " />""<!— posicionamiento en las tres
dimensiones de los triangulos-->

Normals="0,0,1 0,0,1 0,0,1 0,0,1 0,0,1 0,0,1 "
Positions="0.5,-0.5,-0.5 0.5,0.5,-0.5 0.5,0.5,0.5 0.5,0.5,0.5
0.5,-0.5,0.5 0.5,-0.5,-0.5 " />

Normals="1,0,0 1,0,0 1,0,0 1,0,0 1,0,0 1,0,0 "
Positions="-0.5,-0.5,-0.5 -0.5,0.5,-0.5 0.5,0.5,-0.5 0.5,0.5,-
0.5 0.5,-0.5,-0.5 -0.5,-0.5,-0.5 " />

TriangleIndices="0,1,2 3,4,5 6,7,8 9,10,11 "
Normals="0,-1,0 0,-1,0 0,-1,0 0,-1,0 0,-1,0 0,-1,0 0,1,0 0,1,0
0,1,0 0,1,0 0,1,0 0,1,0 "
TextureCoordinates="0,0 1,0 1,1 1,1 0,1 0,0 1,1 0,1 0,0 0,0 1,0
1,1 "
Positions="-0.5,-0.5,-0.5 -0.5,0.5,0.5 -0.5,-0.5,0.5 0.5,-
0.5,0.5 -0.5,-0.5,-0.5 -0.5,0.5,-0.5
0.5,0.5,-0.5 -0.5,0.5,-0.5 -0.5,0.5,0.5 -
0.5,0.5,0.5 0.5,0.5,0.5 0.5,0.5,-0.5 " />

TriangleIndices="0,1,2 3,4,5 6,7,8 9,10,11 "
Normals="-1,0,0 -1,0,0 -1,0,0 -1,0,0 -1,0,0 -1,0,0 "
Positions="-0.5,-0.5,0.5 -0.5,-0.5,-0.5 0.5,-0.5,-0.5 0.5,-
0.5,-0.5 0.5,-0.5,0.5 -0.5,-0.5,0.5" />

<!—Material 3D utilizado para cada cara del cubo -->
<MaterialGroup x:Key="LeavesMaterial1">
<DiffuseMaterial>
<DiffuseMaterial.Brush>
<ImageBrush Stretch="UniformToFill" ImageSource="images1.jp
g" TileMode="None" ViewportUnits="Absolute" Viewport="0 0 1
1" AlignmentX="Left" AlignmentY="Top"Opacity="1.000000" /><!—Dibuja
una imagen a traves de un pincel definido -->
</DiffuseMaterial.Brush>
</DiffuseMaterial>
<SpecularMaterial SpecularPower="85.3333"><!—cantidad de luz que
incide sobre nuestro material -->

<SpecularMaterial.Brush>
<SolidColorBrush Color="#FFFFFF" Opacity="1.000000"/>"><!—
define el color y la opacidad del pincel -->

</SpecularMaterial.Brush>
</SpecularMaterial>
</MaterialGroup>

<MaterialGroup x:Key="RocksMaterial">
<DiffuseMaterial>
1" AlignmentX="Left" AlignmentY="Top"Opacity="1.000000" />
</DiffuseMaterial>
<SpecularMaterial SpecularPower="85.3333">
<SolidColorBrush Color="#FFFFFF" Opacity="1.000000"/>
</SpecularMaterial>
</MaterialGroup>

<MaterialGroup x:Key="BranchesMaterial">
<DiffuseMaterial>

</DiffuseMaterial>
</SpecularMaterial>
</MaterialGroup>
<MaterialGroup x:Key="BerriesMaterial">
<DiffuseMaterial>
</DiffuseMaterial>
</SpecularMaterial>
</MaterialGroup>
<MaterialGroup x:Key="FlowersMaterial">
<DiffuseMaterial>
g" ViewportUnits="Absolute"
Viewport="0 0 1
1" AlignmentX="Left" AlignmentY="Top" Opacity="1.000000" />
</DiffuseMaterial>
</SpecularMaterial>
</MaterialGroup>
<MaterialGroup x:Key="SunsetMaterial">
<DiffuseMaterial>
g" ViewportUnits="Absolute"
Viewport="0 0 1
1" AlignmentX="Left" AlignmentY="Top" Opacity="1.000000" />
</DiffuseMaterial>
</SpecularMaterial>
</MaterialGroup>
<MaterialGroup x:Key="SolidColorMaterial">
<DiffuseMaterial>
<SolidColorBrush Color="Orange" Opacity="1.000000"/>
</DiffuseMaterial>
</SpecularMaterial>
</MaterialGroup>

<!—Modelos visuales 3D -->
<ModelVisual3D x:Key="PictureCubeModelVisual3DResource" >
<ModelVisual3D.Children>
<ModelVisual3D>
<ModelVisual3D.Content>
<AmbientLight Color="#333333" />
<!—el color que toma la textura según la incidencia de
la luz -->
</ModelVisual3D.Content>
</ModelVisual3D>
<ModelVisual3D>
<DirectionalLight Color="#FFFFFF" Direction=
"-0.612372,-0.5,-0.612372" /><!—Dirección de la incidencia de
la luz sobre la textura -->

</ModelVisual3D>
<ModelVisual3D>
<DirectionalLight Color="#FFFFFF" Direction="0.612372,-
0.5,-0.612372" />
</ModelVisual3D>
<ModelVisual3D>
<GeometryModel3D Geometry="{StaticResource
CubeSide01}" Material="{StaticResource BranchesMaterial}"/>
</ModelVisual3D>
<ModelVisual3D>
CubeSide02}" Material="{StaticResource FlowersMaterial}"/>
</ModelVisual3D>
<ModelVisual3D>
CubeSide03}" Material="{StaticResource BerriesMaterial}"/>
</ModelVisual3D>
<ModelVisual3D>
CubeSide04}" Material="{StaticResource LeavesMaterial1}"/>
</ModelVisual3D>
<ModelVisual3D>
CubeSide05}" Material="{StaticResource RocksMaterial}"/>
</ModelVisual3D>
<ModelVisual3D>
CubeSide06}" Material="{StaticResource SunsetMaterial}"/>
</ModelVisual3D>
</ModelVisual3D.Children>
</ModelVisual3D>

</Page.Resources>

<DockPanel>
<Viewbox>

<!—La animación del cubo. -->
<Viewport3D ClipToBounds="True" Width="400" Height="300">
<Viewport3D.Camera>
<PerspectiveCamera x:Name="myPerspectiveCamera"
LookDirection="0,0,-1" UpDirection="0,1,0"
Position="0,0,2.1"
FieldOfView="50" />
<!—dirección,prespectiva,pocición con la que la camara muestra el
cubo -->
</Viewport3D.Camera>
<ModelVisual3D>
<ModelVisual3D.Children>
<ModelVisual3D>
<AmbientLight Color="#333333" />
</ModelVisual3D>
<ModelVisual3D>
<DirectionalLight Color="#FFFFFF" Direction="-
0.612372,-0.5,-0.612372" />
</ModelVisual3D>
<ModelVisual3D>
<DirectionalLight Color="#FFFFFF" Direction="0.612372,
-0.5,-0.612372" />
</ModelVisual3D>
<ModelVisual3D>
CubeSide01}" Material="{StaticResource BranchesMaterial}"/>
</ModelVisual3D>
<!—material 3D que carga para cada cara del cubo -->

<ModelVisual3D>
CubeSide02}" Material="{StaticResource FlowersMaterial}"/>
</ModelVisual3D>
<ModelVisual3D>
CubeSide03}" Material="{StaticResource BerriesMaterial}"/>
</ModelVisual3D>
<ModelVisual3D>
CubeSide04}" Material="{StaticResource LeavesMaterial1}"/>
</ModelVisual3D>
<ModelVisual3D>
CubeSide05}" Material="{StaticResource RocksMaterial}"/>
</ModelVisual3D>
<ModelVisual3D>

CubeSide06}" Material="{StaticResource SunsetMaterial}"/>
</ModelVisual3D>
</ModelVisual3D.Children>

<ModelVisual3D.Transform>
<Transform3DGroup >
<Transform3DGroup.Children>
<RotateTransform3D>
<RotateTransform3D.Rotation>
<AxisAngleRotation3D x:Name="myHorizontalRotation"
Angle="0" Axis="0 1 0" />
</RotateTransform3D.Rotation>
</RotateTransform3D>
<RotateTransform3D>
<RotateTransform3D.Rotation>
<AxisAngleRotation3D x:Name="myVerticalRotation" A
ngle="0" Axis="1 0 0" /><!—Angulo de rotación del Cubo -->

</RotateTransform3D.Rotation>
</RotateTransform3D>
<TranslateTransform3D x:Name="myTranslateTransform"
OffsetX="0" OffsetY="0" OffsetZ="0" />
<!—definicion de la translación del cubo -->
</Transform3DGroup.Children>
</Transform3DGroup>
</ModelVisual3D.Transform>
</ModelVisual3D>

<Viewport3D.Triggers>

<!—Animaciones del cubo despues de ser cargadas. -->
<EventTrigger RoutedEvent="Viewport3D.Loaded">
<BeginStoryboard>
<Storyboard>
<DoubleAnimation
Storyboard.TargetName="myVerticalRotation"
Storyboard.TargetProperty="Angle"
From="0" To="360" Duration="0:0:10"
RepeatBehavior="Forever" />
<!—Rotacion vertical de duración de 10 segundos --
>
<DoubleAnimation
Storyboard.TargetName="myHorizontalRotation"
Storyboard.TargetProperty="Angle"
From="0" To="360" Duration="0:0:9"
RepeatBehavior="Forever" />
</Storyboard>
</BeginStoryboard>
</EventTrigger>
</Viewport3D.Triggers>
</Viewport3D>
</Viewbox>
</DockPanel>

</Page>
Una vez creada la animación deberemos de ir a la carpeta que
contiene todos los Gadgets de la Sidebar. La ruta habitual
donde la encontramos es la
siguiente C:UsersusuarioAppDataLocalMicrosoftWin
dows SidebarGadgets Dentro de dicha carpeta deberemos
de crear una con el siguiente formato: “Nombre
Gadget.gadget” en nuestro caso CUBO3D.gadget. En el

interior de esta carpeta colocaremos nuestro archivo XAML, y
también hemos de crear los archivos XML y HTML que definen
las propiedades y el objeto del Gadget (en nuestro caso la
animación XAML), pero vamos por partes.

El siguiente paso es crear el archivo XML, que debe tener la
siguiente estructura:
<?xml version="1.0" encoding="utf-8" ?>
<gadget>
<name>CUBO3D</name>
<namespace>Cesnavarra</namespace>
<version>1.0</version>
<author name="Cesnavarra">
<info url="http://www.cesnavarra.net" />
</author>
<copyright>2008</copyright>
<description>Gadget animacion 3Da través de un XAML</description>
<hosts>
<host name="sidebar">
<base type="HTML" apiVersion="1.0.0" src="default.html" />
<permissions>full</permissions>
<platform minPlatformVersion="0.3" />
</host>
</hosts>
</gadget>

El significado de cada etiqueta es el siguiente

<name></name>: En esta etiqueta colocaremos el nombre
de nuestro Gadget, en nuestro caso “CUBO3D”

<namespace></namespace>: Esta etiqueta define el
grupo al que asociaremos nuestros Gadgets con lo que
podremos gestionarlos de manera agrupada. Es una etiqueta
informativa y en nuestro caso lo haremos por ejemplo
mediante la agrupación “Cesnavarra”

<version></version>: La siguiente etiqueta nos indicara la
versión de nuestro Gadget para posteriores actualizaciones.

<author name="">: Indica el nombre del autor de Gadget

<info url="" />: Nos ayudará a definir una página de
referencia de nuestro Gadget.

<copyright></copyright>: Esta etiqueta indica los
derechos reservados de autor de nuestro Gadget.

<description></description>: La siguiente Etiqueta nos
ayudara a presentar información descriptiva sobre nuestro
Gadget.

La parte contenida en las etiquetas <hosts></hosts> no la
vamos a modificar ya que está predeterminada para el
Windows SideBar. Lo único que puede interesarnos modificar

va a ser el origen donde obtendremos el contenido de nuestro
Gadget, que se obtiene a través de una página HTML. El
nombre de este origen puede ser diferente al nombre del
Gadget. Ej. scr="default.html".

El archivo XML lo deberemos de nombrar Gadget.xml, ya que
esta es la manera que la Sidebar reconoce nuestro Gadget.

El penúltimo paso será crear nuestra página web de
presentación de nuestro Gadget:
<html>
<head>
<title>CUBO 3D</title>

<style>
body {
width:130;
height:130;
padding:5;
margin:0;
background:black;
}
</style>
</head>
<body>

<iframe height="130"
width="130"
src="3d_animation.xaml" />

</body>
</html>
Como se puede ver es una simple pagina en HTML donde lo
más importante la definición de la carga de nuestra animación
mediante un iframe.

Por último una vez creados todos los elementos
procederemos a incluir nuestro Gadget en la Sidebar de
Windows Vista de la siguiente manera:

En la Sidebar en la parte superior presionaremos la tecla más
lo que nos presentara todos los Gadget que tenemos
instalados en nuestro sistema, entre ellos nuestro CUBO
3D.Realizaremos doble click sobre este Gadget y aparecerá en
nuestra Sidebar.

Categ CES Microsoft
orías
Tema Desarrollo
Autor Raúl Mayo González
Mes Diciembre
Año 2008
Boletí 12
n

Título Copias de seguridad de un repositorio subversion.

Texto Si repasáis los artículos de este año encontrareis 2 artículos interesantísimos
que no deberíais perderos sobre la instalación y despliegue del controlador
de versiones de código Subversión.

En este artículo vamos a tratar con un poco más de profundidad el hecho de
realizar copias de seguridad de un repositorio Subversión ( SVN ).

Copias de un repositorio de SVN. se pueden hacer de varias formas,
podríamos partir incluso de copias basadas en comandos del propio sistema
operativo, tar, cp, xcopy, zip etc., podríamos utilizar gestores de copias
completos tipo los comerciales Backup Exec de symantec (antiguamente de
Veritas.) o como los open source “Bacula backup” o el freeware Cobian
Backup (aunque este gestor tiene alguna versión opensource). Pero nosotros

nos vamos a centrar en las herramientas que distribuye el propio SVN.

El SVN tiene un funcionamiento transaccional. Deberíamos tener en cuenta
que mientras se hacen las copias se pueden estar haciendo modificaciones
en los ficheros bajo el control de SVN y que por lo tanto tendremos nuevas
revisiones. El árbol de directorios y ficheros está fuertemente relacionado a
través revisiones y Vds, etc. para dar consistencia a SVN. En una palabra: es
un sistema complejo.

Digamos que debido a esto y a toda esas psicosis que rodean las gestiones de
copias de seguridad nos vamos a centrar en los propios comandos del SVN.
Éstos nos dan un conocimiento más fino de las modificaciones existentes en
el repositorio y además están pensados para garantizar las interrelaciones y
consistencia entre ficheros revisiones directorios etc. del entramado SVN.

Subversión permite hacer copias de seguridad con las siguientes
herramientas:

svnadmin hotcopy: permite hacer copias completas del repositorio en
caliente. En realidad es tan trivial como hacer una llamada al cp/copy del
sistema dependiendo de si el sistema es Unix o Windows.

svnadmin dump: permite generar ficheros de exportación e importación
“dump” de un repositorio concreto; svnadmin dump permite exportaciones
parciales hasta una revisión concreta o un rango de revisiones. Con el
modifica “–incremental” se pueden hacer ficheros de parciales incrementales
sin incluir las revisiones anteriores a la especificadas.

tools/backup/ hot-backup.py: esta herramienta se distribuye y se localiza en
el directorio “tools/backup”. Si no podríamos localizarlo en la siguiente
dirección, http://svn.collab.net/repos/svn/trunk/tools/backup/hot-
backup.py.in

Hot-backup es un script que nos va a permitir hacer copias calientes de
repositorios de SVN. Automáticamente gestiona los nombres de los ficheros
de backup por cada repositorio cuando tienes múltiples repositorios y se
preocupará de evitar las colisiones con los backups previos. Los backups
antiguos los calificará de “rótate off” borrándolos y conservando solo las
versiones de copia más recientes. Podría ser interesante estudiar un modo
de realizar copias incrementales con la herramienta.

Bien, ya hemos visto que SVN se preocupa por la coherencia de sus
repositorios y por eso dispone de 3 herramientas de volcado de datos. Tanto
hotcopy como hot-backup.py son muy fáciles de usar para realizar copias de
seguridad completas, sobre todo hot-backup.py que además ofrece un nivel
más fino de generación y automatización de copias.

Sin embargo nosotros nos vamos a basar en el svnadmin dump. El método

puede ser más elaborado pero nos va a permitir hacer backups más
personalizados y afinados, como por ejemplo backups incrementales. Sobre
esto último ni que decir tiene que un backup completo es el backup más
seguro y coherente que se puede realizar. Sin embargo cuando nuestros
repositorios empiezan a crecer en cuestión de tamaño, podemos tener otros
problemas como la cantidad de tiempo en la generación de las copias o el
tamaño de los ficheros a distribuir a través de nuestros sistemas hasta llegar
al sistema de archivados de copias, trafico de red, etc.

Las copias incrementales nos van a permitir aligerar las cargas de tráfico y
volumen de datos pero nos van a exigir más control en la gestión de copias.

Vale, para empezar debemos conocer los siguientes 2 comandos y unos
modificadores en particular:

Svnlook: interesante herramienta que distribuye el subversion. Esta
herramienta con sus distintos comandos y modificadores tiene como
objetivo mostrarnos información del repositorio. Tiene muchas opciones
pero para nuestros intereses hemos seleccionado estas tres:

svnlook –info [path/repositorio]

svnlook –info [path/repositorio] –r [ nº revision]

svnlook youngest [path/repositorio]

Por ejemplo:

#svnlook info /opt/Repositorios/PruebaRepo01

Kikorro

2002-11-04 09:29:13 -0600 (Mon, 04 Nov 2002)

57

¡¡¡ Esto martxaaaaaaaa : P !!! …… ¡¡¡ FIESTAAAAAAA !!!

Podemos observar por filas:

Nombre del usuario SVN: Kikorro

Fecha de la modificación : 2002-11-04 09:29:13 -0600 (Mon, 04 Nov 2002)

Número de caracteres del mensaje de modificación :27

Mensaje sobre la modificación : ¡¡¡ Esto martxaaaaaaaa : P !!!!

#svnlook info –r 19 /opt/Repositorios/PruebaRepo01

Kikorro

2002-11-05 09:29:13 -0600 (Mon, 04 Nov 2002)

14

1..2..3...14!

Vemos que la salida es igual que en el ejemplo anterior, pero esta vez nos
esta mostrando un resumen de la información de la revisión 19 (también
podemos observar que al usuario Kikorro se le va mucho la “olla” y que
cuenta tan mal como “Bono”)

Dejando a un lado las bromas, estas instrucciones las vamos a usar para
comprobar que tanto el repositorio como la revisión existen. En caso de que
el repositorio o la revisión fuesen incorrectos se nos mostrarían sendos
mensajes de error, además de devolver el valor estándar de error $? = 1.

La opción “youngest” del comando svnadmin nos va a mostrar la ultima
revisión del repositorio indicado. Por ejemplo :

#svnlook youngest /opt1/Repositorios/PruebaRepo01

19

Svnadmin dump/load: hay que decir que estas opciones están orientadas a
la exportación y migración de repositorios pero perfectamente nos sirven
para hacer copias de seguridad.

La opción “dump” a secas nos generará un volcado binario del repositorio
especificado. Se pueden especificar volcados hasta una revisión, hasta un
rango de revisiones y volcados incrementales de rangos de revisiones.

#svnadmin dump /opt/Repositorios/PruebaRepo01 >
PruebaRepo01_full.dump

#svnadmin dump /opt/Repositorios/PruebaRepo01 –r 15 >
PruebaRepo01_r15.dump

#svnadmin dump /opt/Repositorios/PruebaRepo01 –r 10:15 >
PruebaRepo01_r10_15.dump

#svnadmin dump /opt/Repositorios/PruebaRepo01 –r 16:19 --
incremental > PruebaRepo01_inc_r16_19.dump

Vamos a tratar de explicar la diferencia entre la fila 3 y la 4: SVN tiene el
siguiente comportamiento por defecto para la opción “dump”. Cada revisión
volcada debe poder ser restaurada por sí misma. Si es una revisión nueva no
hay ningún problema pero si la revisión esta basada en otras anteriores,
entonces en el fichero “dump” deben de existir las revisiones necesarias
anteriores para poder restaurarse las revisiones especificadas en el rango.
Como mínimo va a existir un volcado completo de la primera revisión del

repositorio.

Especificando el modificador “–-incremental” se cambia el comportamiento
por defecto de SVN. Evitaremos un volcado completo de la primera revisión
del repositorio pero debemos ser muy cuidadosos con los “dump” parciales
ya sean completos o incrementales si luego queremos restauraciones
coherentes.

Muy bien: hasta aquí sabemos que podemos hacer copias completas de
nuestros repositorios preferidos y que incluso podríamos diseñar una política
de copias incrementales por si nuestros repositorios son muy grandes o
queremos aligerar la carga de red. Ahora lo que debemos saber es cómo
restaurar estas copias que nos hemos feriado.

La opción “load” del comando svnadmin es la que andábamos buscando. Un
ejemplo básico:

#svnadmin load /opt1/Repositorios/PruebaRepo01 <
pruebaRepo01_full.dump.

Claro, éste es el caso más sencillo: la restauración desde una copia completa.

Bien en el caso de tener ficheros “dump” parciales incrementales,
deberemos tener en cuenta la advertencia que hemos hecho anteriormente
sobre la restauración coherente de la revisiones: si una revisión se basa en
una anterior, ésta ha de existir, así que siempre ha de haber una copia
completa desde de la que deben ir partiendo las copias incrementales y por
lo tanto la restauración de dichas copias deberá seguir un orden lógico con
respecto a las copias generadas.

Por ejemplo: secuencia de dumps.

#svnadmin dump /opt1/Repositorios/PruebaRepo01 -r 0:10 >
dumpfile1

#svnadmin dump /opt1/Repositorios/PruebaRepo01 -r 11:14 -
-incremental > dumpfile2

#svnadmin dump /opt1/Repositorios/PruebaRepo01 -r 15:19 -
-incremental > dumpfile3

Secuencia de loads.

dumpfile1

dumpfile2

dumpfile3

En el ejemplo anterior la primera instrucción equivale a una copia completa
hasta la revisión 10. También podríamos haberlo indicado de la siguiente
manera:

#svnadmin dump /opt1/Repositorios/PruebaRepo01 -r 10 >
dumpfile1.

Restaurar un repositorio; Para restaurar………en una noche de verano ….

¡¡CÓMO!! ¡¡QUEEEEEEE!! ¡¡Quée dice este ahora!! … ¿¿No bastaba sólo con el
load?? ….. ¡¡Por favor que acabe yaaaaaa!! (Los lectores digitales)

Queridos lectores: un poco de paciencia, que queda poco.

Para restaurar el repositorio, éste debe existir. “svnadmin load” no crea un
repositorio: carga un una copia generada con el comando svnadmin dump;
En caso de no existir el repositorio debemos recrearlo con la instrucción,
svnadmin create [repositorio].

Por ejemplo:

svnadmin create /opt1/Repositorios/PruebaRepo01

Si el repositorio está corrupto yo recomendaría eliminar el repositorio entero
y recrearlo desde nuestras propias copias. Como os dije en el primer párrafo
la creación y despliegue de un controlador de versiones SVN está detallado
en artículos anteriores así que ante la duda os emplazo a que les volváis a
echar un vistazo.

¡¡¡CONCLUSIONESSSS!!!.
Svnlook nos da mucha información del repositorio SVN, pero nos va permitir
verificar que existe un repositorio o determinada revisión. Además podemos
saber a que revisión corresponde la última modificación registrada en SVN.

Svnadmin dump/load nos permite hacer y recargar volcados a fichero de
nuestros repositorios SVN, además con control por revisiones, de forma
incremental, etc.

Vemos que tenemos un control muy fino de lo que queremos hacer. Sin
embargo se me antoja un poco complicado automatizar todo esto.

Vale, no os preocupéis le doy unas vueltas a todo esto: repasamos un poco
de shell script y nos montamos un “pseudo script” que haga uso de estos

comandos y pueda ser llamado desde un “cron” para automatizar el sistema.

Enlaces de interés:

http://benr75.com/2007/04/24/backing-up-subversion-using-hot-backup-py

http://svnbook.red-bean.com/en/1.1/ch05s03.html

http://svnbook.red-bean.com/en/1.1/ch05s02.html

Categorías CES OpenSouce/Java

Tema Varios

Autor Kike Muro Arbizu

Mes Diciembre

Año 2008

Boletín 12

Título Ontologías

Texto En el artículo XML, RDFS, Ontologías: Camino a la Web semántica, se comenzó a
dar una primera visión de las ontologías, sin embargo quedaron muchos cabos
sueltos y no se llegó a profundizar.

Actualmente, no es algo muy extendido, pero ya comienza a haber iniciativas
como la extensión de MediaWiki (la Wikipedia utiliza este
software)Extensions:Semantic MediaWiki, que pretende incluirlas en las páginas
de esta Wiki. Por otra parte, Swoogle, es un buscador de la Web semántica que
permite buscar entre otras cosas ontologías y recursos de la misma.

A continuación se intentará explicar los pasos necesarios para la creación de una
de ellas. Y se irán ilustrando mediante un ejemplo de creación de ontologías
muy sencillo empleando el lenguaje OWL y en formato XML. Una ontología en
OWL está formada por individuos (son instancias de clases), propiedades (al
darles valores se crean las individuos) y clases.

En términos prácticos, el desarrollo de una otología incluye:

 Definir las clases de la ontología.

Proyecto piloto TDT: parte 4: fase 2

Proyecto piloto TDT: parte 4: fase 2

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Proyecto piloto TDT: parte 4: fase 2

Ähnlich wie Proyecto piloto TDT: parte 4: fase 2 (20)

Mehr von Cein

Mehr von Cein (20)

Proyecto piloto TDT: parte 4: fase 2