An epic story of a guy called Bob.

First of all, there is no Bob. Bob is a lie! And the story isn’t epic at all.

It’s a story about what I’ve done over the last week. Yes, it is boring and potentially hazardous to your health so please, don’t read on.

Finally, after thinking about it for a week at least, I bought the Programming Clojure book from the pragmatic programmers. That’ll help me develop Tweetility while doing the right thing and not just something that does work but could be a lot better. I played around a bit with different approaches to managing the Tweets, did some benchmarking here and there to see what’s a good idea and what isn’t. I’m on page 200 of the book right now but I think I’ll have to re-read two chapters because some stuff is really hard to wrap your head around when you are so much used to do object oriented development. The book is pretty good. There are your usual garbage code example with a big warning never to use them in your app but the good thing about this book is that the author also tells you what code to write instead. But he doesn’t stop there, he gives even more examples of how to do it, every one getting better and better until finally presenting the best solution (that he knows of). It’s not a beginners book though. You should already know a fair bit about programming in my opinion to make use of the book.

Apart from that I started to try out a few operating systems I had never tried. First of all, Open Solaris, because I had read about the ZFS file system and that sounded like just the thing for me (I never do backups, my computer has 3 internal and 3 external harddrives, I do stupid stuff from time to time that messes up my system). ZFS makes it safe to work this way and being on the safe side is always a good idea, especially if it’s done automatically for you, because you are lazy of course.

Well, OpenSolaris did work. But it’s unbelievably slow. Takes three minutes to boot on my computer for example. And there is no version of Inkscape for Solaris (yet), which is one of the apps I use daily. Apart from the speed and the missing software Solaris was nice enough though, I’ll definatly look at it again in a year or two.

Then I tried out FreeBSD. Did install fine but there was so much trouble with the installed system that I just gave up pretty quickly after an hour or two. There are lots of people who did install and do use FreeBSD just fine so I don’t want to say FreeBSD is bad, it’s just that I, personally, wasn’t able to get it to work in a reasonable amount of time because I don’t know anything about BSD and didn’t want to invest too much time. I did not read the manual, I just skimmed over it, that probably explains it.

I hadn’t yet seen much of BSD though so I tried PC BSD which is based on FreeBSD but comes with a nice graphical installer and a working preconfigured desktop environment (KDE) so it should be usable right after installing without the need to configure everything first.

It installed fine, everything looked good, but then, after the first boot… A green screen with ugly lines, some text, everything garbled.. Trouble with my graphics card (ATI Radeon HD 2600 XT). Don’t understand why since the graphical installer worked fine and was really fast, surprisingly so. PC BSD tried to use the open source radeon driver, which failed. I tried switching to vesa which took me a while to figure out how to do because it would just switch back to radeon, ignoring everything else. I also fiddled around for hours with a lot of X server settings. I came closer to a solution, but it just didn’t work completely. Fed up with ATI on Linux anyhow, I bought a cheap NVIDIA graphics card (9500 GT, 1024 MB GDDR2) that is slow enough to work in my old computer but at least a bit faster than my old graphics card so that it wouldn’t be a downgrade, and PC BSD finally booted into KDE.

KDE of course was a garbled mess made up of bugs. Don’t get me wrong, KDE is a nice idea and I admire the things that the KDE developers have achieved, some stuff is really cool, but KDE just doesn’t work for me. Never did. Apps are constantly crashing. It’s a bit better on Arch Linux, you rarely see something in KDE crash there. But with Kubuntu and PC BSD, apps are crashing all the time and that’s just something I can’t work with. Also, I can’t stand Dolphin, the file manager. I’m sure it’s perfect for a lot of people as is KDE but for me it’s pretty much unusable. There are some nice ideas that just don’t work in practice and make working with files harder than it should be. I think KDE can become something truly great but I also think that it will take another 5 to 10 years. Gnome and XFCE work right now so that’s what I use on my computers.

Installing software on PC BSD can be done in three ways. PBI files, which are like installers on Windows, those worked without problems but most of those PBI files I found are really old. Then there are binary packages, those didn’t work at all. And then there are ports, installing software from source. That worked fine. I’m writing this from PC BSD right now, I’m still trying it out. Like OpenSolaris it looks promising but isn’t usable yet from my point of view because I don’t want a system where apps are crashing all the time. KDE needs to get better or they need to switch to Gnome or XFCE and obviously there is something wrong with installing binary packages. Maybe there is a fix for that already on their forums, I haven’t looked there yet. Or maybe the download servers were just down yesterday. Dunno. I’ll try PC BSD for a while longer, see if there are fixes for the problems I encountered.

Next I wanted to try StormOS which is based on Nexenta Core. Nexenta is a combination of the OpenSolaris Kernel with the Ubuntu Linux userland, which sounds really interesting. StormOS didn’t let me install it to a partition though, it wanted the whole disk so I wasn’t able to install it. It didn’t work in VirtualBox for some reason. I hope to be able to try out StormOS at some point in the future, when I ever get the time to clean up a whole harddisk.

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 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