• Home
  • PFC
  • Computer
  • General
  • Personal
  • Posts RSS
  • Comments RSS
Blue Orange Green Pink Purple

Featured content

¡Ves a http://elfiberhabla.net para seguir mi blog! Esta web ya no es activa!
Showing posts with label PFC. Show all posts
Showing posts with label PFC. Show all posts

Reunión 09/03

  1. Adopción (finalmente) de un test-driven development en el desarrollo del Web Service de Moodle. Primero se hacen los unit tests, y luego se desarrolla. Gracias a esta metodologia, los requisitos del sistema y las funcionalidades que debe tener se definen con bastante seguridad desde el principio.
  2. Me traspasan del desarrollo de módulos al desarrollo más activo, a Core.
  3. Moodle ha decidido que el protocolo de REST que tienen ellos implementado es ineficaz ante ciertos problemas, y se intentará readoptar el protocolo que David y Ferran implementaron hace un año. Tengo que ver cómo podemos realizar esta readaptación y qué cambios puede conllevar a la arquitectura de descripción por PHPDOC. Este cambio significará mejoras como la posibilidad de poder utilizar funciones múltiples.
  4. Debido al cambio anterior, hay que tener cuidado. Las arrays de funciones múltiples no deberían ser asociativas (no deben tener una clave por cada ID de usuario, por ejemplo.
  5. Originalmente, REST funcionaba sólo por POST. La idea es hacer algo más descriptivas las peticiones, y que también se permita el uso de PUT y DELETE en las peticiones HTTP. Hay que modificar el optional_param y required_param para que permitan esto.

También me han sido asignados varias tareas en la wiki:

  1. Petr Skodä ha cambiado el diseño de la base de datos de la wiki. Esto afecta directamente a la migración, y hay que adaptarla a los nuevos cambios para que vuelva a funcionar correctamente.
  2. Efeméride: creando un fichero settings.php dentro de cualquier módulo creas una nueva configuración para ese módulo.
Read More 0 comments | Posted by Davigetto | edit post

Reunión 03/03

Montado servidor git donde subir los archivos desarrollados para el Webservice del foro.

Read More 0 comments | Posted by Davigetto | edit post

Testing de los protocolos WS contra el foro - 02/03

  1. Finalizado testing de permisos del foro y de sus funcionalidades. Todo correcto.
  2. Testing del protocolo REST contra el foro: Éxito. Testing protocolo SOAP y XMLRPC: Fracaso debido a que la capa implementada de estos protocolos por parte de la gente de Moodle no funciona correctamente en carpetas más profundas (en /user funciona, pero en /mod/forum no, por ejemplo).
Read More 0 comments | Posted by Davigetto | edit post

Cambios en la arquitectura del Web Service - 26/02

Cambios en la arquitectura

  1. Sustitución de la array descriptions para describir los parámetros de entrada/salida del WebService, anteriormente definida en la capa external, por PHPDOC, facilitando así tanto la construcción de las descripciones como la documentación de las funciones de cara al desarrollador final.
Read More 0 comments | Posted by Davigetto | edit post

Python y PHPUnit Testing - 17/02

  1. Creación de una aplicación en python para poder probar el Webservice en REST.
  2. Creación de varios Unit Tests para probar el webservice de forma ágil - test de permisos y de funcionalidad de las operaciones implementadas para el foro de Moodle.
Read More 0 comments | Posted by Davigetto | edit post

Interoperabilidad en Moodle 2.0 (15/01 - 27/01)

Una vez terminado mi trabajo para la wiki 2.0 (estuve trabajando en la parte de migración que consistía en migrar las bases de datos de otras wikis como Ewiki o la antigua Nwiki hacia la nueva wiki), ahora he sido redirigido a la última parte del proyecto de final de carrera: Ayudar en el desarrollo de la capa de Interoperabilidad para Moodle 2.0 (más conocido como Web Services).

Cada vez más usuarios y organizaciones utilizan Moodle, y estos cada vez utilizan otras plataformas de acceso, ya sea un móvil, cómo una wii, un iPhone... Esta capa garantizará independencia tecnológica que permitirá a estos dispositivos "hablar" con Moodle, "interoperar". Antes Moodle era una aplicación monolítica y todo funcionaba desde la propia aplicación Moodle.

Esto puede derivar en un amplio abanico de posibilidades: Los desarrolladores podrán crear clientes que puedan interactuar con Moodle.

Ejemplo:

  1. Moodle está hecho en PHP, y el Web Service estará implementado de la misma forma. Y tenemos a la FIB, una facultad que tiene Moodle instalado para sus estudiantes, y (por decir algo) una aplicación de automatrícula hecha en Python, y desearía que, a la vez que se matriculan los estudiantes, se cree un usuario automáticamente, sin necesitar que haya un becario que haga el trabajo de ir creando a los estudiantes en el Moodle uno a uno.
  2. De forma "directa", no puedes hacer que una aplicación escrita en Python se comunique con otra aplicación escrita en PHP. Sin webservices, nuestro objetivo es difícil de conseguir.
  3. Con Web Services podemos conseguirlo. Imaginemos que Moodle dispone de un servicio que es "crear usuario". La aplicación en Python utilizaría ese servicio (transmitiéndole los datos necesarios), y Moodle le contestaría a la aplicación diciéndole si ha habido éxito en la inserción o no, y posibles errores.

Y todo eso, cómo se hace?

Hay varios tipos de protocolos que permiten esto: REST, SOAP, OKI, XML-RPC... De momento, sólamente hay implementado parcialmente REST y SOAP. Estos són los encargados de comunicarse con los clientes. Los clientes mandan la petición en un formato estándar (ya sea en una petición HTTP como en REST, o una petición HTTP + un XML como en SOAP), y el Web Service contesta con un XML con los resultados.

Aquí pongo un esquema de lo que sería la comunicación:

Una vez realizada esta pequeña introducción a los Web Services, pasemos otra vez a Moodle y el trabajo que hay que desarrollar.

En esta capa de Interoperabilidad habrá protocolos REST, SOAP, OKI... cada uno de estos componentes invocará las operaciones de dominio y devolverá resultados. Las operaciones de dominio, por supuesto, serán comunes (se hace una implementación única para todos los protocolos). Estas operaciones que se ponen a disposición del Web Service se conoce como API (application programming interface, un conjunto de operaciones o rutinas que sirven para soportar el desarrollo de aplicaciones).

En este dibujo mostramos cuál será la estructura interna de los WebServices:

  • Estará compuesto por tres capas:
    • la Externa, la Media y la Core. En la externa (ubicada en la carpeta /webservices) se encontrarán los protocolos (REST en /webservices/rest, SOAP en /webservices/soap,...). Esta capa tiene por objetivo analizar la petición del cliente, y llamar la función correspondiente del external.php
    • La capa media está compuesta por varios fichero external.php, un fichero external.php por cada parte de la aplicación (/admin/external.php, /user/external.php, /mod/forum/external.php,...). Estos ficheros se encargan de tratar los parámetros que le llegan de la capa externa y pasarselos a la capa de core.
    • La capa core está compuesta por ficheros api.php, un fichero por cada parte de la aplicación, como en el caso del external.php. Estos ficheros son lo que sería la antigua lib.php, el fichero donde se implementan las funciones para acceder a base de datos o ejecutar diferentes acciones.

Cómo implementaremos esto?

El siguiente esquema explica cual será el funcionamiento básico de una petición:

  1. El protocolo no guarda estado. Esto significa que en cada petición el cliente deberá autentificarse enviando su usuario y su password. Una vez autentificado, el protocolo devolverá un "token", que autentificará al cliente durante toda la petición.
  2. El cliente llama una función concreta del Web Service, enviando el nombre del módulo, función a llamar y parámetros, incluído el token.
  3. El protocolo utiliza el token para verificar que la sesión es válida y activa.
  4. El protocolo llama a la función externa correspondiente, ubicado en el external.php del módulo correspondiente.
  5. La función en external.php comprueba que el usuario realmente está autorizado a realizar dicha acción.
  6. La función externa llama a la correspondiente función en core.
  7. Y el resultado de la función es devuelto al externo, de externo al protocolo, y del protocolo al cliente./li>

Aquí tenemos el diagrama de secuencia que correspondría al ciclo de una petición (almenos en REST, y supongo que será un esquema compartido por todos los protocolos):

La solución de la implementación para el caso de la capa media y de core (la implementación de la capa de protocolo porque depende del protocolo) es la siguiente:

  • external.php:
    • Se usa una convención de nombres para el nombre de las clases: las clases tendrán la terminación "_external", y delante llevarán el nombre del módulo en cuestión. Si se trata de una clase de core (como admin o user) el nombre de la clase sería admin_external o user_external respectivamente, y si es un módulo (como el foro) entonces seria mod_forum_external. Básicamente el nombre depende del Path: por ejemplo, como el external.php del foro se encuentra en /mod/forum, la clase debe llamarse mod_forum_external. Si cambiáramos el nombre de la carpeta, habría que adaptar el nombre de la clase.

      Todo esto es por temas de implementación interna. Recordemos que habíamos dicho anteriormente que la capa de protocolo es la que se encarga de localizar y delegar la petición al external.php correspondiente. Pues la localización del módulo se realiza mediante esta convención de nombres.

    • En la constructora de la clase se definen las operaciones que se deben llamar en una array "descriptions". Por cada operación se definen cuales son los parámetros de entra y de retorno.
    • Las operaciones que se definen en la clase serán todas estáticas, y comprobarán la autorización del usuario, adaptarán los parámetros y llamarán a la función correspondiente de core.
  • api.php:
    • Todas las funciones serán estaticas.
    • El nombre de la clase seguirá la misma convención de nombres que en el caso de la external, pero finalizado en "_api".

En esta página podréis ver código de ejemplo del protocolo REST y del external.php: http://docs.moodle.org/en/Development:Web_services

Enlaces relacionados:

  • Web Services, Moodle API y Listado de funciones
  • Discusión sobre Web Services de Moodle 2.0
  • Blog de los desarrolladores
  • CVS de Moodle
Read More 4 comments | Posted by Davigetto | edit post

Extreme programming methodology: theory and experience

Theory

Extreme programming (XP) is an agile development methodology, based in programming “inside out”. One of its main purposes is to provide flexibility against changing requirements, rapid releases and not much heavy processes not directly related with programming. It follows a Manifesto:


  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

And twelve principles:

  1. Customer satisfaction through early and continuous delivery of valuable software
  2. Welcome changing requeriments, even late in development
  3. Deliver working software frequently (2 weeks - 2 months)
  4. Business people and developers must work together daily
  5. Build projects around motivated individuals
  6. Face-to-face conversation
  7. Working software is the primary measure of progress
  8. Agile processes promote sustainable development
  9. Continuous attention to technical excellence and good design
  10. Simplicity
  11. Self-organizing teams
  12. Regular adaptation to changing circumstances

These ones are shared by all agile development methodologies. Referring more strictly to XP, talking about 4 mainpoints into this methodology is possible:

  • There are four variables to be controlled: Cost, Time, Quality and Scope.
  • Five values to be promoted: Communication, Simplicity, Feedback, Courage and Respect.
  • Five principles that should guide us: Rapid feedback, Assuming simplicity, Incremental changes, Embracing change, Quality work
  • The twelve practises: Planning game, small releases, simple designs, automated testing, continuous integration, refactoring, pair programming, collective ownership, 40-hour week, on-site customer, coding standard, metaphor

Nevertheless, the previous statements are not always true, depends on the team and they don't need to be followed strictly (one of the advantatges of XP is the lack of full strictness against heavyweight programming processes).

These diagrams could be self-explanatories:

As it is said before, XP needs to satisfy customer by early and continuous deliveries. There is a release planning at first. Once all is planned, programmer members do their work, iterating as several times as required. Once the bucle has finished, we have to consider if we have to change something (and replan), or all is OK and can be published. Once a version is published, the project must continue improving, or otherwise the project has ended.

In every iteration (iteration stands for a programming cycle and its acceptance) a little teamwork is defined (not strictly necessary, but highly recommended), and all is programmed and tested. If the code is not accepted nor satisfies the requirements, another iteration is made. Otherwise, the piece of code is tried to be integrated with the rest of the team. If the integration is succesful, the program can be published.

This is the main process in the XP methodology. The practise could be a bit different, but not too much.

As a summary, these two tables explains the differences between an agile methodology and a heavyweight methodology like RUP (where documentation – UML diagrams and other kind of documents made by analizers and designers - is very important in this last one because the teams used to be larger):

Although they are very different processes, an agile process could become a heavyweight development process in time, but it's not the aim of this post covering this.

Practise

Practise is slightly different. In the nwiki process, the process is:

  1. First, there is a customer which needs some requirements which should be satisfied (Moodle 2.0).
  2. Define the tasks in order to satisfy that requirements.
  3. Have continuous reunions with the other teammates, and explain them objectives, purposes, workflow... all things about the project that needs to be developed.
  4. Once all developers have understood the problem and have a minimum idea about de development process (how the project will be done), split the task between them.
  5. Every X time, meet them to see how the state of the work is, changes on requirements, discussing problems, anything else...

Firstly, only a ewiki and old nwiki migration should be done. However, after Moodlemoot event, an ouwiki migration should be done too and ewiki parser will not be longer supported. This changes will be made with less cost than it could be if a heavyweight process was used (a demonstration for the advantatges of XP).

To sum up, a heavyweight programming methodology can be used in clearly defined projects (with an extensive analysis and specification), and projects where there are involved a huge amount of developers, and quality software becomes important. For smaller teams and projects which don't have too much time, Extreme programming could be a methodology to follow.

Read More 1 Comment | Posted by Davigetto | edit post

Part of the migration finished - Documentation

The logical scheme of the nwiki project has changed a bit. The conceptual models of ewiki, nwiki 1.9 and the new nwiki 2.0 are shown below:

In both cases (upgrading from nwiki 1.9 or ewiki) old tables must be saved (renamed as 'old_tablename'). In other versions of nwiki, old tables were transformed only into the new ones. Nevertheless, in this new version we can't do it.

A migration should consider the whole community who will upgrade to the new version of Moodle (and indeed, to the new version of Nwiki). There are from single users to university institutions. The last ones probably have in their databases thousands of entries to migrate (pages, wikis...), and this can be a problem: not only spending too much time migrating from old wikis; server memory could not be enough for such operation, depending on the number of pages.

The solution to this problem is importing wikis and pages dynamically.

Focus on the conceptual model of new nwiki:

  • At least, the wiki table must be migrated in the migrate process (all data can be migrated for this table without problem, and this must be done). Further explanations about this migration process can be found below.
  • There is a “wiki_instances" table. This table contains wiki identifier for an instance and who are the owner/users/groups availables to use this wiki. Filling this page at migration time would be a problem (lots of users, lots of wikis...). So at first, this table will be empty. The table will be filled dynamically in the following way:
    • Every time a user accesses for the first time (after a migration) into a wiki, a wiki_instances tuple will be added into the database.
  • “Wiki_pages” is another problem; thousands and thousands of pages. So this table won't be migrated inmediately into the process, too. Every time any user accesses to a page for the first time since the wiki was migrated, it will be migrated. (And synonyms table if it's necessary). That is why the old wiki tables need to be kept. Wiki pages will be migrated using the old wiki_pages tables (probably they will be empty progressively and when the old wiki_pages table is empty, it will be removed.

This is the mainpoint of the migration process.

Now let's see the Wiki table migration:

You can find the code in mod/wiki/db/upgrade.php in the project.

This file only can upgrade from ewiki or from nwiki 1.9. Otherwise, upgrade will not be completed and you will be notified about the problem and recommended to upgrade to nwiki 1.9 first or reinstalling ewiki.

In both cases, old wiki tables will be renamed and new tables installed. Once this is done, the migration of old tables begins. For the upgrade.php, only wiki table will be migrated (because making a full migration would last too much depending on the number of pages and wikis, reasons were explained above).

The migration of wiki table when upgrading from nwiki 1.9 to nwiki 2.0 is quite simple; most fields match in type and concept, so making the relation between fields is direct.

The migration when upgrading from ewiki to nwiki 2.0 is more complex. Some fields are direct, but others aren't. 'wtype' field from ewiki wiki table which says if students must work in groups (group), by their own (student), or they cannot edit the content (teacher). This field has a close relationship with studentmode field from new nwiki 2.0. Depending on the value of groupmode from course_modules table, studentmode value must be 0, 1 or 2:

  • 0 = students in group, users can work together.
  • 1 = separate students, students work on their own and no one except teacher can see each other work.
  • 2 = students visible, students work on their own, but they can see each other.

When wtype is group or teacher, the students must work together (groupmode attribute from course_modules will separate them, not this one), so the value must be 0. If wtype is students, depending on the groupmode attribute, studentmode will have a value of 1 or 2; if groupmode = 0 or 1(no group) then studentmode = 1. Otherwise studentmode = 2.

Another attribute is htmlmode. This attribute describes if the wiki was edited via html code or ewiki parser. It's rather simple.

Finally, in both cases (ewiki and nwiki), in order to avoid running out of memory in server where there are lots of wikis, wiki tuples are retrieved in packets of 100.

Read More 0 comments | Posted by Davigetto | edit post

Bibliography

  • Moodle Oficial Webpage: http://www.moodle.org/
  • Moodle 1.9 API: http://xref.moodle.org/
  • Meaning of Abstraction: http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29
  • Moodlemoot homepage: http://www.moodlemoot.org/
  • Sakai Project: http://sakaiproject.org/portal
  • Google Web Toolkit homepage: http://code.google.com/webtoolkit/
  • Mahara Webpage: http://www.mahara.org/
  • Tutorials of XML, XSLT...: http://www.w3schools.com
  • PHP Oficial Homepage: http://www.php.net
Read More 0 comments | Posted by Davigetto | edit post

My task: The Migration

Well, this afternoon I've met the rest of Nwiki workers, for discussing about how to divide the work and what programming guidelines we should follow, and how the whole work will be done.

At first, we've discussed about which tools we will use to work. These tools are:

  1. GIT: git is a kind of Control Version System, developed by Linus Torvalds. Over SVN it has the advantatge that maintains two repositories: 1 in the local machine and 1 repository on the Internet, so you make changes in your local, and when you feel good, upload all changes to the Internet server. It's quite similar to use as SVN.
  2. Trac: Trac is a Tracker. For now, we will use it to manage ourselves dividing the work (opening tickets) and notifying bugs. Push the screen to zoom it in.

Once the tools are stablished, now we can begin to work. First, we should follow the Moodle Coding Guidelines and some rules for ourselves:

  1. All functions that we program must begin with wiki_
  2. PHPDoc to all function (all function must be well-documented, description, parameters, return...)
  3. For all, functions we make, we should make a PHPUnit and test it. PHPUnit, in single words, are some test games to throw against the function you did to see if it works correctly or not. They all have a similar syntax. Moodle created their own method for testing PHPUnits instead of using a third-party software.
  4. Not using $_POST[] and $_GET[] variables to get values arriving from an external resource. Instead, we have to use optional_param() function to retrieve the value, either GET or POST.
  5. We have to keep in mind that we have to program HTML pieces of code in XHTML 1.0 Strict
  6. All CSS that we could need to add must be added into styles.php file. Moodle fetchs this file for additional CSS parameters if they are included.
  7. All permission which should be assigned must be located at mod/wiki/db/access.php file.

After that, we've discussed the database structure. This is the overall structure:

We must also document the application architecture. Too, we've mentioned some important files to consider:

  • lib.php -> functions that Moodle calls automatically.
  • locallib.php -> functions for internal use.
  • version.php -> for allowing Moodle to notice a DB upgrade
  • weblib.php -> to print screens
  • languages files
  • export folder -> for exporting methods
  • db folder -> install.xml, upgrade.php...

After all this, I've been assigned to do the Database migration from ewiki and older nwiki version to the new wiki (Probably I have to program the upgrade.php file). Pigui told me that it could take me 2 months (omg!). Let's see the hardeness of my task... Time will tidy things...

Read More 0 comments | Posted by Davigetto | edit post

Training: repair an nwiki bug

Well, as a training, before entering into the Nwiki refactoring project, my project leader asked me for repairing an nwiki bug: http://moodle.org/mod/forum/discuss.php?d=107332

This bug is located (into the module directory of nwiki) into db/upgrade.php. The bug is simply understandable: From the previous version of Nwiki to the new version of Nwiki the "wiki" table changed a bit. One of these changes was modifying the type of 1 field from String to Integer (the evaluation field). The previous developer programmed the type change inside out (with a DML function called change_type_field()). However there is a problem. If the table/field is empty, there isn't any problem. But if the evaluation field was filled previously with an string value, the conversion from string to integer cannot be done, and the upgrade fails.

My task is repair this undesired behavior. The way to do this was:

  1. Create a new auxiliar field for the evaluation field in the wiki table, in order to store there the integer value of the string.
  2. Once this auxiliar field is filled for all table tuples, erase the evaluation field and create a new one with type integer. Once this is done, dump all auxiliar field data to this new evaluation field and erase the auxiliar field.

Having DML and DDL Moodle libraries (a libraries used to update-query-manipulate moodle database) it shouldn't be too much difficult. Actually, it isn't. However I needed to use some special update SQL instruction with a WHERE clause, and I've not found any Moodle function to do such a thing, so I've done it with a function called execute_sql(SQL sentence), where you put as parameter an SQL query, and this query will be executed to the database.

What's the matter? All DBMS does not have the same SQL syntax. Functions provided by Moodle DML libraries solves this problem, but as I said before, I haven't found any upgrade function to use with a WHERE clause.

I hope Pigui will give me some assistance. But all my work will be thrown away with Nwiki refactoring, so Pigui will not spend too much time on this. And for me, I've seen I'm capable of doing it and repair bugs with work. I think I'm ready to do whatever task could be assigned to me.

This afternoon all scolarship holders will have a meeting to discuss the methodology we should follow for developing nwiki to fit with the new Moodle 2.0 architecture (probably available in early 2009). This afternoon I'm going to write a summary of the main clues of my meeting.

I post the code I made in order to repair the bug (it is incomplete and fails, but the main idea is clearly visible):

$table = new XMLDBTable('wiki');
$field = new XMLDBField('evaluation');
$field->setAttributes(XMLDB_TYPE_INTEGER, '3', XMLDB_UNSIGNED, XMLDB_NOTNULL, null, null, null, '0', 'studentdiscussion');

$auxfield = new XMLDBField('evaluation2');
$auxfield->setAttributes(XMLDB_TYPE_INTEGER, '3', XMLDB_UNSIGNED, XMLDB_NOTNULL, null, null, null, '0', 'studentdiscussion');
add_field($table, $auxfield);

/*Substitution*/
$evaluation_values = get_records('wiki','','','','id,evaluation');
foreach ($evaluation_values as $key => $single_value) {
//TODO: let's substitute the evaluation string for the integer value.
//To pigui: Falten el valor dels strings
if ($single_value->evaluation == '') {
$a = 0;
}
else if ($single_value->evaluation == '') {
$a = 1;
}
else {
$a = 2;
}
$quer = 'UPDATE '.$CFG->prefix.'wiki SET evaluation2 = '.$a.' WHERE id = '.$single_value->id;
execute_sql($quer);
}
//Now, drop table evaluation, and recreate it as an Integer field
drop_field($table,$field);
add_field($table, $field);

//Dump all evaluation2 field into new evaluation field
$quer = 'UPDATE '.$CFG->prefix.'wiki SET evaluation = evaluation2';
execute_sql($quer);

//Drop aux field
drop_field($table,$auxfield);
Read More 0 comments | Posted by Davigetto | edit post

Sequence diagram about OpenSyllabus integration in Moodle

Now, I've finished the sequence diagrams. Push "read more" to see the diagrams of each operation I've implemented. All comments and explanations are made into the diagram itself:

  • This is the Main operation:

  • XSLT transformation operation:

  • Zip compression operation:

  • getFileValue operation:

  • The definition() operation in syllabi_import_form class:

Read More 0 comments | Posted by Davigetto | edit post

Class diagram about OpenSyllabus integration in Moodle

Well, I've finished doing the class diagram for the plugin I developed for Moodle:

Explanations

Previously in moodle existed a class called Moodleform. This class is intended to be subclassed, as it works as a template for all forms in Moodle. So I subclassed it in order to make my own form for OpenSyllabus plugin. The functions (all their sequence diagrams will be posted in my next post) I needed to redefine were:

  1. definition(): this operation is called by the constructor and builds the form with the fields you define on it
  2. definition_after_data: for making some validations or instructions after data is submitted.
  3. getFileValue(): this operation retrieves the name of the uploaded file.
  4. validation(): this operation makes some validations before the form is accepted. In my case, as I only had to make a prototype, I redefined it empty.
  5. add_action_buttons(): adds the "submit" and cancel buttons to the form.

As I said, I will provide sequence diagrams later. Once I defined the form, now only we must bind this form to our Main process and the logics of our problem is finished. It's easy to understand, it isn't?

Read More 1 Comment | Posted by Davigetto | edit post

The importance of UML in the software programming world

It is well known that one of my preferred fields in computer enginering world is software enginering. I love read and make UML diagrams, because it is an easier way to understand and make programs than following a methodology properly called "eXtreme Programming" (consists on programming inside out).

Indeed, it's easier understanding a 1-sheet diagram where you see a box with some letters inside and some arrows than "public class TEXT { A b; B a; etc etc;}". Learning process about how a program/project works is done extremely faster. And that is why I prefer reading some UML diagrams than reading code.

However in my PFC, Moodle lacks about a good UML documentation in order to make programmers to work easier. That has disappointed me a bit, because I expected I would apply all my software enginering knowledgement and improve my skill in that field. I made the OpenSyllabus prototype (and learn how to do it) with some file examples of Moodle project.

I will propose to Marc (or Pigui) that in my next work in DFWiki refactoring I want to document in UML all my work (if possible). I feel ready to do it and I've leant some basic PHP, enough to do a good job (and, of course, understood Moodle modules, format course, blocks, thinking about the ID substitution, it should not be too much hard but it requires spending some time...).

My objective about this proposition is having a deeper knowledgement about Software Enginering and working methodology. In order to achieve that, I was preparing my PC to make nice class diagrams and sequence diagrams.

The "Free Software Market" about UML isn't too much good. I've tested some programs and very few ones completed my needs:

  • ArgoUML: It lacks of a very intuitive interface and some basic functionalities that I find vital, and it doesn't allow me to do things in the way I want (bad class diagrams, bad sequence diagrams)
  • Violet: It is not updated to UML2, so I couldn't do some stuff like fragments in sequence diagrams
  • UMLet: It would be really good if it had a simple, but very necessary tool: a ZOOM!
  • BoUML: You can't do constructors in sequence diagrams.

So, after some research, I found 2 programs which fit on my needs:

  • SDedit: Probably the best sequence diagram editor I've ever seen. It is not a WYSIWYG editor like the others, you have to know some easy-to-use code (read the program's help) to make sequence diagrams. You type a simple code, and the diagram is drawn while you're doing that. Once you are used to it, the sequence diagram production speeds up in a considerable way, and the diagrams it makes are really nice.

    As it is not a WYSIWYG program, it introduces us to a new philosophy: Dragging&dropping, mouse moves... it's rather slower than simply typing some short lines with keyboard. I leant this concept and idea, and I find it well-builded in empirical demonstrations. I, for instance, I can make sequence diagrams fastly. With a "drawing" (WYSIWYG) editor I spend more time. I can assure you this.

  • Dia: SDedit is a program that has sense: Sequence diagrams are just this, sequential. They can be builded and all drawn objects can have a fixed position in the diagram and it will be well shown; in class diagrams it's not possible to do that (or it is really harder), because you can position your items and classes in many ways and are all pretty or more understandable.

    I was looking for a program to design class diagrams as I design sequence diagrams in SDedit, by code; nevertheless, for the reasons explained above, I have not find any program such that (or I'm so stupid that I am not able to find it), so I had to give up and use a decent WYSIWYG editor. I found Dia for this, it's a great program, similar to Visio, it allows me to do very nice class diagrams in UML. It is far better than all described above, but by default it doesn't allow to create associative classes (it's not a huge problem but it could be good to have them), and last time I tried it, after forcing a bit the program capabilities, I recived a Segmentation Fault, loosing my time. It was not very happy, but I will give him a new try.

