With more web applications implementing desktop-like features, one can look forward to complex business software, that would typically be written for an operating system, being written as an internal web application within an organization. Incidentally, EJChart (http://www.ejschart.com/index.php), developed by Emprise Corporation, struck my attention.

On the frontpage, you can see a demo of the statistical capabilities this neat little web application has. If you select a region of data by dragging over the graph, it’ll zoom in on the selected range and project the data.

After looking through their forums, apparently it can actually take in a large datasource containing 12,000 data points (Man, that’s a lot of data). I suppose once you go over that 12,000 data point threshold, your browser will start puking because of insufficient memory. On a good note, imagine the sweet financial statistics and reports you could generate with this technology!

So, why use web applications instead of desktop applications? This is a funny question because I believe everything should be in a web browser ;).

Let’s face it, companies that develop HRM and/or inventory tracking software in C++, Java, or any other language to develop desktop applications will overcharge you. The development costs to produce a desktop application are overbloated because you need dedicated testing teams on different operating systems and dedicated source management teams that will ensure the code is up-to-date and that functionality hasn’t somehow leaked into another company’s version of HRM software.

Here are a few situations where desktop applications fail and web applications become a far more efficient solution:

1) Installations are time consuming– Installing the software on every single computer that needs it takes up your whole day. What if the installation fails? You have to do it again–more time wasted. If it was a web application, a user would only need to go to a specified URL to access the internal web application. Efficiency.

2) We use a different database platform — Let’s say your company already has a MySQL database with all employee data and more. Your company needs an inventory system to track every item you’re selling on eBay. You’ll look around and you’ll find a “promising” product–it’s a desktop application and it uses Oracle as a database to store the inventory. If you buy this software, not only will you have to install a new database system (Oracle), but you’ll also have to pay $50,000/year to Oracle for each processor your server has. Now, let’s do the calculations–you have 1 server running your company database. The server has 2 processors. 2 cores * 1 server * 50 000 per year = $100,000 per year to Oracle. This doesn’t include how much they’ll charge you for support, tools, and reports. By the way, most likely you’ll have more than one server

Off-the-shelf software will always have different platforms and hidden costs–that’s how they milk your company like a cow.

3) Possible risk to data–You found another desktop application that can actually integrate with your existing company database; However, it requires a user with full permissions on the tables. Let’s say one your ill-informed employees changes something within the application or directly edits a record via the application–your database chokes.

What happened?

The software possibly has horrible checkpoint verification, and wrote a malformed record into the table. Call the database guy–tell him to please revert to the most recent snapshot.

Web applications are more efficient. Hell, if Google has Docs and Spreadsheets, Calendar, and Mail–Why can’t you? Here’s a list of open-source software that you can use for your company:

1) A documentation website: MediaWiki (Requires PHP/MySQL)
2) A web mail client with desktop features: RoundCube Mail (Requires PHP/MySQL)
3) A project management tool: ActiveCollab (Requires PHP/MySQL)

Good luck. Remember–Everything in a web browser.

An RSS feed reads this:

<media:thumbnail>http://...etc/foobar.png</media:thumbnail>

<media:largeThumbnail>http://.../thumb.png</media:largeThumbnail>

While parsing the response XML document after querying a REST server, I found myself clueless as to why Mozilla Firefox (my main development browser) was confused about the “media:thumbnail” tag. Clearly, “document.getElementsByTagName” should grab all the “media:thumbnail” tags–at least in IE/Safari it does–but why not the Fox? Well, Mozilla Firefox seems to respect XML namespaces and thusly doesn’t interpret “media:thumbnail” as a tag while iterating through the DOM. To find the tags (media:thumbnail), you must specify “video” as the string parameter for document.getElementsByTagName().

Wow, so how do I make an elegant solution out of this situation? Hah. As dirty as any AJAX developer can get, I believe the only real way of doing this is to implement “browser specific code”. Damn, I said it. I thought I’d never ever have to write browser specific code. So, firstly, let’s download the BrowserDetect object located at http://www.quirksmode.org/js/detect.html.

Alright, let’s get to it.

//Alright, we've got our response XML from the XHR request already.
var data = o.responseXML;

//Get all 's within the XML document
var items = data.getElementsByTagName('item');

//Let's iterate through the children of

for(var i = 0; i < items.length; i++)

{
if (BrowserDetect.browser == 'Explorer')
{
var thumb = items[i].getElementsByTagName(’media:thumbnail’)[0].firstChild.nodeValue;
}
else
{
var thumb = items[i].getElementsByTagName(’thumbnail’)[0].firstChild.nodeValue;
}
}

That wasn’t so bad. I’ve tested it across Safari, IE6/IE7, and Firefox. Works well! Thanks to Quirksmode for the browser detection JS object.

EDIT: Sorry about the code formatting! I’m very new to Wordpress’s features.

After wrestling with Google’s search API, I found myself going back to the Yahoo Search API for many reasons.

1) Putting a Google Search on your website feels more like a hack than an elegant implementation…

2) Yahoo!’s search API allows you to do REST calls even on localhost as long as you have a valid Application ID, which you can easily acquire. (I’ll explain this in more detail below).

3) In terms of design, I have complete freedom with Yahoo!’s XML result set. With Google’s, you have to include the friggin’ CSS file, and apply some awkward h4cks to change the presentation.

The Google Search API will only allow you to access it based on the the API key and the URL which you registered. Thus, if you’re testing on localhost, it’ll reject your REST calls because your request isn’t coming from the URL you provided, but your IP of your connection. Oppositely, Yahoo! doesn’t care about the URL you’re accessing their APIs from. They only care about your application ID. Flexibility and convenience.

You can check out XWNED (http://xwned.com) now, it uses Yahoo! Web Search now instead of Google’s unflexible search API.