Google's Definition of Beta

So for, like, forever Google apps — in particular, Gmail and Google Calendar — have bore a beta label. Now, no one has any idea why this has been the case, but this week Google has decided to remove the beta label with little more than PR-speak as an explanation:

"We realize this situation puzzles some people, particularly those who subscribe to the traditional definition of “beta” software as not being yet ready for prime time." (via John Gruber)

Gruber himself retorts:

"Imagine that — people thought that what Google meant by “beta” was what everyone else means by “beta”. Shocking"

Classic Gruber.

Now, I've heard Google spin it this way all over the web, but what I keep wondering is what Google's special, newfangled, hi-falutin' definition of beta actually is. The closest I've seen is this:

"Others say that, over the last five years, a beta culture has grown around web apps, such that the very meaning of "beta" is debatable. And rather than the packaged, stagnant software of decades past, we're moving to a world of rapid developmental cycles where products like Gmail continue to change indefinitely."

Um... What the hell are you guys talking about? Really. What is a "beta culture?" Seriously. What is that? And are you telling me that Google's apps are the only ones to "change  indefinitely." That's funny, because I keep running these software update thingies on my computer and all its applications. And every year or so I install new versions of said apps, loaded with new features. So tell me again: How is your definition of beta different than everyone else's? And why in the name of sweet merciful heaven has Gmail been beta for the past five years?

Ridiculous! And the more you try to spin it the more arrogant and full-of-it you come across.

Just admit it. You're afraid to commit. It's okay. We get it. There's no shame in that.

The oddest thing is that Google clearly thinks of the term beta as completely meaningless:

"Don't despair... for those of you long-time Gmail-ers who might feel some separation anxiety, we've got a solution. Just go to Settings, click on Labs, turn on "Back to Beta," and it'll be like Gmail never left beta at all."

That's right. You want the beta label back? Just turn it on. Which begs the question, why did they use the term for the past five years?

It's just stupid.

Gmail Multiple Select

I just discovered this (yes, I am slow): Gmail allows for multiple selection using the same method as the Finder. That is, selecting an email with the email's checkbox and then holding the shift key while ticking another email's checkbox will select a range of emails between the two selections. Very handy!

OGG Theora Converter

John Gruber today opines that there is no GUI interface for the command-line tool for converting Quicktime movies into the OGG Theora format — a very handy thing to be able to do if you want to serve video to Firefox-type browsers using HTML 5's <video> and <audio> tags.

Since this is something I do a lot — wrap command-line tools in Automator wrappers, that is — I thought I'd whip up a GUI method for doing this. So here it is.

The OGG Theora converter

It's a Finder workflow, so download it, unstuff it and put it in:

~/Library/Workflows/Applications/Finder

Placing the workflow there will add the item to the Finder's right-click contextual menu. To use the workflow, simply right-click a video you want to convert, navigate to More->Automator and choose "Convert To OGG" from the menu.

While this crunches you'll see a badge in your menubar:

Wait a few minutes and you'll see the OGG version appear right alongside your original movie.

And remember, you must first install the OGG Theora converter tool, ffmpeg2theora, for all this to work.

I've made a droplet-style version of this as well. Place this version anywhere — your Desktop, the Applications folder, your Dock — and when you want to convert a video, simply drag the video onto the droplet.

Enjoy!

UPDATE:

Folks, for those of you having trouble installing the workflow version, here's a tip, as mentioned in the comments: Double-clicking the unstuffed workflow will open it in Automator. From here you can choose File->Save As Plug-in...

Make sure it's a Plug-in for: Finder, and hit the Save button. It should now show up as an option in the Finder's contextual menu.

And remember, there is a Droplet Version as well whose installation is drag-and-drop. To anywhere!

Hope that helps!

Experimenting with DokuWiki

Wikis are just one more thing I've always wanted to play around with. And my job has, once again, afforded me the opportunity to do just that. We're currently using an engine called DokuWiki, so I decided to kick its tires and see what it — and wikis in general — are all about.

DokuWiki's front page describes it thusly:

"DokuWiki is a standards compliant, simple to use Wiki, mainly aimed at creating documentation of any kind. It is targeted at developer teams, workgroups and small companies. It has a simple but powerful syntax which makes sure the datafiles remain readable outside the Wiki and eases the creation of structured texts. All data is stored in plain text files – no database is required."

No Database

That last little bit — the lack of a database — is actually one of the things that makes DokuWiki unique. It is both its strength and its potential weakness, and one of its defining characteristics.

If you are looking to install a documentation engine for a small to medium-sized workgroup, it's true: DokuWiki is great. It's very easy to install and only requires Apache and PHP be running on your server. This means it can be installed on any Mac OS X machine without having to install or configure much beyond Personal Web Sharing. I say, "much" because you will have to activate (not install) PHP, which isn't too hard for savvy users, but isn't exactly mom-friendly either. Still, it beats having to also install and enable a database application like MySQL, which most other wikis require. So DokuWiki is relatively easy to setup.

That lack of a database is nice, in that it makes installation quick and easy. But it's also a potential drawback, albeit a minor one. DokuWiki writes all its entries to flat files and that could affect scalability, and to some extent performance, if your wiki ever became extremely large. The merits of databases vs. flat files for storing data are debated all over the Internets, but databases usually only offer a significant advantage when dealing with complex, relational data, and that advantage is usually only seen by the developer. For small to mid-sized or even large-ish sites, DokuWiki is great. If you’re worried your wiki might need to grow very large some day (like, to the point where load balancing across multiple servers is required, for instance — we're talking big!), DokuWiki may not be for you. Otherwise, the flat file system offers additional advantages, like easy-to-parse and repair backups, to name just one.

