CountColon – my first Google Wave robot

CountColon – a robot that adds text statistics to your blips

This is my first Google Wave robot ^^ Just got access to the Google Wave sandbox yesterday (finally!).

There don’t even seem to be that many robots and gadgets yet. All in all there are about 50 gadgets and robots on the official list, so my robot is one of the very first add-ons for Google Wave (yay).

I like the feature that many text editors (at least the good ones) have which shows you statistics about your documents. Stuff like line count, word count, character count and so forth. Google Wave doesn’t have that and nobody (at least not that I know of ^^) wrote a robot that adds this functionality to Wave,  so I did it myself ^^ Was easy enough too which is good since I only know the little bit about Python that I learnt when I started working on a website that runs on Google App Engine.

Here’s how it works (for now):

You write [count: lines] or [count: words] anywhere in your text and then the robot swaps it with the count. That way, you can style the output like you want. You can also do [count: chars] to count characters and I plan to add paragraph counting next. And then I’ll make a command that lets you count occurrences of a word or phrase ^^ And THEN I will make an option that lets the counters update live (at the moment they only update exactly… Once ^^).

Developing robots isn’t that easy right now for two reasons. The documentation is incomplete (and that’s a nice word for it ^^) and you can’t test robots locally which means that you have to develop your robot, upload it to Google App Engine, add it to a Wave in Google Wave, check your App Engine logs for error messages, change your code, upload your code again, …

Also the Python API seems to be missing a few features that the Java API already offers (I haven’t looked at the Java API yet). You can’t for example modify styled text (bold, italic, etc.) with the Python API which means that if you do modify text with a robot written in Python, all styles are lost. I learnt that the hard way with my robot

It’s a lot of fun though ^^ I already have ideas for 5 more projects (robots and gadgets) and I’m sure I’ll get a couple more ideas over the next weeks.

I’ll write about my experience with Wave in another blog post.

Multiplayer gem/color matching game using Google Wave

I’m still waiting for an invite to the Google Wave sandbox and I wanted to learn JavaScript anyhow, so I started working on another project for Google Wave instead of my main project that I signed up with for a Google Wave developer account:

You probably have already played games like this, they are very popular. I don’t think there is a multiplayer version though (but of course I might be wrong), so Match them colors! (Funny that nobody has used that name before, is it that bad? I kind of like it ^^) could be the first. By using Google Wave, you can play this game together with any number of people (although I guess it could get a bit messy with more than 5 or so players ^^).

You can play an early version of the game without Google Wave by clicking on the screenshot. It works in all major browsers (no, Internet Explorer is not a major browser, it’s a major pain) but at the moment it works best in Google Chrome/Chromium and Safari. In Opera and Firefox there are missing mouse-over effects which aren’t important though. You have to have JavaScript support turned on, of course.

When you click on a field you will see that it gets marked by a small picture. That’s my avatar On Google Wave, that picture would be your avatar, so you can see on which field someone has clicked.

Things that are missing right now are animations for the fields falling down to replace destroyed fields, displaying the score (so it’s not much fun to play the game at the moment) and the game doesn’t check if a move actually destroys fields, it shouldn’t allow moves that don’t. If there are chain reactions, a lot of fields get swapped with other fields and you may think that something is wrong with the game but that’s only because it’s too fast for you to see what happens (thanks to the missing animations). I tested everything for quite a few hours and everything is working as it should.

As a small side note, I am trying out Mercurial as a version control system while developing this game. Was very easy to get into. I don’t know yet if I like it better than git or not. I’m not actually looking for a new version control system, I was just curious

Update, July 24th:

Mouse-over effects work fine now in Firefox and Opera too. The aspect ratio of the colored fields was wrong, that’s fixed too. And finally, illegal moves (moves that don’t destroy any fields) aren’t possible anymore.

Clojure and cross platform Tweetility

I thought about learning a new programming language, to be specific one that was made with concurrent programming in mind. I tried to decide between Scala, Erlang and Clojure and finally decided on Clojure for no reason at all

