Sinadura 4 sobre ubuntu 14 y KDE

Hace más o menos un mes que liberamos la versión 4.2 de sinadura Desktop, y hoy me ha llegado un mail comentando que en el entorno ubuntu 14.04 con KDE el programa fallaba y se cerraba inesperadamente. Después del intercambio de unos pocos mails hemos visto que el problema estaba relacionado con las librerías SWT y el entorno de KDE.

Bucenado un poco por internet hemos visto que cambiando en el fichero /usr/share/themes/oxygen-gtk/gtk-2.0/gtkrc el valor

`GtkComboBox::appears-as-list = 1`
por
`GtkComboBox::appears-as-list = 0`

 

Todo ser arregla y Sinadura parece comportarse correctamente. No se muy bien que quiere decir este parámeto, pero cambiarlo soluciona el problema. Desde aquí agradecer a Fernando Acero Martín la ayuda a la hora de detectar el problema y la ayuda para solucionarlo.

Para la próxima vez tendermos que probar no solo en Unity ....

Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

Migración, diseño responsive y tunning SEO en Liferay 6.2 EE para el portal de Visure Solutions

Desde Zylk.net, hemos estado trabajando en la migración del portal de Visure Solutions (www.visuresolutions.com), desde una versión 5.2.3 CE de Liferay a una versión 6.2 EE. De esta migración, se desprenden varias mejoras respecto al anterior portal:

  • Aplicación de las recomendaciones SEO
  • Diseño responsive para la correcta visualización de los contenidos del portal en dispositivos móviles
  • Organización de los contenidos por países

Mientras trabajábamos junto a Visure Solutions con la anterior versión de Liferay (5.2.3 CE), el experto SEO nos indicó una serie de recomendaciones resumidas en los siguientes posts:

Entre estas recomendaciones, se encontraba la de tener dominios separados que correspondieran a cada país e idioma, y poder así tener URLs internacionalizadas. Debido a esto y ya que Visure Solutions es una multinacional implantada en varios países (España, Alemania, Reino Unido y Estados Unidos), optamos por tener un dominio por cada uno de estos países:

Así pues, por cada uno de estos sites tenemos un árbol de navegación independiente, con las URLs amigables internacionalizadas, y la gestión de los contenidos la realizaríamos desde el ámbito global de Liferay.

Liferay 6.2 EE gestiona  los links de 'alternate' y 'canonical' de la cabecera a partir de la internacionalización de las páginas de un site, sin embargo, debido a que tenemos diferentes sites por país e idioma, Liferay no es capaz de relacionar una misma página, por ejemplo, en español y en alemán, porque están en diferentes sites. Es por esto que hemos creado un plugin para la relación de las páginas entre distintos sites, para poder completar correctamente la cabecera de cada una de las páginas:

Portlet personalizado para la relación de las páginas entre distintos sites

 

El resultado final, por ejemplo, de la página de 'Requirements Management Software' sería:

  • Canonical: http://www.visuresolutions.com/requirements-engineering
  • Alternate - x-default: http://www.visuresolutions.com/requirements-engineering
  • Alternate - España: http://www.visuresolutions.es/ingenieria-requisitos
  • Alternate - Reino Unido: http://www.visuresolutions.co.uk/requirements-engineering
  • Alternate - Estados Unidos: http://www.visuresolutions.us/requirements-engineering
  • Alternate - Alemán: http://www.visuresolutions.de/anforderungsmanagement

Para la gestión de los sitemaps y la de los robots.txt de cada uno de los sites, Liferay 6.2 EE permite realizarla a través de la interfaz de configuración de estos.

Respecto al diseño responsive, utilizamos el framework Bootstrap 2 que ya trae Liferay 6.2. Además, los nuevos contenidos que hemos añadido en las diferentes páginas del portal, también utilizan este framework. De esta manera, el comportamiento de estos mismos contenidos se adapta para poder renderizarse en dispositivos móviles de forma óptima:

Vista de la página de inicio en un PC

 

Vista de la página de inicio en un dispositivo móvi

 

Vista del menú de navegación en un dispositivo móvil

 

