SlideShare ist ein Scribd-Unternehmen logo
1 von 51
Downloaden Sie, um offline zu lesen
Título                               Dilbert.
Texto    El humor es uno de los ingredientes que nos hacen la vida
         más agradable.
         Dentro de él, el humor gráfico tiene muchas vertientes: desde
         aquéllos que apenas necesitan acompañar las imágenes con
         palabras para hacernos esbozar una sonrisa, como Sempé1,o
         uno de sus más aventajados seguidores, Quino2. Éste último
         es sobre todo conocido por su tira cómica del
         personaje Mafalda3.

         La tira TIC por excelencia es Dilbert, creada por Scott Adams.
         Su éxito es tal que incluso ha inspirado el llamado Principio de
         Dilbert, que es una variación del de Peter.

         En la misma aparecen una serie de personajes alrededor del
         mundo del trabajo en una compañía dedicada a producir
         productos tecnológicos (no podemos concretar más puesto
         que una de las características es el caos que acompaña a
         dicha empresa).
         Así, aparte del propio Dilbert, un ingeniero, están su colega
         Wally, el Jefe, Dogbert, la mascota de Dilbert y que actúa
         como consultor (!), etc.
Las situaciones reflejadas en Dilbert son las cotidianas en una
empresa, sazonadas con un tono mordaz y absurdo pero, a la
vez, fiel reflejo de la realidad.

Adams no deja títere con cabeza y abarca todos los conceptos
que rigen la actividad de una empresa, empezando por la
orientación al cliente:
    - (Jefe): Nos tenemos que preguntar constantemente lo
       qué podemos hacer para tener contentos a nuestros
       clientes.
    - (Alice): Podríamos dejar de hacer estas reuniones,
       echar a todos los presentes y reducir los precios de
       nuestros productos.
    - (Jefe): Estaba pensando más bien en un eslogan...
    - (Wally): ¿Qué tal: 'Despilfarramos su dinero'?

Siguiendo por la, a veces, difícil relación entre los
departamentos comerciales y técnicos:
   - (Dilbert): Stan, le prometiste cosas al cliente que el
      departamento de ingeniería no puede realizar. ¿Sabes
      lo que eso significa?
   - (Stan): Significa que soy un gran vendedor y tú eres
      un mal ingeniero. Tal vez te convendría tomar clases
      nocturnas.
   - (Dilbert, pensando): Sí, de karate.

Por supuesto las relaciones entre jefe y empleado son objeto
de numerosas tiras:
   - (Jefe): Alice, me cuentan que pasas tiempo con tu
      familia por la noche. Este tiempo lo podrías aprovechar
      para trabajar sin cobrar extra.
   - (Alice): ¿Tiene usted familia?
   - (Jefe, pensando): Hmmm... Eso explicaría la gente que
      hay en mi casa...
                             ●●●
   - (Jefe): Hemos rediseñado el organigrama para mostrar
      la Dirección en el rango más bajo. Como símbolo de
      cómo apoyan a nuestros empleados más importantes.
   - (Dilbert): Pregunta: ¿por qué los empleados más
      importantes son los que menos cobran?
   - (Jefe): Porque a ellos nunca se les ocurrirían ideas
      como este concepto de organigrama invertido.
                             ●●●
   - (Dilbert): Aquí tiene mi hoja de horas trabajadas,
      rellenada en incrementos de quince minutos. Y aquí
      tiene mi informe de estado mensual, mi previsión de
      gastos, mis trabajos cumplidos, mi lista de peligros...
   - (Jefe, pensando): Nunca tan poco se ha medido tanto.
                             ●●●
   - (Jefe): Aunque técnicamente soy 'El Jefe', creo que es
      mi trabajo proporcionarles los recursos necesarios a
      ustedes, los empleados.
   - (Dilbert): Necesito más dinero para mi proyecto.
   - (Jefe): Lo siento. Ya no queda nada.
   - (Dilbert): Tal vez le pida una cita para poder hablar del
      tema.
-   (Jefe): Tengo veinte minutos en mi agenda, pero
       habrá que esperar hasta el verano que viene.

Las reuniones, cómo no, dan también mucho argumento:
   - (Wally, a Dilbert): Aquí tienes la tarjeta de bingo para
      la reunión. Si el jefe utiliza una palabra clave que
      aparece en tu tarjeta, la tachas. El objetivo es tachar
      una línea.
   - (Jefe): Hoy están todos muy atentos. Veo que mi
      liderazgo proactivo está surtiendo efecto.
   - (Wally): Bingo, señor.

Y también las certificaciones:
   - (Jefe): Te nombro responsable de nuestro proyecto
      para conseguir la certificación 'ISO 9000'. No sabemos
      de qué se trata, pero queda muy bonito en los folletos
      de empresa.
   - (Dilbert): Creo que certifica que seguimos procesos
      consistentes.
   - (Jefe): Sí... Siempre mentimos en nuestros folletos.

También hay nuevas incorporaciones a las que cuidar:
  - (Jefe): Matt acaba de salir de la escuela de ingenieros.
     Tú vas a ser su mentor. Hagas lo que hagas no le
     aplastes el espíritu antes del miércoles.
  - (Dilbert): ¿Por qué aplazarlo tanto?
  - (Jefe): Porque aposté 10 pavos a que podríamos hacer
     que aguante hasta el jueves.

Así como funciones que clarificar:
   - (Dilbert): Como todos saben, me han nombrado líder
      del equipo.
   - (Alice): ¿Decides los aumentos de sueldo?
   - (Dilbert): No.
   - (Alice): ¿Apruebas los gastos?
   - (Dilbert): No.
   - (Alice): ¿Puedes despedir a la gente?
   - (Dilbert): No. Soy un líder, no un jefe.
   - (Alice): Bien, vete y nosotros te seguiremos.

Finalmente, se satiriza lo absurdo que, a veces, es la
tecnología:
   - (Ordenador): Para configurar la aplicación, introduzca
      el nombre del ganador del año que viene del Oscar al
      mejor actor.
   - (Dilbert teclea algo)
   - (Ordenador): Por favor, espera.

Algunos de los dogmas de Dogbert:
     Todos los trabajos son asignados a la persona que
      menos los entiende.
     Todas las empresas necesitan una estrategia para que
          los empleados sepan cuál no es su trabajo.
          Un optimista no es más que un pesimista sin
          experiencia laboral.
          Todos los rumores son auténticos... sobre todo si tu
          jefe los desmiente.
          Cualquier estrategia acertada parecerá ridícula cuando
          se lleve a cabo.
          Lo que haces es mucho menos impresionante de lo
          que implica tu cargo.
          Un experto es una persona que ha sido asignado a un
          trabajo para expertos. No se necesitan más
          cualificaciones.

Se atribuye a Guy Kawasaki la siguiente frase: 'Hay dos tipos
de compañías, las que reconocen que son exactamente como
la de Dilbert y las que también lo son pero aún no lo saben.'

Puede parecer que lo aquí expresado sólo serviría como
desahogo para personas quemadas. Pero si bien esto es
cierto, quedarse en este estadio sería simplificar las cosas.
En mi opinión las tiras de Dilbert, y otros libros de Scott
Adams, sirven como diagnóstico y reflejo de una realidad que
sirven para desdramatizar situaciones pero no para olvidarlas,
sino corregirlas.
Además cuando uno ve que en todos los sitios cuecen habas,
empieza a relajarse y a reírse de sí mismo, lo cual suele ser
un signo de inteligencia.

¿Una última perla? ¡Venga!
   - (Ejecutivo): Yo pronostico que no venderemos nada
      durante los dos primeros años, y que después
      despegarán repentinamente.
   - (Dilbert): ¿Por qué?
   - (Ejecutivo): El aumento lo añadí para que me
      aprobaran el proyecto. El plazo de dos años me da
      tiempo para que me asciendan.
   - (Dilbert): ¿Y qué hay de las responsabilidades?
   - (Ejecutivo): Aquí es donde entras tú en juego.

Quien piense que este es un artículo frívolo, puede leer el
último libro de Tom DeMarco y compañeros, que también
trata todos estos temas.

Referencias:
    La tira diaria.
    Libros en español.
    Adrenaline      Junkies  and     Template    Zombies:
      Understanding Patterns of Project Behavior.

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           Desarrollo
Autor          Carlos Urtasun
Mes            Septiembre
Año            2008
Boletín        09




Títul                       XSL-FO (Parte 3): objetos.
o
Text Ahora que ya hemos dado el formato al documento, vamos a ver los
o     tipos de objetos que pueden aparecer en el mismo.
        Imágenes
        Este elemento, por sí mismo se considera un objeto inline: sin
        embargo, se puede convertir en otro de nivel de bloque incluyéndolo
        en un objeto como fo:block.
        <fo:block text-align="center">
        <fo:external-graphic width="8mm" height="15mm"
        src=” file:../graphics/image.gif” />
        </fo:block>


        Líneas guía

        El elemento que crea una línea guía es fo:leader. Debe ir dentro de
        un elemento block.
        Contiene el atributo leader-pattern con los posibles valores space,
        rule, dots, use-content e inherit. Su estilo viene definido por rule-
        style, y su longitud por leader-length. Su grosor lo define rule-
        thickness.

        En el ejemplo, se crea lo que suele ser un formato de fecha:
        Fecha:_______ de_________ de______

        <fo:block text-align="center">
               Fecha: <fo:leader leader-pattern="rule"
        leader-length="8mm"
        rule-thickness="0.3mm"/>
               de <fo:leader leader-pattern="rule"
        leader-length="30mm"
        rule-thickness="0.3mm"/>
               de <fo:leader leader-pattern="rule"
        leader-length="10mm"
        rule-thickness="0.3mm"/>
        </fo:block>
Tablas
Son objetos de formato de nivel de bloque.
El elemento es fo:table. Se debe definir el número de columnas que
tiene la tabla en fo:table-column con el ancho de cada una de
ellas, en su atributo column-width. Lo siguiente es crear el cuerpo de
la tabla con sus filas y sus celdas, donde se pintan los datos.
Las tablas también pueden tener cabecera (table-header) y pie
(table-footer).
Esto se ve claramente en un ejemplo:
<fo:block space-before="3mm">
<fo:table table-layout="fixed">
       <fo:table-column column-width="15mm" />
              <fo:table-column column-width="20mm"
number-columns-repeated=”2”/>
              <fo:table-footer>
<fo:table-row>
<fo:table-cell number-columns-
spanned="3">                            <fo:block text-
align="end" font-size="7pt">
Este es el pie de la tabla
</fo:block>
</fo:table-cell>
                     </fo:table-row>
              </fo:table-footer>
              <fo:table-header>
                     <fo:table-row keep-with-next="always">
                            <fo:table-cell>
                                   <fo:block>
                                                  <xsl:text>&#160;</
xsl:text>
                                   </fo:block>
                            </fo:table-cell>
<fo:table-cell display-align="center" border-bottom-
width="1pt" border-bottom-color="black" border-bottom-
style="solid" padding-after="1mm" padding-before="1mm">
                                   <fo:block text-align="start" font-
size="8pt">                                               <xsl:text>
cabecera columna 2
</xsl:text>

                                  </fo:block>
                            </fo:table-cell>
<fo:table-cell display-align="center" border-bottom-
width="1pt" border-bottom-color="black" border-bottom-
style="solid" padding-after="1mm" padding-before="1mm">
<fo:block text-align="start" font-size="8pt">
<xsl:text>
cabecera columna 3
</xsl:text>
                                  </fo:block>
                            </fo:table-cell>
                     </fo:table-row>
</fo:table-header>
             <fo:table-body>
<fo:table-row keep-with-next="always">
                          <fo:table-cell>
                                <fo:block>
                                                <xsl:value-
of select="@dato1"/>
</fo:block>
                          </fo:table-cell>
<fo:table-cell>
                                 <fo:block>
                                       <xsl:value-
of select="@dato2"/>
</fo:block>
                          </fo:table-cell>
<fo:table-cell>
                                <fo:block>
<xsl:value-of select="@dato3"/>
</fo:block>
                          </fo:table-cell>
</fo:table-row>
             </fo:table-body>
      </fo:table>
<fo:block>

A destacar el atributo number-columns-repeated en fo:table-column,
que nos dice el número de columnas de ese mismo tamaño a crear.
A todas las celdas se les puede pintar borde superior, inferior,
derecho o izquierdo, de diferente grosor, color y tipo. Además, con
el atributo display-align, le decimos en qué lugar en vertical de la
celda, mostrar el contenido. Para que no se produzca un salto de
página entre filas, se usa el atributo keep-with-next, o keep-with-
previous.

Listas
Para formar una lista se utiliza el elemento fo:list-block. Es un
contenedor de ítems que se muestran en forma de lista. Cada uno
de estos elementos, contiene un fo:list-item que es cada ítem de la
lista, el cual contiene una etiqueta (fo:list-item-label) y su
contenido (fo:list-item-body).

Hay varios atributos importantes para crear una lista, a saber:
provisional-distance-between-starts: es un atributo de list-block. Nos
dice la distancia que hay entre el comienzo del área de la etiqueta y
el comienzo del área del contenido del ítem. Este valor no se usa
directamente, sino que vale para calcular la función body-start().
provisional-label-separation: es un atributo de list-block. Nos marca
la distancia que hay entre el final de la etiquta y el principio del
contenido del ítem. Este valor no se usa directamente, sino que vale
para calcular la función label-end().
La función body-start() se usa como valor del atributo start-indent
del elemento fo:list-item-body, y la función label-end() se usa como
valor del atributo end-indent del elemento fo:list-item-label.




Ejemplo:
<fo:list-block provisional-distance-between-starts="20mm"
provisional-label-separation="10mm">
       <fo:list-item>
               <fo:list-item-label end-indent="label-end()" start-
indent="6mm">
                      <fo:block>&#x2022;</fo:block>
               </fo:list-item-label>
               <fo:list-item-body start-indent="body-start()" end-
indent="90mm">
                      <fo:block>contenido1</fo:block>
               </fo:list-item-body>
       </fo:list-item>
       <fo:list-item>
               <fo:list-item-label end-indent="label-end()" start-
indent="6mm">                            <fo:block>&#x2022;</fo:blo
ck>
               </fo:list-item-label>
               <fo:list-item-body start-indent="body-start()" end-
indent="90mm">
                      <fo:block>contenido2</fo:block>
               </fo:list-item-body>
       </fo:list-item>
</fo:list-block>


Notas a pie de página
El objeto fo:footnote define una nota a pie de página dentro de
region-body de una página. Tiene dos hijos: fo:inline (referencia de
la nota) y fo:footnote-body (contenido de la nota).
Ejemplo:
<fo:block font-size="10pt">Este es el texto en el que voy a insertar
una
       <fo:footnote>
              <fo:inline>nota</fo:inline>
<fo:inline vertical-align="super">1</fo:inline>
             <fo:footnote-body>
                   <fo:block>1. Este es el contenido de la
nota</fo:block>
             </fo:footnote-body>
      </fo:footnote>
      aquí sigo con el texto
</fo:block>

Si a este ejemplo le añadimos leader y list, quedaría así:

<fo:block font-size="10pt">Este es el texto en el que voy a insertar
una
      <fo:footnote>
             <fo:inline> nota</fo:inline>
             <fo:inline vertical-align="super">1</fo:inline>
             <fo:footnote-body>
                   <fo:block text-align-last="justify">
                           <fo:leader leader-pattern="rule"/>
                   </fo:block>
                   <fo:list-block>
                           <fo:list-item>
                                  <fo:list-item-label end-
indent="label-end()">

                                                  <fo:block>1</fo:bl
ock>
                                  </fo:list-item-label>
                                  <fo:list-item-body start-
indent="body-start()">
                                        <fo:block>
Este es el contenido de la nota
</fo:block>
                                   </fo:list-item-body>
                            </fo:list-item>
                    </fo:list-block>
             </fo:footnote-body>
</fo:footnote>
aquí sigo con el texto
</fo:block>

Marcadores (Runnig headers)
Se suele utilizar en cabecera o pie de página para mostrar algún
texto, como por ejemplo, en los diccionarios en los que en la
cabecera se muestra la primera palabra por la que empieza esa
página y la última en la que acaba. Su contenido cambia en función
del flujo.
Consta de dos elementos necesarios: fo:marker y fo:retrieve-
marker.
El elemento fo:marker nos dice qué texto queremos que se pinte. Se
suele colocar dentro de un block. Tiene un atributo marker-class-
name que contiene el nombre del marcador.
El elemento fo:retrieve-marker se suele colocar en la cabecera o el
pie (siempre en un fo:static-content), lugar donde se pintará. Tiene
el atributo retrieve-class-name con el nombre del marker que
queremos mostrar, es decir, el valor de marker-class-name deberá
coincidir con el valor de retrieve-class-name. Este elemento tiene
además otro atributo interesante, retrieve-position que nos indica la
posición del texto a mostrar, es decir, si mostrará la primera o la
última
Ejemplo:
En el flow: (Es como si dijéramos: utilice este contenido cuando
quiera el contenido del marker llamado título)

<fo:block>
      <fo:marker marker-class-name="titulo">
<fo:block>
<xsl:value-of select="."/>
</fo:block>
</fo:marker>
</fo:block>

En el static-content:

<fo:block>
<fo:retrieve-marker retrieve-class-name="titulo"
retrieve-position="first-starting-within-page"
retrieve-boundary="page"/>
</fo:block>

Enlaces
El elemento que introduce los enlaces es el fo:basic-link. El enlace
a un documento remoto, lleva su URI en el atributo external-
destination. Si el enlace te lleva al mismo documento, la URI va en
el atributo internal-destination. Así, un basic-link solo tendrá uno de
estos dos atributos. El documento destino se puede elegir dónde
abrirlo gracias a otro atributo: show-destination. Si su valor es new,
se abre en una nueva ventana, y si es replace, se cargará en la
misma ventana. Esta última opción es la que viene por defecto.
<fo:block>
       <fo:basic-link external-destination="http://www.google.es">
               Enlace
       </fo:basic-link>
</fo:block>


En el siguiente ejemplo, vamos a ver cómo se haría un índice con
enlaces a las propias páginas del documento:


<fo:block font-size="18pt" font-weight="bold" text-align="center">
      Índice
</fo:block>
     <fo:block text-align-last="justify">
           <fo:basic-link color="blue" internal-destination="capitulo1">
                   Título 1
           </fo:basic-link>
           <fo:inline keep-together.within-line="always">
                   <fo:leader leader-pattern="dots"/>
                   <fo:page-number-citation ref-id="capitulo1" />
           </fo:inline>
     </fo:block>
     <fo:block id="capitulo1" break-before="page" font-size="18pt">
           Título 1
     </fo:block>



     Referencias:
     http://zvon.org/xxl/xslfoReference/Output/index.html

Cate CES OpenSouce/Java
gorí
as
Tem Varios
a
Auto Raquel Urdangarin
r
Mes Septiembre
Año 2008
Bole 09
tín




Título                   Implantación de Nagios (Parte 2).
Texto TOPOLOGIA E INTERPRETACIÓN DE RESULTADOS

         En el anterior artículo descubrimos Nagios y analizamos la forma
         de instalarlo en nuestra red. Esta parte pretende ajustar la
         configuración de los recursos que monitorizar a nuestras
         necesidades.



         1 Configuración de los parámetros de funcionamiento:
         La forma de configurar nagios para adaptarlo a nuestros
         requerimientos es editar varios ficheros de configuración.
Definición de máquinas a monitorizar: tendremos que añadir a
/etc/nagios/hosts.cfg una nueva entrada por cada host, respetando
una "plantilla":
define host{
use generis-host ; Nombre de la plantilla a utilizar
host_name irati ; Nombre de la máquina
alias Javacenter Server 1 ; Alias
address 192.168.14.145 ; IP
      check_command check-host-alive ; Comando que utilizamos
      para comprobar la disponibilidad de la maquina
max_check_attempts 10 ; Opciones de chequeo y notificación...
notification_interval 120 ;
notification_period 24x7 ;
notification_options d,u,r ;
}



En esta plantilla vemos los parámetros que definirán el host, como
nombre y alias, la dirección de red. Además de estos podemos
definir como se va a comprobar la disponibilidad de la máquina
(check_command) y parámetros de intentos de comprobación y
notificación de alertas.
Definición de grupos de máquinas: es útil para separar redes o
diferenciar tipos de máquinas. Tenemos que editar otro fichero
(hostgroups.cfg). La dinámica es similar a la de hosts.cfg (y a la de
todos los ficheros de configuración)
define hostgroup{
hostgroup_name printers
alias Javacenter Printers
contact_groups admins
members printer1,printer2
}
El grupo tiene un nombre, un alias, un grupo de contacto y los
miembros. En este caso mostramos el grupo de las impresoras.



