Unraveling Obfuscation

ob fus cate – 1. to confuse, bewilder, or stupefy 2. to make obscure or unclear

Archive for the ‘Coding’ Category

RIA and the universal universe

Posted by Todd McKinney on April 30, 2007

Partly because it has been way too long since I posted anything, and partly because there’s a lot of really big news going around today, I thought I’d take a few minutes to weigh in on the RIA hubub. Parts of Flex are being open sourced, Silverlight just got unveiled, Apollo is coming our way soon, and Ajax implementations and frameworks are all over the place. Every time I hit a link to a WPF app, I’m thrilled by the experience. Click-once finally works, and the apps have a ton of potential. Lots of good new stuff is becoming very real very quickly, and the future looks bright indeed for highly functional client application development that goes beyond the limitations of standard browser apps.

All of that is really good, and I’m truly excited to see the attention that these platform developments are getting. Everyone seems to have something to say about how cool it all is, so I’m not going to belabor that point. The thing that I’d like to see a little more discussion about is how people are going to get their hands on the tools to make all of this new stuff work. With Ajax, I think it’s a pretty straightforward story. Grab a toolkit and go to town. Most of it is free. With the others, I’m just not getting a warm fuzzy feeling yet.

In the case of Adobe, they probably need to generate a fair amount of revenue from their tools, since that’s pretty much all they do. I see Ryan Stewart talking about tools revenue like it’s a great thing because it will keep Adobe in business. I’ve purchased software from Adobe, and it’s painfully expensive. Microsoft also seems to be very keen to charge a lot of money to outfit a developer workstation with the good stuff. Mostly the strategy there seems to be an unbundling, so that you have to buy more than once to get everything. Similar to the way that OneNote isn’t part of what you buy when you buy Office, the cool graphics tools are still partially separate from the standard MSDN subscription. The original plan was 100% separate, but enough developers screamed long enough that at least part of the tools got rebundled, but come on. It’s not like they’re free – that’s a couple thousand dollars for a yearly tool subscription, and some of the designer apps are still not included.

Lest you think I’m just ranting like a cheapskate about the unfairness of having to pay anything for any software, let me put your mind at ease. I am not even remotely suggesting that it is somehow “unfair” for Microsoft or Adobe to charge big bucks for their tools. They spend a lot of money building them, and the tools are worth a lot to people who use them. What I am suggesting is that the strategy of maximizing developer tools revenue is a really bad idea for a platform vendor. The “DEVELOPERS! DEVELOPERS! DEVELOPERS!” rant that Ballmer got so much press over is a big deal. Where is the next generation of cool applications coming from? Who’s going to be writing them? Where do they get their tools? More and more, I know developers who either don’t like Windows, or don’t use Windows. Mostly, this is because they don’t have easy access to the Windows platform that I love so dearly, and they have learned to create software using LAMP or something crazy like that. This is a critically important lever in a platform race. Developers generate synergy for the platform by creating applications that people want to use. It really seems to me like the smart thing to do is to lower the barriers to entry and get these tools in the hands of the people who will be building tomorrow’s applications. There’s an awful lot riding on it, and whatever tools revenue is being captured is pretty small compared to the platform revenues hanging in the balance.


Posted in Coding, Tech | 3 Comments »

Performance Question – JavaScript Execution

Posted by Todd McKinney on February 25, 2007

As more and more applications that we use everyday are run in a browser, and increasingly rely on JavaScript for enhanced user experience, we developers should spend some time thinking about the implications of JavaScript code performance.

Scott Isaacs shared lessons learned building live.com some time back, and it touches on a couple of issues related to client-side performance. Notably, one of the observations is that parsing XML is slow. Another of the observations is that script download activities can negatively impact user experience unless it is carefully managed.

The IE blog describes some of the work done to improve JavaScript performance JavaScript performance Part 1, JavaScript performance Part 2, JavaScript performance Part 3 in IE7, and also makes recommendations about coding practices to increase client-side performance. Countless other resources exist to help make JavaScript applications run well.

