Media Net Software KIT Blog

Durante nuestra estancia en Amberes tuve la oportunidad de asistir a una conferencia sobre seguridad web. La conferencia la ofrecía un miembro del destacado del OWASP. Me pareció interesante el trabajo de esta organización y voy a emplear el presente post para hablaros sobre la misma.

¿Qué es el OWASP?

El proyecto abierto de seguridad en aplicaciones Web (OWASP por sus siglas en inglés) es una comunidad abierta y libre de nivel mundial enfocada en mejorar la seguridad en las aplicaciones de software. Nuestra misión es hacer la seguridad en aplicaciones “visible”, de manera que las organizaciones puedan hacer decisiones informadas sobre los riesgos en la seguridad de aplicaciones. Todo mundo es libre de participar en OWASP y en todos los materiales disponibles bajo una licencia de software libre y abierto. La fundación OWASP es una organización sin ánimo de lucro.

¿Qué puede aportarnos?

El OWASP ofrece dos tipos de aportaciones: proyectos de documentación y proyectos de desarrollo. La documentación está escrita en un lenguaje muy didáctico, pero es a su vez completa. Puede ser interesante como punto de entrada a proyectos cuya componente principal es la seguridad.

¿Qué proyectos de documentación existen?

La documentación es tanto escrita como audiovisual. Los recursos disponibles son los siguientes:

Guía de proceso:

Es una guía que describe una serie de “actividades empaquetadas” orientadas a roles, con el objeto de que el usuario sea capaz de introducirlas dentro de su proceso de desarrollo de software. Es descargable desde aquí.

Vulnerabilidades top 10:

Este proyecto ofrece información acerca de las 10 principales vulnerabilidades existentes en cada momento. Dispone de dos interesantes guías:

• La guía top 10: Explica cada una de las vulnerabilidades más detectadas en aplicaciones web, y ofrece numerosos links sitios web con información. Es descargable de aquí.
• La guía top 10 JavaEE: Esta guía ofrece información aplicada a JavaEE. Es descargable desde aquí.

Screencasts:

Anualmente el OWASP realiza una conferencia en estados unidos, de una semana de duración. Las conferencias son descargables desde aquí.

Guías tecnológicas:

Existen tres guías tecnológicas diferentes:

• Guía de desarrollo: La guía de desarrollo va orientada a arquitectos, desarrolladores, consultores y auditores. Se centra en el diseño, desarrollo y despliegue seguro de aplicaciones. Existen en este momento una guía estable (2.0.1), y una guía en elaboración (3.0). Ambas están disponibles aquí, aunque la 3.0 no es descargable en formato pdf.
• Guía de revisión: Es una guía orientada a aquellos cuyo trabajo es revisar en código fuente en busca de problemas de seguridad. Es descargable desde aquí.
• Guía de testing: Es una guía orientada a testers. Tiene una serie de escenarios y casos de prueba recomendables. Descargable desde aquí.

Guía legal:

Esta guía ofrece ayuda para elaborar contratos vinculados a productos de software en los que la seguridad sea un pilar importante. Ofrece un anexo de ejemplo a agregar a los contratos. Es descargable desde aquí.

¿Qué proyectos de desarrollo existen?

Proyecto Web Goat: http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project

Es un proyecto orientado a ofrecer un entorno en el cual se puedan poner en práctica vulnerabilidades y prácticas de seguridad sin problemas legales.

Proyecto Web Scarab: http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project

Es una aplicación que se pone como proxy entre el navegador y los servidores http, y sirve para monitorizar, modificar y estudiar técnicas de seguridad sobre protocolo http.

Proyecto DotNet: http://www.owasp.org/index.php/Category:OWASP_.NET_Project

Este proyecto contiene contenido relacionado con el aseguramiento de aplicaciones y servicios sobre tecnología DotNet.

Proyecto Java: http://www.owasp.org/index.php/Category:OWASP_Java_Project

