One thing I ran into this week is trying to run node within the Azure emulator, giving me access to the emulated versions of Azure table storage, queues, and blob, while also having debugging running.

If you are familiar with the Azure Node.js SDK, you’ll know that you can launch your role using the Start-AzureEmulator Powershell command. Unfortunately, this command doesn’t seem to have any debugging options.

Fear not: there’s an easy way to get this up and running with node-inspector: you can open up ServiceDefinition.csdef, where you should see the following line:

<EntryPoint>
  <ProgramEntryPoint commandLine="node.exe .\server.js"
       setReadyOnProcessStart="true"/>
</EntryPoint>

So if you already have node-inspector (if not, run “npm install node-inspector –g”), you can launch it with the “node-inspector” command, and then change this line in ServiceDefinition.csdef to be:

<EntryPoint>
  <ProgramEntryPoint commandLine="node.exe --debug-brk .\server.js" 
      setReadyOnProcessStart="true"/>
</EntryPoint>

Then run Start-AzureEmulator. Happy debugging!

Recently I’ve been playing around with Knockout.js, and one of the features I wanted to implement was a Facebook like button inside of the details view of a master-detail. Facebook provides the following code snippet for their JavaScript SDK:

<div id="fb-root"></div>
<script>
    (function (d, s, id) {
        var js, fjs = d.getElementsByTagName(s)[0];
        if (d.getElementById(id)) return;
        js = d.createElement(s); js.id = id;
        js.src = "//connect.facebook.net/en_US/all.js#xfbml=1&appId=10349446178";
        fjs.parentNode.insertBefore(js, fjs);
    } (document, 'script', 'facebook-jssdk'));
</script>

As well as the following markup snippet for the actual like button implementation.

<div class="fb-like" 
  data-send="true"
  data-show-faces="false" 
  data-href="www.facebook.com">
</div>

Unfortunately, if you simply try the following code – things will not work as you change the details view as the Facebook SDK will not reparse the page to update the URL and render the Like button.

<div class="fb-like" 
  data-send="true" 
  data-show-faces="false" 
  data-bind="'data-href': myUrl">
</div>

Fortunately there’s a simple workaround – create your own binding handler, and then call Facebook’s JS API directly to reparse the markup that you have for the like button. Here’s the binding handler:

ko.bindingHandlers.likeButton = {
  update: function (element, valueAccessor) {
    $(element).attr('data-href', valueAccessor());
    FB.XFBML.parse();
  }
}

Note that I can also be more specific by calling FB.XFBML.parse() on the specific element that contains the like button (not the actual like button itself, for reasons I did not investigate further – likely this is an implementation detail on Facebook’s side). Intuitively though, you should probably pick the containing div as a target for the parse() call for the best performance.

Then simply update your markup to this:

<div class="fb-like"
  data-send="true"
  data-show-faces="false"
  data-bind="likeButton: myUrl">
</div>

And you’re done!

I was reading a Facebook post by a friend today inviting others to try Bing (which currently offers a rewards plan for using it where you can get gift certificates for searching and clicking on sponsored links). I’ve also recently heard about duckduckgo.com, another up and coming search engine.

For the past few weeks I’ve been rotating between using Google, Bing, and DuckDuckGo, and to be honest, I really can’t tell the difference anymore for most of my searches. If I were to do the same thing last year (when I first switched to Bing), there would be things I would need to fall back to Google for. I think a big part of this is that search in general is getting better, to the point where 90%+ of my searches on any engine will give me a relevant result on the first page.

This reminds me of what happened with wireless routers back in the day, when they were new, high margin devices and brands like Linksys, D-Link, and Netgear were clearly differentiated by feature sets, reliability, and UI. Don’t get me wrong, the same holds true today, but to be honest margins have dropped and the differences in terms of wireless performance are difficult for an average consumer to grasp. This lack of ability to differentiate a product leads to commoditization, where producers are unable to effectively market their product.

I think most people would agree today that a wireless router is a commodity. And I would like to think that there are a couple of parallels between that and search engines. Two things jump out at me about the wireless router market:

1. Figuring out which wireless router to buy is difficult. If you go read user reviews, you will see many 5 star and many 1 star ratings for the typical product. It’s impossible to tell who is credible unless you invest a significant amount of time reading reviews, go with the “average” assessment, or ask your friends what they use.

2. Due in part to #1, you stick with brands you know. For example, if you’re a Linksys person and you haven’t had issues with your last router, when time comes to replace it you will probably buy another Linksys product.

When it comes to search engines, I defy you for #1 to say that one search engine is always better than the other. Folks have their ingrained preferences, but if we were to objectively start from ground zero today (that is, you’ve never used a search engine), I think it would take you a while to figure out which one would work best for you, and even then, unless you have specialized needs such as development work, I would argue the differences are marginal.

