Close

PowerShell

Using Windows 7

Posted on July 11, 2012 at 09:00 by Julian Kay

I have used Windows 7 since the early betas, as is always the case with new Windows releases – I was very interested in what new features were coming. Over the years I’ve come to rely on these features quite heavily, and like millions of other people I’m currently use it as my primary operating system.

My use of Windows 7 has changed quite a lot over the years – from simply changing themes to using totally different applications. But as Windows 7 is coming to the end of its life (for me anyway) I’m interested to see how my computer usage will change and evolve when Windows 8 takes over as my primary operating system.

So I thought I’d take a moment to reflect on how I’m using Windows on my MacBook today…

I like to keep things simple, a trend that will no doubt continue to Windows 8. As part of this I usually keep the number of applications I pin to the taskbar to absolute minimum. On my home computer this is PowerShell, Outlook and OneNote.

In the notification area I tend to have only power, networking, and volume icons, as well as the awesome Process Explorer. This is pretty much all I want to see down there, and everything else gets hidden away. (Remember when we couldn’t hide stuff down there? Ugh!)

Because this is a laptop, I tend to run a lot of my programs either maximised or side-by-side using Aero Snap. This is by far one of my favourite features in Windows 7, and I use it all the time. Just grab the title bar of any window and drag it to the top, left or right of the screen to snap the window into place.

Windows itself is just the shell that works around the applications, and right now the applications I tend to use the most (other than the web browser) are:

  • PowerShell
  • Office
  • Visual Studio
  • Expression Studio
  • WebMatrix
  • Windows Live Essentials
  • Zune
  • WorldWide Telescope

All of these applications are made by the same company as the operating system they are running on, so you’d think that they’d all behave exactly the same. This is not the case – each one tends to have its own UX and personality. Something that’s probably going to change in Windows 8 thanks to the advent of the Metro design language.

There are plenty of other smaller applications that I also use, including (but not limited to):

  • Paint.NET
  • EOS Utility
  • FileZilla
  • Flux
  • KatMouse

Oh and as for the browser? My current choice is actually Google Chrome. Mostly because of the spell checking functionality. I’ve used Internet Explorer 10 pretty extensively on the preview versions of Windows 8 and I quite like it, so the chances are I’ll probably move back to IE when it comes out at the end of the year.

Finally I also spend a large amount of time in PowerShell console windows. I have a lot of applications and scripts that I use in this environment, and I’m really hoping we get some kind of full screen Metro treatment to PowerShell – until then I’m probably going to have to use the Desktop to run these kinds of apps.

Windows 8 will definitely let me work in exactly the same way I do today – you can get access to all of the desktop and features of Windows 7 (with more stuff) so there’s no doubt about that. But will things change?

Eventually Metro-style applications will take over from the desktop applications we are using today. It just might take a while.

Querying TFS with TFPT.EXE and PowerShell

Posted on July 1, 2011 at 09:38 by Julian Kay

At Branded3 we use Team Foundation Server for source control, task managment, and various other tracking purposes. One of the benefits of this is being able to run queries with WIQL to pull off reports.

As is usually the case with me, I have set up a couple of PowerShell scripts that use TFPT.EXE from the Team Foundation Server Power Tools to make life a little simpler for myself…

Viewing Open WorkItems

$TFSSERVER   = "hq-tfs08-01.branded3.net"

Function Get-WorkItem
{
    $query = "SELECT [System.Id], [System.Title] FROM WorkItems " +
             "WHERE [System.AssignedTo] = 'Julian Kay' " +
             "AND [System.State] <> 'Closed' " +
             "AND [System.State] <> 'Resolved' " +
             "ORDER BY [System.Id]"

    tfpt query /collection:$TFSSERVER /wiql:$query /include:data
}

This little script gets a list of WorkItems which are not closed or resolved from TFS. I find this much faster than opening a copy of Visual Studio to find out which tasks I have assigned to me. True you could run this kind of script by using a batch file, but I like the fact I can use this in conjunction with the various Outlook scripts I use for PowerShell with simple one-liners like foreach ($workItem in Get-WorkItem) { Add-OutlookTask “$workItem” }

Getting Work Hours

Function Get-WorkItemHours
{
    $month = (Get-Date).ToString("MMMM")
    $year  = (Get-Date).Year
    $query = "SELECT [Completed Work] FROM WorkItems " +
             "WHERE [System.AssignedTo] = 'Julian Kay' " +
             "AND [Assigned Month] = '$month' " +
             "AND [Assigned Year] = '$year'"

    $hours = tfpt query /collection:$TFSSERVER /wiql:$query /include:data
    $total = 0.0
    foreach ($hour in $hours)
    {
       $total += $hour
    }
    $total
}

We also have custom fields which help us keep track of the hours we’ve spent on a project, and as shown above, we can even see how many hours have been spent in a month. By running this simple script I can be sure that all my time is correctly recorded to enable us to both bill correctly, and keep track of how long things really take.

Naturally, everyone has their own requirements for scripts like this, but PowerShell gives me the flexibility to create these simple utilities with very little development work.

Fix for Italic Fonts in Windows Command Prompt

Posted on June 30, 2011 at 15:47 by Julian Kay

