Makahiki Configuration

Building on last week's Makahiki installation, this week I played around with some common configuration tasks. Below are the steps I completed. The section numbers given in parentheses correspond to the Makahiki docs found here.

0. Update your Heroku Makahiki instance (2.1.1.2.11)

I added the AWS credentials environment variables to the project's activate file in ~/.virtualenvs folder first. You should also add the MAKAHIKI_ADMIN_INFO here too. Uploading took 5 minutes or so.

I noticed this line in the output:

Environment variable MAKAHIKI_DATABASE_URL not defined. Exiting.

It didn't seem to cause any later problems though.

1. Getting to the challenge design page (2.3.2 / 2.2.1.1)

I couldn't get to the /account/login page at first. This took me 20 minutes to debug, and I reinitialized the Heroku instance during the process. It turned out I had just mistyped "account". <sigh>

2. Design the global settings (2.3.3.1)

I changed the Name and Logo settings as a test.

3. Design the teams (2.3.4.2)

I added a new Lehua-C team as part of the existing Lehua Group.

4. Set up users (2.3.4.3)

I could create new users, but I could not login normally using their accounts. It was possible to login as them from the admin's account, though. It turns out this was due to having mixed-case usernames, so make your usernames all lowercase.

5. Specify the games to appear in your challenge (2.3.6.1)

I disabled the "Drop Down" water game.

6. Learn about how to design the resource goal games (2.3.6.2.1)

This step just involves learning about the system and the design goals behind it.

6.1. Configure the Energy Goal Game for your new team

I switched the Lehua-C team to using manually-gathered energy data.

7. Learn about how to design Smart Grid Games (2.3.6.3)

This is another learning-about-the-system step, but it's important for the next few sub-steps.

7.0. Design on paper

Or at least mentally sketch out the next level your want to create in the Smart Grid Game.

7.1. Create a Level

I create a new Level 4 that unlocks once the user has completed a couple Level 2 tasks.

7.2. Create a new Activity action

I created an activity involving airship research.

7.3 Create a new Event action

I created an excursion to the helium fields.

7.4 Create a new Commitment action

I created a commitment to hold one's breath while passing a graveyard.

7.5 Finalize the grid

