Bb RealTech

I've finished the re-organization of my web site, though I have odds and ends to finish up. I still have two major changes featuring SVG and RDFa that I need to incorporate, but the structure and web site designs are finished.

Thanks to Drupal's non-aggressive use of .htaccess, I've been able to create a top-level Drupal installation to act as "feeder" to all of the sub-sites. I tried this once before with Wordpress, but the .htaccess entries necessary for that CMS made it impossible to have the sub-sites, much less static pages in sub-directories.

Rather than use Planet or Venus software to aggregate feed entries for all of my sites, I'm manually creating an excerpt describing a new entry, and posting it at Burningbird, with a link back to the full article. I also keep a listing of the last few months stories for each sub-site in the sidebar, in addition to random display of images.

There is no longer any commenting directly on a story. One of the drawbacks with XHTML and an unforgiving browser such as Firefox, is that a small error is enough to render the page useless. I incorporate Drupal modules to protect comments, but I also allow people to enter in some markup. This combination handles most of the accidentally bad markup, but not all. And it doesn't protect against those determined to inject invalid markup. The only way to eliminate all problems is not allow any markup, which I find to be too restrictive.

Comments are, however, supported at the Burningbird main site. To allow for discussion on a story, I've embedded a link in every story that leads back to the topmost Burningbird entry, where people can comment. Now, in those infrequent times when a comment causes a problem with a page, the story is still accessible. And there is a single Comment RSS feed that now encompasses all site comments.

The approach may not be ideal, but commentary is now splintered across weblog, twitter, and what not anyway—what's another link among friends?

I call my web site design "Silhouette" and will release it as a Drupal theme as soon as it's fully tested. It's a very simple two column design, with sidebar column either to the right (standard) or easily adjusted to fall to the right. It's an accessible design, with only the top navigation bar coming between the top of the page and the first story. It is valid markup, as is, with the XHTML+RDFa Doctype, because I've embedded RDFa into the design. It is not valid, however, when you also add SVG silhouettes, as I do with all but the top most site.

The design is also valid XHTML 5.0, except for a hard coded meta element that was added to Drupal because of security issues. I don't serve the pages up as HTML 5, though, because the RDFa Doctype triggers certain behaviors in RDFa tools. I'm also not using any of the new HTML 5 structural elements.

The site design is plain, but it suits me and that's what matters. The content is legible and easy to locate, and navigate, and that's my second criteria. I will be adding some accessibility improvements in the next few months, but they won't impact on the overall design.

What differs between all of the sites is the header graphic, and the SVG silhouettes, which I changed to suit the topic or mood of the site. The silhouettes were a lot of fun, but they aren't essential, and you won't be able to see them if you use a browser that doesn't support SVG inline. Which means you IE users will need to use another browser to see the images.

I also incorporate some new CSS features, including some subtle use of text-shadows with headers (to add richness to the stark use of black text on pastel graphics) and background-color: rgba functionality for semi-transparent backgrounds. The effects are not viewable by browsers that don't yet support these newer CSS styles, but loss of functionality does not impact access to the material.

Now, for some implementation basics:

• *I manually reviewed all my old stories (from the last 8 years), and added 410 status codes for those I decided to permanently remove.
• For the older stories I kept, I fixed up the markup and links, and added them as new Drupal entries in the appropriate sub-site. I changed the dates to match the older entries, and then added a redirect between the old URL and the new.
• By using one design for all of the sites, when I make a change for one, it's a snap to make the change for all. The only thing that differs is the inline SVG in the page.tpl.php page, and the background.png image used for the header bar.
• I use the same set of Drupal modules at all sub-sites, which again makes it very easy to make updates. I can update all of my 7 Drupal sites (including my restricted access book site), with a new Drupal release in less than ten minutes.
• I use the Drupal Aggregator module to aggregate site entries in the Burningbird sidebar.
• I manually created menu entries for the sub-site major topic entries in Burningbird. I also created views to display terms and stories by vocabulary, which I use in all of my sub-sites.
• The site design incorporates a footer that expands the Primary navigation menu to show the secondary topic entries. I've also added back in a monthly archive, as well as recent writings links, to enable easier access of site contents.

