El Blog d'en jrodriguez

Algunas notas útiles sobre Plone

 

Aquí algunas notas dispersas sobre Plone que comparto con vosotros. No se trata de un artículo estructurado, simplemente se trata de notas sobre problemas y situaciones que me han ido apareciendo. En inglés.

 

Introduction

PLONE is a content management system Zope-based and programmed in Python.
http://plone.org contains all information about it.

Zope is an Application Server that integrates a Data Base Management System called ZODB (an Oriented Object Data Base).
Both the APS and the DBMS can be changed to Apache or MySQL if you want it.


Features                                            

  • It’s open source (GNU licence)
  • Multilanguage (includes Spanish and Catalan)
  • Multiplatform (Windows, Linux and Mac).
  • It can be used like a Document Publication System, intranet and a collaborative tool are allowed, so.
  • Separated layers. Contents and design are in independent layers.

 

Installation (Linux Debian)


Zope

It has a web interface to manage it. It’s called ZMI (Zope Management Interface).
ZMI allows you to:

  • Create Plone instances. Every Plone instance is an independent web portal.
  • Improve or change the GUI
  • Add new elements, modify and delete.
  • Add new products, modify and delete.
  • Also, add new content. But it is preferable to do using the Plone instance directly.


Plone instance

You have got and admin user who can edit the content of the portal (plone instance).


Workflow and users

There are 4 roles by default with read, write, revision or admin permissions, but you can define others:

Roles

Read

Write

Approve/Reject

admin.

anonymous

X

 

 

 

member

X

X

 

 

reviewer

X

X

X

 

manager

X

X

X

X

Permissions each user has got over specific object (folder, document, etc.) goes in function of user role:

  • Manager: allows to do anything over the objects (create, edit, delete, permissions and publish).
  • Owner:  allows creating, editing, deleting, permissions and send object to publish, but publish.
  • Review: permite revisar objetos en espera de ser publicados, publicarlos y recharzarlos
  • Member: permite ver documentos publicados, editar su carpeta de usuario y escribir en el wiki.
  • Anonymous: usuario que no ha iniciado sesión en el sistema o no tiene cuenta, sólo permite ver documentos publicados
When someone with sufficient privileges builds a new object, must check all is right and then send it to publish. Later a reviewer will accept the object and then it will be visible for everybody.

If an editor wants to modify the object, he will send it to review another time.


Products

Products are modules that could be integrated if consider necessary it.
Some products: News, events, wiki, user’s management,

To install a product:

  1. Download the product version correct and take care with the platform.
  2. Unzip the packet to the directory

    1. Windows plone_home\Data\Products
    2. Linux var/lib/zope2.9/instance/plone-site/Products
  3. Then use the tool to install Add-on Products. Log in like admin and go to portal administration tools. Select add products option and select the product you like install on.

 

Design layer

The GUI should be designed using ZMI tool, nevertheless you can edit the files directly.
All the styles and templates of portal instance are located in instance/portal_skins/.
You can change it to build your own GUI.

 

Redirect plone instance to domain 

  1. Go to ZMI,  /virtual_hosting/mapping
  2. Edit it putting the next code: http://host:name/instance_name

It doesn’t work for multiple plone‘s istances.

 

Change the logo

To cahnge the principal logo:

  1. Got to ZMI, /portal_skins/custom, Image, Add
  2. And name the image like logo.jpg.


News order

To see the news in reverse order:

  1. Go to ZMI, /portal_skins/plone_templates/news
  2. Edit the line
  3. container.portal_catalog(portal_type='News Item',sort_on='Date',sort_order='reverse',review_state='published');
  4. Deleting this part: sort_order = 'reverse'


More info
Plone & Drupal comparative [spanish] [update Nov 10th 2008]

 

Subversion vs CVS. Guía rápida de Subversion (SVN)

CVS y Subversion (SVN) sirven para controlar las versiones y la historia de los proyectos software. Por lo tanto, a grandes rasgos, permiten:
  • que varias personas puedan trabajar en un mismo proyecto sin afectarse mutuamente en el trabajo que realiza,
  • que haya un histórico de revisiones, por seguridad y para poder recuperar una versión anterior de nuestro código,
  • gestionar versiones de la aplicación, derivaciones y demás.

Podríamos decir que las instancias de CVS y Subversion son repositorios, es decir, un almacén de ficheros, sus versiones y su historial de cambios.

 

Comparativa

Subversion es evolución natural de CVS, mejorando algunas de las carencias de este último. Veamos una comparación:

CVS

Subversion (SVS)

Licencia gratuita

