To pull down, sort out and import the guide data for vuPlan.tv I thought it would be a good excuse to use PowerShell. I’ve been wanting to use this for ages, to get up-to-speed with what the future of scripting on MS Windows looks like.
I hated every moment of it.
This simple script took more than a whole day to write.
#
# Looks for the latest downloaded .zip file and extracts its contents.
#
$random = new-object -typename System.Random
$dataRoot = "C:\DATA"
$sourceFolder = $dataRoot + "\EPG"
$extractRoot = $dataRoot + "\EPG\TEMP-" + $random.Next(100)
$dataRepository = $dataRoot + "\EPG\HEAP"
$unzipToolPath = $dataRoot + "\unzip.exe"
$importerToolPath = "C:\Users\Public\Documents\~Main\Vuplan\Evoq.Vuplan.Data.Epg.Importer\Evoq.Vuplan.Data.Epg.Importer\bin\Release\import.exe"
clear
set-location $sourceFolder
#$latestFiles = get-childitem | where { $_.Name -like "*TV*" -and $_.LastWriteTime.Date -eq [DateTime]::Now.Date }
$files = get-childitem | where { $_.PSIsContainer -eq $false }
$latestFiles = $files | sort -property @{Expression={ $_.LastWriteTime }; Ascending=$false}
$latestZip = $latestFiles[0]
echo "Extracting " + $latestZip.FullName + " to " + $extractRoot
md $extractRoot
# This little chunk of code unzips using Windows shell but problems with the feckin .zip file mean
# that some files extract twice and invoke a UI prompt for overwrite-replace.
#
#$shell = new-object -com shell.application
#$zipFile = $shell.namespace($latestZip.FullName)
#$extractTo = $shell.namespace($extractRoot)
#$extractTo.Copyhere($zipFile.Items())
#foreach($item in $extractTo.Items) {
#
# $item
#}
$processArgs = "-o " + $latestZip.FullName + " -d " + $extractRoot
$startInfo = new-object System.Diagnostics.ProcessStartInfo($unzipToolPath, $processArgs)
$startInfo.UseShellExecute = $false
$unzipProcess = new-object System.Diagnostics.Process;
$unzipProcess.StartInfo = $startInfo
$startInfo
echo "Starting process."
$unzipProcess.Start()
while(!$unzipProcess.HasExited)
{
echo "Waiting for process to complete..."
[System.Threading.Thread]::Sleep(1000)
}
$sourceDirectoryInfo = new-object System.IO.DirectoryInfo($extractRoot)
foreach ($item in $sourceDirectoryInfo.GetFiles())
{
$destinationPath = [String]::Concat($dataRepository, "\", $item.Name)
if ([System.IO.File]::Exists($destinationPath) -ne $true)
{
"Copying " + $item.Name + " to the heap..."
[System.IO.File]::Copy($item.FullName, $destinationPath)
}
if ($item.Extension -eq ".xml")
{
$processArgs = $item.FullName
$startInfo = new-object System.Diagnostics.ProcessStartInfo($importerToolPath, $processArgs)
$startInfo.UseShellExecute = $false
$importProcess = new-object System.Diagnostics.Process;
$importProcess.StartInfo = $startInfo
$startInfo
echo "Starting import."
$importProcess.Start()
while(!$importProcess.HasExited)
{
"[" + $item.Name + "]" + " Waiting for import to complete... " + ([DateTime]::Now - $importProcess.StartTime)
[System.Threading.Thread]::Sleep(1000)
}
}
}
$sourceDirectoryInfo.Delete($true)
It was such a disappointment. I’m still disappointed as I type this. Being a scripting environment for the .NET Framework, I thought it’d be so cool. The power of the .NET Framework and the freedom of scripting.
But the Integrated Scripting Environment (ISE) is just some crappy cobbled-together tool written in not much more time than it took me to write my script here. It even uses the atrocious code editor from the Expression suite and not the awesome editor that Noah Richards and his team made for Visual Studio 2010.
But worst of all, it has no IntelliSense. Can you imagine?
Apparently there’s PowerGUI that is a non-Microsoft ISE that does have autocomplete (which is an absolute must when you’ve all of the .NET Framework at your disposal and there’s no compiler to warn as you go), but I read something about a guy having a problem with a script which was down to the PowerGUI editor getting confused over some combination of slashes and dots, which put me right off.
So I punched my code into the MS ISE, almost single fingering the keys to ensure it was all correct, like I was back in the 1980s with my Sharp MZ-700.
And slowly my will to live drained from me.
I even read some dude praising it because all he needed was Notepad and Google to be a master of his universe. Not out of my pocket does an engineer work with such inefficiency. Would you take the cab if you saw that the driver was peddling the car through a hole in the floor?
Next time, I will do what I usually do and write a full blown console application in a tenth of the time.
If you’re a .NET developer, Hell, if you’re a sys admin (as I was for years), I’d just use Visual Studio all the way. Skip those cmdlets.
Get properly organised by writing and adding to an assembly of reusable components and classes to help you do your admin tasks. Get the whole department adding to a super cool library of administrative joy.
I came into programming from a sys admin background. I worked for a very large organisation with tens of thousands of computers. I saw the same code across so many scripts, it was a terrible duplication of effort.
So I cultivated a library of fine-grained admin tools in a COM component that was deployed to the PC estate and called from the scripts, a core set of reusable functionality. Then later I integrated it with a Microsoft Excel add-in. That’s right, sys admins could build out their scripts from a report in Excel, drag and drop, cut and paste. Done.
Anyway, I’m going off on a tangent. The benefits of PowerShell from my noob viewpoint are, simple visual remotability and a focus for vendors to create simple APIs (by way of custom cmdlets).
These things are important for the daily activities of a busy sys admin performing live commands, sure, but if its a automated or long scripted process you need to write, its not ideal.
If you’re already a programmer, then just write a proper applet in the superior tools you know and love and share it with your team. And if you’re not a programmer, skip scripting and learn C#.
Coding in Visual Studio will blow your mind and make you a hero.
Luke
Labels:
tangent,
windows