Este proyecto contiene contenido relacionado con el aseguramiento de aplicaciones y servicios sobre tecnología Java.

Otros proyectos: http://www.owasp.org/index.php/Category:OWASP_Project

Una de las ponencias de hoy ha tratado sobre OSGI. OSGI es un estándar de componentes dinámicos que pretende solucionar algunos de los problemas que presentan las aplicaciones JAVA cuando el número de librerías implicadas en las mismas y de dependencias entre estas es elevado (cuando digo elevado hablo de 50 o más librerías). La ponencia ha sido expuesta por Peter Kriens, artífice de este estándar. He de decir que ha sido de las mejores que he visto ya no solo por la claridad de la exposición, sino porque el pobre hombre se ha presentado incluso estando medio afónico.

Peter nos contó como todo parte del boom de Internet de finales de los 90. Por esas fechas Peter estuvo involucrado en un proyecto cuyo objetivo era hacer llegar a todos los hogares un ordenador que permitiera controlar vía Internet prácticamente todos los electrodomésticos y artilugios que nos rodean cotidianamente. Para ello su equipo creó un pequeño sistema empotrado con java integrado cuya misión era servir de servidor en esta infraestructura. Por aquellas épocas se pensaba que Internet iba a revolucionar el modo de vida de las personas incluso más de lo que lo ha hecho a día de hoy. Este sistema tenía que funcionar con gran diversidad de dispositivos diferentes que los diferentes fabricantes ofrecerían al mercado.

La heterogeneidad de los distintos dispositivos a integrar dio lugar a una serie de problemas:

• Se hacía tedioso y complejo mantener el classpath de las aplicaciones cuando el número de librerías era elevado. Un claro ejemplo es el de mantener un classpath con 500 librerías, las cuales a su vez dependen de librerías cuya única diferencia es la versión (y el nombre es el mismo).
• Dependencias demasiado mayadas. Esto es comprensible cuando las librerías de cada dispositivo son implementadas por distintos fabricantes siguiendo patrones de dependencia completamente heterogéneos. El modelo de paquetes de java no ayuda a esto ya que está concebido para dar una estructura lógica-funcional a las clases, y no para estructurar una aplicación en base a componentes.
• Necesidad de que la carga, descarga, puesta en funcionamiento y parada de los elementos que constituían una aplicación fuera dinámica. El funcionamiento de los ClassLoaders es completamente estático. Esto no era raro teniendo en cuenta que en aquella época Windows 98 era el último grito en sistemas operativos: un sistema operativo que te obligaba a reiniciar hasta cuando movías el ratón.

En base a estas necesidades se conciben los primeros modelos de aplicaciones orientadas a servicios, y en particular el estándar OSGI, cuya primera versión se publica allá por el 2000. $$$

El estándar OSGI plantea un modelo como el de la figura.

Los puntos más importantes a considerar son:

• Se plantea la creación de Bundles. Estos Bundles ofrecen una serie de servicios y engloban todas las librerías jar que estos últimos necesitan.

• Estos Bundles presentan una interfaz, y ocultan el resto de las librerías a ojos de otros Bundles. De esta manera no existe dependencia entre unos Bundles y otros más que a través de las interfaces públicas de los mismos. La determinación de qué librerías y que clases son públicas, y cuales son privadas, se especifica en un archivo de metadatos.

• La seguridad forma parte del modelo desde el comienzo. Toda operación de acceso a los servicios de un Bundle está asegurada por diseño.
• Los servicios son completamente dinámicos. Si un servicio cae el estándar contempla una parada ordenada de los otros servicios que dependen del mismo. También contempla una recuperación ordenada de los mismos. De este modo la caídas de conexión, desconexiones por falta de batería, etc; están contempladas.
• Un Bundle antes de arrancar diagnostica si el entorno en que se encuentra va a permitir su funcionamiento de manera clara, evitando de este modo problemas en tiempo de ejecución. Además diagnostica de manera muy clara los motivos al usuario para que pueda resolverlo.
• La carga de clases es más rápida porque OSGI implementa ClassLoaders especiales que únicamente buscan clases en la interfaz pública de los Bundles.