Licencia gratuita

Multiplataforma

Multiplataforma

Orientado a ficheros

Versiona los ficheros,
no el proyecto. Esto quiere decir que cada modificación en cada fichero hace
variar  la versión del fichero
modificado.

Orientado a proyectos

Versiona los proyectos, no los ficheros. Es
unaopción mucho más intuitiva que no la de versionar ficheros.

 

Envía ficheros completos

Cuando se hace una modificación
en un fichero, se sube al repositorio el fichero entero, en vez de sólo los
cambios.

Envía sólo cambios

Cuando se hace una modificación en un fichero, se
sube al repositorio el cambio realizado, no el fichero entero. Más eficiencia.

Soporte Unicode limitado

Puede traer problemas
con caracteres "raros".

Soporte Unicode

En principio no debería dar problemas de esta
índole. En principio.

Renombrar/eliminar

No da soporte. Hay que
hacerlo manualmente: copiar con otro nombre y borrar el antiguo.

Renombrar/eliminar

Da soporte parcial. El usuario lo hace en una
única operación pero SVN internamente lo hace las dos cosas en una transacción
de forma transparente al usuario: copiar con otro nombre y borrar el antiguo.

 

Funcionamiento de Subversion

  • Update: Puede haber conflicto entre nuestra copia local del proyecto y la versión en SVN. En tal caso hay que resolver conflictos con merge. Existe una herramienta gráfica de resolución de conflictos que da al programador la oportunidad de escoger entre tres posibles contenidos del fichero:
    • contenido en SVN,
    • contenido en HD local del programador,
    • contenido fusionado por SVN.
  • Edición: El programador modifica los ficheros del proyecto.
  • Commit:  No existe conflicto ya que o nos dejan subir o no nos dejan subir. Los commits son atómicos. O suben todos los ficheros o no sube ninguno (similar a las transacciones con BD) Si no podemos subir un proyecto hay que hacer un update y resolver conflictos. El número de revisión del proyecto se incrementa independientemente de donde se realice el commit (en la rama principal o en una subrama). Todos los commits deberían estar comentados.

SVN de alguna forma penaliza al último en subir los cambios


Ejemplos de trabajo con subversion

Obtenemos una instancia del repositorio en nuestra máquina de trabajo:

svn checkout svn://server/poject

Esto nos copiará los archivos del repositorio, y en cada carpeta añadirá un directorio
oculto de nombre .svn en donde guarda los metadatos con el historial de cambios, las
distintas versiones y demás.
Una vez tengamos la copia en nuestra máquina, el proceso a seguir para a la hora de
realizar modificaciones es:

  1. svn update, para actualizar nuestra versión, por si algún compañero ha introducido algún cambio,
  2. modificamos los ficheros que tengamos que modificar, por ejemplo el fichero carpeta/index.html,
  3. cuando hayamos terminado deberíamos volver a hacer un svn update, por si alguien ha modificado también el mismo fichero que nosotros,
  4. svn commit -m "esto es lo que he hecho" carpeta/index.html para commitear o subir al respositorio la modificación que hayamos realizado, indicando una breve descripción de la misma.

Más información

Página oficial del proyecto [english]

Google y la tecnología PageRank

 

Muchas veces os habréis preguntado cómo los motores de búsqueda, especialmente Google, calculan la relevancia de una página. La verdad es que los algoritmos encargados de ello suelen ser secretos. Sin embargo, una pequeña parte del algoritmo de Google es pública. Y es que el caso que nos ocupa hoy es el de Google y su sistema PageRank

Google recibe hoy el Principe de Asturias en Comunicación y Humanidades 2008
¿Qué es un motor de búsqueda? 
  • Es un sistema de almacenamiento y recuperación de datos.
  • Base de datos diseñada para indexar direcciones web (url, ftp, etc.)

Basados en índices o directorio

  • Los índices o directorios basan la recuperación en la clasificación por un indexador humano.

Basados en crawlers (Google)

  • Rastrean servidores Web con el fin de indexar la información que almacenan. Los programas encargados de hacer el rastreo son los crawlers o indexadores automáticos.

Meta motores de búsqueda

  • Los meta-motores permiten buscar en varios motores de búsqueda simultáneamente.

Características de Google

  • Utiliza la información hipertextual de los documentos Web para calcular la relevancia de cada página, utilizando lo que se denomina PageRank.
  • Utiliza los enlaces (links) y el texto de los mismos para mejorar los resultados de la búsqueda.
  • Mantiene información de la posición de los términos que aparecen dentro de los documentos indexados, lo que permite búsquedas por proximidad.
  • Mantiene información de la apariencia visual de los documentos (p.e: a las palabras marcadas en negrita o con un tamaño de letra mayor se les concede mayor peso al calcular la relevancia).
  • También se sabe que mejora la relevancia las palabras inlcuidas en la URL.
