Super Mario in JavaScript (no kidding)

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/super_mario_in_javascript_no_kidding.htm]

I am impressed - someone has ported a trimmed-down Super Mario engine to JavaScript. Wow. I was impressed with Silverlight because it allowed 2D game development and let you avoid writing as much JavaScript. Just wow, got to give credit where credit is due.

http://www.nihilogic.dk/labs/javascript-games/

LCNUG: JavaScript - Beyond the Curly Braces

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/lcnug_javascript__beyond_the_curly_braces.htm]

Last night several people braved the potential snow storm to hear Sergio Pereira's good presentation on advanced JavaScript. Sergio did a good job of explaining advanced JavaScript nuances, but not dwelling on the obvious stuff. It's a difficult balance to strike because everyone has already heard of JavaScript, but few people know its many obscurities.

 

Sergio blogs at: http://devlicio.us/blogs/sergio_pereira/

 

 

Why syntax is becoming less painful

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/why_syntax_is_becoming_less_painful.htm]

Unless you're a language enthusiast, most developers dislike "wasting" time trying to understand syntax. Syntax trivia makes for bad interviews, developers dismiss a problem as "that's just syntax", and it's generally considered a waste of mental energy for developers to thrash over syntax.

 

Now, at least for the type of .Net application development that I often do, syntax is mostly pain-free, partly thanks to:

• Powerful IDEs that include intellisense and compiler checking.

• Billions of online examples that are a google-query away, such as complete reference guides, tutorials, forums, and fellow blogger's who encountered the exact same one-in-a-million bug.

• Better designed APIs. for example, both C# and VB.Net reuse the entire .Net framework, making syntax differences trivial.

• Emergence of standards, like XML, HTML, and language conventions.

• The deliberate attempt by designers and architects to reduce the need for syntax by wrapping interfaces with abstraction, using standards and patterns and reusable blocks, and leveraging config files.

• More developers in the field with whom you can ask syntax questions too. For example, I can often ask clear-cut SQL syntax questions to our DBA, and he'll just nail them. ("What's the syntax for setting an index on a temp table...?")

• More powerful hardware that lets you do all this. If you only have 4KB of memory, it's a challenge just to make something possible, and you're willing to throw easy-syntax overboard to get it to work. Your machine lacks the resources to "afford" an IDE, and every language construct is optimized for the limited resources as opposed to ease-of-learning.

However, it wasn't always this way. I remember as a kid back in the late 80's, with the TRS80 and RSDOS, just staring blankly at the green and black television (didn't have a monitor). There were a few "computer people" I could talk too (like my brothers), but it was nothing like today.

 

This comes to mind because I've been reading up on PowerShell and Silverlight, and it just works. I haven't had a major syntax problem yet. It feels like I'm just cruising down the highway, and that's a nice feeling.

 

Total Cost of Ownership - a Story

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/total_cost_of_ownership__a_story.htm]

A company needs some software service that isn't their standard-line of business, so they outsource it to you (and your company) and pay for the application. So far, so good.

But then, as the client is using your app, they're struggling on the employee search filter page. After getting frustrated for five minutes, they ask their coworker if they know how to work it, just to make sure it's not some obvious mistake. After neither one can figure it out, they think it's an error (not the friendly name "bug", but an error, and to them a critical and fatal one).

So, they phone your company's customer service rep, who rushes around trying to find a fix, and inevitably has to get back to them. After a string of High-Priority emails between the customer service rep and several maintenance developers and documentation writers, the customer service rep is confident that this is an "issue" (perhaps an "error", but issue sounds less blamable), they apologize to the client and offer that it will be fixed in the next release - several months in the future. "No deal" the client says, "We need this now."

Your company's account manager (who oversees that account) gets involved, trying to work their magic diplomacy to make everyone happy. But the client insists "we need this - the thing simply will not work for our business cases without it." So, your company being one that always puts the customer first, pulls in an executive who directs the issue to a developer who can make a fix right away, and hopefully get out a patch or hotfix.

The developer drops whatever they were doing, losing all the momentum they have built up for their current task, and re-mobilizes to hunt down this issue (which is in code they never even wrote). They coordinate with a product manager to make sure they understand the exact new functionality. After spending hours coming up to speed, and ensuring they can reduplicate the bug, the developer finds a fix. It was one line that needed to be updated. Indeed, it often seems that these types of bugs are "just" one line.

The code is sent as an emergency item to QA, who redeploys their environment, confirms the fix, does a little regression to make sure it didn't break anything else. After all this, they then sends it to IT, who stays late that night to make a special patch deployment.