Si queréis saber más de este tema en la página de OSGI encontrareis más.

Hola a todos:

Como algunos de vosotros ya sabréis, Media Net ha decidido plantar una pica en Flandes (más bien dos) y enviarnos a Ángel Rey y a mí al Devoxx (anteriormente llamado Javapolis). Después de dos conferencias matutinas aprovecho un receso para comenzar a escribir este artículo.

Este no trata sobre nada del Devoxx: para esto ya habrá otros artículos. Este artículo trata sobre Mercurial: una herramienta de control de versiones. Esta herramienta la estamos implantando ahora mismo en el proyecto que estoy trabajando (desarrollo de calculadoras de productos financieros en tiempo real). En este artículo os describo el escenario que nos ha llevado a utilizarlo, y cuáles son nuestras impresiones después de probarlo. La explicación la realizo en modo FAQ.

¿Que es Mercurial?

Mercurial es un sistema de control de versiones que cuenta con las siguientes características:

• Es transaccional: Cada cambio sobre el repositorio se ejecuta atómicamente para todos los elementos implicados en el mismo; sean archivos, directorios y/o metadatos.
• Es un sistema distribuido: El histórico de los archivos gestionados no se encuentra en un único servidor centralizado al que los desarrolladores suben sus cambios. Cuando un desarrollador descarga los archivos de un proyecto de Mercurial, éste descarga además una copia completa del histórico de cambios. De esta manera el desarrollador es capaz de reproducir el estado de la aplicación en cualquier momento de su historia sin necesidad de conectarse a un repositorio centralizado.
• Desarrollado en python y algo de C.
• Funciona tanto en modo Push como en modo Pull; dando flexibilidad a las políticas de versionado a aplicar.

¿Por qué nos hemos decidido a utilizarlo?

Los motivos son los siguientes:

• El modelo de versionamiento de CVS no nos convencía. Hemos tenido bastantes problemas de inconsistencia cuando hemos querido descargar versiones anteriores de nuestro software desde el repositorio de CVS. Por otro lado, los desarrolladores de mi equipo se liaban mucho cuando bajaban una versión antigua de un archivo debido a que si posteriormente hacían un commit sobre una de las carpetas que contenía estos archivos, CVS creaba una nueva rama para estos de manera no transparente. En muchas ocasiones nos vimos en la necesidad de corregir estos problemas. En Mercurial la creación de una nueva rama (branch) forma parte del día a día. Toda descarga de fuentes es en realidad una nueva rama. Esto ha obligado a los desarrolladores de Mercurial a que la gestión de ramas sea muy eficiente.
• Los problemas que hemos tenido con CVS al resolver colisiones. En ocasiones han desaparecido cambios muy costosos de recuperar. De su desaparición nos enteramos solo después de ver que nuestras pruebas unitarias fallaban de manera estrepitosa durante la integración. Mercurial es muy conservador para esto: no se mete a resolver colisiones de manera automática, sino que deja esta responsabilidad siempre en manos del desarrollador.
• La posibilidad de clonar directorios de manera tan sencilla nos facilita realizar copias de seguridad con más frecuencia. Sacar una copia de seguridad del CVS era un suplicio; sobre todo teniendo en cuenta que la copia se realizaba para todos los proyectos del repositorio incluidos los de los proyectos con los cuales compartíamos el repositorio. En Mercurial clonar un repositorio es tan fácil como copiar archivos, y además toda clonación lleva asociado su histórico de cambios.
• CVS no es transaccional. Dado que la máquina en la que está ubicado tiene problemas de estabilidad nos ha ocurrido varias veces que una subida de cambios se ha aceptado solo parcialmente. Mercurial es completamente transaccional.
• Necesitábamos una herramienta cuyos requisitos de instalación a nivel de permisos de administración fueran los mínimos posibles. En nuestro proyecto actual el entorno de desarrollo que nos ha facilitado el cliente no es tal entorno “de desarrollo”, ya que ni lo controlamos nosotros, ni es un entorno aislado (hay como 30 aplicaciones haciendo pruebas sobre la misma máquina).
• No tenemos posibilidad de realizar pruebas de usuario en nuestros entornos de trabajo antes de subir los cambios a un repositorio porque nuestra aplicación se conecta con sistemas externos a través de APIs que solo están instaladas en el entorno de integración. Además algunas de las librerías utilizadas solo funcionan sobre Unix, mientras que nuestros entornos de trabajo son Windows.
• Los mercados de tiempo real tienen unas condiciones de trabajo que son continuamente monitorizadas por los operadores de los mismos. Una incidencia puede dar lugar a multas millonarias. Es fundamental que podamos reproducir cualquier versión de manera rápida para corregir cualquier error. Por otro lado necesitamos la facilidad de poder agregar o quitar funcionalidad hasta pocos días antes de publicar una versión. Mercurial permite reproducir cualquier versión del histórico a partir de cualquier clon de cualquier rama de cualquier entorno, incluido el de los desarrolladores, con lo cual es muy fácil reproducir incidencias de manera rápida. También permite agregar cambios de distintas ramas de desarrollo de manera sencilla e individual.
• La aplicación es altamente concurrente, paralela, multi-hilo, y calcula productos financieros en base a modelos complejos. Es ventajosa la capacidad que da Mercurial al responsable de una rama estable. No son los desarrolladores quienes suben los cambios a la rama estable (modelo push), sino que es el responsable de esta rama quien va demandando los cambios a las ramas de los desarrolladores (modelo pull). Esto permite probar las aplicaciones en ramas de prueba, y posteriormente integrar los cambios individuales solo cuando ya han sido probados y revisados.
• Uno de los problemas que veíamos al uso de Mercurial era la integración con eclipse. Clonar repositorios nos obliga a clonar los proyectos y el workspace de eclipse para poder trabajar. Por suerte existe un plugin (Merclipse) que realiza esta tarea.

¿Cómo funciona el control de versiones?

Cuando un desarrollador descarga un proyecto del control de versiones, en realidad lo que está haciendo es clonar el repositorio de origen. No existen diferencias entre ambos repositorios después de la operación. Haciendo un símil con subversión, es como si cada desarrollador tuviera un servidor de subversión instalado en su equipo. Este “servidor” contiene toda la información histórica del proyecto.

Al clonar el repositorio se crean dos espacios:

• Repositorio público: Contiene el histórico de cambios. Es visible desde otros repositorios.
• Espacio de trabajo: Se genera a partir del histórico. El desarrollador solicita un “update” de una versión determinada, y Mercurial actualiza el espacio de trabajo para que contenga los fuentes de dicha versión.

A la hora de trabajar, un desarrollador realiza los cambios sobre su espacio de trabajo. Cuando quiere poner los cambios a disposición de los demás, este los sube al repositorio público mediante el comando “commit”. Desde este momento los cambios están visibles desde otros repositorios. Hasta aquí el modelo de trabajo es similar al de un control de versiones centralizado con la diferencia de que el servidor es propio de cada rama.

Cuando llega el momento de sincronizar dos repositorios distintos Mercurial ofrece dos comandos: “push” y “pull”. Push se emplea cuando se desea transferir cambios desde un repositorio a otro, y Pull se emplea cuando se desea tomar desde un repositorio los cambios de otro repositorio. Este segundo modelo es más seguro porque permite que un responsable determine qué es lo que le interesa que su rama contenga.

Con estas herramientas un desarrollador tiene capacidad de clonar un repositorio estable, y a su vez clonar esta rama de nuevo para implementar cada nueva funcionalidad por separado. De este modo pueden probarse e integrarse las funcionalidades de modo independiente.

