• conv/title
• lang = en
• style/fontWeight = bold
• style/fontStyle = italic
• style/textDecoration = underline
• style/textDecoration = line-through
• style/fontSize = 2em
• style/color =r gb(229, 51, 51)
• style/backgroundColor = rgb(51, 127, 229)
• link/manual = http://example.com/

A Python example of using the above:


msg = "This is a message for you"
doc = wavelet.GetDocument()
doc.SetText(msg)
doc.SetAnnotation(Range(msg[-4:], len(msg) - 1), "style/fontStyle", "italic")

The above should italicise the word “you” in the variable “msg”.

According to Google employee ‘Pamela’, this isn’t set in stone “as we aren’t confident in their stability”. Thanks to Dave of the same Google Group thread for documenting and posting the styling annotation name and value pairs.

Hope that helps someone ;)

One of the frustrating things about developing Google Wave extensions is the poor documentation. It starts out great: lovely overview documentation and tutorial, with plenty of insight and step-by-step instructions; and then nothing. It stops there. Apart from reading the API documentation which can be cumbersome, you’re left alone in the dark, weeping like a sad puppy after meeting its new owners.

An example of this is using Annotations within Google Wave; formatting text for bold or italics,  providing nicely worded hyperlinks or embedding images is governed by inserting annotations that ‘explain’ how the text should look. If you try to find out how to use these objects within the Python API you’ll see it’s nearly impossible. I got my answer only from guessing and scouring the Google Group and reading and example in Java, then posting when that didn’t work and finally getting some helpful advice. Please Google, document this protocol more!

So, to save an further frustration, here’s how to use Annotations in the Google Wave python API for robots:
doc = wavelet.CreateBlip().GetDocument()
doc.SetText("THIS IS ANNOTATED TEXT")
doc.SetAnnotation(Range(2, 12), "link/manual", "http://www.google.com")

I hope to hell that helps someone and saves the pain I underwent to work it out! Buggered if I know how to bold text though…Happy hacking!

So I managed to join the select elite bandwagon that is the Google Wave preview, which entitled me to early access to Google’s new masterpiece and 8 invites to bribe friends with (although I only have a few, so the whole eight might not stretch too far…). I have to admit, I’m not sure what the fuss is about. It’s clever, really clever; but there’s not much to it yet. It is, for all intents and purposes, a well-marketed collaboration tool, or put simply: a clever chatroom. Time will tell though. Perhaps its usefulness is yet to be seen.

Being a devout geek, and a sucker for anything Google, I was led to explore the programming possibilities behind Wave. Rather brilliantly Google have created an API that will allow you to do one of two things: create a ‘Robot’ – an automated participant programmed by you – or embed your own ‘gadget’ in a wave (think a Google map, but your content). The API is rich, if its documentation can be a bit light in some respects (where the hell are the CreateBlip() and such methods documented?! All you get in the API docs are ‘Get*’ methods…pointless!).

Introducing Wave Toolkit

Having programmed plenty of bots for IRC and Eternal Lands over the years I had the experience and ideas behind creating an automated character that can be used to aid users, or simply provide a bit of light entertainment. So after plenty of reading and hacking, I managed to come up with Wave Toolkit; a simple Python robot for wave that provides features that are either lacking or a little tool that might aid your chatroom…err I mean collaborative-blue-sky-thinking…yeah.

To get a bot running you do need a Google App Engine account, which allowed me to explore this little world offered by Google. It’s cleverly done and nicely polished. Still think it’s just cleverly managed free-hosting though ;)

The capabilities of robots within the Google Wave extension API are pretty much exactly what a human participant can do: edit, post, delete and edit ‘blips‘, create waves, see who’s participating and apparently manipulate playback. It’s very fun writing something that can do all this too; that wonderful satisfying feeling of achievement when you spam “hello world” to a wave…

Wave Toolkit’s in constant development so it might be a little ropey, but please feel free to add wave-toolkit@appspot.com as a contact and invite it to a wave, and feel free to suggest new things, report bugs or even tell me you love it. ;)

So back to coding more lovely Python, and perhaps writing something useful for all the wavers out there. Right? ;)

Pyela is an object oriented (OO) API for communicating with an Eternal Lands server. It aims to be a simple wrapper for socket operations and messages that pertain to the undocumented Eternal Lands Network Protocol. A demonstration of the API is easy to see in the Pyela – GUI application, which is a Eternal Lands chat client written using Pyela. You can download that here.

Pyela is released under the GPL3 and is open to patches and any suggestions you may have and is hosted by Google code – pyela.googlecode.com.

Background

Before I start, I want to explain my programming background with Java and other languages, so this post isn’t regarded as Just Another Flame ™.

I am a Sun Certified Java Programmer, and have been contracting for 3 years here in the UK. I have worked for two large companies (no names) that have given me excellent experience with the Java programming language and its use in the Enterprise tier. As well as Java, I have been required to develop in SQL (both Oracle and MySQL, as well as MS-SQL), Perl (CGI and scripting), BaSH and the usual web design/development languages HTML, Javascript and CSS. I have recently taken to learning Python, the high-level dynamic object oriented programming language, and doing so has prompted me to post this article.

Common Misconceptions

A lot of the Java doubters out there tend to blow the same trumpet; sing the same tune; fuel the same fire – that is, they all say ‘Java sux!!11′. The problem with this, is that Java is all of three things: a programming language, compiler, and virtual machine/interpreter. This means that those blabbering on about how ‘Java sux’ don’t direct their comments at what particular part they dislike; that is whether they hate the language itself, the compiler or the interpretor. Not only is this an inaccurate flame, but it’s usually bellowed by those who have very little to no experience with the programming language or its uses. At best, they’ve tried to run a Java program and due to their own lack of understanding or misconfiguration, it hasn’t worked. However, some people who flame it do know the language and its software components and therefore have an educated opinion. I prefer, and indeed regard myself as, the latter.

One of the other wondrous clauses that Java-haters tout, is that it is slow. Well, they’re mostly right. Again there’s more to it than just speed. The first releases of Java were very slow. Fact. However, the latest releases (Java 5 & 6) have added language features that speed up the run-time execution of Java code – namely parameterisation of types, auto boxing/unboxing of primitives to objects – by forcing compile-time checks as opposed to run-time checks of types (the old object cast when adding/retrieving to/from collections is now unnecessary). Whilst these features do speed things up, Java is still relatively slow.

Now, on to the flame…errr, constructive criticism.

Java’s too Strict

Java has prided itself on two things – strict object orientated design (OO) and ‘Write Once, Run Anywhere’ multi-platform availability – and has been both accepted and rejected on the merits/pitfalls of these features. I don’t actually see anything wrong with OO design. In fact, it’s my preferred software development approach. The issue with Java’s strict OO design, is that it’s very difficult to program otherwise. You’re forced to stick to OO practices whether you’re writing a quick hack, or a fully-fledged framework, and this forces its usefulness to be restricted. This isn’t the case with Python. It’s so dynamic and productive to write, that it can be used to write a quick backup script or large back-end services.

Java is also a strict-typed language. This means that at instantiation, objects are given a type (or ‘class’) and the compiler enforces this. If an object needs to change type, it must do so through the ‘Polymorphism’ object oriented design approach. This is enforced by Java at runtime. It’s another extension of Java not allowing you to make the decision over what software design approach you’re going to take – procedural or object oriented – so you’re stuck from day one. Languages like Python and Ruby are not strict-type. This means the programmer has more flexibility (but has the overhead of ensuring specific types at runtime, and checking thus) over how specific aspects of a program treat information.

Java’s too ‘wordy’ – a.k.a Verbose Syntax

The nature of OO design means that more code is written to define objects and their relative connections. Java does this well, with a nice object hierarchy, but it’s a victim of its own design and conventions – accessors/mutators (‘getters’ and ’setters’) mainly – whereas in languages such as python, the convention isn’t to use this approach, but to expose an object’s properties either by direct dot notation, or to define it as a dict. You can still do this in Java, but obj['val'] is much easier to write than ‘obj.getValue()’. You might see this as a moot point, something that’s purely implementation specific, but in reality anyone that knows how to write Java, will stick to the strict convention that objects should hide their underlying implementation. This is definitely a good approach to software design, but in practice it becomes too much of a burden on a programmer to write and use such design aspects. Not to mention it doesn’t bode well with the 80 character per line rule…

Another example of Java’s ‘wordy’ syntax is the Collections API. Once touted as its glorious achievement, the Java Collections API was an outstanding set of objects aimed at providing objects – an extension to the typical array – that provide easy, OO and fast access to a collection of objects. With the emergence of other languages however, the Java Collections API has become rather stagnant due to the language’s lack of dynamic syntax. Below are two examples, one of defining and iterating over a list in Java 1.5 and the other iterating over a list in Python 2.5:


List<String> list = new List<String>();// define a List that contains only String objects
list.add("Herro");
list.add("Moo");
list.addAll(myOtherList);
for (String str : list)
System.out.printf("Item: %s\n",str);


And the exact same operations in Python 2.5:


list = ['herro','moo']
list.extend(my_other_list)
for item in list:
print "Item: %s\n" % item


4 lines of code, or 6? Stretch that out over a large application (what application these days wouldn’t use lists or maps?), you can see that code written in Java would become quite large, purely because of the language’s syntax. Programmers like to program, they don’t like having to write more than they need to. Python allows you do write exactly what’s needed, and without having to write 100 words to do so.

‘Write once, debug anywhere’

The ability to run an application on any operating system without the need to recompile is a nice idea. Java’s main selling point is that it has this ability. Initially this was a useful and much desired feature of the language because not only did it work, but it was at an age where the Web was booming (pre-2000) and new technologies were on the uptake. Nowadays, the platform is the Web. This means you don’t necessarily need inter-platform abilities from a language and compiler/interpreter. You just need a working web browser, and an internet connection. Indeed, with the rapid adoption of AJAX (Asynchronous Javascript and XML), web sites are now replacing the desktop application. Software As A Service (SAAS) is now the forefront of software development and business aims, and the need for desktop applications becomes ever smaller as more and more websites offer an abundance of features from the web browser – just checkout GMail, EyeOS or Google Maps – and you’ll experience feature rich applications, all in the comfort of your web browser.

What’s next?

Undoubtedly Java will remain a large part of the industry for the next few years. Sun are a large and powerful company, and are good at keeping things alive. Not only that, but they’ve recently released Java under the GPL , so it’ll be around for a while yet. Some might say that this was part of a clever marketing campaign to get people back in to using Java. Either way, I can really only see its demise as more dynamic, open source, reliable technologies take the driving seat.

Java still has a large place in the enterprise market. According to this site, it’s the number one language (in terms of job opportunities, third-party vendors and courses); but as with all statistics, i’d take that with a pinch of salt.

Summary

I’m not a Java-hater. It’s paid my bills for the past few years, so I owe it some credit. Due to my recent adventures with Python though, I immediately saw the flaws in Java. Python makes things quick to write. It’s powerful, ever maturing and more to the point – it’s open source. I think Java will stick around for the foreseeable future, but its original merits are no longer going to keep it alive…