I'm one of those people who has about 9 different email accounts at any given time, one of which is gmail. Yesterday I discovered about 50 legitimate emails had been diverted into my spambox this week, for no apparent reason. I'm guessing that there was some kind of spam-bomb that went off and pushed their filters way up the scale for a day or two. Up until this point it's been one of the most reliable and efficient spam filter's I've used.
As a result I've been thinking about Google a lot the past few days. There's the new Verizon Motorola Android phone on the market. There's the Google Books settlement that just came out:
http://news.cnet.com/8301-1023_3-10397787-93.html?part=rss&subj=news&tag=2547-1_3-0-20
And an interview with their CEO talking about Google's successes and challenges:
http://news.cnet.com/8301-30966_3-10396865-262.html?tag=rtcol;inTheNewsNow
I think the most interesting aspect of this interview is the problem of scale that they are up against. I've been noticing recently that the quality of searches have started to suffer, as they struggle (or fail) to keep up with the new media and blogosphere.
Once again the scale and structure of the internet is changing, and they may have to revisit a number of the assumptions that they build their search engine upon. Which leads me to the question of "how do you plan for fluidity?" How do you plan for a system that is dynamically alive and changing at a pace that only seems to accelerate?
I don't know if anyone has a really good answer for these questions, but I do think the world of computers has some solutions in the works, namely, what I like to call abstraction.
When I was learning to write a simple web application in PHP last spring, the first thing I did was write a bunch of 'classes' that would define objects. Those classes called the database and fetched the data, handling it in the terms defined. All of the PHP I wrote after that called on the classes, calling these 'objects' rather than calling directly to the database.
The beauty and elegance of this is that (in theory) you can change the structure of the database radically, and you only need to change the affected classes. The rest of the code can run, virtually unchanged, on those modified classes. I like to think of it as a type of data abstraction, where the code calls the database via an abstracted, a mediated channel, rather than the database itself.
This is, however, not unique to PHP and web applications. As I understand it, all object oriented programming languages function similarly, defining and calling objects, whether the definition is called a class or a library.
This is, again, not unique to object oriented programming. All of the Linux machines I've used rely on what's called a 'hardware abstraction layer'. Basically the operating system calls this abstraction layer and the abstraction layer acts to communicate with the hardware. One of the big problems with talking to the hardware directly is that if it fails to respond, the system hangs, freezes or crashes. So rather than writing a specific response to every type of possible failure, they rely on the hardware abstraction layer (HAL) which will communicate back to the operating system if the hardware fails to respond or perform normally. Furthermore, if the hardware changes, the operating system doesn't have to change the way it calls the hardware. In my opinion this is one of the main reasons that Linux has made it it out of the geek pit and into the playing field. Prior to this Linux was synonymous with 'hardware configuration nightmares'.
Which leads us back to the question, are there new ways that we can abstract our library functions, our information systems, such that the structures can change without having to create whole new systems? How will we afford flexibility even in our abstractions such that they too can change?
No comments:
Post a Comment