Cafe Bucky

I’m going to sound like such a fanboy saying “TiddlyWiki Rocks”. But heck, it does. So check it out at tiddlywiki.com. In a nutshell, it’s a self-contained Wiki within a page.

I came across it while doing research into all things AJAX and XMLHttpRequest-ish. To me, it’s yet another example of how boundaries are getting pushed in all directions in the “old technologies being used in new ways” meme. I realize it isn’t strictly AJAX. The fact that it dynamically updates is where it’s at. It’s impressive.

The goal I’m after is to implement what I was talking about in “IFrame Sub-Posts?”. The TiddlyWiki is a bit of functionality that I find inspiring. The one thing I would add to is the ability to upload itself to a server (which dovetails into my interest in XMLHttpRequest).

These are fun, fast-moving webdev days we’re living in!

Paul Graham wrote Hackers & Painters, which I was interested in reading, way back in June 2004. It’s finally available on Safari, so I’ll plunge in this week.

I gotta thank my pal Mike Schilli, because I mentioned H&P and Safari to him, and he pointed me at an excellent essay by Paul, entitled “How to Start a Startup” I don’t agree with absolutely everything in it, but I’d go as far as to say that it’s a “must read” for anyone thinking of starting a tech company. He’s been there, and shares his experience in an enjoyable read (chock full of great advice, delivered in a matter-of-fact manner)

A few of the best bits:

• work with good people that know the area of expertise. Don’t hire business people that don’t understand the tech (”newscasters”).
• don’t hire solely to fill up holes in an org chart
• use trade shows as a means of research - chance to listen and learn from customers as to what they want
• important to get a first version out there quickly
• best odds are in niche markets
• don’t burn up startup money on flashy offices (and, location is very important - got to be a place where people want to come back after dinner)

Jason Kottke has decided to quit his day job and blog full-time. He won’t be accepting ads, and will derive his income from micro-patronage.

I hope it works for him! There are only so many artists, performers, creators that can make a go of doing what they love full time. I think my writing would warrant a Mocha (hmm, perhaps just a single) every other week month or so. (but while y’all are holding off, I’ll keep buying my own :-)

I don’t know Jason personally (I see him at Apple SoHo, or ETCon), but my impression is that he’s at a good stage of life to do the all-out risk-taking thing. Perhaps it’s not so much of a risk. He knows he has tons of readers, and 7200-odd links from Google to his site. I’d wager that he has a good chance.

The last bit here is: will it change how he writes? It’s one thing to write for fun. Will it be any different when others are giving bucks? Is there the temptation to steer words towards what the patrons might want to read? Does it make the difference between cooking at home versus grabbing a slice and a beer? I think this is the most interesting part of the experiment: can you get paid to be yourself, or do you change yourself to get paid?

Go for it, Jason. Break a leg!

[idea: "Use the Net to make it easy for people on the same
flight to find each other - before, during, and after"

this is an idea that evolved over a few hours of being stuck
on a plane, gradually getting more coherent towards the end ...
and posted a couple of days later]

(more…)

Is there anything like Hydra for Linux yet? Perhaps something that uses Jabber?

A local Linux User Group is electing folks to different positions,
and one of those is “Scribe”. To me, the idea just seems so 20th century.
A few people with wireless latops and a real-time collaborative
editor can take a much more complete set of notes than
any one person. See my earlier post about how well Hydra did
in a conference setting.

So where’s the breakthrough Linux app? I am aware of distributing
Emacs frames to a bunch of X11 servers, but that’s too dependent
on not having the host machine sneeze.

thanks Lazyweb.org readers for any input on this!

Yes, I still think about ThereThen Addresses quite a bit! I am starting to review an unrelated tech book manuscript (paying gig, I like that), so I will have even fewer cycles for TT for the next week or so. It’s still something that I want to at least document.

• Creating ThereThen Addresses (updated, but still rough)
• Resolving ThereThen Addresses (brand new, in progress)

Any feedback is welcome. I will make pretty HTML later. For now, I am dumping thoughts into Emacs. If I’m hired or otherwise don’t have time for ThereThen in the near term, at least someone will have my notes for reference.

I’ve been writing and researching a bit lately, in my efforts to get ThereThen addresses well-defined. Two new docs:

• A Quick Look - A One Minute Glimpse
• Design Decisions - or, “Why did you do it that way?”

It should be noted that these, and other docs on my site, are in-progress. I will say that I feel I have the specification nailed down, and that my writing is focused on how best to describe the various aspects and implications.

I’m about to start writing some code to demo the concept of href="http://ThereAndThen.org">ThereThen addressing. A guiding
thought has been to Keep Things Simple, which is why I don’t have
localized notions such as Post Codes (UK) or Zip Codes (US) floating
around in the TT notation. Whatever goes into a TT address must be
universally understood. Components of a URL which follow the TT
sections (Location and Time, always those two, and always in that
order) may certainly be as site-specific in their naming conventions
as they are now. Examples:


http://example.com/
37.749991,-122.45,80F/2003-02-4T13:15:20Z/SF-MOMA.html

http://example.com/
37.749991,-122.45,80F/2003-02-4T13:15:20Z/Store/Books/Dali.html


Which brings me to the notion of altitude. Longitude and
Latitude are universal. As near as I can tell, Altitude
is subject to local-interpretation. I’m happy with Feet.
Some folks from the UK that I have met recently are going
to be happier with meters. I looked for guidance at the RDFIG Geo vocab workspace, and didn’t see
anything nailing down how Altitude should be specified.

My inclination, up till now, could be summed up in two quick examples:
80F for 80 Feet, and 15M for 15 Meters.

Somehow, the notation doesn’t sit well with me. Are there
parts of the world where ‘F’ and ‘M’ aren’t going to be
instantly recognizable as Feet and Meters? Will it lead
to confusion? I wouldn’t want a ThereThen address slamming
into the surface of Mars just because someone got
confused between measurement systems!

One approach would be to put a stake in the ground and say “Altitude
is always Meters”. This would give worldwide consistency
in handling ThereThen addresses. Any application that needs
measurements in Feet can do the trivial conversions to and from
Meters. I like this, because it makes addresses that much
more portable. TT addresses are meant to be processed by programs,
as opposed to interpreted by users, so I am not worried about
my fellow Americans getting confused by seeing meters in the
Location component.

Another approach is to drop Altitude entirely. This changes
my first example to:


http://example.com/
37.749991,-122.45/2003-02-4T13:15:20Z/SF-MOMA.html


It’s certainly a little simpler, but it conveys less information.
Altitude can be important in Urban and Country contexts. There are
Urban contexts where one may want to call attention to the fact they
are posting from the 50th floor of a tall building, or a subway
platform. Bridging from City to Country, someone flying in a plane
may take a certain joy from tagging a blog posting from 10,600
meters up. In the Country, it may make sense for someone to point out
that they are at the top of Glacier Point in Yosemite, as opposed to
the Valley, 900-odd meters directly below. href="http://www.burri.to/~joshua/">Joshua Schachter points out a
tiny GPS device
for $99 USD, which is one more piece of the “Location from
the Real World maps into the Internet” puzzle.

My conclusion from all of this is that Altitude is certainly
important to enough groups of people to keep it in the ThereThen
addressing scheme. A tangent question to this is “what’s the
default, when no Altitude is specified?” How about 0? (Sea Level)

My other conclusion (this is why I write stuff, it helps me think the
problem through…) is that sticking with Meters should work pretty
well. The conversion to Feet is trivial for local apps that need it,
and it helps ensure that everything in a ThereThen address is universally
understood.

I’d be keen to hear what others think. If you are thinking
within a RDF-centric world, be assured that I intend to work
out how TT addresses can be used in that context. My present
obsession (which is too strong of a word, really…) is that
I needed to focus on what components of ThereThen mean. I have
it down to a universally accepted latitude and longitude, altitude
in meters, and an ISO standard for time. That seems pretty good,
and should remove a lot of obstacles for people in building
some value on top of it.