Esta gestión de los sites, nos permite además del tratamiento independiente de los contenidos, la gestión, también independiente, de páginas, usuarios, documentos...

Debido a la gestión de diferentes sites por país e idioma (como hemos explicado anteriormente), la gestión de los contenidos que se muestran en estos, la realizaremos observando dónde se mostrará dicho contenido.

Ámbito global y sites por idioma y país

 

Para decidir, dónde tenemos que crear los contenidos, nos hacemos una pregunta ¿el contenido que vamos a añadir va a estar asociado a todos los sites (esté o no traducido)? si la respuesta es que sí, crearemos el contenido en el scope 'Global' de Liferay y lo traduciremos (en caso de que así sea). Si por el contrario, la respuesta es no, crearemos el contenido en el ámbito del site donde se vaya a utilizar, por ejemplo, si queremos añadir un evento (contenido estructurado) que va a tener lugar en Minneapolis sólo añadiremos dicho evento en el ámbito de www.visuresolutions.us (Estados Unidos):

Gestión de un contenido Web estructurado 'Evento'

 

A continuación, vemos cómo se gestiona un contenido no estructurado:

Gestión de un contenido Web no estructurado

 

Además, a corto plazo, se está planteando usar uno de los nuevos plugins que incluye esta versión 6.2 EE de Liferay: 'Audience Targeting EE', que permite dividir a los usuarios en segmentos para poder ofrecerles contenidos específicos. De esta manera podemos crear campañas personalizadas orientadas a los usuarios perteneciente a estos segmentos. Para ello, este portlet nos ofrece la posibilidad de crear reglas a partir de ciertos datos, como por ejemplo: edad, género, número de amigos en Facebook, localización(a partir de su dirección IP)...

 

A través de la gestión de las campañas, el portlet sugiere a los usuarios que pertenezcan a un segmento determinado, una serie de elementos específicos. Por ejemplo, podemos mostrar un enlace de descarga de una aplicación Android a los usuarios que accedan a la página desde un dispositivo Android.

 

Esta visualización de los contenidos de acuerdo al segmento al que pertenece un usuario, la realizamos desde el portlet 'User Segment Content Display', que nos permite configurarlo para indicar si el contenido se muestra al pertenecer (o no) a uno o varios segmentos.

Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

Reactive programming, circuit-breaker y otros patrones de interés para trabajar con flujos de datos

LLevo un par de meses metido en un proyecto bastante interesante, y hasta que no finalice no me está dando tiempo a escribir sobre el mismo. Así que al menos voy a publicar un conjunto de links, muy interesantes, de temas que estamos usando.

Patrones, paradigmas de desarrollo etc... Todos están relacionados con el tratamiento de flujos de datos desde el punto de vista de BigData.

https://gist.github.com/staltz/868e7e9bc2a7b8c1f754
-> reactive programming
http://www.nurkiewicz.com/2014/11/executorservice-10-tips-and-tricks.html
-> tips para concurrent
http://skife.org/architecture/fault-tolerance/2009/12/31/bulkheads.html
-> patrón bulkheads
http://martinfowler.com/bliki/CircuitBreaker.html
-> patrón circuit-breaker
http://www.oracle.com/technetwork/articles/java/ma14-java-se-8-streams-2177646.html
-> usando streams en java8 para procesar datos

 

Espero que resulten ser de interés...

Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

Addons de interes para el modelado de contenidos en Alfresco

En el post de hoy voy a repasar una serie de herramientas y módulos de Alfresco que utilizan entre otras funciones en el modelado de contenidos para Alfresco.
 

Alfresco Model Designer

Alfresco Model Designer es un módulo para el diseño y creación de tipos, aspectos y formularios en Alfresco, directamente desde la interfaz de Alfresco Share proporcionando una vista simple e intuitiva. Permite la creación, testeo y publicación de plantillas y formularios directamente en Alfresco sin la necesidad de editar ficheros XML, y ejecutado en caliente sin la necesidad de reiniciar el servidor. Es un módulo que modifica sustancialmente el núcleo de Alfresco, y es sólo valido para algunas de las versiones de Alfresco, pero permite una edición ágil y sobre todo una visualización de los modelos desplegados e implementados. Hay unos cuantos de propósito similar.
 
 
 
 