Read More 4 comments | Posted by Davigetto | edit post

Blocks, modules and discovers

Well, today I've been working on how to make 'foo' blocks and modules.

Making blocks has been quite easy because in moodle wiki there is a very well explained page about how to make blocks for Moodle: link to the page. I upload the block I've programmed so anyone can see 'in life' the progress:

Foo block

As you can see, making a block in Moodle it's very easy. But making modules... it's rather harder than blocks. There isn't documentation as good as blocks, and the template they give you it's a bit confusing, specially for the database managing.

While trying to learn how can I program a foo module, I think I've learnt accidentally how I can manage databases in Moodle. For the module, I need to create a database table in one of the files of module, but I don't know where and how... I expect that the following libraries I've found will be useful to me:

In the lib folder of Moodle, there is 2 libraries: ddllib.php and dmllib.php. The first one contains functions to alter the main structure of the database (create and alter tables, for instance). The second one is used to access data (like inserting new rows, retrieve values, delete values, etc).

Let's follow working on it... I've not finished yet :)

Read More 0 comments | Posted by Davigetto | edit post

15th September: Meeting with Marc Alier: the IDea

Well, today I've started classes at UPC again (finally, I just wanted it :D), and after my first class in "Web Application System Design" and looking for my scolarship holder table (OMG, it was an enormous and dirty table, but I've cleaned it; I hope I will find it as clean as I left it tomorrow), I met Marc.

