Months ago, I tweeted "Once you have a hammer, everything looks like a nail" with a link to an interesting article about the times you shouldn't use System.DateTime.Now - sure, you know how to use it, but it's not always the right tool for the job. Keyvan Nayyeri provides a number of alternatives for .NET developers who want to know when something happened, or how long something took. Definitely worth a read.

Then just weeks after that, Susan Ibach gave the SQL side of the story with a blog post about avoiding the DATETIME type if you're using SQL 2008. I saw the headline and thought "what? what else would I keep a date or a time in?". The answer is, either something smaller or something with more precision. Makes sense.

Goes to show, just because you've heard of System.DateTime in .NET or DATETIME in SQL doesn't mean there's no other way to solve your problem. Keep learning!

When I provide links from this blog, I don't shorten them. When I get a link in an email, I always hover over it to see where it leads, in case it's a phishing email. But when someone emails you a shortened link, or tweets a shortened link, how do you know where it leads? It might be a phishing link. Or it might just be that cat video you've seen too many times already.

Years ago, Joshua Long wrote up a summary of how to see where a shortened link goes before you click it, and he's been updating it pretty regularly. He covers TinyURL, bit.ly and its relatives like on.fb.me, goo.gl, is.gd, and many I've never heard of. There's even a site you can paste a shortened link and get back what it redirects to. Not all links will be worth this treatment, but many will. It's nice to have a summary of how to check them before you follow them.

I'm pleased to see that Kenny Kerr is writing his C++ column for MSDN again. He's also blogging again and in a recent entry, he provides some really plain-spoken advice to people looking for guidance:

"You can of course still use MFC but I do not recommend it as modern C++ can do
a better job of supporting the Windows developer."

"You should never again use auto_ptr for anything."

So there! I agree with these, especially the auto_ptr one. It was an attempt at a smart pointer that just wasn't smart enough. We have shared_ptr and unique_ptr now and they work in collections and are truly smart pointers. Use them and stop typing delete in your code entirely.

As for MFC, it does fill a need and I certainly wouldn't scrap a working MFC app just because the library is getting old (the facelift a few releases ago helped) but if I was starting a brand new application from File, New Project I would need a good reason to use MFC as my UI framework.

People often ask me what Visual Studio Ultimate offers that other versions do not. There's a handy chart on the Microsoft site:

The only problem is, if you don't know what "Architecture and Modeling" includes, it's easy to think there's probably nothing useful in there. So I was pleased to see a blog post by Susan Ibach from Microsoft Canada showing how easy it is to generate a sequence diagram from code, and how that can help you understand code you've inherited from a predecessor. That's one of the diagramming tools included in Visual Studio Ultimate.

Right click in some code, select Generate Sequence Diagram, set some options (does getting a property count? What about calls to methods of String or other .NET Framework classes?) and presto, you have a sequence diagram.

This sort of thing can save you a tremendous amount of time, and that means it can save your organization money. That's why some people buy Visual Studio Ultimate, after all. Having access to a tool like this is one of the ways I can "hit the ground running" when I join a project. If you need to do the same, make sure you're not ignoring a capability you already have.

Like a lot of people, I got started on Facebook one way, but now I use it another. And like a lot of people, I haven't quite "cleaned up" from my original start. My rule these days is very clear - Facebook friends are actual friends. People I know and like. In fact, my rule is that we should have shared a meal - ideally a meal and some wine - to be friends on Facebook. If we worked together, or presented at the same conference, and we actually enjoy each other's company, chances are we went for dinner, or lunch, or a beer, at some point. It's a handy rule that makes my decision process easy. I get friend requests all the time from people I don't know, and I just ignore them.

With that audience, my Facebook posts can be pretty personal. What my kids are up to. Pictures of my family and my holidays. Details about travel plans, including whole-family trips that leave my house empty. Sure, I know that what you put on Facebook can be forwarded and shared elsewhere. But I know who I'm sharing with and I trust them to have my best interests at heart. I don't connect my Twitter statuses (which I know are public) to my Facebook ones (which are more private and less frequent) or vice versa.

What I've set up, for people who use Facebook as a news hub, is a public page. Here I post when I'm speaking somewhere, or when a video or article is published. If you "like" this page, my announcements will end up in your news feed. So if you added me on Facebook and never heard back, use the public page instead. I don't post links to all my blog entries there, because I figure you can always subscribe to this RSS. I don't post anything personal either, so if you don't actually care where I'm spending my holidays, you might want to like that page even if we're already Facebook friends.

