If you're using Windows and aren't using ZoomIt, you're missing something. We all run into those scenarios where we see an image, but it's not quite as big as we'd like. For those situations, Microsoft gives us ZoomIt. There's not a whole lot to explain here. Download it, run it, and press Ctrl+1 to zoom in. From there, move your mouse around to reposition the view and press up and down to zoom in and out further. There are also options for drawing, typing, and even a timer. These are for presentations and I don't use them much, but I'm sure others find them more useful. If you haven't tried it before, ZoomIt is definitely worth at least trying once. You can even run it from the web to stay up-to-date with the latest release.

I'm a month and a half late, but the Resharper nightly builds are back! I guess I stopped checking after not seeing any movement for a while. I'm glad to see some activity, tho. This is the most beneficial add-in to Visual Studio I've seen; especially as a productivity geek. What I've been most surprised about is the overall quality of the nightly builds in the past 6 months. Simply outstanding. If you're asking yourself whether to give it a shot or not, I say go for it. You're likely to run into minor issues, but if my experiences are indicative of how well they manage their day-to-day development, this is a team with a very tight ship. I always grab the latest and try to update a few times a week, depending on what I'm in the middle of. If you're not quite as confident as I am, grab a "works here" release. I'm sure you'll see how great this tool is in relatively short time. An absolute must-have for all code-focused developers.

I know some people have asked in the past how to map latitude/longitude on Live Maps and I just ran into a scenario where I needed to do it. Well, it's as simple as typing in the desired lat/long, selecting Locations, and doing a search. Admittedly, it's not the most intuitive thing in the world, but I figured it out in a matter of seconds.

If you're looking to link directly to a lat/long position, you can also pass in the lat/long via querystring parameters. There are a number of different querystring parameters, and I'm not going to go thru them all here, but I will mention the two most important: cp and where1. The cp parameter is the lat/long position you want to center on. Using this alone will center on the lat/long at the default level, which isn't much help. For this reason, I'd recommend you also specify the where1 parameter, which performs a search for the lat/long. The key thing to remember here is that cp delimits the latitude and longitude by a tilde (~), whereas where1 uses a comma. Here's a sample URL: http://maps.live.com?cp=36.16773~-115.157181&where1=36.16783%2C-115.15707.

Over the years, I've been asked to put together coding standards again and again. The nice thing about this is that it enables me to pull out the old docs and touch them up a little. A year or two ago, I heard something that made a lot of sense: developers never really read coding standards and, even if they do, they don't usually adopt them. Let's face it, if you don't adopt a standard as your own, you're not going to use it. The only way to ensure the standard is applied is to catch the problem before it gets checked in. I tried a VS add-in that attempted to do this as you type, but it wasn't quite as extensive as I want, but I grabbed onto the concept. For the past year, I've been wanting to start this and have finally decided to do it.

As I sat down and started to investigate writing custom code analysis rules, I asked myself how I was going to validate them. After hacking away at one approach after another, I started to realize I wasn't going to get very far. Apparently, with the latest releases of Visual Studio and FxCop, there's no way to create the objects used to represent code. After talking to the product team, the official position seems to be that, since custom rules aren't "officially supported," they're not going to support their testability. I'm not sure who made this decision, but I think it's a bad one. Of course, I say this without knowing their plans. Well, not completely, anyway.

It's not all bad news, however. It turns out there are hopes to start officially supporting custom code analysis rules in the next major release, Visual Studio 10. Nothing's being promised at this point, it's just something the team would like to deliver. I should also say that the upcoming Rosario release isn't the major release I'm referring to. I'm expecting Rosario to be a 9.1 release that will probably hit the streets in early 2009. That's a guess, tho. If that's true, the VS 10 release probably wouldn't be until 2011. All I can really say about it is that it'll be a very exciting release. I can't wait to get my hands on a beta. Speaking of which, some of the goals they have for the product will make beta testing much much easier... I'm talking about a hugely evolutionary change, if not revolutionary, considering where the product is today. That's all I can really say, tho.

Back to the point, since there's no realy testability of the code analysis framework, I decided to create my own object model. The part I'm missing, obviously, is the factory logic that converts code analysis types to my types. I'm hesitant about this approach, but it's working so far. Hopefully, I'll have something to deliver soon. I keep bouncing around, tho, so at this point, I want to deliver a release with only naming conventions. That release is mostly complete, I just need to get approval for a distribution mechanism. If I don't get that soon, I'll just release it on my site.

It's amazing what sticks and what doesn't. Back in Aug 2004, I caught wind of UpdateVersion, a tool Matt Griffith wrote to update version numbers in AssemblyInfo files. The tool is pretty simplistic, but provides an absolute benefit. Every couple of months, I get asked for a copy of the changes I made... despite the fact that they've been available online for years. Nonetheless, it's about time I created a project on CodePlex for the utility. At this point, I don't really expect to make any changes to it, but I will if someone sees value in it. If I were to make any changes, I'd probably go ahead and convert it to .NET 3.5 and possibly even add a PowerShell cmdlet.

