February 28, 2005
How much do you really care about accessiblity?
A lot of people who were once preaching the accessiblity dogma are now hooked on the implications of XMLHttpRequest as the next big thing for web applications. Clearly browsing tools designed to aid the visually impaired will not get along with this new breed of über-dynamic DOM remixing, but the resulting challenges of downgrading gracefully aren't being discussed. This makes me think how honest the heavily hyped move to "accessible" markup has been in the first place.
The way accessiblity is prevalently dealt with feels more like a cargo cult than a well-founded discipline. We have all converted to table-less designs with semantic markup and hidden "Skip navigation" links because someone said it was the Right Thing To Do™, but how many of us have actually used a screen reader? Where did the unanimous consent originate that screen readers would go belly-up at the first sign of a non-semantic <table>, as if these tools were built for a web that didn't even exist at the time? Have you ever watched a handicapped person browsing the Internet?
It is about time to become more honest about accessiblity. A lot of damage has already been done to the integrity of the trade by using "accessiblity", "standards compliance" and "semantic markup" as if they were exchangable terms. Let's stop showing off "AAA compliant" badges as if pleasing a piece of software said anything about your site being accessible. Accessiblity is more than a convenient argument to sell clients another reconstruction of their old site. Accessibility is a serious issue. Don't have your résumé claim you mastered it only because you know how to separate style from content.
February 24, 2005
Serious Perl goes to Print
If you liked my article Writing serious Perl you can now enjoy it on paper in the latest issue of The Perl Review.
Among the usual dose of news, book reviews and the Serious Perl column this issue brings you contributions such as:
- Test::Number::Delta
- David A. Golden
- Barcodes from Perl
- brian d foy
- 9-Block Quilting Patterns in Perl (First Page)
- Daniel Allen
- Packet Sniffing in Perl (First Page)
- Gerry Finkel
- Hashes with History (First Page)
- Alberto Manuel Simões
February 23, 2005
Rails versus Javaland: Why the hate?
If there is one thing that could improve the already wonderful Ruby on Rails framework, it would be David cutting back on bashing Java.
Bashing Java seems to become for Railers what bashing Bill is for the Slashdot crowd, and words can't tell just how fucking sad this makes me. I want to support a great piece of technology without the swamp of politics that comes with it. Can someone tell my why this is so hard?
In order to throw more oil into the fire, both the Java crowd and the Rails community are constantly talking at cross-purposes. David keeps pitching Rails which is perfect for 80% of the web applications out there (and by design opts for simplicity insteads of going for the last 20%) and ridicules Javaland for having to take the scenic route when implementing the same thing. Javaland strikes back by convicting Rails of all the things it wasn't built for, like integrating existing infrastructure or writing distributed applications. Add some background noise about matter-of-taste minefields like persistence and view templates and you have enough ammo to fuel a decade of arguing about nothing at all.
Every second wasted arguing this way could be spent doing something productive. I don't understand how two camps of so obviously intelligent and well-educated people can be so hell-bent on stepping on each other's toes.
February 18, 2005
Stock up on Becks and popcorn!
Coming to a theater near you this summer: The sound of a million CSS hackers crying out in terror, and then abruptly falling silent.
You hack, you have to pay the price.
February 07, 2005
I want to shoot people over the phone line
I can deal with email spam. What I cannot deal with are wankers who presume the audacity to waste my lifetime by calling me and attempting to sell me their fraudulent shit. It's rude, intrusive and of course completely illegal (German page). But hey, both we and the spammers know they're organized crime, so why don't we stop pretending that the fight hasn't left that arena long ago.
Let's start by giving me an option to reject any anonymous or redirected calls to my number. "I'm sorry, but the person you are trying to reach has no business with anonymous callers. Press 1 to reveal your number and retry. Press any other key to go fuck yourself.". I'd also like to have previously unknown numbers be greeted with a message that I'd rather die than buy anything over the phone and if they'd really like to have their call put through.
In the real world, of course, telcos are forced to built Uncle Scroogesque money bins to somehow store away all the profit they make through spam-spewing call centers. But dreams are still free.
February 01, 2005
The state of art sucks
There is a friendly discussion about the philosophical implications of the halting problem going on over at Netalive. I thought you might enjoy the following, slightly off-topic rant I contributed. Quoted is Neil Harmon, another Netalive user.
At least for me, it's hard to imagine a better programming language than the ones we already have.
Personally I am dissatisfied with the current state of language design. I don't have the overwhelming feeling that we're closing in on the best way. The state of art merely seems to be the result of many next logical steps stacked on top of each other. There is little overall concept to what we do. We’re nailing planks together and seeing what happens.
Of course it is hard to imagine something better, because we immediately associate "better" with "improvement to what we have" and the obvious improvements have already been implemented. No one can come up with something radically different on the spot.
What can't you do with today's programming languages if you had enough time and resources?
Even if I could do everything with the languages we have, it doesn't mean there isn't something vastly better. The biggest problem in software design is currently the fight against complexity. Even when implementing mildly extensive requirements complexity grows over our heads much faster than one would intuitively think it would. Object oriented design and, more recently, aspects, have taken away some of the pain, but what remains is a strong suspicion that there has to be a better way.
Also you can only throw so many people and resources against a problem until time required for coordination reaches some sort of equilibrium against productivity. And even unlimited resources do little to banish the scourges of complexity, increase of coupling and loss of cohesion.
Centralized trust assurance considered nontrivial
Rumor has it that Netscape 8 will help you decide whether you should trust a site:
Netscape is in talks with various security companies to obtain blacklists of sites that are suspected of harbouring spyware, phishing scams and other nasties. The browser will display warnings when visiting blacklisted sites and disable features like ActiveX, scripting and cookies. Conversely, whitelisted sites will be highlighted with a green light icon.
Let's assume for a second that this new feature would become popular enough that being ownz0red by Netscape's blacklist would translate into a decline in someone's sales of penis enlargement patches. What about companies trying to blacklist their competitors? Who would handle the daily flood of requests to be whitelisted? What if someone was challening their inclusion in Netscape's blacklist? Who would bear the legal brunt of lawsuits from spammers suing for their lost ability to rape the stupid?
I applaud the attempt to draw a clear line between fraudsters and real people. Come the revolution, we would know exactly who to hunt down first. Nonetheless, drawing that line isn't a job I would like to do for an entire planet.
As opposed to hunting them down of course. I could spend a lifetime doing just that.
