SourceTree: My new favorite Git GUI

I've started a new job, so I've been offline for a while. But I want to give a quick shout-out to Atlassian SourceTree.

I like Git, and I'm not afraid of the command line, but I'd rather use faster, more informative GUI tools if they exist. I've been using GitHub for Windows for my projects stored on GitHub. I learned about SourceTree at work and, now that I know it also integrates with GitHub, I've switched over at home as well.

GitHub for Windows is very simple, which is an advantage when you're just getting started with Git. But I find certain things can only be done through the GitHub web interface or on the command line. SourceTree, on the other hand, has a lot more power to it. As just one example, you can easily pick chunks and specific lines of a file to include as a commit.

If you like a GUI front-end to your Git, but you want a bit more power and elegance, check out SourceTree.

HabitMaster: Alpha release

HabitMaster is now live in the wild. You can see the new one-page HabitMaster project site that links to everything else you might want to see, including a running Heroku instance.

Overall, this deadline has been met with limited success. I'm calling this an alpha release because the HabitMaster achievements (in other words, the actual gamification parts!) are still unimplemented. It means HabitMaster is just a basic habit tracker right now, and still a little rough around the edges at that.

This has mostly been due to just slow progress. According to my time tracker, I averaged around 8 hours a week on ICS691 projects for most the semester. I stepped that up to averaging around 12 hours a week for the past month, but I still don't appear to have much to show for it. Yet it seems all of my implementation projects go this way: I continue to underestimate just how much code is required to do things.

I spent most of my time implementing back-end details, such as streak detection given a list of activities and a particular schedule type. I was excited to use a Python generator (basically a fancy iterator) to good effect there.

I also came up with a workable solution to handling polymorphism in database objects. Specifically, my habits link to a Schedule object, but there are two subtypes of Schedule: DaysOfWeekSchedule and IntervalSchedule. Grabbing habit.schedule would give me a row from the Schedule table, which was fairly useless. I ended up adding a cast() method to Schedule that would resolve that instance to the proper subtype for me.

Django's unittest framework was very handy. I didn't get into the UI unit tests that actually let you test requests and responses, though. I would like to explore that more. I'm still impressed with Django and its documentation.

I picked up more HTML5 tags, which has been enjoyable. I dig all the semantic tags they have now. Twitter Bootstrap and CSS design in general was a time drain, though. There was a lot of fidgeting required to get everything laid out right. I'm still a lousy graphical designer. CSS still trips me up on things that seem like they should be easy, such as define a DIV of a given relative width and then align a couple items to the left and one or two to the right within that DIV. And then have them all play nicely as the window resizes. I will say that Bootstrap helped compared to trying to do this from scratch in CSS, though.

GitHub (and to a lesser extent Heroku) has been an increasing pleasure to use. I put GitHub Pages and GitHub's wiki, issues, and milestone features to work on this project. I code alone so often that I've developed some lazy git practices, though. The main one is that my commits are based on work-session rather than issue. It doesn't affect anyone else, but it means I often commit things half-done or in a broken state. That is going to come back to haunt me if I ever have to rollback to a previous verison. I also have a lot yet to learn about merging and pulling with git. I ran into a bit of that while I was editing on Windows, Linux, and through the GitHub web interface today.

As you can probably tell, I enjoyed all the technical learning this project has afforded me.

Regarding the gamification aspects, I have this lesson to share: It takes a lot of time. Any gamification mechanics will be in addition to implementing the underlying service you want to provide. The gamification needs to be well-thought out, too. If possible, leveraging an existing framework could help cut down on that time... though it means you'll need to spend the time learning the framework and then being bound by its limitations.

The other thing that HabitMaster has clarified for me is the difference between gamification and a serious game. I see HabitMaster as an example of the former but not of the latter. To me, gamification means being inspired in your design by the fun and rewarding engagement we find in games--even when you're designing something that is clearly not a game. Because it's not a game, you can't just paste game mechanics onto your service. You need to think about the experience you're going for... which brings us to deeper concepts like mastery, autonomy, meaning, flow, engagement, reward, and the like. A serious game, on the other hand, is when you take something that is clearly a game and try to graft non-game goals or outcomes on to it.

HabitMaster will likely be dormant for a little while as I finish up some other pressing projects, but I do hope to resume development when I get some time. I'll also be starting a new teaching job in July. I wonder if I might bring some gamification to bear on course design there.

HabitMaster Progress

This past week or so I've been implementing my previously-mentioned Habit Master design.

So far, things are going slowly but smoothly. I decided to divide my design into three apps: habits, users, and rewards. I first defined the habit and schedule models, some unit tests for them, and got them setup for admin view access. I also defined a User model before I realized it would be a much better idea to reuse Django's existing auth system for that. I still have a users app as a good place to put the views and page templates associated with account creation, login, and logout. I learned more about how templates work, so I have a base page template I'm inheriting from. I've also sorted out how static files work for things like style sheets and html5shiv.js. I'll eventually get Twitter Bootstrap into that mix too, but I'm focusing on functionality first.