The expanded primary menu footer was simple, using Drupal's API:

<?php
$tree = menu_tree_all_data('primary-links');
print menu_tree_output($tree);
?>

To implement the "Comment on this story" link for each story, I installed the Content Construction Kit (CCK), with the additional link module, and expanded the story content type to add the new "comment on this story" field. When I add the entry, I type in the URL for the comment post at Burningbird, which automatically gets linked in with the text "Comment on this story" as the title.

I manually manage the link from the Burningbird site to the sub-site writing, both because the text and circumstance of the link differs, and the CCK field isn't included as part of the feed. I may play around with automating this process, but I don't plan on writing entries so frequently that I find this workflow to be a burden.

The images were tricky. I have implemented both the piclens and mediaRSS Drupal Modules, and if you access any of my image galleries with an application such as Cooliris, you'll get that wonderful image management capability. (I wish more people would use this functionality for their image libraries.)

I also display sub-site specific random images within the sub-site sidebars, but I wanted the additional capability to display random images from across all of the sites in the topmost Burningbird sidebar.

To get this cross-site functionality, I installed Gallery2 at http://burningbird.net/gallery2, and synced it with the images from all of my sub-sites. I then installed the Gallery2 Drupal module at Burningbird (which you can view directly) and used Gallery2 plug-ins to provide random images within the Drupal sidebar blocks.

Drupal prevented direct access from Gallery2 to the image directories, but it was a simple matter to just copy the images and do a bulk upload. When I add a new image, I'll just pull the image directly from the Drupal Gallery page using Gallery2's image extraction functionality. Again, I don't add so many images that I find this workflow to be onerous, but if others have implemented a different approach, I'd enjoy hearing of alternatives.

One problem that arose is that none of the Gallery2 themes is XHTML compliant because of HTML entity use. All I can say is: folks, please stop using  . Use   instead, if you're really, really generating XHTML, not just HTML pretending to be XHTML.

To fix the non-compliant XHTML problem, I copied a version of my site to a separate theme, and just removed the PHP that serves the page up as XHTML for XHTML-capable browsers from this "Silhouette for HTML" theme. The Gallery2 Drupal modules allow you to specify a different theme for the Gallery2 pages, and I use the new HTMLated theme for the Gallery2 pages. I use my XHTML compliant theme for the rest of the site. Over time, I can probably add conditional tests to my main theme to test for the presence of Gallery blocks, but what I have is simple and works for now.

Lastly, I redirected the old Planet/Venus based feed locations to the Burningbird feed. You can still access full feeds from all of my sub-sites, and get full entries for all but the larger stories and books, but the entries at Burningbird will be excerpts, except for Burningbird-only posts. Speaking of which, all of my smaller status updates, and general chit-chat will be made directly at Burningbird—I'm leaving the sub-sites for longer, more in-depth, and "stand alone" writings.

As I mentioned earlier, I still have some work with SVG and RDFa to finish before I'm completely done with the redesign. I also have some additional tweaks to make with the existing infrastructure. For instance, I have custom 404, 403, and 410 error pages, but Drupal overrides the 403 and 404 pages. You can redirect the error handling to specific pages, but not to static pages, only to pages within the Drupal system. However, I'm not too worried about this issue, as I'm finding that there's typically a Drupal module for any problem, just waiting to be discovered.

I know I must come across as a Drupal fangirl in this writing, but after using the application for over a year, and especially after this site redesign, I have found that no other piece of software matches my needs so well as Drupal. It's not perfect software—there is no such thing as perfect software—but it works for me.

* This process convinced me to switch fully from using Firefox to using Safari. It was so much more simple to fix pages with XHTML errors using Safari than with Firefox's overly aggressive XHTML error handling.