My concern with all of this is that we are very quickly moving into a world where poor performance is becoming commonplace because of a combination of factors:
1. We have a ton of code being downloaded into our browsers and executed through an interpreter.
2. Browsers are not the most miserly resource consumers to begin with (see Firefox memory leak for example).
3. Too often, the performance characteristics of the code are not well understood and thoroughly analyzed by the developers writing the code.
4. With ubiquitous tabbed browsing and a proliferation of web-based applications, the end user is increasingly loading many different applications into the same process.

I am less concerned with items one and two than I am with three and four. We have a history of optimizing interpreted execution environments through the magic of JIT compilers. If there’s a speed advantage to be gained, and the performance pain is widespread and visible enough, I have confidence that the browser vendors will solve the interpretation problem. The same goes for garbage collection and general browser application resource consumption. The worse it gets, the more likely it is to be solved.

On the coding practices front, one thing seems obvious to me. This is not a no-brainer. As with most performance optimization, it takes a deliberate effort and a significant attention to detail to get the coding done right. Every time that a development effort prioritizes “get cool stuff done quickly” over well engineered, efficient code, the opportunity for end users to run something in the barely adequate to poor end of the performance spectrum increases.

To really compound things, loading up multiple sites in a browser instance with tabs means that the end user will often be running with more than just the code from one site in memory. I’m generalizing based on my own behavior here, but it can’t be that unusual. Typically, I have 15 tabs open in a single browser instance. The reason for the magic number 15 is that is about how many comfortably fit horizontally across the screen in my usage. Once I’ve gotten the browser instance “full” with 15 or so tabs, I launch a separate window and keep going. Normally, two browser instances is about all I’m willing to tolerate without going back and “recycling” existing tabs for something else. What I’m noticing is that more and more if I start hitting the wall on my local machine, the browser is a likely culprit for using up gobs of memory, and/or causing the CPU to sustain high levels of activity.

Interestingly enough on Windows XP, with IE 7, the mechanism used to open the browser window determines whether you share the process of the open browser instance, or get a separate process. Right-click a link in IE, select “Open in new window”, and you’re sharing the same process. Launch IE from the start menu, and you get a new process. Firefox 2 shares a single process under both of these scenarios.

I’ve really only just asked the question here. I need to do some measurement and analysis to make any sense out of it, but I do think we have some cause for concern.

Posted in Coding, Tech | Leave a Comment »

Atlas is baked

Posted by Todd McKinney on January 24, 2007

If you care, you’ve probably already heard, but the .Net Ajaxy thing is RTW…very cool 🙂


Posted in Coding | Leave a Comment »

Just warming up

Posted by Todd McKinney on January 19, 2007

One post down, and I already broke a rule. Just realized that my hello world post did not include any indication of what I plan to write about on this blog. Part of that could be on purpose, since I hadn’t thought much about it yesterday and I didn’t really know. Most of it is because I forgot.

My personal experience is that the types of blogs I truly enjoy reading are usually those that are consistently focused on a topic. Particularly the writing of Jeff Atwood is one of the first examples that comes to mind for regularly delivering something thoughtful and well presented. I’m also somewhat astonished at the consistently useful topics that the dynamic duo (Raymond Chen and Larry Osterman) serve up. I doubt that I’ll come out of the gate with that kind of impact, but it’s nice to have something to shoot for.

With that in mind, I’m going to stick to a couple of closely related ideas. First and foremost, I’m going to write about coding, because it’s what I do. With my recent focus turning to test automation and software releases, expect quite a bit of discussion about software quality and testing. The other bits will be something of a grab bag category – technology. Whether it’s cool gadgets that I find useful, or just something interesting going on in the industry, I’m going to consider it fair game and completely on-topic.

That covers what I will write about, but says nothing of what I will very rarely if ever touch on. I’m not going to spend much time meta-blogging about blogging and bloggers. I’m not going to pour out my innermost feelings and every thought that pops into my head on a daily basis as some sort of outlet for my frustrations (although I have to say that I do find Rory to be really hilarious sometimes). I’m not going to cover politics, or ever say anything about Lindsey Lohan.

Also, I plan to be consistent with the updates. None of this blog going dark for a month or two because I’m busy with something else. At the very least, I’ll put the word out if I’m going to go on hiatus.

Now that we have that nonsense out of the way, let’s get to work. There’s a lot of obfuscation going on out there, and it really is our job to unravel it.

Posted in Coding, General, Tech, Testing | Leave a Comment »