Alfresco FDK (Alfresco Development Form)

Alfresco FDK proporciona soporte a los administradores y desarrolladores que desean configurar, extender y personalizar formularios en aplicaciones basadas en Spring Surf como Alfresco Share. Sólo para Alfresco 4.
 
 
 
 

Listas de valores en Alfresco Share

Este addon propociona una manera de gestionar una lista de valores para ser usados en los fomularios de metadatos de Alfresco, como alternativa a al modelo de constraints de tipo lista de datos. Con este módulo, no es necesario reiniciar Alfresco tras editar las listas.
 
 
 

Explorador de nodos

El explorador de nodos es una utilidad de depuración que permite la navegación por la estructura del repositorio de Alfresco, permitiendo visualizar la información para cada nodo de los objetos documentales como tipos o aspectos aplicados, valores de las propiedades, asociaciones o permisos. Es posible acceder a los diferentes almacenes (stores) del repositorio, y acceder a la información de los usuarios, de las categorías o de la papelera. Permite hacer búsquedas mediante referencias de nodo, xpath, jcr-xpath, lucene, fts-alfresco, cmis-strict, o cmis-alfresco. Se puede acceder al explorador de nodos desde los clientes Alfresco Share y Alfresco Explorer. Es muy interesante para las búsquedas por tipos, aspectos y metadatos de nuestro modelo custom de contenidos (o incluso la simple navegación por los stores) permitiendo comprobar que se están consolidando los datos adecuadamente a través de los formularios o APIs utilizadas.
 
 

Consola de Javascript

La consola de Javascript para Alfresco Share es una herramienta precisa y eficaz para desarrolladores de aplicaciones y servicios vía API Javascript, así como tareas de mantenimiento del sistema, proporcionando una potente consola con acceso a la información de nuestra instancia. Desde la consola es posible acceder a toda la información de un nodo o un conjunto de nodos a través de una búsqueda vía API Javascript, y de realizar operaciones sobre los nodos. Es especialmente útil cuando se ejecutan procesos para recorrer e iterar sobre todos los nodos bajo un espacio, por ejemplo de un tipo documental implementado determinado. Es necesario la instalación de un módulo de Alfresco.
 
 
 
 
Ejecutar scripts desde Alfresco Share
 
Un hermano menor de la consola Javascript de Alfresco Share es simplemente definir una acción que permita ejecutar un script de Javascript en Alfresco Share (los scripts albergados en /Data Dictionary/Scripts). Esto es posible en el cliente Alfresco Explorer, pero no en Alfresco Share, con lo que es necesario instalar un módulo adicional. En Alfresco Share podría hacerse algo similar a través de una regla, aunque puede obviarse si se tiene instalado la consola de Javascript. En la versión 5 de Alfresco, al desaparecer Alfresco Explorer, adquiere aún más sentido.  
 
 

Alfresco Filesystem Import

El módulo Alfresco Filesystem Import permite cargar y reemplazar el contenido de una unidad local preservando la estructura de carpetas y ficheros. Es posible así mismo cargar versiones de los documentos así como información sobre los metadatos de nuestro modelo custom a través de ficheros XMLs. El módulo es monoproceso (sólo se puede ejecutar un proceso cada vez), y el acceso a la GUI está restringido a un administrador de Alfresco. El webscript de inicio del módulo de bulk import está en:
 
 
https://alfrescoserver/alfresco/service/bulkfsimport/initiate
 

Exportar e importar ACPs desde Alfresco Share

Un método de importación y exportación (que no exactamente de migración) puede realizarse a través de archivos ACPs (Alfresco Content Packages). Estos archivos contienen toda la información de los permisos, versiones y metadatos de un conjunto de ficheros importado. Es posible realizar importaciones y exportaciones de ACPs desde el cliente Alfresco Explorer y desde Alfresco Share a través de la instalación de un módulo para Alfresco Share. Es interesante no sólo para importación y exportación de contenidos entre instancias de Alfresco, sino también para la manipulación de los metadatos de los mismos.
 
 
 

Alfresco Support Tools

