Categories
Money

The Frugal Algorithm: begin as you mean to go

Recovered from the Wayback Machine.

Once I decided on the Frugal Algorithm as the name of this new site, I checked to see if the domain was still available. It was, and for the trivial amount of $30.00 or so dollars for the domain, private registration, and ICANN fee, it would be mine.

Hold on a sec, though. Thirty dollars is a tank of gas, a donation of food for a family of four for a week, not to mention three albums of digital music, or a couple of DVDs. The money would be worth it, if the domain was worth it, but the question is: is the domain worth it?

At one time, it was important to have an easy to remember domain name for your site. After all, we had to hand type in the domain addresses when we wanted to visit the site. However, that was in the days before most sites were found via link from others, or search engine results. Having one domain is important, because you can’t depend on owning the same IP address forever. But you don’t need to have a domain for every interest, itch, and thought that crosses your mind. Big companies might need domains, but the small business owner, organization, or individual can get by with one domain. Just one.

It would be a sad commentary on this site if my first act in creating it was to spend money I didn’t need to spend. Thirty dollars doesn’t seem like much, but it adds up. Not only would I need to obtain the domain for The Frugal Algorithm, but I’d also need to renew my domain for MissouriGreenSecret of Signals, and the domain, shelleypowers.com for Just Shelley. Yet, I doubt that anyone has ever looked at the domain names for the sites, much less typed the domains into a browser’s address bar.

I hestitated on not renewing MissouriGreen, as eventually I’d like to get a jacket with the name of the site embroidered on it, so when I take photos at events, people know where to look to see if their picture appears. But if I display “MissouriGreen” on the back. rather than “MissouriGreen.com”, people will just look up “MissouriGreen” in Google and find the site. And though it may seem as if my encouraging the use of Google will melt the polar ice caps and drown baby polar bears, I have a feeling from an environmental perspective, it’s all a wash.

Look how much money I’ll save buy not buying the new domain, or renewing the old ones. I estimate I’ll save about $150.00 a year in domain fees, and that’s a conservative estimate. That’s enough money to pay half of my annual server fees, sponsor Crackers for a year, or buy 15 books for my Kindle.

Ummm, 15 books for my Kindle…OK, OK, I’ll split the difference: Crackers gets half, the server gets paid this month, and I’ll get those three history books I’ve been wanting.

Categories
Semantics

Pinky and the Markup Brains

What ended up being the ultimate irritation of my brief foray into HTML5 land, is that I found out, after careful perusal of my original use of RDFa, that I wasn’t using it incorrectly. However, by the time I got through listening to all the arguments, back and forth, and round and round, I was beginning to doubt whether an angle bracket really looked like < and >. I am correct, aren’t I? These are angle brackets, right?

Of course not. I call them angle brackets, but others call them diamond brackets, and I’m sure someone else, most likely from the UK, calls them elbow brackets or the Queen’s brackets, or some such thing.

However, the back and forth, and round and round, wouldn’t be an issue, could even be a journey of discovery, if it weren’t for the arrogance of some of the participants. Or, what I perceive to be arrogance. Variations of, “But that’s wrong and here’s why”, followed up with references to other specifications that hurt, actually physically hurt just to look at, given in a tone of, “How could you think otherwise?” Or responses based on some absolutely obscene piece of markup minutia, repeated over and over again, in attempts to hammer the point home to we, the seemingly dense as bricks.

The end product of such discussions, though, is that people like myself flee the discussion—literally flee, as if the hounds of hell were chomping at our butts. The downside of running away, though, is we’re left feeling that we have no input, no control over what the web of the future will, or will not, allow. That the web of the future of the web is designed by and for the web designers, and not thee and me.

The real problem, though, has less to do with communication style, and more to do with differing levels of expertise and interest. People like me, who are consumers of specs, are mixed in with people who create the parsers and the browsers, and live and breath, eat and sleep this stuff. What else can we, the consumers, do, though? There seemingly is no way for those of us, on the dumb side of markup, to communicate our concerns, wishes, and desires to the other side. But when we do venture into the lists, we are quickly overwhelmed with the specs, the references, the minutia. Our interests get lost in the fact that we don’t have the language to participate. Worse, we don’t have the language to participate in a field notorious for being both competitive, and impatient.