It's worth explaining a few things about me and Twitter. First, I'm @gregcons. There is someone with @KateGregory but it's not me, and whoever it is has never tweeted. I follow several hundred people and several hundred people follow me. I don't "follow back" when people follow me, unless I happen to recognize the name when Twitter emails me about it. I look at the tweets of people who retweet me or @ me (or who people I follow retweet, or who people I follow are in @ conversations with) and if the tweets look interesting, I follow for at least a while.

I tweet a mixture of personal ephemera (wow, what beautiful weather we're having today), personal stalker-bait (I'm at place x with person y, hey whoever sure was great seeing you today, wow my child just did thing x in place y), and actual technical stuff. The technical stuff might be my own blog entries, my own material being published (a PluralSight course, a Channel 9 interview, a TechEd talk) or a link to someone else's blog entry/interview/talk that I think is interesting. If you want only the technical stuff, my public Facebook feed (more on that in an upcoming post) is a better choice.

I unfollow people for a variety of reasons. People who post a great volume of tweets that are in a language I can't read, or are about things that don't matter to me, just clutter up the stream, so I will unfollow. It's not a value judgement and it's not about the ratio of useful to non useful, just the volume of non useful. (Non useful includes what your cat just did, what airport you just left or arrived at (a few close friends excepted), what you are eating/drinking unless it's inspirationally yummy, coded/veiled potshots at your coworkers, and updates on your car repair or the planning of your wedding.) Since there's a lot of overlap among the people who care about the same stuff as me, I find that when these people post something useful, ten of my friends retweet it anyway, so I won't miss it. People who just post the same thing over and over because they read somewhere that Twitter is ephemeral and people might miss your announcement at 8am so you should do it again and noon and again at 5pm and so on I will usually unfollow also. I don't keep track of who is unfollowing me and I'm not offended if I realize someone has - we all use these things differently and one person may unfollow for too much personal stuff and another may unfollow for not enough personal stuff or not different enough from my other feeds.

I mostly use MetroTwit. This lets me have search columns on myself, my @mentions, and whatever topic I'm interested in according to the news of the day or the event I'm attending. I have a Twitter client on my Windows Phone and A Quick Tweet by Scott Cate as well - it loads super fast because it's for sending tweets, not reading them. I also use the web page from time to time. I always check email before Twitter, so it's not a great way to get hold of me in a hurry.

I don't blog my tweets. I often tweet my blog posts. If something deserves to stick around for a while, I may quickly tweet it, then later write up a blog post about it. Other than that, there's little overlap.

Twitter has turned out to be hugely valuable to me. I find out about breaking news faster than Google News, I hear technical rumours and announcements there first, and I keep in touch with technical friends the world over, as well as my own neighbourhood and my family. I've started my day with smiles from jokes or from just seeing what people I care about are up to, and I've kicked off business conversations, too. It's part of my work rhythm now and it's pretty much the only place I put personal stuff these days. If you're not part of it, consider giving it a try for a week and see what changes for you.

Here's an article in a pretty mainstream publication - the Economist - that explains why concurrency matters. I used to say "the future is concurrent" but that was then; this is now and it's the present that's concurrent. As the article says,

What was once an obscure academic problem—finding ways to make it easy to write
software that can take full advantage of the power of parallel processing—is
rapidly becoming a problem for the whole industry. Unless it is solved, notes
David Smith of Gartner, a market-research firm, there will be a growing divide
between computers’ theoretical and actual performance.

I'll have some more concurrency material over the next little while in this space. Things continue to change pretty rapidly. If you haven't been thinking about concurrency, now's a pretty good time to start.

Take this blog post by "Daan-Nijs" about the abilities of the watch window. I knew the first one, but the rest are new to me:

Changing a value in the watch window

Changing a type in the watch window

Inspecting an array in the watch window

Then there's re-running or skipping code by dragging the instruction pointer - I only knew I could right click somewhere and say Set Next Instruction. Finally he includes a reminder of how to enable Edit and Continue. All this is for C++, but you're welcome to give some of the techniques a try in other languages and see what happens. Being a faster and more productive debugger will rocket you up the overall productivity leagues like nothing else.