I edited the existing car-pool activity and added it to my level. (I was careful to select an activity that wasn't assigned to a category or level yet.)

Although I tested each of these sub-steps as admin along the way, I ran through the tests again with a different user.

8. Design the Top Score Game (2.3.6.4)

I created a new prize.

9. Design the Raffle Game (2.3.6.5)

I created a teddy bear raffle prize and tested it.

10. Design the Badge Game Mechanics (2.3.6.8)

I created a badge and earned it.

11. Manage Action submissions (2.4.2.2.1)

I approved and rejected a few activity responses that I generated during the earlier tests.

Overall, I found Makahiki to be a fairly polished and complete system. The most challenging parts of this proved to be my own mistakes (mistyping the URL) or undocumented requirements (such that the usernames need to be all lowercase). My general impression, though, is that Makahiki design and management is a rather long and tedious affair. I tried to create some slightly amusing activities to stay engaged with the process, but I'm still glad I'm done with this exercise.

Remote Makahiki Installation: A Reader's Guide

After installing Makahiki locally, it's time to try deploying it to Heroku. Once again, I'm following the user manual's instructions for this with a report of how each step went.

2.1.1.2.1. Install Heroku

Already installed.

2.1.1.2.2. Add your SSH keys to Heroku

Already done from an earlier project.

2.1.1.2.3. Verifying your Heroku account

Grudgingly done. I didn't really want to hand out my credit card for this.

2.1.1.2.4. Setup Amazon S3

Grudgingly done. (Later, in Step 9, I learned I should have selected US Standard as the region for my bucket.)

2.1.1.2.5. Setup environment variables

As instructed, though I changed the admin password.

2.1.1.2.6. Download the Makahiki source

Skipped this step, since I still have it from the local installation.

2.1.1.2.7. Initialize Makahiki

This was probably unnecessary, but: I wasn't sure if this initialization would mess up my existing local installation. I created a new virtualenv with mkvirtualenv makahiki-heroku.

In the next step, I realized I also needed to run pip install -r requirements.txt at this point.

The upload process took about 20 minutes or so.

2.1.1.2.8. Start the server

Everything loaded fine, but the pages lacked style and images. I checked my S3 bucket and it was empty. Trying again, I found this in the output:

Do you wish to continue (Y/n)? Y
resetting the db...
Resetting HEROKU_POSTGRESQL_RED_URL (DATABASE_URL)... done
syncing and migrating db...
Running `python makahiki/manage.py syncdb --noinput --migrate --verbosity 0` 
attached to terminal... up, run.4074
collecting static and media files...
Traceback (most recent call last):
  File "/home/ztomasze/makahiki/makahiki/manage.py", line 9, in <module>
    from django.core.management import execute_from_command_line
ImportError: No module named django.core.management
s3put -q -a AKIAJC76TME6N23PKRMA -s [...omitted...] -b ztomasze-makahiki 
 -g public-read -p `pwd` media
sh: 1: s3put: not found
s3put -q -a AKIAJC76TME6N23PKRMA -s [...omitted...] -b ztomasze-makahiki 
 -g public-read -p `pwd`/site_media site_media/static
sh: 1: s3put: not found
loading base data...

Both django.core and the s3put commands seem to be missing. I remembered that I had created a new virtualenv, so I ran pip install -r requirements.txt and tried again. Problem solved.

2.1.1.2.9. Verify that Makahiki is running

The links to images and stylesheets were still failing, even though the files were now in place on S3.

As an example, in the source code of the main page, the logo gif had this URL: https://s3.amazonaws.com/ztomasze-makahiki/static/images/old-logo.png

Accessing this URL directly got me this error message:

<Error>
<Code>PermanentRedirect</Code>
<Message>
The bucket you are attempting to access must be addressed using 
the specified endpoint.  Please send all future requests to this 
endpoint.
</Message>
[...snip...]
<Endpoint>ztomasze-makahiki.s3.amazonaws.com</Endpoint>
</Error>

And indeed, accessing https://ztomasze-makahiki.s3.amazonaws.com/static/images/old-logo.png instead worked fine.

Feedback from Yongwen, the current Makahiki admin, suggested that this URL difference is due to which region you select when creating the S3 bucket. I originally went with S3's suggestion of Oregon, but apparently US Standard gives you the URLs assumed by Makahiki. To try this, I deleted and tried to recreate my bucket. There was a temporary name conflict, so I had to choose a different bucket name. I updated the MAKAHIKI_AWS_STORAGE_BUCKET_NAME environment variable and reinitialized Makahiki (step 7).

It looks like everything now works.

Conclusion: Total Time: 3 hours. This was longer than the local install, although there were fewer steps. This time difference was mainly due to waiting for downloads and uploads. Overall, this process was about as painful as any Heroku deployment, though each one gets easier with more practice.

Local Makahiki Installation: A Reader's Guide

Today I worked through the installation of the Makahiki energy competition platform, as documented here. This is a record of how each step went for me. YMMV.

2.1.1.1.1.1. Hardware requirements

Running on Debian 7 in a VirtualBox with 2GB of RAM (on Windows 7), as described earlier. Apparently I could have just grabbed a large VirtualBox image and worked from there. Instead, I followed the step-by-step Unix instructions within my existing system.

2.1.1.1.1.2. Install Python

I checked the version: already installed.

2.1.1.1.1.3. Install C Compiler

I checked the version: already installed.

2.1.1.1.1.4. Install Git

I checked the version: already installed.

2.1.1.1.1.5. Install Pip

I checked the version: already installed.

2.1.1.1.1.6. Install Virtual Environment Wrapper

Followed instructions. As root: pip install virtualenvwrapper

I initially moved on at this point, but I later found that workon did not work. Don't forget to setup up your shell startup file as instructed. I chose to go with lazy initialization, and I changed PROJECT_HOME to just $HOME, since that's where I've been putting my projects so far.

2.1.1.1.1.7. Install Python Imaging Library

As instructed, I used apt-get to install python-imaging and libjpeg-dev. (I already had python-dev.) I also had to set up the symlinks as instructed.

2.1.1.1.1.8. Install PostgreSQL

PostgreSQL was already installed, but I did need to edit pg_hba.conf as instructed. The full path to this file was: /etc/postgresql/9.1/main/pg_hba.conf

2.1.1.1.1.9. Install Memcache

As instructed, I used apt-get to install memcached and libmemcached-dev.

2.1.1.1.1.10. Download the Makahiki source

As instructed.

2.1.1.1.1.11. Workon makahiki

Once I fixed the part I accidentally skipped in step 6, this worked fine.

2.1.1.1.1.12. Install required packages

As instructed. The download and install took a while (5 minutes) with a lot of output and warnings, but no errors.

2.1.1.1.1.13. Setup environment variables

As instructed. I added the configuration to the end of ~/.virtualenvs/makahiki/bin/postactivate. If you copy-and-paste, don't forget to remove the % signs. I also reused my existing PostgreSQL user, django. (This may or may not be a good idea, so I don't necessarily recommend it. It worked fine for me, though.) Once I wrote these to the config file, I typed deactive and then workon makahiki to refresh the settings.

