Month: March 2014

Sorry if I look dumb, this was sent from my phone

I’m sure this isn’t anything new, but it’s something I’ve noticed several times in the past few weeks: email signatures that say, “This email was sent from my phone, please excuse typos and brevity.” I already find it borderline offensive when somebody sends me a sloppy email with misspelled or abbreviated words and broken sentences, but to then suggest that I overlook these “mistakes” is enough to set me off.

Yes, it’s harder to type quickly and accurately from your smartphone. There’s nothing that prevents you from reading what you wrote to determine whether or not you sound like a moron, though. Nobody’s reading your horrible email and then getting to the signature and saying, “Ohhhhh, it’s just because they sent it from their phone. Whew! I was beginning to think they were dumb or didn’t care about the quality of what they produce, but it’s actually because they’re being ultra-responsive to my needs by replying on the go.” What people are really going to think is that you don’t know better or don’t care about your mistakes, and I’m not sure which is actually worse.

So, instead of letting the world know that you probably know better–and I assure you, the world doesn’t think you do–but you just don’t care, how about you take the time to READ what you’re sending and correct mistakes that you notice? Yes, you’ll probably make a typo here and there or misuse/forget to use a comma, but that’s bound to happen regardless of how you’re communicating. It’s okay, and it’s better than acknowledging that you probably sound like an idiot but just don’t care.

At the end of the day, people who care about spelling, grammar, and professionalism are going to judge you regardless of what your email signature suggests. What you should really do is just slow down and review what you produce. If you find that you just can’t write a high-quality email from your phone, I suggest you stop trying and reserve yourself to only sending emails from a computer. If it’s something that really, truly can’t wait, email is probably not the most effective means of communication, anyway. (Hint: It is incredibly likely that your phone has a phone feature.)

Database SpecFlow Scenarios and TransactionScope

My team has been using SpecFlow to verify that our data access components are working correctly. In an effort to write repeatable tests that won’t pollute the database, we’ve decided to wrap each scenario in a transaction.

Creating and rolling back the transactions is very simple to do with SpecFlow’s BeforeScenario & AfterScenario hooks.

using System.Transactions;

[Binding]
public class TransactionHooks
{
    private TransactionScope _transactionScope;

    [BeforeScenario]
    public void BeforeScenario()
    {
        _transactionScope = new TransactionScope();
    }

    [AfterScenario]
    public void AfterScenario()
    {
        _transactionScope.Dispose();
    }
}

By including these hooks, you’re placing your test scenarios in the loving embrace of a transaction scope. The act of instantiating the TransactionScope will update the ambient transaction that will be used by all subsequent code unless you explicitly tell it to do otherwise.

If you’re testing code that uses TransactionScope itself, using TransactionScopeOption.Required will allow the code to use the ambient transaction if one exists. Note that this is the default value, so it’s what you’re using if you’re not explicitly specifying an option. However, the other TransactionScopeOption values will cause code to execute outside your test scenario’s ambient transaction by either creating a new/different transaction (RequiredNew) or executing outside the transaction (Suppress).

Why are you doing that?

We’ve all been there before: the boss approaches and asks you to do something that seems useless. You don’t ask questions. You just do it because they’re the boss, and that’s what they asked you to do.

“Why are you doing that?”
“I don’t know.”
“It seems dumb, doesn’t it?”
“Yes.”
“Then why are you doing that?”
“Boss told me to.”

Ugh. Don’t you see? Everybody loses when this happens! You’re doing something you perceive as useless, so you probably feel like you’re time is being wasted. You’re also probably not putting forth your best effort since you’re doing something you think is useless. Plus, you don’t understand the reason you’re doing it, so there’s a good chance you might overlook something that’s relevant to the actual goal. So even if you’re trying your best, you might not be as effective as you could be. Maybe there’s a better way to accomplish the goal than what you’re being asked to do, but how can you know without having any awareness of said goal?

