Rubénerd!

While Polly is understandably optimised for Ubuntu, it runs well enough on Fedora to still be my favourite multi-column Twitter client! Here's the quickest way to get it running.

Getting the source

Polly doesn't ship with an RPM, but we can install it ourselves without too much trouble. Head to their Launchpad download site and download the latest source tarball. As of writing, the latest is:

Polly-0.93.4 (pre-alpha 3.4).tar.gz

Dependencies

The tarball's README list dependencies for Ubuntu, but it didn't take long to find their Fedora equivilents.

Ubuntu	Fedora
python-gtk2	pygtk2
python-dbus	dbus-python
python-xdg	pyxdg
python-notify	notify-python
python-oauth2	python-oauth2
python-gconf	gnome-python2-gconf
python-socksipy	python-SocksiPy
python-httplib2	python-httplib2
python-pycurl	python-pycurl
python-numpy	numpy
python-keyring	python-keyring
python-gtkspell	gnome-python2-gtkspell

And here they are on a single line to make installing easier. Depending on which spin you're running, you may already have most of these.

# yum install pygtk2 dbus-python pyxdg notify-python python-oauth2 gnome-python2-gconf python-SocksiPy python-httplib2 python-pycurl numpy python-keyring gnome-python2-gtkspell

These also bring in several dependencies, including:

atlas, gnome-python2-extras, gtkspell, libgfortran, python-nose

Installing

Now it's just a matter of extracting the tarball, and running the install script.

% tar xzvf "Polly-0.93.4 (pre-alpha 3.4).tar.gz"
% cd "Polly-0.93.4 (pre-alpha 3.4)"
# ./install

Restarting gconfd-2

If Polly works now, you're done! Add your accounts, and tweet away!

Even with the latest alpha versions, Polly still refuses to load on any of my Fedora machines unless I restart gconfd-2 before I run it the first time. According to the GConf site, the safest way to do this (other than outright killing it) is:

gconftool-2 --shutdown

The friendly Polly developers I've talked to on Twitter expressed surprise that this was still needed. This leads me to believe it's a localised Fedora issue, which means when I research this further I'll be filing a support ticket with them, and not Polly. We'll see.

I'd tried 0.1 back in the day, but @OliYoung reminded me this morning of sshuttle, the poor man's VPN that's just too much fun!

On Soviet Internets, sshuttle proxies you

For most all of my SSH connections, I use custom ports. Security through obscurity is a dangerous misnomer if only used by itself, but it helps to lower the chances of a roaming bot scanning on port 22 from finding it.

With a regular SSH connection you define a port with -p, though fancy alliteration is not necessarily required:

% ssh -p 60000 username@SuperSexySSHServer

Sshuttle doesn't have a -p option, so you merely append the port old school style:

# sshuttle -r username@SuperSexySSHServer:60000 \
0.0.0.0/0 -vv

This then gets converted into a -p option when sshuttle initiates the required SSH connection.

Starting sshuttle proxy.
Binding: 12300
Listening on ('127.0.0.1', 12300).
firewall manager ready.
c : connecting to server...
c : executing: ['ssh', '-p', '60000', 'username@SuperSexySSHServer', '--', '\'python\' -c \'import sys; skip_imports=1; verbosity=2; exec compile(sys.stdin.read(764), "assembler.py", "exec")\'']

I would know, because I'm using it to write this blog post! Very cool :)

With this huge move and all the unexpected problems we've had, I've had very little time these last couple of months to do much programming... or blogging! I can't wait, I'm posting this from my phone.

More history you don't care about

When I left high school in 2005, my first proper job was to write Perl scripts for possibly the friendliness boss I've ever had. He absolutely loved the language, and his enthusiasm rubbed off on me! I learned to LOVE CPAN and though I never did submit any of my own ACME modules I sure created lots of them! If I were learning the language today, I'd write one that just prints The Bird is The Word until the hapless user types Papa Ooom Maw Maw Maw. ACME::Trashmen, I can just see it now!

Anyway after that I started part one of my studies and was inundated with Java. I use the word inundated because it did feel like a flood! I could understand what was going on and appreciated how the language was in some ways self documenting, but the huge, narly long lines of camel case drove me batty. Features like linked lists and generics<T> seemed nice, but felt more like a tacked on after thought in an attempt to look more like C#, a language I did in high school when I was a .net guy and didn't really care for.

Then my mum really went south and programming took a back seat to amateur nursing. Then when she left I went through what I've retroactively dubbed The Ruben Troubles. But enough about that.

Yukihiro Matsumoto is really cute

Around that time while I was taking a break from university for aforementioned family reasons, I picked up the second edition of the pickaxe book and fell in love. Ruby was like Perl but was so schweet... to the point where I was thinking "this can't be healthy!" If you'd been reading my blog for a while you would have read that I came this close to implementing my site in Rails at the time.

I don't quite know why, but as if my brain is terrified of becoming specialised (and therefore successful) despite really liking Ruby I kept tinkering around with Python as well, and eventually grew to like it more. Despite the terrible design of my site here and the fact I like to ramble on continuously without not so much as one cohesive thought or succinct statement, I'm a huge fan of minimalism and Python is such a clean language. Not only that, it uses the white space for something! I mean, we all indent our code, it makes SO MUCH SENSE to USE it! Ruby still needs end statements or braces just like C and Basic, what's up with that!?

Oh yeah now I remember why I got into Python: Django. Django is one of the nicest frameworks I've ever used. We just clicked. I really tried to like Rails and did my fair share of work with it, but we didn't click. Despite what some mathematicians and computer scientists say, I think programming is a deeply personal thing, and sometimes things just click, and sometimes they don't. I've done equal amounts of work in Ruby and Python (and WAY MORE in Perl and Java, groan!) and it just makes more sense to me.

This heading is just as useless as the other two

Ruby has some very beautiful language constructs (the iteration block is so friggen elegant and nice I want to give it a huge hug), but an equivalent Python application will [often] be smaller, a boon for people like me who do most of their development hunched over a small ThinkPad at a coffee shop or an Apple computer that has a screen that sacrifices vertical space to make it wider.

Nonetheless, for its lucrative advertising potential (RUBEN DOES RUBY!) and to shut you all up (Ruben... why don't you do Ruby? Hey Ruben, do Ruby! Hey Ruben, Python isn't for you, Ruby is! Hey Ruben, your name is a total fit! Ruben, where did I leave my keys?) I've decided to give it another shot and submit my next assignment in it instead of Python. Who knows, it'd be great to do some RubyCocoa stuff :).

#!/usr/pkg/env ruby -w

class MugiChan
  def to_s
    return "Can Yui have this guitar cheaper?"
  end
end

if __FILE__ == $PROGRAM_NAME
  waifu = Mugichan.new
  puts waifu
end

Sent from my iPhone
(one of these days I'll get rid of this thing)

I've been running Fedora 13 Goddard on my ThinkPad X40 for the last few days. Aside from some rendering and install issues, things are pretty smooth sailing.

Fedora 13 is the latest version of the Fedora operating system sponsored by Red Hat that I switched over to from Slackware as my Linux of choice last year. On the whole I prefer it to Ubuntu because they keep more of the original Gnome interface in tact, and I've grown to like YUM for installing packages. Pkgsrc works great on Slackware, but being able to simply enter "yum update" is a real boon.

Installation

Since toying with Red Hat Linux 5.0 in the bad old days, for some reason the Anaconda installer and my computer hardware have generally not played nicely. I remember wanting to use Red Hat's then-new Bluecurve theme back in the day but I couldn't get past the timezone screen without it crashing, despite the BSDs and Mandrake Linux installing without any issues.

Fortunately Anaconda has worked reasonably well for me since Fedora 12, and aside from the internal ThinkPad TrackPoint mouse not being detected throughout the entire install process (necessitating a ton of [TAB]-ing) things went fairly smoothly.

Of note, I like to configure my own partition layout but for those who just want it installed fresh or to have it overwrite an existing Linux install, Anaconda's new layout was very slick. I also noticed Joe was available as a pre-installed editor option on the software screen; not sure whether that's always been there but throwing that out there for what it's worth :).

Interface nastyness

A fresh install and a yum update later, Fedora 13 was booting just fine on my ThinkPad X40, the mouse had even been detected which Anaconda couldn't do. The document icons look suspiciously Mac-like, but that's okay because I'm also a Mac user and find them rather fetching!

Now for the bad news. I'm not sure whether it's the new open intel X11 video drivers (with otherwise work beautifully), but unfortunately the interface looks terrible. Icons displayed in menus and toolbars are either poorly rendered with jaggered, ill defined edges or in some cases not even existent. All the default Gnome icon sets and icon sets I've installed myself (I like Nimbus and Tango) look this way.

On a Windows machine I would diagnose this problem as being caused by a low colour depth, but photos and Metacity render gradients and colour just fine, so I'm thinking it must be a GTK issue. Lending support to this theory is that icons in Firefox look the way they should too, which means (I'm assuming) Cairo is okay but plain GTK isn't.

These visual artefacts are not present on the FreeBSD 8.0 partition on this machine, nor were they there in Fedora 12. To make sure the installer didn't do anything funky or forget to install a package, I reinstalled Fedora 13 from a DVD and a USB key from different sources with the same results.

Oh yeah, and Metacity still can't handle double width characters in window titles. I suppose this is an issue with the Gnome folks and not Fedora though, so I'll leave it at that.

The compliment sandwich

As Stewie Griffin would do, I thought I'd structure this review as a compliment sandwich, with positive things on the outside and the negative things in the middle so we end on a high note :).

Firstly, kudos to the Fedora team for continuing to reduce their dependency on Mono! Fedora 12 implemented the beautiful Gnote in place of Tomboy, and with 13 they replaced F-Spot with Shotwell. I have to admit I'd never heard of the Vala language until I read up about Shotwell, it looks really interesting and the perfect antidote to Mono which has always made me feel uneasy. Could Gnome finally be able to compete with KDE and Qt in this regard now?

And of course I'm delighted that a fully featured Python 3.0 stack is now available in the default install! Granted my primary Python haunt is Django, but my personal scripts have been running on 3.0 on my Mac for a long while now, so it'll be great to port them over.

Conclusions

Overall aside from a couple of glitches on my specific hardware, Fedora 13 looks like a solid release.

Having got used to Python 3.0 development on my Mac through MacPorts, I was a little surprised to find it currently unavailable for Fedora, at least in Constantine (Fedora 12, the current stable release) without any third party RPM sources.

I suspected it may have had something to do with many of Fedora's tools depending on Python 2.x, so one solution would be to do what the MacPorts folks did and implement them as separate ports, or RPMs. I'm still getting used to the lingo ;).

According to the Fedora Wiki for Fedora 13, that seems to be their intention. From the Benefits to Fedora subheading:

Fedora has long been a great platform for doing Python 2 development, but we don't yet have Python 3. Having Python 3 available via rpms will extend our Python coverage.

Note also:

• Python 3.0 was released almost 10 months ago, on 2008-12-03, and the latest release of the 3.* branch is 3.1.1, released on 2009-08-17.
• Other distros have python 3, though not necessarily with anything "on top" resembling the full python 2 stack.
• We have a working, valuable python 2 stack, which is used by critical system components (yum and anaconda): we must not destabilize the python 2 stack.
• Python 3 is sufficiently different from python 2 that we need them to be independent software stacks.
• The Spanish Inquisition. Spam spam spam. The knights who say... the soft cushions! The comfy chair!

I can live with that. As far as Linux distributions go, I like how transparent the decision making process is in Fedora and enjoy reading their discussions, even if in this case they seem to be a bit behind.

As for me, Django still uses Python 2.x but I'd started moving some of my personal projects over to 3.x. I suppose I can keep using the -3 flag with the Python 2.6.x interpreter to warn me of any deprecated features I may be inadvertently using.

While I revel in this more traditional approach to blogging (when it works, looking at you WordPress), I do admit I'm jealous of how it easy it is for people on Tumblr to re-post entries from other tumblogs (that is the term, right?). Say... this one, for example!

So here's my idea

Usually I would start reading up on a site's API, but with so many things to do right now I decided to take the easy way out given I'd only be using it in a personal context. Here's my idea:

1. Write a crappy Python script that accepts the URL/URI/address for a Tumblr entry I'd like to re-post in true Tumblr-like fashion.
2. Use curl to grab the page, or fetch, or... heaven forbid, wget.
3. Extract the textual information from the post, including the links to the people who re-posted it.
4. Download local copies of the image(s) in a post and use ImageMagick to scale and convert them.
5. SFTP to my webserver and upload the image(s)
6. Connect to my WordPress database, add all the stuff, done.

Of course things aren't that simple!

How so? Ugh I hate rhetorical questions, mainly because I always need to consult a spell checker whenever I spell rhetorical.

For example, the picture of the girl above whom I can't stop looking at for some reason was saved on Tumblr as a gigantic PNG. What?! I know it could be saved as a JPEG and save a ton of space and bandwidth, but ImageMagick can't tell that from a diagram that should be kept as a PNG. In other words, it couldn't be an entirely automated process. Perhaps I could specify along with the URL I'm giving the script whether or not the images should be messed with. Ugh, but then it's not as automatic, which kinda defeats the purpose.

Secondly, Tumblr allows people to share far more than just pictures. If someone embedded a YouTube video or something else, what do I do then? I prefer hosting my own copies of stuff with attributions becuase I don't like relying on third party sites to stay alive. Why am I hearing Bee Gees all of a sudden? Ha, ha, ha, ha, staying alive... staying alive. Ha, ha, ha, ha, staying aliiiiiiive!

Thirdly, I shouldn't do this hack job and instead use the public APIs to get all the information I need and implement it in a WordPress plugin. It'd mean I'd have to actually learn PHP for real instead of just the hackish bits and pieces I've picked up from my Perl days and from maintaining MediaWiki and WordPress installs.

Okay I admit it!

This entire post was an excuse to post that picture. I'm a sucker for eyes, and I'm lonely, shaddup.

Andreas Constantinou has written one of the most interesting blog posts about Android that I've read in a long while; he argues its claim to being open source is not only suspect, but that the platform's relative success has very little to do with it. The following are my own thoughts.

It's not as open

Years ago I wanted a Qtopia device, a chocolate-bar form factor phone made by the Qt framework folks. I was on the mailing lists for the OpenMoko phone for years as it missed deadline after deadline. The Neo1973 looked like a boat anchor, complete with an awkward handle for tying rope onto its frame.

For a sizable part of the 2000s I was a Mac user but longed to move to entirely free and open source systems because it was the "right thing to do", but as with many FLOSS efforts I gave up when they failed to deliver on promises.

When Android was announced my hopes were renewed, but as it quickly became clear it's advertised openness wasn't as clear cut as we were led to believe, as Andreas painstakingly points out. This has led to a few discussions personally on Twitter asking whether Apple's unabashed "play by our rules or leave" approach is more honest than Google's "we're all about openness" when there are even parts of their own systems that are off limits.

That said, I have no problem acknowledging they're light years ahead of Microsoft, and as consumers in general we're far better off with Android being the generic OS for phone makers than WiMo with either a creaky old codebase or a UI design that'd look great... in print!

It's not really original

Prior to the iPhone, the Android prototype looked like a Blackberry, right down to the tiny keys and the layout of the user interface. Fast forward a few years and aside from some awkward slide-out keyboards and trackballs that even most Android users claim is utterly unnecessary, Android devices look like iPhones with a few more buttons. That's not necessarily a bad thing, but one can hardly claim Android is original in any really meaningful way.

Daniel Eran Dilger wrote a brilliant piece in Roughly Drafted recently about the upcoming Android 2.2 software and how if Apple released something akin to it people would be up in arms.

While Apple has taken a public beating for being slow to deliver some significant features of the iPhone OS, including last year’s copy and paste or this year’s multitasking, it’s less well known that Android is missing key features that everyone just assumes it must have.

I still want one

While acknowledging the iPhone is a superior device in terms of usability, security and design, the nerdy part of me would still love to have an Android device, and not just so I'd have an icebreaker with Gina Trapani who I have a mad crush on.

One of the more limiting aspects of the iPhone [for me] is not being able to automate tasks that I would otherwise fire up a shell and hack away at on a desktop. Having a Python interpreter (or even just basic shell scripting) on a phone would be an absolute slice of heaven, and I know that Apple will never allow it on my current device. I could imagine Apple doing an Automater.app-like environment for the iPhone OS at some point in the future, but I'd still prefer being able to write some scripts that use APIs for the phone, text messages, email and so on, then upload them to the phone. There's so much stuff I repeat everyday that the phone itself could do for me.

All that said, having done no research into this I have no idea an Android device would allow me to much (or any) of this either, but I suppose if they didn't I could roll my own custom firmware... that is, if Google allows it.

It's 3am and I'm writing about phones. I should be asleep, dreaming about them instead. Hey, wait.

I've decided to put my code snippets blog idea on hold because I don't have time to be maintaining a separate blog right now. Had I started it, this would have gone there.

Not having main methods never used to worry me, but since studying Java again I really like being able to have an application kick into action without having to create an instance of it manually.

To illustrate what I mean, here's a crappy Java application that I merely have to execute from the command line for it to display Bender's favourite words.

MainInJava.java:
public class MainInJava
{
  public static void main(String[] args)
  {
    System.out.println("Kiss my shiny metal arse");
  }
}

Now here are roughly equivalent applications written in Ruby (my formerly favourite scripting language) and Python (my formerly favourite scripting language, and now my favourite scripting language again!):

MainInRuby.rb:
#!/usr/bin/env ruby -w

class MainInRuby
  def initialize()
    puts("Hello, world!")
  end
end

MainInPython.py:
#!/usr/bin/env python -3t

class MainInPython:
    def __main__(self):
        print("Hello, world!")

If you were to run either of these example applications, nothing would happen. The initialize and __main__ methods aren't run because merely running the application doesn't do any instantiation. Ruby and Python expect you to create and run an instance of the application in the source.

The proposed workarounds if you really want Java-ish main method equivalents in these languages are to write these lines of boilerplate outside the class.

MainInRuby.rb:
if __FILE__ == $PROGRAM_NAME
  # Put "main" code here
end

MainInPython.py:
if __name__ == "__main__":
    main()

I understand what these functions do, but for scripting languages that pride themselves on making life easier compared to heavy languages like Java, these don't seem all that intuitive or elegant.

I suppose one could argue that I've been corrupted into thinking I need a main method and that I haven't bothered to learn the Ruby or Python way of doing things. They may be onto something ^_^.

__EXIT__

Having used both, while I do prefer Django for my own projects, Ruby on Rails has a fancier welcome page. Sorry, it had to be said :D.

If they were really smart they'd include a picture of Reinhardt the Awesome and some wicked jazz music, plenty of both to choose from! It'd probably quadruple the size of the framework tarball, but to borrow a phrase from my sister "it'd be SO worth it!" Am I right? Don't answer that.

Yesterday I wrote a longwinded post about choosing Ruby/Tk or Java Swing to create a silly Monopoly clone for the family. Alex reminded me of Qt which is still just as easy as ever to install on Mac, but I still haven't got the Qt4-QtRuby bindings working because of a problem with Smoke.

First I got the latest complete Qt SDK from Nokia/Trolltech, then built cmake from MacPorts:

# port -v selfupdate
# port -v install cmake

Then downloaded a copy of Qt4-QtRuby and was able to get passed the cmake stage:

# tar xzvf qt4-qtruby-2.0.3.tgz
# cd qt4-qtruby-2.0.3
# cmake -DENABLE_QTWEBKIT_SMOKE=off \
-DENABLE_QTWEBKIT_RUBY=off .

But when I got to the make stage it reported an error in smokedata.cpp and proceeded to print a laundry list of errors.

Writing smokedata.cpp...
FATAL ERROR "com.trolltech.Qt.QGraphicsItem") inline void \
QGraphicsItem::setPos(qreal \
"com.trolltech.Qt.QGraphicsItem") \
inline void QGraphicsItem::setPos(qreal \
"com.trolltech.Qt.QGraphicsItem") \
inline void QGraphicsItem::setPos(qreal isn't a known type \
(type="com.trolltech.Qt.QGraphicsItem") inline void \
QGraphicsItem::setPos(qreal)

This was the reason why I was going to stick with Tk with Ruby because it comes bundled with the language and you don't need to go through all these hoops. Python works great with Qt though, so I might give that a shot instead. Or I'll just keep soldiering on with Swing.