PageRank
PageRank es un valor numérico que representa la importancia que una página Web tiene en Internet, según Google.

 

 

  •   r(i) es el PageRank de la página.
  •   N(i) es el número de enlaces (salientes) de la página.
  •   B(i) es el número de páginas que apuntan a la página.
  •   m es el número total de nodos en el grafo.
  •   d es el factor de decaimiento (entre 0 y 1).


Por lo tanto:

  • El PageRank para una página será alto:
  • Si existen muchas páginas apuntándola
  • o aunque la apunten pocas páginas, éstas tienen PageRank alto. 

  • Prestaciones
  • Ranking ordenado y ponderado de acuerdo al PageRank de cada página.
  • Prioridad de la calidad de las búsquedas sobre la eficiencia (en tiempo) de las mismas.
  • Límite del tiempo de respuesta: una vez que se ha encontrado un número determinado de documentos se devuelven resultados parciales.

El diccionario de datos en Oracle 9i. Guía útil.

Sí, soy consciente que hay versiones más nuevas y mejores de Oracle, sin embargo mi conocimiento como Administrador de este Sistema Gestor de Base de Datos está provisionalmente detenido en la versión 9i. Todo se andará...

Así que no soy consciente de los cambios y mejoras que puedan haberse producido en versiones postriores. En el presente artículo me referiré a Oracle 9i.

El diccionario de datos es quizá una de las partes más importantes de Oracle. Se trata de un conjunto de tablas de sistema, de sólo lectura, que proporcionan información muy útil sobre la base de datos.

 

Estructura

  • Tablas: Tablas del diccionario de datos.
  • Vistas: Para que algunos datos puedan ser accesibles por cualquier usuario autorizado.
  • Usuario SYS: EL propietario de las tablas del diccionario de datos.

Información proporcionada y forma de acceso (las vistas del diccionario de datos)

Aquí os dejo una guía útil:

SELECT OWNER, TABLE-NAME

FROM DBA_TABLES

WHERE OWNER = ‘usuario';

Para ver las tablas de los usuarios

DESC USER_TABLES

Para ver lo que se guarda en las tablas

SELECT TABLE_NAME

FROM USER_TABLES;

Para saber las tablas que tiene el usuario

USER_CONS_COLUMNS

DBA_CONS_COLUMNS

ALL_CONS_COLUMNS

Para ver las restricciones que afectan a las columnas

USER_TABLES

Muestra las tablas propias del usuario activo

ALL_TABLES

Muestra todas las tablas propias del usuario activo

DBA_TABLES

Muestra todas las tablas de la BD's

USER_CONSTRAINTS

Para ver las restricciones del usuario activo

DBA_CONSTRAINTS

Para ver las restricciones de la BD's

ALL_CONSTRAINTS

Para ver todas las restricciones

SELECT *

FROM USER_TABLESPACES;

Para ver todos los tablespaces

SELECT_CATALOG_ROLE

Para ver entero el diccionario de datos

SESSIONS_PRIVS

Información de los privilegios del usuario activo

USER_SYS_PRIVS

Información de los privilegios de sistema del usuario activo

DBA_SYS_PRIVS

Información de los roles y privilegios del sistema del usuario activo

USER_TAB_PRIVS

Información sobre los privilegios de objeto relacionados con el usuario, tanto otorgados como concedidos

USER_TAB_PRIVS_MADE

Privilegios concedidos

USER_TAB_PRIVS_RECD

Privilegios recibidos

SESSION_ROLES

Roles del usuario activo

ROLE_SYS_PRIVS

Privilegios de sistema asignados a los roles

ROLE_TAB_PRIVS

Privilegios sobre objetos asignados a los roles

DBA_ROLES

Todos los roles del sistema

DBA_PROFILES

Todos los perfiles de la BD's

DBA_DATA_FILES

Archivos que componen mi espacio de tabla

USER_FREE_SPACE

Tamaño libre de mi espacio de tabla

DBA_FREE_SPACE

Tamaño libre en todos los tablespaces

DBA_TABLESPACES

Tablespaces del sistema

DBA_TS_QUOTAS

Uso de los tablespaces por los usuarios

 

Más información

Diccionario de datos (vía Oracle) [english]

Usabilidad en las Interfaces Gráficas de Usuario - GUI (II)