The team's work pays off - thanks to hours and hours from the customer service rep, the account manager, the product manager, the developer, the QA tester, and IT - one line of code has been fixed in production, and the client is happy again. For some development shops, this is actually optimistic, as many places wouldn’t just dismiss it as "a small issue" or have to wait to the next release instead of patching right away.

However, while it's great that the team was flexible enough to handle this change, think of the cost. Here's the problem. Fixing that one-line bug after production release could have easily cost hundreds of times more resources than just doing it right the first time. If it took the whole team 16 people-hours, and the original developer could have caught it with an extra 5 minutes of unit testing, then this was a colossal waste of time. The problem is that many developers insist (and managers cave in to) that "I just don't have time" to do . And then from their short-sighted perspective, they've saved the company time because they got the feature done 5 minutes earlier. However, the total cost of ownership - not just the developer creating the initial feature, but everything else involved (like QA and maintenance) is what really matters. If a sloppy developer can shortcut 5 minutes, only to waste the team hours later - whose really coming out ahead? Answer: Your competition.
 

Book: C# 3.0 in a Nutshell

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_c_30_in_a_nutshell.htm]

I recently finished a casual read of Joseph & Ben Albahari's good book C# 3.0 In a NutShell (by "nutshell" they mean 800+ pages).

 

They do a good job of including two audiences - those new to programming (who need C# syntax and the basics of an array explained), and those familiar with C# who just want to see the new stuff. I found the chapters on Linq and Ling-to-Xml very instructive.

 

They also then give a healthy chapter to each of the main parts of the framework. To be able to jump from language design to Linq to System.Net to Reflection to Xml to Serialization and beyond is an impressive feat. I think having that kind of broad knowledge gives the developer a powerful tool belt. Besides the basics (like xml), there are simply cool tools and process that you can never create unless you understand reflection, diagnostics, networking, streams, and even threading.

Real life: Automation and teaching your kids

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/real_life_automation_and_teaching_your_kids.htm]

We have 2.5 kids. Cute little bunch - but very dependent on Mom and Dad. Every few minutes, they come back to us, needing something. Of course, our goal is to teach each kid to just take care of things - brush their own teeth, pick up their toys, eat their food, etc... And then, ideally they could string all these acts together and just take care of themselves for some time on end. Especially as the older one learns to do this, it frees us up to focus on other things - like the young one throwing toys at the wall. Especially with the second, and third, you realize that you don't scale - there are too many kids per parent - you need to make them self-sufficient, at least for a time.

 

This reminds me much of automated process. Both ideally could be on autopilot. Both come back to me asking for help (my console app burped on a bad xml input file, my service didn't handle the machine restart, my build script crashed on spaces in a filename, etc...). While it's cute to initially have your pet application that you baby-sit and marvel in awe of how well it churns through those calculations, soon you'll have a new pet application, and you'll need that first one to be self sufficient.

 

One more similarity - you hope that one day they'll both make you rich. The kid will strike it big and take care of Mom & Dad in their old age, and those .Net applications will keep delivering business value and keep you employed. [just kidding]

 

Although, of course the analogy breaks down because the kiddies are so much cuter, but you get the idea...

Why I'd rather be an optimist

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/why_id_rather_be_an_optimist.htm]

Some programmers take pride in calling themselves either an optimist or a pessimist. Both have their positive and negative stereotypes: The out-of-touch bubbly optimist vs. the encouraging can-do optimist; the always grumpy pessimist vs. the face-the-facts pessimist.

Part of it is that most producers tend to be optimists, as it takes a can-do attitude to carry out the positive act of creating. Most critics/complainers tend to be pessimists, negatively and constantly pointing to the shortcomings. However, these are not equal positions. The producer can produce without the critic, but that the critic needs someone else to produce something so that they have something to criticize. In other words, the producer (usually the optimist) does not need the critic (usually the pessimist), but the critic needs the producer. It's like riding a sled down the hill vs. pulling it back up - they're not equal tasks; one is much easier. Likewise, a room full of complainers will never actually build something. While constructive feedback is great, a purely negative feedback loop isn't constructive. It also will get on other coworker's nerves.

Some pessimists think they're providing a great service by always pointing out the flaws, lest the optimists lose touch with reality. However, "reality" doesn't need any help in reminding developers about the facts of life. It's got the compiler, project plan, and end-users to do that.

Ideally, as with everything else in life, there would be a good balance. But, everything considered, if I had to choose one I'd rather be an optimist. It's been said that "The pessimists may be right, but the optimists have more fun along the way."