There's lots and lots of talk all over the blogosphere regarding the potential acquisition of Yahoo by Microsoft. There are quite a few spouting how terrible it will be if this happens. People seem to think that 'evil' Microsoft monopoly will get ahold of some percentage of the internet and ruin it. That's a knee-jerk reaction, in my opinion. Not everyone is reacting that way, techcrunch has an interesting post on it up.

First of all, when it comes to a monopoly on the internet, only one company has it and is actively going after it. Google. Now, I use Google and love a lot of their services, but they are actively seeking a monopoly on parsing and analyzing all information that flows through the internet. Their various services extend across the internet and make website after website dependent on their infrastructure (much like computer after computer became dependent on windows).

They seek this through everything from their advertisement model to email. They seek it too in their 'open' APIs, which essentially tie everyone, in the end, to their servers. Is this a bad thing? Not necessarily. It depends on what they do with the dependency so many have and will have on their infrastructure. It depends on if they truly won't be 'evil'.

In regards to Yahoo, while Google has the billion dollar algorithms, I think they have always been better at user interface. I much prefer Yahoo mail over Google, for example. So, combining Yahoo's web know-how with Microsoft's financial and marketing juggernaut could push Google towards bettering some of their weaknesses (like customer support and marketing their products). Yahoo's brand makes Microsoft friendlier. Microsoft's brand makes more Yahoo dangerous to competitors (read: Google).

I think Google's response to a Microsoft/Yahoo merger (read: acquisition) would be to buy some giant marketing firm, some giant customer support company, update the user interfaces on their products and start going to town. That would be very interesting. They might even have to start bringing some of their products out of beta.

The new Iron Man TV Spot (which showed during the Super Bowl - which was, by the way, one of the best games I've ever seen) is available online. I'm starting to get excited.

Find it here: http://www.apple.com/trailers/paramount/ironman/

For those of you ASP.NET developers who haven't tried (or, somehow, haven't heard of) Elmah as a solution for error logging: version 2, which has been around since last year, is still great.

Implemented as an HTTP Handler, it provides a clean way to log and review any unhandled errors thrown by your ASP.NET application. I prefer the SQL Server storage method (a single table and some stored procedures), but XML is an option. Run the script in your database, add some entries to the web.config file, drop the DLL in your bin directory, and you're good to go. The handler provides access to an error review page, which shows the detailed error information, as if you had been running the application and the error was thrown in front of you (i.e. it mimics the standard ASP.NET detailed error page).

It even provides an RSS feed to the error log. Highly useful! Again, if you haven't tried it, I highly recommend it. It's easy and quick to setup, and may save you a ton of headache in the future. You can find the binaries and the source code here: http://code.google.com/p/elmah/

The upcoming Star Trek prequel, directed by JJ Abrams, has its official trailer out. You can check it out here:

http://www.paramount.com/startrek/

There is also a viral site out where you can checkout the Enterprise (the original) being constructed. Check that out here.

The movie will chronicle an adventure involving a young Captain Kirk and Mr. Spock. Apparently some time travel or some such will be involved as Leonard Nimoy is involved in the project as well. (Sorry Shatner, but you already got your own movie with 'Generations'!)

Here's hoping this movie can reboot a much missed franchise.

Remember point and click adventure games? I have always been a fan of some of the greats (like the Myst series, etc.) Not long ago telltalegames reintroduced the world to a classic duo that starred in some of the most beloved adventure games ever: Sam and Max. They have been for a while releasing games in episodic format (once a month upon starting a new 'season') and season two's second episode is out.

Titled 'Moai Better Blues' its fun, but what's more its funny. Very funny. You can get through the game without getting all of Max's (a furry white lunatic of a bunny) comments, but you'd be missing a lot. Clicking around to hear what the title characters are going to say is half the fun.

The game is your usual adventure game formula of 'get inventory items, use inventory items', but not in an overly obtuse way. Object usage makes sense, even if the world the game inhabits is utterly looney.

