Monthly Archive

Categories

Philosophy

Putting on the style

PowerShell is all about getting things done but how you do things can be as important as what you do. I’ll explain what I mean so you be able to be putting on the style.

 

While PowerShell is used by a number of developers its predominantly an administrators tool. Most administrators aren’t taught to code so they pick things up as they go along -  including coding styles.

 

Back when PowerShell first appeared Jeffrey Snover talked about administrators having an ad hoc development methodology. They’d use single cmdlets to get things done. Then progress to using multiple cmdlets in a pipeline. They’d then realise that if they saved that pipeline in a script they wouldn’t have to retype it every time they wanted to use it and so save so time and errors.

 

What happens once you’ve got those first scripts?

 

You’ll realise that scripting enables you to generate tools that make your life easier and that others can also use. By then you’ve probably discovered the PowerShell community and seen what others are doing – so you learn a bit more about coding.

 

You adopt some standards – no aliases in scripts etc., etc. And you think about creating modules of advanced functions.

 

At this point you need to think about your coding style. I’m deliberately separating coding standards from coding style. Standards are what you do – style is how you do it.

 

We’ve used this style concept as the basis of the Iron Scripter competition at PowerShell Summit 2018. To help people divide themselves into teams we have three factions defined - http://ironscripter.us/factions/. The factions split on coding styles as much as anything. You can regard the differences between the factions as philosophical discussions if you prefer.

 

The factions can be summarised as:

  • Daybreak Faction - beautiful code
  • Flawless Faction - flawless code
  • Battle Faction - good enough to get the job done

 

Battle faction is the easiest to understand. You have a solution to your problem. It works and gives the correct result in a reasonable time frame. Job done. Next task. if it breaks at some time in the future you’ll fix it then but in the meantime there’s a stack of other problems to solve.

 

This is the way many administrators work, at least to begin with. Working code doesn’t mean that the code is easy to maintain. If it breaks in the future you may not be the one to fix it – so the code needs to be readable and understandable. Daybreak faction with their view that code should be beautiful take this to the extreme.

 

Ideally, your code shouldn’t break. The idea of flawless code is at the heart of Flawless faction who believe in doing everything possible to ensure that the code will run. Beauty has its place but beautiful code that doesn’t work is wasted time and effort.

 

The three factions are stereotypes and extremes but there is an extremely valid point to them. Imagine an equilateral triangle that has a faction at each point.  Your code will sit somewhere in that triangle with varying influences of battle, flawless and daybreak factions.

 

Does all your code sit at the same place in the triangle? Sometimes good enough will do and you can move on to the next task. Sometimes the code just has to run so you need a lot of flawless influence.

 

All the code you produce doesn’t have to have the same influences but knowing when to be putting on the style – and more importantly which style – could arguably make you a better coder and make your life easier.

A thought for Halloween

Just a quick thought

31 OCT = 25 DEC

Enjoy

PowerShell too big to know

A couple of sentences in the Scripting Guy’s post from yesterday

http://blogs.technet.com/b/heyscriptingguy/archive/2013/09/27/the-powershell-summit-why-you-should-care.aspx

stuck in my mind:

I am not certain I have ever met anyone who knows everything there is to know about Windows PowerShell. In fact, I am not certain I have ever met anyone who knows nearly everything there is to know about Windows PowerShell.

One simple anecdote should put that in context. At the recent PowerShell summit a number of things were demonstrated that had senior members of the PowerShell team saying “I didn’t know you could do that” As an aside similar scenarios played out at the 3 PowerShell Deep Dives in 2011 & 2012.

I’ve been using PowerShell since the early betas for 1.0 & have been an MVP for 6 years and I definitely don’t know everything about PowerShell. I’m learning something new about PowerShell every day.

Think also that it took three of us to write PowerShell in Depth.

There are a whole bunch of modules in Windows 2012 & 2012 R2 I haven’t had time to paly with yet. Add in the PowerShell functionality in SharePoint, Exchange, SQL Server plus all the other Microsoft and third party products and no one can know all there is to know about PowerShell.

One of the great joys of working PowerShell is that there is always something new to learn. Sure, you’re building on what you already know but even the core PowerShell engine can bring surprises.

I’d be highly suspicious of anyone claiming to know everything about PowerShell.

Time for D-CRUD?

I was thinking on the plane back from the PowerShell summit about the CRUD activities. They are a concept we have inherited from the database world:

C = Create

R = Read

U = Update

D= Delete

Create, Update and Delete correspond directly to the PowerShell verbs – New,Set and Remove respectively.

The Read action corresponds to the Get verb.

Well sort of.

Get-* is used in two distinct scenarios.  Firstly we know of an object and we we want to read its properties – for example:

Get-Process -Name powershell

We are reading the information about the PowerShell process. That corresponds directly to the Read action in the CRUD paradigm.

However, we also use Get* when we want to Discover the processes that are running:

Get-Process

In which case we are Discovering the processes that are running.

I think its time to update the CRUD concept and make it DCRUD where D stands for discovery.

Can I? Should I?–examples–legacy scripts

In this post http://msmvps.com/blogs/richardsiddaway/archive/2011/07/17/can-i-should-i.aspx I stated that PowerShell isn’t necessarily the right answer to every problem.

I was left a comment asking if I could expand.  I’ll do that over a series of short posts as I think of examples.

One of the first that comes to mind is legacy scripts.

VBScript never really caught on as a mainstream administration tool. There were a number of reasons for this:

  • non interactive
  • harder to use and debug
  • less information
  • less flexible
  • admins addicted to the GUI
  • less pressure on people i.e. more admins

However, a number of organisations created a significant number of scripts and performed some very clever stuff.

Now, the question for those organisations is this -

“PowerShell has appeared. Do I convert all those scripts, that work really well to PowerShell?”

 

My answer would be no!  Learn PowerShell first . Get really proficient. Develop new stuff in PowerShell and migrate the legacy scripts when they need an over haul (or you get some free timeSurprised smile) that way you get the best of both worlds and run the smallest risk when you come to migrate the legacy scripts.

Can I? Should I?

The question “Can I do X with PowerShell?” comes up very frequently.

PowerShell provides access to a huge range of functionality:

  • .NET
  • COM
  • WMI
  • Microsoft and third party products

Usually the answer is “Yes, you can”

BUT

What doesn’t seem to be considered so often is the question “Should I do X with PowerShell?”

If you don’t have alternatives then by all means try it but if there are better ways to accomplish the task then consider them.

If all you have is PowerShell everything looks like a script