Wherefore Wiki?

That said, once installed, DokuWiki is very easy to use. It does use its own markup for page layout, but that markup is exceedingly sensible and easy to learn. My biggest stumbling block was getting started: How do you create a page? Well, once you know, it's pretty simple, but figuring it out took me a minute. The easiest way to create a page, is to navigate to that page. If the page doesn't exist, DokuWiki allows you to create it. See? Easy! Maybe too easy!

So what's it for? Well, I'll tell you, TASB was almost a wiki rather than a blog. While both are types of Content Management Systems (CMSes), and essentially do the same thing — allow a person to easily and rapidly build and read a structured store of text and media data — the difference is intent.

Blogs — and therefore blog engines — are geared toward personal, diaristic, periodic writing. They're usually organized chronologically, like a diary, and require no special markup when creating entries. Entries, once made, are rarely revised. One of the things I enjoy about writing this blog is that it's a bit more personal. It's a record of personal experience as much as, if not more than, documentation. So I stuck with using the blog format. I like to be chatty.

Wikis, on the other hand, are made to be accessed like a reference, like an encyclopedia, for instance. They're not chronological, but are usually ordered and read alphabetically; and wiki articles are made to be maintained and updated as information changes. Wikipedia is a great example of this. There is also a blog called the Tao of Mac that uses a wiki engine for content management, showing that, in the end, the two types of engines do essentially the same thing. They simply present different capabilities to their users based largely on the purpose of the site.

Conclusion

If you're looking for a quick, easy-to-use and easy-to-maintain storehouse of information (either for yourself, or for use with others), a wiki is a great thing to have. Need to document a procedure for your workgroup? Put it on the wiki. Need to let everyone know where that essential file is? Put it on the wiki. Just want to jot down some notes for the general use? Put 'em on the wiki.

After using one for a few days I can already see just how damn handy a wiki is to have. And DokuWiki is super-easy both to install and learn. If you just need something small to document procedures or productions — or if you're just looking to dip your toe into the world of wikis — DokuWiki is very nice indeed.

UPDATE:

I've edited the article for clarity and accuracy regarding the use of flat file systems vs. relational databases. Thanks to DokuWiki's author for pointing out the error.

More Data Recovery

It's been a bad couple of weeks for data loss in the Systems Boy household. Fortunately, it's been a fairly good week for data recovery, so we've mostly broken even, minus the time lost recovering data, of course.

Most recently, something seems to have taken a large (by which I mean everything) bite out of a very important CSS file. See, we tend to use Coda to build sites at our house, and we tend to work over the network as the most expedient means to that end. Now, working on a website over the network is not without its perils, as I'm sure you're aware. Particularly if you're working wirelessly, and particularly if you're working on a server of unknown reliability. So, a very awesome someone I know (okay, yes! I have a girlfriend!) was doing exactly that when all of a sudden her CSS file appeared to be completely empty. Mind you, she was not working on the file. She merely had it open while she worked on another document in another tab. But after switching to the CSS tab, the CSS file — which she'd been working on obsessively for about a week — appeared to be empty.

Now I've had the same thing happen to me after a network dropout — or, more likely, a server disconnect — and the solution in my case was to simply shut down and restart Coda. Mine was largely a cosmetic issue brought on, I assume, by Coda's inability to reconnect to the documents after a disconnect. So I told her to simply restart Coda, confident that the problem would correct itself. But it didn't. Even after restarting Coda, still no CSS joy. The file was there, but it was completely empty!

This is the point at which panic generally sets in. (And no, that is not a reference to the makers of Coda.)

If there's anything I've learned in my near-ten years of professional systems work, it's that data is rarely ever completely wiped out in a single stroke. And if there's anything else I've learned, it's not to panic. So I coolly, calmly set about the task of recovering the file while my exhausted and infuriated sweetheart went to bed.

The first thing I did was to check the server to see if any backups had been made. I know that her provider, and some of the software she uses, make automatic backups from time to time. So I downloaded anything and everything I could find from the server that might prove useful, including a backup of the entire site for safekeeping. I soon discovered that there was nothing even remotely recent enough to contain the missing CSS file. So I started looking in the local home account, first by grepping for anything with "css" in the name. Some Coda cache files came up, some of which were fairly recent, but none failed to yield the data I was searching for. I searched /tmp as well, to no avail.

Finally, after a couple of hours of downloading and grepping and searching and hoping, I was about ready to give up. As a last ditch effort I decided to use the find command on the entire local hard drive:

find / -name *.css*

This command will search the entire file system for any file whose name contains the string ".css." And it turned out to be the winner. The command yielded a ton of useless results, many of which came from application documentation. But in the end a Coda cache file turned up in:

/private/var/tmp/501

Of all places!

Moreover, this file had a time stamp very near the time of the disappearing data. So I made a copy of it (okay, I made, like, four copies of it) and uploaded it to the server. The next day my sweetie confirmed: I'd found the file! The day was saved!

So remember, people: Stay calm, and always try find before giving up the ghost. And for poops sake, make a backup!

Whew! That was close!