2.1.1.1.1.14. Initialize Makahiki

As instructed.

2.1.1.1.1.15. Start the server

As instructed. Both servers worked for me.

2.1.1.1.1.16. Verify that Makahiki is running

Yay, it runs!

Conclusion: This process is fairly easy as long as you go carefully and don't miss a step. It is less difficult than installing the Django toolchain for Heroku, though you would need to make it through much of that process first if you want to deploy Makahiki to Heroku.

Total Time: 2.5 hours, including the time taken to document the process here. Probably only 1.5 hours or so if you were just following the directions.

Kukui Cup: A Taste of Gamification

I spent this past week playing a demo run of the Kukui Cup competition. This is an online educational "game" normally run for UH undergrads living in the dorms. It intends to teach participants about current energy issues and promote new energy conservation habits.

The primary form of interaction in the Kukui Cup is completing "Get Nutz" tasks. These tasks include watching educational videos and answering a short question about each one; commiting to a daily habit such as turning off lights when you leave a room; and field-trip activites. Completing each task earns you points that you can apply to a raffle to win prizes. In the real competition, real-time energy use of the dorms would also play a role.

It was interesting to see some recent views on gamification embodied in the mechanics of the Kukui Cup. Jane McGonigal proposes that gamification could be used to harness the energy people devote to games to affect positive change in the real-world. The Kukui Cup seems founded on that principle: that the habits and knowledge gained during the course of the game will continue to influence people afterward.

Tadhg Kelly suggests that gamification really boils down to three mechanics: social validation, completion, and prizes. The Kukui Cup uses all of these. You can see your ranking compared to others, and you are encouraged to advertise your participation through social media and on your dorm-room door. The Get Nutz layout makes it very clear what tasks are available to you and how far you've progressed through them, which gives a sense of completion. The points you earn are all given a real-world value by letting you use them to buy tickets for raffle prizes.

It is less clear to me whether the Kukui Cup contains the three ingredients that Sebastian Deterding claims are missing from most gamification efforts: meaning, mastery, and autonomy. When you strip away the game mechanics of the Kukui Cup, there is not much content left behind that is inherently meaningful to users. That is, the game needs to assume that user have an existing motivation to learn about energy and compete with their peers to conserve it; the game then provides a fun way to do so. There is no real skill that you improve by playing the Kukui Cup, although the way that Get Nutz is broken down into levels that need to be unlocked does give a sense of improvement over time. Finally, the Kukui Cup offers users a fair amount of autonomy in choosing which tasks to complete and habits to cultivate, but users are not able to propose new activities or incorporate goals of their own design into the game.

I also gathered a few practical design tips from playing the Kukui Cup. I found the steady stream of points to be almost motivation in themselves, though giving them a real value through the raffle system was also fun. It was nice to be in the running to win something even if I wasn't close to the top player's ranking. The task-unlocking system was also motivating; it felt a bit like leveling-up in an RPG. The need to check back in every day in order to claim the points for yesterday's habits was a very slick way to keep people logging in. That said, it was fairly easy to cheat on the habits, and sometimes it was unclear whether I adhered to the rule or not. For example, if I promised to do only full loads of laundry, but I didn't do laundry at all today, did I still fulfill my promise?

On the downside, the constant pressure to advertise what I had done on Facebook was a bit annoying, as were the constant requests for feedback. Because of these, it took 3 or 4 clicks to complete a task when it seemed like it should have only taken 2 or 3. Also, if the review questions for the short videos were multiple-choice or matching rather than short answer, their scoring could be automated. This would eliminate the delay in earning points and save someone a few hours "grading" time.

Overall, I found the Kukui Cup a solid example of gamification. It's always nice to explore some concrete examples of theoretical concepts.

Django on Heroku: Revisited

Last week, I spent quite a while getting a simple "Hello World" Django app in place on Heroku. This week, I wanted to see if I could repeat the process by posting a small working demo project. Things went much more smoothly this time around.

I used git to grab a local clone of the project. I used virtualenv to setup a virtual environment and pip to load that environment with the project's requirements.

I created a local PostgreSQL database so I could test things locally. I remembered to set the DATABASE_URL environmental variable and to sync Django with the new database. I debated on whether I needed to run python manage.py collectstatic in order to move the website's static files (such as scripts and stylesheets), but the site ran fine locally as-is without it.