For #2, like with routers, folks aren’t going to switch search engines unless they perceive a problem with their current solution. Let’s face it, most people on Google don’t feel like they have a problem today. Until the thought leaders start switching over to other search engines because of a remarkable improvement, it’s going to be an uphill battle for newcomers to the space, which brings us full circle to why Bing needs to incentivize you to switch.

What do you think? Feel like search engines are becoming a commodity?

You would think that working on the ASP.NET team you would eventually get jaded by the novelty of the Internet and come to accept it as a fact of daily life. And to some extent this does happen because you’re focusing on the task at hand: pumping features out the door and ensuring that they rock.

I know it sounds cliché, but this weekend I was reminded of the simplest thing about the Internet: the fact that it allows people from all over the world to collaborate and help one another in real time (sometimes you don’t even need Twitter for that).

Here’s the story: I had my Mazda up on jack stands because I was planning to drain and replace the transmission and differential fluid. I got the differential fluid done fine, but when it came time to do the transmission, my transmission case looked different from the one in the step-by-step guide, so I was guessing which bolts were the fill and drain. Obviously this was the worst possible time, as I had already jacked up the car, was already dirty, and none of my friends who would have the expertise were available.

So I whipped out my laptop and posted a picture on Mazda forums, and within minutes somebody had gotten back to me and confirmed where the fill and drain plugs on the transmission were. Maybe I had just inhaled too many fumes, but in that moment, I was very grateful to have the Internet. And more importantly kind connected strangers willing to help a computer guy with his car.

*IE9 Reference Intentional. www.beautyoftheweb.com

As I’ve been preparing for my talks at DevConnections next week, it’s struck me how talk preparation is one of those things that is immensely enjoyable yet incredibly frustrating (read: time-consuming) at the same time. 

Why me?

What’s so hard about giving talks?  Well, being in a programmer role, this is one of those things that most people dread, and for good reason: it’s a lot of work and there’s a lot of pressure. But perhaps more importantly, you don’t get a lot of practice doing it.  And this turns out to be incredibly important both in general and specific cases.

How did you become a good programmer?

Nobody ever sits down at a computer and instantly is a master programmer.  Skill in programming, like any discipline, is learned, molded, and practiced, typically in a relatively relaxed environment where you get to collaborate with more experienced people who can give you feedback about your code. In my opinion, this is one of the reason open source projects tend to do so well.  If you didn’t have to practice to get good, well, congratulations, you’re some kind of super genius, but I would say most people aren’t like you :).

So What?

At this point, you’re probably wondering what this observation has to do with giving technical presentations.  Well aside from reading a list of tips, which is really useful and great, there is the underlying principle of getting better at anything.  How do you build a better coder?  I like to think of it in terms of three major categories:

  • Mentoring from experienced people: Code reviews, chatting with your managers and senior developers
  • Practicing: Getting hands on experience doing what it is you want to get better at, so in this case, writing code
  • Learning: This is an obvious but important point.  Practice and mentoring are worthless unless you learn from them and do things differently.  Don’t make the same mistakes.  Learn new things.  Keep getting better.  My piano teacher always said: don’t trick yourself into thinking that doing something wrong 100 times is practice: it’s not.  It’s better to do it right even just once.

What about my talks?

And so dear reader, if you’re still with me at this point, we come now to the crux of the matter.  Most programmers have never had experience giving technical presentations, and thus never really had a change to practice or get good at it.  Even for those of us who have, how often do you do it? That’s why Scott’s Post is so relevant: a lot of us simply don’t do presentations often enough to remember all of these things and get better at them.  I myself am guilty of this, and find that every time I have to do talks I need to rebuild some of my expertise, and this takes some time.

Fine, but why do I care? Let Scott do the demos.

Technical presentation skills are highly effective and transferrable to your day to day work.  The core discipline is to communicate technical information as effectively as possible, and we all do this in our day to day work.  More recently, our QA team has started recording bug repro videos for the developer team to use.  Getting good at these is a great stepping stone to improving your presentation skills: nobody wants to watch a video of a bug report where you are saying “uhm” and “errrrr” all the time.  I’ve also heard good things about Toastmasters as a way to get better by practicing, but YMMV.

Okay I believe you.  How do I get better?

By now you probably know the answer.  Practice.  Like crazy.  But look for opportunities to practice.  Whether it’s giving a small presentation to your team, or maybe to your boss, or even getting good at shooting small videos, these things add up to being a better presenter.  One of the things that helped me greatly was doing joint talks at first, with James Senior and also with Simon Calvert.  I got to see first hand how experienced speakers prepared for talks, structured content, and kept the audience engaged.

My biggest three tips are:

  1. Keep the audience engaged and involved.  James Senior taught me this one first hand, and watching Scott Hanselman present has really driven this point home for me.  People aren’t there just to learn from your content, they are there to be entertained and kept awake.
  2. Provide compelling content.  Tell a story.  Nobody wants to see you go up there and rattle on about a boilerplate list of new features when they don’t see how it could map to their day to day work.  Don’t expect anyone to make the leap on their own.  Show them.
  3. Practice.  Know your talk and your content.  Time your slides.  Set up dry runs.  Go over the talk until you know it by heart.  It’s funny because you would think that this leads to a scripted delivery (and to be fair you should be careful that you aren’t doing this).  On the contrary, I’ve found that it allows you to be flexible when questions do pop up –> you can recover much easier and also go off the beaten path if you sense the audience is interested. 