I see this all the time, and it drives me CRAZY. It’s sad, too, because the solution is so simple: ask questions. Don’t do something without understanding why you’re doing it. The worst reason you can have for doing something is because somebody told you to do it. The next worst reason is that it’s what you’ve always done. If you’ve been given an assignment, and you don’t understand why you’re doing it, don’t just do it: ask some damn questions! You’re smart. You have ideas. If you understand the problem you might be able to come up with some smart ideas about how to solve it. (And if you can’t, at least you’ll understand why you’re doing that dumb thing you’re doing.)

You might be able to do an okay job by just doing what you’re asked to do without knowing why you’re doing it. You’ll probably do a better job if you know what’s trying to be accomplished, but you’ll do your best work if you can somehow find a way actually care about the problem. Mindlessly doing what your told is a fantastic way to be mediocre and not have a satisfying career. Being engaged plays an important role in both performance and satisfaction. You must understand a problem in order to care about it, and only when you care will you become truly engaged–unlocking your full potential, producing your best work, and feeling maximum satisfaction for what you’ve accomplished.

Paste as Plain Text in Windows Store App

I was working on a Windows Store app that used a RichEditBox for text entry. Everything worked great until I pasted some formatted text into it. The dumb thing kept all the formatting! Okay, I guess that’s probably good since it would be pretty annoying if you wanted the formatting, but I didn’t.

Good news, though: it’s easy to remove that formatting and paste as plain text. So easy, in fact, that you can do it in a single line. RichEditBox has an ITextDocument property (Document) that has an ITextRange property (Selection). And guess what ITextRange has? A Paste method! However, this is where it got a little tricky for me because Paste takes an integer parameter, and it took me some googling to find a list of valid values. (Sorry, text-pasting enthusiasts, but you can’t use DataFormats in a Windows Store app.) In the end, I was able to find what I needed here.

Once you’ve got the code, you just hook up a handler to the RichEditBox’s Paste event and–voila!–pasting as plain text.

XAML:

<RichEditBox Paste="OnPaste" />

Code-behind:

private void OnPaste(object sender, TextControlPasteEventArgs e)
{
    var editBox = sender as RichEditBox;
    if (editBox.Document.CanPaste())
    {
        editBox.Document.Selection.Paste(1);
        e.Handled = true;
    }
}

Create a Single WSDL File for WCF Services in .NET 4.5

One of the things that I’ve always found to be annoying is that WSDL files generated for WCF services that reference objects in different namespaces include wsdl:import links to other WSDLs. This separation by namespace may make sense from an organizational/maintainability standpoint, but it makes it difficult to provide a WSDL for a privately hosted service to a third party consumer doing external development.

I was excited to learn that .NET 4.5 has an option to generate WSDLs as a single file–what a great idea! It’s easy to do, too. All you do is append ?singlewsdl to your service instead of the standard ?wsdl. When you do this, all of the types from the various namespaces that might be in-use are included in a single file. It’s wonderful!

Read more about this and other new enhancements to WCF in .NET 4.5 here.

How to Not Suck at Exception Handling

Yesterday a co-worker sent me an email about an error that was reported to them. “Have you seen this error before? If you have, can you tell me what it means?” This is a huge pet peeve of mine. Too many developers view exception handling as nothing more than an anti-crash mechanism. When an exception occurs, it gets logged and ignored. If the application’s not working, somebody might look at the log and see a repeated error message in the form of an exception.ToString(). That exception gets reported and travels electronically through the ranks until it makes its way back to the developer: “Oh, that exception?” the developer replies, “That just means the certificate is missing.”

Oh, that’s it? Thanks for the info, but I’ve got news for you: you failed. If you can say “That exception means…” then that’s what the application should’ve reported to begin with. Further, an explanation like this should only be forgivable if it’s followed by “I’ll update the application to say that.” Accepting “<insert exception here> means <actual problem>” as a solution should be unacceptable to all parties involved.