All the games are available for download from the developers website, or through GameTap if you're a subscriber. I highly recommend buying both seasons one and two. The individual games are short (between 3 to 6 hours I'd say on average depending on how well you do, or if you use a walkthrough), but they're not expensive and of very high quality in regards to puzzles, dialouge and acting.

Check out the site to download: TellTaleGames

John Stewart and The Daily Show (retitled during the strike as A Daily Show) have been back for a few days despite the writer's strike. If anyone doubted, Jon is a funny guy. There haven't been as many large scale skits, but Jon's usual funny-because-it's-true commentary hasn't changed a bit.

Episodes have been available online for some time, so you can watch last night's show on your lunch break at work the next day (of course, you wouldn't watch it during work, would you?)

Here's a link: The Daily Show

To The Making of Books...
"To the making of many books there is no end, and much devotion to them is wearisome to the flesh." - Ecclesiastes 3:12

If one could chop down books and make them into trees, one could imagine the destruction of all technologically related books allowing the restoration of a decent percentage of the South American rainforests. There are hundreds of books on every technology one can think of, with more coming out every day. Finding the right set of materials to read is a chore, truly "wearisome to the flesh." How does the developer choose the right book? There is one deadly assumption that many make when choosing their self-education material: the more example code the better. Developers who make this assumption will find themselves inside an insidious layer of abstraction that is not obvious upon first glance.

The Example Taxi
Example code is a wonderful thing. Developers are often faced with problems which have already been solved by someone else. A quick search on the internet reveals that slice of code which saves him or her a great deal of time. This is useful. However there is a difference between example code for specific needs, and the attempt to teach concepts or development methodology through coding examples. Understanding the difference is imperative to good self-education.

Let's illustrate why learning by example code is an insufficient method of self-education:

Imagine a man gets a job as a taxi cab driver in New York City. This is a job which requires a demanding amount of self-education. One needs to know how to travel from any point A to any point B that the passenger requests. Now we introduce the 'example taxi.' Let us suppose that, rather than studying maps of New York, a second, more experienced taxi cab driver is utilized whom the new driver follows. Whatever the passenger requests the example taxi is notified of. The new driver simply follows the example taxi to the desired destination.

Has our new driver successfully carried out his duty? On the surface, the answer is yes. What's more, if that driver needs to travel from that exact same point A to point B again, he may remember how to do so. However, does the driver truly understand how to travel through the city of New York? Clearly not. He knows only one particular route (someone else's favorite route, at that) to his destination. However, that is almost never the only path, and it may not be the best under all circumstances. What is a better route during the busier times of day? What if there is construction? Without understanding all the possibilities, and without getting the 'big picture' of New York, our driver will soon discover the inflexibility and lack of self-sufficiency in his education.

The fatal flaws in our driver's education are the same flaws in the education of a developer through example code. Someone else's code is merely one route to solving a problem or implementing an idea. However, it is never the only route, and not always the best one. Simply parroting another's code without understanding it, nor understanding the alternatives, is like following the example taxi. One arrives at their destination, yes, but one will soon hit roadblocks (such as requirements and assumptions different from those of the example code). Once hit, those roadblocks will bring into focus the inflexibility and lack of self-sufficiency in their education.

A lack of self-sufficiency is manifested all the time, for example, in newsgroups and forums on the internet. Developers leave messages asking for 'the code to' do some task. One message seen was a new developer asking for 'the code to' build an address book. The fundamental lack of development of problem solving skills is staggering in a request like this. There are hundreds of ways to approach an application like an address book. There are dozens of possible pieces of functionality, each with varied ways of implementing them. It is also easy to design the application very, very poorly! This newsgroup poster will soon find himself with a library of code, and the headache of having no real idea what to do with it.

When it comes to self-education, avoid the example taxi. Choose reading material that teaches you concepts and core units of knowledge that promote understanding. Then use example code for ideas and inspiration, not for an education. How can one recognize proper reading material? We separate the developer's reading material into two categories: "how I code" books, and "how it works" books.