Continuando con...
El artículo Usabilidad en las Interfaces Gráficas de Usuario - GUI (I) ...
4. Confiabilidad
El usuario se debe sentir seguro al manejar la GUI. Si el usuario tiene miedo de "cargarse algo", nunca sacará el máximo rendimiento a la interfaz.
Pedir confirmaciones a operaciones sensibles (borrados). Idealmente permitir recuperar información antigua. Esto da mucha confianza al usuario. El mayor temor del usuario inexperto es borrar información. Vamos… cargarse algo.

Agreement Technologies (AT) - Tecnologías de Acuerdo

 

AT es el mayor proyecto de investigación al que se ha enfrentado el IIIA. Se trata de la búsqueda de un nuevo paradigma para sistemas distribuidos. Este nuevo paradigma se estructura a través del concepto de acuerdo entre agentes software… bueno… creo que el coordinador del proyecto, el Prof. Carles Sierra, seguro que lo explica mejor que yo y además en menos de 2 min.:

 


Get the Flash Player
to see this player.

 

¿Cómo?

Las líneas de investigación se han estructurado en una arquitectura de torre de 5 niveles.

Arquitectura AT

 

  • Nivel 1: Semántica y gestión de recursos. Solucionar incompatibilidades semánticas y establecer ontologías para comprender las normas o acuerdos.
  • Nivel 2: Definición de las normas que determinan las restricciones que todo acuerdo debe satisfacer. En este nivel se debe estudiar la capacidad del software para adaptarse a la normativa.
  • Nivel 3: Organizar las estructuras sociales de los agentes: roles y relaciones entre ellos.
  • Nivel 4: Este nivel es para el estudio de métodos de argumentación y negociación. Esto se traduce en alcanzar acuerdos que respeten las restricciones que las normas y organizaciones imponen a los agentes.
  • Nivel 5: La capa de confianza que se encargará de construir las relaciones entre agentes a partir de la reputación que adquieran estos. Muy importante para un sistema abierto como éste.

¿Quién? ¿Cuándo?

Más información

www.agreement-technologies.org

 

Desde la UDT-IA seguimos dando nuestro apoyo al proyecto.

Metodología de desarrollo de sotware. El Modelo en V o de Cuatro Niveles.

 

Imaginemos, si no hubiera crisis (desaceleración debido a la coyuntura económica internacional, que diría mi primo) que quiero construirme una casa.

¿Qué pensaríais de mí si empezara a poner ladrillos sin antes haber hecho un estudio...
...del suelo, materiales, recursos, y sin haber hecho un diseño previo? Pensaríais de mí, lo mismo que yo pienso de la gente que se pone a programar sin seguir una metodología de programación.

La metodología que os presento es el Modelo en V, o Modelo de Cuatro Niveles

¿En qué casos la utilizo?
Se trata de un proceso ideal, por su robustez, para proyectos pequeños, con equipos de una a cinco personas. 

También es ideal, por su claridad, para toda esa gente que nunca ha programado siguiendo una metodología. Para el proyecto final de carrera o para ese cliente que te ha conseguido un amigo de un amigo que te lo pide a ti y no se dirige a una empresa por esto de la desaceleración.

¿En que consiste exactamente?
La figura que aparece a continuación presenta el Modelo en V, o Modelo de Cuatro Niveles, del ciclo de vida de un proyecto de desarrollo de software. El modelo representa, en forma de V, las relaciones temporales entre las distintas fases del ciclo de desarrollo de un proyecto.

 

Modelo en V o Modelo de Cuatro Niveles

 

En los niveles lógicos del 1 al 4, para cada fase del desarrollo, existe una fase correspondiente o paralela de verificación o validación. Esta estructura obedece al principio de que para cada fase del desarrollo debe existir un resultado verificable.

En la misma estructura se advierte también que la proximidad entre una fase del desarrollo y su fase de verificación correspondiente va decreciendo a medida que aumenta el nivel dentro de la V. La longitud de esta separación intenta ser proporcional a la distancia en el tiempo entre una fase y su homóloga de verificación.

  • El nivel 1 está orientado al “cliente”. El inicio del proyecto y el fin del proyecto constituyen los dos extremos del ciclo. Se compone del análisis de requisitos y especificaciones, se traduce en un documento de requisitos y especificaciones.
  • El nivel 2 se dedica a las características funcionales del sistema propuesto. Puede considerarse el sistema como una caja negra, y caracterizarla únicamente con aquellas funciones que son directa o indirectamente visibles por el usuario final, se traduce en un documento de análisis funcional.
  • El nivel 3 define los componentes hardware y software del sistema final, a cuyo conjunto se denomina arquitectura del sistema.
  • El nivel 4 es la fase de implementación, en la que se desarrollan los elementos unitarios o módulos del programa.

