Desde hace ya algún tiempo estoy haciendo cosillas con el mini-framework webpy y hace poco se me ocurrió que estaría muy bien tener un gestor de contenidos (CMS) modular al estilo de drupal pero usando webpy para que hacer un módulo sea tan simple como definir una función.
Así está la cosa que desde hace un par de días estoy diseñando/implementado un CMS bueno, bonito y barato con python.
De momento tengo implementado el sistema básico de módulos, todavía sin acceso a base de datos, pero cada vez tengo más clara la forma de hacer que quede bien, usable y ampliable.
Para este proyecto me he montado un trac en el que voy a ir añadiendo documentación y tareas y desde donde voy a gestionar todo el proyecto, basta ya de usar forjas de terceros.
Edito: He movido el proyecto a la forja de sugus
Qué tengo ya y qué tengo pensado por el momento
Hoy he terminado la resolución de rutas hacia módulos. Un módulo define una serie de rutas con expresiones regulares 'ruta/(.*)' y cuando tú accedes a '/nombremodulo/ruta/parametro' se llama a la función del módulo determinada pasandole como argumentos los parametros que se definan en la ruta entre parentesis, al estilo de las urls con webpy.
Lo siguiente que tengo planeado es hacer la disposición y plantillas principales, pudiendo así definir zonas como cabecera, panel lateral, zona principal, etc dónde poder definir diferentes módulos a mostrar.
Un poquito más alejado en el tiempo queda la página de administración de módulos, el acceso a la base de datos, el módulo de autenticación, el módulo página/wiki, temas, etc. etc.
Siempre es bueno colaborar en otros proyectos de software libre y más aún cuando el proyecto lo están haciendo compañeros de la asociación SUGUS.
Ya dejaron caer un par de veces Alex y Edulix que al proyecto meshias no le vendría mal un logo, así que una tarde me puse a ello y salió esto:
Ya que estabamos y puesto que este proyecto me pareció interesante estuve mirando un poco el código y también arreglé un pequeño bug por ahí.
Pienso seguir colaborando tanto en este proyecto como en otros que considere interesantes. Y esta es otra muestra más de que este "Concurso Universitario de Software Libre" no va de rivalidad ni de ganar premios, sino de llevar a cabo proyectos y entre todos aprender.
Y por supuesto no he abandonado todavía GECO, aún le quedan un par de detalles para considerarlo como proyecto acabado y espero dedicarle un par de tardes esta semana para que esté terminado para la fase final.
- Hola, quiero ser pintor.
- Ah, muy bien, aquí tenemos muchos pintores y muchas pinturas. Hay mucho que pintar.
- Genial entonces.
- Oiga, ¿aquí solo se pintan paredes?
- Bueno no, también pintamos muros y de vez en cuando pintamos algún grafiti o mural.
- Pero es que lo que yo quiero hacer en la vida es pintar de verdad, no pintar paredes, que está muy bien, pero no es lo que yo quiero hacer.
- Pero hombre, si lo haces muy bien, eres de los que mejor pinta. Además hay muy pocos lienzos y muchos muros, no se puede tener a todo el mundo pintando en lienzo. Ya me gustaría a mi que todos pudieramos pintar lienzos. También tienes que tener en cuenta que en un futuro tendremos más lienzos, pero ahora vas a tener que pintar paredes.
- Pues me encuentro en una tesitura. Puedo perseguir mi objetivo en la vida de ser pintor aunque tenga que pintar con un boli sobre servilletas. O por otra parte puedo continuar pintando paredes durante mis años de mayor creatividad con la esperanza de que en un futuro pueda acceder a pintar lienzos de verdad.
El tiempo corre y cada decisión abre un abanico de infinitas ramas temorales, pero sólo vivirás una, así que decide correctamente y no pierdas el tiempo mirando las ramas que no elegiste.
Cada vez que hago un desarrollo comienzo creando una carpeta y a partir de esa carpeta raíz del proyecto comienzo a generar todo lo necesario para que se pueda ejecutar. Hasta hace bien poco GECO estaba así y se podían ejecutar cada una de sus partes, tanto el servidor como el cliente de forma simple tan solo entrando en el directorio correspondiente y lanzando el script.
Pero cuando comienzas a utilizar un programa de manera más o menos habitual, no es cómodo el tener que entrar en el directorio correspondiente y lanzar el script, para un uso habitual es más conveniente el tener el programa instalado como uno más del sistema. Y esto es lo último que he realizado, un instalador sencillo que te deja todo donde "debe" estar para facilitar el uso.
Python ofrece una forma sencilla de hacer instaladores de módulos y programas, es el conocido módulo distutils. Normalmente los programas en python cuando te los descargas vienen con un fichero setup.py el cual hay que ejecutar para que se instale en el sistema, es una especie de make, pero para python.
¿Cómo crear un fichero setup.py?
El fichero setup.py no es más que un pequeño script en python en el cual tendremos que definir qué queremos que se instale, autor, descripción y otros datos.
Veamoslo con ejemplos:
$sudo python setup.py install
Con este script se puede instalar la librería gecolib que está en el paquete gecoc y el script terminal-geco. La mayoría de las opciones se entienden perfectamente, son datos opcionales que dan información sobre el programa. Las partes importantes en este ejemplo son las opciones scripts y packages. Scripts instala la lista de scripts en /usr/bin y packages instala un paquete python (directorio con __init__.py) en /usr/lib/pythonX.X/site-packages/.
El directorio destino de la instalación se puede cambiar y poner otro en lugar de /usr/, por ejemplo /usr/local/
$sudo python setup.py install --prefix=/usr/local/
Este otro ejemplo es el instaldor de la aplicación de escritorio gtk-geco. En este caso además de instalar un script y el paquete gecoc se instala un módulo python, que es un simple fichero .py y una serie de datos, que se hace con data_files. Con datafiles se puede instalar cualquier tipo de archivo en cualquier ruta del sistema. Si la ruta es relativa se instala a partir de La ruta /usr (o la que se haya especificado), y si la ruta es absoluta se usa esa. La ruta define un directorio y la lista de ficheros siguiente serán los que se copien a dicha ruta.
Facilitando un poco más la instalación
Tengo el código dividido en dos carpetas dentro de src, gecod y gecoc y dentro de gecoc está gtk-geco y web-geco que son dos clientes diferentes. Para facilitar la instalación he creado un script en bash que se encarga de instalar el módulo que deseemos de manera sencilla:
Y con este instalador instalar por ejemplo el cliente de escritorio es tan fácil como ejecutar:
$sudo ./install.sh gtk-geco
Esta semana se han celebrado las "Jornadas sobre conocimiento Libre" en la escuela de informática de la Universidad de Sevilla. Estas jornadas han consistido en dos días, jueves 2 y viernes 3 en los cuales llenos de conferencias sobre conocimiento libre y software libre tratando de exponer todos los puntos de vista posibles para volver a reiterar que el conocimiento nació libre y debería volver a ser libre y sobre todo para aclarar que todo el sistema en el que vivimos de conocimiento privativo y "propiedad intelectual" es algo totalmente inventado.
La importancia de los eventos, charlas y congresos dentro de la universidad
A mí personalmente cada vez me gustan más este tipo de eventos, en los cuales te vuelves a reencontrar con gente conocida, conoces personalmente a gente que sólo conocías de manera virtual, y se comparte conocimiento de manera continua y desinteresada. Yo me he pedido dos días de vacaciones para no perderme nada, ni de la parte organizativa ni tampoco estando como simple asistente.
Para un estudiante centrado en sus estudios este tipo de eventos puede parecerle una perdida de tiempo, sobretodo si tiene alguna entrega de prácticas o quizás un examen, pero en este tipo de eventos se aprende muchísimo más que en cualquier clase, además se hacen amigos que en un futuro te recordarán y te posiblemente te abran el mercado laboral. Así pues, aunque recomiendo siempre asistir a las clases (aunque el profesor sea malo) este tipo de eventos son una gran excepción y considero que no debería haber nada más importante que el tratar de aprender lo máximo posible de de los diferentes ponentes y de toda la gente que se mueve por estos temas.
La mayoría de los ponentes invitados a todos los eventos de esta índole son reconocidos en algún campo y puedes estar seguro de que aprenderás muchísimo tan solo estando al lado de estas personas.
¿Quién monta todo este sarao, quién pone el dinero?
Habrá quien se pregunte de dónde sale el dinero y el esfuerzo necesario para montar este tipo de eventos, y si no te lo has preguntado y no lo sabes, deberías hacerlo.
Hasta donde yo sé y en lo que yo he participado, los organismos que ponen el dinero suelen ser las universidades y organismos universitarios en forma de promoción, infraestructuras y demás. Pero detrás de estos eventos lo de menos es el poco dinero que pueda haber detrás (pago de hoteles para ponentes, viajes, etc), el trabajo realmente duro lo realizan los organizadores y puedo asegurar que no obtienen ningún beneficio económico de este tipo de eventos. La mayoría de los eventos están organizados por asociaciones de estudiantes, profesores universitarios y gente pro-activa en general. Y aunque no lo parezca, aunque no se vea, es un trabajo realmente duro y poco reconocido. Así pues quiero agradecer a toda la gente que hace posible todo este tipo de eventos, tanto las jornadas de conocimiento libre como el mes que viene la fase final del CUSL.
Temática de las Jornadas
El propio nombre dice bastante, estas jornadas se han centrado en el conocimiento y en las formas de distribución del conocimiento, tomando como conocimiento tanto el conocimiento científico como cultural, música, libros, arquitectura, software, etc.
Cabe destacar la gran presentación de Jorge Cortell que nos mostró a todos los presentes de una forma clara que la propiedad intelectual es un invento, que no tiene sentido y que sin embargo está regulada y hay leyes que protegen una cosa que no existe. Por lo tanto es importante pensar en ello y empezar a cuestionarnos esa idea que intentan vendernos, y que mucha gente toma como ley natural de que las ideas tienen un propietario.
Una idea es tuya mientras esté en tú cabeza, una vez que la has comunicado deja de ser tuya para ser de dos o más personas. Tú no pierdes nada, la otra persona gana mucho.
Las ideas, y cuando hablo de ideas hablo de música, pinturas, libros, escritos, etc. no son cuantificables, no se pueden delimitar, no puedes decir esta idea la tengo yo y es mía, si la compartes no puedes obligar a la otra persona a que te devuelva tú idea.
Por supuesto eso no quita que tú sigas siendo el autor de tu idea, eso no se puede quitar por mucho que se comparta o replique una idea. Siempre serás el autor de tus ideas, pero no tienes derecho ninguno para prohibir a otra persona que utilice tu idea.
Hay muchas personas que confunden o quieren confundir cultura con mercado, y la cultura no es un producto, no se puede vender, aunque se hace.
Una vez leí en alguna parte "Cuando oigo a alguien hablar de cultura echo mano a mi cartera". Y esto es así, pero tenemos la oportunidad de cambiarlo con todo esto de internet, y de hecho lo estamos haciendo.
Como conclusión se podría decir que el copyright es un artefacto de monopolio y censura que se inventó a partir de la imprenta y que se ha ido reformando según han ido apareciendo tecnologías nuevas de difusión de cultura, pero no deja de ser un artificio, no deja de intentar poner puertas al campo, porque yo no debería tener la propiedad de ninguna idea desde el mismo momento en el que la comparto con otra persona o simio medio inteligente.
Premios del concurso local de la Universidad de Sevilla del CUSL3
Al final de estas jornadas se han entregado los premios a los proyectos participantes de la Universidad de Sevilla en el CUSL3. Hemos expuesto cuatro proyectos y todos hemos recibido un premio.
Proyecto más educativo: pyrubik
Proyecto más innovador: meshias
Segundo mejor proyecto: unimail
Mejor proyecto: geco
Por parte de la Universidad de Sevilla se inscribieron inicialmente alrededor de 30 proyectos, pero como suele pasar en estos casos al final solo llegan los que realmente tienen un objetivo. Muchas ideas se habrán quedado en el camino y espero que se motiven para futuras ediciones porque es una oportunidad genial para tener una motivación extra a la hora de comenzar o participar en un desarrollo.
Lo más importante del Concurso no es llevarse un premio, sino el camino, lo que se aprende, la gente que conoces, la de errores que cometes durante el desarrollo y de los que aprendes muchísimo, es toda una experiencia que hay que vivir.
Hay que hacer las cosas bien, sino se puede, hay que intentar hacer las cosas bien, si tampoco se puede, hay que hacer las cosas mal, si tampoco pues haces las cosas fatal, pero lo que JAMÁS se debe hacer es no hacer nada, porque en ese momento estas cerrando todos los posibles caminos que llevan al éxito. Es mucho mejor fracasar mil veces que ni siquiera intentarlo, así que valor y al teclado.
Estoy deseando que llegue la fase final del CUSL porque tengo muchísimas ganas de volver a encontrarme con gente que desarrolla porque le gusta, tengo ganas de volver a hablar con gente que sabe muchísimo más que yo para aprender y también con gente que está empezando para poder enseñar. El flujo de conocimiento es el clímax de las relaciones sociales, produce los avances y es lo que nos diferencia como especie de todas las demás. No pongamos barreras al conocimiento, no dejemos morir nuestras ideas.
Hay algo en lo que he pensado en varias ocasiones, y es que a todo el mundo se le ocurren geniales ideas, y ¿a dónde van las ideas que no se cuentan y caen en el olvido? No podemos permitir que ninguna idea se pierda, quizás creas que no tienes tiempo, pero no puedes esperar que el tiempo venga a ti, búscalo y comparte.
Crea, comparte, copia, modifica y distribuye.
Hace ya algún tiempo que hice la interfaz gráfica de GECO y esto lo hice usando glade para generar un fichero xml que posteriormente se carga desde python y se trabaja con los controles. Así se consigue separar la capa de presentación de la lógica del programa y es muy simple cambiar casi cualquier aspecto gráfico sin tener que tocar código.
Para hacer aplicaciones de escritorio con gtk lo más simple es utilizar glade-3, en casi todas las distribuciones hay varios paquetes, glade o glade-2 y glade-3. En las versiones anteriores el editor glade presentaba varias ventanas dispersas, al estilo gimp, pero glade-3 presenta una interfaz unificada y mucho más intuitiva.
Es muy sencillo crear una interfaz con este programa, sólo tienes que ir pinchando en los controles que quieras añadir y se van dibujando sobre la marcha, luego cambias sus propiedades y le das el aspecto visual que prefieras.
La mayoría de los manuales de pygtk y glade indican que hay que hacer lo siguiente para cargar una interfaz creada con glade desde código python:
¿Qué simple verdad? pues en principio no funciona, cuando lo intentas hacer no funciona, a no ser que en el glade le des a guardar como libglade. Esto es porque desde hace algún tiempo, y yo no me había enterado, se utiliza otro formato que es gtkbuilder. Para utilizar interfaces generadas con glade y guardadas como gtkbuilder (que es como debería ser) hay que hacerlo de la siguiente manera:
Como podrás observar no ha cambiado mucho la cosa, solo cambiar get_widget por get_object y poco más.
Una vez cargado un objeto ya se puede trabajar con él, modificándolo, obteniendo información de él, etc. Para conocer todos los métodos y señales disponibles lo mejor es mirar la documentación.
Más facilidades, connect_signals, antiguo autoconnect
Desde glade, además de poner los controles en su sitio y definir los nombres se pueden definir funciones asociadas a los diferentes eventos que el objeto en cuestión pueda recibir. Así podemos evitarnos el tener que enlazar todos los botones con sus correspondientes funciones con el método connect, como se puede ver en los ejemplos anteriores y se pueden enlazar todas las funciones con una serie de funciones o métodos definidos.
Supongamos que tenemos una interfaz con un par de botones y hemos enlazado la señal clicked de cada botón con dos funciones llamadas boton1 y boton2 respectivamente.
Para que estos botones hagan algo, tendríamos un código así:
Si al método connect_signals se le pasa una instancia, buscará el nombre de las funciones en sus métodos, sin embargo también puede recibir un diccionario, y en tal caso, buscará las funciones a enlazar en ese diccionario.
También es posible pasarle argumentos a las funciones, pasándole otro argumento al método connect_signals:
Y con esto y un bizcocho, hacer interfaces gráficas con pygtk y glade es mucho más simple de lo que nunca pudieras imáginar :P
Esta mañana me he levantado con una idea en la cabeza, sería genial: poder importar módulos de una ruta...
Pues bien después de haber pensado en la implementación y todo me ha dado por buscar en la web y da la casualidad de que no soy demasiado original y ya alguien tenía alguna que otra implementación.
He encotrado el módulo urlimport:
http://urlimport.codeshift.net/
Ejemplo de código:
Con esto se podrían ejecutar aplicaciones gtk por ejemplo de manera que el código esté en remoto y nos lo bajemos sólo para ejecutarlo. Así tenemos aplicaciones de escritorio remotas, es lo mismo que pasa con el javascript pero a nivel de python y sin navegador. Y con esto si por ejemplo cambiamos nuestro código no tenemos que ir instalando la nueva versión en cada cliente, sólo en el servidor, sino que la próxima vez que se ejecuten estarán actualizados.
Esto tiene un pequeño fallo de seguridad, y es que si alguien consigue mandarte una respuesta con codigo malicioso podría ejecutar casi cualquier cosa en tu propia máquina.
Por eso me he puesto a modificar un poco el código y le he añadido firma con RSA. Para esto he utilizado un módulo python puro http://stuvel.eu/rsa.
El servidor en el cual está el código tiene una clave pública y otra privada, con la clave privada se cifra el sha256 del código y se incluye tanto el código como el hash firmado en un zip. Por otra parte el cliente se descarga el fichero zip y teniendo la clave pública verifica que el hash que va incluido en el zip es el que se corresponde con el código y además está firmado por el servidor.
Para crear el fichero .zip he utilizado el módulo zipfile y hashlib para generar el hash.
Cosas por hacer
Aún me quedan un par de mejoras que quiero añadirle, además de código python quiero poder ponerle dependencias a los módulos .zip de otros "módulos" pero de datos para por ejemplo poder añadir las imágenes de una aplicación o los ficheros .glade, etc. También quiero estudiar la posibilidad de que los datos como imágenes y los ficheros .glade se los pueda descargar por petición, es decir que se los descargue si intenta cargar un fichero y falla, aunque no tengo mucha confianza en la viabilidad de esta solución.
El código lo estoy versionando en mi repositorio: http://bzr.danigm.net/urlimport/. Quiero hacer que sweetgtk se ejecute así.
Este fin de semana me he puesto a hacer el cliente de escritorio, que ya hacía tiempo que quería meterle mano.
El sábado por la noche tras llegar de jugar a los bolos me senté en mi escritorio y estuve programando a oscuras hasta que el cliente de escritorio tomó forma y fué usable.
Basandome en otros desarrollos que ya tenía, como sweetgtk hice la interfáz lo más simple y usable posible. Es un icono de sistema y al pulsarlo sale una lista con todas nuestras contraseñas. En ese listado aparece el nombre de la contraseña, que es clickable, el tiempo de expiración que está representado por una bolita verde, amarilla o roja y dos botones, uno para editar y otro para borrar.
Si se pulsa sobre el nombre de una contraseña nos pedirá la contraseña maestra (si no la sabe ya) y cuando la introduzcamos se copiará la contraseña al portapapeles, lista para ser pegada. Además el icono se pondrá verde, que quiere decir que recuerda la contraseña. Al pasar diez minutos el icono volverá a estar rojo y si queremos copiar otra contraseña habrá que introducir la contraseña maestra de nuevo.
Al pulsar con el botón derecho sobre el icono aparece un menu desde el cual se puede cerrar el programa, configurar (aún no implementado) y añadir nuevas contraseñas.
La ventana de adición de contraseñas muestra un formulario donde se pueden generar las contraseñas de forma automática y además tiene un indicador de la fortaleza de una contraseña en concreto.
Aún está muy verde el cliente de escritorio, con las configuraciones en código y cosas sin implementar pero con un par de tardes más ya estará completo.
Durante esta semana he realizado un avance bastante grande, si bien quería haber comenzado con el desarrollo del cliente de escritorio, lo he pospuesto para dejar prácticamente listo el cliente web, con toda la funcionalidad que debiera tener.
Así pues esta semana he implementado la posibilidad de exportar todas las contraseñas para después importarlas en otro servidor o como copia de seguridad.
La exportación es un simple volcado de las contraseñas del usuario tal y como se almacenan en la base de datos. Las contraseñas están cifradas, por lo tanto el fichero en teoría es seguro. El formato elegido ha sido lo más simple posible, un fichero de texto en el cual por cada línea hay una contraseña y los campos están separados por barras verticales.
En este proceso he tenido algunos problemas con las codificaciones pero parece que lo he acabado solventando.
La importación funciona a modo de mezcla, comparando por fecha de actualización si una contraseña ya existe, y en tal caso prevalece la que tenga fecha de actualización posterior. En ningún momento se borran contraseñas durante la importación, eso lo dejaré para otro proceso similar que será una importación con preferencia.
Esta nueva funcionalidad la he implementado en los dos clientes que llevo por el momento, que son el cliente de terminal y el cliente web.
Cambios en el cliente web
Para dar soporte a esta funcionalidad he añadido una nueva página al cliente. Esta página es la de "Opciones". Además ya que he creado una nueva página he añadido la funcionalidad de cambiar la contraseña del usuario de GECO y la posibilidad de borrar la cuenta del servidor, que ya estaban implementadas en gecolib y en el cliente de terminal.
Además, dado que tenía que hacer que estas páginas sean accesibles he añadido un pequeño menú.
Por otra parte, había otro tema que tenía pendiente en el cliente web, y es que no controlaba los errores debidamente. Así que hoy he añadido una página de error para que cuando pase algo inesperado no salga un mensaje feo, sino una página más o menos bonita.
Aún así se puede ver que la página está muy bien, pero no muestra nada de información, así que cuando ocurra un error habrá que investigar el por qué desde el lado del servidor y no del cliente :P
Yo sigo a lo mio, aunque no lo parezca. He seguido desarrollando pequeñas cositas del cliente web de GECO. Lo ultimo que me quedaba por desarrollar desde la ultima entrada en el blog era la modificación de contraseñas. Pues bien, eso ya esta hecho, se pueden modificar contraseñas y además le he añadido la posibilidad de mostrar la descripción de esa contraseña.
Por lo tanto podría decir que el cliente web esta terminado, en fase beta. Lo único que le falta es el poder cambiar la contraseña de la cuenta en GECO, poder borrar la cuenta y poder hacer un cambio de contraseña maestra masivo.
Ahora que lo pienso una funcionalidad curiosa seria poner un botón de exportación, que te diera un tar.gz o un zip con todas las contraseñas, cifradas, para poder importarlas en otro servidor GECO o como copia de seguridad.
Pronto comenzare a desarrollar el cliente gtk, que no debe ser nada de complicado porque todo el trabajo esta hecho en gecolib.
Animo a cualquier interesado a programar un cliente en qt, wx, o cualquier otro tipo de interfaz gráfica utilizando gecolib.