I just wanted to share a small script that creates a new profile and registers the ps1 file extension. For those that don't know, ps1 is the default extension for PowerShell scripts. Of course, there's a difference between ps1 and bat or cmd. If you double-click a ps1 file in Windows Explorer, it'll open in Notepad. What's up with that!? Apparently, this was done for security reasons. The idea is that, since you can't simply double-click on the file to execute it, hopefully you'll actually look at it to make sure it's not going to kill your system. PowerShell is much more dangerous than traditional batch files are, so this is probably a good thing. With that in mind, PowerShell, by default, doesn't allow you to even execute these ps1 files. To do that, you have to set the execution policy. Anyway, here's the script...

# create profile script
$dir = [System.IO.DirectoryInfo]$profile
New-Item -Type Directory -Path $dir.Parent.FullName

# enable the ability to execute ps1 files
Set-ExecutionPolicy RemoteSigned

I found this online a while ago, but I don't remember where. The only other thing I want to mention, since I imagine some people might freak out by it is the New-Item cmdlet, is that there's a function that simplifies this call and gives us a familiar DOS experience: md. I always thought md was an alias, but never bothered to consider why/how the New-Item cmdlet was determining that you wanted a directory.

I just downloaded IE8 and have to say I'm liking it so far. I was pretty concerned that it was going to be a horrid experience, but it hasn't been. Of course, the next thing I did in this self-centered world of ours was check my website. Being built on DotNetNuke, which is notorious for non-standard HTML, I was concerned. I was happy to see no problems. I'm sure there will be some, but at least I'm looking good so far. I guess all that work I did trying to keep tables out of my design was well worth it.

My only real disappointment has been the fact that web slices have to be explicitly coded into web content. For some reason, I was thinking we could simply select a portion of the age and tell IE to create a web slice from it. I guess not. Maybe I was just thinking of Dapper.

Is PowerShell the best command line environment out there? Looking at a comparison of computer shells, I'm thinking it is. I'm sure others would disagree, but the facts are there. There are about 3-5 runners up, but the one feature which puts PowerShell over the top, in my mind, is the use of .NET objects in the pipeline.

As I've been working with PowerShell more and more, I keep picking up small tidbits I'd like to share. Arguably, I'd have learned a lot of them much sooner if would've picked up a book or something, but I look at this as a language I'll just pick up over time and don't really want to dedicate the time to a book... at least not at this point. So, I've decided to start throwing out a few PowerShell tips. I'd like to do a tip of the day, but I don't know if I'll come up with that many. We'll see. For this first post, I guess I should give a very brief overview of what PowerShell is and a few of the basic concepts behind it.

PowerShell is Microsoft's command line replacement. If you've ever done any time on the command line -- yes, I phrase it that way on purpose -- then you know it can be a pain. Not only is it painful, like any "good" prison, it's very limiting... another prison-like attribute. Another aspect I believe PowerShell is trying to attack is Windows shell scripting with VBScript or a similar language. I've used VBScript a few times for UI automation and I have to say, it's not much better than the traditional command line. The bottom line is that PowerShell is a powerful scripting environment for Windows.

So here are the basics: cmdlets, aliases, functions, and the pipeline. Cmdlets are commands. Go figure. If you want to do something, it all comes down to the commands you have available to you. To get a list of commands, type Get-Command. From there, you can figure out what's possible. If you have any questions about how to use them, type Get-Help [cmdlet]. Aliases are exactly what they sound like, aliases for cmdlets. This is one of the great things about PowerShell because it allows people to adopt PowerShell much easier. For instance, dir and ls are both aliases for the Get-ChildItem cmdlet, which is great for DOS and Linux/Unix users, respectively. Notably, the parameters are still PowerShell parameters and not the same as what's in DOS or the *nix systems. Functions are like a gateway drug to true PowerShell productivity. Think of functions as small scripts -- once again, go figure. Lastly, the pipeline is a concept that one command, whether that be a cmdlet or function, can send its output to another command via the pipeline. This is done by using the pipe ("|") character. For instance, to sort a list of folder contents by size, you pipe the contents to one that will sort the items it receives: Get-ChildItem | Sort-Object Length. Pretty simple. The key here, and true power of PowerShell, is the fact that PowerShell acts on .NET objects. This is a first. All other command line environments are pure text and piping content from one command to another is simply sending text down the pipe. Being built on .NET, PowerShell gives us an unprecedented amount of control and flexibility in our scripting.

To give you an idea of Microsoft's dedication to PowerShell, there's an internal mandate that all system administration tools must be built on PowerShell by 2009. The latest Exchange, Active Directory, and System Center releases have already made the switch and SQL Server 2008 is well its way, too.

I'll leave the intro here. In coming posts, I'll dig a little deeper into new features that I find. I'd like this to ultimately turn out to be a developers' guide to PowerShell, but that's more lofty a goal than I'm ready to sign up for. We'll see how things progress.

This is old news, but it's still worth mentioning. Google has always been known for its simplicity, which is one thing I wish Microsoft would learn, and the announcement they made back in December is no different. Surprisingly, I haven't seen much adoption of the service, but Google's new chart API looks pretty nice. The fact that you can build charts with relatively simple URLs is pretty nice. Admittedly, maximizing SQL Server Reporting Services is a much richer experience with much more options, but this API is still nice for smaller scale needs. If you haven't already, check it out. There are still some kinks that need to be worked out and parts that are harder to grasp than is really necessary, but they have made a huge improvement on something that just about every developer could use.