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.

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.

Lisp: First Impressions

I learned the basics of Lisp 10 years ago when I was the TA for ICS313: Programming Language Theory. This semester, I returned to Lisp after a decade away, again in the context of TAing for ICS313. After so long away, I basically had to start over from scratch again. Though it certainly goes much faster the second time around, it's still a lot like learning it the first time. So these are my "first" impressions.

We are learning Common Lisp. So far, I'm not very impressed.

First of all, I find that Common Lisp is bloated. There are usually about 6 different ways to do something. For example, want to compare two items? Consider =, eq, eql, equal, equalp... and that's just getting started. Want to print something? Consider print, princ, prin1, pprint, format, etc. The reason that so many options exist is because each is subtly different. I'm sure that, once mastered, all these options increase your programming power, since you can pick exactly the right tool for the job. And, in many cases, some of the options seem to be now-unused holdovers that persist from earlier days in Lisp's development. So eventually you learn which ones you can ignore. But it all makes Common Lisp rather tedious to learn.

My next stumbling block is the formatting. As evidenced by both my students' code and my own inclinations, it seems natural as a programmer to try to format the parentheses to make matching them up much easier. The parentheses are subtle, and it's easy to get one out of place. This can produce code that compiles or loads but then fails at runtime because the meaning is subtly different to what you intended. This well-discussed blog posting sums it up fairly well. In general, I agree with the author there. Parentheses in Lisp mark the start and end of various expressions in the same way that braces mark the start and end of blocks in C-like languages. In C-like languages, we have proponents of such extremes as the Allman style of indenting. These Allman proponents feel that such formatting is so essential to readability that every brace deserves its own line! Yet the Lisp community advocates the exact opposite: that no parenthesis should be clearly placed. Instead, they should all just be tucked away at the start or end of a line of code. Supposedly some day you get to the point were you can "see past the parentheses". But this seems to me like a convention that makes code unnecessarily hard to read.

I find most of the arguments for this "parenthesis stacking" format are weak at best. One of them that irks me is that your editor will help you. First of all, you're not always reading code in an editor. Secondly, I should have to move my cursor around or press keys or require fancy color highlighting to make quick sense of the code on the screen. It's called "readability", not "navigability". A third argument is that you can ignore the parentheses because the indenting should show you the structure. But the indenting is not what actually determines the code structure--the parenthesis do! So I need to be able to quickly spot when the parentheses are wrong even though the indenting is correct.

This formatting thing bugs me because it seems the problem comes from an asinine coding convention choice. And that's the one reason that has me formatting this way rather than the way that makes sense to me: because "that's how it is done in Lisp." Like the choice to drive on the right side of the road, it's hard to buck the community on such a choice as a late-comer! Yet, because it makes the code harder to work with, but with no good reasons that I can see, it feels a little like hazing: "This is the way we all had to deal with it when we learned, so you do too."