Definición de monitoreo de servicios, este es uno de los
ficheros trascendentales para el perfilar el monitoreo, en el fichero
services.cfg se definen todos los servicios que se van a checkear
en cada hot.
define service{
use generic-service ; Nombre del “servicio plantilla” a usar
host_name gw,kirnis,isis,mider,rea,isthar
service_description PING
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 5
retry_check_interval 1
contact_groups admins
notification_interval 240
notification_period 24x7
notification_options c,r
check_command check_ping!100.0,20%!500.0,60%
}



Al definir el servicio incluiremos el host o hosts a los que se les va
aplicar, una descripción, parámetros de checkeo, reintentos y
notificaciones, y además el comando que vamos a usar en el
servicio. Como se ve en el ejemplo, el comando es
check_ping!100.0,20%!500.0,60%
Realmente el comando llama a un plugin (que previamente ha sido
instalado) y le pasa los parámetros adecuados en cada caso,
porque dependiendo del plugin necesitara unos u otros. Aunque
seguramente siempre estén los umbrales que definen en qué
situación está el servicio que queremos monitorizar.
El modo de funcionamiento de nagios es comprobar en qué estado
se encuentra el recurso observado. Estos estados se establecen
en la definición del servicio y suelen ser ESTADO NORMAL,
ALERTA y CRITICO aunque dependerá del plugin en cada
caso.
Si por ejemplo queremos monitorizar el estado en el que se
encuentra el disco duro de una máquina, establecemos que un uso
menor de 60% es el estado NORMAL, entre 60% y 90% ALERTA y
más de 90% CRITICO. Una vez definido el servicio, el demonio de
nagios consultará el plugin correspondiente y mostrará el resultado
obtenido en la interfaz web. La sintaxis seria la siguiente:
check_disk!40%!10%!/dev/sda1 ( los umbrales y el dispositivo a
monitorizar )
Los plugins en este caso están instalados
en /usr/lib64/nagios/plugins/ y podemos ver desde monitores
de la carga del procesador, el estado de la RAM o de servicios http
como servidores ftp o web. Además de los proporcionados por
nagios existen numerosos creados por la comunidad.
Hay que tener en cuenta que estos plugins sólo son capaces
de trabajar en modo local, es decir, sólo pueden trabajar con
datos de la máquina en la que se ejecutan. Para poder monitorizar
datos remotos necesitamos la ayuda de otro
plugin (check_nrpe) que hace de proxy entre el demonio de
nagios y los plugins que se encuentran en la máquina remota.
Lógicamente en la máquina remota también estará ejecutándose
otro demonio o servicio que se encargará de recoger la petición del
plugin desde el servidor, llamare al plugin correspondiente y
devolver el resultado al servidor, como hemos comentado antes.
Entonces para definir un servicio remoto debemos utilizar siempre
el plugin check_nrpe, con lo que la sintaxis quedaría de la siguiente
forma:
check_nrpe!check_disk!c:!150!200
Se le llama al nrpe y como argumentos se le pasa el plugin a
ejecutar con sus respectivos umbrales. Hay que tener en cuenta
que la definición del comando puede ser sensible al sistema
operativo de la máquina.
Comentar que también en cada máquina remota a monitorizar hay
que configurar el demonio que atienda las peticiones del plugin
check_nrpe y copiar los plugins que vayamos a necesitar. Habrá
que adecuar a nuestra configuración un fichero de configuración
(nrpe.cfg) en el que se definen el puerto, los clientes aceptados, si
se utiliza ssl, y demás parámetros de funcionamiento, así como los
plugins ofertados. Por ejemplo si queremos que se pueda acceder
al plugin de comprobación de uso de disco, tenemos que definirlo,
indicar la ruta al ejecutable y establecer la forma en la que se le
pasarán los argumentos



command[check_disk]=C:nrpe_ntpluginsdiskspace_nrpe_nt.exe
$ARG1$ $ARG2$ $ARG3$



De esta forma iremos definiendo los servicios que nos interesen y
podremos empezar a recoger los datos devueltos. Además se
pueden definir grupos de contacto, formas de notificación y
estructuras que nos faciliten el tratamiento de esa información.



2 Visualización de los datos recogidos por Nagios:
Parte de los requerimientos de la instalación de Nagios eran
disponer de servidor Apache2 y de un sistema de archivado de los
datos recogidos que varía entre un sistema basado en ficheros de
texto o basados en bases de datos relacionales. En este ultimo
caso podíamos optar entre un motor de base de datos MySQL o
PostGresSQL: nosotros hemos optado por MySQL.
La visualización y cierto grado de gestión de Nagios se hacen a
través de un interfaz web que se integra en Apache2 durante el
proceso de instalación.
Existen otros de interfaces gráficos desarrollados por terceros más
ricos y amigables. Sin embargo hemos probado el que ya viene
montado en la distribución de Nagios. La elección de otros tipos de
herramientas de para interactuar con Nagios queda para otro
momento.
Repasar todas las opciones del interfaz gráfico llevaría mucho
tiempo, así que hemos seleccionado 4 muestras. Aunque hay
muchas más hemos seleccionado éstas porque representan el
estatus de los servicios que monitorizamos, reflejan el
almacenamiento y registro de los datos recogidos y la
configuración de servicio.
Service Detail: esta captura representa la opción service detail.
Esta opción está localizada en la zona “Monitoring” y muestra el
estado de todos los servicios definidos para ser monitorizados.
Alert History, localizado en la zona “Reporting”, nos muestra un
histórico de las alertas producidas.




Notifications, también en la zona Reporting, muestra las
notificaciones realizadas (esto todavía esta en fase de
implementación)
host: esta opción está localizada en la zona configuration.
Deberemos seleccionar qué aspecto de la configuración de nagios
queremos observar, ya sean los servicios, los host, plugins etc. En
este caso hemos seleccionado “host”, que representa las
estaciones de trabajo, servidores e impresoras.
Categ CES OpenSouce/Java
orías
Tema Arquitectura
Autor Igor Unanua
Mes    Septiembre
Año    2008
Boletí 09
n




Títu              Proyecto piloto TDT: parte 1: definición
lo
Tex 15 de Octubre del 2006: “Has sido seleccionado para
to   Responsable del Centro Java y Open Source”, no cabía en mi de
     gozo...eso ayudaría a afrontar lo que se avecinaba, “el 23 de
     Noviembre hay una reunión en NGA para conocer la
encomienda del proyecto que nos han encargado y para
presentarte como responsable, hazlo bien, mucho depende de
este proyecto”.

Esta frase marcaría mi periplo durante el 2007, cuya
experiencia trataré de transmitir a lo largo de este y los
próximos artículos.

Así pues, allí me encontraba, el 23 de noviembre, esperando mi
bautismo como “responsable” ante NGA y Gobierno, frente a un
conjunto de personas que posteriormente se perfilarían como el
comité de seguimiento y la dirección del proyecto, es decir, las
personas con las que tenía que trabajar y aquellas a las que
debía informar.

En esa dirección estábamos yo, como responsable, una persona
de NGA y otra de la DGpSI. Nuestras funciones consistían en
dirigir el avance del proyecto llevándolo a buen puerto,
cumpliendo los objetivos marcados, tomando las decisiones
pertinentes y llevando a cabo las acciones necesarias, todo de
forma consensuada. Así mismo, este equipo debía rendir
cuentas ante el comité sobre el avance y acciones. Este comité
lo formaban representantes de CEIN, NGA y DGpSI.

Esa reunión nos puso caras a todos y nos fue entregada
oficialmente la encomienda del proyecto que llevaba por título:

PLIEGO DE PRESCRIPCIONES TÉCNICAS DE LA ENCOMIENDA A
NGA PARA EL DESARROLLO EN LOS CENTROS DE EXCELENCIA
DE UN PROYECTO PILOTO PARA EL DISEÑO E IMPLANTACIÓN
DE UNA PLATAFORMA SOFTWARE PARA DESARROLLAR Y
MANTENER SERVICIOS INTERACTIVOS A TRAVES DE LA
TELEVISIÓN DIGITAL TERRESTRE (TDT)

A continuación resumo los puntos más importantes:

     ¿Porque la TDT y su papel para la administración?
     La tendencia actual es que la información sea accesible
     desde cualquier parte y con cualquier terminal. La
     familiaridad, comodidad, penetración y alcance de la TV
     la convierten en un dispositivo preferente para extender
     la Sociedad de la Información, para favorecer
     participación del tele-espectador (interactividad) y reducir
     la “brecha digital”: aquella población sin posibilidades de
     acceder a Internet por edad, reticencia, disposición,
     educación o poder adquisitivo.

     Por tanto, la TDT permite acercar la administración
electrónica a aquellos ciudadanos a los que resulta difícil
    llegar   a    través    de   Internet:   ancianos,   niños,
    discapacitados, desempleados, ciudadanos con retas más,
    menor formación, etc, proporcionando a la ciudadanía un
    nuevo canal de Servicios Administrativos de interés
    público y la posibilidad de participar = una sociedad de la
    información amplia, participativa y democrática.

    Objetivos
   Creación de aplicaciones sobre el estándar MHP
    (Multimedia Home Platform) que permitan la integración
    de contenidos interactivos en la TDT (Televisión Digital
    Terrestre), y establecer un nuevo canal entre la
    Administración y los ciudadanos potenciando el desarrollo
    de la e-Administración.
   Aprendizaje y transferencia de conocimiento a las
    empresas del sector TIC de Navarra mediante el
    desarrollo del proyecto en los Centros de Excelencia.
    Había una serie de objetivos añadidos entres lo que cabe
    destacarse: potenciar      la TDT      y modernizar    la
    administración.

    Alcance del proyecto
   Definición de especificaciones y puesta en marcha de la
    plataforma tecnológica necesaria para la generación y
    mantenimiento de aplicaciones interactivas en TDT sobre
    el estándar MHP.
   Desarrollo de un conjunto de servicios hacia el ciudadano
    (priorizando los correspondientes a la Hacienda
    Tributaria),   que     abarquen    todas   las   tipologías
    (Informativos, Interactivos y Transaccionales).
    Plan inicial
    La ejecución no podrá exceder 12 meses desde la
    formación del equipo de trabajo. En cualquier caso los
    trabajos estarán finalizados a 31 de diciembre de 2007.

   Fase I: transferencia de conocimiento al equipo de
    trabajo, análisis funcional, especificación y puesta en
    marcha de la plataforma tecnológica necesaria para la
    generación y mantenimiento de aplicaciones interactivas
    en TDT sobre el estándar MHP
   Fase II: implantación de servicios informativos sobre la
    plataforma base de Televisión Digital
   Fase III: ampliación de funcionalidades de la plataforma
    de Televisión Digital, habilitando el canal de retorno
    (interactividad).
    Equipo de trabajo
   Comité de dirección: dirección del proyecto, formado por
       el responsable del Servicio de Promoción de la Sociedad
       de la Información, un responsable de NGA y el Jefe de
       Proyecto en el Centro de Excelencia.
      Equipo de Trabajo: técnicos destinados al desarrollo del
       proyecto:
           1 persona del Servicio de Promoción de la Sociedad
             de la Información que coordinará los contenidos a
             incluir (dedicación 10%).
           1 persona de NGA encargada de coordinar al equipo
             y los trabajos realizados (dedicación 10%)
           Responsable del Centro de Excelencia Java y Open
             Source (dedicación 60%)
           Becario del Centro de Excelencia Java y Open
             Source con conocimientos de Java (dedicación
             100%)
           1 analista especializado en proyectos de desarrollos
             de servicios TDT encargado de aportar su
             experiencia y conocimiento (dedicación 50%)
           1 ingeniero de desarrollo especialista en MHP
             (dedicación 60%)
           2 técnicos de empresas del sector TIC de Navarra,
             con experiencia de 2 a 3 años en Java (dedicación
             60%)

       Planificación
       Se elaborará un Plan de Trabajo que defina las tareas a
       realizar, los responsables de su ejecución y los resultados
       a obtener en cada caso. Se aportará también la secuencia
       y el cronograma de módulos o agrupación de
       funcionalidades que se proponga seguir.

       En cualquier caso existirá una 1ª Fase a finalizar a 30 de
       abril de 2007, en cual estarán para poner en producción
       un mínimo de 2 de servicios en el ámbito de la Hacienda
       Tributaria.

Tras leerlo mi primera impresión fue confusa: en la planificación
y en el alcance, dos aspectos muy delicados.

El título del proyecto sugería un alcance concreto: el desarrollo
de toda una plataforma que soportase los contenidos de la
administración para la TDT. Sin embargo, el contenido del texto
vislumbraba otro alcance añadido: el desarrollo de un conjunto
de servicios de la administración para TDT. Se trataba de
alcances y trabajos diferentes, una ambigüedad que presagiaba
dificultades a futuro.
Por otro lado, había dos planificaciones incoherentes entre si.
Una contemplaba 3 fases: una para formar, preparar el equipo
y definir la plataforma, a continuación otra en la cual se
incorporaban a la plataforma servicios informativos y una
última donde se incorporaban servicios interactivos. Un
planteamiento lógico y de dificultad gradual. Por el contrario,
luego se hablaba de otra planificación en 2 fases: una en la cual
se desarrollaban los servicios para Hacienda (interactivos), y
una segunda aún por definir. Se empezaba por tanto por la
parte más compleja y con el equipo probablemente sin
preparar. Sugería que la fecha de la campaña de la renta había
comprometido el planteamiento inicial.

En esta situación, las 4 prioridades para   la fase 1 parecían ser:
identificación de los servicios para TDT    de Hacienda, montaje
del equipo, plataforma de servicios          TDT e identificación
servicios para la fase 2. Esto es, una      primera fase bastante
completa.

ASPECTO A MEJORAR: a futuro debe esclarecerse el
objetivo del proyecto, su alcance y las condiciones.

En cualquier caso, aún había muchas cosas por aclarar y
concretar. Por esa razón, durante el mes de diciembre se
sucedieron una serie de reuniones en los CES, el centro de
operaciones de ese momento en adelante, de las cuales pueden
extraerse las siguientes informaciones útiles:

       Limitaciones de la TDT:
       Interfaz: se cuenta con un espacio muy reducido, además
       el aprovechamiento no es muy eficiente dado que debe
       ser visible desde el sofá. Así mismo, el tele-espectador no
       tiene porque ser un usuario habituado a las tecnologías,
       con lo que la navegación y uso de la aplicación debe ser
       lo más sencilla posible, guiando al tele-espectador en
       todos los pasos. A todo esto hay que añadir el bilingüismo
       propio de la Comunidad Foral de Navarra y la guía de
       estilos dewww.navarra.es con el fin de que se identifiquen
       los servicios con la marca del Gobierno de Navarra en la
       web.
       Capacidad: tanto el ancho del banda del llamado carrusel
       (donde se emiten las aplicaciones) en torno a 2Mbits
       compartido, como la escasa capacidad de procesamiento
       y memoria del deco, obligan a tener mucho cuidado en el
       peso de la aplicación.
      Existen varias implementaciones diferentes del estándar
MHP en el mercado, pero la preponderantes son dos,
    Alticast y Osmosys, con lo que el comportamiento de las
    aplicaciones puede diferir de un deco a otro. Esto obliga a
    realizar pruebas exhaustivas en una amplia batería
    de decos comerciales.
   La llamada interactividad en la TDT no viene de “serie”,
    sino que precisa de un canal de retorno a través de
    Internet por parte del deco bien por módem o bien por
    ADSL.

    Tratamiento de la información:
   Se acuerda diseñar la aplicación de modo que la lógica
    esté desacoplada de la información de modo que esta
    sean fácilmente modificable en emisión sin afectar a la
    funcionalidad. Esta información, consumida por la
    aplicación, se presentará en forma de fichero XML, dada
    la estandarización de este formato.
   Toda esta información se acuerda introducirla en la
    aplicación para su emisión de forma “manual”, sin llegar a
    integrarlo en el gestor de contenidos. Esto queda fuera
    del alcance.
   Así mismo, el intercambio de datos entre los servicios
    sobre TDT y los sistemas de información del portal web se
    realizarán en base a servicios web. Aquí se quedó fuera
    del tintero que ocurría si no existían esos servicios web,
    quién debía desarrollarlos.
    Servicios a desarrollar:
   Con información estática aún por determinar a modo de
    teletexto.
   Con información dinámica (modificable en emisión) aún
    por determinar pero priorizando los más demandados
    en www.navarra.es. (Ej: meteorología, farmacias, boletín,
    carreteras, empleo, etc)
   Interactivos: servicios de Hacienda para la campaña de la
    RENTA.
   Portal o lanzadera: se precisa de un menú que de acceso
    a todos estos servicios del Gobierno de Navarra.
    Servicios Hacienda:
   Los dos servicios que más interés podían tener porque
    habían funcionado a nivel nacional se descartaron: la “cita
    previa” era demasiado compleja y la “petición o
    aceptación de borrador” no existía en Navarra. Por esa
    razón todo apuntaba a los siguientes dos servicios:
    “Cuanto me sale a pagar o devolver” y “Cuando me
    devuelven”.
   Estado     del    back-end:     existen   servicios    web
    implementados y reutilizables por lo que tan solo faltaba
recibir sus especificaciones (XML) para verificar su
      viabilidad e integración con TDT.
    Funcionalidad: el usuario se identifica mediante un DNI y
      un PIN que le proporciona Hacienda.
    Plazos: La campaña de la RENTA comenzaba la segunda
      quincena de Mayo, lo cual daba un poco más margen
      respecto al hito inicial de Abril.
      Organización:
    Reuniones semanales de la dirección del proyecto: NGA,
      DGpSI; CES y el asesor técnico.
    Existirá una reunión de arranque con el comité entorno a
      Enero-Febrero y otra coincidente con la campaña de la
      RENTA. El resto dependerá del Plan de Acción.
    Debía definirse un plan de comunicación al comité para
      informar de los progresos, dificultades y decisiones
      pendientes que la dirección no podía tomar. Así mismo,
      debía detallar los entregables de cada fase, perfiles,
      tareas, fechas y riesgos.
Las cosas empezaban a tomar forma pero aún había mucho por
hacer. Por lo menos entonces teníamos claro lo que debía
hacerse para seguir avanzando y concretando puntos.

De entre todas esas tareas, puesto que el desarrollo para
Hacienda (RENTA) era de lo más acuciante, tenía una absoluta
prioridad. Había que comenzar por aquí, además era lo más
tangible y sólido de todo el proyecto.

No obstante, había otra serie de tareas también importantes
que se pretendían acometer en paralelo:
    Determinar el proceso de incorporación de las empresas:
      perfiles requeridos, selección, contrato y transferencia de
      conocimiento.
    Selección de los servicios a implementar durante la
      segunda fase: reuniones con jefes de sección.
    Definición de la metodología y herramientas de trabajo.
Todo esto debería haberse contemplado dentro de un Plan de
Acción, aún sin definir, que planificase todas las tareas antes de
entrar en acción, para lo cual se hubiera necesitado recopilar
algo de información previamente, no obstante, la premura de
las cosas no lo permitió, todo iba sobre la marcha. La sensación
era que había demasiadas cosas a realizar, mucha urgencia,
pocos recursos y bastante indeterminación.

Definición de la metodología y herramientas de trabajo
Como cualquier otro proyecto de software había unas
herramientas básicas necesarias: un gestor de proyectos, un
sistema de control de versiones de código y una metodología.
Puesto que aún no contaba con equipo para poner en marcha
todo esto, debíamos salir adelante con lo que fuese.
Casualmente, contábamos con una instalación de dotproject
para la gestión del proyecto y en última estancia con un CVS
para el control de versiones de código (posteriormente
trabajaríamos    con   subversion).   Esto  era   lo  mínimo
imprescindible con lo que empezar. En cuanto a la metodología,
se decidió asumir la que el asesor técnico sugiriese en estos
casos, lo cual también sería parte de esa transferencia
tecnológica.