The objective of the meeting was to show him the OpenSyllabus integration in Moodle prototype I made and "look for" more work.

After Marc took a look into my work, he noticed something he didn't like: Lesson outlines (see image) are all wikis (1 wiki per lesson). This was the unique way I found to solve a problem:

  • Marc wanted me to make only 1 wiki, and the lesson outlines were mere links to a wiki page from that wiki. The problem is that links are stored in the Moodle course XML files as static links.
  • These links have a number parameter, the wiki identifier. (For example, ID 10). When restoring a course, moodle assigns a different ID automatically to the new modules of the course, so the wiki will have probably another ID different than 10. But the lesson outline link has the ID 10 as parameter!!! (static link).

So, what can I do now? Well, Marc told me that I have to find the way to change the ID of these links to redirect to the current wiki ID. How can I do this?

As a first requirement, I can make an abstraction:

  1. First, I have to found, in the restoring process, where the new wiki ID is given and restored.
  2. Then, after the piece of code I found before, I have to retrieve the new ID value.
  3. Then, I have to locate the code where the link resources are restored.
  4. Finally, I have to modify every link that will be restored in the previous founded code, retrieving the current link direction, and modifying the id parameter to the previous retrieved ID value from wiki.

I hope it won't be so hard to perform, however Marc's purposes for this piece of work are merely for my own learning and education.