Since everything seemed to work fine locally, it was time to push to Heroku. I double-checked that .gitignore was in place with venv and *.pyc in it. When I ran git add . I realized that I'd done all of this testing without touching a single project file. That's a neat design.

I created a new heroku app and used git to push the files to heroku. I initially forgot to sync the database on Heroku's end, but the resulting error message was obvious and it only took a minute to correct. To make sure everything really worked, I used Django's default admin interface to add some database contents (a poll with 4 possible answers). Everything seems to be running fine.

Given the light expected traffic, I didn't bother to switch out the default Django server for gunicorn.

All of this took me about 1 hour, compared to last week's 20 hours. Now that I've got this down, maybe Heroku isn't so bad after all!

Django on Heroku: A Reader's Companion

I recently setup a fresh VirtualBox Debian Linux system. Within that context, I then walked through the Heroku tutorial on Getting Started with Django on Heroku. I ran into a number of errors along the way. Most of them took a few minutes (or an hour) of surfing to find a solution. If you've found this page, perhaps you hit one of those same error messages, and so my solutions will save you a little time.

I'll follow the sections of the current Django on Heroku tutorial here and just add the errors and solutions I encountered.

Prerequisites

There are a bunch of different Python installers out there: pip, distribute, setuptools, easy_install, etc. You'll need both pip and virtualenv... but virtualenv is listed specifically as a prereq at the start of the tutorial. According to the virtualenv page, the preferred way to get virtualenv is to use pip... but the best way to get pip is to use virtualenv. To resolve this, I decided to install pip globally... but pip requires distribute. Of course, the easiest way to get distribute is to use pip to install it (haha!)... but there is also this option where you use curl (or wget) to download an installation script. Once you have distribute, you can do something similar for pip.

Start a Django app inside a Virtualenv

It turns out the virtual environment needs a few things installed locally too...

Error: pg_config executable not found.

You need the postgresql package installed. (Use apt-get install postgresql to install it.)

Error: You need to install postgresql-server-dev-X.Y for building a server-side
extension or libpq-dev for building a client-side application.

Okay, so you also need the postgresql-server-dev-9.1 package (currently).

In file included from psycopg/psycopgmodule.c:27:0:
./psycopg/psycopg.h:30:20: fatal error: Python.h: No such file or directory
compilation terminated.

And the python-dev package too.

Hooray! At this point, I could get a Python app created in the virtualenv and run it. Things seemed downhill for me from here until...

Deploy to Heroku

Typing heroku create gave me:

!    Heroku client internal error.
getaddrinfo: Name or service not known (SocketError)

