bodom_lx at task3 dot cc

As promised, Dycapo 0.0.2 is out.

Dycapo will be an open client (mobile)/server system that will improve travel experiences of users in a city. The system will let people to define a destination on their mobile phone. DyCaPo will suggest and arrange trips by either using the Public Transport Service or Carpooling volunteers.
That is, DyCaPo will implement full Dynamic Carpooling functionalities as well as static approaches.

More information and download on the official page.

Here are the release notes and the changes since 0.0.1:

RELEASE NOTES
***************
2010-01-10 Daniel Graziotin 
Dycapo 0.0.2 is just for _showing_out_some_functionalities_ of the system and testing the underlying technologies. Dycapo 0.0.2 incorporates and shows:
* OpenTrip Core adoption and OpenTrip Dynamic data structures proposal (in Django Model format)
* Use of XML-RPC with Django (rpc4django over HTTP and HTTPS)
* (Sort of) integration of Dycapo models with Django and rpc4django
* Authentication
* Insertion of a trip by a driver
* Start of a trip by a driver
* Search of a trip by a rider
* Send a ride request to a driver
* Let the driver accept the ride request
No one exported XML-RPC function will surely be included in the final API! No one exported XML-RPC function is either optimized or completely working!
Code is (somewhat) documented. Expect a completely better work for 0.1.0 

CHANGES SINCE 0.0.1
***************
Some refactoring to make the code cleaner.
Lots of bugs fixed.
Test suite rewritten and (finally) fully working.

models.py:
- added utility methods (i.e. __unicode__ and to_xmlrpc)
- use of OpenTrip id proposal instead of Django id
- addition of fields to Participation model, regarding a ride request and a request accepted

trip.py:
this module has been splitted in four files:
- driver.py - holds all the XML-RPC methods that a Driver needs.
- rider.py - holds all the XML-RPC methods that a Rider needs.
- commin.py - will hold all the XML-RPC methods shared by Rider and Driver
- utils.py - holds some utility functions.

driver.py (formerly trip.py):
- added check_ride_requests(trip) - checks for ride requests
- added accept_ride_request(trip, person) - for accepting a Rider

rider.py (formerly trip.py):
- added request_ride(trip) - sends a ride request to a trip

tests/:
- Cleaner code and better organization
- Added test_all_simple.py - creates a Driver and a Rider with the same destination as target
- test_all.py - creates 3 drivers and 5 riders with random locations as target

Related posts

• Announcing Dycapo 0.0.1 (0)
• Update: first UML diagrams, some implementation thoughts (0)
• Introduction To Software Testing (0)
• Some systems analyzed, thinking about protocols (0)
• Unipoli (0)

I would say that Dycapo-0.0.1 is done and out (there is a PRE-0.0.1 tag on GitHub already). I’m just looking for a server to test it, then I will push it out.

Related posts

• Announcing Dycapo 0.0.2 (1)
• Announcing Dycapo 0.0.1 (0)
• Update: first UML diagrams, some implementation thoughts (0)
• First working method, test client written (0)
• Some systems analyzed, thinking about protocols (0)

Road to 0.0.1 for Dycapo. Today I succesfully wrote a first xml-rpc method accepting OpenTrip Core objects, that inserts a trip chosen by the driver.

def add_trip(trip, mode, source, destination)

Actually, the driver is automatically retrieved by the system, since we are waiting rpc4django 0.1.6 to come out and access User from requests. Moreover, only a source and a destination Locations can be specified.
But it works. It works fine.
The method is located at: server/trip.py
I also wrote a tiny python client to test the remote call, located at: tests.

In a couple of days I should try to publish Dycapo 0.0.1. That’s what I hope

Related posts

• Announcing Dycapo 0.0.2 (1)
• Update: first UML diagrams, some implementation thoughts (0)
• Announcing Dycapo 0.0.1 (0)
• Curriculum (0)
• On the protocol adopted by Dycapo (3)

While searching for solutions on adopting Django for the server side of our Dynamic Car Pooling system, I found two very interesting projects:

• WAPI – a framework which abstracts the details involved in publishing an API and translates class methods to API methods, serializing the objects returned when possible. WAPI handles authentication, too, and other advanced functions. It’s an amazing, fully Django compatible system that currently works over ReST (JSON, XML, YAML) but not with XML-RPC. Therefore, I contacted the author to have some information about the status of the project. It would be very interesting in our system, to provide API and XML-RPC services just by using his layer
• RPC4Django – provides XML-RPC and JSON-RPC support to an existing Django project. It promises a XML-RPC interface by just adding the decorator @rpcmethod to an existing python function. It also fully integrates with Django authentication framework

I’m going to experiment with these two tools. Obviously the first one is the most interesting because of its ability to “export” services in more formats. But the most important protocol for us is missing. Let’s hope it will be added soon!

Related posts

• Update: first UML diagrams, some implementation thoughts (0)
• Change MSN address (0)
• BD-incollo 0.9 is out! (0)
• Announcing Dycapo 0.0.2 (1)
• What is taking me busy – Pomotux! (0)

My third meeting at FBK is about to end. Today we discussed about some use-case, sequence and class diagrams I wrote during the week. Obviously there were lots of changes after the discussion and I will post them as soon as I’ve updated them. For the next time I will take a look at some implementation issues. The client side could be written using Android while for the server side we are seriously looking at Python and Django. It would be very interesting! For the communication, we are reasoning about XML-RPC, SOAP or a personalized Restful API. OpenTrip protocol might not be included in our implementation, as we don’t have the time to parse non-standard XML and adapt the system to use it. But this is not a final decision.
I will also write some simple mockups to test all the possible combinations.

Related posts

• Announcing Dycapo 0.0.2 (1)
• On the automation of API writing and XML-RPC serving for Python Django (0)
• Announcing Dycapo 0.0.1 (0)
• First working method, test client written (0)
• Some systems analyzed, thinking about protocols (0)

BD-review is a dynamic website to allow people to review releases (albums, demos, EPs, singles) of (young, unsigned) music bands. The project is the outcome of the Internet Technologies course at the Faculty of Computer Science of the Free University of Bolzano. The requirements of the project were to build a website using a small subset of JavaEE technologies, without the use of web-frameworks.

A screenshot of a Review

The project is not really meant for production use. It was made as a strong, working and correct base for studying JavaEE academically. It should be useful for every student (also non-student) willing to have an overview on JSP and study it. The code is well-written, uses MVC, and the whole project is documented in detail in a 20+ pages report.

Read more on the project page, download the sources and play with it! Please let me know about your experience with BD-review code.

Related posts

• BD-review (0)
• Projects (0)
• Unipoli (0)
• Introduction To Software Testing (0)
• BD-shell (0)