"How I Code" Books
"How I code" books are very easy to recognize. They are clogged with example code and example scenerios. Normally a scenerio is presented, and the developer steps piece by piece through the code they would write to implement a solution. At the end, they may then show all of the code together so the reader can happily copy it in order. This is rather like sitting and looking over another developer's shoulder while they code. You may learn something, yes, but what you learn isn't how to code.

In books like these, you are learning one developer's approach to designing a piece of software, which is fine if you are able to call the author on the phone and ask for the code to implement every problem you come across. If you can't do that, well, then there was little point to your exercise. One taxi following another around is not learning a city. Watching a painter paint, is not learning to paint for yourself. Looking at the database someone designed to support an address book application is not learning normalization and relational database design. One is an exercise in implementing a concept, the other is a concept itself. Without the latter, the former is nearly useless.

"How It Works" Books
"How it works" books are harder to find, but are very much worth the effort. They explain concepts, and use brief scenerios (and usually even briefer snippets of code) to demonstrate, not to educate. Look for books that detail how a technology was implemented, not solely how to use it.

A good example of this are the various books available for teaching ASP.NET. The ultimate purpose of this technology, like JSP or PHP, is to deliver HTML to the user. The framework allows for quite a wide array of tasks to be accomplished behind the scenes, but the medium of final delivery is still the same. There are mountains of "how I code" books on ASP.NET, detailing how to build various kinds of websites (image management systems, time tracking systems, shopping carts, etc.) For the new developer, the example based route can be quite tempting.

On the other hand, there are good ASP.NET and .NET framework books out there that explain how ASP.NET works. How does this technology move from the abstract concepts the developer uses to implement their solution to the HTML delivered to the user? If one understands the core architecture, one will not need so much example code to solve whatever scenerio is presented to them!

These kind of books promote understanding. Once you understand, you can do anything. Thus, be wary of "how I code" books! They can be useful, but one should first have a core understanding of whatever technology it is discussing. You don't want to learn how someone else codes. You want to learn to code for yourself. Only then will you progress as a developer.

Below is a proposed idea I wrote in response to my frustration with the stateless nature of the web (which it was intended to be) attempting to now become a stateful, application-friendly environment.

Statefulness and State Transitions through Transitional Markup Language

Abstract
Web applications have progressed significantly over the years. Once limited to simple scripting, technologies have now evolved to give web-based applications near desktop application-like power. Yet, in the midst of these advances one aspect of web applications has plagued the industry. The interface. The layout definition methodology (HTML) and the medium of delivery (the internet browser) were not originally intended to deliver the kind of rich interactive applications web users now desire.

Methodologies have been implemented to attempt to remedy some of the interface dilemmas web application developers face. Cascading Style Sheets (CSS) were introduced as a standard to attempt to separate layout from HTML, giving greater and more streamlined control over visual appearance. Javascript, a "client-side" (or "browser-side") programming language was introduced, intended to try to mimic desktop application delivery through in-browser code.

The latest efforts are to use one of Javascript's abilities (the ability to generate an HTTP post in code on the browser) to effectively request new page content without actually "refreshing" the page (i.e. forcing the browser to make the request the standard way). This methodology, called "asynchronous postback", is the core of AJAX (a general term describing the attempt to make "refresh free" web applications) which is one route developers are taking to attempt to make web applications more like desktop applications.

These ideas however, while admirable and quite powerful, are workarounds which do not face the real issue. The issue is that the core technology, that is to say HTML and the internet browser, are being used in a way that they were never intended to be. For web applications to every truly become as rich and user-friendly as desktop applications, it is that issue that must be addressed.

Another issue in regards to current web applications is the difficulty of making said applications accessible to all users. The goals of interaction and clear response are not easy to implement when taking into consideration those users with disabilities. A more generalized approach is needed to building interactive pages that, while still allow for competition through varied interface options, generalize these interfaces for interpretative clarity.

For these reasons, we introduce two new core concepts designed to rectify the inherent weaknesses of HTML and the current internet browsers. The first is a new XML-based structure which we call Transitional Markup Language (or TML). The second is the TML stateful browser. We will loosely define both in this document, and expound on ideas for implementation.