Marc has explained to me that I will work on DFWiki code refactoring (lot of work is coming OMG), so as a training he demanded me to program a "foo" (example) Moodle format course, Moodle module and a Moodle block. This job has priority for me over the "ID" job explained previously.

In Moodle wiki I remember founding something related with that (some module/block/course format templates), so I'm going to take a look immediately.

Ok guys, let's work!

Read More 0 comments | Posted by Davigetto | edit post

Next round: The XSLT part

Once I've programmed the PHP part of the prototype, I had to program the other part of the project: the XSLT file.

Let's go back for a while; the main purpose of the project is, having a syllabi (OpenSyllabus XML course file), I have to make a moodle course automatically according to that syllabi.

Moodle courses can be saved as XML files and be restored with that XML file. With this premise, and knowing that syllabi are also XML files, we can see that we need to transform in some way the syllabi into a Moodle course. The way for doing it is called XSLT (eXtensible StyleSheet Language Tranform).

The process for making the XSL file:

  1. First, having a syllabi example, I've made manually a Moodle course.
  2. Then, I've stored the XML file into my computer to work with it (making a backup of the course). Now, the objective is to transform the syllabi XML file into a Moodle XML course file with the aid of XSLT language.

(in the previous entry of my blog I wrote about the PHP part and his relantionship with XSLT part).