That brings me to the Lisp community in general. First of all, I don't care to worship at the altar of Emacs. As I mentioned above, I shouldn't have to have a special editor to write code. Don't get me wrong: an IDE is great at increasing productivity and I definitely want one. But the code should be both readable and writable without one. Then I'm free to choose the IDE that meets my own requirements. (On that note, after trying Emacs and LispWorks, I settled on Cusp. It's a little tricky to get up and running, and a bit quirky at first, but it works pretty well. The highlighting of parentheses structure is very helpful.)

Secondly, there's just this "Lisp is so much better!" vibe in the community. Now, obviously you've got to wave the flag for your favorite language. I have no problems there. But, as others have pointed out, if Lisp is so wonderful, how come we're not all using it? Just about every computer science major has to learn a Lisp dialect at some point, so it's not just an issue of exposure. Is it because it lacks good libraries for modern tasks? Is it because, while powerfully writable, its dynamic re-writability makes it hard for someone else to read or maintain? Is it because, while a pioneer of so many cool ideas, most of those ideas have now been imported from Lisp by other languages? Is it because Lisp has built up over 50 years of cruft, but each new Lisp project to simply and overhaul it fractures the small but fanatical Lisp community, leading to inter-dialect derision and flamewars? Hard to tell. What I can tell is that the fanatical belief in Lisp's supremacy over all other programming languages is a little hard to swallow.

My general conclusion is that Lisp is still worth learning for the history of it. However, I don't think I'll be taking it up as my day-to-day language. I'll be looking elsewhere for more modern implementations of Lisp's contributions that are useful to me.

Still, the code-as-data idea is largely still unique to Lisp. That would be fun to explore more, so finding a Lisp dialect that fits me better might still be rewarding. I've considered Scheme a bit, but I think either Clojure or newLisp would be even better. (I found newLisp because I thought: "Why doesn't someone clean up and simplify Lisp back to it's glorious essence? If I did that, I'd call it 'new Lisp'." I searched... and behold! Already done 20 years ago by someone else.) Both seem to have newer, friendlier, more open communities. Clojure has the advantage of the JVM and the entire Java API behind it. newLisp is targeting what I think is a great niche for Lisp: scripting. This is where powerful writability at the expense of readability and maintainability is a viable tradeoff.

These are my current impressions of Lisp. Perhaps they'll change with time. If so, I'll let you know!

Timmon and the Three Prime Directives

Philip Johnson proposes Three Prime Directives to guide open-source software development. While provided as goals for developers to aim for, Johnson claims that the developer of a system cannot verify whether their own system actually achieves these goals. Only an external user or developer can do this.

As an example of using the Three Prime Directives as a framework for software review, here is my own review of Timmon Time Monitor. I've actually been a Timmon user for about four years now. Unable to explain how many of my days seemed to get away from me without much to show for it, I searched for a good time tracker program. Of the three or four programs I eventually downloaded and tried, Timmon was my favorite.

PD1: The system successfully accomplishes a useful task.

I think the reason I finally settled on using Timmon is that it is fairly simple. It does exactly what I wanted in a time tracker. I can define my own hierarchy of activities or projects. Then, with a click of a button, I can start tracking time for any of those activities. Another click of the same button stops the timer. It is also easy to edit the time spent on a task, to add a complete task that covers a given time period, or to add a comment describing the work done on a task.

It is then possible to view the accumulated time for all activities at different levels of the hierarchy. For example, I have a Personal category that includes Emailing and Surfing. For the current day, week, month, or year, I can easily see the total time spent either Emailing or Surfing. I can also see the total for both activities combined, plus any other activities I labelled as simply Personal.

Here's a screenshot of Timmon in action:

Timmon has a couple extra features I don't use, such as reports or setting the max time for a given activity.

PD2: An external user can successfully install and use the system.

It's been a while since I installed Timmon, so I had to revist the process. The project homepage lets you try Timmon as JNLP program, so, assuming you don't mind visiting the website every time you wanted to use Timmon and you don't mind giving the self-signed web application full access to your computer, it's actually possible to run Timmon without installing it all. This is a pretty nice feature. When run this way, Timmon still saves its time record in a number of XML files in a .timmon directory in your home folder, so this is a viable option for a novice user.

Installing is a little tricky because the Timmon project provides both a .zip and a .tar.gz. However, the .zip is damaged and unopenable, so you have to be able to unzip a .tar.gz on your system. Also, running the program requires executing a jar file. I think this is foreign to many users, though the main project page provides fairly clear instructions on how to do so.

The Documentation link from the project home page is broken. The project README file included in the download mentions a .pdf manual that doesn't exist. However, the download does include an HTML manual. The manual basically covers the program menus and buttons, so it doesn't add much beyond what could be learned by simply exploring the program. I think Timmon's interface is fairly self-explanatory, though; I don't think I ever used the manual when I initially installed it.

PD3: An external developer can successfully understand and enhance the system.

In the four years I've used it, I have discovered a few little bugs. For example, if I close Timmon while tracking time for a particular activity, Timmon will resume tracking for that task every time I open it. I have to delete the task and restart Timmon to break it of this. So I was interested to see how easy it would be to modify the program.

The project has been dead for about four years. The project README that it is included in the download explains how to build the project manually or by using Ant. The source code for the current version of the project is supposed to be in the damaged .zip file and so is not currently available for easy download. It is still available for checkout from the sourceforge CVS, though.

Browsing the CVS reveals that the code is well-formatted and well-documented with javadoc comments. So it would be easy to extract a javadoc overview of this project's files. However, I did not find an overview document intended for a new developer. There are a number of packages and classes here. Based on the README, the project also builds on 5 separate open-source libraries. With no high-level overview, it would certainly take a fair amount of work for a new developer to build a mental picture of how this program is structured.

In conclusion, I think Timmon clearly satisfies PD1 (does something useful). It does fairly well on PD2 (easy to install and use)--the .zip file and documentation link just need to be fixed. Though well-documented, Timmon needs to provide a short introduction or overview document for a new developer to really satisfy PD3 (easy to enhance).