I’ve ported a tiny (200 lines or so) text editor with encryption support that I’ve written a few months ago from Java to Clojure and so far I like Clojure. Especially the building an application while it is running part, really cool. This app doesn’t look like much but it’s actually one I use daily, to store sensitive data on my dropbox account (yes I’m paranoid). The Clojure version is about 30 percent shorter than the Java version (and that’s with some features added that were missing in the original Java version ^^). Took about an hour I think to learn Clojure well enough to port the app and the porting took maybe another hour.

Since Clojure is a Lisp I also started to switch from using Vim for programming to Emacs. It’s actually rather nice and the steep learning curve is a myth in my opinion. It’s perfectly usable after going through the ~30 minute tutorial. All the other features are just a pretty nice bonus and yes, learning about all of those could take years but you don’t have to learn them so they really shouldn’t be counted ^^

And after I’ve portet the text editor to Clojure I started writing Tweetility with Clojure (I’ll continue to develop the Haiku version too of course). The thing is, I’m using Linux on my desktop and Mac OS X on my laptop and I wanted a nice Twitter app for those operating systems for myself. Since Clojure runs on the JVM it runs everywhere where Java is installed (Java 5+, I keep it compatible since my old G4 iBook only runs Java 5). There are already quite a few good Twitter apps for those platforms but there are two problems. First, either they are Mac only or written with Adobe Air which means they are fast enough but still feel sluggish. Second, each of those apps have a few really nice features but none of them has all of those features that I want.

So, developing Tweetility for those operating systems too sounded like a great idea. Here are a few screenshots of my progress so far. It’s not much to look at yet, I have only just started. The screenshots are taken on Ubuntu Linux but it should look pretty much the same on all platforms. The screenshots are in chronological order so at the very bottom is the current version of Tweetility.

A few of the GUI parts are written in Java instead of Clojure since I was too lazy to look up how to do some stuff with Clojure instead ^^ This is actually a good thing though since Java should be 3 to 4 times faster than Clojure from what I’ve heard and the GUI should be as responsive as possible (and it is, tested on my slow as a snail single core 1 ghz iBook).

Up, right, left, down, shoot, shoot, shoot

Killed the bug that bit me. No wait, that was something else. What I wanted to say is that I managed to squash the bug that made Tweetility (0.6.0) crash when quitting. The solution isn’t perfect but I wanted to ensure data integrity when you close the app abruptly. The problem is, it could be downloading Twitter profile pics right now and if you quit it while it’s doing that it would mean you have damaged profile pics on the harddisk. Tweetility now nicely stops all transfers when you quit it and deletes uncompletely transferred profile pics so that it downloads them again when you start it the next time.

There is still one problem though. Since I’m doing this, I can’t just force quit the download threads. I have to tell them that they should shut down (by a Kill Switch!!!! ^^) and then I have to wait for them to finish. That shouldn’t be a problem but somehow it doesn’t work. If I tell the main thread to wait for the download threads to finish and they then do finish, the main thread keeps on waiting forever. This seems to be a bug in Haiku but I’m not sure, I may not have understood the documentation.

That’s why I wait just one second now and in that amount of time the download threads have to clean up because then the app shuts down. This is a bit hackish and in rare circumstances this will not work (like when your CPU is used up 100% and 1 second isn’t enough anymore for Tweetility to clean up). So I’ll definatly look into this some more but that didn’t keep me from packaging version 0.6.0 of Tweetility yesterday

Oh and of course I still haven’t even released 0.5.0 but there still isn’t anyone reading this blog because I haven’t released the app yet (or told anyone about it) so it still doesn’t matter and I will take my time

a glimpse into the future.. of tweetility

I still haven’t uploaded the damn beta of Tweetility (which is version 0.5.0) but here is some news about version 0.6.0. You may have guessed that this version is threaded (or to be precise, it is more threaded than 0.5.0 since every BeOS app has multiple threads anyway) which was necessary so that Tweetility can check for new Tweets every 60 seconds (some call that a minute but then again, some are really crazy blokes) without interrupting anything else (like reading or sending Tweets). Apart from two minor bugs (a memory leak and a problem when quitting Tweetility while it’s downloading profile pictures) this version is done and works fine. I may end up releasing 0.5.0 and 0.6.0 on the same day.

