This might be interesting to those who enjoy staring at ASN.1 encoded data like certs, digital signatures, or *gasp* Sun's Fast Web Service data streams: a ASN.1 editor written in C#.
WARNING: Using the ASN.1 editor might make you want to slap some lets-replace-XML-with-ASN.1 folks around.
Today, IE reported that my main blog page had script errors so I looked at the HTML and found that RDF fragments were causing the problem. What the hell is RDF doing in my blog web page? Each blog post item had this RDF fragment preceding it.
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
<rdf:Description
rdf:about="https://blog.docuverse.com/2003/08/28.html#a845"
dc:identifier="https://blog.docuverse.com/2003/08/28.html#a845"
dc:title="Tim Oren on Subsidized Wi-Fi Business"
trackback:ping=
"http://radiocomments.userland.com/comments$trackback?u=112479&p=845"
dc:creator="Don Park"
dc:description="Tim Oren adds a VC perspective to my Subsidized Wi-Fi AP
idea.&nbsp; He wrote: [...] the average usage per Starbucks site is
three sessions per day."
dc:date="2003-08-28T17:18:24-07:00" />
</rdf:RDF>
<
p dir=”ltr”>Unless I am mistaken, RDF fragments are being inserted automatically by Radio Trackback script. Yikes.
Sun released JDK 1.4.2_1 today. Aside from the usual bug fixes, JavaUpdate is enabled again by default. You can turn it off from the Update section of Java Plug-In Control Panel. Note that you might not be able to turn it off if you don't have administrator rights. At least that restriction was among the list of bug fixes.
I don't have much time to elaborate, but I wanted to jot it down here as a note to myself. Yes, I find myself using my blog as PostIt of sort. I gotta pursue that idea later as well.
Distributed Wiki is what you get when you take something like HTMLHelp and add Wiki-like editing capability and content synchronization via a central server or P2P.
More scattered bits. Manuals as whiteboards and discussion forum. Continually updated product documentation. Kill view and sliding filter bar. Admins updating and customizing contents especially terms by replacing generic terms with domain specific terms. Local cache of content with updates trickling in and out. Living documents.
Ray Ozzie's Groove is a good platform for this stuff. ShareDoc. HelpShare. LiveHelp?
I got pelted by about 20 SoBig.F virus laden e-mail on Friday. This morning, I got 20 more and the storm continues where it left off Friday. Since other people are having a much harder time than I am, I guess I am sitting in a nice quiet paranoid patch of the online social network.
Everybody will learn to live with waves of virus storms like the way they deal with real world showers and storms. Hmm. I wonder Yahoo will do Virus Forecasts along side Weather Forecasts?
BTW, if you sent me e-mail and I haven't replied, chance is good that it got thrown out in my daily pile of spam and virus. As a last resort, you might try leaving me a comment to one of my recent blog posts or post a blog of your own referencing my blog so I can find it via trackback or Technorati.
Negotiation is a fascinating yet difficult subject. First negotiation probably took place in the Ice Age between cavemen, but the art of negotiation hasn't advanced much since then.
While there are countless papers on negotiation theories, strategies, tactics, psychology, and even philosophy, negotiation still comes down to people talking face to face, just like the cavemen.
Ross Mayfield's Negotiation and Social Software post got me thinking about web-based negotation tools. Ross writes:
Social software can support negotiation, at the least, by revealing what kind of argument is in play. […] There are three kinds of arguments: Fact, Value or Policy. You can argue over what is, what should be or how it should be. […] Social software can support negotiation, at the least, by revealing what kind of argument is in play.
Unless I am mistaken, Ross wants to use tools to identify and classify arguments. Assuming Ross is thinking about using Wiki, I am not sure how effective this approach is using purely textual solutions like Wiki. I am of the opinion that more visual approach is necessary.
Ross also touches on an important point:
Tools that allow mediators the flexibility to structure dialogue while deemphasizing personalities can accelerate constructive conversation.
Personalities and emotions are difficult to isolate and deemphasize in negotiations. Even act of doing so can backfire. I think a game-like interface might encourage negotiators to detach themselves emotionally from the arguments similar to the way chips in casinos detach gamblers from monetary value.
People often see negotiation as a game of sort. Unlike games like Chess and Go, negotiation has no game board nor game pieces, just an optional table to rest hands on and mouths to create or move pieces in your opponent's head.
What would negotiation look like as a game?
Here is my Swiss Cheese answer.
Game area looks like a Crap table, a flat surface divided into two major areas: Common Areas and Player Areas. Two-party negotiation would have one Common Area and two Player Areas. Each area is divided into subareas representing player-specified categories. Some area-specific effects would be interesting.
A mediator is a player with some special privileages such as ability to view hidden pieces. More than one mediator can participate in a game.
Game pieces look like a stack of chips and can be created by any players. When a player creates a piece, matching piece appears in each Player Area. Height of a piece is determined by its value which is assigned by the player who owns it. Hidden pieces are visible to all but it's content is opaque to all except the piece creator and mediators.
A Deal is a Wheel-like balance in the Common Area. Players contribute pieces to the Deal using the pieces' value as weights. If a Deal is balanced, it lights up in green color.
<
p dir=”ltr”>Like Swiss Cheese, it has a lot of holes yet to be filled, but I like the way the issues are visualized and players become detached. Call it work in progress. <g>
I have been using SpamBayes since others have suggested it in response to my Death of E-Mail post. SpamBayes is good, probably good enough most of the time, but not good enough for all the time.
SpamBayes is like my wife. Since my wife pays the bills, she also does the mail. Everyday, she checks the mail, throws out apparent junk mail, set aside bills, and brings me the rest. With her standing there, I separate junk out so she can recognize new types of junk next time. After ten years of this, she rarely has to bring me mail.
One key advantage my wife has over SpamBayes is that she can expect important mail like tax refund or my son's report card. She knows ahead of time when, from where, and how (i.e. FedEx or US Postal) mail will come. She also handles unexpected mail well. This is why I trust her and why I don't trust SpamBayes completely.
Despite all the fancy algorithms behind today's spam filters, all they do is tossing mail into a trash can. This is sufficient most of the time, but is prone to failure at exceptional times.
When was the last time you digged into your trash and why? Would you do that daily? You can't do it weekly because the pile would be way too big, even daily pile is starting to get too big. You won't unless there are some important e-mails you have been expecting. That leaves important yet unexpected e-mails that get thrown out every day with rest of the garbage.
<
p dir=”ltr” style=”margin-right:0;”>Message to my wife: Honey, you are so much prettier than SpamBabes, er, SpamBayes.
Typical rollover uses multiple images, one for each state. Petr Stanicek shows how CSS2's background-position attribute can be used to do rollover with just one image containing subimages for multiple states. Cute. Via Paschal L.
For the impatient, here is the meat:
#menu a { …
background: url("button.gif") top left no-repeat;
… }
#menu a:hover { …
background-position: 0 -39px;
… }
#menu a:active { …
background-position: 0 -78px;
… }
Head-Body is a well known design pattern for markup languages such as XML, HTML, and RSS. Most common example is HTML which has <head> and <body> elements under <html> root element to separate metadata from content. Another example is SOAP where Head-Body pattern is used to separate information on the envelope from the payload inside the envelope.
While the Head-Body pattern is well-known, it can be confusing in practice as Mark Pilgrim and Sam Ruby's recent posts indicate. The pattern also adds verbosity and complexity to document structure and language bindings because it adds an extra layer of elements between the container elements and contained elements (i.e. dog.body.tail instead of dog.tail).
I came up with an alternative to the Head-Body pattern while waiting for Vikingsholm tour to start at Emerald Bay: the Neck pattern. The basic idea is to use a divider (<neck> element) instead of two boxes (<head> and <body>).
Here is a silly example of Head-Body:
<animal>
<head>
<eyes>2</eyes>
<nose>1</nose>
<mouth>1</mouth>
</head>
<body>
<legs>4</legs>
<tail>1</legs>
</body>
</animal>
And here is Neck version of the same:
<animal>
<eyes>2</eyes>
<nose>1</nose>
<mouth>1</mouth>
<neck/>
<legs>4</legs>
<tail>1</legs>
</animal>
FYI, the Neck pattern is an instance of the Road Sign pattern.
Next-App Button is too geeky and not hip enough so I came up with a more catchy name: Appy, which I hereby define as Application Happy. Hey, I like it! I am so Appy!
I wonder which cellphone or PDA will sport the Appy button first?
Don Park's Weekly Habit 