I do have to credit Simon Calvert with teaching me the importance of #3.  I think few people put in the tremendous effort to deliver a phenomenal show for our customers.  For all the blog posts and tweets and books I have and could have read, none of them resonated with me more than sitting down with a mentor and learning, apprentice-style, from a master.  I encourage you all to find these people in your circle and follow in their footsteps.  Happy practicing!

For those of you who have heard about it, Mark Berryman and I are taking over the CodingQA podcast from Matthew Osborn and Federico Silva Armas.

In our first episode, we talk about the different roles –> how developers and testers work together, and how it’s not about the people, but sometimes about the part they play.  Check it out, I promise more episodes to come :)

Last week I posted about looking into the keyboard locking up issue in Visual Studio.  So far it looks like not a lot of people have replied to provide concrete repro steps, which confirms my suspicion that this is somewhat of a random issue.

So at this point, I have a couple of choices.  I can either wait for somebody in the community to provide a repro of the problem that I can reliably run into, or I can do the work myself.

I’m going to do both, so while I’m waiting for more possible bug reports, I’m going to write a tool that models the behavior of a typical Visual Studio user and use that to hopefully isolate the problem.

I’ve chosen to go with this path since given the information in the bug reports, it seems people hit the issue with many different configurations in many different scenarios.  This means that me sitting down without any solid repro steps is likely not going to be a good use of time.  Instead, I’m going to go with a model-based testing approach where I will define a series of actions that a user in VS can do, and then proceed to run my model.  I’ll let you guys know how this works out for isolating bugs :)

I’m using an internal tool for the model engine and AutoIt for the UI automation (I want something lightweight for a one-off).  One of the challenges will be getting feedback: AutoIt is great at driving, but not so great at understanding what success and failure means.

One of the initiatives I’m involved with on the ASP.NET and Visual Studio teams is the Tactical Test Team (TTT), which is a group of testers who dedicate a portion of their time to roaming around and testing different parts of the product.  What this generally translates to is a day and a bit a week helping out with areas of the product that have been flagged as risky, or tackling problems that span both ASP.NET and Visual Studio.  There is also a separate component of this effort outside of TTT which is to help with customer scenarios and design.

I enjoy being on TTT because it allows me the opportunity to look at the entire product and gain expertise in a wide range of areas.  This week, I’m looking at Visual Studio 2010 performance problems, and this gem with the keyboard in Visual Studio locking up ended up catching my attention.

First of all, here’s a link to one of the many Connect bugs describing the problem:

Microsoft Connect

I like this problem because it really highlights the challenges of reproducing customer bugs.  There aren’t any clear steps provided here, and I don’t know a lot about your environment: not just the basics like our OS version, but also what third party plug-ins or antivirus software you might be running that might contribute to the problem.  In this case, my gut tells me that there is more than one bug here, just by the sheer volume of reports.  Here’s another thread where users talk about it:

Microsoft Connect

The volume and different configurations are staggering.  From a customer perspective, this is a very clear cut case of basic functionality not working in the product, but from our perspective, it’s hard to find something reproducible: even customers don’t quite agree on what causes the problem (installing ReSharper seems to cause a problem…or does it?).

So this then, is the start of a QA investigation. If anybody has isolated repro steps (just comment on this post) that they can provide this will immensely help us nail down the issue(s), but I’ll be doing a multi-part series on my progress and methodologies as I look into the problem.

Recently, I’ve been playing around with the Windows Phone 7 Developer experience.  Quick tip: I tried to deploy my application to the phone, and got an error: “Zune software is not launched. Retry after making sure that Zune software is launched.”  This wasn’t particularly helpful for me since I did have the software launched, and my phone was connected through wireless sync (didn’t remember this at the time). 

A quick search turned up nothing, and restarting the client didn’t help.  But then I remembered my setup and plugged my phone straight into the USB port and then had no problems.

Thinking about it, I wouldn’t expect this scenario to work, but there was no indication of this provided to me as a devt.

A couple of takeaways as a tester and geek:

1. Bad error messages cause customers a lot of pain.  Fighting for these in triage is probably worth your time.

2. Wired > Wireless, even in 2011 :)

If all goes well I’ll be speaking about WebMatrix and NuGet this March at DevConnections Orlando! I always enjoy coming out to conferences and meeting customers who work on the Microsoft stack. When I went to DevConnections Las Vegas in 2009 it was to talk about what was new in ASP.NET Web Forms, and it was really great to hear all the community feedback about the new features we were delivering.  I look forward to seeing you all in March and talking about the new web development paradigm we are delivering with WebMatrix.  Till then!

More Posts Next page »