I kept getting a problem where the Consolas font was in italics on when using either CMD or PowerShell on Windows 7.

After messing around with lots of options, I actually ran a repair on the Office 2010 installation I had. It worked. I’m not exactly sure why this is the case, but if you’ve got this problem – you might want to try this too.

I know Consolas ships with Office 2010, so maybe the repair just makes sure the font files are installed correctly. If anyone knows the real reason, please feel free to leave me a comment!

Outlook Tasks in PowerShell and Vim

Posted on June 29, 2011 at 10:15 by Julian Kay

Getting Outlook Tasks in PowerShell is actually pretty easy. All you need to do is use the Office Interop to get access to the default tasks folder, then iterate through the items that are returned.

Create a file called Get-OutlookTask.ps1 in your scripts folder, and paste the following code:

Add-Type -AssemblyName Microsoft.Office.Interop.Outlook
$folders = "Microsoft.Office.Interop.Outlook.OlDefaultFolders" -as [type]
$outlook = New-Object -ComObject outlook.application
$mapi = $outlook.GetNameSpace("mapi")
$tasks = $mapi.getDefaultFolder($folders::olFolderTasks)

foreach($task in $tasks.Items)
{
  if(!$task.complete)
  { 
    $task.subject 
  }
}

Naturally, you could customize this script to work any way you like – for example, you could sort by priorty or date, or you could show an extra column for category information. I have actually set up an alias to this script, so all I have to do is type tasks to see all my current tasks.

If you have set Vim to work with PowerShell, you can import your Outlook Tasks directly into the open document by using the Vim command:

:r! tasks

Pretty cool huh? If you’re looking to add Outlook Tasks in a similar way, you can check out this script by Lee Holmes. I use this one with the alias of nt to save on all that extra typing.

If you want to be able to add Outlook Tasks from Vim, I suggest you add the following function to your vimrc file:

function! Task(args)
  system("nt \\\"" . a:args . "\\\"")
endfunction

command! -nargs=1 Task :call Task('')

Now you just need to call :Task buy milk and it’ll get added – without switching to the shell itself.

Writing and Running F# Scripts with Vim

Posted on June 28, 2011 at 09:15 by Julian Kay

When I’m writing software for the .NET Framework I tend to have a copy of F# Interactive open. This lets me run commands directly like so…

This is fine for simple stuff, but if you’re writing something a little more complex it’s better to write a script. In the past I’ve done this by having another copy of Visual Studio open and running the script that way. This works really well, and includes colour coding, intellisense and all the other good stuff you expect.

However there are times that having yet another copy of Visual Studio is a little heavy for just keeping track of a script. Enter Vim, the de facto command line editor for Unix and other operating systems.

  1. Set up Vim to work with PowerShell
  2. Grab yourself a copy of the F# Syntax file
  3. Save it into your Vim plugins directory
  4. Add the following lines to your vimrc file…
au BufRead,BufNewFile *.fs set filetype=fs
au BufRead,BufNewFile *.fsx set filetype=fs

Now when you create a .fsx file, you can run it directly from F# Interactive by using Vim’s shell execution feature.

:!fsi %

This will run your script in F# Interactive and present you with the results. The :! Vim command is for running the external program, and the % represents the filename of the currently open document.

Note that you’ll need to have set up F# Interactive by either adding it to the path or setting an alias in PowerShell. If you haven’t done this already, you can do it by adding the following lines to your PowerShell profile:

$FSIPATH     = "C:\Program Files (x86)\Microsoft F#\v4.0\Fsi.exe"

Set-Alias fsi  $FSIPATH

Setting up Vim to work with PowerShell

Posted on June 27, 2011 at 09:50 by Julian Kay

As an avid console user, I like being able to edit text without opening an interface that requires a mouse. For me this text editor is Vim – the extremely well regarded editor that ships with a very large number of operating systems.

My command line of choice is PowerShell, and I set up any extra commands to live in a Scripts directory inside my Windows user directory. If you’d like to do this you need to download Vim to the Scripts directory, then edit your PowerShell profile to include an alias so you can access Vim from any directory you might be in, as well as a couple of commands to make editing common files even simpler.

# There's usually much more than this in my profile!
$SCRIPTPATH = "C:\Users\Julian\Scripts"
$VIMPATH    = $SCRIPTSPATH + "\vim73\vim.exe"

Set-Alias vi   $VIMPATH
Set-Alias vim  $VIMPATH

# for editing your PowerShell profile
Function Edit-Profile
{
    vim $profile
}

# for editing your Vim settings
Function Edit-Vimrc
{
    vim $home\_vimrc
}

Then you need to set Vim up in the way you like it, there are lots of sites with suggestions for how to set your vimrc file, but for now I’m just going to suggest you add a link back to PowerShell by adding the following lines:

set shell=powershell
set shellcmdflag=-command

This means that when you run the :shell command in Vim, you will actually use PowerShell itself to run commands, including all the aliases you set in your profile. I find this especially handy for writing and running F# scripts, as well as task management with Outlook – both of which I’ll write about in posts this week, but you can test this out now by running :sh or :!get-childitem | more and seeing what happens!