One of my least favorite parts of nearly every programming language I’ve spent much time with has been the ubiquitous switch statement. Though it does serve a useful purpose in some compiled languages, I think switch is a clunky eyesore in most code. Its structure is prone to taking root and only growing larger and more cumbersome over time.

If you’re coming to JavaScript from a background in procedural languages like C#, Java, or PHP, it’s natural to reach for the same tools, like switch, that you’re accustomed to using in those languages. However, JavaScript’s flexible object literal syntax and first-class functions offer alternatives to switch that I believe are cleaner, more extensible, and more maintainable.

So, in this post I want to show you a few ways that you can refactor a JavaScript switch statement to use this alternate technique, and improve its extensibility and maintainability in the process.
Click here to read the rest of this post »

ASP.NET Web API has been one of my favorite recent additions to ASP.NET. Whether you prefer a RESTful approach or something more RPC-oriented, Web API will do just about anything you need. Even if you’re still using ASP.NET WebForms, Web API still has you covered – a nice example of the “One ASP.NET” philosophy that’s finally beginning to come together.

However, ASP.NET Web API throws an unintuitive curveball at you when you want to accept simple primitive types as parameters to POST methods. Figuring this issue out is particularly confusing because it’s one of the rare parts of Web API that violates the principle of least astonishment.

Because of that, using jQuery to interact with those methods requires a slight contortion that seems strange at first, but makes sense once you understand why it’s necessary. In this post, I’ll briefly describe the underlying issue and show you how jQuery can be convinced to work around the issue.
Click here to read the rest of this post »

One of the best things about Twitter is that relationships there can be asymmetrical. Even if I don’t know you or follow your updates, you can still follow mine if you’re interested. Over time, we might talk in @mentions from time to time and I might realize that you’re someone whose updates I’m interested in all the time. In fact, that’s exactly how I end up following most of the people on Twitter that I’ve never met before.

It’s not that I don’t want to hear what everyone has to say, but automatically following thousands of people back would make my timeline impossible to keep up with (and even more productivity-cripplingly distracting than it already is).

One thing about these loose, asymmetric relationships constantly frustrates me though. The requirement that I must follow you in order for you to direct message me, even after I’ve direct messaged you, is too restrictive. Pointlessly restrictive.

It often makes sense to take a Twitter discussion private, but we can only use Twitter to do that if we have a symmetric relationship with each other. Sure, I can follow you temporarily or message you my email address for follow up, but why? It should be easy for Twitter to allow anyone to reply to any direct message for some period of time, or even forever.

Wouldn’t that make the direct message feature a lot more useful?

GitHub recently released a new version of its search feature. Unfortunately, it quickly became obvious that the feature could be misused to locate data that wasn’t intended to be exposed publicly. Passwords, oAuth tokens, and private API keys are particularly common in source code, and well-crafted searches to find them were making the social media rounds almost immediately after the new feature was released.

Of course, this sort of thing is nothing new. Similar Google searches have been possible for years. However, GitHub currently seems to house a concentration of particularly sensitive secrets. Maybe that’s because it’s so easy to accidentally commit these things along with associated code with a quick git commit -a.

I’ve been working on a few Node.js projects hosted on Windows Azure lately, and one in particular is stored in a public GitHub repository but needs access to private oAuth keys. So, this topic is something I’ve been dealing with myself lately. Through that project, I’ve been fortunate enough to stumble onto a nice symbiosis between Azure and a Node.js module called nConf that solves the problem of storing secrets in my public repositories.
Click here to read the rest of this post »

Each year, I get a little closer to not making this post before the year is over, much less on the actual anniversary of when I started posting (12/21). That’s mainly because it seems more like a “me” post instead of something that you might actually find interesting or useful and that’s not really what this site is supposed to be about. However, every time I mention skipping it, the feedback is in favor of making the post. So, here it is (and I’ll try to do better next year).

Click here to read the rest of this post »

If you follow me on Twitter, you probably know that I’ve been playing with a shiny new Microsoft Surface RT that I’ve had for about a month now. I’ve had a bunch of requests for a post about my experience with it thus far, so here we go…

Since I had a few weeks to write it, this post grew a little bit out of control. Sorry in advance for the wall of text. To hopefully compensate a bit, here’s an index of the major sections:

• Windows 8 RT
• Hardware
• Touch and Type Covers
• ClearType Display
• Apps
• Performance
• Battery Life
• WiFi
• Conclusion