Alfresco Support Tools es un módulo que proporciona herramientas de soporte adicionales en la consola de administración del repositorio. Entre sus características encontramos la posibilidad de visualizar la consola de logs de Alfresco a través de un acceso web (de administrador), lo que es esencial a la hora de probar nuestros modelos de contenidos. Solo para la versión Enterprise de Alfresco.
 
 
 
Más información y otros usos:
Nota: En Alfresco 5.x no está disponible el cliente Alfresco Explorer
Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

Algunos conceptos básicos en el modelado de contenidos de Alfresco

El pasado viernes comencé una serie de posts relativos al modelado de contenidos en Alfresco ECM. Como empecé por el final voy a definir algo de terminología y conceptos clave en el lenguaje documental de Alfresco, ara los que empiezan. Lo que sigue es una traducción parcial basada en el excelente tutorial de Jeff Potts sobre tipos documentales en Alfresco y que referencio más abajo.
 
Un modelo de contenido describe los datos que se están guardando en el repositorio. Conforma una parte esencial y crítica, ya que sin él Alfresco sería algo más que un sistema de ficheros. Un modelo de contenido presenta la siguiente información clave:
 
  • Los tipos de datos fundamentales y como deben persistirse en base de datos. Sin un modelo de contenido, Alfresco no sabría la diferencia entre un literal y una fecha.
  • Los tipos documentales (tipos de datos de alto nivel) como carpetas y contenidos, así como los tipos documentales personalizados (procedimiento, factura, contrato...).
  • Aspectos como “auditable” o “clasificable” o aspectos personalizados como “Datos de factura” o “Datos de empresa”...
  • Propiedades (o metadatos) específicos de cada tipo de contenidos.
  • Ligaduras (constraints) de ciertas propiedades, por ejemplo, una lista restringida de datos.
  • Como indexar el contenido para las búsquedas.
  • Las relaciones (asociaciones) entre los tipos documentales.
 
Los modelos de contenido de Alfresco están construidos en un conjunto de bloques relativos a:
  • Tipos (types)
  • Propiedades (properties)
  • Asociaciones (associations)
  • Ligaduras (constraints)
  • Aspectos (aspects)
Tipos documentales
 
Los tipos documentales son como las clases en el mundo de la programación orientada a objetos. Se utilizan dentro de los diferentes modelos documentales, tienen propiedades asociadas (que usualmente llamamos metadatos) y pueden heredar características y propiedades de otros tipos documentales base de Alfresco, como por ejemplo persona (cm:person), carpeta (cm:folder) o contenido (cm:content). Hablamos normalmente de extender tipos documentales base, basados en un documento (por ejemplo, una factura, un registro o un documento electrónico) o una carpeta (por ejemplo, un expediente), es decir, que heredan las propiedades fundamentales de esos tipos base. La herencia de los tipos documentales es un concepto muy importante en el modelado de contenidos. Cabe notar que los tipos, propiedades, constraints, asociaciones y aspectos tienen nombres únicos dentro de un modelo. Un modelo utiliza un espacio de nombres con una abreviatura como prefijo.
 
Propiedades (metadatos)
 
Las propiedades son metadatos asociados con un tipo particular. En estas se definen el tipo de dato que manejamos y que incluye los tipos básicos fundamentales como literales (strings), fechas (dates) o booleanos. Los tipos fundamentales básicos están definidos por defecto. 
 
Ligaduras (constraints)
 
Las constraints pueden ser usadas para restringir el valor de un valor en Alfresco cuando este se almacena en Alfresco. Hay de cuatro tipos: 
  • REGEX: Se usa para restringir en base a una expresión regular (por ejemplo un CIF)
  • LIST: Se utiliza para restringir en base a una lista de valores (por ejemplo, entre los idiomas disponibles de un documento)
  • MINMAX: Se utiliza para restringir las cotas superior e inferior de un valor numérico. Por ejemplo una propiedad de año valida entre 1970 y 2014.
  • LENGTH: Se utiliza para restringir la longitud de un literal.
 
Las constraints pueden definirse una vez y ser reutilizadas. Por ejemplo, para el nombre de fichero el modelo de contenido de Alfresco define una constraint denominada cm:filename que define una expresión regular. No todos los nombres son posibles, por ejemplo el nombre no puede acabar con un . o no puede utilizarse la /.
 
