Different platforms are developed by different groups, each with their own mindsets and ways of doing things. If you take the time to step outside your own world, you might be able to learn new ways of doing stuff you never would have if you stuck to the familiar toolsets of your current platform. Take PHP and ASP, for example. Although very similar in nature, much of the “nitty gritty” implementation details are considerably different.

It’s actually in a developer’s best interests to know the best of both worlds. The Internet is heavily intertwined, with many companies seeking out cloud hosting solutions while integrating more than one vendor’s product. Besides, whether you like it or not, Microsoft maintains a huge presence in the computing world, and they aren’t going anywhere anytime soon. Plus with today’s mergers and acquisitions, many companies are no longer homogeneous with their technologies even if they originally started out that way. Knowing more than one technology would put you in a good career position for interfacing and merging new in-house technologies.

In today’s lackluster economy, what’s more important to you anyway: platform snobbery or job security? Let’s say you’re working in a code shop that’s totally dependent upon some open source LAMP flavor. But one day that place, like many dot coms of recent past, goes belly-up. It sure would be nice to be able to immediately jump ship to another place dependent mostly on ASP.NET, wouldn’t it?

So break out of the mold. Stop thinking whatever IDE you’re using is the best thing since pre-sliced bagels. Besides, “real” programmers don’t cling do their toolset. Real programmers don’t brag about how good they are at using “x” text editor or “y” compiler. Real programmers aren’t clueless like the recruiters who land them their jobs, mindlessly performing keyword scanning for the latest technology buzzwords. Real programmers are supposed to know how to determine/evaluate requirements, design systems, and write the code necessary for the task at hand, finding the right tools for the job instead of turning every problem into a nail for their only hammer.

Disclaimer: This is a sponsored post not written by the blogger.

Please leave your thoughts on this, and whether you found it an interesting read in the comments. I wanted to publish this one to see how it works out. Depending on your comments I may or may not run more sponsored articles.

Well, it turns out to be a perfectly feasible task, and I have a working prototype too!

The idea and the implementation

The idea was to look at Microsoft Excel COM interop with ASP.NET – I had seen examples of generating spreadsheets using interop, but it seemed no one had actually done anything more.

Since I haven’t really done any ASP.NET stuff from the ground up, and it was mostly cobbled together to just see if it could be done, so it involved software development methodologies such as “Copy and Paste”.

There was initially a problem with talking to Excel, as the Windows version I’m using is in Finnish, and my Office 2007 is the English version. Every time I tried doing something to the spreadsheet, such as getting a value from a cell, it would throw an exception. Luckily some Googling gave me an answer to change the currently executing thread’s locale to en-US, which fixed it and let me continue.

Eventually I found ways to do all I needed: Getting and setting specific cells’ values and their formulas. Then it was on to creating a JavaScript-based interface for it, which is essentially a very bare-bones inline editable table, which sends the modifications to the server with Ajax.

A demonstration

I sadly do not have a server which can run ASP.NET, and it is not actually a very good idea to run it on a live server for real users either due to things I’ll tell you about in a bit… however, here’s a screencast I made of it, which should give you an idea:

From the screencast, you can see how it first loads the Excel spreadsheet’s current data into the grid, and then when edits are made, any changes that happen to the values in the spreadsheet are reflected in the grid as well.

So is this a Google Spreadsheets killer?

Well… Maybe.

As you can see from the above, it is a feasible concept. However, it has several issues, because Excel is not a “server” type of application.

Excel is built as something that the user interacts with directly, as in a desktop application. If you typed a formula wrong, it would show you a popup and you’d close it and things like that.

If you type a formula wrong in the JS grid, it will go to Excel, which will display a popup… but it will have no one to close it. It will effectively stop the whole app with the pop: It will not reply to messages until the popup is closed, and any actions done before that will throw an exception.

In theory you could set up the server so, that it runs an application which would automatically click any popups Excel shows to close them… but I’m not sure if that would work out so well.

Finally, if you want to play with the code, the code for Webxcel is available in my SVN. To run the code you’ll probably need Visual Studio 2005 Web Developer and Excel 2007. Run an instance of Excel first, and then access the webpage.