In an unsurprising twist ending, I wrote the first few drafts of this entire post on my Surface RT. I used the Touch Cover for most of it, and then picked up a Type Cover toward the end and used that for the rest.

I tried to write a post like this soon after receiving my original iPad, but was not successful due to a combination of the pain that comes along with long-form writing on a screen-board and the tedious multi-app workflow in iOS — it’s definitely possible, but it’s a task that requires more determination than I could muster at the time.

By contrast, Windows 8 and the physical keyboard made writing this on the Surface RT nearly indistinguishable from writing on my 13″ laptop. If you want a tl;dr for the next 6,500 words, I think that sums it up pretty well.

Click here to read the rest of this post »

Windows 8′s new gesture for closing programs works pretty well when you’re using a Surface in your hands as a pure tablet, but it feels a bit awkward when you have the Surface’s kickstand and a Touch/Type Cover deployed. Something about the combination of angle and distance in that configuration makes dragging from top to bottom of the screen feel awkward.

Though Windows 8 apps don’t look like traditional Windows programs, many of Windows’ traditional keyboard shortcuts still work in them. In Windows, Alt + F4 is the keyboard shortcut to quit the active application and that shortcut also closes apps running in the new UI.

At first glance, the Surface’s Touch Cover doesn’t appear to have traditional function keys. However, the top row doubles as function keys if you hold down the “Fn” key at the lower right. As you might expect, the fourth key from the left (marked as a play/pause key) is F4′s secret identity.

So, holding both Alt and Fn and then pressing play/pause works to close the active application without dealing with the vertical dragging gesture.

Have you ever tried washing dried, day-old ketchup off a dish? It’s not fun. What would have taken just a couple seconds to rinse off while it was still fresh can take minutes and multiple attempts to scrub off later.

Worse, the realisation that you’re going to have to deal with the dried ketchup is most likely to come right when you need to do something else with that dish the most.

As you let ketchup (and other foods) accumulate on your dishes without cleaning them immediately, eventually your entire collection of dishes is unusable.

Some dishes are more disposable than others. For some dishes, you’re eventually more likely to throw the dish out and start over with a new one than find a way to make the ketchup-spackled disaster you’ve created serviceable again.

Seriously though

One of the hardest parts of software development is simplifying and explaining it to the non-technical people who write the checks. Technical debt is one of those crucially important concepts that can alter the course of an entire company if left unchecked, but it can be incredibly difficult to clearly convey that to non-technical stakeholders.

Your negative notions about what debt is might be what a “business guy” considers productive leverage. You can just pay that debt back after the new feature makes us all rich, right? I wonder if that has ever happened?

Next time, tell them it’s like ketchup.

This post was originally going to be about improving performance in ASP.NET MVC websites that use the Razor view engine. Instead, it became a cautionary tale about just how important it is to run your ASP.NET sites in release mode if you care anything at all about performance.

The whole thing began when I tweeted about some rough benchmarks on ASP.NET MVC controller actions vs. ASP.NET Web API endpoints last week, and Ashic Mahtab asked me to also run some benchmarks comparing MVC’s Razor and WebForms view engines. When I ran those benchmarks and replied to him with the result that Razor was running much slower than WebForms, he had this suggestion:

@encosia did you remove the web forms view engine for the razor test?

— Ashic Mahtab (@ashic) September 2, 2012

Good idea. I did that, re-ran the Razor benchmark, and the magnitude of the change really surprised me. Razor was over twice as fast with the WebForms engine removed!

I knew that removing the WebForms view engine improves the performance of Razor view resolution, but I didn’t expect the difference to be nearly that significant. So, why was the difference so large?

Click here to read the rest of this post »

Rob had me on This Developer’s Life recently, along with several other fine folks, talking about drama on the Internet, semicolons, and generally “why so mean?”

I thought it was an interesting episode. Though I’ve occasionally been sucked into “someone’s wrong on the Internet” myself, I try to avoid drama. So many debates-turned-arguments on the Internet are all downside and have almost no potential upside even if you “win”.

So, I was really interested to hear what others had to say about the topic, and they did not disappoint. If the subject sounds interesting to you (and fair warning, there’s almost no technical content in this one), you might enjoy it too.

You can stream or download the episode here: The Developer’s Life – 2.0.9 Drama