The Weaknesses of HTML and Internet Browsers
The Hypertext Transfer Protocol, the Hypertext Markup Language and the HTML browser were brilliant concepts. The World Wide Web which they have brought about has changed the world as we know it. The Hypertext Transfer Protocol is an excellent and simple medium for data exchange, and we do not propose to changing it. Yet, there are inherent weaknesses in the HTML / HTML browser paradigm in regards to constructing powerful web applications.

Weakness #1: Statelessness:
HTTP and the HTML browser are inherently stateless constructs. There only intention was to receive data requests, and return data responses. There is no concept of state across multiple requests and responses. All statefulness implemented in any web application framework is shoehorned into the HTTP request and response structure. Rich software applications require statefulness. Thus statefulness should be an inherent part of the construct.

Weakness #2: Large and Visible Transitions:
The internet browser builds HTTP requests and outputs the response. Current browsers, therefore, rebuild an entire request and then return the entire response during each transaction. This causes, in many cases, more information than necessary being sent across the wire. These requests are also "visible" to the user. That is, the user is often presented with a white screen while the request and response transaction is being carried out.

Thus, any approach to solve these weaknesses must enforce statefulness between requests and responses, and small, invisible transitions between said requests and responses.


Goals of TML
The goals of TML are as follows:

1) Stateful Construct: To define a markup language and server structure which is inherently supports statefulness across requests.

2) Markup Generality: To define a structure which generalizes types of content, thus enhancing search and delivery efficiency, while using various attributes to specify said generalizations.

3) Low Bandwidth Usage: To define a structure which inherently uses smaller amounts of bandwidth by minimizing the amount of information being transferred.

4) High Accessibility: To define a structure which eases and promotes higher accuracy of interpretation, thus enabling software to more easily and accurately represent a webpage to all users, no matter what the interface needs require.


Transitional Markup Language (TML)
Transitional Markup Language is an XML-based language designed to be interpreted by an HTML browser and by an HTTP server with the goal of delivering rich content via the Internet. TML defines a methodology to allow browser and server communication to be stateful and minimize the size of transitions from request to response.

A) The Root
Each TML document would define a TML page. The common structure of a TML page would appear as follows:

The root tag of a TML document is the PAGE tag. Each page may have one title, many META tags (such as to describe keywords, a description, etc.), and many STYLESHEET tags (to define external stylesheets). The core of the TML page, however, is what is contained in the STATEBAG section.


B) The Statebag
The STATEBAG is a collection of regions, defined by the REGION tag. The statebag is identified by a guid which is to be provided by the server upon first request, and will be delivered back to the server on each subsequent request. The browser would persist this state bag guid ID through all requests as long as the user remained inside the same internet domain name.

B1) The Region
All rendered elements of a TML page are defined within a region. A region is specified by an ID unique to the page, and a type. A region may be of a type bucket, text, button, image, textbox, dropdownlist, multiselectlist, radiobutton, checkbox, or video. Within the region will be defined an INTERFACE, CLASS, and CONTENT. A region of type bucket would have no interface, or content. It is merely designed to identify multiple regions as being related:

A region may also contain one or more EVENT tags.

B1a) The Interface
The interface is a method of defining the interface to a particular type.

For example, a region of type text may have an interface of hypertext (which may contain hyperlinks, carriage returns, paragraphs, span tags, and anchors), PDF, or RTF.

A region of type button may have an interface of button, or image.

A region of type image may have an interface of type JPG, GIF, PNG, or BMP.

A region of type video may have an interface of type Quicktime, RealPlayer, WindowsMedia, or Flash.

Form type regions (textbox, dropdownlist, multiselectlist) have no interface.

Thus the placement of an image would appear as follows:

The list of valid interfaces for all types may be extended by plugins installed into the browser.

B1b) The Class
One goal of TML is to have no aspect of its structure define the layout of the page. All layout would be done through current or future Cascading Stylesheet (CSS) specifications. The CLASS section would either be the name of the CSS class defined in an external stylesheet, or inline CSS.

B1c) Content
The CONTENT section contains either text (in the case of a region of type text, or of type button if the b