Unbeknownst to ourselves, we have become Pinky to the markup Brains.

So we consumers flee the lists and leave them to the developers and designers, and the end result is that we have specifications, and eventually implementations, that, well, frankly, scare the shit out of most of us.

Don’t believe me? How else could you explain the Yellow Screen of Death that appears whenever you make a simple mistake in markup for the post you’re writing? Not a helpful error, or an error that gently points out where and why the problem occurs; an error that tries to work with you to correct the problem.

No, it is an ugly error, an angry error, with red on yellow, that screams, “Bad, Shelley! Bad”, before it invariably trails off to uselessness on the right side of the browser. You don’t think an actual person like you and me would have designed a specification that encourages this behavior, or a browser that implements it, do you?

The true irony, though, is when you do voice concerns, or criticism, you’re typically met with, “If you want something, you need to participate in the email lists working on the specifications”, and the cycle begins anew. Narf.

Categories
Writing

Breaking eggs

I have an egg.
A perfect egg.
I am lost in admiration of my perfect egg.

But I am hungry.
I must break the egg.

I break the egg.
It is awful.
Slimy, wet, with a bulbous yellow eye.
And I am sad.

But look!
I have an omelet!
A perfect omelet!
I am lost in admiration of my perfect omelet.

But I am still hungry. 
I must eat the omelet.

I eat the omelet.
It is good. 
But now it is gone, all gone, every bite.
And I am sad.
Categories
SVG

The SVG Feed

I had originally created a Planet SVG in order to bring together a feed of SVG items. Once the SVG IG created Planet SVG web site, for all things SVG, I redirected planetsvg.org to it.

I still wanted a feed of SVG-related items, so I created the SVG Feed. Currently, the application queries SVG feeds once a day, including my own Delicious SVG-related feed. The latter was my way of ensuring that items related to SVG that aren’t accessible via a feed, or the related feed isn’t specific to SVG, get included.

The SVG Feed has it’s own feed, and uses Planet and Venus software. It only updates daily, as there are not enough items for more frequent updates. If you know of an SVG feed that should be included, send me an email.

Categories
Just Shelley RDF

And with all that

And with all the unpleasantness this weekend, including a comment breaking my XHTML, captured for posterity by the playful, puckish, Anne, I find that I have misunderstood one key element of the RDFa specification, and have embarrassed myself greatly.

screenshot of Anne being an asshole

Why is every time I touch anything to do with the W3C or associated mailing lists, I always come away feeling like the idiot child who has just wasted the time of her elders? It has gotten to the point, where I don’t want to write anything about technology online.

Now, I have to re-visit my XHTML formatting for my comments, for yet another use case that is slipping through the filters.

update Another set of test cases bites the dust. I now have two modules, HTML Purifier and htmLawed implemented, in addition to the built-in URL converter and automatic line break functionality. The order these are implemented is important and the following seems to create a compatible effect: HTML Purifier, htmLawed, URL converter, line break. I’ll have to do other testing, but two particular use cases that came up yesterday—yes, two— both seem to be trapped with these changes.

second update Based on request from from the htmLawed creator, I attempted to reduplicate the original errors. One was quite simple: the use of <self-close /> caused the Drupal built-in HTML corrector to over correct, adding a </self-close >. I’m not sure why I had the built-in HTML corrector active, anyway, as it does conflict with htmLawed. Removing it removed the problem.

The second test case didn’t get corrected by htmLawed, when I tested with the original comment, so I added HTML Purifier. However, when I went to duplicate the test case, I couldn’t, so I had documented the test case for duplication incorrectly. I’ve since turned off HTML Purifier, and if the case occurs again, will leave it to show the htmLawed creator. It doesn’t hurt to use both modules, and I only use them with comments, but if I don’t need two, I’d rather not use two.