I never did any XSL transformation or programmed a XSL file, and I needed learning some advanced XSL features immediatelly not recommended for a newbie who wants to learn XSL as a hobby :). Also I had to adapt the xsl syntax to moodle, because Moodle needs "special" considerations:

  1. Moodle xml files have very separated parts in the document. However, some parts have a very close relationship, and this relation can only be linked with an Identifier. But this identifier needs to be independent of the XML syllabi, so after some heavy research, the XSL function I needed for this was "generate-id" (this function generates a unique ID for a node, ideal for the lesson bucle).
  2. I didn't know why Moodle, after the point 1 application, gave me errors didn't allow me to create a course. The explanation was that generate-id generates an id like "id7623472". Moodle only reads numbers, not strings!, so I have to discard the "id" string with "substring" xsl function.
  3. In bucles, I needed incremental variables (aka i++ :)). Nevertheless, "variable" xsl element doesn't allow changing his first assigned value (OMG, problem!), because XSL is a declarative language, not a procedural one like C++ or PHP. The first and valid approach I found to solve this problem was the "number" xsl element. In a bucle, it makes something like a counter, from 1 to N being N the number of iterations. I found it a rustic and 'vaste' method, but valid for my purposes :)

After all these ones, and spending some time, finally I've finished the XSL file and it works perfectly. But this XSL file is built over a syllabi prototype, not over a final version, so I will have to modify it a lot when I recive it.

