Monthly Archives: October 2008

I just did some tinkering with offline sound and it turns out you can embed an audio clip in an HTML file, and play it without using Flash. I could have demo’d this in a raw HTML file, but it was just as easy to stick it in a Tiddlywiki file. So I made a TiddlyWiki called JinglyWiki. Click on the button and it will play a sound. If you grab the file (safest using a tool like Curl or wget, as the browser will sometimes Save As something different), you can run it offline and it will still play the sound.

JinglyWiki started after an office conversation yesterday. We had a flaky wifi connection and were pleased to be able to play a beat on http://instantrimshot.com to signify a re-connection. This got us thinking about playing beats in Tiddlywiki. Jeremy mentioned the possibility of data: URIs, and I thought back to Reinier’s great effort in playing sound without Flash. I wondered if it would work with data: URIs and to my pleasant surprise, it did. At least in FF3, which is all I’ve tested so far. I also forgot how tiny the code is to play audio without Flash – you just add an element to the page.

The point of JinglyWiki is you can stick a 300K file on your local file system or a USB stick and play gratuitous sounds without being online. Your iPod cost you several hundred bucks, whereas JinglyWiki is entirely free. Free as in you can spend your money on beer instead. JinglyWiki may well be the best portable music player you never paid a penny for. Groovy.

It would be so much more useful with some code to dynamically generate WAVs, but that’s a project for another day.

As for the name, it’s a play on the much more important project Phil Hawksworth has initiated to build a JQuery
based Tiddlywiki framework: JigglyWiki. I think this nascent effort is going to produce some wonderful plugins for the JQuery community and be an important enough project to derive novelty joke names out of :), so I’m setting the trend here.

It makes me wonder if this is the plan for Chrome add-ons. Forget about anything like Firefox’s add-on mechanism and just rely on Greasemonkey. With the right APIs, it’s all you need.

For a long time, I have been confused and disturbed by the disparity between Greasemonkey and Firefox extensions. Creating a Greasemonkey extension is dead simple for any Ajax developer; creating a bona fide Firefox extension is more complicated, and involves writing the kind of meta-descriptions and JARs that most Ajax folk avoid. (The kind of simplicity mantra that has made JQuery king of the hill for now.)

What do Firefox extensions do that Greasemonkey can’t? Nothing Greasemonkey can’t get around.

Extended access – manipulating the Browser Object Model, accessing local file system, etc. All of this could be possible from a Greasemonkey script with the right APIs available. There are security implications, of course, but as long as users are aware of who can do what, it’s no different from what we have now. It may be even better, due to Greasemonkey’s built-in wildcard-based URL filtering, so that certain apps might only be limited to certain domains.

Metadata – certain metadata is present in an extension. This could just as easily be part of Greasemonkey’s metadata.

It’s my hope that Google’s vision for Chrome plugins is Greasemonkey on Steroids, and that this unleashes a whole new ecosystem of powerful add-ons that have until now required too much effort to build.

LOGGING on to Gmail or other e-mail service has become a routine of daily life, completed without a thought. What would you do, however, if you woke up tomorrow, plugged in your user name and password as you always do, but then received an unfamiliar message: â€œUser name and password do not matchâ€?
If youâ€™re a Gmail user, what youâ€™ll want to do after a few more unsuccessful, increasingly frantic attempts is to speak with a Google customer support representative, post haste. But thatâ€™s not an option. Google doesnâ€™t offer a toll-free number and a live person to resolve the ordinary userâ€™s problems.

The gist is, if you want GMail with the assurance you won’t get locked out, pay up $50 a year for support.

$0/year is very reasonable, but there’s a way you can do it for free, and quite simply. You just sign up for Google Apps for Your Domain (note: I’m not a shareholder nor an affiliate, just a fanboy). The catch is you have to own a domain, but (a) they are damn cheap, around $7/year for .coms; (b) it doesn’t even have to be a .com; some other endings like spam-infested .biz and .info are even cheaper; (c) you may already own a domain anyway. (A friend recently showed me a great little website some had put together for his business, with its own domain, but the email was a yahoo! address – more professional to match it to the website ne?)

With Google Apps for Your Domain, you point your DNS server’s MX at Google. If you’re locked out, you can point your MX at another mail server, perhaps your SNS registrar provider as most of them provide some rudimentary support. And you’re unlikely to be locked out anyway, because you can post a special message on a website on your domain, to prove you control it, which will reset the domain admin password. This is all offered free of charge.