There have been no major obstacles or bugs so far (knock wood). It's just been slow due to the general learning curve. Though I feel like I had a comfortable conceptual overview thanks to earlier exercises this semester, I still had to skim through the tutorial again as I completed each step for this project. I've also been diving deeper into the Django documentation for things like the auth system, view decorators (a bit like Java annotations), and request object details. I think Django could have provided more built-in help with my login form, but I haven't dug into that yet. Overall, I still like Django and its documentation.

I've been reading the HTML 5 spec to pick up some of the many new tags and throw them into the mix too.

There have also been a few toolchain improvements along the way. For example, I learned that git add . doesn't remove deleted files from the repository. To handle this, I learned more about git add -u, which will update all modified and deleted files but not stage any new additions, and git add -A, which will properly stage all changes. I've also been improving my virtualbox linux environment. For example, I found that KDE's Kate editor does allow to keyboard binding customization after all: you just have to go to Settings -> Configure Shortcuts... instead of Settings -> Configure Kate... to find them.

Hopefully things continue to go well. It doesn't seem like I have much to show at this point, but it feels like I've touched all the major parts at this point--apps, settings, models, tests, views, templates, urls, static files, and deploying to Heroku--so the rest should hopefully just be fleshing out more of the same. The next two or three weeks will tell.

HabitMaster: Gamified Habit Formation

I'm starting on a new web-based gamification project. The current design is on GitHub.

This design has been evolving from its original broad concept. Some recent design additions include:

• Users can now record notes regarding each task completion, or even if they did not complete the task for a given day.
• Users can specify degrees of completion (green for "wholehearted" or yellow for "halfhearted"). However, to avoid discouraging those just starting out, this will be an advanced feature that is unlocked only once a habit has been firmly established.
• Social features have been given a bit more consideration, though they will still probably not be implemented as part of version 1.0.
• Fleshed out a number of specific details about the interface and flow between screens, including three new UI mockups.

Version 1.0 will include only the core features. I could evaluate the effectiveness of these gamification features by creating a second version with them stripped out. Specifically, this would omit the mechanics of streak tracking, leveling up a habit, badges, milestones, 1UPs, and social sharing. This would leave only the ability to enter habits, check them off each day, and review their history. I could then compare user adoption of the two systems: would users use the system longer and more frequently, have more successful habit formations, and enjoy the process more with these extra gamification features?

I'm looking forward to starting the implementation next week and learning some Django from scratch.

Makahiki Widget Development

My exploration of the Makahiki platform continued this week. I tried my hand at adding a few new widgets that could be inserted into a different pages. (Apologies to any general readers: this will be a very Makahiki-specific post.)

I started by following the Hello World tutorial. This was fairly painless and gave a nice overview of the files and functions that comprise a widget.

Next, I built a Group Scoreboard widget. At this point I wished for a bit more of a high-level overview of how widgets should work. I wasn't sure where the best place would be to add new data-gathering code: within the template HTML page, within the related views.py, or in the corresponding manager library. I quickly learned that code within a Django template doesn't seem to handle any parentheses or parameters, so that left views.py or the manager classes. I ended up working with both of these.

Groups are closely related to teams, so there was a fair amount of existing code to review and cannibalize. But, as with any complex system, it is hard to quickly build a mental map from the bottom-up like this. I felt a bit like I was redecorating while stumbling around in a dark room.

I got my Group Scoreboard together, though. I also built two Group Resource Use widgets. This proved a little trickier since it involved "subclassing" a widget. I also initially missed the INSTALLED_COMMON_WIDGET_APPS setting in settings.py, so I couldn't figure out why my common template file couldn't be found while resource_goal's could be. Also, I made a few errors that prevented the server from starting, and so I spent a while trying to debug single-line error messages such as "Error: cannot import name Team". I learned about this command:

  ./manage.py shell --traceback

which provides a full stack trace on an error. This was invaluable for debugging.

By this point, I was running short on time. I skipped making a Group Prize widget and started on a couple group-related Status page widgets. I spent an hour or so trying to decide how best to gather the group data from the team scoring/ranking system that is spread between score_mgr and team_mgr. I started toying with a plan to filter the team data to include only those in one group. As I neared the point to start testing it, I realized I didn't know exactly how the existing score widgets were placed on the Status page.

Specifically, I found the two templates (team_point.html and team_participation.html) that I wanted to copy in the widgets/status/score folder. However, simply adding a new group_point.html template in the same place didn't auto-magically show up. There is also no status.score widget registered through the Makahiki interface. Instead, these templates appear to be controlled indirectly through a separate scoreboard app. Looking through scoreboard's template was a bit of a mystery, however, since it makes no explicit reference back to the status.score templates.

The listed Makahiki widgets (front right) and corresponding file structure (back left).

At this point, it was time to move on from this project to bigger and better things. Here is a shot of my successful widgets currently on the Profile page:

And these are available within Makahiki to be added to any page:

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.