Now, I've finished all my work on OpenSyllabus integration prototype for Moodlemoot for now until "new external requirements" (probably they will arrive soon).

As you can see, in my blog entries I'm writing about XML files and other kind of resources, but I don't put any example to allow you understanding me clearly. Once I finish the project I will upload all those files and will modify all posts adding to them the mentioned ones (or until my teacher tells me that it could be good to upload them while they are in process).

Read More 0 comments | Posted by Davigetto | edit post

Next round: Implementing the OpenSyllabus integration we've though for Moodle

Finally, the requirements for OpenSyllabus integration into Moodle are clearly defined. The main purpose: having a Syllabi (an OpenSyllabus XML file), Moodle has to process this XML file by means of an XSL file, which transforms the original Osyl XML file into a Moodle XML course file, and then process it to have a new Moodle course ready for being used.

However, I only have two more weeks to finish the work (all must be ready soon for Moodlemoot).

The main abstraction (God heavens, I love this word!) is (the main tasks):

  1. Create a new administration option, called 'Import OpenSyllabus course'.
  2. That option will link to a Moodle Form, where the administrator will be able to upload an XML file.
  3. Once the user has selected an Osyl XML file, and he submits it, the file is uploaded.
  4. After that, the uploaded file will be parsed with an XSL parser, who will transform the original XML into another Moodle readable XML course file.
  5. In order to reuse some original Moodle code (concretely the course restoration code) the output XML file needs to be zipped.
  6. Once the file has been zipped, now is the time to invoke the restoration process with the zipped file as parameter.