Admittedly, this is not a mom-and-pop solution. It’s obviously requires some tech knowledge to own a domain and point its MX somewhere or post a message to it. But certainly doesn’t require hardcore geek-fu either, just a little savvy and willingness to try things out and follow some instructions. If you already own a domain, you may as well go this route over just using a plain GMail/Yahoo account. it’s great piece of mind to know that you, and only you, are the master of your own domain!

I feel compelled to do so because I haven’t seen it mentioned once in the mainstream media during the past fortnight of turbulence, and yet it should have at least played some role in reducing the likelihood and impact of an event like this. Otherwise, it was a waste of effort.

The pain felt in middle America was so intense that Congress enacted legislation to clamp down on such errant behaviour. The Sarbanes-Oxley Act of 2002 imposed stricter levels of disclosure on public company boards, management and accounting firms. It was hailed at the time as a breakthrough in regulating errant corporate behaviour. But it should come as no surprise that about a year ago, during the height of the most recent boom, US regulators were coming under intense pressure to dilute parts of the legislation.
Sarbanes-Oxley, the argument went, had cost Wall Street its coveted position as the world’s financial hub. The high cost of compliance with the legislation had seen international focus shift to London.

The article goes on to explain why it might be not so relevant to the current situation, which is completely dominated by the banks:

The latest crisis has emerged from a different area – the lax prudential regulation of America’s banks. Housing loans were pushed on to people who had a history of default. That’s the definition of subprime.

So it’s not a case of “this is exactly the kind of thing SOX was meant to prevent”. It’s more subtle than that – SOX is only public companies, and not all banks are public; SOX covers all types of companies, not banks which have particularly complex financial characteristics; SOX is about control and reporting, and does not place specific constraints on levels and forms of credit risk.

Nevertheless, many banks are public companies and public companies must comply with SOX (even if the system is developed in the UK…as long as it operates in the USA, it must comply, that’s my legally dunce understanding of the matter). Sarbanes still applied in banks from around 2003. I was working on one project where “pulling up your SOX” was a constant non-functional force lurking in the background of many major design decisions. So, for example, if we were to choose an in-memory database, what would happen to the auditing facility in the event of a sudden crash, would this cause a violation of SOX?

Another system I was looking at working on involved the treasury operation of a prominent American bank, where SOX was a big driver for them to streamline the performance of the system that comes out with a single, very important number: the bank’s overall position.

It’s vastly beyond the scope of this blog to explain away the crisis or even SOX’s (non) effect on it. What I can say, though, from a software perspective is that it feels like yet another standard that’s complex enough, and enforced enough, to drive substantial effort, while being high-level enough to not necessarily be very useful, at least not in cases where the intent was already there.

Alistair Cockburn wrote to the effect, “show me the methodology, and I’ll show you the methodologist’s fears”. We might well apply this to standards and regulations too.

SOX can be very closely tied back to Enron and related collapses and the fear of a repeat incident. However well-intentioned, there are two problems with standards that emerge from fear: (a) forcing someone to not follow the same strategy as that which led to a collapse…is no way to guarantee a similar collapse won’t take place again, for there are many alternative strategies they may take; if you retrospectively try to do what would have prevented recent incidents, you can expect your standard to be gamed hard by those using alternative strategies; (b) even if you can prevent a repeat incident, at what cost? Many times, the constraints you place on creativity and the degree to which your standard crushes human spirit and consequently inhibits progress, these costs may well outweigh the benefits.

Whether these problems were causes by SOX is a topic for debate. But as the world readies itself for a whole new set of controls – many of which will affect your daily work and mine, dear software reader – one can only hope there is big ups on some fair dincum contemplation and ixnay on the knee jerk, eh.

Share this:

G’Day

Welcome to Michael Mahemoff's blog, soapboxing on software and the web since 2004. I'm presently using HTML5 and the web to make podcasts easier to share, play, and discover at Player FM. I've previously worked at Google and Osmosoft, and built the Ajax Patterns wiki and corresponding book, "Ajax Design Patterns" (O'Reilly 2006).
For avoidance of doubt, I'm not a female, nor ever have been to my knowledge. The title of this blog alludes to English As She Is Spoke, a book so profoundly flawed it reminded me of the maturity of the software industry when this blog began in 2004. I believe the industry has become more sophisticated since then, particularly the importance of UX.
Follow @mahemoff