I guess I will now be looking at how to port my Drupal installations to PostGreSQL, since Sun sold out to Oracle. The Java issue doesn't impact me, as I saw the writing on the wall as regards to Java a long time ago.

However, support for MySQL will most likely be completely undercut, if not eliminated. Or it will go through that fine Oracle touch, which means you can't depend on support for the database in the future—not without it being either bloated, or "monetized" in some way. This is how Oracle works.

I can hear it now: But MySQL is open source. Oracle can't hurt it, because it's open source!

Being "open source" will protect MySQL. Yeah, right. And I believe I'm Superwoman and can't be hurt by bullets, so just shoot me now.

From the lack of interest I'm seeing in my feed list, I would have to assume I'm not the only one less than enthused about Microsoft's Azure. About the only person I know who has perked up and displayed real interest is Nicholas Carr, and some of his interest is most likely because he wrote a book on cloud computing.

That Azure is a competitive strike at Amazon is a given. What's missing in Ozzie's statement, though, is the fact that Amazon originally rolled out it's cloud computing services as a way of maximizing under-utilized server farms during the company's quiet times. I don't know if this has changed, and Amazon is now farming clouds deliberately, but I hope not—the original idea was quite sound.

I am not surprised that Ray Ozzie would urge Microsoft into the clouds considering his background, first with Lotus, and then with Groove. Groove, especially, was cloud-based. Probably one of the more sophisticated cloud-based applications at the turn of the century.

But as far as I know, Groove never did catch on in any big way. I imagine when Ozzie was hired at Microsoft and Groove folded into the Microsoft family, the expertise this acquisition brought into the company played a big part in the implementation of Azure, but it still doesn't compensate for the fact that Groove never caught on. Not in corporate America, which is Microsoft's bread and butter.

Amazon can probably make do providing data storage and services for the startups, which seems to be its primary customer. I can't see Microsoft doing the same, not the least of which, startup and Microsoft are not words that necessarily go together well. Microsoft has always been a corporate company, pricing its products accordingly, and in doing so, giving both Apple and Open Source room to breathe and expand. Apple sold to the artists and mavericks. (Can I use maverick still, or has that term been trademarked by the Republican Party?) Open source managed to capture all the folks who fell in-between, though when Apple released Mac OS X, there was some platform straddling.

Seriously, I have to ask: can you imagine Citigroup or Bank of America farming any of its applications out to the Azure platform? How about Chrysler, or Blue Cross? Oh, there might be some IT in these big companies that will want to experiment around, but I've not met a big company yet that didn't want to control every last aspect of its data. Several industry types can't do something like cloud computing for most of their data—they would be prohibited by laws built to safeguard private information.

So, Azure isn't a move to entice the corporates to the cloud (can't be, really can't be). It's seemingly a move to entice the smaller guy, something that Microsoft has not shown itself to be particularly adept at. For one thing, the Visual Studio 2008 application that developers can use to build to Azure is pricey. Microsoft still hasn't learned that rule number one is you don't charge the developers money to access the development tools, if you want the developers to drive business to your platform.

Oh sure, Microsoft puts out a baby version of its different developer applications, but I'll bet you dollars to donuts, the baby version won't interface with Azure. And SOAP? Seriously, who does SOAP anymore? I thought the whole SOAP/REST thing was decided, a long time ago. We are talking 2009, not 1999.

I must admit to being a skeptic of all the recent cloud fooflah, not the least of which we've all seen what happens when a cloud server like Amazon has problems, resulting in several different startups being without service for several hours. I can respect that cloud computing allows startups to get a leg up, but I have to wonder: is that enough for a long-term sustainable business? Is there really enough business for another player in the game?

