Technical Ramblings

Hula – Open Source Groupware for the Corporate Soul.

There’s lots more out there on all aspects of this than I care to even think about, but some of the things that Nat has written about it in his weblog sound pretty cool. Personally, I have only one wish for this product: for it to become something that I can use in the workplace for task/appointment management. Currently, we’re in a 20% Windows/80% Mac world, but all the appointment management is done through Outlook and ACT!. The number of times I’ve heard the people who use it cursing ACT! is way too high, and it has the obvious problem that the rest of the office can’t use it.

I need to learn to accept that not everything is going to validate, and I need to learn that hacks and workarounds are a way of life. I need to accept that Javascript really is here to stay, and do more to learn how to make good Javascript applications, because really, they can make the entire user experience way better. Software isn’t about perfection, it’s about doing the simplest thing that could possibly work, and making things better for the user.

I wonder what I could start with… a project to learn some of the more advanced Javascript technology, while still keeping the interface usable for non-Javascript enabled browsers, allowing for linking, and so on. Google’s interfaces don’t work so well for this: Gmail, Orkut, and Google Maps all fail miserably without Javascript. I don’t like that.

Ponder ponder…

Around the time that Nokia Python was released, someone mentioned that it would be very interestig to see a replacement for the built in Nokia Notepad program. The Notepad program has many limitations: you can’t fit much text on a screen, there’s no easy way to browse or link notes you’ve written, all the typical limitations that you see when writing in a small paper notepad.

It was discussed that a small, wiki-like implementation might be a way to improve the usability of the notepad. Allow people to link between pages or nodes, let them type what they want and link it together. This would greatly improve the usability of having a phone along with you: if you can take notes on it that you can actually usee, there’s less chance you’ll lose them than paper, and you’re far more likely to be able to use something that’s connected than just write one note to yourself.

For a while, I didn’t develop anything on the phone, mostly due to technical issues related to my development process. However, after the recent Python SIG meeting, I decided that the next time I saw people, I wanted the phone to do something useful. So, I took on the challenge: a wiki-like scratchpad.

I started last night, and didn’t get too far before I ran into some symbian related problems: I couldn’t get anydbm to save anything. The file would open, it would stay open, but it wouldn’t sync, and it wouldn’t close. This morning, I finally looked at some code, and realized – wait. I need a full path. And once I got that far, things started looking up. In the hour I had this morning before work, I hacked out the basics: open a node, write to it, save, exit. Paavo on #mobitopia pointed out some other issues: the exit key handler, for one.

Then, over lunch, I created a webpage, and fleshed it out a bit more: adding a feature such that when you hit the action button, the word underneath the cursor is opened as a new node. This was about another two hours of work, spread over lunch and 10 minute breaks from work throughout the day. This included writing a program that catches keypresses and displays their associated keycodes, including learning a bit more about lambdas than I used to. I then had a working wikipad, and have since been adding minor cleanup tweaks.

In the past hour, I’ve created a beta, which allows uploading the wiki database to a webpage as POST data, from which it can be done with what you wish. (I’m currently storing the data in print_r() form, just for the sake of doing so.) From here, it’s pretty easy to imagine how this could allow reimporting the data.

So, the next step is, of course, making this work in a collaborative sense: allowing multiple people to edit one wiki via their phones. However, for the time being, it’s a great little scratchpad app, that’s only likely to get greater. You can get the code from the WikiPad Homepage.

I posted recently about Zeroconf, which allows for automated service discovery. One aspect of this which has already been exploited is the ability to have a local network of presence information, something like what iChat does to announce users who are online. However, it also passes along some simple FOAF information with it. I can’t remember who wrote the tool. If I recall correctly, it was shellac/Damien… ah, here we go. foaffinger.

Small HTTP server combined with zeroconf shares data.

Now, to expand this out a bit… now that I’m starting to know how to deal with Python a bit better, I might be able to do something with pyzeroconf and pyrple. I’d probably want to learn something about graphics too… wxPython requires an install. Are there any “built in” GUIs for Python? I don’t think so.

Anyway, local FOAF browsing of full data rather than just a subset would be nice. Not too hard, I don’t think, since Python makes almost everything simple. Of course, there is the problem that there’s no one that I share my network with… 😉

Ah well, I do have 2 macs, 2 linux boxes, and 2 windows laptops in the house now. (Wow! An even split. Nifty.) I can try it out somehow or another.

I’m kind of rambling. Usually I’d reserve this for noets, but I wanted a tie in from the Zeroconf post I just made.

There’s not a lot of webpages out there on the neat things you can do with Zeroconf. For some reason, this surprises me. I feel like it’s a pretty interesting technology, but it doesn’t seem like anyone’s done much with it, despite the fact it’s been around for quite a while. For example, AaronSw wrote about zeroconf more than two years ago.

For those who may have missed the boat, the primary thing that I mean when I talk about Zerconf is automated service discovery (DNS-SD). This is the kind of thing that allows iTunes to see the other computers locally that are also sharing iTunes music. Apple has put a lot of work into making this stuff simple, to the point that it’s one of their more popular open source releases. (Their mDNSResponder code, that is.) I know that Gnome is putting a lot of effort into making things like this work, but I don’t run Gnome (I’m a minimalist) so I don’t know where that’s really at.

Earlier tonight, I was having some problems announcing services over Rendezvous, which is the only way that iTunes will attempt to talk to a DAAP share – there’s no way to tell iTunes “go to this IP address”. This is probably by design: this way I can’t open up someone’s music share that’s not announcing it locally. Kind of annoying for me, since I’d like to be able to play my music from home at work, which I would be able to do with DAAP otherwise After some trouble, I eventually got my machine to announce the iTunes share (which is done via mt-daap) on my Linux box, so I can now play that music. I also added a few other Services: HTTP and SSH. Still, I don’t really know what I can do with these. Why doesn’t putty or some other app capitalize on this by offering to search local hosts for SSH? Does no one really use local services that this could make easier?

My Zeroconf stuff comes from Howl, which offers a multi-platform open-source solution to providing Zeroconf services. It’s a decent library, with decent tools. It is a bit iffy on the user-level: The error messages are pretty unspecific. For example, if you try to announce a service before first running mDNSResponder, it will give an error message that it is unable to connect: but won’t tell you where or why, nor is it mentioned in any documentation (that I can find). The code itself seems solid, however, and is working well here. So, what cool ideas are there for Rendezvous that no one has done anything with? And who’s going to step up to the plate to start?

One example I can think of: set up Rendezvous to announce your local MySQL servers. Then, if you’re in an office where you do development, you can just pick from a drop down of development servers: you don’t have to depend on static IP addresses, you can just scroll through a list. You can even use the text fields of the Rendezvous to include a Guest login. Seems like something that would work well for CocoaMySQL. Of course, it doesn’t look like it’s been touched for more than a year, so it’s not likely to change in the near future. Just an idea.

What zeroconf does not do, which many people don’t seem to understand, is provide any real help in actually creating the connections. Lots of people, myself included, seem to think “Rendezvous” is this magical tool that does all the network communication for you. (That is, I used to think that way – I know better now.) Really, all it does is give you an IP address – nothing that a relatively tech savvy person couldn’t do on their own, at the application level. The communication actually takes place over the typical channels – regular socket communication.

So, although Zeroconf/Rendezvous is cool, it’s not an “end all/be all” to network communication. Just something to keep in mind.

My pet Python project is redlandbot, the most popular manifestation of which is julie, an irc bot. Basically, the service allows for adding data from a URL to the local model, and then running RDQL queries against that model. As the name implies, it’s built as a layer on top of Redland, using the Python language bindings.

One of the biggest complaints about using julie, or at least, one of my biggest complaints, is that it requires namespaces to be used explicitly in some cases. Or should I say, that *was* was one of my biggest complaints: I just fixed it.

From now on, julie will automatically add namespaces to a query. It checks if there already are any (by looking for ” using < "), then adds the rest of the predefined namespaces, trying to match syntax. There may be some commands which break because of multiple spaces between "using" and "<". If there are any, feel free to fix them by simply pulling the namespaces out of the command: they will be added automatically. This allows for more complex queries with less work, which is always a good thing. Any bugs can be reported to me. This has been on my wish/todo list for way too long, and it's good to have done. I should really work on fleshing out julie/redlandbot as a web service a bit more, I think. It'd be nice to be able to just set up the service on a webpage, and use the ircbot as a very high level transport between IRC and the web interface: this would allow me to move the bot around a bit more, without needing to install Redland to use it (occasionally a bit of a pain, due to dependancies, mostly because I suck at resolving them without root).

Recently, a number of local Python users have assembled some form of organization, to the point that there is actually now relatively regular meetings of these groups of people (before other Linux Users Group gatherings, thus far). With the recent Nokia Python announcement, there’s been some renewed interest in my mobile python work, so I’m hopefully going to get some of that into shape over the weekend for a demonstration to the group on Monday, assuming I can make the meeting.

For those of you who have an interest in Python: What do you think would be interesting to a bunch of Python coders as a demonstration? Is there something that’s particularly spiffy that I could show off, or convert from being a command line application to being a cell phone application? Note thave I’m thinking relatively simply here: I only have a relatively limited memory space to work in, and I only have a small subset of modules to work with, and I’m in Python 2.2.

So, what do you see as being interesting topics/programs to demonstrate to the world the power of Python on the cell phone?

I’m really looking forward to getting together with a bunch of like-minded hackers, and racking their brains on what I can do better. I’ve never really had a good development process before, but Python developers seem to have one, especially the ones that I’ve seen discussing things on the mailing list. I’m used to LiveJournal’s spaghetti code, or writing in PHP which is typically not so well tested. It’ll be interesting to enter conversations with a group of more “formal” developers than myself.

Just looking for thoughts on what I should be working on.

For a while, I’ve moaned about the fact that the only decent collaborative editing software was SubEthaEdit, an application which only runs on the OS X platform. I’d discussed with the developers the possibility of releasing even the protocol for the application, so that other tools could interact with it, but no interest was shown in doing so. As a result, I did some small amount of work on the “FortyTwo” project – a play off SubEthaEdit and the Hitchiker’s Guide.

However, a couple days ago I was pointed to something that may soon strike fear into the hearts of the Coding Monkeys: MoonEdit, a Windows, Linux, and FreeBSD application which is free for non-commercial use.

Although it lacks a bit of the glitz and glamour that SEE sports, MoonEdit features a couple things which make it immensely better for collaborative editing of documents:

* History feature, which allows you to roll back to any point in the edit stream, from the first character to the final punctuation mark.
* Full document zoom: simply hit f12 to see a summary view of the whole document, allowing you to easily keep an eye on what’s changing.
* Standalone server mode, allowing you to set up editing of documents on a server easily.
* Macros built into the application.
* Most importantly, Windows support.

Now, collaborative editing is open to the other 97% of the world that doesn’t have a PC. Unfortunately, this app isn’t yet available on the mac platform. I’ve contacted the author, first asking where I can send him money for a donation, and secondly asking if there’s anything I can do to help create a Mac version of the program. With a mac port, it really would become a SEE killer: not as a generalized editor, but as a collaborative one.

To be perfectly honest, I have no idea how this application works. It’s a tiny, static binary – source is not available: me: ELF 32-bit LSB executable, Intel 80386, version 1, statically linked, corrupted section header size, total size 129,401 bytes. I didn’t realize things still came that small. However, I can tell you that using this application is extremely cool. What it lacks in polish, it makes up for in usability, both due to wider platform distribution and to the History feature. You can also save documents with full history, allowing you to open them offline and read through the changes that were made.

MoonEdit is the way of the future. If I can get a Mac binary out of the author, I will be an extremely happy camper. If you’re using a mac and want to have a cross platform collaborative editing program, you may want to send an email to the author as well, asking for support; I haven’t gotten a response yet, but given significant motivation (Think $$) most coders will take care of their audience.

The response Sean, Cody and myself have had to RSS 1.1 has been mostly positive, and we’ve gotten a number of suggestions for ways to make it better. We’re going to be working over the weekend to implement these changes into the schema, and releasing a second draft on Monday sometime.

The response was, all in all, pretty good: We’ve had some good people on our side, offering encouraging comments on the specification. At the same time, there is the all too common “Oh no, not another RSS version” that you get in the case of anything new. I can honestly say that I think most of these comments misunderstand the goals that were being worked towards by RSS 1.1.

If you are not using RSS 1.0 right now, do not worry about RSS 1.1. It is designed only to fix the bugs that RSS 1.0 has, due to the fact that it’s 5 years old. If you try to drag me into politics: whether it be on whether another RSS format is good or bad, or on other things which are unrelated in a change from 1.0 to 1.1, you are misunderstanding the original intentions behind this format.

It is a possibility that given a better defined specification, using the current version of RDF rather than the one that was available 5 years ago, some people who are not using RSS 1.0 now may want to make the switch to RSS 1.1 (if it achieves support in the community). If you do, great. If you don’t, also great. I have no interest in converting those of you using RSS 2.0. I have no interest in telling you to stop using Atom. I want a technical improvment over RSS 1.0: and RSS 1.1 does that.

At the same time RSS 1.1 was designed to fix bugs with RSS 1.0, it was also designed to make it easy for aggregator developers to develop support for it. Complete backwards compatibility, although wonderful, would have been so limiting as to make any changes to the schema useless.

RSS 1.0, although it still had an existing working group, was not being developed further. To work in the working group atmosphere would most likely have stifled creation of the new specification. Although some may think this is a bad thing, I think that RSS 1.1 does fit the needs of a small group of people without putting an ardurous strain on the people who develop tools for it.

In the end, lots of people will be unhappy with any new syndication format. The motivations behind this move, however, are entirely technical, rather than political, so, as Sean said at one point, most political arguments against it “concern us not”. The technical questions, on the other hand, do concern us, which is why we’ll be working to craft a second draft as quickly as possible, to get further feedback from the community.

As a developer, for a long time, I believed RSS 2.0 to be significantly superior to RSS 1.0. It was a more popular format, more people had heard of it, but most importantly, it was easy to create. In comparison to RSS 1.0, creating RSS 2.0 documents was downright trivial. There was no need to have the goofy “rdf:RDF” tag at the top, with all those weird looking URIs for some reason no one could tell me. Clearly, at the time when I was thinking this, I was not aware of RDF or the benefits of it. As time went on, I realized the benefits of the RSS 1.0 way of doing things, most importantly, that the content is RDF.

However, RSS 1.0 is still a relatively confusing format to implement to a non-RDF aware developer. The “table of contents” listed in the rdf:Seq is redundant, and to a lot of people who are used to working in XML and not under the constraints of RDF, confusing. The documentation on all the RSS formats is quite weak. A table comparing what each one offers is hard, if not impossible, to find, especially since most such lists are biased towards the writer of said list.

As I’ve become more and more involved in developing tools relating to RDF and the Semantic Web, RSS 1.0 has become more and more of a sticking spot in my experiences with people. They are soured by their 1.0 experience: a feeling I can not blame them for, as RSS 1.0 is constrained in many ways by the circumstances under which it was developed.

Fed up with dealing with a less than optimal format that was truly leaving people feeling negatively towards RDF in general, I decided that I was going to work on something that would be better for RDF and RSS. I was just going to write it myself, but luckily for me, I had the help of a couple of friends.

sbp, and myself, along with many a helping hand from d8uv, have written a specification we are labeling RSS 1.1. From the Specification:

This specification is therefore made available by users of the RSS 1.0 format who wanted to update the specification to make use of the latest features of RDF in order to reduce the redundancy in the format, and the ambiguity in the specification, while at the same time implementing a series of bugfixes from the lessons learned in developing the other descendent of RSS 1.0, Atom.

This specification comes with a full Test Suite, a validator, and a number of other resources, from background information to implementation details in several different types of configuration.

We have formed a channel for discussion of RSS 1.1 related issues on Freenode: #rss1.1 on irc.freenode.net. If you are interested in using the specification, or would like to offer your opinions, you can stop by there to talk to us.

This specification is not designed as competition for Atom: it is designed only as a bugfix release for RSS 1.0, and is not designed to compete with any other existing efforts. There were a significant number of issues with RSS 1.0 that had been raised over the years, some of which were relatively important from the standpoint of a lazy developer such as myself. Hopefully others will feel a similar way.

Many of you who know me on IRC and other similar places will know that I have a wonderful partner-in-crime, Jessica. Together, we are rel:parentOf to Alicia and Julie. Julie, unfortunately, has a bad ear infection today, and is therefore getting ice cream for dinner, per doctor’s orders.

Julie decided that she wanted to come with on this trip, despite having a fever of 103. She said “I’m four, I can come!” Of course, this request was denied, at which point she repeated her assertion.

Repeated assertions reminded me, naturally, of RDF, so I expressed her statement in RDF: :Julie foaf:age “4”. (Which, verbally, is “Julie foaf:age 4”.) Our roomate looked askance at Jess and said “Ya know, he’s going to express your wedding anniversary in FOAF so he can’t forget.” Jess’s joking reply was “One of these days, I’m going to break up with him because he can’t stop whispering sweet RDF nothings into my ear.”

My response, naturally, was :ChrisAndJessBreakup log:implies “sad”.

(All terms, RDF and otherwise, in this entry are considered non-normative and non-validating. Do not use data from this entry for the basis of forming real RDF documents. I don’t understand rules, and I have no idea what log:implies does, so I probably used it wrong. But it was funny.)