¿Tengo que hacer documentación de todo?
Por supuesto. Cada fase tiene que estar respaldada por su documento correspondiente y test.

¿Por qué utilizar una metodología?
Porque es lo más rápido y barato. Volviendo al ejemplo de la casa, imaginad la cantidad de veces que debería volver atrás y tirar paredes ya hechas porque de pronto descubro que el suelo es inestable, la bañera no cabe, la instalación eléctrica no la había tenido en cuenta… 
Pues, con el código pasa exactamente lo mismo.

Usabilidad en las Interfaces Gráficas de Usuario - GUI (I)

 

Alguien dijo una vez que "el hardware es aquella parte del ordenador que se lleva las hostias cuando falla el software". La frase va más allá de una simple gracia y tiene implicaciones muy importantes.

La implicación más inmediata, a parte de los destrozos que nuestra ira pueda causar, sería el reconocimiento de que el software muchas veces no cumple nuestras expectativas.

 

Yo voy más allá,  simplifico la cuestión al Problema de Realizar Interfaces de Usuario o,  como es el caso que nos ocupa, interfaces gráficas de usuario. Sí, sí… estoy diciendo que si estuvieran bien hechas, no perderíamos la paciencia tan fácilmente con nuestro PC.

Existe toda una teoría que intenta abordar esta cuestión, metodizando el proceso de creación de GUIs para que el diseño sea centrado en el usuario, aunque pocos nos hemos interesado por ella.

Como desarrollador de software, durante un tiempo se me encasilló en el papel de "experto en GUIs". ¡Qué fácil es ser experto en algo en este país!

La verdad es que experto no era, pero a ojos de las empresas en las que buscaba trabajo sí (que es lo que cuenta). Recuerdo una entrevista para una conocidísima inmobiliaria en que La Prueba consistía en criticar una GUI de un producto propio.  Abordé, con éxito, las siguientes cuestiones que quiero compartir con mis lectores porque son básicas para un buen diseño:

 


1. Simplicidad

El punto óptimo se alcanza cuando la GUI ha sido simplificada al máximo sin reducir un ápice su funcionalidad.

 

El éxito de Google es que es sólo un buscador

El éxito de Google, la simplicidad. Buscador que busca.

 

2. Mantenibilidad

No establecer nunca los elementos de nuestra GUI en posiciones absolutas. Utilizar siempre posiciones relativas o layouts. A ser posible.

 

Poco mantenible
Este es el penoso aspecto que tiene ahora una de mis primeras aplicaciones
en Java, de hace 4 ó 5 años, por no haber usado layouts

 

Tener en cuenta ésto mejora el aspecto de nuestras aplicaciones a lo largo de los años (se adapta a nuevas resoluciones, plataformas, etc.), también permite añadir nuevos elementos a la GUI sin trastocarla. 


3. Distribución

Para los formularios, hacer "uniones lógicas" de campos, esto es que los campos que se encuentren próximos entre sí tengan relación. Idealmente los campos se colocan en el orden de tabulación de izquierda a derecha y de arriba a abajo.

 

Campos bien distribuidos
Campos bien distribuidos. Porción de una aplicación que, junto a
mi antigua empresa, hice para el gobierno de la Generalitat.

Malísima distribución
Una conocidisísma empresa de transporte de paquetería, para la cual me obligaron a trabajar.
¿No seria más claro agrupar dirección-población-provincia? ¿Teléfono-eMail?

 

Continuará...

Usabilidad en las Interfaces Gráficas de Usuario - GUI (II) [Actualización 13/10/2008]

Drupal vs Plone

 

Drupal vs PloneHe tenido la oportunidad de trabajar con ambos sistemas de gestión de contenidos para construir sitios web y me gustaría compartir algunas conclusiones personales.

Ambos son Sistemas de Gestión de Contenidos con licencia GPL, escalables, modulares, con flexibilidad en el uso de plantillas y permisos, de fácil instalación, multiidioma, con soporte a la localización, workflow y con una gran comunidad tras ellos. Plone está basado en lenguaje Python y Drupal en PHP.

Drupal es mucho más reducido en comparación a Plone. La complejidad de este último reside en que se trata de una capa de usuario sobre un poderoso framework, el Content Management Framework CMF, que se ejecuta en el servidor de aplicaciones Zope. Esto convierte a Plone en un sistema tan potente como complejo. 

Contingut sindicat