Once I made the decision to quit writing for a living (there was a living involved?) and return to consulting and development, I looked around at all of the existing technologies and asked myself what I should spend time on, in order to sharpen my development skills. Perhaps I'm a relic of times past (yeah, all of five years, ancient times), but I decided to spend most of my time working with Drupal and one or two other CMS, REST, a little RDFa, a touch of SVG and other programmable graphics tools, and maybe a smidgen of this or that, whatever strikes my fancy, and that includes AIR and OpenLaszlo and some of the other web/desktop platforms. You can never go wrong becoming as proficient as possible with CSS, the markups, the data sources (SQL/RDF/XML/JSON), PHP (or Python or Perl, maybe Ruby, always C++), JavaScript, and REST.

One could say that what I described is all that's necessary for cloud computing, but there's a whole new game when you have to create pie slices of your applications and throw them into a black box. It takes no additional time to learn to do cloud computing, true. However, it takes additional time to learn to do cloud computing well. I'm not taking that time, for any cloud. Not Amazon's. Not Google's. Not Safesforce.com (Salesforce.com?) Certainly not Azure.

If I'm wrong in my assessment, I'll watch the rest of you fly past me, like birds on the wind. If I'm right, though, and today's cloud is the same as yesterday's Web 2.0—more hype than reality—I'll already be well grounded when this bubble pops.

O'Reilly Radar has a post with graphics related to the recent study of people using older, insecure browsers. At a glance we can easily see that most of the problem occurs with Internet Explorer, most likely IE6.

If Wikipedia is correct, IE6 was released on August 27, 2001. Come this August 27th that makes this browser seven years old, far older than most software supported by most organizations.

If we apply the same longevity to other software that's been applied to IE6, all those who are using IE6 must still be using Windows 2000, the first release of the Mac OS X, Photoshop 3.x, a dial-up modem, AOL for chat, Yahoo for search, most of your applications are on the desktop, most of your backend processes are on a Sun or IBM mainframe, probably in Java, and probably using the JRE 1.3 or so. If you're using a database, it's most likely Oracle 7.x or SQL Server 2000. If you're developing for the web, you're most likely still using Perl and CGI, if not Java, or ASP. You might be using some Python or PHP, definitely no Ruby or Rails. If you are developing using Visual Studio, it's Visual Studio 6, and you're still not ready for .NET

You do your social networking through Usenet or AOL, Epinions, The Wall, or some other online BBS or forum. You can write over 140 characters. When you publish to the web, you're hand editing your web pages, or using a freebie HTML editor, Macromedia's DreamWeaver, Vignette, or some other larger commercial product. You might be using Blogger, though it's doubtful. You might be using a syndication tool, though it's doubtful. In fact, it's doubtful that you would be reading this.

At one time, IE6 was the best there was, but that was a long time ago. We've used it when it was shiny and new, and it brought us innovation and delight. We used it through its usefulness, when it became more anchor than step. We've used it until we now curse its name. We continue to use it because no one seems to be willing to say, "It's over".

We should celebrate what Internet Explorer 6 brought us at one time, by letting it go. I think that August 27, 2008 would make a fine EOL date for this once great browser.

Adobe has decided to partner with Yahoo and Google, specifically, in order to enable search engine access to Flash contents. In other words, web builders that use bad web practices have been rewarded, and can continue to use Flash to completely build their sites, without regard for accessibility or an open web. The site designers do not have to worry their pretty little heads any longer, because the big boys have come to an "arrangement of mutual benefit", and have decided that no, their shit does not stink.

I'd like to think that one reason Adobe is making this move is because it feels threatened from competition by SVG, but even a fangirl like myself has to acknowledge that much of this is probably related to recent moves into the animation and rich content field by other not-to-be named competitors. Besides, what chance does an open sourced, and openly accessible, technology have against such attractively packaged vendor lock-in? I mean, Google, Adobe: what more would we want?

We should just quit work on HTML5, right now. RDFa, too, not to mention microformats. Forget that semantic markup stuff, and the debate over ABBR. Who needs SVG, anyway? We have Flash, and Flash can be searched. The web has arrived.