Como alternativa a la constraints de tipo lista a veces se utilizan listas de datos.Os dejo el link de un artículo previo aquí.
 
Asociaciones
 
Las asociaciones definen las relaciones entre tipos. Existen de dos tipos:
  • Relaciones (peer association) entre dos objetos, sin subordinación.
  • Relaciones hijo-padre (child association): Relación subordinada padre – hijo de tal manera que si se borra al padre, los hijos son borrados (borrados en cascada). 
Un ejemplo por defecto en el modelo de contenidos de Alfresco, de esto ultimo es cm:contains. La asociación cm:contains relaciona una carpeta cm:folder con cada documento en su interior. Os dejo también un ejemplo práctico aquí.
 
Aspectos
 
La herencia de propiedades tiene muchas implicaciones en el modelo de contenidos. En ciertos casos, los modelos planteados no son especialmente jerárquicos si no que necesitan de estructuras más flexibles, transversales y planas. Los aspectos son características de Alfresco (cm:versionable, cm:auditable o cm:taggable son algunos de los aspectos por defecto de Alfresco) y contienen en general conjuntos de propiedades dinámicas que pueden aplicarse a diferentes tipos documentales. Es un concepto en sí, mucho más dinámico que una clase o tipo documental, ya que sus propiedades se pueden asignar en cualquier momento, mientras que las propiedades del tipo son asignadas en la inicialización de la clase. En ciertos contextos, se puede hablar de ellos como tipos documentales de segundo orden.
 
Enlaces:
 
Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

Recomendaciones a la hora de implementar un modelo de contenido en Alfresco

Existen algunas recomendaciones más o menos generales para la implementación de modelos de contenidos en Alfresco, que se apuntan en la propia documentación de Alfresco y en los tutoriales como:
  1.  No cambiar el modelo por defecto de Alfresco, sino extenderlo si es posible.
  2.  Considera implementar un modelo base organizativo con metadatos organizativos.
  3.  Implementa lo que tu modelo necesita inicialmente, no lo compliques innecesariamente.
  4.  Evita una profundidad innecesaria del modelo, evitando jerarquías complejas de tipos documentales.
  5.  Toma ventaja de los aspectos frente a los tipos, por su flexibilidad y reutilización.
  6.  Puede tener sentido definir tipos lógicos que no tienen propiedades o asociaciones.
  7.  Recuerda que las carpetas o personas en Alfresco también son tipos documentales.
  8.  No tengas miedo de tener más de un modelo de contenidos.
  9.  Implementa una clase java correspondiente a cada modelo de contenido.
A la hora de implementarlos puedes:
  • Desplegarlos en caliente en Data Dictionary/models
  • Desplegarlos en el directorio extension
  • Desplegarlos mediante un JAR
  • Desplegarlos mediante un AMP
Normalmente suelo preferir durante el desarrollo desplegarlos en el directorio de extensiones, para finalmente empaquetarlo en un AMP o JAR, en el entorno de producción.
 
Para un modelo uso al menos seis archivos de configuración. En el repositorio normalmente tendré tres archivos por modelo:
  • $ALF_HOME/tomcat/shared/alfresco/extension/zk-model-context.xml 
  • $ALF_HOME/tomcat/shared/messages/zkModel.properties
  • $ALF_HOME/tomcat/shared/alfresco/extension/model/zkModel.xml
En el fichero de contexto de Spring usaré una notación para los ids relacionados con mi modelo, en este caso zylk. Por ejemplo, zk sera el prefix del modelo de contenidos, zk aparecerá en los ids de beans de Spring, zk aparecerá en los ficheros correspondientes.
 
En Alfresco Share tendré así mismo otros tres ficheros para los formularios y share-config-custom.xml:
  • $ALF_HOME/tomcat/shared/alfresco/web-extension/zk-share-forms-context.xml 
  • $ALF_HOME/tomcat/shared/alfresco/web-extension/messages/zk.properties
  • $ALF_HOME/tomcat/shared/alfresco/web-extension/forms/zk-config-custom.xml 

