Planet

El termino DLL Hell se refiere a los problemas ocasionados por las dll en Windows. El “infierno” ocurre cuando:

• Una instalación sobreescribe una biblioteca con otra versión, dejando en algunos casos los porgramas que enlazaban con ella inservibles.
• Una desintalación borra una biblioteca compartida.

El DLL Hell se ha intentado corregir por parte de Microsoft con los “side-by-side  assemblies”  (SxS) que permiten a una aplicación selecionar una versión específica de una dll.  En que consiste esto? Pues tiene una fácil explicación: en el manifest de la aplicación se especifica la dll que vamos a usar y su versión, de tal forma que cuando se vaya cargar dicha dll, se buscará el ensamblado con la versión especificada en el manifest. El problema es que se buscan las dll’s en un caché de ensamblados y si no está, la aplicación muere al no poder cargarla. Ahora ya no se puede simplemente copiar esa dll a cargar en el directorio en el que está el ejecutable (esto daría lugar al famoso DLL Hell), sino que tiene que estar registrada en el caché
Esto deriva en nuevo problema: el Manifest Hell. ¿Qué pasa si compilamos una aplicación con VC2008, enlazando con el CRT de Windows, es decir, con msvcr90.dll? La aplicación tendrá un manifest de este tipo:

<?xml version=’1.0′ encoding=’UTF-8′ standalone=’yes’?>

Cómo se observa en la sección dependentAssembly, la aplicación buscará el ensamblado Microsoft.VC90.CRT de versión 9.0.21022.8 , el cual no se distribuye en por defecto en ningún sistema operativo de Windows. ¿Esto quiere decir que si compilo una aplicación con VC2008  no la puedo ejecutar en culauiqer máquina? La respuesta es NO, NO SE PUEDE. Este problema ha sido todo un infierno, de ahí el nombre Manifest Hell, en el despliegue de LongoMatch (y más específicamente de GStreamer) y me ha llevado un muchos de quevraderos de cabeza estos últimos meses. La solución de Microsoft es instalar en la máquina objetivo el Microsoft Redistributable Package, lo cual me parece una solución poco elegante al tener que recurrir a otro instalador.
El problema es que mi aplicación usa  GStreamer, cuyos binarios tengo que compilar con VC2008 (GStreamer no proporciona binarios para Windows y cada uno tiene que hacerlo a su manera, lo cual ha derivado en nuevo proyecto que está teniendo muy buena acogida en la  comunidad GStreamer).  La solución es más simple de lo que parece, pero estando muy mal documentada fué muy difícil de encontrar.
Antes he comentado que la busqueda de ensamblados se realiza en una caché de ensamblados SxS, pero existe una forma de distribuir copias privadas. Consiste en copiar el contenido de la capeta %PROGDIR%\Microsoft Visual Studio 9.0\VC\Redist\x86\Microsoft.VC90.CRT a la carpeta bin\ de nuestro programa. De esta forma, al lanzar el ejecutable principal y buscar el ensamblado Microsoft.VC90.CRT, encontrará en su directorio de ejecución una carpeta de nombre Microsoft.VC90.CRT con el contenido del ensamblado. Si la versión buscada coincide con la especificada en el manifest cargará la dll con éxito.
Problema Solucionado!

Eclipse, además de un IDE para Java fantástico, es también una plataforma para el desarrollo de aplicaciones. Estas o bien pueden ser plugins (como el que estoy haciendo yo), o aplicaciones RCP como pueden ser Cool Imaging Project, de unos compañeros que también están compitiendo en el CUSL (saludos!!). El caso es que al ser Eclipse al 99% modular, se presta a ser extendido. La Wikipedia tiene un artículo muy interesante sobre Eclipse, en developer.com hablan de su arquitectura, y en el libro The Java Developer's Guide To Eclipse (muy muy recomendable) hay muchísima más información. Como a veces lo más sencillo es una imagen, he tomado prestada una imagen de ese libro que es representativa de la arquitectura de EclipseQuizá el componente más usado de Eclipse es JDT, porque de un modo u otro todos los que desarrollamos sobre Eclipse lo utilizamos. Pero con la tendencia actual de ver a Eclipse como un framework de desarrollo de aplicaciones han aparecido proyectos alrededor que son muy interesantes, como por ejemplo BIRT, Mylyn, DTP... si, todo son siglas ;-)Uno de estos componentes que me está siendo especialmente útil es EMF, que responde a Eclipse Modeling Framework Project. En plan rápido, EMF es un framework para el modelado y gemeración de código para construir herramientas y otras aplicaciones basadas en un modelo de datos estructurado. Desde la especificación de un modelo descrita en XMI, EMF proporciona herramientas y soporte para generar un conjunto de clases Java para el modelo, además de clases adapter para soportar la visualización y la edición del modelo. Como imagino que esta descripción tampoco es muy útil, y hay sitios donde pueden explicar con más criterio que yo en qué consiste EMF, voy a intentar explicar porqué es útil para mi proyecto.Imaginemos que estamos desarrollando una aplicación en la que hemos identificado un modelo de datos relativamente complejo, y que debemos ser capaces de serializar y deserializar desde XML. Por ejemplo este, descrito en UML, y que modela parte del soporte para Casos de Uso que tiene eOPSOA:Este modelo se podría implementar sin problemas en Java, pero sería una tarea cuanto menos dolorosa. Y si a esto añadimos el asunto de la serialización/deserialización en XML, listeners, adapters... etc., nos podemos dar cuenta que no es un asunto trivial.Si desarrollamos un plugin para Eclipse, una aplicación RCP, o simplemente una programa Java, nos puede resolver la vida. Entre otras muchas cosas, con EMF podemos hacer:

• Describir el modelo de datos a alto nivel. P.e. podemos usar un diagrama de Rational Rose, un diagrama UML, XSD, interfaces Java anotadas... etc. para construir un fichero ecore con el modelo de datos de nuestro sistema.
• Con el fichero ecore, podemos generar un fichero genmodel que a su vez puede ser usado para generar el código Java que describe nuestro modelo. Crea además un editor en línea de comandos y otro gráfico como plugins de Eclipse. Todo eso sin tener que escribir una línea de código ;-)
• Con el código que hemos generado, podemos serializar/deserializar nuestro modelo a XMI y XML, tenemos relaciones entre objetos, notificaciones, notificaciones inversas, adaptadores... etc. Todo ello como he comentado out-of-the-box, solo con la descripción a alto nivel de nuestro modelo y sin escribir (casi) una sola línea de código.
• Podemos manipular el código generado, y si en un futuro hay cambios en el modelo, se puede recargar y regenerar el código, respetándose nuestros cambios.
• Podemos usar los ficheros ecore y genmodel anteriores para crear un editor gráfico (en plan pinchaiconos, copiar y arrastrar) con GMF.
• Y bueno, muchas cosas más que no sé ni creo que vaya a necesitar en un futuro cercano, pero que parecen cosa fina oiga.

A mí al menos, me ha resuelto la vida. Si le echáis un ojo a mi SVN, el plugin org.uclm.eopsoa.core es prácticamente un modelo EMF un poquito grande, y todo el código Java que me genera automáticamente. Si queréis comenzar con esto hay bastante información disponible en Internet, pero lo suyo es comenzar mirando la documentación de EMF, leer la guía para programadores, e intentar hacer los tutoriales. Hay una chuleta de referencia que viene muy bien, y si sabes que te vas a pegar mucho han sacado hace poco la segunda versión del libro EMF: Eclipse Modeling Framework. No es barato pero cubre mucho mucho mucho más de lo que puedas encontrar en Internet, y es extremadamente útil.No sé si os habré convencido, pero para terminar voy a comentar algunas cosas que he aprendido durante estos meses usando EMF:

• En los tutoriales apenas se comenta, pero la forma más cómoda para crear un modelo EMF es editando el fichero ecore con el editor. Muestra un árbol con los elementos, se pueden añadir/eliminar nuevos hijos, y manipular las propiedades en el properties view. Las interfaces Java anotadas son útiles porque proveen de una perspectiva más cercana a la que podemos tener los programadores, pero es mucho más fácil meter la pata y se pierde flexibilidad. Además, que si tu modelo EMF es un poco complejo es un rollo recordar las 80 anotaciones que quizá te hagan falta.
• Procura tener tu modelo EMF lo más limpio, expresivo y rico posible. Si te ves modificando mucho código autogenerado, suele ser señal de que necesitas trabajar más tu modelo.
• El nombre de los atributos va a tener mucho que ver en cómo se va a generar el fichero XMI/XML de persistencia del modelo. No te agobies demasiado si alguna etiqueta queda algo rara; mejor tener una API cómoda para trabajar. Y si alguien tiene que usar tu XML, siempre podrá usar a su vez EMF y entonces te agradecerá las decisiones que hayas tomado.
• NUNCA, NUNCA pienses que no vas a tener que regenerar el modelo (y el código) y muevas paquetes, cambies nombres a clases sin que se entere EMF. Suele pasar cuando en tu proyecto usas una convención de nombres de interfaces/clases distinta a la que genera EMF, y con las facilidades de refactorización que provee Eclipse puede ser goloso liarse la manta a la cabeza, y moverlo y cambiarlo todo de sitio. Pero aunque no quieras, tarde o temprano vas a tener que modificar tu modelo, y al final tendrás un pisto y perderás tiempo.

Espero que este post haya sido útil, si alguien quiere comentar lo que fuera es bienvenido :-)

Ha sido confirmada por parte de la organización del II Concurso de Software Libre castellanomanchego la fecha de la fase final de dicho concurso, donde se hará entrega de los premios a los proyectos ganadores.  Se llevará a cabo el 23 de Abril de 2009 en la Escuela Universitaria Politécnica de Cuenca.
Aquellos que deseen acudir a dicho evento dispondrán de autobuses gratuitos para asistir desde Albacete y Ciudad Real.

Hoy vamos a comentar un poco por encima el entorno de desarrollo que vamos a utilizar así como la configuración que fue
necesaria darle, el resto de herramientas que se están usando en el proyecto, el tipo de lenguaje de programación elegido, y las librerías que utilizadas.
Usaremos C# como lenguaje para desarrollar la aplicación, nos hemos decantado por esté ya que la librería que utilizamos para el reconocimiento de las marcas de colores está implementada en C#, esta librería es Touchless de Microsoft con licencia Ms-PL ( Microsoft Public License) y ya que estamos ante un concurso de software libre hemos utilizado herramientas de software libre, como pueden ser:  SharpDeveloper, Tortoise, etc…
En la siguiente imagen pueden observar un poco las clases que conforman toda la librería Touchless  a día de hoy y en la cual vamos a basar nuestro trabajo.
Clases que conforman toda la librería Touchless, con la que vamos a trabajar a lo largo del proyecto.
Comentar que nos hemos decantado por SharpDeveloper ya que el IDE de Mono (MonoDeveloper) no estaba del todo funcional a la hora de empezar con el proyecto, a continuación  explicamos con detalle los pasos necesarios para poder configurar SharpDeveloper y compilar a través de la plataforma libre de Mono.
En principio es una tarea bastante sencilla, simplemente tenemos que indicarle a SharpDeveloper que al compilar ya sea en Release o Debug este lo haga a través de la plataforma de Mono, para ello vamos a las “propiedades” del proyecto, se nos abrira una ventana que nos da diversas opciones separadas en distintas pestañas, elegimos la pestaña de depuración y alli realizaremos los siguientes paso tanto para Debug como para Release:

• Dentro de “Acción de Inicio” elegimos “Iniciar programa externo” y buscamos el ejecutable de Mono “mono.exe” como se muestra en la segunda imagen.
• Dentro de “Opciones de Inicio” añadimos a la opción “Argumentos de línea de” el siguiente trozo con las comillas incluidas como se muestras en la imagen “${TargetPath}”
• Y por último en la siguiente opción “Directorio de trabajo” añadimos ${TargetDir}

Bueno una de las cosas que me quedan por hacer o empezar ha hacer es el motor de informes o yai que es el codeName.
Estuve que elegir en que formatos pdf, RTF, excel , Open  Calc, pues viendo todas las herramientas de reporting vi que lo estándar es pdf,excel y html, esto me llevo a una pregunta que usar para pdf ya que para Excel esta mas que claro POI por que es la única que conozca.
Pero para pdf he visto algunas sobre todo con 2 una que me la enseño dagi3d programador cualificado donde los alla y es una capa que recubre a  iText que es la otra.
Voy a enseñar un poco ambas con algunos ejemplos y los resultados de mis pruebas con ellas , siempre con una cantidad de datos mas grande de lo avitual para los sistemas de reporte.
la Primera es iText,a segunda es la que he hablado anterior mente Flying Saucer y por ultima la todo poderosa PIO de Apache.
iText

iText es una biblioteca Open Source para crear y manipular archivos PDF, RTF, y HTML en Java. Fue escrita por Bruno Lowagie, Paulo Soares; está distribuida bajo la Mozilla Public License con la LGPL como licencia alternativa.
Esta librería es de las mejores en el mundo java para la exportación a pdf , el problema que tiene es la maqueta  es muy complicada y eso hacer difícil su uso , requiere una gran cantidad  horas de pruebas para poder usarlas.
Flying Saucer
Esta librería es la que he comentado antes muy por encima , esta iberia emcapsula a iText y lo que   hace es renderizar una pagina xhtml+css y sacarte el pdf . Esta librería tiene problemas o mas de 6000 registros en base de datos , usa mucha memoria ya que utiliza DOM para poder pasear el xhtml.
Esta es POI para poder generar ficheros excel ya que es el formato de fichero mas común dentro de los negocios , hay barbaridades hechas con POI , tiene otras aplicaciones pero esta creo que es la mas común.
Ejemplos de uso
Ahora voy a explicar como voy a usar cada una y por que. La primera es POI , necesito un método para que cuando ejecute la query me de un fichero .xsl con el nombre que yo quiera tanto en el fichero como en las pestañas.
xsl

public void escribirExcelOnlySheetHerad(String nameXsl, String nameSheet,
ResultSet datos) throws SQLException, IOException {
HSSFWorkbook wb = new HSSFWorkbook();
// Creo la pestaña
HSSFSheet sheet = wb.createSheet(nameSheet);
HSSFRow row = sheet.createRow((short) 1);
// pongo las cabezeras de la query
for (int j = 1; j <= datos.getMetaData().getColumnCount(); j++) {
HSSFCell cell = row.createCell(j, HSSFCell.CELL_TYPE_BLANK);
…….
Ahora toca iText .Como ya hable iText es para pasar a pdf tiene muy buena documentación y es potente , pero es complicada de manejar.Tiene un buen libro
public void RendderPEF(ResultSet rs,String NameFile,String size){
try {
int numS = rs.getMetaData().getColumnCount();
Document document  = new Document();
PdfWriter.getInstance(document, new FileOutputStream(NameFile));
document.open();
PdfPTable table = new PdfPTable(numS);
PdfPCell cell = new PdfPCell(new Paragraph(”Informe Ejemplo”));
cell.setColspan(numS);
table.addCell(cell);
int i = 1;
while (rs.next()) {
for(int j = 0 ; j>rs.getMetaData().getColumnCount();j++){
table.addCell(rs.getString(j));
….
y por ultimo flying saucer , lo que tengo es un método que saca un xhtml con el ResulSet y me genera el informe, el problema de esta librería es que come mucha ram para informes de 6000 registros , por usar DOM para renderizar el informe , pero esta librería es muy sencilla de manipular ya que con css uno hace maravillaras.
String inputFile = “samples/firstdoc.xhtml”;
String url = new File(inputFile).toURI().toURL().toString();
String outputFile = “firstdoc.pdf”;
OutputStream os = new FileOutputStream(outputFile);
ITextRenderer renderer = new ITextRenderer();
renderer.setDocument(url);
renderer.layout();
renderer.createPDF(os);
os.close();
Este es el diagrama UML de yai que es básicamente un modelo Strategy.
Siento si el post es algo grande .
Fuentes:

• http://itextdocs.lowagie.com/tutorial
• http://poi.apache.org/spreadsheet/quick-guide.html
• http://apiconz.wordpress.com/2007/10/22/como-generar-hojas-de-excel-en-u...
• http://dagi3d.net/blog/archive/2007/06/28/generar-documentos-pdf-con-rai...
• http://today.java.net/pub/a/today/2007/06/26/generating-pdfs-with-flying...

Buenas! hace ya tiempo que estamos algo inactivos, la culpa de los exámenes :P, pero una vez liberados de cierta presión volvemos al asunto, voy a dejar unas capturas para que se puedan hacer una idea de como va a ser el funcionamiento del sistema de detección de movimientos.
Para explicar un poco el asunto antes de las capturas y fotografías, comentar que la detección se hace a través de  marcas de colores, por ello nos hemos vistos obligado a idear un sistema para poder situar los distintos dedos de la mano en una determinada posición dentro de la zona de captura de la cámara.
El hardware utilizado es bastante básico y barato de echo el que estamos usando ahora es una cámara web de hace ya unos cuantos años, aunque siempre es mejor una cámara con mas resolución esta funciona bastante bien.

Bienvenidos a  sapiensproject.wordpress.com. Inicio del blog para el proyecto Sapiens. En breve se informará de todo aquello que rodea y comprende dicho proyecto.

En primer lugar hola a todos, el proyecto que estamos desarrollando es la implementación el diseño y la cinemática de un manipulador de 5 grados de libertad, esto quiere decir que tiene 5 ejes de movimientoeste manipulador esta pensado para que actúe de una manera independiente (como el de la figura) o como una base móvil que opera autónomamente en n entorno controlado.con esta idea básica empezamos a desarrollar este proyecto, el interfaz de control del brazo optamos por realizarlo en un entorno de java y el control interno del manipulador lo realizamos con una placa de arduino.

Hola a todo el mundo , últimamente me he atascado bastante en el proceso del xmi y la generación efectiva de las querys , así que haciendo uso de Will he mandado un correo al todo poderoso Matt para que me aconseje y/o colabore aun con un coste para mi proyecto.
Dear Matt,
I am a student and am doing my final thesis project, which consists in making an application similar to Pentaho?s Adhoc. This application offers some improvements, such as including more input types, DataSet (obtained from Birt), access to Google Analytic and Yahoo, access to OLAP and metadata, as well as the possibility of carrying out studies on the selected data (statistical formulas, clustering with Weka, etc.), or saving reports using Lucene, sending via e-mail and getting reports in various formats (PDF, Excel, etc.).
My main problem is processing the metadata, as I can not manage to correctly parse the file and do properly the queries. I would like you to help me with this or even top co-operate in the project; the code is free and am doing the application in order to integrate it within Mantel. The application is made in Java, Spring and ICE FACES with regard to interfaces, but can be changed to GWT trouble-free.
I can give you access to the SVN repository if you like.
You can find below a summary of the project with a diagram.
rc

Ahora mismo estoy trabajando en volver a integrar POP en el proyecto. Aunque no puedo reutilizar del todo el código de las versiones antiguas que usaban POP y lo estoy modificando un poco. Tengo el código casi terminado, me falta integrarlo con las interfaces de usuario, de tal forma que el usuario pueda elegir entre usar POP e IMAP.
Espero publicar pronto una nueva versión con POP ya integrado.