En el caso de nuestro proyecto actual las ramas existentes son las siguientes:

• Rama estable: Es la rama desde la que se generan las versiones publicables. Ubicada en la máquina de integración. Está bajo control del responsable de proyecto y solo toma cambios desde las ramas de desarrollo.
• Ramas de desarrollo: Cada desarrollador tiene una rama en la máquina de integración para subir y probar sus cambios. Esta rama se clona desde la rama estable al comienzo de cada iteración. Una vez probados, estos cambios se revisan para asegurar que se están cumpliendo las especificaciones de desarrollo y las buenas prácticas establecidas. Hecho esto el responsable de proyecto realiza un pull e importa los cambios sobre la rama estable.
• Ramas locales: Cada desarrollador tiene una rama local principal que se clona a partir de su rama de desarrollo al comienzo de cada iteración. El desarrollador puede clonar tantas ramas a partir de esta como estime oportuno. Idealmente una por funcionalidad.

¿En que se diferencia de subversion?

Subversion es un sistema que nos gusta, pero no respondía a nuestras necesidades porque:

• Únicamente se puede tener un repositorio central. No nos resuelve la papeleta de tener varias ramas en el entorno de desarrollo.
• El esquema de versionamiento y el sistema de ramificación es mucho menos flexible. Nos permite realizar menos adaptaciones. Con Mercurial las políticas de ramificación, mezclado y subida de cambios son un mero evento social.
• No es capaz de funcionar en modo pull. Solo admite modo push, y nos ha gustado mucho el control sobre los cambios que nos da este esquema de funcionamiento.

Está muy chulo todo esto, ¿pero donde está la pega?

Las pegas que yo veo son las siguientes:

• Requiere por parte de los desarrolladores un cambio de mentalidad a la hora de trabajar con el control de versiones.
• Al ser muy flexible permite hacer muchas cosas bien, pero también muchas cosas mal. Obliga a ser muy disciplinado. Un símil a lo que pasa con C++ y JAVA.
• Las herramientas de usuario aún no están tan maduras como pueden estar las de subversión, CVS, u otros controles más populares. Sin embargo la línea de comando se la han currado mucho y es muy sencilla, muy coherente, y muy intuitiva.

¿De dónde puedo descargarlo?

Podéis descargarlo desde http://www.selenic.com/mercurial/wiki/. En este sitio Web hay manuales (muy buenos), ejecutables, código fuente y guías de ayuda rápida.
El plugin de Merclipse lo podéis descargar de http://www.goldenhammers.com/merclipse/.
¿Tengo que hacer algo en especial para instalarlo?
Nada. Se instala mediante un instalador. Instalar y ejecutar.

En el proyecto actual -una aplicación web JEE / jdk1.5 construida fundamentalmente con portlets, jsf(myfaces, tomahawk) y ejb3 que se despliega sobre JBoss Portal Server- en el que estamos colaborando nos hemos encontrado con un problema, que aunque puede que habitual en algunas ocasiones, nos está afectando en nuestras tareas de desarrollo y despliegue.

Concretamente, el problema es el tiempo que requieren las tareas de compilación, generación del archivo de despliegue (actualmente ocupa 120 megas) y el propio arranque del servidor de aplicaciones. Después de algunas “optimizaciones”, dichas tareas nos pueden llevar de 3 a 5 minutos, así que os podéis imaginar lo frustante que puede ser cuando, después de invertir ese tiempo, tratas de testear los últimos cambios que has realizado y te encuentras con un error tonto como que olvidaste negar la condición pusiste en un if o algo así… y tienes que volver a repetir todo el ciclo…