Así pues parecía estar todo, pero me surgía una duda,
¿necesitamos algo más para desarrollar aplicaciones para TDT?
La respuesta no estaba muy clara, así que se indagó y se
elaboró un informe que contemplaba las necesidades hardware
y software. Este informe se publicó en ediciones anteriores del
boletín (TDT: herramientas para desarrollo MHP (Parte
1) y TDT: herramientas para desarrollo MHP (Parte 2)). En
resumidas cuentas, había que hacer una fuerte inversión en un
laboratorio de pruebas y en unas herramientas de desarrollo
específicas para TDT. Las herramientas de desarrollo específicas
para TDT aunque facilitaban el diseño y el desarrollo no eran
estrictamente necesarias, y dado que se buscaba entre otras
cosas una transferencia de conocimiento, se barajó no
emplearlas. No obstante, esto habría incidido en el ritmo de
trabajo y dadas las circunstancias no era factible.

Esta decisión tomó largo tiempo en tomarse y unas cuantas
conversaciones.

Selección de los servicios a implementar durante la
segunda fase: reuniones con jefes de sección
Esta tarea requería sin lugar a dudas una intervención por parte
de NGA y la DGpSI, por lo que, decidí delegar y depender de
ellos en este punto y concentrarme en otras tareas que recaían
directamente en los CES.

Determinar el proceso de incorporación de las empresas:
perfiles requeridos, selección, contrato y transferencia de
conocimiento
Junto con el análisis de los servicios de la RENTA, la formación
del equipo parecía ser otra tarea muy urgente, debían estar
preparados para el desarrollo de la RENTA lo antes posible. Esta
responsabilidad recaía en los CES.

Este fue el planteamiento tomado:
Es decir, la búsqueda del becario comenzó en cuanto se supo
de esta necesidad en el proyecto. No obstante, la selección de
los profesionales exigía definir un perfil más específico, que
debía establecerse según los requerimientos del proyecto. Este
no pudo establecerse hasta finales del 2007 cuanto ya se tenía
claro la experiencia y profesional buscado. En cualquier caso, se
trató de un proceso contra-reloj, como se puede observar en la
planificación, con el fin de que el equipo estuviera listo a finales
de enero y el proyecto pudiera arrancar con la primera reunión
del comité, teniendo aproximadamente un margen de un mes
para recibir y seleccionar las candidaturas válidas.

Para lo cual, se establecieron unas bases de participación en el
proyecto que incluían el perfil establecido y que se distribuyó de
diversas formas: prensa, mail electrónico y web. Cabe decir que
algunos aspectos dieron lugar a ciertas confusiones,
probablemente por no estar suficientemente claras en las
bases: fue el caso, por ejemplo, del objetivo de estas bases, se
buscaban empresas para participar en el desarrollo de un
proyecto ya concedido, no para conceder el desarrollo del
proyecto a un tercero, número de candidaturas por empresa,
etc. En cualquier caso, tras la recepción de candidaturas se
estableció un mecanismo por el cual se contrastaban con el
perfil buscado, descartando aquellas que no lo cumplían. Una
vez hecha esta criba quedaba decidir entre las que restaban,
cuales participaban y cuáles no. Teníamos 3 candidatos válidos
técnicamente, decantarnos por uno u otro hubiera sido
partidista. Con el fin de ser neutral, se decidió sacarlo a
suertes, aunque hubo cierto desacuerdo con este método.
Finalmente no hubo necesidad, puesto que una de las
candidaturas abandonó el proceso por fuerza mayor. Esto puso
de manifiesto las carencias del sistema elegido que habría que
pulir y corregir.

ASPECTO A MEJORAR: a futuro, para evitar estas
ambigüedades, definir ámbito de las bases, tabular las
condiciones y emplear un proceso más objetivo.

Con el comienzo del año 2007, volvimos a reunirnos para seguir
atando cabos , retomar los trabajos y preparar la primera
reunión del comité de Enero-Febrero. Las cosas no habían
cambiado mucho. Todo se centraba en preparar la reunión del
comité, que era la presentación del arranque del proyecto, y
por tanto, los puntos en que había que trabajar:

    Equipo de trabajo.
    Plan de Acción.
    Presupuesto inversiones para entorno de desarrollo y
     pruebas.
    Estado servicios de la RENTA.
    Portal (lanzadera).
    Propuesta de servicios a implementar.

Por tanto, seguíamos más o menos donde lo habíamos dejado.
Las tareas del equipo de trabajo ya estaban lanzadas y se
habían detectado así mismo, las necesidades para el entorno de
desarrollo y pruebas, tan solo quedaba ponerles “números”. No
obstante, los puntos más importantes que aún estaban abiertos
y que eran claves: no habíamos avanzado en cuanto a la
propuesta de servicios puesto que antes debíamos reunirnos
con las personas indicadas en Gobierno de Navarra, tampoco
estaba definido el Plan de Acción dentro del cual debían
enmarcarse la propuesta de servicios, el análisis de los servicios
de la RENTA, y la definición del portal (lanzadera).

Así pues, el mes de enero resultó bastante “movido”,
centrándonos en elaborar ese Plan de Acción y en recopilar
información para poder llevarlo a acabo: análisis de los
servicios de RENTA, definición de la Lanzadera y selección de
los siguientes servicios.
El caso es que, como se puede observar, dada la premura, la
     definición empezaba a diluirse con la primera fase de ejecución.

     No obstante, estas andaduras se comentarán en el próximo
     artículo.
Cat CES OpenSouce/Java
ego
rías
Tem Varios
a
Aut Raúl Sanz de Acedo
or
Mes Septiembre
Año 2008
Bol 09
etín




Título                   Configuración de Subversion
Texto    Tras haber escrito un artículo de introducción a
         Subversion y otro explicando su instalación, a continuación
         se explicará cómo configurarlo de tal forma que se pueda
         empezar a usar.

         La distribución de Subversion incluye un cliente remoto
         (svn), un servidor (svnserve), y varias utilidades. Se
         comenzará explicando cómo configurar el acceso a los
         repositorios a través de Apache. Para ello se supondrá que
         ya existe un repositorio creado y que se ha modificado
         httpd.conf para reflejar la configuración existente en la
         máquina antes de configurar el acceso a Subversion. Si no
         se ha creado ningún tipo de repositorio, se podrá crear
         mediante el uso de la herramienta svnadmin. La
         instrucción que se debería ejecutar sería:

               svnadmin create
         /ruta/al/repositorio/NombreRepositorio

         o si se quiere elegir el tipo de almacenamiento del mismo:

               # Para crear un repositorio basado en FSFS

               svnadmin create --fs-type fsfs
               /ruta/al/repositorio/NombreRepositorio
# Para crear un repositorio basado en Berkeley-DB

       svnadmin create --fs-type bdb
       /ruta/al/repositorio/NombreRepositorio



Una vez que se tienen perfectamente configurados apache
y creados los repositorios necesarios, lo primero que
httpd.conf debe hacer es cargar el módulo mod_dav_svn
que se instaló. Para ello debe existir la línea:

     LoadModule
dav_svn_module        modules/mod_dav_svn.so

y debe ir por debajo de:

       LoadModule dav_module        modules/mod_dav.so

si no, se producirá un error.

Para dar acceso al repositorio se necesitará añadir al final
del archivo httpd.conf o en un archivo .conf separado que
esté situado en un directorio en el que el servidor sea
capaz de encontrarlo y cargarlo.

       <Location /svnRepos>

               DAV svn

               SVNPath /ruta/absoluta/al/repositorio

       </Location>



Esto dará un acceso sin restricciones al repositorio a
cualquiera que acceda
a http://URLServidorConSubversion/svnRepos. Para
limitar el acceso de escritura o lectura, se deben añadir las
siguientes líneas al bloque de Location:

               AuthType Basic

               AuthName "Subversion repository"

               AuthUserFile /ruta/a/archivo/de/contraseñas

y además si:

      El repositorio tiene restringido el acceso de
lectura/escritura:

      Require valid-user

     Para un repositorio con acceso de escritura limitado:

      <LimitExcept GET PROPFIND OPTIONS REPORT>

            Require valid-user

      </LimitExcept>

     Para restringir de forma diferente el acceso a lectura
      y escritura:

      AuthGroupFile /my/svn/group/file

      <LimitExcept GET PROPFIND OPTIONS REPORT>

            Require group svn_committers

      </LimitExcept>

      <Limit GET PROPFIND OPTIONS REPORT>

            Require group svn_committers

            Require group svn_readers

      </Limit>

Para crear el fichero de contraseñas se utilizará el comando
de apache htpasswd. Lo que hace es con la opción –c crea
un archivo con las contraseñas en la ruta
especificada. Con la opción –m, usa encriptación MD5 en
las contraseñas, que es más segura que la que usa por
defecto. Así un ejemplo de cómo crear un archivo de
contraseñas sería el siguiente:

      ### Primera vez: use -c para crear el archivo

       ### Use -m para usar encriptación MD5 de la
      contraseña, que es más segura

      htpasswd -cm /ruta/a/archivo/de/contraseñas harry

      New password: *****

      Re-type new password: *****

      Adding password for user harry

      ### Como el archivo ya está creado, no se vuelve a
usar la opción -c

      htpasswd -m /ruta/a/archivo/de/contraseñas sally

      New password: *******

      Re-type new password: *******

      Adding password for user sally

Si en vez de apuntar a un único repositorio se quiere
apuntar a varios que están contenidos en un mismo
directorio en vez de usar SVNPath, se puede emplear la
instrucción SVNParentPath. Es decir:

      <Location /svnRepos>

             DAV svn

             SVNParentPath
/ruta/absoluta/al/directorio/con/repositorios

      </Location>

Esto dará un acceso sin restricciones a todos los
repositorios incluidos en esa carpeta. Para acceder a ellos
habrá que usar la siguiente
URL:http://URLServidorConSubversion/svnRepos/NombreR
epositorio.

Apache también permite otras formas de autentificación
como la de tipo Digest, que se basa en autentificar al
usuario mediante una contraseña que en vez de enviarse
sin encriptar, usa encriptación MD5. Para ello habría que
emplear:

      <Location /dominioDeDigest >

             DAV svn

             SVNParentPath
/ruta/absoluta/al/directorio/con/repositorios

             AuthType Digest

             AuthName "Subversion repository"

             AuthDigestDomain /dominioDeDigest/

             AuthUserFile /ruta/a/archivo/de/contraseñas

             Require valid-user
</Location>

En este caso además habría que cargar el módulo
mod_auth_digest y para crear los usuarios, en vez de
emplear la utilidad htpasswd de apache habría que emplear
la htdigest. El problema que puede existir es que es un
módulo todavía experimental y que no se ha probado
completamente, así que puede tener fallos. Para crear el
archivo, entonces emplearíamos:

      ### Primera vez: use -c para crear el archivo

      htdigest -c /ruta/a/archivo/de/contraseñas
      /dominioDeDigest/ harry

      New password: *****

      Re-type new password: *****

      Adding password for user harry

      htdigest /ruta/a/archivo/de/contraseñas
      /dominioDeDigest/ sally

      New password: *******

      Re-type new password: *******

      Adding password for user sally

Si se quiere tener un control más estricto de la
comunicación se puede emplear conexiones seguras
mediante SSL. Esto implica tener instalado OpenSSL para
poder cargar el módulo correspondiente en apache y
también tenerlo instalado en la máquina cliente. Habría
que crear un certificado en el servidor y otro en el
cliente. En este caso para acceder a Subversion se
utilizaría: https://URLServidorConSubversion/svnRepos/No
mbreRepositorio

Otras opciones que permiten un control más fino en el
repositorio se basan en el uso del módulo mod_dav_auth
además del mod_dav_svn y el mod_dav necesarios
anteriormente, un fichero de contraseñas y un fichero de
grupos y/o usuarios. En este último fichero se especificará
a qué partes del repositorio tiene acceso cada uno de los
usuarios/grupos. Es decir, podrá haber partes de un
repositorio a las que no podrá acceder nadie más que unas
personas determinadas, otras en las que sólo se podrá leer
y otras en las que se podrá leer y escribir. El problema
que tiene este tipo de autentificación es que el repositorio
tardará más en responder a las peticiones porque primero
deberá comprobar si el usuario que la ha solicitado tiene
permiso para hacerlo. Así, para tener acceso que exija
autentificación la directiva Location debería tener este
aspecto:

      <Location /svnRepos>

             DAV svn

             SVNParentPath /var/svn

             # our access control policy

             AuthzSVNAccessFile /path/to/access/file

             # only authenticated users may access the
repository

             Require valid-user

             # how to authenticate a user

             AuthType Basic

             AuthName "Subversion repository"

             AuthUserFile /path/to/users/file

      </Location>

Si se quiere tener una mezcla entre acceso anónimo y
autentificado, entonces debería ser similar a:

      <Location /svnRepos>

             DAV svn

             SVNParentPath /var/svn

             # our access control policy

             AuthzSVNAccessFile /path/to/access/file

             # try anonymous access first, resort to real

             # authentication if necessary.

             Satisfy Any

             Require valid-user

             # how to authenticate a user
AuthType Basic

             AuthName "Subversion repository"

             AuthUserFile /path/to/users/file

      </Location>

El aspecto que debería tener el archivo que restringe el
acceso a los directorios del repositorio
(AuthzSVNAccessFile) debería ser:

      # Se indica que CN=Harold
      Hacker,OU=Engineers,DC=red-bean,DC=com es
      harry, para simplificar las cosas en el archivo.

      [aliases]

      harry = CN = Harold Hacker, OU = Engineers, DC =
      red-bean, DC = com

      #Se definen los grupos, como harry es un alias, debe
      ir precedido por &

      [groups]

      calc-developers = &harry, sally, joe

      paint-developers = frank, sally, jane

      everyone = &harry, sally, joe, frank, sally, jane

      # Con las siguientes 2 líneas se da acceso de lectura
      a cualquier usuario en todos los repositorios y en
      todas las carpetas, porque todos los repositorios lo
      cumplen. Si no se especifican restricciones por
      carpeta, entonces podrá leer en cualquiera de
      ellas cualquier usuario

      [/]

      *=r

      # En las siguientes líneas, se restringe el acceso al
      directorio branches/calc/bug-142 del repositorio
      calc. Se dan permisos de lectura y escritura a harry,
      a jane sólo de lectura, y se niega explícitamente el
      acceso de lectura y escritura a joe al no añadir nada
      tras el igual.

      [calc:/branches/calc/bug-142]
&harry = rw

      sally = r

      joe =

      # Dentro de la carpeta projects/calc, del repositorio
      calc, el grupo calc-developers tendrá acceso de
      lectura y escritura, el resto de grupos o usuarios no
      tendrá ningún permiso por no estar indicados.

      [calc:/projects/calc]

      @calc-developers = rw

      # Dentro de la carpeta /projects/paint del repositorio
      paint jane, a pesar de pertenecer al grupo paint-
      developers sólo podrá leer porque es más restrictivo,
      y el grupo paint-developers (salvo jane) podrá
      escribir y leer.

      [paint:/projects/paint]

      jane = r

      @paint-developers = rw

Este ejemplo ilustra varias cosas, desde el uso de grupos,
de alias y el acceso a ciertas partes del repositorio. En
principio, se tomará la regla más restrictiva por la carpeta
que se solicite.

Subversion también permite mostrar una lista de los
repositorios que se encuentran en el directorio al que
apunta la directiva SVNParentPath de los ficheros de
configuración de Apache. En principio, esta opción
permanece deshabilitada por motivos de seguridad. Si se
quiere habilitar habría que añadir la siguiente línea a la
directiva Location:

      SVNListParentPath on

Esta opción no termina de funcionar correctamente. Para
poder mostrar los repositorios y que funcione, lo que se
debe hacer es además de añadirla dentro de la directiva
Location, añadir un / al final del nombre al que apunta
Location, de esta manera nos quedaría la directiva Location
así:

      <Location /svnRepos/>
DAV svn

             SVNParentPath
/ruta/absoluta/al/directorio/con/repositorios

              SVNListParentPath on

       </Location>

Se podrían añadir todas las opciones que fueran
necesarias. Para ver la lista de repositorios que hay en el
servidor, entonces se iría
a:http://URLServidorConSubversion/svnRepos/ . Es muy
importante añadir la última barra, porque si no, no los
mostrará y dará un error.

Si en vez de usar Apache como servidor de Subversion, se
emplea „svnserve‟, entonces para invocarlo se puede hacer
de diferentes formas:

      En sistemas basados en UNIX como Linux, se puece
       hacer que svnserve corra como demonio escuchando
       las peticiones.

      Hacer que el demonio inetd de Linux/UNIX/Solaris
       lance temporalmente svnserve cada vez que una
       petición llegue por un cierto puerto.

      Hacer que SSH invoque un svnserve temporal sobre
       un túnel encriptado.

      Ejecutar svnserve como un servicio de Microsoft
       Windows.

Para lanzar svnserve como demonio, entonces habrá que
ejecutar:

       svnserve –d

Si además se quiere aumentar la seguridad, se puede
pasar la opción –r seguida de una ruta, que restringirá los
repositorios a los que se puede acceder a aquellos que
estén en subdirectorios de la misma.

Para que sea inetd el que invoque a svnserve, se debe
lanzar svnserve con la opción –i, pero además habrá que
comprobar que en el fichero /etc/services existan las
entradas referidas a Subversion:

       svn   3690/tcp    # Subversion
svn   3690/udp     # Subversion

Además habría que añadir la siguiente línea al fichero
inetd:

      svn stream tcp nowait svnowner /usr/bin/svnserve
svnserve -i

donde svnowner es un usuario que debe tener permisos de
lectura y escritura sobre el repositorio, se puede cambiar a
otro que los tenga.

En el caso de que sea SSH el que invoque a svnserve,
entonces lo hará con la opción –t.

En el caso de querer ejecutarlo en Windows, entonces
habrá que ejecutar una vez:

      sc create svn

      binpath=
      "C:directorioinstalacionSubversionbinsvnserve.ex
      e --service -r C:directoriorepositorio"

      displayname= "Subversion Server"

      depend= Tcpip

      start= auto

Con esto se ejecutará cada vez que se lance Windows el
servicio svnserve. No puede ejecutarse con opciones como
–d, -t o –i porque entra en conflicto.

Si se quiere modificar la forma de acceder al repositorio a
través de svnserve, habrá que modificar el archivo
svnserve.conf. En este se especificará el tipo de acceso
que se deja, como se puede ver en los siguientes
ejemplos:

      [general]

      password-db = ArchivoDeContraseñas

      realm = dominio_de_ejemplo

      # Los usuarios anónimos solo pueden leer el
      repositorio

      anon-access = read

      # Los usuarios autentificados pueden leer y escribir
auth-access = write

En este caso se ha permitido acceso de lectura a usuarios
anónimos y de lectura y escritura a todos los usuarios, es
como viene por defecto. En el siguiente el acceso será más
conservador y sólo se permitirá que accedan si se
autentifican.

     [general]

     password-db = ArchivoDeContraseñas

     realm = dominio_de_ejemplo

     # No se permiten usuarios anónimos

     anon-access = none

     # Los usuarios autentificados pueden leer y escribir

     auth-access = write

El proceso servidor entiende no sólo estos controles de
acceso al servidor si no también controles más finos
definidos en archivos de acceso como el explicado en el
caso de Apache como servidor de Subversion. Para ello se
necesita un archivo con las reglas más detalladas y que la
variable authz-db la señale.

     [general]

     password-db = ArchivoDeContraseñas

     realm = dominio_de_ejemplo

     # Reglas de acceso específicas para localizaciones
     específicas

     authz-db = ArchivoDeReglasDeAcceso

Además, la opción authz-db, anon-access y auth-access no
se excluyen por lo que si se incluyen las tres, sólo los
usuarios que las cumplan podrán acceder al repositorio.

Para hacer estas autentificaciones, svnserve trae por
defecto implementado MD5, pero si durante la instalación
de Subversion tanto en el lado del cliente como en el del
servidor se instaló SASL, esto permitirá mayores opciones
para la comunicación entre ambos.



Para obtener más información sobre el tema, se pueden
consultar la documentación siguiente:



          ENLACES DE INTERÉS:

          Subversion

                  http://en.wikipedia.org/wiki/Subversion_(software)

                  http://es.wikipedia.org/wiki/Subversion

                  http://subversion.tigris.org/

                  http://www.1x4x9.info/files/subversion/html/online-
                   chunked/index.html

                  http://svn.collab.net/repos/svn/trunk/INSTALL

                  Version Control with Subversion, Ben Collins-
                   Sussman, Brian W. Fitzpatrick, C. Michael Pilato. -
                   > http://svnbook.red-bean.com/



Categorí CES OpenSouce/Java
as
Tema      Varios
Autor     Blanca Cubas
Mes       Septiembre
Año       2008
Boletín   09




Título                    Técnicas de mapeado de texturas. Parte 1

Texto       Para la implementación de shaders que es en lo que me
            encuentro inmersa en este momento, y sobre lo que ya traté
            brevemente en un artículo anterior, es muy común la
            utilización de distintas técnicas de mapeado de texturas. Su
            ventaja es que, sin consumir muchos recursos gráficos, nos
            permiten obtener efectos complejos y bastante realistas de
            manera sencilla.

            Como introducción al tema, decir que un mapeado de textura
            sencillo consiste en indicar la correspondencia entre los
            vértices de un objeto 3D (x,y,z) y las coordenadas de una
textura (u,v), tal y como se ve en la siguiente figura:




Sin embargo, si queremos conseguir mayor nivel de realismo,
tendríamos que utilizar otro tipo de técnicas más avanzadas.
Algunas de las más utilizadas son las siguientes:

   
    Bump Mapping.
    Normal Mapping.
    Displacement Mapping.
    Parallax Mapping.

Debido a la complejidad de las mismas, en este primer
artículo nos vamos a centrar en las dos primeras
técnicas. Ambas, tienen como objetivo dar aspecto de
relieve a un objeto, a partir de una textura que modifica
sus normales sin cambiar la geometría del mismo: es
decir, modificamos la representación del “material” del
objeto pero no su estructura 3D.
La única diferencia que existe entre una técnica y otra es
la textura de normales que utilizamos en cada caso.




                   Bump Mapping   NormalMapping



Bump Mapping

Las texturas que se emplean para realizar Bump Mapping son
texturas en escala de grises que únicamente nos dan el valor
de la altura. Los valores más próximos al negro se convierten
en protuberancias y los más cercanos al blanco en
hendiduras. Con ello lo que hacemos es “falsear”
desplazamientos arriba y abajo de la verdadera superficie.

Normal Mapping

Las texturas que se emplean para realizar Normal Mapping
son texturas RGB que a través de sus distintos canales, nos
dan información sobre los ejes x, y, z. La componente azul, es
la que más nos interesa en este caso, ya que es la que nos da
la información sobre el relieve de la textura.

La mejor forma de ver el resultado que tienen estas técnicas
es a través de un ejemplo práctico. Para ello hemos
implementado el siguiente código enNvidia FX Composer 2:

//Lo primero que hacemos es definir las matrices de transformación y los
parámetros a //utilizar por defecto.

float4x4 WorldITXf : WorldInverseTranspose < string UIWidget="None"; >;

float4x4 WvpXf : WorldViewProjection < string UIWidget="None"; >;

float4x4 WorldXf : World < string UIWidget="None"; >;

float4x4 ViewIXf : ViewInverse < string UIWidget="None"; >;

float Timer : Time < string UIWidget = "none"; >;

float4 lightPos = (1.0f,1.0f,1.0f,1.0f);

//A continuación definimos las texturas que vamos a utilizar. La primera
se trata de la //textura (u,v), que vamos a aplicar a nuestro objeto, en
este caso, un plano.


  texture WallTexture   <

   string ResourceName = "rockwall.jpg”;

   string UIName =   "WallTexture";

   string ResourceType = "2D";

   >;

   sampler2D WallSampler = sampler_state {

   Texture = <WallTexture>;

   };

//Y la segunda se trata de la textura que se utiliza para almacenar la
información de //las normales.


   texture NormalTexture    <

   string ResourceName = "rockwall.tga";

   string UIName =   "Normal Map";

   string ResourceType = "2D";

   >;
sampler2D NormalSampler = sampler_state {

    Texture = <NormalTexture>;

    };

//Vertex Shader

// Necesitaremos la normal, binormal y tangente para poder situar la
textura en el //espacio 3D, porque la función tex2D no tiene eso en
cuenta. Para transformar los //vectores luz y posición se emplean la
normal, binormal y tangente, que forman un //espacio de coordenadas
propio (una matriz) que al multiplicarla nos dará los vectores //luz y
posición en ese espacio de coordenadas.

void mainVS(float4 Position : POSITION0,

    float3 Normal : NORMAL,

    float3 tangent : TANGENT,

    float3 binormal : BINORMAL,

    float2 TexCoord : TEXCOORD0,

    out float4 oPosition : POSITION0,

    out float2 oTexCoord : TEXCOORD0,

    out float2 oNormalCoord : TEXCOORD1,

    out float3 lightVec : TEXCOORD2,

    out float att : TEXCOORD3)

{

    oPosition = mul(Position, WvpXf); //

    float4 posWorld = mul(Position, WorldXf);    // Posición del vértice
en el mundo 3D

    float3 light = normalize(lightPos - posWorld); //Obtenemos la luz en
cada vértice

    float3x3 TBNMatrix = float3x3(tangent, binormal , Normal);

    lightVec = mul(TBNMatrix, light);

    att = 1/( 1 + ( 0.005 * distance(lightPos.xyz, posWorld)
) );//calculamos la atenuación de la luz

    oTexCoord = TexCoord;

    oNormalCoord = TexCoord;

}

//PixelShader

// Tendremos que pasar los vectores luz y posición transformados al
pixel shader que //los usará igual que hasta ahora para generar el
componente difuso y especular.


void mainPS (float4 oPosition : POSITION0,

          float2 oTexCoord : TEXCOORD0,

          float2 oNormalCoord : TEXCOORD,

          float3 lightVec : TEXCOORD2,

          float att : TEXCOORD3,

          out float4 oColor : COLOR)

{

    float4 color = tex2D(WallSampler, oTexCoord); //Calculamos el color
de la textura en cada punto

//La normal se extrae del nuestra textura NormalTexture de la siguiente
manera:


    float3 normal = 2.0f * tex2D(NormalSampler, oNormalCoord).rgb -
1.0f;

      float3 light = normalize(lightVec); //Normalizamos el valor de la
luz

    float diffuse = saturate(dot(normal, light)); //Calculamos el color
difuso

      oColor = att * color * diffuse; //Obtenemos el color final

}

//Y aplicamos la técnica deseada

technique Main

{

      pass p0

      {

          VertexShader = compile vs_3_0 mainVS();

          PixelShader = compile ps_3_0 mainPS();

      }

}


La imagen de la izquierda se corresponde con un mapeado de
textura básico, y la de la derecha aplica dicha textura junto
con un Normal Mapping.
Comentar como aspecto interesante, que las texturas de
           normales se puede crear con el plugin para Photoshop de
           NVidia, o con el programa CrazyBumpentre otros.




Categorías CES Microsoft

Tema       Desarrollo

Autor      Goretti Ortigosa Rada

Mes        Septiembre

Año        2008
Boletín      09




Título                     Registro (Logging) en aplicaciones .NET

Texto     En la pasada edición de la NavarParty, que contó con una muy buena asistencia,
          tuve la oportunidad de asistir a una charla presentada por Iván Gonzalez,
          de PlainConcepts, que trató sobre el registro de eventos en aplicaciones .NET.
          Iván demostró ser no sólo un muy buen comunicador y un profesional con
          muchos conocimientos, sino además alguien que se esfuerza por ello como
          aquellos que conocen en periplo ferroviario que Iván realizó para venir a dar esa
          charla pueden atestiguar. Como sencillo reconocimiento aquí pongo una foto de
          Iván en acción:




          El tema de la charla me recordó que en alguna parte había visto algo al respecto
          y me acordé de un articulito breve de Scott Mitchell (MVP desde 2002, gurú de
          ASP.NET, creador de4gyusfromrolla.net… en definitiva, todo un IT) sobre un
          tema muy similar. En él se presentan un par de herramientas que vienen a cubrir
lo presentado por Iván en cuanto a registro de eventos:

    -    Enterprise Library 4.0: http://msdn.microsoft.com/en-
        us/library/cc512464.aspx
    -    Log4net: http://logging.apache.org/log4net/index.html


Ambas son herramientas OpenSource, siendo la segunda de ellas obra de la
Apache Software Foundation como una versión de su log4j, la librería para
registro de eventos en aplicaciones Java, mientras que la primera es creación del
grupo de Microsoft “Patterns & Practices”.

¿Cuál es el beneficio de usar estas librerías? O más sencillamente, ¿por qué
deberíamos molestarnos en usarlas? Estas librerías tienen como objetivo facilitar
en registro de eventos en aplicaciones de escritorio hechas en .NET. Hoy en día
los desarrollos de software disponen de una serie de herramientas, marcos de
desarrollo (frameworks), librerías, etc. que permiten que las aplicaciones en
general sirvan para el cometido para el que se han diseñado de manera
aceptable. La calidad en el desarrollo de software sin embargo se encuentra
ahora en otras áreas: zonas como el control de rendimiento y errores ocultos así
como la trazabilidad de accesos y auditoría son elementos que hoy en día se
demandan por parte de los compradores de software. Y es aquí donde el
beneficio de este tipo de librerías se aprecia al máximo. Porque si bien
anteriormente este registro de eventos se podía hacer de una manera artesanal
y era aceptable (quién no recuerda pasar horas con el bloc de notas buscando
mensajes específicos en ficheros planos de texto para poder explicar qué había
pasado en un programa…) hoy nos encontramos con que la gran mayoría de
fabricantes de software empresarial disponen en su catálogo de herramientas de
control y monitorización de sistemas automatizadas (IBM, MS, Oracle…) que
simplifican enormemente la vida a los administradores de sistemas y por tanto
van a querer que nuestro software utilice cuanto antes. Y a nosotros como
desarrolladores nos va a facilitar tareas como el traceado de nuestras
aplicaciones, análisis de errores, mejoras en rendimientos, y otras como la
distribución de aplicaciones (nos evitaremos errores por configuración errónea
de los contenedores de estos registros), etc.

La Enterprise Library es un conjunto de bloques de aplicación, que se definen
como un conjunto de clases, cada uno diseñado para una tarea de desarrollo
específica, como:

    -   Registro
    -   Acceso a datos
    -   Gestión de excepciones
    -   …

El que nos interesa es el Bloque de Aplicación de Registro (Logging Application
Block) que nos facilitará este registro de eventos. Antes de utilizarlo, deberemos
configurarlo e indicar qué monitores de traza (trace listeners) vamos a emplear.
Un monitor de traza es el objeto que se encargará de recoger la información que
nos interesa y escribirla en un almacén de registro específico. La Enterprise
Library tiene varios monitores predefinidos que pueden escribir la información
en el Registro de Sucesos de Windows (Event Log), en una base de datos, en un
fichero de texto, un mensaje de email, etc. También se nos permite crear
nosotros mismos otros monitores para escribir en otras fuentes.

La configuración del Bloque de Aplicación de Registro también incluye
categorías, filtros y formato de los registros. Las categorías nos permiten la
clasificación de los registros, por ejemplo: “Errores de acceso a datos” o
“Mensajes de Debug”. Cada registro pertenecerá a una categoría, y tendrá
también una serie de propiedades como prioridad o severidad. Mediante el uso
de diversos filtros basados en las categorías y propiedades de los mensajes de
registro podremos ajustar el comportamiento del registro de eventos en
distintos entornos: por ejemplo, en un entorno de pruebas podemos
interesarnos por todos los mensajes de prioridad 5 o más, o bien en un entorno
de producción podemos querer omitir todos los mensajes de la categoría
“Mensajes de Debug”. Por último, el formato de los registros nos permitirá
definir el formato que usaremos para almacenar la información en los mensajes.
Una vez hecho esto, tendremos que hacer uso en nuestros desarrollos de la API
del bloque de aplicación de Registro de manera que creemos eventos en
nuestros programas. Esto será tan sencillo como por ejemplo crear un objeto de
tipo LogEntry en la parte Catch de una excepción, recoger en este objeto los
detalles de la excepción mediante sus propiedades y finalmente registrar el
evento mediante una llamada al método Write de la clase que representa el
motor de registro enviándole como parámetro el objeto LogEntry. Esto generará
que el Bloque de Aplicación de Registro evalúe la entrada contra los filtros
definidos previamente y las categorías, determine si debe almacenarse y en caso
positivo le aplique el formato adecuado antes de registrarlo.

Por ejemplo, en el blog de Tercer Planeta nos mostraban el siguiente código
(sobre la versión 3.0 de la Enterprise Library, pero vale igualmente para 4.0)

public void EjecutarTarea(Tarea tarea)

{

        try

        {
Logger.Write("Preparando la tarea " +
tarea.Descripcion);

        tarea.Preparar();

      Logger.Write("Ejecutando la tarea " +
tarea.Descripcion);

        tarea.Ejecutar();

        Logger.Write(string.Format("Resultado de la Tarea (0):
{1}",

                tarea.Nombre, tarea.InfoResultado));

        }

        catch (Exception ex)

        {

                Exception outEx;

            if (ExecutionPolicy.HandleException(ex, "TareasP
olicy", out outEx))

                        throw outEx ?? ex;

        }

        finally

        {

                Logger.Write(tarea.Descripcion + " Finalizada");

        }

}




Por su parte log4net emplea una aproximación similar (algunos elementos
cambian de nombre, como los “appenders” en vez de los monitores de traza, o
los “layouts” en vez de las reglas de formato) y proporciona los mismos
resultados. Por defecto incluye más posibles destinos para el registro, como
fuentes de datos ADO.NET, la traza ASP.NET, la ventana de consola, un buffer en
memoria, etc. Lo que sí aporta log4net es la posibilidad de emplear una jerarquía
de registros, de manera que se puede definir niveles para los registros (por
ejemplo DEBUG, INFO, WARN y FATAL) que permiten clasificar de manera simple
los niveles de los registros que se crean y que pueden usarse para establecer que
un determinado appender responda sólo a los mensajes de un nivel concreto.

En definitiva, dos librerías que merece la pena considerar si hemos decidido dar
dos cosas:

             -    Dotar a nuestras aplicaciones de calidad en todos sus extremos.
             -    Sufrir menos en nuestro trabajo, usando herramientas que nos
                 simplifiquen tareas y sobre todo que nos permitan apagar fuegos
                 más rápido.

Categor CES Microsoft
ías
Tema     Desarrollo

Autor    Rafael Flores Yoldi

Mes      Septiembre

Año      2008

Boletín 09

Weitere ähnliche Inhalte

Andere mochten auch

Aplicaciones moviles de streaming de video para el seguimiento y control del ...
Aplicaciones moviles de streaming de video para el seguimiento y control del ...Aplicaciones moviles de streaming de video para el seguimiento y control del ...
Aplicaciones moviles de streaming de video para el seguimiento y control del ...Cein
 
Patrimonio versus industrialización, Eólicas en Chiloe
Patrimonio versus industrialización, Eólicas en ChiloePatrimonio versus industrialización, Eólicas en Chiloe
Patrimonio versus industrialización, Eólicas en ChiloeNicolas Oyarzun
 
Fuerza Cortante y Momento Flector (1)
Fuerza Cortante y Momento Flector (1)Fuerza Cortante y Momento Flector (1)
Fuerza Cortante y Momento Flector (1)delgadoeu
 
Treball de naturals
Treball de naturalsTreball de naturals
Treball de naturalsguillem15
 
Constitución
ConstituciónConstitución
Constituciónlokandenk
 
Luis Goñi (Fundación MODERNA). Financiación de la innovación en agroalimentación
Luis Goñi (Fundación MODERNA). Financiación de la innovación en agroalimentaciónLuis Goñi (Fundación MODERNA). Financiación de la innovación en agroalimentación
Luis Goñi (Fundación MODERNA). Financiación de la innovación en agroalimentaciónCein
 
Seguridad en internet paders
Seguridad en internet padersSeguridad en internet paders
Seguridad en internet padersJUANDIEGO-NW
 
Proyecto valores tercero
Proyecto valores terceroProyecto valores tercero
Proyecto valores terceroecullanco
 
Glosario base de datos presentacion
Glosario base de datos presentacionGlosario base de datos presentacion
Glosario base de datos presentacionjohanasolis
 
Cesnavarra 2008-boletín 11
Cesnavarra 2008-boletín 11Cesnavarra 2008-boletín 11
Cesnavarra 2008-boletín 11Cein
 
Trabajopractico5
Trabajopractico5Trabajopractico5
Trabajopractico5delfimassa
 

Andere mochten auch (20)

Aplicaciones moviles de streaming de video para el seguimiento y control del ...
Aplicaciones moviles de streaming de video para el seguimiento y control del ...Aplicaciones moviles de streaming de video para el seguimiento y control del ...
Aplicaciones moviles de streaming de video para el seguimiento y control del ...
 
Sustitutos
SustitutosSustitutos
Sustitutos
 
Slideshare
SlideshareSlideshare
Slideshare
 
El pasado
El pasadoEl pasado
El pasado
 
Patrimonio versus industrialización, Eólicas en Chiloe
Patrimonio versus industrialización, Eólicas en ChiloePatrimonio versus industrialización, Eólicas en Chiloe
Patrimonio versus industrialización, Eólicas en Chiloe
 
Tipos de texto
Tipos de textoTipos de texto
Tipos de texto
 
032 zacatecas ped 2010 2016
032 zacatecas ped 2010   2016032 zacatecas ped 2010   2016
032 zacatecas ped 2010 2016
 
Presentacion vrae alumnos
Presentacion vrae alumnosPresentacion vrae alumnos
Presentacion vrae alumnos
 
Fuerza Cortante y Momento Flector (1)
Fuerza Cortante y Momento Flector (1)Fuerza Cortante y Momento Flector (1)
Fuerza Cortante y Momento Flector (1)
 
Treball de naturals
Treball de naturalsTreball de naturals
Treball de naturals
 
Constitución
ConstituciónConstitución
Constitución
 
Muñecos de nieve
Muñecos de nieveMuñecos de nieve
Muñecos de nieve
 
Luis Goñi (Fundación MODERNA). Financiación de la innovación en agroalimentación
Luis Goñi (Fundación MODERNA). Financiación de la innovación en agroalimentaciónLuis Goñi (Fundación MODERNA). Financiación de la innovación en agroalimentación
Luis Goñi (Fundación MODERNA). Financiación de la innovación en agroalimentación
 
Seguridad en internet paders
Seguridad en internet padersSeguridad en internet paders
Seguridad en internet paders
 
Proyecto valores tercero
Proyecto valores terceroProyecto valores tercero
Proyecto valores tercero
 
Glosario base de datos presentacion
Glosario base de datos presentacionGlosario base de datos presentacion
Glosario base de datos presentacion
 
redes sociales buap
redes sociales buapredes sociales buap
redes sociales buap
 
Cesnavarra 2008-boletín 11
Cesnavarra 2008-boletín 11Cesnavarra 2008-boletín 11
Cesnavarra 2008-boletín 11
 
Trabajopractico5
Trabajopractico5Trabajopractico5
Trabajopractico5
 
Trabajos en altura
Trabajos en alturaTrabajos en altura
Trabajos en altura
 

Ähnlich wie Cesnavarra 2008-boletín 9

modelo entidad_relacion
modelo entidad_relacionmodelo entidad_relacion
modelo entidad_relacionluis alvarez
 
256 tonos de Grey - A veces soy truhán, a veces soy señor
256 tonos de Grey - A veces soy truhán, a veces soy señor256 tonos de Grey - A veces soy truhán, a veces soy señor
256 tonos de Grey - A veces soy truhán, a veces soy señorSergio de la Casa
 
Designer vs Front-end - DrupalCampES 2018 Alicante
Designer vs Front-end - DrupalCampES 2018 AlicanteDesigner vs Front-end - DrupalCampES 2018 Alicante
Designer vs Front-end - DrupalCampES 2018 AlicanteLa Drupalera
 
Branding práctico: el Drupal Visual Language Guide
Branding práctico: el Drupal Visual Language GuideBranding práctico: el Drupal Visual Language Guide
Branding práctico: el Drupal Visual Language GuideIgnacio Segura
 
Dilbert.pptx. horacio german garcia
Dilbert.pptx. horacio german garciaDilbert.pptx. horacio german garcia
Dilbert.pptx. horacio german garciaRobertoOtazu
 
Revista1j mmx modmex
Revista1j mmx modmexRevista1j mmx modmex
Revista1j mmx modmexnon
 

Ähnlich wie Cesnavarra 2008-boletín 9 (7)

modelo entidad_relacion
modelo entidad_relacionmodelo entidad_relacion
modelo entidad_relacion
 
256 tonos de Grey - A veces soy truhán, a veces soy señor
256 tonos de Grey - A veces soy truhán, a veces soy señor256 tonos de Grey - A veces soy truhán, a veces soy señor
256 tonos de Grey - A veces soy truhán, a veces soy señor
 
Designer vs Front-end - DrupalCampES 2018 Alicante
Designer vs Front-end - DrupalCampES 2018 AlicanteDesigner vs Front-end - DrupalCampES 2018 Alicante
Designer vs Front-end - DrupalCampES 2018 Alicante
 
Investor Deck - Boske - Juan Jesús Velasco
Investor Deck - Boske - Juan Jesús VelascoInvestor Deck - Boske - Juan Jesús Velasco
Investor Deck - Boske - Juan Jesús Velasco
 
Branding práctico: el Drupal Visual Language Guide
Branding práctico: el Drupal Visual Language GuideBranding práctico: el Drupal Visual Language Guide
Branding práctico: el Drupal Visual Language Guide
 
Dilbert.pptx. horacio german garcia
Dilbert.pptx. horacio german garciaDilbert.pptx. horacio german garcia
Dilbert.pptx. horacio german garcia
 
Revista1j mmx modmex
Revista1j mmx modmexRevista1j mmx modmex
Revista1j mmx modmex
 

Mehr von Cein

Directorio Viveros CEIN 2022 Septiembre.pptx
Directorio Viveros CEIN 2022 Septiembre.pptxDirectorio Viveros CEIN 2022 Septiembre.pptx
Directorio Viveros CEIN 2022 Septiembre.pptxCein
 
II Feria del Trabajo Autónomo de Navarra 2019
II Feria del Trabajo Autónomo de Navarra 2019II Feria del Trabajo Autónomo de Navarra 2019
II Feria del Trabajo Autónomo de Navarra 2019Cein
 
Jornada Energy Trends-ciudades inteligentes-Zabala
Jornada Energy Trends-ciudades inteligentes-ZabalaJornada Energy Trends-ciudades inteligentes-Zabala
Jornada Energy Trends-ciudades inteligentes-ZabalaCein
 
Jornada Energy Trends-Retos tecnológicos
Jornada Energy Trends-Retos tecnológicosJornada Energy Trends-Retos tecnológicos
Jornada Energy Trends-Retos tecnológicosCein
 
Showroom energy trends
Showroom energy trends Showroom energy trends
Showroom energy trends Cein
 
Completa showroom new industry
Completa showroom new industryCompleta showroom new industry
Completa showroom new industryCein
 
Tecnalia modelos oppsnegocioeradigitalindustrial_cein_151028
Tecnalia modelos oppsnegocioeradigitalindustrial_cein_151028Tecnalia modelos oppsnegocioeradigitalindustrial_cein_151028
Tecnalia modelos oppsnegocioeradigitalindustrial_cein_151028Cein
 
Workshop completo.Jornada Biomed XXI
Workshop completo.Jornada Biomed XXIWorkshop completo.Jornada Biomed XXI
Workshop completo.Jornada Biomed XXICein
 
Luis gabilondo gobierno de navarra-Jornada Biomed XXI
Luis gabilondo gobierno de navarra-Jornada Biomed XXILuis gabilondo gobierno de navarra-Jornada Biomed XXI
Luis gabilondo gobierno de navarra-Jornada Biomed XXICein
 
Juan ramón de la torre aditech-Jornada Biomed XXI
Juan ramón de la torre aditech-Jornada Biomed XXIJuan ramón de la torre aditech-Jornada Biomed XXI
Juan ramón de la torre aditech-Jornada Biomed XXICein
 
María rosario luquin idisna-Jornada Biomed XXI
María rosario luquin idisna-Jornada Biomed XXIMaría rosario luquin idisna-Jornada Biomed XXI
María rosario luquin idisna-Jornada Biomed XXICein
 
Julio maset cinfa-Jornada Biomed XXI
Julio maset cinfa-Jornada Biomed XXIJulio maset cinfa-Jornada Biomed XXI
Julio maset cinfa-Jornada Biomed XXICein
 
Presentaciones Showroom Jornada "Agrofuture&Ventures"
Presentaciones Showroom Jornada "Agrofuture&Ventures"Presentaciones Showroom Jornada "Agrofuture&Ventures"
Presentaciones Showroom Jornada "Agrofuture&Ventures"Cein
 
Sodena y CEIN. ORIZONT. Construye una propuesta ganadora
Sodena y CEIN. ORIZONT. Construye una propuesta ganadoraSodena y CEIN. ORIZONT. Construye una propuesta ganadora
Sodena y CEIN. ORIZONT. Construye una propuesta ganadoraCein
 
Carlos Franco (CDTI). Financiación de la innovación en agroalimentación
Carlos Franco (CDTI). Financiación de la innovación en agroalimentaciónCarlos Franco (CDTI). Financiación de la innovación en agroalimentación
Carlos Franco (CDTI). Financiación de la innovación en agroalimentaciónCein
 
Alberto Moratial (ENISA). Financiación de la innovación en agroalimentación
Alberto Moratial (ENISA). Financiación de la innovación en agroalimentaciónAlberto Moratial (ENISA). Financiación de la innovación en agroalimentación
Alberto Moratial (ENISA). Financiación de la innovación en agroalimentaciónCein
 
Victoria Iriarte (Sodena). Financiación de la innovación en agroalimentación
Victoria Iriarte (Sodena). Financiación de la innovación en agroalimentaciónVictoria Iriarte (Sodena). Financiación de la innovación en agroalimentación
Victoria Iriarte (Sodena). Financiación de la innovación en agroalimentaciónCein
 
María Arbeloa (Gobierno de Navarra). Financiación de la innovación en agroali...
María Arbeloa (Gobierno de Navarra). Financiación de la innovación en agroali...María Arbeloa (Gobierno de Navarra). Financiación de la innovación en agroali...
María Arbeloa (Gobierno de Navarra). Financiación de la innovación en agroali...Cein
 
Jorge Fernández (Planasa). INSPIRING SESSION. La anticipación y la I+D+i en l...
Jorge Fernández (Planasa). INSPIRING SESSION. La anticipación y la I+D+i en l...Jorge Fernández (Planasa). INSPIRING SESSION. La anticipación y la I+D+i en l...
Jorge Fernández (Planasa). INSPIRING SESSION. La anticipación y la I+D+i en l...Cein
 
Ignacio Hernández (General Mills). INSPIRING SESSION. La anticipación y la I+...
Ignacio Hernández (General Mills). INSPIRING SESSION. La anticipación y la I+...Ignacio Hernández (General Mills). INSPIRING SESSION. La anticipación y la I+...
Ignacio Hernández (General Mills). INSPIRING SESSION. La anticipación y la I+...Cein
 

Mehr von Cein (20)

Directorio Viveros CEIN 2022 Septiembre.pptx
Directorio Viveros CEIN 2022 Septiembre.pptxDirectorio Viveros CEIN 2022 Septiembre.pptx
Directorio Viveros CEIN 2022 Septiembre.pptx
 
II Feria del Trabajo Autónomo de Navarra 2019
II Feria del Trabajo Autónomo de Navarra 2019II Feria del Trabajo Autónomo de Navarra 2019
II Feria del Trabajo Autónomo de Navarra 2019
 
Jornada Energy Trends-ciudades inteligentes-Zabala
Jornada Energy Trends-ciudades inteligentes-ZabalaJornada Energy Trends-ciudades inteligentes-Zabala
Jornada Energy Trends-ciudades inteligentes-Zabala
 
Jornada Energy Trends-Retos tecnológicos
Jornada Energy Trends-Retos tecnológicosJornada Energy Trends-Retos tecnológicos
Jornada Energy Trends-Retos tecnológicos
 
Showroom energy trends
Showroom energy trends Showroom energy trends
Showroom energy trends
 
Completa showroom new industry
Completa showroom new industryCompleta showroom new industry
Completa showroom new industry
 
Tecnalia modelos oppsnegocioeradigitalindustrial_cein_151028
Tecnalia modelos oppsnegocioeradigitalindustrial_cein_151028Tecnalia modelos oppsnegocioeradigitalindustrial_cein_151028
Tecnalia modelos oppsnegocioeradigitalindustrial_cein_151028
 
Workshop completo.Jornada Biomed XXI
Workshop completo.Jornada Biomed XXIWorkshop completo.Jornada Biomed XXI
Workshop completo.Jornada Biomed XXI
 
Luis gabilondo gobierno de navarra-Jornada Biomed XXI
Luis gabilondo gobierno de navarra-Jornada Biomed XXILuis gabilondo gobierno de navarra-Jornada Biomed XXI
Luis gabilondo gobierno de navarra-Jornada Biomed XXI
 
Juan ramón de la torre aditech-Jornada Biomed XXI
Juan ramón de la torre aditech-Jornada Biomed XXIJuan ramón de la torre aditech-Jornada Biomed XXI
Juan ramón de la torre aditech-Jornada Biomed XXI
 
María rosario luquin idisna-Jornada Biomed XXI
María rosario luquin idisna-Jornada Biomed XXIMaría rosario luquin idisna-Jornada Biomed XXI
María rosario luquin idisna-Jornada Biomed XXI
 
Julio maset cinfa-Jornada Biomed XXI
Julio maset cinfa-Jornada Biomed XXIJulio maset cinfa-Jornada Biomed XXI
Julio maset cinfa-Jornada Biomed XXI
 
Presentaciones Showroom Jornada "Agrofuture&Ventures"
Presentaciones Showroom Jornada "Agrofuture&Ventures"Presentaciones Showroom Jornada "Agrofuture&Ventures"
Presentaciones Showroom Jornada "Agrofuture&Ventures"
 
Sodena y CEIN. ORIZONT. Construye una propuesta ganadora
Sodena y CEIN. ORIZONT. Construye una propuesta ganadoraSodena y CEIN. ORIZONT. Construye una propuesta ganadora
Sodena y CEIN. ORIZONT. Construye una propuesta ganadora
 
Carlos Franco (CDTI). Financiación de la innovación en agroalimentación
Carlos Franco (CDTI). Financiación de la innovación en agroalimentaciónCarlos Franco (CDTI). Financiación de la innovación en agroalimentación
Carlos Franco (CDTI). Financiación de la innovación en agroalimentación
 
Alberto Moratial (ENISA). Financiación de la innovación en agroalimentación
Alberto Moratial (ENISA). Financiación de la innovación en agroalimentaciónAlberto Moratial (ENISA). Financiación de la innovación en agroalimentación
Alberto Moratial (ENISA). Financiación de la innovación en agroalimentación
 
Victoria Iriarte (Sodena). Financiación de la innovación en agroalimentación
Victoria Iriarte (Sodena). Financiación de la innovación en agroalimentaciónVictoria Iriarte (Sodena). Financiación de la innovación en agroalimentación
Victoria Iriarte (Sodena). Financiación de la innovación en agroalimentación
 
María Arbeloa (Gobierno de Navarra). Financiación de la innovación en agroali...
María Arbeloa (Gobierno de Navarra). Financiación de la innovación en agroali...María Arbeloa (Gobierno de Navarra). Financiación de la innovación en agroali...
María Arbeloa (Gobierno de Navarra). Financiación de la innovación en agroali...
 
Jorge Fernández (Planasa). INSPIRING SESSION. La anticipación y la I+D+i en l...
Jorge Fernández (Planasa). INSPIRING SESSION. La anticipación y la I+D+i en l...Jorge Fernández (Planasa). INSPIRING SESSION. La anticipación y la I+D+i en l...
Jorge Fernández (Planasa). INSPIRING SESSION. La anticipación y la I+D+i en l...
 
Ignacio Hernández (General Mills). INSPIRING SESSION. La anticipación y la I+...
Ignacio Hernández (General Mills). INSPIRING SESSION. La anticipación y la I+...Ignacio Hernández (General Mills). INSPIRING SESSION. La anticipación y la I+...
Ignacio Hernández (General Mills). INSPIRING SESSION. La anticipación y la I+...
 

Cesnavarra 2008-boletín 9

  • 1. Título Dilbert. Texto El humor es uno de los ingredientes que nos hacen la vida más agradable. Dentro de él, el humor gráfico tiene muchas vertientes: desde aquéllos que apenas necesitan acompañar las imágenes con palabras para hacernos esbozar una sonrisa, como Sempé1,o uno de sus más aventajados seguidores, Quino2. Éste último es sobre todo conocido por su tira cómica del personaje Mafalda3. La tira TIC por excelencia es Dilbert, creada por Scott Adams. Su éxito es tal que incluso ha inspirado el llamado Principio de Dilbert, que es una variación del de Peter. En la misma aparecen una serie de personajes alrededor del mundo del trabajo en una compañía dedicada a producir productos tecnológicos (no podemos concretar más puesto que una de las características es el caos que acompaña a dicha empresa). Así, aparte del propio Dilbert, un ingeniero, están su colega Wally, el Jefe, Dogbert, la mascota de Dilbert y que actúa como consultor (!), etc.
  • 2. Las situaciones reflejadas en Dilbert son las cotidianas en una empresa, sazonadas con un tono mordaz y absurdo pero, a la vez, fiel reflejo de la realidad. Adams no deja títere con cabeza y abarca todos los conceptos
  • 3. que rigen la actividad de una empresa, empezando por la orientación al cliente: - (Jefe): Nos tenemos que preguntar constantemente lo qué podemos hacer para tener contentos a nuestros clientes. - (Alice): Podríamos dejar de hacer estas reuniones, echar a todos los presentes y reducir los precios de nuestros productos. - (Jefe): Estaba pensando más bien en un eslogan... - (Wally): ¿Qué tal: 'Despilfarramos su dinero'? Siguiendo por la, a veces, difícil relación entre los departamentos comerciales y técnicos: - (Dilbert): Stan, le prometiste cosas al cliente que el departamento de ingeniería no puede realizar. ¿Sabes lo que eso significa? - (Stan): Significa que soy un gran vendedor y tú eres un mal ingeniero. Tal vez te convendría tomar clases nocturnas. - (Dilbert, pensando): Sí, de karate. Por supuesto las relaciones entre jefe y empleado son objeto de numerosas tiras: - (Jefe): Alice, me cuentan que pasas tiempo con tu familia por la noche. Este tiempo lo podrías aprovechar para trabajar sin cobrar extra. - (Alice): ¿Tiene usted familia? - (Jefe, pensando): Hmmm... Eso explicaría la gente que hay en mi casa... ●●● - (Jefe): Hemos rediseñado el organigrama para mostrar la Dirección en el rango más bajo. Como símbolo de cómo apoyan a nuestros empleados más importantes. - (Dilbert): Pregunta: ¿por qué los empleados más importantes son los que menos cobran? - (Jefe): Porque a ellos nunca se les ocurrirían ideas como este concepto de organigrama invertido. ●●● - (Dilbert): Aquí tiene mi hoja de horas trabajadas, rellenada en incrementos de quince minutos. Y aquí tiene mi informe de estado mensual, mi previsión de gastos, mis trabajos cumplidos, mi lista de peligros... - (Jefe, pensando): Nunca tan poco se ha medido tanto. ●●● - (Jefe): Aunque técnicamente soy 'El Jefe', creo que es mi trabajo proporcionarles los recursos necesarios a ustedes, los empleados. - (Dilbert): Necesito más dinero para mi proyecto. - (Jefe): Lo siento. Ya no queda nada. - (Dilbert): Tal vez le pida una cita para poder hablar del tema.
  • 4. - (Jefe): Tengo veinte minutos en mi agenda, pero habrá que esperar hasta el verano que viene. Las reuniones, cómo no, dan también mucho argumento: - (Wally, a Dilbert): Aquí tienes la tarjeta de bingo para la reunión. Si el jefe utiliza una palabra clave que aparece en tu tarjeta, la tachas. El objetivo es tachar una línea. - (Jefe): Hoy están todos muy atentos. Veo que mi liderazgo proactivo está surtiendo efecto. - (Wally): Bingo, señor. Y también las certificaciones: - (Jefe): Te nombro responsable de nuestro proyecto para conseguir la certificación 'ISO 9000'. No sabemos de qué se trata, pero queda muy bonito en los folletos de empresa. - (Dilbert): Creo que certifica que seguimos procesos consistentes. - (Jefe): Sí... Siempre mentimos en nuestros folletos. También hay nuevas incorporaciones a las que cuidar: - (Jefe): Matt acaba de salir de la escuela de ingenieros. Tú vas a ser su mentor. Hagas lo que hagas no le aplastes el espíritu antes del miércoles. - (Dilbert): ¿Por qué aplazarlo tanto? - (Jefe): Porque aposté 10 pavos a que podríamos hacer que aguante hasta el jueves. Así como funciones que clarificar: - (Dilbert): Como todos saben, me han nombrado líder del equipo. - (Alice): ¿Decides los aumentos de sueldo? - (Dilbert): No. - (Alice): ¿Apruebas los gastos? - (Dilbert): No. - (Alice): ¿Puedes despedir a la gente? - (Dilbert): No. Soy un líder, no un jefe. - (Alice): Bien, vete y nosotros te seguiremos. Finalmente, se satiriza lo absurdo que, a veces, es la tecnología: - (Ordenador): Para configurar la aplicación, introduzca el nombre del ganador del año que viene del Oscar al mejor actor. - (Dilbert teclea algo) - (Ordenador): Por favor, espera. Algunos de los dogmas de Dogbert:  Todos los trabajos son asignados a la persona que menos los entiende.
  • 5. Todas las empresas necesitan una estrategia para que los empleados sepan cuál no es su trabajo.  Un optimista no es más que un pesimista sin experiencia laboral.  Todos los rumores son auténticos... sobre todo si tu jefe los desmiente.  Cualquier estrategia acertada parecerá ridícula cuando se lleve a cabo.  Lo que haces es mucho menos impresionante de lo que implica tu cargo.  Un experto es una persona que ha sido asignado a un trabajo para expertos. No se necesitan más cualificaciones. Se atribuye a Guy Kawasaki la siguiente frase: 'Hay dos tipos de compañías, las que reconocen que son exactamente como la de Dilbert y las que también lo son pero aún no lo saben.' Puede parecer que lo aquí expresado sólo serviría como desahogo para personas quemadas. Pero si bien esto es cierto, quedarse en este estadio sería simplificar las cosas. En mi opinión las tiras de Dilbert, y otros libros de Scott Adams, sirven como diagnóstico y reflejo de una realidad que sirven para desdramatizar situaciones pero no para olvidarlas, sino corregirlas. Además cuando uno ve que en todos los sitios cuecen habas, empieza a relajarse y a reírse de sí mismo, lo cual suele ser un signo de inteligencia. ¿Una última perla? ¡Venga! - (Ejecutivo): Yo pronostico que no venderemos nada durante los dos primeros años, y que después despegarán repentinamente. - (Dilbert): ¿Por qué? - (Ejecutivo): El aumento lo añadí para que me aprobaran el proyecto. El plazo de dos años me da tiempo para que me asciendan. - (Dilbert): ¿Y qué hay de las responsabilidades? - (Ejecutivo): Aquí es donde entras tú en juego. Quien piense que este es un artículo frívolo, puede leer el último libro de Tom DeMarco y compañeros, que también trata todos estos temas. Referencias:  La tira diaria.  Libros en español.  Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior. Si quieres enviar algún comentario o sugerir temas a tratar en otros artículos, escribe a: curtasun[simboloArroba]cein.es
  • 6. Categorías General Tema Desarrollo Autor Carlos Urtasun Mes Septiembre Año 2008 Boletín 09 Títul XSL-FO (Parte 3): objetos. o Text Ahora que ya hemos dado el formato al documento, vamos a ver los o tipos de objetos que pueden aparecer en el mismo. Imágenes Este elemento, por sí mismo se considera un objeto inline: sin embargo, se puede convertir en otro de nivel de bloque incluyéndolo en un objeto como fo:block. <fo:block text-align="center"> <fo:external-graphic width="8mm" height="15mm" src=” file:../graphics/image.gif” /> </fo:block> Líneas guía El elemento que crea una línea guía es fo:leader. Debe ir dentro de un elemento block. Contiene el atributo leader-pattern con los posibles valores space, rule, dots, use-content e inherit. Su estilo viene definido por rule- style, y su longitud por leader-length. Su grosor lo define rule- thickness. En el ejemplo, se crea lo que suele ser un formato de fecha: Fecha:_______ de_________ de______ <fo:block text-align="center"> Fecha: <fo:leader leader-pattern="rule" leader-length="8mm" rule-thickness="0.3mm"/> de <fo:leader leader-pattern="rule" leader-length="30mm" rule-thickness="0.3mm"/> de <fo:leader leader-pattern="rule" leader-length="10mm" rule-thickness="0.3mm"/> </fo:block>
  • 7. Tablas Son objetos de formato de nivel de bloque. El elemento es fo:table. Se debe definir el número de columnas que tiene la tabla en fo:table-column con el ancho de cada una de ellas, en su atributo column-width. Lo siguiente es crear el cuerpo de la tabla con sus filas y sus celdas, donde se pintan los datos. Las tablas también pueden tener cabecera (table-header) y pie (table-footer). Esto se ve claramente en un ejemplo: <fo:block space-before="3mm"> <fo:table table-layout="fixed"> <fo:table-column column-width="15mm" /> <fo:table-column column-width="20mm" number-columns-repeated=”2”/> <fo:table-footer> <fo:table-row> <fo:table-cell number-columns- spanned="3"> <fo:block text- align="end" font-size="7pt"> Este es el pie de la tabla </fo:block> </fo:table-cell> </fo:table-row> </fo:table-footer> <fo:table-header> <fo:table-row keep-with-next="always"> <fo:table-cell> <fo:block> <xsl:text>&#160;</ xsl:text> </fo:block> </fo:table-cell> <fo:table-cell display-align="center" border-bottom- width="1pt" border-bottom-color="black" border-bottom- style="solid" padding-after="1mm" padding-before="1mm"> <fo:block text-align="start" font- size="8pt"> <xsl:text> cabecera columna 2 </xsl:text> </fo:block> </fo:table-cell> <fo:table-cell display-align="center" border-bottom- width="1pt" border-bottom-color="black" border-bottom- style="solid" padding-after="1mm" padding-before="1mm"> <fo:block text-align="start" font-size="8pt"> <xsl:text> cabecera columna 3 </xsl:text> </fo:block> </fo:table-cell> </fo:table-row>
  • 8. </fo:table-header> <fo:table-body> <fo:table-row keep-with-next="always"> <fo:table-cell> <fo:block> <xsl:value- of select="@dato1"/> </fo:block> </fo:table-cell> <fo:table-cell> <fo:block> <xsl:value- of select="@dato2"/> </fo:block> </fo:table-cell> <fo:table-cell> <fo:block> <xsl:value-of select="@dato3"/> </fo:block> </fo:table-cell> </fo:table-row> </fo:table-body> </fo:table> <fo:block> A destacar el atributo number-columns-repeated en fo:table-column, que nos dice el número de columnas de ese mismo tamaño a crear. A todas las celdas se les puede pintar borde superior, inferior, derecho o izquierdo, de diferente grosor, color y tipo. Además, con el atributo display-align, le decimos en qué lugar en vertical de la celda, mostrar el contenido. Para que no se produzca un salto de página entre filas, se usa el atributo keep-with-next, o keep-with- previous. Listas Para formar una lista se utiliza el elemento fo:list-block. Es un contenedor de ítems que se muestran en forma de lista. Cada uno de estos elementos, contiene un fo:list-item que es cada ítem de la lista, el cual contiene una etiqueta (fo:list-item-label) y su contenido (fo:list-item-body). Hay varios atributos importantes para crear una lista, a saber: provisional-distance-between-starts: es un atributo de list-block. Nos dice la distancia que hay entre el comienzo del área de la etiqueta y el comienzo del área del contenido del ítem. Este valor no se usa directamente, sino que vale para calcular la función body-start(). provisional-label-separation: es un atributo de list-block. Nos marca la distancia que hay entre el final de la etiquta y el principio del contenido del ítem. Este valor no se usa directamente, sino que vale para calcular la función label-end(). La función body-start() se usa como valor del atributo start-indent
  • 9. del elemento fo:list-item-body, y la función label-end() se usa como valor del atributo end-indent del elemento fo:list-item-label. Ejemplo: <fo:list-block provisional-distance-between-starts="20mm" provisional-label-separation="10mm"> <fo:list-item> <fo:list-item-label end-indent="label-end()" start- indent="6mm"> <fo:block>&#x2022;</fo:block> </fo:list-item-label> <fo:list-item-body start-indent="body-start()" end- indent="90mm"> <fo:block>contenido1</fo:block> </fo:list-item-body> </fo:list-item> <fo:list-item> <fo:list-item-label end-indent="label-end()" start- indent="6mm"> <fo:block>&#x2022;</fo:blo ck> </fo:list-item-label> <fo:list-item-body start-indent="body-start()" end- indent="90mm"> <fo:block>contenido2</fo:block> </fo:list-item-body> </fo:list-item> </fo:list-block> Notas a pie de página El objeto fo:footnote define una nota a pie de página dentro de region-body de una página. Tiene dos hijos: fo:inline (referencia de la nota) y fo:footnote-body (contenido de la nota). Ejemplo: <fo:block font-size="10pt">Este es el texto en el que voy a insertar una <fo:footnote> <fo:inline>nota</fo:inline>
  • 10. <fo:inline vertical-align="super">1</fo:inline> <fo:footnote-body> <fo:block>1. Este es el contenido de la nota</fo:block> </fo:footnote-body> </fo:footnote> aquí sigo con el texto </fo:block> Si a este ejemplo le añadimos leader y list, quedaría así: <fo:block font-size="10pt">Este es el texto en el que voy a insertar una <fo:footnote> <fo:inline> nota</fo:inline> <fo:inline vertical-align="super">1</fo:inline> <fo:footnote-body> <fo:block text-align-last="justify"> <fo:leader leader-pattern="rule"/> </fo:block> <fo:list-block> <fo:list-item> <fo:list-item-label end- indent="label-end()"> <fo:block>1</fo:bl ock> </fo:list-item-label> <fo:list-item-body start- indent="body-start()"> <fo:block> Este es el contenido de la nota </fo:block> </fo:list-item-body> </fo:list-item> </fo:list-block> </fo:footnote-body> </fo:footnote> aquí sigo con el texto </fo:block> Marcadores (Runnig headers) Se suele utilizar en cabecera o pie de página para mostrar algún texto, como por ejemplo, en los diccionarios en los que en la cabecera se muestra la primera palabra por la que empieza esa página y la última en la que acaba. Su contenido cambia en función del flujo. Consta de dos elementos necesarios: fo:marker y fo:retrieve- marker. El elemento fo:marker nos dice qué texto queremos que se pinte. Se suele colocar dentro de un block. Tiene un atributo marker-class-
  • 11. name que contiene el nombre del marcador. El elemento fo:retrieve-marker se suele colocar en la cabecera o el pie (siempre en un fo:static-content), lugar donde se pintará. Tiene el atributo retrieve-class-name con el nombre del marker que queremos mostrar, es decir, el valor de marker-class-name deberá coincidir con el valor de retrieve-class-name. Este elemento tiene además otro atributo interesante, retrieve-position que nos indica la posición del texto a mostrar, es decir, si mostrará la primera o la última Ejemplo: En el flow: (Es como si dijéramos: utilice este contenido cuando quiera el contenido del marker llamado título) <fo:block> <fo:marker marker-class-name="titulo"> <fo:block> <xsl:value-of select="."/> </fo:block> </fo:marker> </fo:block> En el static-content: <fo:block> <fo:retrieve-marker retrieve-class-name="titulo" retrieve-position="first-starting-within-page" retrieve-boundary="page"/> </fo:block> Enlaces El elemento que introduce los enlaces es el fo:basic-link. El enlace a un documento remoto, lleva su URI en el atributo external- destination. Si el enlace te lleva al mismo documento, la URI va en el atributo internal-destination. Así, un basic-link solo tendrá uno de estos dos atributos. El documento destino se puede elegir dónde abrirlo gracias a otro atributo: show-destination. Si su valor es new, se abre en una nueva ventana, y si es replace, se cargará en la misma ventana. Esta última opción es la que viene por defecto. <fo:block> <fo:basic-link external-destination="http://www.google.es"> Enlace </fo:basic-link> </fo:block> En el siguiente ejemplo, vamos a ver cómo se haría un índice con enlaces a las propias páginas del documento: <fo:block font-size="18pt" font-weight="bold" text-align="center"> Índice
  • 12. </fo:block> <fo:block text-align-last="justify"> <fo:basic-link color="blue" internal-destination="capitulo1"> Título 1 </fo:basic-link> <fo:inline keep-together.within-line="always"> <fo:leader leader-pattern="dots"/> <fo:page-number-citation ref-id="capitulo1" /> </fo:inline> </fo:block> <fo:block id="capitulo1" break-before="page" font-size="18pt"> Título 1 </fo:block> Referencias: http://zvon.org/xxl/xslfoReference/Output/index.html Cate CES OpenSouce/Java gorí as Tem Varios a Auto Raquel Urdangarin r Mes Septiembre Año 2008 Bole 09 tín Título Implantación de Nagios (Parte 2). Texto TOPOLOGIA E INTERPRETACIÓN DE RESULTADOS En el anterior artículo descubrimos Nagios y analizamos la forma de instalarlo en nuestra red. Esta parte pretende ajustar la configuración de los recursos que monitorizar a nuestras necesidades. 1 Configuración de los parámetros de funcionamiento: La forma de configurar nagios para adaptarlo a nuestros requerimientos es editar varios ficheros de configuración.
  • 13. Definición de máquinas a monitorizar: tendremos que añadir a /etc/nagios/hosts.cfg una nueva entrada por cada host, respetando una "plantilla": define host{ use generis-host ; Nombre de la plantilla a utilizar host_name irati ; Nombre de la máquina alias Javacenter Server 1 ; Alias address 192.168.14.145 ; IP check_command check-host-alive ; Comando que utilizamos para comprobar la disponibilidad de la maquina max_check_attempts 10 ; Opciones de chequeo y notificación... notification_interval 120 ; notification_period 24x7 ; notification_options d,u,r ; } En esta plantilla vemos los parámetros que definirán el host, como nombre y alias, la dirección de red. Además de estos podemos definir como se va a comprobar la disponibilidad de la máquina (check_command) y parámetros de intentos de comprobación y notificación de alertas. Definición de grupos de máquinas: es útil para separar redes o diferenciar tipos de máquinas. Tenemos que editar otro fichero (hostgroups.cfg). La dinámica es similar a la de hosts.cfg (y a la de todos los ficheros de configuración) define hostgroup{ hostgroup_name printers alias Javacenter Printers contact_groups admins members printer1,printer2 } El grupo tiene un nombre, un alias, un grupo de contacto y los miembros. En este caso mostramos el grupo de las impresoras. Definición de monitoreo de servicios, este es uno de los ficheros trascendentales para el perfilar el monitoreo, en el fichero services.cfg se definen todos los servicios que se van a checkear en cada hot.
  • 14. define service{ use generic-service ; Nombre del “servicio plantilla” a usar host_name gw,kirnis,isis,mider,rea,isthar service_description PING is_volatile 0 check_period 24x7 max_check_attempts 3 normal_check_interval 5 retry_check_interval 1 contact_groups admins notification_interval 240 notification_period 24x7 notification_options c,r check_command check_ping!100.0,20%!500.0,60% } Al definir el servicio incluiremos el host o hosts a los que se les va aplicar, una descripción, parámetros de checkeo, reintentos y notificaciones, y además el comando que vamos a usar en el servicio. Como se ve en el ejemplo, el comando es check_ping!100.0,20%!500.0,60% Realmente el comando llama a un plugin (que previamente ha sido instalado) y le pasa los parámetros adecuados en cada caso, porque dependiendo del plugin necesitara unos u otros. Aunque seguramente siempre estén los umbrales que definen en qué situación está el servicio que queremos monitorizar. El modo de funcionamiento de nagios es comprobar en qué estado se encuentra el recurso observado. Estos estados se establecen en la definición del servicio y suelen ser ESTADO NORMAL, ALERTA y CRITICO aunque dependerá del plugin en cada caso. Si por ejemplo queremos monitorizar el estado en el que se encuentra el disco duro de una máquina, establecemos que un uso menor de 60% es el estado NORMAL, entre 60% y 90% ALERTA y más de 90% CRITICO. Una vez definido el servicio, el demonio de nagios consultará el plugin correspondiente y mostrará el resultado obtenido en la interfaz web. La sintaxis seria la siguiente: check_disk!40%!10%!/dev/sda1 ( los umbrales y el dispositivo a monitorizar ) Los plugins en este caso están instalados
  • 15. en /usr/lib64/nagios/plugins/ y podemos ver desde monitores de la carga del procesador, el estado de la RAM o de servicios http como servidores ftp o web. Además de los proporcionados por nagios existen numerosos creados por la comunidad. Hay que tener en cuenta que estos plugins sólo son capaces de trabajar en modo local, es decir, sólo pueden trabajar con datos de la máquina en la que se ejecutan. Para poder monitorizar datos remotos necesitamos la ayuda de otro plugin (check_nrpe) que hace de proxy entre el demonio de nagios y los plugins que se encuentran en la máquina remota. Lógicamente en la máquina remota también estará ejecutándose otro demonio o servicio que se encargará de recoger la petición del plugin desde el servidor, llamare al plugin correspondiente y devolver el resultado al servidor, como hemos comentado antes. Entonces para definir un servicio remoto debemos utilizar siempre el plugin check_nrpe, con lo que la sintaxis quedaría de la siguiente forma: check_nrpe!check_disk!c:!150!200 Se le llama al nrpe y como argumentos se le pasa el plugin a ejecutar con sus respectivos umbrales. Hay que tener en cuenta que la definición del comando puede ser sensible al sistema operativo de la máquina. Comentar que también en cada máquina remota a monitorizar hay que configurar el demonio que atienda las peticiones del plugin check_nrpe y copiar los plugins que vayamos a necesitar. Habrá que adecuar a nuestra configuración un fichero de configuración (nrpe.cfg) en el que se definen el puerto, los clientes aceptados, si se utiliza ssl, y demás parámetros de funcionamiento, así como los plugins ofertados. Por ejemplo si queremos que se pueda acceder al plugin de comprobación de uso de disco, tenemos que definirlo, indicar la ruta al ejecutable y establecer la forma en la que se le pasarán los argumentos command[check_disk]=C:nrpe_ntpluginsdiskspace_nrpe_nt.exe $ARG1$ $ARG2$ $ARG3$ De esta forma iremos definiendo los servicios que nos interesen y podremos empezar a recoger los datos devueltos. Además se pueden definir grupos de contacto, formas de notificación y estructuras que nos faciliten el tratamiento de esa información. 2 Visualización de los datos recogidos por Nagios: Parte de los requerimientos de la instalación de Nagios eran disponer de servidor Apache2 y de un sistema de archivado de los
  • 16. datos recogidos que varía entre un sistema basado en ficheros de texto o basados en bases de datos relacionales. En este ultimo caso podíamos optar entre un motor de base de datos MySQL o PostGresSQL: nosotros hemos optado por MySQL. La visualización y cierto grado de gestión de Nagios se hacen a través de un interfaz web que se integra en Apache2 durante el proceso de instalación. Existen otros de interfaces gráficos desarrollados por terceros más ricos y amigables. Sin embargo hemos probado el que ya viene montado en la distribución de Nagios. La elección de otros tipos de herramientas de para interactuar con Nagios queda para otro momento. Repasar todas las opciones del interfaz gráfico llevaría mucho tiempo, así que hemos seleccionado 4 muestras. Aunque hay muchas más hemos seleccionado éstas porque representan el estatus de los servicios que monitorizamos, reflejan el almacenamiento y registro de los datos recogidos y la configuración de servicio. Service Detail: esta captura representa la opción service detail. Esta opción está localizada en la zona “Monitoring” y muestra el estado de todos los servicios definidos para ser monitorizados.
  • 17. Alert History, localizado en la zona “Reporting”, nos muestra un histórico de las alertas producidas. Notifications, también en la zona Reporting, muestra las notificaciones realizadas (esto todavía esta en fase de implementación)
  • 18. host: esta opción está localizada en la zona configuration. Deberemos seleccionar qué aspecto de la configuración de nagios queremos observar, ya sean los servicios, los host, plugins etc. En este caso hemos seleccionado “host”, que representa las estaciones de trabajo, servidores e impresoras.
  • 19. Categ CES OpenSouce/Java orías Tema Arquitectura Autor Igor Unanua Mes Septiembre Año 2008 Boletí 09 n Títu Proyecto piloto TDT: parte 1: definición lo Tex 15 de Octubre del 2006: “Has sido seleccionado para to Responsable del Centro Java y Open Source”, no cabía en mi de gozo...eso ayudaría a afrontar lo que se avecinaba, “el 23 de Noviembre hay una reunión en NGA para conocer la
  • 20. encomienda del proyecto que nos han encargado y para presentarte como responsable, hazlo bien, mucho depende de este proyecto”. Esta frase marcaría mi periplo durante el 2007, cuya experiencia trataré de transmitir a lo largo de este y los próximos artículos. Así pues, allí me encontraba, el 23 de noviembre, esperando mi bautismo como “responsable” ante NGA y Gobierno, frente a un conjunto de personas que posteriormente se perfilarían como el comité de seguimiento y la dirección del proyecto, es decir, las personas con las que tenía que trabajar y aquellas a las que debía informar. En esa dirección estábamos yo, como responsable, una persona de NGA y otra de la DGpSI. Nuestras funciones consistían en dirigir el avance del proyecto llevándolo a buen puerto, cumpliendo los objetivos marcados, tomando las decisiones pertinentes y llevando a cabo las acciones necesarias, todo de forma consensuada. Así mismo, este equipo debía rendir cuentas ante el comité sobre el avance y acciones. Este comité lo formaban representantes de CEIN, NGA y DGpSI. Esa reunión nos puso caras a todos y nos fue entregada oficialmente la encomienda del proyecto que llevaba por título: PLIEGO DE PRESCRIPCIONES TÉCNICAS DE LA ENCOMIENDA A NGA PARA EL DESARROLLO EN LOS CENTROS DE EXCELENCIA DE UN PROYECTO PILOTO PARA EL DISEÑO E IMPLANTACIÓN DE UNA PLATAFORMA SOFTWARE PARA DESARROLLAR Y MANTENER SERVICIOS INTERACTIVOS A TRAVES DE LA TELEVISIÓN DIGITAL TERRESTRE (TDT) A continuación resumo los puntos más importantes: ¿Porque la TDT y su papel para la administración? La tendencia actual es que la información sea accesible desde cualquier parte y con cualquier terminal. La familiaridad, comodidad, penetración y alcance de la TV la convierten en un dispositivo preferente para extender la Sociedad de la Información, para favorecer participación del tele-espectador (interactividad) y reducir la “brecha digital”: aquella población sin posibilidades de acceder a Internet por edad, reticencia, disposición, educación o poder adquisitivo. Por tanto, la TDT permite acercar la administración
  • 21. electrónica a aquellos ciudadanos a los que resulta difícil llegar a través de Internet: ancianos, niños, discapacitados, desempleados, ciudadanos con retas más, menor formación, etc, proporcionando a la ciudadanía un nuevo canal de Servicios Administrativos de interés público y la posibilidad de participar = una sociedad de la información amplia, participativa y democrática. Objetivos  Creación de aplicaciones sobre el estándar MHP (Multimedia Home Platform) que permitan la integración de contenidos interactivos en la TDT (Televisión Digital Terrestre), y establecer un nuevo canal entre la Administración y los ciudadanos potenciando el desarrollo de la e-Administración.  Aprendizaje y transferencia de conocimiento a las empresas del sector TIC de Navarra mediante el desarrollo del proyecto en los Centros de Excelencia. Había una serie de objetivos añadidos entres lo que cabe destacarse: potenciar la TDT y modernizar la administración. Alcance del proyecto  Definición de especificaciones y puesta en marcha de la plataforma tecnológica necesaria para la generación y mantenimiento de aplicaciones interactivas en TDT sobre el estándar MHP.  Desarrollo de un conjunto de servicios hacia el ciudadano (priorizando los correspondientes a la Hacienda Tributaria), que abarquen todas las tipologías (Informativos, Interactivos y Transaccionales). Plan inicial La ejecución no podrá exceder 12 meses desde la formación del equipo de trabajo. En cualquier caso los trabajos estarán finalizados a 31 de diciembre de 2007.  Fase I: transferencia de conocimiento al equipo de trabajo, análisis funcional, especificación y puesta en marcha de la plataforma tecnológica necesaria para la generación y mantenimiento de aplicaciones interactivas en TDT sobre el estándar MHP  Fase II: implantación de servicios informativos sobre la plataforma base de Televisión Digital  Fase III: ampliación de funcionalidades de la plataforma de Televisión Digital, habilitando el canal de retorno (interactividad). Equipo de trabajo
  • 22. Comité de dirección: dirección del proyecto, formado por el responsable del Servicio de Promoción de la Sociedad de la Información, un responsable de NGA y el Jefe de Proyecto en el Centro de Excelencia.  Equipo de Trabajo: técnicos destinados al desarrollo del proyecto:  1 persona del Servicio de Promoción de la Sociedad de la Información que coordinará los contenidos a incluir (dedicación 10%).  1 persona de NGA encargada de coordinar al equipo y los trabajos realizados (dedicación 10%)  Responsable del Centro de Excelencia Java y Open Source (dedicación 60%)  Becario del Centro de Excelencia Java y Open Source con conocimientos de Java (dedicación 100%)  1 analista especializado en proyectos de desarrollos de servicios TDT encargado de aportar su experiencia y conocimiento (dedicación 50%)  1 ingeniero de desarrollo especialista en MHP (dedicación 60%)  2 técnicos de empresas del sector TIC de Navarra, con experiencia de 2 a 3 años en Java (dedicación 60%) Planificación Se elaborará un Plan de Trabajo que defina las tareas a realizar, los responsables de su ejecución y los resultados a obtener en cada caso. Se aportará también la secuencia y el cronograma de módulos o agrupación de funcionalidades que se proponga seguir. En cualquier caso existirá una 1ª Fase a finalizar a 30 de abril de 2007, en cual estarán para poner en producción un mínimo de 2 de servicios en el ámbito de la Hacienda Tributaria. Tras leerlo mi primera impresión fue confusa: en la planificación y en el alcance, dos aspectos muy delicados. El título del proyecto sugería un alcance concreto: el desarrollo de toda una plataforma que soportase los contenidos de la administración para la TDT. Sin embargo, el contenido del texto vislumbraba otro alcance añadido: el desarrollo de un conjunto de servicios de la administración para TDT. Se trataba de alcances y trabajos diferentes, una ambigüedad que presagiaba dificultades a futuro.
  • 23. Por otro lado, había dos planificaciones incoherentes entre si. Una contemplaba 3 fases: una para formar, preparar el equipo y definir la plataforma, a continuación otra en la cual se incorporaban a la plataforma servicios informativos y una última donde se incorporaban servicios interactivos. Un planteamiento lógico y de dificultad gradual. Por el contrario, luego se hablaba de otra planificación en 2 fases: una en la cual se desarrollaban los servicios para Hacienda (interactivos), y una segunda aún por definir. Se empezaba por tanto por la parte más compleja y con el equipo probablemente sin preparar. Sugería que la fecha de la campaña de la renta había comprometido el planteamiento inicial. En esta situación, las 4 prioridades para la fase 1 parecían ser: identificación de los servicios para TDT de Hacienda, montaje del equipo, plataforma de servicios TDT e identificación servicios para la fase 2. Esto es, una primera fase bastante completa. ASPECTO A MEJORAR: a futuro debe esclarecerse el objetivo del proyecto, su alcance y las condiciones. En cualquier caso, aún había muchas cosas por aclarar y concretar. Por esa razón, durante el mes de diciembre se sucedieron una serie de reuniones en los CES, el centro de operaciones de ese momento en adelante, de las cuales pueden extraerse las siguientes informaciones útiles: Limitaciones de la TDT:  Interfaz: se cuenta con un espacio muy reducido, además el aprovechamiento no es muy eficiente dado que debe ser visible desde el sofá. Así mismo, el tele-espectador no tiene porque ser un usuario habituado a las tecnologías, con lo que la navegación y uso de la aplicación debe ser lo más sencilla posible, guiando al tele-espectador en todos los pasos. A todo esto hay que añadir el bilingüismo propio de la Comunidad Foral de Navarra y la guía de estilos dewww.navarra.es con el fin de que se identifiquen los servicios con la marca del Gobierno de Navarra en la web.  Capacidad: tanto el ancho del banda del llamado carrusel (donde se emiten las aplicaciones) en torno a 2Mbits compartido, como la escasa capacidad de procesamiento y memoria del deco, obligan a tener mucho cuidado en el peso de la aplicación.  Existen varias implementaciones diferentes del estándar
  • 24. MHP en el mercado, pero la preponderantes son dos, Alticast y Osmosys, con lo que el comportamiento de las aplicaciones puede diferir de un deco a otro. Esto obliga a realizar pruebas exhaustivas en una amplia batería de decos comerciales.  La llamada interactividad en la TDT no viene de “serie”, sino que precisa de un canal de retorno a través de Internet por parte del deco bien por módem o bien por ADSL. Tratamiento de la información:  Se acuerda diseñar la aplicación de modo que la lógica esté desacoplada de la información de modo que esta sean fácilmente modificable en emisión sin afectar a la funcionalidad. Esta información, consumida por la aplicación, se presentará en forma de fichero XML, dada la estandarización de este formato.  Toda esta información se acuerda introducirla en la aplicación para su emisión de forma “manual”, sin llegar a integrarlo en el gestor de contenidos. Esto queda fuera del alcance.  Así mismo, el intercambio de datos entre los servicios sobre TDT y los sistemas de información del portal web se realizarán en base a servicios web. Aquí se quedó fuera del tintero que ocurría si no existían esos servicios web, quién debía desarrollarlos. Servicios a desarrollar:  Con información estática aún por determinar a modo de teletexto.  Con información dinámica (modificable en emisión) aún por determinar pero priorizando los más demandados en www.navarra.es. (Ej: meteorología, farmacias, boletín, carreteras, empleo, etc)  Interactivos: servicios de Hacienda para la campaña de la RENTA.  Portal o lanzadera: se precisa de un menú que de acceso a todos estos servicios del Gobierno de Navarra. Servicios Hacienda:  Los dos servicios que más interés podían tener porque habían funcionado a nivel nacional se descartaron: la “cita previa” era demasiado compleja y la “petición o aceptación de borrador” no existía en Navarra. Por esa razón todo apuntaba a los siguientes dos servicios: “Cuanto me sale a pagar o devolver” y “Cuando me devuelven”.  Estado del back-end: existen servicios web implementados y reutilizables por lo que tan solo faltaba
  • 25. recibir sus especificaciones (XML) para verificar su viabilidad e integración con TDT.  Funcionalidad: el usuario se identifica mediante un DNI y un PIN que le proporciona Hacienda.  Plazos: La campaña de la RENTA comenzaba la segunda quincena de Mayo, lo cual daba un poco más margen respecto al hito inicial de Abril. Organización:  Reuniones semanales de la dirección del proyecto: NGA, DGpSI; CES y el asesor técnico.  Existirá una reunión de arranque con el comité entorno a Enero-Febrero y otra coincidente con la campaña de la RENTA. El resto dependerá del Plan de Acción.  Debía definirse un plan de comunicación al comité para informar de los progresos, dificultades y decisiones pendientes que la dirección no podía tomar. Así mismo, debía detallar los entregables de cada fase, perfiles, tareas, fechas y riesgos. Las cosas empezaban a tomar forma pero aún había mucho por hacer. Por lo menos entonces teníamos claro lo que debía hacerse para seguir avanzando y concretando puntos. De entre todas esas tareas, puesto que el desarrollo para Hacienda (RENTA) era de lo más acuciante, tenía una absoluta prioridad. Había que comenzar por aquí, además era lo más tangible y sólido de todo el proyecto. No obstante, había otra serie de tareas también importantes que se pretendían acometer en paralelo:  Determinar el proceso de incorporación de las empresas: perfiles requeridos, selección, contrato y transferencia de conocimiento.  Selección de los servicios a implementar durante la segunda fase: reuniones con jefes de sección.  Definición de la metodología y herramientas de trabajo. Todo esto debería haberse contemplado dentro de un Plan de Acción, aún sin definir, que planificase todas las tareas antes de entrar en acción, para lo cual se hubiera necesitado recopilar algo de información previamente, no obstante, la premura de las cosas no lo permitió, todo iba sobre la marcha. La sensación era que había demasiadas cosas a realizar, mucha urgencia, pocos recursos y bastante indeterminación. Definición de la metodología y herramientas de trabajo Como cualquier otro proyecto de software había unas herramientas básicas necesarias: un gestor de proyectos, un sistema de control de versiones de código y una metodología.
  • 26. Puesto que aún no contaba con equipo para poner en marcha todo esto, debíamos salir adelante con lo que fuese. Casualmente, contábamos con una instalación de dotproject para la gestión del proyecto y en última estancia con un CVS para el control de versiones de código (posteriormente trabajaríamos con subversion). Esto era lo mínimo imprescindible con lo que empezar. En cuanto a la metodología, se decidió asumir la que el asesor técnico sugiriese en estos casos, lo cual también sería parte de esa transferencia tecnológica. Así pues parecía estar todo, pero me surgía una duda, ¿necesitamos algo más para desarrollar aplicaciones para TDT? La respuesta no estaba muy clara, así que se indagó y se elaboró un informe que contemplaba las necesidades hardware y software. Este informe se publicó en ediciones anteriores del boletín (TDT: herramientas para desarrollo MHP (Parte 1) y TDT: herramientas para desarrollo MHP (Parte 2)). En resumidas cuentas, había que hacer una fuerte inversión en un laboratorio de pruebas y en unas herramientas de desarrollo específicas para TDT. Las herramientas de desarrollo específicas para TDT aunque facilitaban el diseño y el desarrollo no eran estrictamente necesarias, y dado que se buscaba entre otras cosas una transferencia de conocimiento, se barajó no emplearlas. No obstante, esto habría incidido en el ritmo de trabajo y dadas las circunstancias no era factible. Esta decisión tomó largo tiempo en tomarse y unas cuantas conversaciones. Selección de los servicios a implementar durante la segunda fase: reuniones con jefes de sección Esta tarea requería sin lugar a dudas una intervención por parte de NGA y la DGpSI, por lo que, decidí delegar y depender de ellos en este punto y concentrarme en otras tareas que recaían directamente en los CES. Determinar el proceso de incorporación de las empresas: perfiles requeridos, selección, contrato y transferencia de conocimiento Junto con el análisis de los servicios de la RENTA, la formación del equipo parecía ser otra tarea muy urgente, debían estar preparados para el desarrollo de la RENTA lo antes posible. Esta responsabilidad recaía en los CES. Este fue el planteamiento tomado:
  • 27. Es decir, la búsqueda del becario comenzó en cuanto se supo de esta necesidad en el proyecto. No obstante, la selección de los profesionales exigía definir un perfil más específico, que debía establecerse según los requerimientos del proyecto. Este no pudo establecerse hasta finales del 2007 cuanto ya se tenía claro la experiencia y profesional buscado. En cualquier caso, se trató de un proceso contra-reloj, como se puede observar en la planificación, con el fin de que el equipo estuviera listo a finales de enero y el proyecto pudiera arrancar con la primera reunión del comité, teniendo aproximadamente un margen de un mes para recibir y seleccionar las candidaturas válidas. Para lo cual, se establecieron unas bases de participación en el proyecto que incluían el perfil establecido y que se distribuyó de diversas formas: prensa, mail electrónico y web. Cabe decir que algunos aspectos dieron lugar a ciertas confusiones, probablemente por no estar suficientemente claras en las bases: fue el caso, por ejemplo, del objetivo de estas bases, se buscaban empresas para participar en el desarrollo de un proyecto ya concedido, no para conceder el desarrollo del proyecto a un tercero, número de candidaturas por empresa, etc. En cualquier caso, tras la recepción de candidaturas se estableció un mecanismo por el cual se contrastaban con el
  • 28. perfil buscado, descartando aquellas que no lo cumplían. Una vez hecha esta criba quedaba decidir entre las que restaban, cuales participaban y cuáles no. Teníamos 3 candidatos válidos técnicamente, decantarnos por uno u otro hubiera sido partidista. Con el fin de ser neutral, se decidió sacarlo a suertes, aunque hubo cierto desacuerdo con este método. Finalmente no hubo necesidad, puesto que una de las candidaturas abandonó el proceso por fuerza mayor. Esto puso de manifiesto las carencias del sistema elegido que habría que pulir y corregir. ASPECTO A MEJORAR: a futuro, para evitar estas ambigüedades, definir ámbito de las bases, tabular las condiciones y emplear un proceso más objetivo. Con el comienzo del año 2007, volvimos a reunirnos para seguir atando cabos , retomar los trabajos y preparar la primera reunión del comité de Enero-Febrero. Las cosas no habían cambiado mucho. Todo se centraba en preparar la reunión del comité, que era la presentación del arranque del proyecto, y por tanto, los puntos en que había que trabajar:  Equipo de trabajo.  Plan de Acción.  Presupuesto inversiones para entorno de desarrollo y pruebas.  Estado servicios de la RENTA.  Portal (lanzadera).  Propuesta de servicios a implementar. Por tanto, seguíamos más o menos donde lo habíamos dejado. Las tareas del equipo de trabajo ya estaban lanzadas y se habían detectado así mismo, las necesidades para el entorno de desarrollo y pruebas, tan solo quedaba ponerles “números”. No obstante, los puntos más importantes que aún estaban abiertos y que eran claves: no habíamos avanzado en cuanto a la propuesta de servicios puesto que antes debíamos reunirnos con las personas indicadas en Gobierno de Navarra, tampoco estaba definido el Plan de Acción dentro del cual debían enmarcarse la propuesta de servicios, el análisis de los servicios de la RENTA, y la definición del portal (lanzadera). Así pues, el mes de enero resultó bastante “movido”, centrándonos en elaborar ese Plan de Acción y en recopilar información para poder llevarlo a acabo: análisis de los servicios de RENTA, definición de la Lanzadera y selección de los siguientes servicios.
  • 29. El caso es que, como se puede observar, dada la premura, la definición empezaba a diluirse con la primera fase de ejecución. No obstante, estas andaduras se comentarán en el próximo artículo. Cat CES OpenSouce/Java ego rías Tem Varios a Aut Raúl Sanz de Acedo or Mes Septiembre Año 2008 Bol 09 etín Título Configuración de Subversion Texto Tras haber escrito un artículo de introducción a Subversion y otro explicando su instalación, a continuación se explicará cómo configurarlo de tal forma que se pueda empezar a usar. La distribución de Subversion incluye un cliente remoto (svn), un servidor (svnserve), y varias utilidades. Se comenzará explicando cómo configurar el acceso a los repositorios a través de Apache. Para ello se supondrá que ya existe un repositorio creado y que se ha modificado httpd.conf para reflejar la configuración existente en la máquina antes de configurar el acceso a Subversion. Si no se ha creado ningún tipo de repositorio, se podrá crear mediante el uso de la herramienta svnadmin. La instrucción que se debería ejecutar sería: svnadmin create /ruta/al/repositorio/NombreRepositorio o si se quiere elegir el tipo de almacenamiento del mismo: # Para crear un repositorio basado en FSFS svnadmin create --fs-type fsfs /ruta/al/repositorio/NombreRepositorio
  • 30. # Para crear un repositorio basado en Berkeley-DB svnadmin create --fs-type bdb /ruta/al/repositorio/NombreRepositorio Una vez que se tienen perfectamente configurados apache y creados los repositorios necesarios, lo primero que httpd.conf debe hacer es cargar el módulo mod_dav_svn que se instaló. Para ello debe existir la línea: LoadModule dav_svn_module modules/mod_dav_svn.so y debe ir por debajo de: LoadModule dav_module modules/mod_dav.so si no, se producirá un error. Para dar acceso al repositorio se necesitará añadir al final del archivo httpd.conf o en un archivo .conf separado que esté situado en un directorio en el que el servidor sea capaz de encontrarlo y cargarlo. <Location /svnRepos> DAV svn SVNPath /ruta/absoluta/al/repositorio </Location> Esto dará un acceso sin restricciones al repositorio a cualquiera que acceda a http://URLServidorConSubversion/svnRepos. Para limitar el acceso de escritura o lectura, se deben añadir las siguientes líneas al bloque de Location: AuthType Basic AuthName "Subversion repository" AuthUserFile /ruta/a/archivo/de/contraseñas y además si:  El repositorio tiene restringido el acceso de
  • 31. lectura/escritura: Require valid-user  Para un repositorio con acceso de escritura limitado: <LimitExcept GET PROPFIND OPTIONS REPORT> Require valid-user </LimitExcept>  Para restringir de forma diferente el acceso a lectura y escritura: AuthGroupFile /my/svn/group/file <LimitExcept GET PROPFIND OPTIONS REPORT> Require group svn_committers </LimitExcept> <Limit GET PROPFIND OPTIONS REPORT> Require group svn_committers Require group svn_readers </Limit> Para crear el fichero de contraseñas se utilizará el comando de apache htpasswd. Lo que hace es con la opción –c crea un archivo con las contraseñas en la ruta especificada. Con la opción –m, usa encriptación MD5 en las contraseñas, que es más segura que la que usa por defecto. Así un ejemplo de cómo crear un archivo de contraseñas sería el siguiente: ### Primera vez: use -c para crear el archivo ### Use -m para usar encriptación MD5 de la contraseña, que es más segura htpasswd -cm /ruta/a/archivo/de/contraseñas harry New password: ***** Re-type new password: ***** Adding password for user harry ### Como el archivo ya está creado, no se vuelve a
  • 32. usar la opción -c htpasswd -m /ruta/a/archivo/de/contraseñas sally New password: ******* Re-type new password: ******* Adding password for user sally Si en vez de apuntar a un único repositorio se quiere apuntar a varios que están contenidos en un mismo directorio en vez de usar SVNPath, se puede emplear la instrucción SVNParentPath. Es decir: <Location /svnRepos> DAV svn SVNParentPath /ruta/absoluta/al/directorio/con/repositorios </Location> Esto dará un acceso sin restricciones a todos los repositorios incluidos en esa carpeta. Para acceder a ellos habrá que usar la siguiente URL:http://URLServidorConSubversion/svnRepos/NombreR epositorio. Apache también permite otras formas de autentificación como la de tipo Digest, que se basa en autentificar al usuario mediante una contraseña que en vez de enviarse sin encriptar, usa encriptación MD5. Para ello habría que emplear: <Location /dominioDeDigest > DAV svn SVNParentPath /ruta/absoluta/al/directorio/con/repositorios AuthType Digest AuthName "Subversion repository" AuthDigestDomain /dominioDeDigest/ AuthUserFile /ruta/a/archivo/de/contraseñas Require valid-user
  • 33. </Location> En este caso además habría que cargar el módulo mod_auth_digest y para crear los usuarios, en vez de emplear la utilidad htpasswd de apache habría que emplear la htdigest. El problema que puede existir es que es un módulo todavía experimental y que no se ha probado completamente, así que puede tener fallos. Para crear el archivo, entonces emplearíamos: ### Primera vez: use -c para crear el archivo htdigest -c /ruta/a/archivo/de/contraseñas /dominioDeDigest/ harry New password: ***** Re-type new password: ***** Adding password for user harry htdigest /ruta/a/archivo/de/contraseñas /dominioDeDigest/ sally New password: ******* Re-type new password: ******* Adding password for user sally Si se quiere tener un control más estricto de la comunicación se puede emplear conexiones seguras mediante SSL. Esto implica tener instalado OpenSSL para poder cargar el módulo correspondiente en apache y también tenerlo instalado en la máquina cliente. Habría que crear un certificado en el servidor y otro en el cliente. En este caso para acceder a Subversion se utilizaría: https://URLServidorConSubversion/svnRepos/No mbreRepositorio Otras opciones que permiten un control más fino en el repositorio se basan en el uso del módulo mod_dav_auth además del mod_dav_svn y el mod_dav necesarios anteriormente, un fichero de contraseñas y un fichero de grupos y/o usuarios. En este último fichero se especificará a qué partes del repositorio tiene acceso cada uno de los usuarios/grupos. Es decir, podrá haber partes de un repositorio a las que no podrá acceder nadie más que unas personas determinadas, otras en las que sólo se podrá leer y otras en las que se podrá leer y escribir. El problema que tiene este tipo de autentificación es que el repositorio
  • 34. tardará más en responder a las peticiones porque primero deberá comprobar si el usuario que la ha solicitado tiene permiso para hacerlo. Así, para tener acceso que exija autentificación la directiva Location debería tener este aspecto: <Location /svnRepos> DAV svn SVNParentPath /var/svn # our access control policy AuthzSVNAccessFile /path/to/access/file # only authenticated users may access the repository Require valid-user # how to authenticate a user AuthType Basic AuthName "Subversion repository" AuthUserFile /path/to/users/file </Location> Si se quiere tener una mezcla entre acceso anónimo y autentificado, entonces debería ser similar a: <Location /svnRepos> DAV svn SVNParentPath /var/svn # our access control policy AuthzSVNAccessFile /path/to/access/file # try anonymous access first, resort to real # authentication if necessary. Satisfy Any Require valid-user # how to authenticate a user
  • 35. AuthType Basic AuthName "Subversion repository" AuthUserFile /path/to/users/file </Location> El aspecto que debería tener el archivo que restringe el acceso a los directorios del repositorio (AuthzSVNAccessFile) debería ser: # Se indica que CN=Harold Hacker,OU=Engineers,DC=red-bean,DC=com es harry, para simplificar las cosas en el archivo. [aliases] harry = CN = Harold Hacker, OU = Engineers, DC = red-bean, DC = com #Se definen los grupos, como harry es un alias, debe ir precedido por & [groups] calc-developers = &harry, sally, joe paint-developers = frank, sally, jane everyone = &harry, sally, joe, frank, sally, jane # Con las siguientes 2 líneas se da acceso de lectura a cualquier usuario en todos los repositorios y en todas las carpetas, porque todos los repositorios lo cumplen. Si no se especifican restricciones por carpeta, entonces podrá leer en cualquiera de ellas cualquier usuario [/] *=r # En las siguientes líneas, se restringe el acceso al directorio branches/calc/bug-142 del repositorio calc. Se dan permisos de lectura y escritura a harry, a jane sólo de lectura, y se niega explícitamente el acceso de lectura y escritura a joe al no añadir nada tras el igual. [calc:/branches/calc/bug-142]
  • 36. &harry = rw sally = r joe = # Dentro de la carpeta projects/calc, del repositorio calc, el grupo calc-developers tendrá acceso de lectura y escritura, el resto de grupos o usuarios no tendrá ningún permiso por no estar indicados. [calc:/projects/calc] @calc-developers = rw # Dentro de la carpeta /projects/paint del repositorio paint jane, a pesar de pertenecer al grupo paint- developers sólo podrá leer porque es más restrictivo, y el grupo paint-developers (salvo jane) podrá escribir y leer. [paint:/projects/paint] jane = r @paint-developers = rw Este ejemplo ilustra varias cosas, desde el uso de grupos, de alias y el acceso a ciertas partes del repositorio. En principio, se tomará la regla más restrictiva por la carpeta que se solicite. Subversion también permite mostrar una lista de los repositorios que se encuentran en el directorio al que apunta la directiva SVNParentPath de los ficheros de configuración de Apache. En principio, esta opción permanece deshabilitada por motivos de seguridad. Si se quiere habilitar habría que añadir la siguiente línea a la directiva Location: SVNListParentPath on Esta opción no termina de funcionar correctamente. Para poder mostrar los repositorios y que funcione, lo que se debe hacer es además de añadirla dentro de la directiva Location, añadir un / al final del nombre al que apunta Location, de esta manera nos quedaría la directiva Location así: <Location /svnRepos/>
  • 37. DAV svn SVNParentPath /ruta/absoluta/al/directorio/con/repositorios SVNListParentPath on </Location> Se podrían añadir todas las opciones que fueran necesarias. Para ver la lista de repositorios que hay en el servidor, entonces se iría a:http://URLServidorConSubversion/svnRepos/ . Es muy importante añadir la última barra, porque si no, no los mostrará y dará un error. Si en vez de usar Apache como servidor de Subversion, se emplea „svnserve‟, entonces para invocarlo se puede hacer de diferentes formas:  En sistemas basados en UNIX como Linux, se puece hacer que svnserve corra como demonio escuchando las peticiones.  Hacer que el demonio inetd de Linux/UNIX/Solaris lance temporalmente svnserve cada vez que una petición llegue por un cierto puerto.  Hacer que SSH invoque un svnserve temporal sobre un túnel encriptado.  Ejecutar svnserve como un servicio de Microsoft Windows. Para lanzar svnserve como demonio, entonces habrá que ejecutar: svnserve –d Si además se quiere aumentar la seguridad, se puede pasar la opción –r seguida de una ruta, que restringirá los repositorios a los que se puede acceder a aquellos que estén en subdirectorios de la misma. Para que sea inetd el que invoque a svnserve, se debe lanzar svnserve con la opción –i, pero además habrá que comprobar que en el fichero /etc/services existan las entradas referidas a Subversion: svn 3690/tcp # Subversion
  • 38. svn 3690/udp # Subversion Además habría que añadir la siguiente línea al fichero inetd: svn stream tcp nowait svnowner /usr/bin/svnserve svnserve -i donde svnowner es un usuario que debe tener permisos de lectura y escritura sobre el repositorio, se puede cambiar a otro que los tenga. En el caso de que sea SSH el que invoque a svnserve, entonces lo hará con la opción –t. En el caso de querer ejecutarlo en Windows, entonces habrá que ejecutar una vez: sc create svn binpath= "C:directorioinstalacionSubversionbinsvnserve.ex e --service -r C:directoriorepositorio" displayname= "Subversion Server" depend= Tcpip start= auto Con esto se ejecutará cada vez que se lance Windows el servicio svnserve. No puede ejecutarse con opciones como –d, -t o –i porque entra en conflicto. Si se quiere modificar la forma de acceder al repositorio a través de svnserve, habrá que modificar el archivo svnserve.conf. En este se especificará el tipo de acceso que se deja, como se puede ver en los siguientes ejemplos: [general] password-db = ArchivoDeContraseñas realm = dominio_de_ejemplo # Los usuarios anónimos solo pueden leer el repositorio anon-access = read # Los usuarios autentificados pueden leer y escribir
  • 39. auth-access = write En este caso se ha permitido acceso de lectura a usuarios anónimos y de lectura y escritura a todos los usuarios, es como viene por defecto. En el siguiente el acceso será más conservador y sólo se permitirá que accedan si se autentifican. [general] password-db = ArchivoDeContraseñas realm = dominio_de_ejemplo # No se permiten usuarios anónimos anon-access = none # Los usuarios autentificados pueden leer y escribir auth-access = write El proceso servidor entiende no sólo estos controles de acceso al servidor si no también controles más finos definidos en archivos de acceso como el explicado en el caso de Apache como servidor de Subversion. Para ello se necesita un archivo con las reglas más detalladas y que la variable authz-db la señale. [general] password-db = ArchivoDeContraseñas realm = dominio_de_ejemplo # Reglas de acceso específicas para localizaciones específicas authz-db = ArchivoDeReglasDeAcceso Además, la opción authz-db, anon-access y auth-access no se excluyen por lo que si se incluyen las tres, sólo los usuarios que las cumplan podrán acceder al repositorio. Para hacer estas autentificaciones, svnserve trae por defecto implementado MD5, pero si durante la instalación de Subversion tanto en el lado del cliente como en el del servidor se instaló SASL, esto permitirá mayores opciones para la comunicación entre ambos. Para obtener más información sobre el tema, se pueden
  • 40. consultar la documentación siguiente: ENLACES DE INTERÉS: Subversion  http://en.wikipedia.org/wiki/Subversion_(software)  http://es.wikipedia.org/wiki/Subversion  http://subversion.tigris.org/  http://www.1x4x9.info/files/subversion/html/online- chunked/index.html  http://svn.collab.net/repos/svn/trunk/INSTALL  Version Control with Subversion, Ben Collins- Sussman, Brian W. Fitzpatrick, C. Michael Pilato. - > http://svnbook.red-bean.com/ Categorí CES OpenSouce/Java as Tema Varios Autor Blanca Cubas Mes Septiembre Año 2008 Boletín 09 Título Técnicas de mapeado de texturas. Parte 1 Texto Para la implementación de shaders que es en lo que me encuentro inmersa en este momento, y sobre lo que ya traté brevemente en un artículo anterior, es muy común la utilización de distintas técnicas de mapeado de texturas. Su ventaja es que, sin consumir muchos recursos gráficos, nos permiten obtener efectos complejos y bastante realistas de manera sencilla. Como introducción al tema, decir que un mapeado de textura sencillo consiste en indicar la correspondencia entre los vértices de un objeto 3D (x,y,z) y las coordenadas de una
  • 41. textura (u,v), tal y como se ve en la siguiente figura: Sin embargo, si queremos conseguir mayor nivel de realismo, tendríamos que utilizar otro tipo de técnicas más avanzadas. Algunas de las más utilizadas son las siguientes:   Bump Mapping.  Normal Mapping.  Displacement Mapping.  Parallax Mapping. Debido a la complejidad de las mismas, en este primer artículo nos vamos a centrar en las dos primeras técnicas. Ambas, tienen como objetivo dar aspecto de relieve a un objeto, a partir de una textura que modifica sus normales sin cambiar la geometría del mismo: es decir, modificamos la representación del “material” del objeto pero no su estructura 3D. La única diferencia que existe entre una técnica y otra es la textura de normales que utilizamos en cada caso. Bump Mapping NormalMapping Bump Mapping Las texturas que se emplean para realizar Bump Mapping son texturas en escala de grises que únicamente nos dan el valor de la altura. Los valores más próximos al negro se convierten en protuberancias y los más cercanos al blanco en hendiduras. Con ello lo que hacemos es “falsear” desplazamientos arriba y abajo de la verdadera superficie. Normal Mapping Las texturas que se emplean para realizar Normal Mapping
  • 42. son texturas RGB que a través de sus distintos canales, nos dan información sobre los ejes x, y, z. La componente azul, es la que más nos interesa en este caso, ya que es la que nos da la información sobre el relieve de la textura. La mejor forma de ver el resultado que tienen estas técnicas es a través de un ejemplo práctico. Para ello hemos implementado el siguiente código enNvidia FX Composer 2: //Lo primero que hacemos es definir las matrices de transformación y los parámetros a //utilizar por defecto. float4x4 WorldITXf : WorldInverseTranspose < string UIWidget="None"; >; float4x4 WvpXf : WorldViewProjection < string UIWidget="None"; >; float4x4 WorldXf : World < string UIWidget="None"; >; float4x4 ViewIXf : ViewInverse < string UIWidget="None"; >; float Timer : Time < string UIWidget = "none"; >; float4 lightPos = (1.0f,1.0f,1.0f,1.0f); //A continuación definimos las texturas que vamos a utilizar. La primera se trata de la //textura (u,v), que vamos a aplicar a nuestro objeto, en este caso, un plano. texture WallTexture < string ResourceName = "rockwall.jpg”; string UIName = "WallTexture"; string ResourceType = "2D"; >; sampler2D WallSampler = sampler_state { Texture = <WallTexture>; }; //Y la segunda se trata de la textura que se utiliza para almacenar la información de //las normales. texture NormalTexture < string ResourceName = "rockwall.tga"; string UIName = "Normal Map"; string ResourceType = "2D"; >;
  • 43. sampler2D NormalSampler = sampler_state { Texture = <NormalTexture>; }; //Vertex Shader // Necesitaremos la normal, binormal y tangente para poder situar la textura en el //espacio 3D, porque la función tex2D no tiene eso en cuenta. Para transformar los //vectores luz y posición se emplean la normal, binormal y tangente, que forman un //espacio de coordenadas propio (una matriz) que al multiplicarla nos dará los vectores //luz y posición en ese espacio de coordenadas. void mainVS(float4 Position : POSITION0, float3 Normal : NORMAL, float3 tangent : TANGENT, float3 binormal : BINORMAL, float2 TexCoord : TEXCOORD0, out float4 oPosition : POSITION0, out float2 oTexCoord : TEXCOORD0, out float2 oNormalCoord : TEXCOORD1, out float3 lightVec : TEXCOORD2, out float att : TEXCOORD3) { oPosition = mul(Position, WvpXf); // float4 posWorld = mul(Position, WorldXf); // Posición del vértice en el mundo 3D float3 light = normalize(lightPos - posWorld); //Obtenemos la luz en cada vértice float3x3 TBNMatrix = float3x3(tangent, binormal , Normal); lightVec = mul(TBNMatrix, light); att = 1/( 1 + ( 0.005 * distance(lightPos.xyz, posWorld) ) );//calculamos la atenuación de la luz oTexCoord = TexCoord; oNormalCoord = TexCoord; } //PixelShader // Tendremos que pasar los vectores luz y posición transformados al pixel shader que //los usará igual que hasta ahora para generar el
  • 44. componente difuso y especular. void mainPS (float4 oPosition : POSITION0, float2 oTexCoord : TEXCOORD0, float2 oNormalCoord : TEXCOORD, float3 lightVec : TEXCOORD2, float att : TEXCOORD3, out float4 oColor : COLOR) { float4 color = tex2D(WallSampler, oTexCoord); //Calculamos el color de la textura en cada punto //La normal se extrae del nuestra textura NormalTexture de la siguiente manera: float3 normal = 2.0f * tex2D(NormalSampler, oNormalCoord).rgb - 1.0f; float3 light = normalize(lightVec); //Normalizamos el valor de la luz float diffuse = saturate(dot(normal, light)); //Calculamos el color difuso oColor = att * color * diffuse; //Obtenemos el color final } //Y aplicamos la técnica deseada technique Main { pass p0 { VertexShader = compile vs_3_0 mainVS(); PixelShader = compile ps_3_0 mainPS(); } } La imagen de la izquierda se corresponde con un mapeado de textura básico, y la de la derecha aplica dicha textura junto con un Normal Mapping.
  • 45. Comentar como aspecto interesante, que las texturas de normales se puede crear con el plugin para Photoshop de NVidia, o con el programa CrazyBumpentre otros. Categorías CES Microsoft Tema Desarrollo Autor Goretti Ortigosa Rada Mes Septiembre Año 2008
  • 46. Boletín 09 Título Registro (Logging) en aplicaciones .NET Texto En la pasada edición de la NavarParty, que contó con una muy buena asistencia, tuve la oportunidad de asistir a una charla presentada por Iván Gonzalez, de PlainConcepts, que trató sobre el registro de eventos en aplicaciones .NET. Iván demostró ser no sólo un muy buen comunicador y un profesional con muchos conocimientos, sino además alguien que se esfuerza por ello como aquellos que conocen en periplo ferroviario que Iván realizó para venir a dar esa charla pueden atestiguar. Como sencillo reconocimiento aquí pongo una foto de Iván en acción: El tema de la charla me recordó que en alguna parte había visto algo al respecto y me acordé de un articulito breve de Scott Mitchell (MVP desde 2002, gurú de ASP.NET, creador de4gyusfromrolla.net… en definitiva, todo un IT) sobre un tema muy similar. En él se presentan un par de herramientas que vienen a cubrir
  • 47. lo presentado por Iván en cuanto a registro de eventos: - Enterprise Library 4.0: http://msdn.microsoft.com/en- us/library/cc512464.aspx - Log4net: http://logging.apache.org/log4net/index.html Ambas son herramientas OpenSource, siendo la segunda de ellas obra de la Apache Software Foundation como una versión de su log4j, la librería para registro de eventos en aplicaciones Java, mientras que la primera es creación del grupo de Microsoft “Patterns & Practices”. ¿Cuál es el beneficio de usar estas librerías? O más sencillamente, ¿por qué deberíamos molestarnos en usarlas? Estas librerías tienen como objetivo facilitar en registro de eventos en aplicaciones de escritorio hechas en .NET. Hoy en día los desarrollos de software disponen de una serie de herramientas, marcos de desarrollo (frameworks), librerías, etc. que permiten que las aplicaciones en general sirvan para el cometido para el que se han diseñado de manera aceptable. La calidad en el desarrollo de software sin embargo se encuentra ahora en otras áreas: zonas como el control de rendimiento y errores ocultos así como la trazabilidad de accesos y auditoría son elementos que hoy en día se demandan por parte de los compradores de software. Y es aquí donde el beneficio de este tipo de librerías se aprecia al máximo. Porque si bien anteriormente este registro de eventos se podía hacer de una manera artesanal y era aceptable (quién no recuerda pasar horas con el bloc de notas buscando mensajes específicos en ficheros planos de texto para poder explicar qué había pasado en un programa…) hoy nos encontramos con que la gran mayoría de fabricantes de software empresarial disponen en su catálogo de herramientas de control y monitorización de sistemas automatizadas (IBM, MS, Oracle…) que simplifican enormemente la vida a los administradores de sistemas y por tanto van a querer que nuestro software utilice cuanto antes. Y a nosotros como desarrolladores nos va a facilitar tareas como el traceado de nuestras aplicaciones, análisis de errores, mejoras en rendimientos, y otras como la distribución de aplicaciones (nos evitaremos errores por configuración errónea de los contenedores de estos registros), etc. La Enterprise Library es un conjunto de bloques de aplicación, que se definen como un conjunto de clases, cada uno diseñado para una tarea de desarrollo específica, como: - Registro - Acceso a datos - Gestión de excepciones - … El que nos interesa es el Bloque de Aplicación de Registro (Logging Application
  • 48. Block) que nos facilitará este registro de eventos. Antes de utilizarlo, deberemos configurarlo e indicar qué monitores de traza (trace listeners) vamos a emplear. Un monitor de traza es el objeto que se encargará de recoger la información que nos interesa y escribirla en un almacén de registro específico. La Enterprise Library tiene varios monitores predefinidos que pueden escribir la información en el Registro de Sucesos de Windows (Event Log), en una base de datos, en un fichero de texto, un mensaje de email, etc. También se nos permite crear nosotros mismos otros monitores para escribir en otras fuentes. La configuración del Bloque de Aplicación de Registro también incluye categorías, filtros y formato de los registros. Las categorías nos permiten la clasificación de los registros, por ejemplo: “Errores de acceso a datos” o “Mensajes de Debug”. Cada registro pertenecerá a una categoría, y tendrá también una serie de propiedades como prioridad o severidad. Mediante el uso de diversos filtros basados en las categorías y propiedades de los mensajes de registro podremos ajustar el comportamiento del registro de eventos en distintos entornos: por ejemplo, en un entorno de pruebas podemos interesarnos por todos los mensajes de prioridad 5 o más, o bien en un entorno de producción podemos querer omitir todos los mensajes de la categoría “Mensajes de Debug”. Por último, el formato de los registros nos permitirá definir el formato que usaremos para almacenar la información en los mensajes.
  • 49. Una vez hecho esto, tendremos que hacer uso en nuestros desarrollos de la API del bloque de aplicación de Registro de manera que creemos eventos en nuestros programas. Esto será tan sencillo como por ejemplo crear un objeto de tipo LogEntry en la parte Catch de una excepción, recoger en este objeto los detalles de la excepción mediante sus propiedades y finalmente registrar el evento mediante una llamada al método Write de la clase que representa el motor de registro enviándole como parámetro el objeto LogEntry. Esto generará que el Bloque de Aplicación de Registro evalúe la entrada contra los filtros definidos previamente y las categorías, determine si debe almacenarse y en caso positivo le aplique el formato adecuado antes de registrarlo. Por ejemplo, en el blog de Tercer Planeta nos mostraban el siguiente código (sobre la versión 3.0 de la Enterprise Library, pero vale igualmente para 4.0) public void EjecutarTarea(Tarea tarea) { try {
  • 50. Logger.Write("Preparando la tarea " + tarea.Descripcion); tarea.Preparar(); Logger.Write("Ejecutando la tarea " + tarea.Descripcion); tarea.Ejecutar(); Logger.Write(string.Format("Resultado de la Tarea (0): {1}", tarea.Nombre, tarea.InfoResultado)); } catch (Exception ex) { Exception outEx; if (ExecutionPolicy.HandleException(ex, "TareasP olicy", out outEx)) throw outEx ?? ex; } finally { Logger.Write(tarea.Descripcion + " Finalizada"); } } Por su parte log4net emplea una aproximación similar (algunos elementos cambian de nombre, como los “appenders” en vez de los monitores de traza, o los “layouts” en vez de las reglas de formato) y proporciona los mismos resultados. Por defecto incluye más posibles destinos para el registro, como fuentes de datos ADO.NET, la traza ASP.NET, la ventana de consola, un buffer en memoria, etc. Lo que sí aporta log4net es la posibilidad de emplear una jerarquía de registros, de manera que se puede definir niveles para los registros (por ejemplo DEBUG, INFO, WARN y FATAL) que permiten clasificar de manera simple los niveles de los registros que se crean y que pueden usarse para establecer que un determinado appender responda sólo a los mensajes de un nivel concreto. En definitiva, dos librerías que merece la pena considerar si hemos decidido dar
  • 51. dos cosas: - Dotar a nuestras aplicaciones de calidad en todos sus extremos. - Sufrir menos en nuestro trabajo, usando herramientas que nos simplifiquen tareas y sobre todo que nos permitan apagar fuegos más rápido. Categor CES Microsoft ías Tema Desarrollo Autor Rafael Flores Yoldi Mes Septiembre Año 2008 Boletín 09