Today, Mozilla Labs announced yet another new product to add to its long list of experiments and prototypes. First things first -- let us pray that this experient will fare better than its predecessors (Weave and The Coop, I'm looking at you...).

With that out of the way, let us examine precisely what it is that we so fervently wish to preserve.

To hear Aza Raskin of Mozilla explain it, you would fall under the impression that Ubiquity is essentially a dream, and that dream is to make natural language processing a reality in the context of bringing web mashups to the masses. The following ultimate example goal sums the project up fairly well:

Book a flight to Boston next Monday to Thursday, no red-eyes, the cheapest. Then email my Boston friends the itinerary, and add it to my calendar.

To which the system responds:

Leaving from SF to Chicago on March 20th at 9am. Returning on March 24th at 7pm. Itinerary will be sent to Andrew, Margaret, and Josh.

Elegant, efficient, and if done right, revolutionary. Essentially, Mozilla Labs wants to make that old Apple Newton web ad a reality.

However, the current prototype does not reflect this goal. Instead, it exists today as a launcher, a necessary menagerie of smaller plugins which connect to various different web applications and services, the composite whole of which may yet someday form this natural language beast that Aza and his team have envisioned. This shouldn't faze anyone, however -- in fact, I'm actually here to argue that the prototype is brilliant as is. First, some background.

Inarguably the most powerful utility on Mac OS X is Quicksilver. To most people, Quicksilver is simply a faster alternative to Spotlight for application launching purposes: if you need to load Word, just hit Ctrl+Spacebar to pop up Quicksilver, type "Word", and hit enter. Much faster than going to the dock, and definitely better than the half second lag that Spotlight suffers from for the identical operation. However, Quicksilver is much more powerful than that, and represents in fact an entire philosophy, which creator Nicholas Jitkoff once detailed in a Google Tech Talk.

In the standard operating system shell paradigm, the goal of the OS browsing interface is to get you to the application. From there, you're on your own. Thus, browsing the filesystem is the key and the model on top of which most operating system shell interfaces are developed -- Windows Explorer, Nautilus, Finder, etc are all designed to let you browse through your hierarchy of files and eventually select a file or application to execute.

The key philosophy behind Quicksilver is that this barrier is an artifical construction, one that need not exist. Sure, Quicksilver will let you browse the filesystem and launch applications faster than anything else on the market, but the real beauty behind Quicksilver is how it lets you step past the filesystem. There is no need, for instance, to stop once you reach "iTunes.app" -- you can, within Quicksilver, navigate straight into iTunes and browse your Library as if it iTunes were merely a folder and you were still browsing the filesystem. This far-reaching mentality is what makes Quicksilver truly powerful and flexible, and is where most power users spend their time with the utility.

The filesystem-application barrier is artificial and need not exist.

Now, let us at last take a look at the current incarnation of Ubiquity. As demonstrated in the screencast, the plugin is currently essentially a launchbar, from which contextual actions may be launched. You can, for instance, highlight an address, call Ubiquity, and tell it to "map," which will not only load Google Maps, but let you drop it into an email you're writing. Similar functionality exists to find things on Yelp and other web services. It also lets you do things, such as highlight foreign language text within a page and ask Ubiquity to translate it in-line, TinyURL a URL, or tweet about things that you see around the web.

Thus, I would argue that Ubiquity is currently Quicksilver for the web. And perhaps it wouldn't be so bad to keep it that way. Essentially, Ubiquity allows Firefox to become more than a web browser, in a nonobtrusive way: it becomes an active component of the web. You can execute actions on any webpage through the browser to any supported web service.

Essentially then, the core philosophy [at the moment] is that the browser/URL-web application/services barrier is artificial and need not exist.

Ubiquity is tons of fun to play around with, and will probably become a core part of my Firefox experience before long. But does it need to be anything more? Quicksilver for the web is already an ambitious goal, and while natural language programming would be nice, this set of features and this paradigm is here now. And I think the web is ready for it.

I had an interesting conversation with teacher and friend Clifford Tatum on the subject of my previous post, Collaborative Work for the Future, largely as a direct result of having freshly written and published its content. While a large part of the proceedings revolved around the difficulty of uniting communities, technologies, and needs (among other things), we raised many more questions than we answered, and so I would like to start by pointing out a few examples that I now realize fall under the wing of non-software-development collaborative platforms which I would like to address.

First is Microsoft's SharePoint. While it certainly provides a collaborative platform with revision and user tracking, with the added benefit of a useful, rich, and familiar working environment (Microsoft Office), it has more than its share of significant shortcomings. One is the sheer mass of technology involved: dedicated servers are needed to power the platform, with enterprise-grade database (MS-SQL) and web (IIS+ASP.NET) services. The amount of setup work is remarkably prohibitive and upgrading the software components is a nightmare, on top of which the entire platform is built to function mostly in a trusted Intranet environment, not for worldwide collaboration. In addition, the whole package, which requires not only the SharePoint software, but also the aforementioned Windows Server, MS-SQL, and ASP.NET licenses, tally up to a rather frightening price tag, on top of the maintenance and server upkeep costs. Clearly, this solution is aimed at medium to large businesses, and not the average user or researcher.

A similar product to SharePoint is Alfresco. I haven't personally used it, but it's built entirely on an open-source software stack, and is free to use. It has yet to make any major waves on the market, and since they don't appear to offer fully-hosted services based on their software, installation is again a key factor. However, it might be interesting to keep an eye on them in the future.

Another example which came to mind after-the-fact was Google Documents. What began life as Writely and Google Spreadsheets has slowly evolved to become a usable, albeit limited office suite. And, due to its origins, collaboration was built in to the platform from minute one. It's free, fully hosted, and ready to use the moment you own a Google account, offering comprehensive live-edit, sharing, security, and revision support. It's exceptional at what it does. What it does, however, is the issue – once again, even though Google Docs wants to be a fully fledged office suite someday, it simply isn't there yet. All the features it supports are on a me-too level, and Javascript in browsers is simply too slow and glitchy to be relied upon just yet. In the end, the platform still ends up being a web-medium lock-in, much like the wiki solution is. It will be interesting to see, however, how the product evolves in the future.

But what do the researchers need? What do non-profit organizations need? Does there need to be comprehensive project management features built-in to the document collaboration platform? What is the key ingredient that is missing at the moment? This difficulty in uniting communities with technologies and addressing their needs head-on has been traditionally (one would assume) a barrier to the advancement of these technologies, and needs to be addressed.

Perhaps now that I have a small handful of research projects under my belt, finding out what researchers and small organizations want is my next step.

Communication has long been the most-touted invention of the modern era – first telecommunications, then the Internet spawned a society where people are not only able to communicate instantaneously, they are able to do so with complete ease and near ubiquity. Services like Facebook, Twitter, and the various Instant Messaging protocols connect us to each other at nearly every breathing minute.

A byproduct of communication – the one I'd like to focus on today – is collaboration. While communication and communication technologies provide the inroads to facilitate collaboration, the ability to transmit data of any form to one another instantaneously is not enough to genuinely collaborate. As network technologies, then web technologies, then rich media technologies began to grow, however, we have seen increasingly frequent attempts to provide a complete system for collaboration. Videoconferencing packages, for instance, provide unique features such as shared whiteboards or screens, allowing for work to happen across the globe in ways never before imaginable. However, this is still a fundamentally communication-oriented development, which while immensely beneficial to collaborative efforts, doesn't necessarily address the ultimate goal of building a single product, paper, or project.

So, how do we better use technology to facilitate direct collaboration?

There are several bits of software that attempt to address this issue head-on, but being by developers, they largely address developers' own needs – the rest of the world hasn't necessarily woken up to technology's potential in this regard, and so very little attention and effort have been raised towards furthering these projects in other directions.

These pieces of software are known as VCSs, or Version Control Systems. Several prominent examples are CVS, SVN, Git, and TFS. Three-lettered length aside, they all tout a number of core features – the ability to keep track of revisions and who made them, the ability to view or roll back to any of these revisions, and the ability to merge two versions of a file if, say, they were both being worked on at once. While very efficient, useful, and relatively simple for people working on software, these systems are on the difficult side for even moderately technologically proficient users, and setting them up is a nearly insurmountable task, one even seasoned experts tend to dread.

So, what's out there that's easier for the general public to use? The solution that my Amsterdam study abroad class appears to have chosen is to repurpose a wiki for the task. And at first glance, it appears to be a fitting choice – wikis generally feature user and revision tracking, and at least a rudimentary form of diff merging. However, they are also a very restrictive medium – one wouldn't be able to build a trifold brochure, or a technical manual on them with any sort of practicality: while it may be possible to format the wiki to look properly in these regards, these things tend to be done with real desktop software, with real formatting tools and rich output. Adobe has a solution for its Creative Suite that's slowly evolving, but what of the rest of the business and academic market?

It's pretty obvious to those who know me either through the words here or in person that I'm a fairly staunch progressive/liberal. I believe, for instance, in rights. Hey, fancy that.

Fiscally, though, it's a mixed bag. Too much market freedom (as I believe we have at the moment) will yield the way to corruption, consumer exploitation, corporate greed, and general mayhem. Too much regulation, though, and you run the dangerous risk of stifling entrepreneurship and innovation. Of all these potential evils, the one I fear the most (and sadly the one that comes to pass with the greatest ease) is the intrusion of the private sector into the government through corruption, and so I lean towards increased regulation. Once again, I point my finger at recent events.

So on one hand, I support the de-privatization of the healthcare industry.

On the other hand, though, it becomes clear at some points where the government needs to cut back. In this particular instance, I'd like to focus on NASA.

Overview

I'm a big fan of NASA. Were I to single out the greatest and most awe-inspiring technical achievement of mankind thus far, it would be far and away the Saturn V "Moon rocket." And, technical nightmares aside, no space organization has yet to create a spacecraft as elegant as the Space Shuttle. However, as media excitement and public interest over the International Space Station begins to wane, people are beginning to wonder what the next step for manned space exploration is.

NASA's Purpose of Being

Having run out of options, the Bush administration and NASA got together and answered, "Moon base and Mars." Here we run into the first problem. NASA's overarching goal was to further the advancement of human society and improve human life through space exploration. This included, explicitly, the external probing of the Earth from outer space. It seems that NASA realizes that a base on a large rock we've thoroughly explored has absolutely no bearing on these goals, and so as of 2006 it changed its official mission statement to "pioneer[ing] the future in space exploration, scientific discovery, and aeronautics research." Ah, now they have a legitimate argument for a Moon base! We haven't built a base on a rock besides the Earth before, so this is pioneering space exploration! Sadly, the Moon is just a rock, and so any base wouldn't be able to sustain itself, requiring supplies to be sent to it at both literally and figuratively astronomical cost, and to little scientific benefit.

And at what further costs? It was reported around the same time that all these other changes were made that NASA was drastically cutting its budget on general climate studies programs directed at our on precious planet. What will be the point of exploring Mars for life if we don't even understand our own planet, and cut off our primary means of studying it as a whole? NASA science director Alan Stern has been responsible recently for fighting back at the cutbacks in critical science-related areas and pushing for more useful and relatively inexpensive unmanned science to be done; he's been trying to get NASA back to its roots of benefiting mankind as a whole. His reward? He was gently pressured out of the organization by current NASA administrator Michael Griffin.

But whatever, this is past history and we're going to the Moon and Mars whether I like it or not. Let us examine how NASA intends to deliver that goal.

Ares

NASA's new project is Ares, which comes in three configurations at the moment: the Ares I will provide manned crew support for the CSM-derived Orion, the Ares IV will provide combined cargo/manned crew lift support, and the Ares V will be the heavy lifter for cargo, primarily for Earth-orbit rendezvous purposes. The goal behind the Ares project is to reuse as much of the technology developed for the Space Shuttle program as possible -- this is referred to as "Shuttle-derived launch architecture." In theory, the reuse of Shuttle technology will expedite the development process and lower costs, in addition to preserving the jobs of those technicians currently working on the Space Shuttles.

However, it seems that none of these purported advantages have panned out. NASA has become increasingly conservative in its estimated date of launch, currently placing a 65% chance that a mission will launch by 2015. Until then and after we phase out the Space Shuttle in the next two years, we will have to utilize Russia's Soyuz launch and spacecraft hardware. In addition, NASA has remained suspiciously mum on exactly how much each launch will cost, while the Ares program as a whole has already cost $7 billion.

Furthermore, there have been accusations that the so-called "shuttle-derived launch architecture" isn't even close to as shuttle-derived as possible. In fact, a proposed alternative, headed by NASA employees on their spare time, called DIRECT was a proposal which would have drastically reduce the amount of engineering required to put NASA back in orbit, in addition to significantly reducing costs. NASA, however, pushed the proposal aside, calling Ares the "right set of rockets for the mission."

When it rains, though, it pours, and it's telling how many NASA engineers are skeptical enough to develop solutions on their free time. Another set of engineers has been working on another alternative, known currently as Jupiter. The alternative rocket would be simpler technologically, which generally leads to safer and more economical operation. Indeed, the development savings alone could total $35 billion. Once again, NASA pushed the proposal aside for not meeting some critieria or another, but is this not why the scientific community exists? To collectively work to solve problems? Surely, these alternative solutions, all crafted by NASA engineers themselves, aren't completely infeasible? And, given the amazingly tangible immediate benefits these designs offer, why is NASA not at least working with these groups to improve their designs?

The Private Sector

The private space sector is great. For the sake of profitability, any private space company must not only ensure rock-solid reliability from launch one, it must constantly innovate and optimize to improve costs and performance to compete in an ever-widening market. Gone are the delusions that the government will absorb the fiscal blow of a failure in the name of the progress of mankind.

That being said, NASA's short-sightedness does not apply solely to its own hard-working engineers. Eagle-eyed observers will note the similarity of the Ares family's specifications to those of the Atlas rockets and particularly the current Boeing-built Delta family of rockets. These are private-sector solutions that have proven themselves over time commercially and are available today. NASA's valid concern that manned spacecraft require triple-redundancy is, as noted in the reference linked, no reason not to attempt the retrofit process.

In addition, PayPal founder Elon Musk never ceases to impress with his leadership in Tesla Motors, SolarCity, and SpaceX. SpaceX's rise to the forefront of the private sector space scene has been meteoric and remarkable. Relying only on in-house technology developed from scratch with simplicity and pragmatism in mind, the fledgling company will very soon have a full lineup of rockets comparable to the Ares or Atlas rockets. In addition, SpaceX's manned space program, called Dragon, has been absolutely tearing through NASA's Commercial Orbital Transportation Services program, passing many performance and technical NASA reviews in one try, while other companies struggle for months at each milestone for a green light to proceed. Clearly, then, it meets technical specifications for manned spaceflight. In addition, SpaceX is currently aiming for a 2009 launch window for the Dragon. They could delay for 7 years and still have a 65% chance at beating NASA to space!

How does a 400 person company founded 6 years ago create not only a commercially competitive full lineup of rockets and a manned space capsule capable of a full line of work from scratch while NASA's thousands of engineers and contractors burn through billions of our hard-earned money?

Conclusion

It might be time that NASA stood aside. Not completely, of course. But, when it comes to a pure technological standpoint, it has become clear that NASA's leadership and prowess is rapidly fading. When it comes to repeated hardware such as launch vehicles, it's now more than proven that NASA simply cannot compete with a private sector which is constantly and rapidly developing in order to compete with itself. There is no need to waste hundreds of billions of government dollars when private companies are already investing their own money into developing solutions. If NASA were to adopt this mantra, it could use those suddenly-freed billions to study meaningful things, such as our own planet, or the further reaches of our own solar system. We could build a proper replacement to the Hubble telescope, whose imagery has delighted and inspired many a child and whose success has brought much positive attention to NASA.

The time for massive government development of technology is long past. Let other fools waste their own money, NASA. Stop wasting ours.

Carbon nanotechnology is extremely promising. It will provide cooler, smaller circuitry to relieve the rapidly aging silicon technologies, it has given us the Memristor, it will allow us to efficiently target and destroy cancer, build a space elevator, develop fuel cells, and a veritable plethora of other applications. And, with new methods of mass producing them being developed constantly, the future looks bright.

The past week, however, has not been kind to the development of carbon-based nano-technology. First, we found out that longer carbon nanotubes are rather unfortunately similar to asbestos in a disconcerting number of ways, particularly in how the long fibrous tubes behave. There is a chance, therefore, that they may well cause cancer in the same way that asbestos does: long fibers are inhaled, whereupon cells in the lungs, unable to deal with such long, thin fibers, freeze, inflame, and eventually scar and develop into cancer. There is no complete study on the issue yet, but the resemblances are alarming.

As well, it seems that Buckminsterfullerene, better known as the Buckyball, is capable of crossing over lipid cell membranes with almost no effort - this also means that they could, according to the laboratory that ran the computer simulation, cross the all-important Blood-brain barrier, which keeps our brain free of invasions and toxic elements. It remains to be seen what the consequences of buckyball invasion into cells are.

This turn of events is sobering and unfortunate, but that attention is being paid to these types of issues is certainly reassuring.

It's been a while since a video entitled "Web 2.0 .. The Machine is Us/ing Us" circled around the web. For those of us who live in Web 2.0, who think constantly in its context, the video was nothing new, but simply provided a neat, bundled package summarizing a number of its tenets, potentials, and quandaries.

The core idea presented in the video is that of form and content. Mike Wesch, the author of the video, argues that with the advent of XHTML and RSS/ATOM, effective separation of form and content has been achieved, and information sharing has become not only easier, but a core principle of the Web, vis-à-vis Web 2.0. This is currently arguable, as the quality of code dictates the level of separation afforded in each individual instance. HTML5 is fascinating in that it provides more native mechanisms for determining these separations without sacrificing expression of form.

The point at which this conversation becomes interesting is that at which we turn the argument upon itself: what is the medium of the video? One of Wesch's more tangential (and thus questionable) assertions is that the separation of form and content has directly led to the influx of the user-generated web. What is inarguable, however, is that without the user-generated web, his video could not have possibly existed in the plane it currently does. It is thus appropriate that a video about the web is in fact a video on the web.

Likewise, Philip Thurtle, in his book The Emergence of Genetic Rationality, focuses on, among many other topics, the necessity of effective information collection, collation, and communication in the rise of certain forms of social consciousness, among them genetic rationality. In fact, in the introduction of the book, he comments on the organization and information principles followed by the book - this bit of meta draws attention to the book as the medium, as the ultimate culmination of a certain process of information processing which is perhaps the most final and arduous of them all.

On the other hand, the media in general filters out instead most commonly over the mediums of print, the web, and television. The most interesting point here is in fact the medium itself - each communicates in an entirely separate way, organizing and shaping both form and content with radically deviant methods. When ground down to these separate considerations of form and content, the concept of the television as a medium seems to become the most bipolar, and the print medium the least. When we consider the effect of the content alone, it seems that given the wealth of content on the Web, to survive in the medium means that content is of absolutely key importance.

These deviations are things to consider when considering other concepts relating to media.

Every once in a while, you see a bit of news that makes you wonder what on earth executives smoke. This is one of those things.

Many of you probably heard of NBC's little spat with Apple. The short version is that NBC pulled all of its shows from Apple (which were making both of them boatloads of cash), claiming that Apple's restrictions were too tight. Apple then came out and informed the waiting public that NBC in fact wanted to charge $4.99 an episode, up from the standard $1.99 that it enforces across the board. NBC, of course, denied until its sales died.

Since then, there have been rumors of the two getting back together. NBC did one right and launched Hulu with Fox, which is an excellent service and which represents a vast step forward in traditional media's representation in the internet world. My only complaint with it is that they no longer have the entire catalogs of shows that are currently running up for stream, which is an egregious error: this is the Internet, why limit content access and revenue?

Well, NBC's chief digital officer George Kliavkoff has done it again. They want to return to iTunes, but they want to prevent anybody from putting their content on iPods.

I'll say that again.

NBC will put their shows on iTunes, but they want Apple to prevent anyone from putting their content on iPods.

What?

The point behind the iTunes Music Store is that the content can be brought with you, that it can be put in your iPod. Most people I know who download television shows from iTunes watch them on the go. Once again, NBC misses the ball. Badly.

Someday, perhaps, a new generation of executives will rise who will understand the Internet and technology and what it's all become. For now, we get to live under the wisdom and guidance of George Kliavkoff.

Much has been made out of Windows Vista's failure, which at this point is rather (and unfortunately) undeniable. One particular topic of debate is the point at which XP will no longer be sold, which may perhaps also be characterized as "the point at which Microsoft starts shoving Vista down their customers' throats." That point is currently June 30th, 2008.

The problem, of course, is that no one wants anything to do with Vista. Downgrades are frighteningly common, and the operating system is simply not nearly as refined as XP is, by virtue of having not existed on the market for quite as long. In essence, in the process of waiting so long to release Vista, Microsoft shot itself in the foot by - directly or indirectly - refining Windows XP to the dreaded "good enough" point. Vista's (lack of) quality, of course, did not help.

So Dell doesn't want to sell Vista exclusively. People don't want it yet, and Vista means more support calls, with questions that may not yet have answers.

Microsoft has the answer: sell XP, but we're counting them as Vista sales.

Yeah, that's right. When your operating system fails to sell, save face by pretending it sold. Here's another idea, Microsoft: get it right with Windows 7. Then we wouldn't have to deal with the highly questionable bookkeeping we're not facing.

[Via Gizmodo]

Hardware enthusiasts will remember the hubbub made out of the development and impending release of the Cell processor back in 2005 and 2006. A joint effort by sony, Toshiba, and IBM, the Cell processor was supposed to revolutionize the electronics industry, rock the core of it to its bone. The basis of the Cell ideology was to be that it produced high performance not by virtue of running necessarily fast, but instead through its networking capabilities with other Cell processors. The Cell itself was supposed to be tiny enough to put in everything - your TV, set-top box, radio receiver - even your refrigerator and microwave were supposed to be able to accommodate the Cell, it would be so cheap and tiny. And, when they all talked to each other, your home would become a veritable supercomputer. Of course, the fact that the first application of this mythical technology was to be a next-gen gaming console whose power would rival that of desktop computers at its launch should probably have been enough of a warning that this would not be the case, but nevertheless the Cell has yet to find its way into my alarm clock.

So the idea of desktop-class processors powering your everyday household appliances was lost to the ages - for a time. Apparently, and incredibly, Intel has been paying attention, and have given the concept try itself - and this time, it looks like they may be successful. Their strategy is to put a cheap implementation of x86 on a chip that is easy to manufacture in droves and runs cool enough that it does not require auxiliary cooling. "But wait," you say, "the x86 is the architectural brain behind the Pentium and Athlon chips! That's desktop class! Intel has already made its first folly and we haven't yet begun." And you would be right, of course, if Intel has approached this chip with the same mindset as it had with the Pentium (especially the miserable Pentium 4, which gave us the horrific NetBurst architecture). But there's more.

The power of the x86 ISA isn't necessarily in any particular design strength. In fact, it is an architecture with a number of marked flaws and weaknesses, particularly a slight dearth of available registers. Rather, the power of the x86 is in its popularity - everything these days is written for x86, and the resulting pre-existing libraries and optimization knowledge is a huge boon for any project that deems to use it. And of course, Intel itself has had substantial experience with the x86 set itself. So, they began there.

I will only cover the technical details of Intel's entrant into this market, called the Atom (and codenamed Silverthorne) in brief. For significantly greater detail, you could peruse the Anandtech article on the subject. In short, the Atom is tiny, efficient, and reasonably fast. Its most interesting architectural feature is that rather than allowing out-of-order execution, the Atom is strictly in-order. This means that if the Atom runs across an instruction that it knows will require main memory access (an incredibly slow process in terms of the sheer speed at which processors run), it cannot take the liberties nearly every processor since the original Pentium has done, and choose other instructions to run first. The reason for this decision is due to the aspect of the Atom that I find much more interesting - the emphasis of efficiency in the development process.

The implications of the adoption of this particular mindset is a revolutionary one for Intel, and one that should be adopted across all projects, not just the Atom. Already on a solid path of recovering the CPU crown from AMD after the dark years, Intel had already begun to push efficiency with its various and successful Core architecture processors. However, Atom takes it a step farther. While the standard mantra in Intel right now is that if a feature will increase performance by 1%, it may increase power consumption (and this heat dissipation) by no more than 2%. With Atom, this latter statistic has been reduced to 1%, the result of which is that the Atom runs at incredibly fast speeds - up to 1.8Ghz - without need for any sort of external cooling whatsoever. This accomplishment is also due in part to Intel's success with the 45nm fabrication process, and the size of the Atom - less than a quarter of a penny - means that Intel can manufacture these things for an estimated $10 $6 a pop.

Another interesting feature of the development process of the Atom was that the processor itself was designed in incredibly small chunks, or "modules", of which each developer was in charge of several. This means that developers are able to work more freely from the constraints of the processor development process, with the various stages, especially layout, less locked together. In addition, this made locking the footprint of the die down much easier - if any developer wanted more space for one of their modules, they were required to convince a neighboring module to give up some room.

It remains to be seen whether the Atom processor will revolutionize the consumer electronics industry. I hope it does, as the machines people buy these days are in increasing need of such technology - Blu-ray and (hah) HD-DVD players are becoming increasingly slow, and televisions are having to deal with increasingly ridiculous resolutions, resulting already in a slight lag that any serious gamer would have noticed by now. It will also make Intel spades of money, which isn't a good thing for the yet-again underdog AMD (which I still hope will make a comeback after the terrible Phenom), but the beauty of the decision to use x86 shines through again - AMD could easily manufacture competing chips. VIA has been in the low-power x86 business for years, with its nano- and pico-ITX classes of ridiculously tiny x86 computers.

What can be seen immediately, though, is the benefit the development process of the Atom can and hopefully will have on Intel's general mindset. Efficiency and modular development are features that will benefit not only Intel, but consumers as well.

It seems that IE8's standards compliance may not be nearly as impressive as we had hoped. As reported on Download Squad and elsewhere, IE8 only passes the Acid2 standards compliance test if you visit the official one: if you visit an identical mirror elsewhere on the web, it will fail. Microsoft's reasoning for this?

IE8 fails the copies of ACID2 due to the cross domain security checks IE performs for ActiveX controls. Since IE does not natively handle HTML content in the OBJECT tag, but rather uses IE’s rendering engine as an ActiveX to display this HTML content, the same cross domain security checks also apply.

While it seems like a legitimate enough reason to fail, and Microsoft is understandably scared stiff about anything that might even vaguely resemble a security hole these days, I can't help but wonder why the other browsers don't have this problem.

For true, I never visited this whole debacle in the first place, but now seems like a good time to "re"visit the issue, as the IE team at Microsoft just announced that they have reversed their previous decision to continue supporting by default IE's "quirks" mode. This is a resounding victory for developers everywhere.

It's no secret whatsoever that Internet Explorer has traditionally shown a flagrant disregard towards standards in general, especially those put forth by the W3C. There are few to no web developers whose first utterance upon hearing mention of the browser is not a string of curse words; while other browsers' discrepancies with regards to standards are often minor, easily reparable issues in practice, Internet Explorer's behavior is often so far out in left field that it would seem far simpler to just code a new site from scratch to account for the browser. This is precisely why standards are important, as they save the developers time, improve the end user experience, and make the world a happier place; however, Microsoft has historically pushed its own idea of "standards" upon the web developer base, which is to say its own idea on how to implement what the W3C has already done. To this day, Internet Explorer supports only VML, and not the W3C-approved SVG that every other browser supports, and indeed was created out of a W3C merger of VML and PGML.

To be sure, Internet Explorer 7 is a step towards the right direction; transparent PNGs are now (finally) supported, and the box model has been repaired to some extent. However, because IE7 continues to support the broken model of IE6, and because there is no standards-compliant method of distinguishing between browsers, the addition of yet another tier in compliance from Microsoft simply made matters worse - now there are three entirely seperate cases to account for when developing for the web, rather than the two that existed before.

The solution of course is to not only improve upon IE's standards compliance, but also to force the phase-out of the previous, broken models of IE. This isn't good for diplomacy on Microsoft's behalf, but it's the right move to make for the future, and developers would appreciate Microsoft for it. They'd previously refused to make this move, but with today's announcement, Microsoft is further proving that step by agonizing step, they are making up slowly for the grievances of the past. Here's to the future.

The big story of the day: Microsoft aims to acquire Yahoo to the tune of a lean $44.6 billion dollars. And what a story it is.

It makes sense, of course. Microsoft's web presence isn't where they want it to be. While long-term gains may eventually be gained from their online service convergence into the "live" brand and domain, what they have migrated now is fractured, and imprinting the live brand rather than the old services into peoples' minds will take a while yet. Worse yet, Microsoft is loathe to let go of the MSN brand, which it has invested countless time and money into: MSNBC has proven its worth, and with the home page of seemingly every other web browser in the world set to msn.com, it's hard to fault them for this. However, the move is one that has to be made if Microsoft wishes to truly unite its web presence.

The fight isn't about services though, of course: it's all about advertising. Microsoft's purchase of aQuantive last year has made headway into the battle, but has been largely disappointing. The Google advertising juggernaut continues to plow forward, and with the DoubleClick acquisition having been approved and looming on the horizon, the advertising market for Microsoft is starting to look less like an uphill battle and more like Mount Everest.

So, Microsoft's purchase of Yahoo would earn it at least a bit more foothold in a market one of its most fearsome rivals dominates. But what does Yahoo gain? They aren't doing well financially at the moment, but then again, they haven't been doing well financially for years. Perhaps the execs will see this as a chance to finally dump their woes on someone else for good; it remains to be seen. For now, while they appear to be extremely cautious about their public reactions, their stock is leaping by spades.

While Yahoo isn't what it used to be, it will be extremely interesting to see how this story unfolds; could this be the end of one of the web's biggest giants?

Whoever designed ASP.NET 3.5 MVC is a huge fan of Rails.

If you read one sentence of this post, that's the one; you can stop reading now, most of the article is done. From that phrase, you can infer most of the sentiments I am about to force upon you, the reader: ASP.NET just got a lot less mangled, MVC is winning the day, pre-enforced design patterns are good, and ASP.NET developers should be very, very happy.

ASP classic was just that: Microsoft's classic web development framework, laden with inline code, no templates, and terrible design practices, not to mention a general development model that most of the company's previous platform developers had no grasp or bearing upon. Sensing that ASP classic could only ever play second fiddle to the all-too-similar PHP, and hoping to rope more of its existing developers into the whole web thing, ASP.NET was born. In a move that made sense at the time given the above conditions, ASP.NET was sculpted to resemble Visual Basic's model as closely as possible: Interfaces are designed, then wired with events which are fired, with most of the heavy lifting being done in a code- behind file. Nifty bits and pieces came together like the use of controls and postbacks.

Unfortunately, the web isn't built like a desktop application, and ASP.NET is often needlessly complex and piggish to compensate - it spits out often unintelligible markup which the developer has little control over, and ViewState data rides down and back between the server to manage page status, a costly bit of bandwidth depletion which is often abused, resulting in ghastly results. It is altogether far too easy to write terrible code in ASP.NET, with ill-defined design patterns. Learning the intricacies, idiosyncrasies, and idiocies of the ASP.NET web framework is a lengthy task, to the extent that being able to accurately spill its guts is a rare quality in a developer.

ASP.NET MVC futures represents a step back from that overreaction Microsoft had so many years ago. Markup you write is passed straight through. Everything is properly wired up to post data back in a more traditional web format. This should hopefully lead to cleaner, easier to manage applications than the behemoths ASP.NET 2.0 tended to create. However, even more interesting is a strange resemblance to many of Ruby on Rails' structures - routes are declared and processed in a nearly identical fashion, and helper methods and classes are used to aide in template processing, not to mention an uncanny resemblance in directory structure all add up to a tribute to the beauty and simplicity of Ruby on Rails. These are all good things.

You may be wondering what the justification is for the strange article heading. In exploring the MVC framework, the similarities between its setup and Rails' structure makes comparing design philosophies of the Rails team and Microsoft very easy -- and somewhat enlightening, bringing up the interesting question of an "80/20" type of problem.

ASP.NET is convoluted, yes. It is, however, also extremely flexible. Because it is built on the .NET framework, and because much of the web framework and application's interals are either exposed or redefinable via the XML web.config settings file, it is possible to strip out nearly anything in ASP.NET and replace it with a custom solution. This design philosophy is still extremely prevalent in ASP.NET MVC in spite of the nailed down design pattern models and more web-friendly development model, and the extreme difference in this regard to Ruby on Rails makes a greater pattern more evident. One example of this is in the handling of route mapping. The following two extracts of code do the same thing in different frameworks:

ASP.NET MVC
RouteTable.Routes.Add(new Route
{
    Url = "[controller]/[action]/[id]",
    Defaults = new { action = "Index", id = (string)null },
    RouteHandler = typeof(MvcRouteHandler)
});

Ruby on Rails
map.connect ':controller/:action/:id', :controller => 'blog'

It's immediately evident which one is cleaner. With fewer niggling bits to mess around with, the Rails implementation seems to be the clear winner. It even saves itself an object initialization that ASP.NET puts itself through, though it may be argued that Rails' performance is middling enough that it's a nonfactor. Indeed, if we look beyond the mere appearance of each block of code, we find a number of mysterious pieces in the ASP.NET implementation that seem completely superfluous and repetitive: why do we need to specify that the id should be null by default? Why do we have to specify what the type of the Route Handler should be; why can't ASP.NET assume a default? Why do we even need to instantiate a new object? What is all of this extra work that ASP.NET wants us to do that Rails is perfectly happy inferring?

The answer lies within a phrase heard in Scott Hanselman's webcast showing off the framework:

"In this particular instance we chose convention over configuration..."

This is a telling phrase; an instance of convention over configuration requires an explicit, almost a apologetic explanation! The idea of "configuration over convention" is so completely ingrained into the spirit of the company's products that a single instance of a design choice to the contrary requires a footnote. To the contrary, Ruby on Rails makes a number of choices for the developer which simplifies and streamlines the development process. However, in doing so, it sacrifices the ability to muck about easily with the internals; it's not nearly as easy to strip out, say, the Route handler or the HTTPHandler and swap in a custom one that befits your application's needs.

Who is right? The answer is, as with everything in the computer industry, it depends. Ruby on Rails' design choices will make life infinitely easier for, say, 80% of developers. However, Microsoft's offerings will definitely, without modification to the core framework, be customizable and thus useful to all developers on the spectrum. This is, of course, merely a side effect of how large Microsoft has become: it is impossible for the company to ignore any sector of its developer base, no matter how small. Meanwhile, Ruby on Rails (as well as Django and other platforms out there) is able to decide for its developers how development should be done, even if that means alienating a small sector of potential developers, or else forcing them to delve into the codebase of Rails itself.

This is the other 80/20 problem, and how it shapes the development process of various frameworks is both interesting and critical to both platform/framework developers and consumers.

So it seems that Network Solutions is stealing domain names that their customers search for, hold them hostage so that they may only buy from Network Solutions for 4 days, then pass them off to domain squatters/snipers, presumably for a nice premium. This is quite the deplorable and disgusting practice, which goes without saying.

However, I highly doubt that this problem is limited to Network Solutions; in finding a domain to host our projects, our first choice name was registered less than a day after we first considered it and checked for its availability. It was then offered back to use for 4000 euros. We never searched through Network Solutions.

This is a terrible practice that is allowed through a hole left by the ICANN as a benefit to registrars, and it needs to be stopped.

So, Weave. Essentially, Mozilla wants to create a persistent desktop and services platform for your browser across any computer you run into with Firefox. It's a good concept, and it works pretty well (as advertised) after you get past the buggy signup page and email server (I just gave it a few shots and on the fifth try the request went through). As far as I can tell from using it so far, it only really tracks your bookmarks and history thus far.

It will be interesting to see how the concept develops and evolves on its march to fruition, as Mozilla's exact intentions aren't exactly clear just yet.

The Internet is already the most pervasive and important persistent platform in existence. Anywhere you go, you can log into the same accounts on the same sites and services and - trifling details such as browser compatibility aside - be presented with the same experience as you would on your own machine. We all know this; this is why it's so popular, why Google's plethora of web-based applications, most notably GMail, are as popular as they are.

Mozilla appears to be unsatisfied with stopping there, and the basic concept behind Weave appears to be to extend this fundamental nature of web browsing up one level of meta to the browser itself. This, however, raises some interesting questions.

For instance, even in its current incarnation, Weave appears to displace at least one aspect of at least one major web service - del.icio.us. At least one reason of del.icio.us's fundamental utility is that it allows its users to persist their bookmarks across the web. There are many, many other reasons for del.icio.us's existence and popularity, but who's to say that as Mozilla's initiatives to push social browsing and persistence into Firefox via The Coop (speaking of which, whatever happened to The Coop?) and Weave, that del.icio.us won't slowly be forced out of the equation? Mozilla's well-being is based largely upon Firefox's, and Firefox's well-being is based entirely on the web. At what point does a browser cease to become a better browser and begin to impinge upon the sites and services whose job it is to render?

Of course, the above is just a question. There is no accusation, there is no prediction in that question. It's too early to tell what Mozilla's plans and direction for Weave is just yet. However, if we make the assumption that Mozilla will recognize such scenarios as being contrary to its interests and missions, all of a sudden Weave becomes a lot more meaningless, a hollow manifestation of its promise - after all, at the point that Weave is restricted to merely persisting the existing browser experience and functionality across multiple machines rather than extending that experience, we quickly find that Weave has already reached its full potential. After all, the only horizontal growth Weave could find in this regard is, as far as I can tell, to also provide each user's favorite extensions across machines, which would make it, and Firefox immediately and immensely improved. However, this feature is a technical and security nightmare, and not likely to see the light of day.

Thus, color me skeptical about Weave thus far. However, it's extremely early, and the Mozilla Foundation may yet surprise us all. Most of what I have presented are merely questions, and perhaps they will, or have already, answered them all.

I've been running 10.4.9 for a good long while now, refusing to install either the 10.4.10 or 10.4.11 updates that have rolled along in the past few months. Something just didn't seem... necessary about them. iWork, however, begs to differ with my delusions and in fact requires the .10 update in order to install, thus rendering the whole sordid affair altogether too unavoidably necessary. As it turns out, my hesitation to take the plunge wasn't without merits, though I had no rational explanations at the time.

Some of you may recall that I stubbornly stick to Shiira, an alternative web browser on OS X based on the same WebCore technology as Safari. Though it crashed every so often, and the bookmark experience left a bit to be desired (not to mention the overall grammar), I stuck to it because the core experience was nearly exactly how I wanted it to be, because without the rough edges, the promise of what the browser was supposed to be was worth it. However, Shiira 2 didn't really fix what was wrong with Shiira 1.2 and move on, instead introducing a slew of very questionable issues, including the lack of any sort of documented method of renaming bookmarks. The least that can be said for it is that it is stable. Thus, I've been sticking to Shiira 1.2 far past its support period.

Unbeknownst to me at the time, the .10 update in face comes pre-packaged with Safari 3, and thus a new version of WebKit. A radically new version. One Shiira has issues coping with. It's fine for the basic needs, but throw nearly any AJAX-laden Google app at it and it balks. Well, I thought, it's a bit late to go back now, so it's time to pack up my things and move onto some other browser, I suppose. A little sleuthing drops me onto Demeter, a branch of Shiira 1.2 that's still supported. Hey! Things are looking up. A download and a few package contents modifications to replace the icon with that of Shiira later, I find myself staring at essentially Shiira resurrected, with working support for the latest WebCore! Well, not quite.

Clicking on links in emails seems to raise Demeter's wrath, leaving it to deposit you on a blank page. Searches in Google Maps work smoothly with AutoComplete and all, right up to the point where you actually hit Search, at which point all hell breaks loose. Not to mention the small issue that it seems even more unstable than Shiira 1.2.

And so now I'm stuck without a solid browser for my OS X setup. Safari isn't flexible for my needs, Shiira 1.2 is no longer functional, Demeter only works most of the time, Shiira 2 is just a joke, and Firefox is too ludicrously slow on OS X to even consider (though Firefox 3.0 beta 2 makes small strides) and fails to respect OS X conventions (hitting the up arrow in a single-line edit should result in going to the beginning of the line, etc). I've become slowly accustomed in the past week to opening increasingly "safer" browsers each time I run into a compatibility issue on the web, and I found this morning to my utmost horror that I had every single browser mentioned in this paragraph opened with various pages without even realizing it.

I'm tempted to write my own browser just to solve this once and for all, but all the issues mentioned above make the whole ordeal seem strangely understandable.

Well, the preview SDK for Android is now out, as well as a slew of titillating screencasts describing the architecture and development process for the platform. I hadn't been really following the "gPhone" story apart from noting the fact that it apparently existed, so I took advantage of this opportunity to educate myself on the details of the beast.

And what a beast it is.

One of the things that I have always noted as being very impressive about OS X is a certain system-wide consistency and self-integration which Windows has failed to achieve, probably because the community is much more fractured. Beyond a highly consistent look and feel (ironically violated only by Apple's own efforts in Mail and iTunes), there is a smorgasbord of underlying services and platforms that unify the OS - Cocoa services allow for inter-application actions (I can spellcheck text from in Shiira, my browser, through the services of another application such as Word, for instance), Spotlight integrates with a slew of applications to provide system-wide searching, AppleScripts allow for quick and easy automation and extensibility of applications, and most recently in Leopard, Quick Look allows for a preview framework that greatly assists in locating and identifying files.

Sharp-eyed readers will note that every one of the unifying services I have just listed require a certain amount of active participation from application developers. Time must be put in to integrate support for each of these services. However, the point is that they exist, and the capability is there. Because they exist, and because it is therefore reasonably easy to do so, users expect this level of functionality and developers put in the effort to make it work.

Android was built from the ground up for application integration. I haven't messed around with the SDK yet, and I probably won't until next weekend (there are some updates to My College Apps that are waiting to be pushed out), but from the screencasts, the gist of the platform seems to be entirely based on an operating-system level of content and action management. Of course, if I turn out to be wrong, please do correct me.

Rather than having default applications for a small number of things like file formats, email, and web browsing, Android is built on the concept of Intents, which are far more granular. Every action you'd want to perform, such as viewing a map, an email, picking a photo, making a call, or even going to the home screen is performed through a system call on an Intent. Android then determines which application would be best suited to perform the requested Intent - a process that is user-configurable - and then executes that action, optionally returning data such as the selected photo. In this way everything built in Android maybe reused and replaced, right down to, as previously mentioned, the home screen.

Additionally, while applications can store data in their own formats, they can opt into Android's Content Manager service, which is apparently built on top of a SQLite engine they have integrated into the OS. In this way, content may be stored not only for the host application in question, but also made accessible for other applications to utilize, all with little to no additional effort - one prime example is Contact information, which could be useful to a whole slew of other applications.

A smaller, but very neat and appealing system-wide integration is the Notification Manager, which streamlines and standardizes the appearance of notification icons you often find along the top of phones. In android, all applications may display notification icons that the user may access at any point. When the icon is highlighted (tapped/selected once) it centers itself along the top and displays a little speech bubble indicating briefly what the notification is about, and should the user decide to act upon the notification, the application is then launched with information on what is going on.

Everything is built in Java, with the Java code being put through a custom compiler to leanify and meanify applications for a mobile environment, resulting in ".dex" files.

As a side note, I find it interesting that the entire Android appearance is highly evocative of the translucent smoke Apple has pushed in a few of its applications recently, not to mention that the screencast, while mentioning that Android's web browser is built off of WebKit, calls it the "standard these days."

Beyond whether all of this works as well as Google claims, my biggest question is how well Android takes care of the highly varying input and display methods on SmartPhones these days for the developer - it is a complex issue that in Windows Mobile requires the use of an extra framework on top of the .NET CF which makes the entire process extremely painful - just looking at the diagrams of abstraction required to draw a simple form with fields is enough to turn anyone off the idea. In one of the screencasts, the View Manager is described, and this issue is very briefly mentioned, with a note that Google has solved all these issues for the developer.

In summary, Google has created, in concept, an extremely interesting platform. The foremost goals appear to be open information sharing and platform self-integration, along with ease of development. Whether that concept is real, we shall soon find out. I'm off to download the SDK.

The Internet is an interesting place to be right now, either as a content consumer or as a content producer. Websites such as Daily Kos are quickly gaining steam and credibility (Daily Kos, for instance, is quoted almost nightly on Keith Olbermann's show these days), while being simultaneously lambasted by the traditional media for concerns of integrity -- some legitimate, some manufactured for obvious reasons.

However, these are age-old issues that have already been extensively explored by people far more versed and intelligent than I. Today I'd like to comment instead specifically on social news sites such as Digg.

Digg has had an interesting effect on the ecosystem of the Internet. Digg upends the traditional structure of the Internet, acting as a user-determined hub that sends traffic to the far-flung reaches of the web. To be featured on Digg means a blast of traffic, with hopefully some residual increase, and to be a Digger whose submissions are regularly featured on the front page is to have a certain amount of power. As both of these are desirable outcomes, those vying for such benefit find themselves now in a bit of a competition -- and all that comes with it.

The issue of note here is that everything that comes with competition. Digg in general is a cesspool of noise, unorganized chaos that only plays at coming together into a cohesive idea. A submission will float through the ether and be lost, while perhaps mere minutes later, a nearly identical candidate will be picked up and flung into the stratosphere. In today's world of short attention spans and busy denizens, every moment counts, and if anything fails to interest within a small handful of moments, it gets dropped for the next scrap in the heap; and it is thus, amidst this whirlwind of conditions, that we find ourselves in the thick of it.

Today's Digg, and -- dare I say it -- blogosphere is a giant collection of exaggerations. One after another, with everyone struggling to stand out against the noise, minor issues are magically and thoughtlessly transmogrified into grand proclamations of triumph and terrifying prophecies of impending doom.

My point is illustrated, and indeed was inspired by, the recent discovery of a "trojan" that targets Mac OS X. Headlines drifted by my Digg feed proclaiming doom and gloom for Cupertino's favorite operating system, with one article going so far as to declare that years of not patching security holes will now finally catch up to Apple.

From a purely technical standpoint, this entire ordeal is a pile of putrid stink. The so-called security flaw consists of a user downloading an executable package, supplying the adminstrative password, and finally finding their requests redirected to web-based advertisement portals. This is roughly equivalent to pointing out the horrid security hole in Unix whereupon a user is convinced into typing in rm -r *. And as a side note, this is not equal to most of the user-instigated security holes on Windows, as most of those involve carriers that are not executables.

Regardless, the issue at hand stands; how are we as a community to deal with attacks from all sides regarding our credibility when we ourselves, vying for a spot in our own limelight, fail to uphold any scrap of integrity or dignity? Perhaps I am the one that is overreacting here. Perhaps in today's atmosphere, words have lost their edge, their meaning dulled. Perhaps these hyperbolic articles flooding my screen are no longer an affront to a society of emotional capriciousness. All I know is that Digg and the social news conglomerate seem to be becoming less and less relevant.

So we launched our facebook app, My College Apps, about 15 hours ago. Since then we've accumulated some number of users, which is vaguely amusing to watch. I'm actually working right now on some sort of flash fireworks that can go off every time we have a new user. Essentially, the application allows users to list and track what colleges they are applying to, as well as discuss the schools in question. Wish us luck!

I can't explain any stage of this phenomenon:

1. Colbert announces his presidency, but only in his native South Carolina.
2. Someone makes a "1,000,000 strong from Stephen T Colbert" group to rival Barack Obama's group.
3. Group grows ridiculously fast. Ridiculously.
4. Group is growing at several members a second, passes Obama's group easily (1.5+ year lifespan vs 5ish day lifespan? Can anyone say cultural phenomenon?).
5. Group vanishes without a trace.

I'm sure this isn't censorship or anything sinister, but I'm also sure there was a better way facebook could have handled the server load. It was especially disappointing because I was just about to demonstrate the group's magically expanding ranks second-by-second when it vanished right underneath me.
Pity.

Here I was, minding my own business, and I need to shut my computer down. Vista decides to install 8 updates.

"Installing update 1 of 8..."

Okay, fine. That's not too bad, I've waited through 26 updates before. An hour later,

"Installing update 1 of 8..."

There's no way. I'm scared to power-cycle this thing, but there's no HD activity, there's no way it's still working... let's see what will happen.
Now I have a half-bricked computer. Aren't updates supposed to fix my computer?

Step in the right direction. Microsoft has revealed that they're finally, with .NET 3.5, going to release parts of the .NET framework code. Eventually, all of the code will be released, including the new (and pretty exciting, if it makes good on its promises), LINQ DB access technology. I won't make any comments about open-source software, because Microsoft's stance is very clear on that subject, and this is clearly irrelevant to that discussion.

What this issue is relevant to, however, is the lives of .NET developers. Currently, Lutz Roeder's excellent .NET Reflector - essentially a decompiler from CLR code to code that makes sense to developers for any and all .NET classes - is the only recourse for getting any sense of how .NET is working under the covers. Extending .NET's default classes would be impossible without this invaluable tool, given that the convoluted order in which .NET's library classes call their internal methods aren't particularly well documented. However, .NET Reflector can only do so much to alleviate the problem given its fundamental nature as a decompiler; the code it extracts is often riddled with oddities, including but not limited to numerous labels and goto statements (!).

A far more fundamental problem lies within the process of debugging. Stepping into any .NET code will drop you into either assembly or bytecode, depending on how Visual Studio is feeling on that particular day, which is a complete waste of time and often precludes any sort of productive debugging getting done.

Having the actual and whole source code to the .NET libraries alleviates both of these problems, instantly.

I'm glad that Microsoft, at least on one front, has come to its senses on its secrecy. It will make the lives of countless developers far, far easier.

There are an incredibly disproportionate number of people here at the UW that are using Macs, something we discovered last year. With that influx of new Mac users comes a complementary number of amusing mishaps, missteps, and generally just mistakes going on. So, to amend a general lack of content coming to my mind to blog about, here is a beginner's guide to boosting your OS X familiarity and productivity off the bat.

First! Installing applications. In general, the process for installing OS X applications is as follows. You'll most likely get a file in the format of a DMG. Think of this as someone emailing you a virtual CD. You can put the CD in your computer (mounting it), or remove it, but you won't be able to edit it, and you most likely don't want to run everything off a CD. Generally, you'll find a .app file in the DMG. You'll want to first drag that to your Applications folder, then run it from your Applications folder. There are two exceptions; if the .app says "Installer" in it, or if instead of a .app you find a .pkg, you'll want to run them straight off.

You'll probably need to know some Finder-fu if you want to efficiently copy files such as those .apps. The best view in finder by far is column view. That's the one to the far right. In this one, as you delve deeper into folders, you'll progress to the right. If you want to go back up, just go left. Also, if you select a file, you get a nifty preview pane with information in it. To couple this, the best way to manage the copying of files is to just open two Finder windows and navigate to the two paths in question straight off the bat. Cmd+N opens new Finder windows. If you click on the desktop, the Finder application comes into focus, so you can at any point simply click on your desktop, then hit Cmd+N to get a new window or two.

However, if your desktop is buried, your friend is F11. Arguably more useful than F9 (Exposé), this critter will instantly sweep your windows aside temporarily and give you instant access to the desktop. Nifty.

When you're presented with a dialog (especially Yes/No or Save dialogs), you'll often see a solid blue button and a glowing blue button. To select the solid one, hit Enter. To select the glowing one, hit Spacebar. Usually on save dialog this corresponds to Space->Don't Save, Enter->Save. Also, if there is a small dark circle in your close button, it means you have unsaved changes.

This one is very simple. Use Cmd+Q to quit your applications! They won't close if you just hit the red button. You'll see over time why this is, but while it makes perfect sense after you do, it's hard for Windows users to grok at first. While we're at it, other keyboard shortcuts that are standard across all OS X apps are:

• Cmd+W: Close window (but not application
• Cmd+T: If an application has tabs, new tab. Otherwise, gives you the font changer window
• Cmd+F: Find
• Cmd+left or Cmd+right: Generally left tab or right tab... Sometimes Shift is required
• Cmd+Tab: Switch applications, much like Alt+Tab in Windows
• Cmd+~: Exactly like Cmd+Tab, but only between windows within the application.

In addition, there are many nifty Option+ shortcuts that produce special characters. Try Option+Shift+K. Or try Option+E, then hit any vowel.

Are you on a MacBook or MacBook Pro? If so, do me a favor. Right now, put down two fingers instead of one. Now move your hand up and down. It's a crying shame how many people don't know this. In addition, if you go to System Preferences (Apple Menu) and go to the mouse category, you can select "Place two fingers on trackpad and click for secondary click" so that you can right click simply by placing two fingers on the trackpad and clicking, rather than using Control+Click.

Get Quicksilver. Yes, not having Quicksilver is just as egregious an error as any of the above. Quicksilver is the single most amazing and useful application you will ever find on OS X, bar none. You can simplify literally hundreds of tasks with Quicksilver, among which are launching applications, extending applications with keyboard shortcuts, instantly open a directory in terminal, instantly open a file with an application, all the way up to selecting multiple files and emailing them without even touching Mail. I'll elaborate on this in my next post.

So now there's an eerie white blank where there used to be an erlenmeyer flask of green bubbly on the Google Reader logo, indicating that now that they've finally rolled out search and made sure that it's stable, Google's ready to move Reader out of beta, and has done so. Truly amazing given that GMail still claims to be in beta... come on, Google, that ship sailed long ago.

Google Reader itself, though, is a great example of how flexible app development in Web 2.0 is. I first tested the Google Reader waters long ago when it was still in its infancy. I didn't like it one bit, but by the time I came back to it this February or so, it was a completely changed product, which has become indispensible to my daily routine. Welcome to agile development.

The sound of silence echoing off the streets is due to a number of projects in both my work and hobby arenas that have been chewing away at my time, as well as a general lack of discussion topics. Nonetheless, without any further ado, today's post.

I might be a bit late to this bandwagon, and this might be a blast from the past for some of you, but I thought I'd post my impressions on Ruby on Rails after having used it for a week and a half now. Forthcoming as well are my impressions on working with the Facebook platform.

I've mentioned to several people that I've started developing with Rails, and the general reaction seems to be uniformly "Oh, Rails? I've heard a lot about it, how is it?" Note the complete lack of specificity - no one knows exactly what is great about it, only that it is buzzworthy. Having now used it for a week, and having developed extensively with ASP/ASP.NET and hacked PHP sites for ages now, I think I have a fairly decent impression on its strengths and weaknesses, as well as how it stacks up with the competition.

First, let's get Rails' biggest benefits over with. These are two in number as far as I'm concerned, the first of which is that ActiveRecord rocks. ActiveRecord is easy to describe yet hard to quantify; it has an entire subdomain of its own over at the Rails website, and for good reason - the point of ActiveRecord is to embody the DRY (Don't Repeat Yourself) principle in the data layer of the application. A normal web application will feature several layers of architecture, starting with the DB layer (the actual storage itself), then the Data Access layer (the factory classes that grab data), then the Business Logic layer (the classes that represent the database classes field-for-field, and methods for getting to and from the Data Access layer). This process involves multiple repetitions of the same information, especially that of the fields each object is associated with. ActiveRecord quite simply collapses this entire model into the database - you create a database table, and through their naming guidelines, declare a class that the database backs. That's it. You can also specify validation, relationships, and other metadata in the class, but there is no need to redeclare the fields, or create any access methods. Since the data classes inherit from ActiveRecord, nearly anything you'd ever want to do is baked in. On a related note, Migrations are a neat idea: they are essentially versioning Ruby scripts that up- or down- grade your database schema as you change it. The benefit is that if data itself needs to be migrated, you're already in ruby script, and that sort of thing is baked in.

The second huge benefit of Rails is that it follows MVC patterns to the letter. Because of this, the naming of your pages (called actions), backing code, and helper methods all fall right into line without any fuss. It's a small feature, but it simplifies the process greatly, and there aren't too many cases where you'll want to break out of it.

Rails in general tries to be automagical - things are taken care of for you. The best example I can think of is that the addition of an AJAX-ified autocomplete box takes one line of code in the controller backing code, and one line of markup, which simply prints the box. This general air of niftiness pervades through a majority of Rails' features. However, Rails won't do anything for you unless you know the magic word to ask for. It's very particular about exactly how everything should be given to it, and if it doesn't like what it sees, it balks. This can lead to long, frustrating sessions of debugging, ending in (true story) "can it really be that simple...?" moments of realization.

Thus we get to the final bit of my impressions: how it stacks up with the competition. Rails is more or less on the extreme end of the spectrum from PHP - whereas in PHP, you lovingly craft everything you need from hand (or download someone else's code), Rails tries to abstract it away for you. ASP.NET lies in the fuzzy middle - it tries to make web development follow a more desktop paradigm, which is both neat and confusing at the same time, and therefore in doing so it also abstracts many things away for you. However, ASP.NET has a very different philosophy as to how it should treat these abstractions - it allows, sometimes even forces the developer to customize every last aspect of it through various means, and therefore it becomes complex, cluttered, and bloated very quickly in many real-life scenarios. Rails, on the other hand, lays down the law of development and how you need to be doing it. Which one is better? That comes down to your own development preferences.

So far, for all the time I've wasted trying to figure out Rails' quirks, I firmly believe that the time I saved from having to write database access code has more than made up for it.

If only switching servers was as easy as saying an incantation, a la Harry Potter. However, it was reasonably seamless, even if behind the scenes I dropped about 2.5 hours on transferring everything over and getting it all to work. Either way, I'm on another DreamHost server now, and I should have a little more breathing room to get development done.

Oh, and can anyone say "iPod Touch?" Yum. Tell me when it hits 50GB.

ASP.NET is wonderful and awful. Some of the conveniences it affords are great, like the control paradigm. However, it's just too convoluted to offer a good experience. Everything in ASP.NET is "yes, you can do this, but..." and nested databinding and event handling is a mess. I've often wondered why such random WTFs such as using empty iframes to provide menu backgrounds arose, but today we find out why. In an obscure error message hidden in the bowels of the Wizard control:

SideBarList control must contain an IButtonControl with ID SideBarButton in every item template, this maybe include ItemTemplate, EditItemTemplate, SelectedItemTemplate or AlternatingItemTemplate if they exist.

Classic Chinese-American grammatical error. So I guess it turns out that Microsoft outsourced ASP.NET to China...

Facebook appears to be on an email backlog and is sending out everyone's email notifications in reverse chronological order. I'm personally now up to about a week ago, and they're still coming in.
I know bulk emailing is tricky, Facebook (having been working on a project involving such a thing), but I had no idea that first-in-last-out was the best way to send these things...

It's no secret that Microsoft's relatively new Silverlight is intended as a competitor to Macromedia's (now Adobe) long-time rich-web media stalwart Flash. Having been a Flash developer for a very long time, I recently wrote a smallish Silverlight application for a project we're working on for work, and I have a number of things to say about the experience relative to that of developing webapps with Flash.

Overall, the most glaring, obvious, and often painful differences lie in the obvious question of maturity. Silverlight's API is constantly shifting, and the documentation is little to no help at this point. Little things, and sometimes huge issues, haven't been totally thought through just yet (though given Microsoft's track record it's in question if they ever will be), and flux is always frustrating to deal with. However, some of the issues are more inherent to the platform itself, laying mostly in the nature of its development and its integration with browsers and with code. Here's a more detailed breakout.

Silverlight is very young. It's not even out of beta. Therefore, it should be expected that the API and XML schema will shift here and there. That's little comfort to the developer, however. The latest preview edition of Microsoft's Expression Blend 2, the official application for developing in Silverlight, provides almost no correlation between the WYSIWYG/graphical options it provides for interface development, and what the Silverlight schema actually represents. Triggers appear to be unsupported, though Silverlight supports them, and there is no way to add events to objects. There are countless other discrepancies between Blend and reality, many of them too grave to even think about. Therefore, designers and developers alike are stuck editing XAML markup, which isn't the most delightful task. "Fine," thinks the average developer, myself included, "if I can't use Expression Blend I might as well just edit in Visual Studio and avoid the shortcomings and annoyances of Blend's XAML editor." That's a bad notion -- Visual Studio doesn't as of yet recognize the Silverlight schema and as such will live-compile everything as errors. You'll get a productivity rate of about one word per minute. To add insult to injury, the MSDN documentation is very poorly written; I'm pretty sure they took the full Avalon XAML documentation, and appended all the caveats, issues, exclusions, and other miscellenia to the end of each page. It makes for poor reading. This issue, though, brings us to the next topic of discussion:

Silverlight is mini-WPF. This is both a strength and a weakness. XAML is a reasonably well structured language which accomplishes its goals fairly well. I don't have too much of a problem with it. It also eases the transition for any developers who are already developing for WPF (which, as far as I know, is an extremely scant few) into developing Silverlight. However, in order to make WPF web-friendly, a lot of things were cut. Some things that don't even seem to be very heavy were cut. Complaints about lack of support run the gamut from simple things like animating clipping areas, to even simply having geometry as clipping area, rather than what are effectively polylines. However, larger than this is a more serious problem, which is that...

WPF (and therefore Silverlight) just wasn't built for the web. wPF is a desktop creature. There are a whole slew of things to consider when developing for the web, the largest of which is bandwidth. Flash may not have a built-in preload manager, but at least it provides the mechanisms with which, with minimal knowledge and 2-3 lines of code, you can build one. Silverlight provides virtually none of these things. The only way to preload things is to use the Loader object, which works asynchronously, requires a separate instance for each element to be downloaded, and requires extensive knowledge and coding to get to work. This becomes a serious issue, especially because images are essentially just standard html images. Blend may claim that you can apply effects and animations regarding skewing and transparency, but it's just wrong. This leads me to my final conclusion on flash's advantages (outside of simple maturity and installed base):

Flash's main advantage is that it is a single, self-integrated package that is both developer and designer friendly. It was built from the beginning for the web, it has a solid IDE that works for both designers and developers (unlike Silverlight's Blend vs Visual Studio model), and requires jumping through less hoops (there is no markup to edit by hand). Everything from the development experience down to the consumer experience is provided in one simple, neat package. Silverlight's deployment requires four or five javascript files (why aren't these part of the plugin itself?), along with any collateral content, such as images, to be deployed as individual pieces. Flash also allows far more flexibility from a design perspective, as Blend isn't particularly any good at drawing any shapes outside of elementary geometric elements.

In a final stroke of irony, Flash trumps Silverlight at one of the elements WPF was greatest boasted for: developer/designer integration and separation. Silverlight requires events to be wired up in XAML (which right now is even greater a task given Blend's complete inability to do so for you), and thus there is programming being done in XAML. Flash, conversely, allows for developers to wire up events without touching anything design-side.

Overall, Silverlight is a decent platform. Once it matures, we'll get a better sense of its capabilities and pitfalls. Right now, however, it simply has too many of the latter for me to be greatly interested in developing extensively for it.