Los archivos de contexto de Spring tanto en el repositorio como en Share apuntarán a las rutas de los otros archivos. Luego es posible que intervengan más ficheros, por ejemplo javascript, si configuramos metadata templates.

Otras recomendaciones útiles pueden ser:
  • Si despliegas los modelos en el directorio de extensiones crea un directorio models por debajo de extension y de forms por debajo de web-extension.
  • No dispongas toda la configuración de los formularios en el archivo share-config-custom.xml, separa los formularios por tipos. Utiliza el archivo unicamente para share-config-custom.xml para las definiciones genéricas como alta de aspectos, utilización de tipos en reglas de contenido o cambiar tipo, y trata de no machacar onfiguraciones anteriores (no uses replace=true).
  • Es preferible que los modelos de contenidos no estén desplegados en Data Dictionary en el entorno de producción (al igual que webscripts o scripts js).
  • El método dinámico de despliegue de modelos es útil para comprobar si hay errores de sintaxis en el modelo, o si el modelo tiene algún error en la carga.
  • En un entorno tanto de desarrollo como de producción, es muy interesante separar las capas del repositorio y de Alfresco Share porque te va a permitir trabajar con formularios de manera más ágil.
  • No mezclar los modelos de despliegue dinámico y estático, sobre todo si se trata de los mismos modelos. Puede ser interesante un acceso web a los logs del repositorio para cuando los modelos no carguen correctamente.
Enlaces:
Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

Nos mudamos a un nuevo blog: blog.irontec.com

Tras nuestra nueva web y nuestra nuevas oficinas en el proyecto Bilbao Berrikuntza Faktoria… nos tocaba también un nuevo blog con aire renovado.

Te esperamos con nuestros contenidos de siempre (VoIP y Asterisk) y mucho más (nuestros proyectos, desarrollo, sistemas, el día a día) en blog.irontec.com.

nuevo-blog-irontec

Kategoriak: General | Komentarioak desgaituta daude

Nos mudamos a un nuevo blog: blog.irontec.com

Tras nuestra nueva web y nuestra nuevas oficinas en el proyecto Bilbao Berrikuntza Faktoria... nos tocaba también un nuevo blog con aire renovado.

Te esperamos con nuestros contenidos de siempre (scripts, partes de código, php, software libre...) y mucho más (nuestros proyectos, voip, sistemas, el día a día) en blog.irontec.com.

Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

Tip for Libreoffice script in Alfresco 5.0.c

Alfresco script $INSTALLDIR/scripts/ctl.sh in Alfresco Community 5.0.c needs a fix for using Libreoffice in transformations and previews for MS-Office and Libreoffice formats:

LIBREOFFICE_SCRIPT=$INSTALLDIR/libreoffice/scripts/ctl.sh
 
to
 
LIBREOFFICE_SCRIPT=$INSTALLDIR/libreoffice/scripts/libreoffice_ctl.sh
 
And in $INSTALLDIR/libreoffice/scripts/libreoffice_ctl.sh script it is necessary to remove "\" in soffice command.
 
Then Libreoffice starts normally with alfresco.sh script. Tested in Ubuntu 14.04 LTS Server.
Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

Script para refrescar los tags de sitios en Alfresco Share

En muchas implantaciones de Alfresco CE y EE de las versiones 3.x, 4.x y 5.x me he encontrado que los tags no funcionan lo suficientemente bien, viendome obligado a refrescar el tagscope de los sitios. Esto produce un reindexado de estas etiquetas. Es una solución temporal, pero permite definir una acción a demanda por ejemplo en un dashlet, un webscript, o incluso en una tarea programada.

Dejo aqui un script aplicable a las librerías de documentos de los sitios. Se puede ejecutar desde la consola de Javascript o desde el módulo ejecutar script en Share, albergando el siguiente código en la carpeta Scripts de Data Dictionary.

 

var nodes = search.luceneSearch('@name:documentLibrary');
 
for each(var node in nodes) {
    logger.log(node.webdavUrl + ' (' + node.typeShort + '): ' + node.nodeRef);
    var refresh = actions.create("refresh-tagscope");
    refresh.execute(node.nodeRef);
}

 

Enlaces:

Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude