Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements


jsnover jsnover

Niner since 2004

  • Scott Hanselman & Jeffrey Snover Discuss Windows PowerShell

    Thanks for the thoughtful feedback - it was precise and helpful.

    > 1. Consistency: Powershell was built to be consistent and yet object property names are often not. The process object uses processname but company not companyname, i.e. some properties have name in them and some don't. This happens with many objects and not only that. It seems to me that object properties could be made more consistent.

    Absolutely correct.  While .NET is substantially more consistent than previous efforts, it still has inconsistencies such as this.  This is one of the reasons that PowerShell extends the .NET type system.  Look what happens when you ask for the names on Processes:

    PS> get-process |Get-Member *Name*

       TypeName: System.Diagnostics.Process

    Name            MemberType    Definition
    ----            ----------    ----------
    Name            AliasProperty Name = ProcessName
    ProcessName     Property      System.String ProcessName ...

    We have produced a property alias which maps Name to ProcessName.  This allows us to address the inconsistencies of .NET.  As a user, you can take advantage of this feature yourself adding additional properties, methods, etc to objects and object types.  It is an incredibly powerful aspect of PowerShell.

    > 2. What you think you type? Think again. Powershell was built to simplify management by the use of a set of similarly named objects using a verb-noun pattern. And yet in Powershell many management tasks require using WMI and COM and etc which is a mess and not at all "what you think is what you get". If WMI is needed for everything, then we lose the easy syntax of Powershell.
    This is a coverage issue.  Cmdlets represent the best user experience but we knew that it would take years before we had complete coverage.  We decided to provide access to things like COM, WMI, ADSI, .NET, etc even though they did not provide the level of abstarction we wanted to provide our users.  What they do is 1) ensure that you can always do what you need to do and 2) allows you to create the right level of abstractions for others using Scripts.

    > 3. COM clean-up: Create a COM object in Powershell such as Internet Explorer or Word. How do you clean it up. The COM reference is not released and setting the variable equal to $NULL does not change anything
    Setting it to $NULL deferences it but the object will continue to exist until the garbage collector (GC) disposes it.  You can control this yourself but as a general rule, it is best to let the GC handle it.

    > 4. Language documentation is not adequate: When do you use square brackets and when round ones in variables? When a comma, etc? Why does where require a script block? Why was the pipeline object named $_ which is difficult to type instead of $$ which would have been easier? Why do I need to specify $_ in a where script block anyway? Can't it be assumed? And many more. There are many language design questions are not answered in the documentation and some language featured are not clearly explained.
    Yup.  There are a number of books now available on PowerShell that fill this gap.  Bruce Payette, the developement lead on the language, as a great book focused on the language coming out this month.  It is called PowerShell In Action. 

    Jeffrey Snover [MSFT]
    Windows PowerShell/MMC Architect
    Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
    Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

  • Scott Hanselman & Jeffrey Snover Discuss Windows PowerShell

    > How is he doing this {}.RemoteInvoke("string") thing?

    In PowerShell, you can add methods or properties to any object or object type.   You can see how this works by doing the following:

    PS> notepad $pshome/types.ps1xml

    This is an XML file that gets loaded upon PowerShell startup.  You can create your own file and import your extensions using the Update-TypeData cmdlet.

    Scott created a file which added the RemoteInvoke() method on the ScriptBlock type so when you include his stuff, every scriptblock now as this method.  When you call it, PowerShell dispatches the method to his code which implements the function.  

    This is one of the most powerful features of PowerShell.

    Jeffrey Snover [MSFT]
    Windows PowerShell/MMC Architect
    Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
    Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
  • Managing IIS 7 with Windows PowerShell

    <Did you noticed that Bill mentioned that we could get greater throughput but that the network was throttled?> 

    When I did the demo in the keynote we thought we had a problem because after I turned on IIS7 output caching - the CPU stayed at 100%. 

    Now doing a keynote demo - you can't have any glitches and having things break the day before the event - is a VERY VERY bad thing.  So there I am looking at my keynote demo not working before my very eyes. 

    I ran off and was examining the code looking for flaws.   I couldn't find any so I tried to enable caching a few more times and nothing worked.  I was starting to feel a little ill when I looked up at the gauges and noticed that they were ALSO BROKEN.   Things were getting WORSE. 

    Instead of showing 400+ Requests per second, the gauges were showing about 3000.  Arrrgggg!   I started trolling the system to see what was broken when it suddenly dawned on me that maybe the data was correct.  At the show, I had an isolated network so what was happening was that the stress machine just zoomed and the servers had REALLY gone from 24 to 3000 RPS - over 100x improvement.  Awesome  - truly awesome.  It is incredible to have an improvement soooo dramatic that you think your instrumenation is broken!

    BTW - that is why the demo is different in the keynote address - it wasn't interesting to show CPUs stay at 100%.  Smiley 

    Jeffrey Snover [MSFT]
    Windows PowerShell/MMC Architect
    Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
    Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

  • Jeffrey Snover - More talking about Monad

    We'll ship in 2006.  I'd put my money on "before Vista" but much of that will be determined by the overhead of the process to get out the door.
  • Jeffrey Snover - More talking about Monad

    Here is a pointer to the Marc van Orsouw's (aka /\/\o\/\/ )  blog.  He is the guy I mentioned in the Video.  He is doing some very noteworthy stuff with Monad.


  • Jeffrey Snover - More talking about Monad

    However what left me shocked with this video is how much weight did Snover loose  I should do some workout myself I think...

    Its amazing what a couple hundred hours in the gym will do for you.


  • Jeffrey Snover - Monad demonstrated

    tigerfeat wrote:
    Great stuff, but unless I missed something you didnt talk about managing another machine on the network as opposed to just your own local machine. It would be great to have a demo of that too... The kind of thing I'm thinking of is logging out those people who have forgotten to log out or shutting down certain processes right across a network, or something even more cool that I've not yet thought of but that you will no doubt be able to demonstrate!

    At this point, the only way I can demo the remoting stuff is with hand puppets.  Smiley

    It's going to be great but we just don't have the code to show it right now. 

    We'll be leveraging the WS-Management protocol to do remote management. What that means is that you'll be able to use the same protocol and cmdlets to manage the Pre-OS environment of your servers (once they have a WS-Management compliant MB-Controller [which the HW guys are developing]) and your OS-Present environment.

  • Jeffrey Snover - Monad explained

    mlauzon wrote:
    Does anyone have a screenshot of Monad in action, seeing as how there are a few people already lucky enough to be beta testing it?!

    There will be a demo video posted soon.
  • Jeffrey Snover - Monad explained

    >Is there a solution for automation that doesn't require the command line?
    Yup.  Cmdlets are .NET classes which are hosted by Monad.  Monad then surfaces that class as a Command line interface, an API, and eventually a WS-Management Web Service.

    We surface the cmdlets as an API for management applications and to support rich GUIs. Both of these need very low latency access.