The good news for developers is that this isn’t a hard problem to solve: you just have to not suck at exception handling. The even-better news is that it’s not hard to be a good exception handler, you just have to think about what you’re doing and follow a few easy steps.

Reduce exception handling

My smelly-sense definitely goes off when I see code that has exception handling in every single function. This obviously depends on the code–maybe it’s necessary–but you should try to only include exception handling where it’s needed. If you can’t think of anything that can go wrong, don’t cover it up when the unthinkable occurs.

Of course, if you can think of things that might cause exceptions…

Catch specific exception types

This is where you look at your code and think of everything that might go wrong. If you’re writing a file, what happens if you don’t have permissions or the directory is missing? If you’re calling a web service, what happens if the service isn’t available? What happens if you access that database with invalid credentials? Each of these problems produces a specific exception type that can be caught and handled in its own special way. If you know where an exception could occur but don’t know the specific exception type, test to find out.

It would be rude in all of these scenarios to simply pretend that everything is okay and move on. Instead, do the courteous thing…

Provide meaningful messages

Don’t just tell people what happened, tell them what it means or what they can do about it! Should they restart the application? Do they need to contact an administrator? Is it connection problem? Is this going to resolve itself?

I mean, don’t get me wrong: System.ServiceModel.Security.SecurityNegotiationException “SOAP security negotiation with http://localhost/someservice.svc for target http://localhost/someservice.svc failed. See inner exception for more details” is a terrific error, but you’re not doing anybody any favors by showing it in a message box or writing it to a log. Doing something like that is just begging to be bothered for interpretation later. Instead, provide a meaningful message: “A security negotiation exception occurred. Verify that the certificate exists and has appropriate permissions.”

Remember that updating these messages is an important maintenance step. If a new cause for an exception is identified, be sure to add relevant information to your messages to make them as helpful as possible!

Don’t eat exceptions

One of the worst things you can do is to “eat” exceptions. I’m talking about adding try { … } catch (Exception) { } around all your code where the catch logic does nothing or quietly logs some details without indicating any problems to the rest of the application. I’m not suggesting that you let any and all unaccounted for errors crash your application, but allowing exceptions to fail as loudly as possible will lead to a more robust end product. The squeaky wheel gets the oil, you know? If you follow the guidance above, a new exception that was previously unaccounted for will result in code that specifically handles the newly identified scenario and provide meaningful information. The next time the exception occurs, there should be no mystery around what caused it or what should be done as a result.

Test everything*

*Everything that you can think of. The end goal of most applications is (or should be) to create a positive user experience. To that end, when you’re adding exception handling for specific scenarios and providing meaningful messages, you should verify how it will present to the user. If it’s something the user needs to address, make sure they receive clear information about what they should do. If the user needs to contact somebody, such as an administrator, make sure they know what to tell them. If something happened that the user doesn’t need to worry about, maybe you want to make sure that they can’t tell it even happened. Whatever it is that you’re trying to do, test it and make sure it works how a user should expect it to.

Find the Best Wifi Channel with Meraki Wifi Stumbler

Recently, I’ve been having network connectivity issues at home. Browsing the internet is generally fine, but if I try to stream a video or play games online, I have disruptions every few minutes. One of the suggestions that I got from Comcast was that there might be interference on the wireless channel that my router is using.

I’m not wireless pro, but that seemed like a reasonable thing to check out. Before arbitrarily picking a different channel, I wanted to see what other wireless networks around me were using. After a quick or search or two, I found a free wireless analyzer called Meraki WiFi Stumbler.

WiFiStumbler

WiFi Stumber is a simple app that gives you basic details about the wireless networks that can be found. It’s easy to see the signal strength, encryption, and–what I was looking for–channel. Using the app, I did a quick scan to determine a channel that wasn’t being used by one of my neighbors and plugged it into my router. Now I can check wireless interference off my list of possible culprits!