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

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!

Both the Wiki and the blog has been set up. Tomorrow I'm going to have the first official meeting at FBK to discuss my first results.
I've just finished the grid containing a short description that each paper proposed as a solution (or suggest) for the areas:

• System Suggestions
• Interface Design
• Algorithms
• Coordination
• Trustiness
• Safety/Reputation Systems
• Social Aspects
• Chicken-Eggs problem
• Incentives

The WIKI is located at the following URL: http://www.opensocialcapital.com/dynamic_carpooling/wiki/
The Blog, which currently takes the RSS of the category carpooling-research of my blog, is located at: http://www.opensocialcapital.com/dynamic_carpooling/wiki/.
I will fill the Wiki as soon as I have the time to do it, I promise.

After the study of pointers versus references, the second natural question that comes in head of a ex Java developer turning to C++ is:

"What are the difference between static and dynamic memory allocation in C++?"

which can be translated as:

"When should I use the stack and when do I have to use the heap in C++?"

that can be further simplified to:

"When should I use the new operator in C++?"

I could simply summarize the answer to: "Use stack when possible", but I think that this time there is the need of more explanations. Let's have the following model for a process in the system:

A simplified model for a process

I'm not really interested in an real representation of a process (see Modern Operating Systems by A. S. Tanenbaum for a very good explanation on processes), but focus on the stack and on the heap.
In reality the heap is a software abstraction but you can also imagine it like the stack.
In C++ programs there are also several other memory areas in which objects and non-object values may be stored (see this article on GotW for further details).

Why then choose between stack or heap? Quoting my publication on object-oriented memory management in Java:

Stack-based variables have their extent determined by their scope, so the former is constrained by the structure of the code at compile-time .

Sometimes there is a need for the variables with unconstrained extent in order to cope with
problems where lifetime of a variable can only be known at run-time.
In this case heap-based variables, whose extent is strictly under control of the programmer, are used. [..]

I promise that I will update my 17 pages about OO-memory management to cover also C++ by the end of June. By the way, following some forums, wikipedia, my publication and GotW, I also summarized pros and cons of stack and heap use in C++:

Update 2009-07-03
After 4 months of heavy GUI and Database C++ programming, here are my thoughts: if you are planning to write a program with something more than a couple of objects interacting, using associations and therefore, objects as attributes, use the heap. Every serious program, even if not really big, uses heap for object allocation. Just take care to delete the objects when you don't need them anymore. Objects on the heap are dynamically allocated and it is more comfortable to pass them through other objects using pointers. The use of the heap assures the live of objects even if the method that generated them runs out of scope ( =dies ). If you also plan to write GUIs, solid toolkits like QT recommend the use of heap to create graphical objects.

In some Operating Systems, stack is also very limited while heap is usually not.

Here are listed the sources I used for writing this article:

• http://www.velocityreviews.com/forums/t278261-stack-vs-heap.html
• http://www.computing.net/answers/programming/stackheap-c/2293.html
• http://www.codeguru.com/forum/showthread.php?p=1186307#post1186307
• http://www.codeguru.com/forum/showthread.php?t=350945
• http://www.gotw.ca/gotw/009.htm
• http://en.wikipedia.org/wiki/Process_(computing)#Representation
• http://task3.cc/object-oriented-memory-management/

Hope that this article helped you to clearly understand the differences between stack and heap allocation in C++, write me if there are other issues or you need more explanations!

As I promised about 4 hours ago, here is my introduction to Hyper Text Transfer Protocol in form of a mind map.
It is to be intended as a really short introduction to this protocol. Like the previous one about computer networks, the mindmap summarizes materials copyrighted by Tanenbaum and also material taken from Wikipedia.

The topics covered are:

• Scope of the protocol
• HTTP connection
  • HTTP/1.0
  • HTTP/1.1
• HTTP request methods:
  • GET
  • HEAD
  • PUT
  • POST
  • DELETE
  • TRACE
  • CONNECT
  • OPTIONS
• Message Headers
  • Request Headers - all
  • Response Headers - all
• Status Codes:
  • 1xx Information
  • 2xx Success
  • 3xx Redirection
  • 4xx Client error
  • 5xx Server Error
• Sessions:
  • Cookies
  • Server-Side sessions
• Secure HTTP - HTTPS:
  • By URI scheme
  • HTTP Upgrade Header
  • SSL/TLS

You can browse an HTML version online.

You can download:

• Mindmap source file (Freemind)
• An export in PDF format
• An export in PNG format

As always, you are free and encouraged to contact me in case of errors or anything else.
Hope you like it!

As I promised, BD-incollo 0.1 is finished and the source code is available in the project page under the GPL 3 license.
Every MUST requirement has been done and just two MAY requirements could not be developed in just 6 days. But They will surely be in the next releases.
Sourcecode is well commented using xP standards and there are few comments where necessary, but is should be clear. If not, drop me a mail.
I will write a map that describes the source code tree tomorrow!
The conclusions of this experiment are that Django is really a web framework for perfectionists with deadlines! I spent more time playing with templates and CSS than with the whole python coding! It's a valid alternative to Ruby on Rails, and built on a programming language I really like.
Go and grab the code!