Monthly Archive

Categories

Philosophy

Opposing Automation

Opposing Automation – no I don’t mean that you should oppose it. The sad fact is that there are very many administrators opposed to automation.

 

Within two hours of starting my last job I was told by my team lead “you’ll never automate anything here”. Needless to say our relationship never really worked after that. I ended up in a different team and yes I did automate a lot of stuff.

 

Other all time favourites of mine are:

“We’re too busy to automate”

“We’ve always done it this way”

 

If you meet real roadblocks like this you’ll more than likely end up looking for another job.

 

There are a few things you can try though.

 

In your own work try automating tasks that take a long time and very repetitive for example one company insisted on the event logs being checked for specific events on a regular basis. Now, the idea solution would be a monitoring solution but that means spending money… One solution is to RDP into all the boxes and query the event logs. On the other hand a quick script that remotes into the required servers and checks the logs. Report the date and time of the events by server and you’re done. Better still schedule the task for overnight and you don’t need to do much at all once its set up. Even if you have to create the functionality in chunks its surprising how quickly you can build up to a useful set of utilities. Don’t forget – automate what you need not what the books (including mine) suggest – you’re the one how knows what you need.

 

The other approach that can sometimes work is to find how you can help someone else get something done. Again you may need to build the functionality in chunks but getting other people to sell the benefits of automation will be a big help.

 

However, you approach the problem there will always be people opposed to automation – your only options are to work round them or to move somewhere where your ideas are appreciated. Don’t stay and suffer – its not worth it.

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