Category: Technology

Threadneedle just got competition

Post author By Shelley Powers
Post date August 25, 2002

Ben and Mena at Movable Type just released a Trackback threading tool that will build an entire tree out of MT trackbacks. Here’s a page showing the Trackbacks from one of my earlier postings

Yes, this is what ThreadNeedle is supposed to do. Yes, ThreadNeedle is not finished.

When you enable TrackBack for a posting, Movable Type embeds a small piece of RDF in the page, such as the following:

<rdf:RDF xmlns:rdf=”http://www.w3.org/1999/02/22-rdf-syntax-ns#”
xmlns:dc=”http://purl.org/dc/elements/1.1/”>
<rdf:Description
about=”http://burningbird.net/cgi-bin/mt-tb.cgi?tb_id=17″
dc:title=”World Summit Weblog”
dc:identifier=”http://weblog.burningbird.net/archives/000476.php”
dc:subject=”Politics”
dc:description=”Many thanks go out to Farrago for pointing out that there’s an extremely well organized weblog covering the World Summit. Now, this is what a political weblog is all about. Take a look and tell me you’re not impressed with…”
dc:creator=”shelley”
dc:date=”2002-08-2514:00:27-06:00″ />
</rdf:RDF>

This simplified RDF can be embedded because all of the RDF data is treated as attributes — notice that there’s nothing outside of the Description element? Attributes don’t get printed out via the parsers in the browsers.

So, why can’t I do this with ThreadNeedle? Two reasons.

First, I can’t control the output of the weblogging tools, so if I give you a piece of RDF to embed in your posting, the weblogging tool will try to add break tags (< br/>) to the code to handle line breaks in the RDF. This screws up all RDF processors.

Secondly, anything more sophisticated then the example I showed you requires special handling to embed the RDF in HTML/XHTML. Surrounding the data with the Script tags will work — the parsers ignore anything contained in script tags. However, this still doesn’t solve the problem of weblogging tool munging.

I can generate RDF, and it’s very doable to create an application that finds the RDF, and follows the threaded entries to the new page and looks for embedded RDF and so on (as the Movable Type Trackback threading application does, except that it uses the Trackback data stored in our local data stores) but I can’t control the munging of the RDF by the weblogging tool.

Ben, Mena, this was cool. Really. And thanks! I hate to be greedy, but can you and Ev and Dave and the other weblogging tool builders give us a window in the weblog posting page to include content that is embedded directly in the posting, without manipulation by the weblogging tool? Then others, such as myself, can provide functionality — such as ThreadNeedle — that isn’t dependent on the weblogging tool and without having to go through extraordinary means of handling this markup munging problem.

I realize that webloggers can turn off line breaks (either for a weblog or a posting), but many webloggers don’t know how to include their own HTML line breaking tags. What I’m looking for is the best of all possible worlds — a separate window that takes text which is added to the bottom of a weblog posting without any processing by the weblogging tool, while still allowing tool processing of the weblog entry itself.

Pretty please?

In the meantime, I have the Movable Type Threading CGI application running (Access here, pass in the URL of the page with Trackbacks). Feel free to try this with pages that have TrackBack enabled. If it slows my server too much, I’ll have to pull it, but we can give it a try for now.

Technology

The geeks have it

Post author By Shelley Powers
Post date August 21, 2002

Jonathon has become the latest recruit to the Geek Force. I’ll have to send him an autographed copy of Unix Power Tools 3rd edition as soon as it’s published. Just think, Jonathon– 1200 pages full of tips!

(Makes a good doorstop, too.)

And now Jonathon can join us in the most important debate of geekdom:

Which is better? vi/vim? Or emacs?

Blood has been spilled over this issue, so use caution when responding Jonathon. In fact, there are many items that generate an almost religious ferver within the Unix world as you’ll find out…soon.

Technology Weblogging

They are intriguing

Post author By Shelley Powers
Post date August 15, 2002

I’m not normally into tweaking the technology for the weblog, but I’m getting pulled into the lure of MT-macros, primarily through Mark Pilgrim’s infectious enthusiasm.

I rather like that acronym macro. And while I’m at it, I should incorporate better search. And I should think about converting to pure CSS and getting rid of my HTML tables. And since I’m in the neighborhood…

Whoa! Time out! RDF book to finish. ThreadNeedle to finish.

Must…not….blog. Must….not….play with blogging tools. Must….not….tweak site again. Must….not….

update Mark, did you mean <$MTEntryBody$>?

Technology Weblogging

Updates and a banana

Post author By Shelley Powers
Post date August 10, 2002

Some updates:

First of all, work is progressing on ThreadNeedle. My first implementation plan had to be scraped when I found that the Redland RDF infrastructure doesn’t seem to want to work on my FreeBSD machine. Additionally, the Redland Perl code also overwrote the existing Perl RDF libraries, and broke my content management system. I moved development to my J2EE environment, but I’m finding that this environment might be more of a resource hog than I can afford on my machine (you all might notice slowdowns in access at times).

However, work is progressing on it, I haven’t dropped it, it’s still important to me.

Second, I started an idea about a weblogging consortium, which received a great deal of commentary. I think the idea is worth at least further conversation and when I’m finished with the RDF book and ThreadNeedle, am starting this up. As per Matt’s suggestion I had planned on starting a wiki on this, but a friend has been sending me suggestions for other tools, including Andy’s RabbleRouser. I want to check these out, in addition to a wiki solution.

This friend, BTW, is Michael Mussington, a person who’s always sending me links to fun and interesting things, particularly when I’m being battered about. If for no other reason, you weblog to meet people like Michael.

(Michel, sorry, but I just “outed” your weblog.)

For those who follow my comings and goings with such passionate interest I have news for you: this is a fact of life. Get used to it. If you have a problem with me taking some time off and taking a break or quitting or starting again, take it up with management. Add your 0.02 to the comments. Otherwise, get off my fucking back.

On to more interesting stuff: warblogging (a particularly tasty, juicy piece), Bob Dylan, XHTML or Rejection.

Technology

The Line-of-Sight Developer

Post author By Shelley Powers
Post date August 7, 2002

I heard the term “Line-of-Sight” in reference to certain breeds of dogs, such as the Afghan.

It seems that these dogs have this instinctive urge to run towards the horizon, and if they get loose, they’ll keep running towards the horizon at full speed until their owners catch them (fat chance) or until they run out of steam.

My brother and his family have a Greyhound/Great Dane mix dog named Hillary that’s a line-of-sight dog. The problem is that she has the speed of a Greyhound and the size of a Great Dane — not a dog one takes for a walk without a great deal of trepidation.

These pooches just can’t help themselves: they see, they do.

Odd thing, though, is that I know of developers that are like line-of-sight dogs: they see, they do. The problem is that you can’t leash these folks up, at least not without breaking several laws of the land.

The Characteristics of a Line-of-Sight Developer

How do you recognize if you work with a Line-Of-Sight (LOS) developer, or are one yourself? Well, there are several warning signs to look for.

You receive an email from another team member that they have “improved” the performance of a key element in the application your team is working on, have checked in the change and is ready to move it into production. Unfortunately, none of the rest of your team knew that the developer was working on this key piece of code, much less what the change was, and how it will impact on the rest of the application. Congratulations, you’ve just identified a LOS developer.

During a team meeting, you discuss the possibility of making a change to the user interface of an application, but decide to wait and get additional information. The next thing you know, the change has been made. You track the change down to a specific developer who states “Well, I had some time so I thought I would go ahead and implement the change”. Yup, one of the classic characters of the LOS breed is the words “Well, I had some time …”.

In an environment where clients have direct access to the developers, they always approach the LOS developer with requests for changes. You see, it’s an established fact that Clients instinctively know which developer will make the requested change without question. This ability is part of the client’s built-in survival instinct.

The LOS developer can program better than anyone else — at least, that’s their own opinion. So, they’ll fix other team members code whether the code was broken or not, inefficient or not, up to specs or not. After all, it’s a tough job, but someone has to do it.

The LOS developer: they saw, they did.

Two Different LOS Breeds

There are actually two different breeds of LOS developers.

There is the “I’m inexperienced and very eager” LOS developer. I call this type of LOS developer the “WOWIC” (Watch Out World I’m Coming) developer.

The WOWIC LOS developer brings the unanticipated changes they make to you for praise and at that point, all you can do is tell them they’ve done a good job, and give them a stock option to chew on. After all, to beat them about the head with a project plan will only break their spirit — you have to approach their training more cautiously than that.

The second type of LOS developer is harder to work with but thankfully less common than the WOWIC LOS developer. The chief signs of this type of developer is their arrogance, so I call this breed the AAH (Arrogant A**H***) LOS Developer.

You can easily recognize the AAH LOS Developer — one of their chief hobbies is to go through their teammates’ code and change it to what they believe is better code. If the teammate disagrees with the change, the AAH LOS developer looks at them as if they were an amoeba that just started to sing the “Star-Spangled Banner”. No one disagrees with The Programmer.

Dangers of LOS

Anyone who has worked on a larger application knows how dangerous a LOS developer can be. What may seem to be a simple change in the code for one application module can have disastrous effects on the application as a whole. If the change is in shared code, the developer has a responsibility to inform others before making the change. Better yet, the change should be incorporated into a staged development rollout, to ensure appropriate testing.

Another danger of the LOS developer is to the morale of the team. If you have a developer, particularly an AAH LOS Developer, grabbing other people’s code and changing it without legitimate cause you’re going to have dissension in the group. This type of behavior is discourteous. This type of behavior is costly to the development effort. Really, this type of behavior is just plain rude.

To make changes daily or even weekly and just plunk the code in without a plan only disrupts the work of other developers. I’ve found that any language that supports class inheritance, such as Java or C++ is particularly susceptible to this type of “ad hoc” code changing.

Is there a cure for LOS?

As stated there are two breeds of LOS developers, so there are two cures.

Having a well-established change control system and good software development procedures in place are about all you need to train the WOWIC LOS developer. They’re eager to please so showing them that good programming practices and teamwork support are just as valuable as lines of code will get the point across, quickly.

How about the AAH LOS Developer? Well, sometimes all you have to do is tell the AAH LOS Developer that they’ve tromped all over the team’s code and to please not do so in the future. If they’re more arrogant than A**H*** this could work.

However, the best approach with the AAH LOS Developer is to again set procedures in practice that curb the more I, PROGRAMMER urges of the AAH LOS Developer. In other words, track what the person is working on, and keep them busy enough with their own assignments to leave other people’s work alone.

Oh, did I mention that you need to have good programming practices, change control, and well understand project plans in place? I did? Just wanted to make sure.