Version 21 (modified by Fran Boon, 13 years ago) ( diff )

potlatch improved

Grace Hopper Celebration Codeathon for Humanity

The Codeathon at GHC2011 is intended to introduce participants to rapid development of FOSS applications in a collective coding setting.

Ready, set, go!

Install the Eden development kit

Instructions for installing from the kit supplied at the event on flash drives are here.

Get an account on Launchpad

If you're in a hurry to get on with things, you can leave this til later, when you're ready to upload something to Launchpad.

  • Sign up for an account on Launchpad -- follow their account setup instructions.
  • You should make your own SSH keys (needed for uploading to Launchpad) -- see the instructions on Launchpad. (For Windows users, PuTTY is recommended as it's much faster to install then Cygwin.)
  • Join the GHC Codeathon team. Look for the "join the team" link.
  • When you have a branch ready to push to launchpad, you can do it without first creating the branch there. This example creates a branch called "work" that is associated with the Sahana Eden project on Launchpad. Say that your Launchpad username is "abcde":
    cd /home/web2py/applications/eden
    bzr push lp:~abcde/sahana-eden/work
  • When the time comes to do a "merge proposal" to get your changes into the team branch, you'll need to change the merge target to the team branch.

The IRC channel

We're going to take over the Eden IRC channel: #sahana-eden on freenode. If you don't already have an IRC client, the easiest way to connect is to use freenode's [ web chat client].

  • To post a message, type in the text box, type Enter.
  • To get someone's attention, type their nick anywhere in your message. (Use sparingly -- this will ring bells / flash lights on their machine.)

It doesn't end at 3pm

The 3pm end of the event is artificial -- you can continue afterward. If you sign up on Launchpad and join the team, you can keep in touch with other team members via Launchpad.

Suggested Codeathon Projects

OpenStreetMap integration

Leveraging the synergy of of OSM's participation...

Potlatch integration

There is already a basic integration of Potlatch (web-based OSM editor) into Sahana Eden (currently, if the system is configured, we have an 'Edit in OpenStreetMap' button on the toolbar in the fullscreen map which opens the relevant area):

This could use:

  • updating to current Potlatch2 code (can we make an easy process for this?)
  • improving the way that the resources are loaded (currently nasty hack to redirect from active to static code, which is very slow, can avoid through a rewrite rule, but better if could just be straight to static)
  • moving the OSM OAuth config from the site-wide to a per-user gis_config setting, including appropriate online help to point users to the right place to get their OAuth details copied-in.
  • configuring the presets for the Humanitarian context (there are some presets here:
  • the current zoom-in is crude, so a zoomed-out area should force the user to draw a BBOX for the zoomed-in area that they wish to work in
  • great if we can have layers in Potlatch configured from the layers in the Map Service Catalogue

OSM Importer UI

A nice further refinement would be to provide a UI to select a BBOX (usually by selecting a location from the hierarchy & using the bounds for that gis_location record) & optional resource-type filter to pull down the .osm file via XAPI

  • Initially this could be manual text box entry of BBOX/filter
  • Then add dropdowns for the Location Hierarchy & filter (which prepopulate the real dropdowns for manual verification/amendment)
  • Then add an option for Map-based BBOX selection

Translations Admin Panel

Use Cases

  • Admin wants to update /languages on their running instance with current version from Pootle
  • Admin wants to be able to do offline translation of main language file(s) (either using native web2py UI or using a PO-based tool like Virtaal)
  • Admin wants to be able to translate additional custom strings in this instance (either using native web2py UI or using a PO-based tool like Virtaal)


  • Add a page to controllers/ to handle Translations.
  • Update the InstallationGuidelines with any new optional requirements (such as translate toolkit).
  • Gracefully give nice error messages if the translate toolkit isn't installed.
  • Update UserGuidelinesLocalisation

Export PO file

  • Dropdown to select which language
  • Button to call web2py2po to convert the .py file to a standard PO file for the user to download

Import PO file

  • Upload Widget which calls po2web2py onaccept to convert a .po file to a Web2Py .py file stored in the languages folder
    • Use the same filename prefix or prompt?
    • Do a merge

Update Pootle

Provide a set of admin scripts (bzr post-commit hook?) to update Pootle with any changed strings as a Merge.

CAP: Common Alerting Protocol

This is the least well defined project, and may be more investigation than coding.

  • Receive CAP messages from an external CAP source.
  • Provide a form for originating CAP messages.
  • Send CAP messages to subscribers, retrying on failure.
  • Write a Facebook app to receive CAP messages and post them on one's wall.

See more here.

SAARAA: Situational Awareness and Rapid Assessment Application

Caution: Getting set up to do Android development is a Whole Separate Thing from the Eden development environment setup. Consider doing the Eden side, and faking the messages from the Android client with (e.g.) curl or RestClient.

This was started as an Android app at !RHoK #3 that allows the user to report on a dangerous situation by filling out a form and uploading an image. That version uploaded data to a very simple Heroku back end.

As a follow-on to that project, allow the app to send to an Eden back end.

  • Add an appropriate model to hold the uploaded situation report.
  • Allow users who have an Eden account to give their username and password. (Current version has no accounts.)
  • Handle receiving uploaded messages from users who don't include a username and password -- provide a code they can use to log in later.
  • Display the messages by category and time.
  • Allow commenting on the messages (e.g. adding updates about handling the messages).
  • Allow sending a message back to the user.
Note: See TracWiki for help on using the wiki.