Tratando de solucionar este problema, probamos el Hotswapping (recarga de “clases” en caliente, es decir, sin necesidad de reinicar el servidor) nativo que ofrece el jdk pero, por desgracia, no conseguimos hacerlo funcionar correctamente (no tengo muy claro donde estaba el problema si en los frameworks o en el servidor de aplicaciones…) así que le dimos otra vuelta más por google y encontramos un JavaRebel:producto de pago :(, con versión de evaluación de 30 días y licencias gratuitas para desarrollos open source, que la verdad funciona bastante bien… En nuestro caso concreto pasamos de tener que construir todo el proyecto y desplegarlo (unos 3-5 minutos) a simplemente compilar las clases modificadas (10-15 segundos).

Básicamente, lo que ofrece JavaRebel es la modificación “casi completa” del bytecode “on the fly”. Aquí podéis ver una comparación con la fucionalidad ofrecida por JavaRebel frente a la ofrecida por los jdk’s actuales.

Bueno, y que hay que hacer para utilizarlo? Pues simplemente hay que descargarse el jar de JavaRebel y luego incluir -javaagent:/path/to/javarebel.jar en el arranque. (El tema de javaagent da al menos para otro post, pero básicamente es un “interceptor” del proceso de carga de clases, que permite monitorizar dicho proceso de carga y modificar el bytecode que se va a ejecutar… Esta funcionalidad es utilizada por algunas herramientas de profiling o frameworks de Programación Orientada a Aspectos)

En la propia página del producto podéis encontrar un flash que describe bastante bien nuestra situación inicial y también hay una demo real de como funciona esto…

Una de las cosas no tan buenas, además del problemita de ser de pago, es que no es posible depurar desde Netbeans (tienen identificado el bug pero de momento no han previsto cuando liberarán esa versión…) En cuanto a otros IDEs funciona correctamente para Eclipse y para IDEA IntelliJ.

JUnit es, a día de hoy, el método más extendido de realizar pruebas unitarias sobre las funciones de nuestro desarrollo. Pero desde luego, no es infalible. Completar con éxito el 100% de las pruebas unitarias solo significa que la aplicación funciona para los supuestos lanzados en las pruebas. Es decir, nuestro código funciona con A+B+C, ¿pero funcionaría para A+C+B?, ¿como podemos saber qué parte del código se prueba con los test que hemos lanzado?

Para poder contestar esta última pregunta podemos usar Cobertura. Un desarrollo opensource con licencia GNU General Public License, Version 2.0.

Cobertura instrumentaliza nuestras clases java. Introduce nuevas instrucciones dentro de las clases compiladas de nuestro proyecto que utiliza para obtener un informe muy completo sobre lo que ha ocurrido en esas pruebas.

Podemos introducir Cobertura en nuestro proyecto empleando las propias tareas de Cobertura para Ant. Dentro del fichero del proyecto Ant (típicamente build.xml) introduciremos la siguiente línea:

taskdef classpath="cobertura.jar" resource="tasks.properties"


Esto será suficiente para comenzar a utilizar los objetivos de Cobertura.

Una vez lanzados los test los resultados se almacenarán en el fichero “cobertura.ser”.
Este fichero lo podremos formatear como un HTML al estilo javadoc o como un XML que nos servirá para procesar y presentar los resultados con nuestra propia herramienta.

Por ejemplo, el resultado de los test para la propia librería de cobertura los podemos ver en la siguiente imagen

De la misma manera que en un javadoc podremos navegar por los diferentes niveles de la librería y comprobar cuantas lineas de código han sido probadas. Además muestra el indice de complejidad de la clase y el porcentaje de ramificaciones del código probadas

Si pinchamos sobre cualquier clase nos mostrará el código asociado con el número de veces que nuestros test han pasado por cada línea de código. Esto es especialmente útil para comprobar de un vistazo si hemos entrado por todas las ramificaciones de nuestros if-then-else o cuantas veces se ha pasado por un determinado bucle.

En la web de Cobertura se pueden descargar las últimas versiones y gran cantidad de documentación (Getting Started, FAQs, samples…)

Después de un largo tiempo ya están concluidas las especificaciones para USB 3.0, tecnología que hará posible copiar un fichero de 25 GB en solo 70 segundos.

¿Cómo es de rápida? 4.8 Gbps para ser exactos. Esto significa que es posible copiar un fichero de 25 GB en 70 segundos, por lo menos en la teoría. Hay otros factores que inciden en la rapidez de transmisión, como por ejemplo la velocidad del disco duro y el desempeño general del sistema.

El nuevo estándar no sólo es más veloz, sino también optimiza el consumo eléctrico, de manera que el usuario no tiene que esperar que dispositivos como teléfonos móviles o reproductores mp3 estén totalmente cargados para que puedan interactuar con el PC.

Los primeros productos con soporte para USB.3 comenzarán a comercializarse hacia finales de 2009, pero 2010 será sin duda alguna el año en que la tecnología se generalice.

Una de las cosas más importantes y obvias cuando escribimos un programa es preparar un buen control de errores. Esto que al principio parece algo fácil, sencillo y encapsulable, al final terminamos haciéndolo siempre de una manera diferente, ya que poco a poco se va complicando porque:
- controlamos la excepción y devolvemos un código de error, o si simplemente la propagamos
- qué herramienta/librería utilizamos para generar la información de log
- qué nivel de log vamos a mantener
- cómo vamos a informar del error
- …

Pero siempre hay algo que solemos olvidar, y es que, tan importante como la detección del error, es el registro del contexto en el que se estaba ejecutando el programa cuando falló, es decir, con qué datos estaba operando.
Este conjunto de datos, está claro que es variable en cada caso, con lo que pasárselo a un método genérico que registre el error suele ser algo lioso, a no ser que empleemos un método que acepte un número variable de argumentos no determinado inicialmente. Esta es una característica que antiguamente el C era uno de los pocos lenguajes que la soportaba, pero que es común en los lenguajes modernos (.NET, Java…), así en Java podríamos tener algo por el estilo:


public String generarCadenaParaLog(Object...args)
{
    StringBuilder logString = new StringBuilder();
    for(Object argTemp: args)
    {
        logString.append(argTemp);
    }
    return logString.toString();
}


Para llamarlo por ejemplo del siguiente modo:
...

...

  En un reciente proyecto me he encontrado con una situación no demasiado común: necesitábamos imprimir los documentos de Word desde un servicio sin interfaz de usuario. A los ya consabidos problemas de trabajar con documentos de Office en servidor (pero eso ya es otra historia….) se le añadía la dificultad de las pruebas en los entornos intermedios (en nuestro caso: desarrollo, integración y pre-producción), una vez verificado el resultado de la impresión.

  Primeramente intenté configurar uno de los múltiples drivers de impresión existentes en el mercado que acaban generando un documento en formato PDF y/o XPS. El problema era que todos ellos requerían de la interacción del usuario para seleccionar la ubicación del fichero a generar.

  La opción de implementar un mecanismo, que mediante configuración habilitara/deshabilitara la impresión de los documentos, la descarté porque podía acabar ocultando problemas en los entornos.

  La solución implementada consiste en la definición de una IMPRESORA NULA. Esto consiste en definir un nueva impresora local, asignándole un puerto nuevo local con valor “NUL:” En el siguiente paso de seleccionar el modelo podemos elegir cualquiera, puesto que los datos imprimidos se DESCARTAN DIRECTAMENTE. Para finalizar basta con asignarle un nombre significativo “Void Printer”, o “Impresora Pozo Negro” y configurarla en nuestro servicio en el modo adecuado

  De este modo habremos conseguido, sin alterar en lo más mínimo el comportamiento de la aplicación, trabajar con la aplicación evitando talar árboles de manera innecesaria.

  Os dejo unos pantallazos de la configuración de la impresora en mi máqiuna (Windows Vista). Por cierto, esto está probado en Windows Vista y Windows 2003 Server.

En el proyecto actual nos hemos encontrado con la problemática de realizar construcciones automáticas de TFS con un proyecto de tipo “Office AddIn”. Este tipo de proyectos utilizan ClickOnce para el despliegue, lo cual implica firmar el manifest. Aunque esto es algo que podemos obviar cuando estamos trabajando en nuestra máquina, puesto que Visual Studio nos genera de manera automática un certificado con funcionalidad “Code Signing”, provoca errores de construcción en el servidor de integración

• C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(1805,7): error MSB3323: Unable to find manifest signing certificate in the certificate store.

Para resolver esto, basta con seguir estos pasos:

1. Copiar el certificado utilizado para la firma, ya sea el generado por VS o uno de nuestra propia cosecha, a una carpeta del servidor de compilación
2. Iniciar sesión con el usuario que ejecuta el servicio TFS Build
3. Iniciar la consola de administración de certificados: Run => certmgr.msc
4. Importar el certificado a la carpeta de certificados personales. En este momento se solicitará el password que le hayamos asignado.

A partir de este momento el certificado es accesible para el servicio de build y habremos solucionado el error anterior.

Salu2 a tod@s,

Desde el año 2004 Microsoft y la comisaria para la competencia de la Comisión Europea venían manteniendo una serie de discrepancias sobre la posición dominante de Microsoft en los mercados europeos, finalmente, en septiembre de 2007, esa discrepancia se resolvió favorablemente a las tesis de la Comisión Europea, y aunque en los medios de comunicación lo que más resaltaban eran los aspectos referentes al Windows Media Player, había una cuestión seguramente más importante, que hacía referencia a la facilitación de los protocolos de comunicación con sus sistemas servidores, entre ellos el protocolo de comunicación entre Office y SharePoint.

Aunque hasta ese momento, existían sistemas que podían intentar algún tipo de funcionalidad similar, siempre dependían del soporte de plugins/addons o similares, que dificultaban enormemente el despliegue de la solución final, sin embargo, desde septiembre de 2007 es posible implementar, de manera segura, un sistema que aproveche la comunicación nativa con Microsoft Office/Outlook y de ese modo poder ofrecer funcionalidades similares a las ofrecidas hasta el momento únicamente por SharePoint.

Un año después, Alfresco es un de los primeros sistemas en ofrecer este tipo de funcionalidad, es decir, simplificando, es un sistema que viene a ofrecer lo mismo que SharePoint, pero si vincularse a un sistema operativo o una base de datos.

Alfresco nació aproximadamente unos tres años de la mano de gente procedente de Documentun e Interowen con la idea de construir un sistema de Gestión de Contenidos basado en OpenSource y en estándares abiertos que ofreciera el contenido como un servicio, y con esta idea han ido creciendo paulatinamente a lo largo de estos años hasta ofrecer con su versión 3 un sistema que a grandes rasgos ofrece las siguientes capacidades:

• Gestión Documental
  Manejo sencillo de documentos a través del Explorador de Windows (Shared Drive) o través de la integración nativa con Microsoft Office (igual que SharePoint: grabar, versionar, compartir…)…y lo mismo con Open Office.
  Document Libraries
  Definición de workflows para documentos.
  Definición de reglas para documentos (manejo de sistemas virtuales de ficheros, iniciación automática de workflows, conversiones automáticas de formatos, envío de notificaciones…)
  Búsquedas (aprovechando toda la potencia de Apache Lucene)
  …
• Gestión de Sites y plataforma colaborativa
  Plataforma para sitios corporativos, intranets…
  Plataforma colaborativa para la gestión de wikis, blogs, páginas personales…
  Gestión de contenidos estáticos
  Gestión de cotenidos dinámicos a través de WebScripts (similares a las WebParts de SharePoint)
  Capacidades de despliegue en servidores de producción, manteniendo múltiples versiones de cada site (SandBox y Staging)
  …

Read the rest of this entry »