This error was coming from the excon gem. heroku login gave me the same error. Turns out I had a DNS problem. I entered 8.8.8.8 (Google's public DNS server) into /etc/resolve.conf and tried it again. Worked.

Then git push heroku master lead to:

Permission denied (publickey).
fatal: The remote end hung up unexpectedly

I needed to generate a public key with: ssh-keygen -t rsa By default, this puts the key into ~/.ssh/id_rsa.pub. You then need to register it with Heroku: heroku keys:add ~/.ssh/id_rsa.pub

At this point, I could execute the basic Django app both locally (with foreman start) and on Heroku.

Although my app wasn't actually using the database, I figured I'd better try syncing with it anyway...

Syncing the database

I wanted to run it locally first, so I needed to setup a local postgreSQL database. (The tips on the assignment page were very helpful here.) Also, you need to be postgre user in order to execute the psql command that starts the PostgreSQL console. (It took me a while to even track that command down.) So:

root@tinkVr:~# su postgres
postgres@tinkVr:/root$ psql
could not change directory to "/root"
psql (9.1.8)
Type "help" for help.

postgres=# CREATE USER django WITH CREATEDB PASSWORD 'djangoapp';
CREATE ROLE
postgres=# CREATE DATABASE a17 OWNER django;
CREATE DATABASE
postgres=# \q

You'll probably want to change the lowercase details (user, password, and database names) to something else. Note that you do not need to update your Django project's settings.py with these details because dj_database_url will pull these from from the DATABASE_URL environment variable. (If you log into Heroku's web interface and check your database settings, you can see what these values will actually be in the Heroku environment.) However, to run locally, you do need to set this variable appropriately. In my case, this translates to:

export DATABASE_URL=postgres://django:djangoapp@localhost/a17

typed at the command prompt.

At this point, I could successfully run python manage.py syncdb locally. However, heroku run python manage.py syncdb lead to a timeout. This happened even when just trying to open a simple shell on Heroku with heroku run bash. Heroku does offer some troubeshooting on this. It turns out port 5000 was being blocked by my ISP (the wired network in the Computer Science department on campus). I switched to the public UH wireless and I was able to connect.

The rest of tutorial went smoothly for me. (pip installs gunicorn for you.) Hopefully it goes smoothly for you too!

Next up: Fleshing out the Django app to actually do something...

Debian 7 on a VirtualBox

I'm currently taking a class on serious games. We've already covered Django and the nature of gamification. This week we are trying to deploy a simple Django project to Heroku, a cloud-based app hosting service. This proved fairly difficult, requiring that we get a long toolchain in place. (Details of that process to follow.)

This toolchain requires running scripts that download and install other required components. Whenever you're missing something, you get error messages that look like this:

  building 'psycopg2._psycopg' extension
  error: Unable to find vcvarsall.bat

You then have to figure out why you don't have vcvarsall.bat, or why it's not in the right place, and what you need to do to fix it.

Other students in the class reported that, since most of the required tools assume a unix-like environment, trying to get everything configured in Windows seemed to lead to even more problems. Also, project dependency managers like Ivy or pip always make me a little nervous. I don't really like the idea of downloading some dude's script from GitHub, running it, and having it download other arbitrary code from various points around the web and freely executing it all on my machine.

Given this context, I decided to create a Linux environment to work in. While I've dual-booted on a number of different machines before, I decided to try a virtual machine this time. There are a lot of advantages to this:

• No need to mess with your current partition configuration.
• Your can run the virtualized OS in a window, switching back and forth between the environments, even copying clipboard and file data between them.
• You can pause and save a running instance. (I've already used this feature: I paused a lengthy compilation/installation process so I could shutdown the real machine and then resumed everything again in the morning.)
• You can take a snapshot of the whole machine as a backup, which can be especially handy before you make any significant OS changes.
• You can copy the entire virtual OS environment to another machine. So, once you get your OS all configured, you're not bound to the original hardware.

For my virtual machine, I went with VirtualBox over VMware, since VirtualBox costs nothing and is open-source. Their provided documentation is pretty good too.

I then installed Debian 7 on it. (I actually did this twice, but here's what the process looked like the second time around. I'm assuming here that you know the basics of installing a Linux system.)

Due to previous Linux endeavors, I already had an ISO of the last stable Debian release (6.0/"squeeze") handy on a CD. (If I was doing this from scratch, I would grab a "testing" ISO instead.) I created a VirtualBox machine with a 12.0GB hard drive. (I hear this the only parameter you can't change once you create the machine.) Although it's a little slower, I went with a dynamically-sized file to save space on my host machine. I gave the machine 2GB of RAM and 1 CPU. (I'm used to running Linux on ancient hardware, so this is more than most of my installations get.) When I first started the virtual machine, it booted off the CD and began the installation wizard.

Debian's default Graphical Install worked out fine. When asked for what subsystems to install, I unchecked everything (including Standard System Utilities), so I had the barest machine possible. The default setup reserved 500MB of my 12GB for a swap partition.

The "stable" release tends to get outdated. For example, squeeze gives you Python 2.6. The current 2.7.3 is available in the "testing" release, and that will be updated within about a week of any new Python updates. So, once the installation was done, I edited my /etc/apt/sources.list to pull from "testing" rather than "squeeze". I then ran an apt-get dist-upgrade to switch over.

In upgrading, I got a new kernel. On rebooting, I found that my virtualbox guest services were not longer starting up properly. I would get this error:

AdditionsVBoxService error: VbglR3Init failed with rc=VERR_FILE_NOT_FOUND

At this point, the only obvious problem this caused is my mouse scrollwheel stopped working, but I knew it could cause other problems later on. I eventually learned that I needed to install the appropriate linux-header package. (While I love the idea of Linux, this is an example of why I don't actually use it everyday. You upgrade something that's supposed to be routine and suddenly something else breaks with some arcane error that requires an hour to debug, some config file hacking, and some new packages to track down. <sarcasm>Oh, you're obviously just missing the necessary the kernel headers. Duh!</sarcasm>)

For my desktop environment, I used: apt-get install lxde. This is pretty minimalist desktop, but I figured it should still be snappy in the virtual machine. So far, it is responsive. It looks crude coming to it from Windows 7, but I find I don't mind so much when I have Windows 7 running in the background, a single click away! When I get some time, I'm curious to see how well the latest KDE runs under these conditions.

I also installed openjdk7 and Eclipse (which wanted openjdk6 and a bunch of other stuff).

At this point, I had a working virtual Linux machine. Time to put it to work!

LXDE in maximized window with Windows taskbar readily available below.