Although Don gives people with a programming background permission to just skip Chapter 6 I got intrigued by the title "Objects: data by just another name". My programming experience grew from getting frustrated with the limitations of scripting. Seeing things from others perspectives is always interesting because it can help me find new ways to avoid limitations. Here, the title alone made me realize something rather self-evident: objects are just data by another name. "Yeah, I read that." you may be thinking, Why are you highlighting it?" Objects had always been a little mysterious to me. When I started using PowerShell I felt I found a secret passageway into the world of .NET because I could poke around under the black box. Here I see "objects"-as in object oriented programming-are really fancy labels for data. This may sound trivial, but, when the title of a chapter alone gives me a breakthrough of sorts I get thrilled.In Section 6.1 Don gives a good practical way to start thinking about what objects are and contain. What is key to realize, or, at least was for me, is that when you are working with PowerShell, it is object oriented. The contrasting example from the Unix/bash/batch/cmd perspective is that PowerShell does not deal in text, but, rather, in data and objects. This is a big deal. In other shells a ton of time is spent finding ways to manipulate text as if it is objects. That is a beauty (and curse) of those shell (and systems): everything is a file. PowerShell deftly sidesteps this problem before it ever even arises. Having written some cmd batch scripts that look like something aliens would struggle to understand I am immensely appreciative for PowerShells objects and their simplicity.The major things to know about objects are broken down in key sections: objects have properties that describe it (6.4) and methods to take action on or with it (6.5). Collectively, these are called members. What is great about members is how much they can tell you about an object. PowerShell, like other .NET languages, is self-describing. When you look at an object the right way it can tell you all about itself through its members. Many folks who get deep into PowerShell eventually seem to end up loving the Get-Member cmdlet mentioned in Section 6.3 as a favorite. Want to know about any object? Fine, just ask it to tell you its story with Get-Member. In other languages you have to know what things are before you start working with them. In PowerShell it is just so easy: simply ask.In sections 6.6 and 6.7 talk about two cmdlets: Sort and Select. Sort is handy. For me-and, in what I do (data extraction and manipulation)-Select is king. In the examples in the book, I feel like I was teased a bit, just because I have worked so extensively with this cmdlet it deserves a chapter unto itself almost. I know these sorts of things will be expanded upon in later chapters, but, just seeing something simple, like the ability to sort, as shown in the DVD on a property, or, how to select begins to give glimpses of the things that can be done.One great tip given in the Sorting video was seeing a practical use of Get-Member and Sort together. To me, Get-Member is an exploratory tool. With it I get objects to tell their story. To belabor the point a bit, keep in mind: when you start hearing the story remember you are dealing with objects and their members. These are objects for the entire life of a pipeline until you make them something else (I am thinking specifically of text). The PowersShell story is like any good tale: it has a beginning, middle and end. And in every part the key characters are objects. When I started looking at PowerShell this way I got a much richer tale every time I used it.
Tuesday, July 26, 2016
Don Jones Month of Lunches Day 6
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment