Wednesday, April 28, 2010previously wrote about. I'm curious how long it will take for this post to go through, given the general lack of reliability of the publisher that I've experienced since I started this little thing here; how many people are waiting until the last minute and desperately trying to continue to post?
Because it may be awhile before I start posting again, I thought I'd spend a few moments just giving a "final" (I keep using the quotes because this definitely is not the end for my site—just this particular way of posting) update. Decidedly on-topic is that I spent some time this weekend giving teaspoon (please ignore the date on that post!) a bit of rethinking; it's getting a reincarnation in html5lib, which actually solves a number of problems that had slowed me down before—most notably a selector language. I'll be totally honest and say I don't expect a whole lot of progress any time soon, but I'm positive on the direction. So we'll see how that goes.
Since I originally talked about it, I've been singing the praises of Ubuntu's Lucid Lynx release to anyone who would listen—and many who weren't. This release is so much better than the Karmic disaster... so very, very much better. Apart from the little bumps in the road that accompany following a series of alphas, I really just cannot point to anything wrong with it. It boots faster, it's more modern, I like the way it looks... it's all good. Kudos to the team there. Looking forward to evaluating it for my home servers next.
And that's it. It's time to get to work now, but I thought maybe I'd at least try to send the journal into its hiatus with a little substance instead of just a note of administrivia. Thanks for reading, and I hope to be back soon!
MORE: Hey, it published fast! Google ought to shut down services more often! ;)
STILL MORE: I spoke too soon. Adding that last comment is taking forever!
posted by zigg 6:50 AM 0 Comments
Sunday, January 25, 2009Facebook applications were basically a backdoor to gather up info on you and your friends. I still almost choked on my iced coffee today when I saw, as I poked through Facebook's privacy settings, the following list:
- Profile picture
- Basic info
- Personal info (activities, interests, etc.)
- Current location (what city I'm in)
- Education history
- Work history
- Profile status
- Groups I belong to
- Events I'm invited to
- Photos taken by me
- Photos taken of me
- Relationship status
- Online presence
Oh, but it's not for applications you add. It's for applications that your friends add. So when that girl you knew from high school who is addicted to celebrity-alike quizzes adds that app to her ever-growing profile, the impact to you isn't limited to getting the weekly spams begging you to take the test as well. The way Facebook words it:
When a friend of yours allows an application to access their information, that application may also access any information about you that your friend can already see.And, perhaps even more creepily:
Please note that this is only for applications you do not use yourself.You can flip this crap off in Privacy > Applications > Settings.
My plan to include as little info as possible is looking pretty smart.
posted by zigg 4:00 PM 6 Comments
Saturday, January 24, 2009Facebook the other day. I'm not sure quite what spurred it on, in retrospect, though I can point to a few catalysts.
I originally left because of the Beacon debacle. I don't know why it'd never occurred to me before, but Beacon exposed a vector I'd not considered before: my e-mail address. Everyone who I'd registered with as email@example.com (which isn't exactly private) could aggregate data on what I'd done with them. I started creating tagged e-mail addresses that would at least defeat simple aggregation, a practice I continue to this day (I expect it'll be sufficient since few others on the planet seems to care much, yet), and left shortly thereafter with concerns that the company was out to monetize my social graph by any means possible, and tie it back to anything they could outside of their enclave.
I've moderated somewhat since then. I decided I can be careful about what I say and what I tell the site about myself, and still use it at least as a meeting point to connect with friends. So, after Cory announced after months of resistance that he'd signed up for Twitter, and having seen many friends catch the Facebook bug, I thought, eh, why not. I could handle it.
My friend list is rebuilding with speed that'd be astonishing except that I'm pretty sharply aware of how a few simple queries can map possibilities in the social graph that only need confirmation by the next person to sign on and see them. I've picked up a few new friends that I haven't had before, and amusingly, some that I did have before are welcoming me to the fold as if I'm totally new. But what really has surprised me is how open people are when they think they're surrounded by just their close friends.
In the real world, you make decisions as to who to share information with. If you have friends, you might talk to them about personal problems. You certainly wouldn't stand up in the office or at a high school reunion and broadcast them to the world. If your friends turned around and talked about your problems to others, you'd label them gossips.
Now, social networking has become that gossip. When you hit that "post" button, everyone knows what's what, whether it's your best friend or a passing acquaintance. In some situations, you might think you're even talking to a specific friend, only to have your comments be seen by their friends.
Looking down my "news feed", a list of what's been going on among the people I've marked friends on Facebook, there's already some really personal stuff in there. Stuff I wouldn't necessarily share with everyone if it happened to me. I'm aware there are so-called "privacy nudists" in this world who would do this anyway, but I think there's a curtain of illusion there, intentional or not, that when you make a post on Facebook—or any other similarly-operating network—that you're talking to your friends.
You should know that you're talking to everyone else, too.
posted by zigg 11:46 AM 0 Comments
Monday, January 12, 2009
I can get in there, mind—I just have to click the freaking logo.
How unintuitive is that?
posted by zigg 6:37 AM 0 Comments
Sunday, January 4, 2009
I also discovered that somewhere down the edit line, Blogger eats leading whitespace—slowly—inside of <pre> elements. Delightful. I apologize in advance for any code snippets that lose their indentation over time.
If you take a peek at the source and note that I'm using px units, well, there's a reason for that, and that is that we lost the em/%/what-not battle ages ago. Whether it's CSS not being up to the job, browser manufacturers being sloppy, the proliferation of raster graphics, or a combination of all of the above isn't really something I'm interested in talking about today, but just know that I came to the conclusion that I should be working in px from here on out with a heavy heart. I do have some other ideas for dealing with variably-sized screens, though, and someday I shall tell you all about them!
posted by zigg 4:21 PM 0 Comments
Saturday, January 3, 2009
The core idea originated in an internal perfectionist tirade I had while building a simplistic content-publishing site in LAMP. The modus operandi for LAMP is that your content is stored in a database, and a script fits that content every time it is requested into HTML.
The database model has won the day because it is very flexible and supports a model that is pretty easy to understand, but it's always nagged at me that, especially for a site that publishes high volumes of content, code on the web server is constantly issuing queries (as opposed to just quickly navigating a file tree), fetching the pieces of content, and custom-assembling what is almost always the same exact content for every visitor. Bigger players in this space often use caching—essentially, inserting yet another server between publisher and reader that keeps a copy of this custom-assembled page to serve up to multiple people instead of having the backend server do it again for every request.
When I first discovered markup languages like HTML I was very intrigued by them. They (at least when used properly) don't just pretty things up, but they also impose a structure for a document. What's so great about that structure, though, is that it means that if you construct your document carefully, you can read it back again and deconstruct it into its component pieces (i.e. title, publication date, author, text). If a web publishing platform took this into account, it could circumvent the whole process of assembling the same servable content for each visitor and still retain the flexibility, permitting each document to be changed simply by reading it in, changing what needed changing, and writing it back out again.
There's one other piece to the puzzle that makes my platform complete, though. Despite all this tirade about inefficiencies in web publishing, I am actually a great fan of what is possibly the most inefficient platform of all, Zope. The reason for this is the model by which I interact with it; instead of dealing with rows in databases or opaque files on disk, I instead deal with Python objects, whose classes can encapsulate all kinds of behavior. I determined that if I take the read-in/change/write-out bit named above and apply it to object persistence, I can now insert the power and ease-of-use of object-orientation into this very efficient platform. It's kind of heady, honestly.
I call the whole thing "teaspoon", which is a bit of a geeky play on words; round-tripping a flat-file form to objects and back is called persistence, and I'm parsing HTML as "tag soup"; giving me the concept of "tag-soup persistence". The Python module for this is called tsp, which is also the common abbreviation of the good old teaspoon measurement that I still use cooking today... and so I have my sufficiently Web 2.0 name ready to go.
Until I do get this project off the ground in a real way, I continue to use Blogger to write, and while Blogger's feature of publishing HTML pages that don't require rejiggering for every visitor is a step in the right direction, it's not fully bidirectional like teaspoon would be.
So, I press on.
posted by zigg 10:39 AM 0 Comments
Monday, December 29, 2008introductory post to talk a little bit about why I needed Blogger to be able to publish under my domain, zigg.com.
In 1998, Tim Berners-Lee, the guy who invented the Web, wrote a little bit for the W3C called Cool URIs don't change, in which he advocates keeping resources available under the same URI forever in the face of the beginnings of a worrying trend: URLs that we used just a few years ago are increasingly being invalidated by the march of progress.
You've seen it yourself, if you've used the Web for any length of time, I'm sure. A link used to go to some page you're interested in, and it drops you off at a dead page—or worse, asks you to try searching their site for it—an exercise that is usually fruitless. It doesn't have to be this way; a conscientious and competent webmaster can either keep the same URL scheme forever or provide some server-side trickery so that URLs from many years ago will still work, with one key catch: they have to have full control over the domain that the original URLs lived on.
This is why I need my journal to live under zigg.com; if, down the road, I do quit using Blogger, I can continue to serve up all the content that I've created since I started transparently—even if I switch software and end up using a new URL scheme, I can have the old mapped to the new. If I hosted my blog elsewhere, though, I wouldn't have that option. I'd be at the mercy of whatever that host provided me. If I fully control the domain I'm using, I can do what I need to do, and if the people I'm paying to host zigg.com can't give me what I need, I can go elsewhere.
I'm glad I can do this for my blog, but it's troubling that so many other sites (including many that may simply not be here in a few years) are lining up to have me host resources without giving me any sort of control over the namespace itself. If it's a Facebook-like situation, where there's a walled garden of sorts and no expectation of external linking, the stakes are obviously much lower; but if I am going to be creating public resources, I need to be able to promise the public that I am committing to continuing to serve that resource, as long as it exists and I am able, at the address I originally give for it. Publishing things under anyone else's domain just doesn't give me that ability.
And to not be able to make that promise, well, that's just not cool.
Footnote: If you're confused by "URIs" and "URLs", you're not alone. The types of addresses most people have been exposed to on the Web, those that start with http:// and ftp:// and what not, those are URLs because they locate a resource. There are also things called URNs, which name a resource, but don't actually locate it on the network; something like urn:isbn:068486293X would be a URN. Both URLs and URNs are URIs. The more you know!
posted by zigg 9:00 PM 0 Comments