Until here, all seems to be tidy and clear. Yes, it is. This is the main specification however, I've found some personal problems (the design, how can I made it? how can I implement it?):

  1. I've no idea about PHP (I'm a pure Java developer, I've never touched PHP).
  2. How can I add a new link (which points to the import form) in the Moodle admin block?
  3. How can I create a form for allowing a user to upload a file compatible with Moodle?
  4. How can I retrieve the file? And the name of the file?
  5. How can I store a file into an specific folder in PHP?
  6. How can I process a XML file with an XSL parser with my XSL file to transform it into another XML file in PHP?
  7. How can I zip files in PHP?
  8. How can I reuse the restore implementation?

Well, all these questions have their proper answer. But where can I find the answers and understand them? Afortunately I've already found them, however, it has not been easy:

  • Or I'm stupid and I can't find it, or Moodle lacks of a good developer documentation (such as complete class diagrams, specifications, sequence diagrams, proper explanations...). It only has an API over hundreds of files composing Moodle (omg, finding something has been really hard).
  • I'm tired of searching concrete functions among the API files. Is the Moodle API useful or useless? Can I do my job with brute programming? Or has someone implemented what I need yet?

After some days of desperate study:

  1. PHP is an Object Oriented language, so a port from Java should not be too difficult. PHP is rather different than Java, however it has some similarities (like classes, attributes...), so with some practice, learning PHP should be easier (in fact, I believe I know now PHP and now I can program better than some time ago)
  2. I've found the admin block is implemented in admin/settings. I've located my option link in courses.php file:

    $ADMIN->add('courses', new admin_externalpage('osylimp', get_string('osylimp', 'admin'), $CFG->wwwroot . '/course/osyl.php'));

  3. Moodle has a superclass for forms, called moodleform (located at lib/formslib.php). Using a form example (edit_form.php located in course folder), I've created a new subclass, called syllabi_import_form.

    But the form example doesn't have a field for uploading files. How can I make one? After lot of websearching and coffees, I've found that I can add a line into the definition function of my new class:

    $mform->addElement('file','syllabi', 'XML course file','maxlength="150" size="20"');

    There were lots of similar lines in the document, however, replacing the first parameter with 'file' I've created a field for uploading files.

  4. For retrieving the file value, exists a moodle function for forms: getElementValue. Passing as parameter the name of the file, it will retrieve the value entered by the user. Nevertheless, the value returned by getElementValue for the file field was an array. Arrays in PHP are rather different than Java:

    For expressing an array, in Java we use this expression: namevariable[integer]. In PHP, is something similar, but different. Arrays can be used in many ways, like hash tables, priority queues, stacks... so you can use also strings into the [], and mapping a key to a value in the array. See PHP documentation for further explanation.

    Finally, I could retrieve the name of the file :)

  5. For retrieving the file and store it, Moodle forms have a method for storing into an specific path all files the user wants to upload: "save_files".
  6. There are lots of XSL parser for PHP: the most interesting I found was Sablotron. However, I couldn't get it working, so I've used the built-in XSLT parser (libxslt library). In PHP documentation about XSL I've found some functions to get it working. This is the main procedure:

    $xp = new XSLTProcessor(); //First we create a XSLT process
    $xsl = new DomDocument; //Then, we must load an XSL file
    $xsl->load('../OsylCourse.xsl');

    $xp->importStylesheet($xsl); //After that, we must import the XSL file
    //to the XSLT process
    $xml_doc = new DomDocument; //now we have to load the XML file
    $xml_doc->load($CFG->dataroot.'/3/backupdata/'.$file['name']);
    /*finally, we have to apply the transformation to the document and
    save it to a file*/
    if ($xml_out = $xp->transformToDOC($xml_doc)) {
    $xml_out->save($CFG->dataroot.'/3/backupdata/moodle.xml');
    } else {
    trigger_error('XSL transformation failed.', E_USER_ERROR);
    }
  7. Zipping a file is quite easy:

    $zip = new ZipArchive(); //First we create an instance of a Zip file
    /*Then, with open system call we create a zip file*/
    if ($zip->open($CFG->dataroot.'/3/backupdata/course.zip', ZIPARCHIVE::CREATE)!==TRUE) {
    exit("cannot open");
    }
    //Add as many files as you want (also directories)
    $zip->addFile($CFG->dataroot.'/3/backupdata/moodle.xml', 'moodle.xml');
    //Close the zip file
    $zip->close();

    For further information see PHP Documentation for ZIP.

  8. Reuse the restoration code is easy. Simply pass as a parameter the recently zipped file.

Well, that's all for now. However, there are plenty of bugs. For now, I'm only making a functional prototype for Moodlemoot... Doing things well requires time :)

Read More 0 comments | Posted by Davigetto | edit post

The right way of my project

I've had a nice conversation with Marc last Tuesday. Maybe it has been the most interesting meeting I've had with him. We have defined a good path I must follow (finally!).

From the XML file created in OpenSyllabus (the syllabi file) we will make a port to the Moodle courses. Nevertheless, how can I make this port?

Marc's idea is making a new option for Moodle in Moodle course creation. Now Moodle can make courses from Moodle course backups (these backups are also XML files). So we have to make a new option, called "Import OpenSyllabus course", where the user can select an Osyl XML syllabi and import it into Moodle.

Once imported, this course will have all information the XML syllabi defines.

For achieve that, I will do a simple task: adquire a complete XML file for testing purposes, and manually build a Moodle course with all information I can see in that XML file (wiki's, lessons, title, description...).

Tasks:

  1. Obtain the DTD of Osyl XML syllabi.
  2. Obtain a complete XML syllabi for testing.
  3. Make manually a course with that XML.
  4. Compare the XML backup of that course and the XML file and build a XSLT for transform the Osyl XML into a Moodle readable XML file.
  5. Define the requirements which can be needed for the "import OpenSyllabus course" tool.
Read More 0 comments | Posted by Davigetto | edit post

Mahara e-Portfolio and OpenSyllabus: Fuuuusion-ha?!

Well, until now, I have been talking about OpenSyllabus, their benefits and their objectives, ideas about how me and my partners could integrate it into moodle, how can we use and interpret the XML file that it generates, etc.

I recived a call from Marc telling me that the important question about OpenSyllabus is the idea behind it, not the technology behind it. Also, he told me about Mahara Portfolio, and that he is also interested on it. I should think about how we can integrate into Moodle Mahara Portfolio and OpenSyllabus.

Mahara is a CMS Project developed by Catalyst IT, a brother project of Moodle (they have between them some collaborations). It objective is similar to Moodle and Sakai, create social learning networks and share resources between members (The typical web 2.0). It has a interesting tool, called Portfolio. I will explain it in detail immediately.

Yesterday I invested the whole afternoon in install on my PC Mahara (I followed the guide in the oficial webpage, but it was quite difficult) and make working OpenSyllabus into Eclipse (omg, 3 hours for making it working good!). Regardless, now I have a full working mahara and OpenSyllabus on my PC and I can take a look to code when I want.

After that, I could explore what is Mahara, and what is Portfolio. And O-M-G! It seems to be a nice CMS and Portfolio a nice tool! (I say seems because I have only tested it one day, however I can see interesting uses for myself :D). You know what is a portfolio, right? The typical folder where you store your drafts, currículums, learning resources... Well, Mahara implements something similar:

  • First, it has a complete and interesting user profile (where you can put your personal information, like other CMS systems). Nevertheless, it's different in Mahara. In your profile you can define your own Curriculum Vitae (Certifications, books and publications, education history, employment history), your academic/career goals, and what are your skills. Moodle doesn't have an user profile as great as Mahara.
  • Portfolio allow users to upload files (their notes, pdfs, even source code) in a structured way (in folders). Also it allows creating view pages for every user (blogs, etc...). However, it's bugged for now.

So, Mahara Portfolio is a good tool to allow students having their own Curriculums and notes in a structured and organized way.

Now, How can we integrate Mahara and OpenSyllabus into Moodle once we know what are their advantatges and disadvantatges? I've got some ideas. I write one of them:

  • Modify the Moodle user profile to make it equal to Mahara user profile and Portfolio. With a good user profile, users and students would be engaged in organizing their notes and their curriculums, sharing them among other students. This will improve their learning experience and their learning performance.
  • Add/embed OpenSyllabus to Moodle for creating easy and uniform syllabi, and allow teachers to create courses in a very easy way. This would improve the organization of courses and their upgrading.

Well, in 21th I'm talking with Marc and Pigui about all of these.

Hey, I'm really enjoying this project! :D

PD: I attach two screens about Mahara profile and portfolio.

Read More 0 comments | Posted by Davigetto | edit post
Older Posts Home

The FIBer Talks

  • About
      I'm using this blog as logbook for my PFC
  • facebook

    Facebook

    Who is Davigetto?

    My photo
    Davigetto
    View my complete profile

    Blog Archive

    • ▼  2009 (7)
      • ▼  May (1)
        • Nos trasladamos a un Wordpress!
      • ►  March (3)
      • ►  February (2)
      • ►  January (1)
    • ►  2008 (37)
      • ►  December (1)
      • ►  October (6)
      • ►  September (7)
      • ►  August (2)
      • ►  July (7)
      • ►  June (7)
      • ►  May (4)
      • ►  February (3)
    • ►  2007 (12)
      • ►  December (1)
      • ►  September (1)
      • ►  August (2)
      • ►  July (2)
      • ►  June (3)
      • ►  March (3)

    Labels

    • Computer (8)
    • database (1)
    • Diary Life (1)
    • General (6)
    • Information Systems (1)
    • Me quejo (2)
    • Miscelanea (1)
    • moodle (4)
    • opensyllabus (1)
    • Personal (7)
    • PFC (26)
    • php (2)
    • Poetry (6)
    • restore (1)
    • Testing (1)
    • Web (1)
    • xml (1)
    • xslt (2)
    • zip (1)

    Last Comments

    Loading...




    • Home
    • Posts RSS
    • Comments RSS
    • PFC

    © Copyright El FIBer Habla. All rights reserved.

    Back to Top