What does this mean? In short, it means that with version 0.6.0 Tweetility becomes a quite usable Twitter client that lacks a few features that would be nice to have but aren’t necessary (and which will be added over time of course).

I would say sorry for not uploading the public beta when I wanted to but then again no one reads this blog yet so I don’t have to

Purplepurpleton and the licenses of doom

Made a new screenshot of Tweetility with bogus Tweets since I don’t know if it’s completely legal to post screenshots with other people’s Tweets in it It should be covered by fair use but then again, I’m not a U.S. citizen. Or a lawyer.  Or sane.

Speaking about legal issues, I hope I got all the license stuff right while packaging Tweetility. It uses MIT and BSD licensed code so I had to add licenses for that to the package. I hope I’ve done that right, there should be a tutorial for that kind of stuff And of course Tweetility needed it’s own license (it’s closed source freeware at the moment until I feel more comfortable with writing C++ code, then I plan to release it as MIT licensed open source software) so I just wrote a line of my own and used part of the MIT license (the part that protects me from, well, everything). The license pretty much says do what you want with it but don’t modify it and if you redistribute it, include all the license files and docs and also, if something bad happens, I can’t be held responsible.

I haven’t uploaded Tweetility yet although I do have the Zip file ready so I should do it some time today. I’m currently trying to decide if I should put it up on Haikuware and/or BeBits or if I should wait until I’ve got the 1.0 version ready.

!Lazy

I was quite not-lazy today, so I hope to have the public beta of Tweetility ready by tomorrow which would mean I would upload it the day after (or sooner).

I worked around the issues with networking in Haiku on my computer by using another webserver to test Tweetility instead of a local webserver like I had planned originally.

I’ve also implemented a small preferences window now where you can enter your Twitter login data. It pops up when you haven’t entered your username and password yet and then never comes back again (which is bad so that’s only temporary ^^). It saves your login info to a preference file together with the window position of the Tweetility window.

I would love to add oAuth authentication to Tweetility because that is much more secure than http basic authentication. You wouldn’t even have to enter your login data into Tweetility then and Twitter would display that tweets sent with Tweetility were sent from Tweetility instead of saying they would have been sent “from web”. There is no C++ library for oAuth though (only one that relies on the Qt framework which isn’t yet fully ported to Haiku) and writing one myself is out of the question at the moment, that’s too advanced for me since Tweetility and BeVideoBot are my first C++ apps. Hopefully in a few weeks or so I’ll be advanced enough in C++ to write an oAuth library myself or maybe someone else will have written one by then. There were two people on the oAuth mailing list who said they would write one.

Bugs, delays, torches and pitchforks

Tweetility will take a bit longer than I had hoped, hopefully only a few days. Due to a bug in Haiku that makes networking kind of unusable with my internet connection it’s painful for me to test any kind of app that uses the internet, which includes both BeVideoBot and Tweetility. This will give me more time to work on Tweetility though so when I release the public beta it will have a few things included hat would have otherwise been included in a later release.

This also gives me more time to think about how to implement a preference pane for Tweetility. Or to be more precise, how to open the preference pane. I could of course add a menu to Tweetility but that would only be for preferences, about, copy, paste and quit. I think that a menu could be a bit overkill here since there really wouldn’t be much in it. Another possibility would be to use a toolbar. Or a small button with a cogwheel on it in the purple bar where the Send button and the character counter is. I think the menubar and the small cogwheel icon are the best options, but maybe I’ll think of something completely different

I’ll probably write a small website that mimics Twitter’s REST API so that I can test the app locally without needing to access the internet. Hopefully that will circumvent the problem.

…and a screenshot of BeVideoBot

The window grows when you add downloads to the app. At the moment the window just gets bigger and bigger and bigger but I’ll make it so that when it reaches 5 downloads, the download views are wrapped in a scrollview and the window won’t get bigger anymore.

And I shall name you…Tweetility

Found a name for my Twitter client (Tweetility), registered it with Twitter so no one else can use the name aaand here is a screenshot