Also, as a side note for any die-hard Spectrum fans Manic Miner is actually available to run on your Windows WP7 phones! Enjoy!!!

In the illustration below you can see the high-level design of Script Explorer illustrated. The dotted line in the middle shows the divide between code and repositories that run / exist inside a corporate network vs those outside of the corporate network. One of the most interesting aspects of Script Explorer is something we have called the Aggregation Service. This service takes responsibility for helping us aggregate scripts from different sources based on your requirements. The service is able to take content from any number of repositories, regardless of what protocol they use or what format the scripts are exposed in and then aggregate the functionality and expose that data as an oData based feed.

As you can see in the illustration below there are typically two instances of the Aggregation Service running. The first (on the right-hand side) runs on Windows Azure and is responsible for aggregating feeds from different Internet based repositories such as TechNet or Posh. The second (on the left-hand side) runs along-side Script Explorer and takes responsibility for retrieving scripts from the external aggregation service as well as internal resources such as your local file system and any corporate repositories you want to stand up.

One of questions we have heard is wrt why through the Script Explorer UI have we limited ourselves to just TechNet and Posh repositories – and the good news is that we haven’t. The Aggregation Service includes a standard way to write new providers enabling you to search alternative sources of scripts and have them exposed directly inside Script Explorer simply by changing the configuration file. Another question we hear frequently is why only Bing? To which we obviously respond – why not Bing – what other search engine would you ever want to use! :-) Seriously though, for all you AltaVista or Yahoo fans out there – you can easily create a provider that used a different search engine if you wanted to. Similarly, if you have dedicated hours to posting PowerShell Scripts to your blog and want to enable people to find them – but don’t want to republish all scripts with a schema.org schema (more about this later) describing the Script – then take a stab at writing your own provider – and then share it with other folks. For creating a new repository or creating a new provider take a look at the sample posted on CodePlex. There will be more samples posted there in the coming weeks - plus if you have any questions / requests please make sure to post them there as well.

In my last blog post I promised to provide an overview of the design of Microsoft Script Explorer. Before I do that it is worth spending a little more time talking about our vision for a semantic web focused in and around PowerShell. In very simplistic terms, a semantic web takes the information that is typically hidden inside product documentation, blog posts, support forums and so forth – and enables that information to be defined in a predictable manner – which of course enables discovery of that information. A great example of this is of course a PowerShell Script. Scripts are typically just text hidden inside web pages – and search engines such as Bing / Google and Yahoo can’t discriminate whether a page containing the words “PowerShell Script” is what you are looking for vs pages that actually contain valid PowerShell scripts.

But the semantic web is much more than that. In addition to being able to define types of information, we also want to specify types of relationships between such information. Having found a web page with a PowerShell script on it – there are often any number of other links on the page – some are navigational within the site, some are links to related content and some are advertisements. A lack of clarity around what the links on a page are prevents us from creating great information experiences where we can lead a user from one page to the next in a predictable fashion – either inside a
browser or inside a tool such as the ISE. Ideally we want to be able to take a web page that contains a script supporting a cmdlet such as “get-wmiobject” and inform the user that if they want an “Overview” of WMI click this link, or if they want “Getting Started” guidance click on another link, and if they want more “Examples” of how this cmdlet can be used for managing user accounts then
they should click a third link. It is these explanations of what purpose the serve that will enable richer guidance experiences across information sets.

The Semantic Web has of course been discussed for a long-time now – both as an architectural vision and a variety of implementation techniques showing how to realize this vision. Based on our initial set of requirements we have settled on a set of implementation techniques based on the following combination of standards: oData, HTML 5 Micro-Data and schema.org schemas.

The illustration below attempts to illustrate that PowerShell Scripts can be stored in a number of different places – inside local file systems, network shares, web sites, online forums and script repositories. When the scripts exist inside a web page such as in a blog or a threaded discussion we believe HTML 5’s Micro-Data will enable us to include additional meta-data that will describe the specific parts of the page that contain scripts and information related to the scripts name and purpose that will better enable search. For repositories such as TechNet and POSH we believe oData
provides a great programmatic means of accessing these repositories.

Makes sense at a high-level – correct? But any astute PowerShell repository / blog / forum owner will immediately recognize that very few of these sites have standardized on these technologies – and worse still adoption would require editing and reposting of much of this information. So what can be done in the mean time? The answer is of course Microsoft Script Explorer for Windows PowerShell – and I will use my next blog post to drill into more detail.

For our IT Pro audience this meant recognizing that many of the tasks being performed by IT Pro’s are now being implemented entirely in PowerShell. We also recognized that many of these tasks are similar across organizations – which has led to a number of different script repositories existing on the web – including but not limited to the Microsoft Script Center. After talking with many large customers they recognized the value in these repositories but also wanted to establish internal corporate repositories with scripts and modules that were customized for their organizations and fully trusted for execution within a production environment.

This of course led us to Microsoft® Script Explorer for Windows PowerShell® (Script Explorer). Script Explorer enables you to search for PowerShell scripts on your local computer, your local network and intranet, and of course online script repositories. You are shown available scripts that are organized by category, and  can search for scripts from local and trusted community repositories by applying filters based on focus areas.
Script search results return information about script usage, code samples, and articles about the scripts. When you find the scripts you that you need, you can download and store the scripts and use them at a later time. Script Explorer isn't just about scripts. It also allows you to find other assets such as modules, script snippets (for use in Windows 8 ISE) and even allows you to view how-to guidance topics from Windows PowerShell commands and community resources such as TechNet wiki pages to get started with Windows PowerShell.

Some of the underlying concepts behind Script Explorer derive from the vision of a semantic web – one in which information has meaning– where searching for a PowerShell Script returns only pages that contain
PowerShell scripts – not just pages that contain the words “PowerShell Script”. This approach will enable tools such as Script Explorer to take advantage of that meaning and provide much richer information experiences. In a future blog post I will touch on the underlying design of Script Explorer and how we are embracing a semantic web… but for now please give Script Explorer a test drive. For those fortunate to already be running Windows 8 Beta you will be glad to know it runs on both Windows 7 and Windows 8 Beta.

Download the beta of Microsoft Script Explorer for Windows PowerShell from here and let us know how it helps you. We would really like to hear from you.

Steve has innovated across all three HCI generations:

• CLI - In 1977 when the Apple II was first introduced we were stuck in the CLI paradigm where humans were forced to learn a strict syntax through which we could interact with our computers.
• GUI – In 1984 the GUI was popularized in the Apple Macintosh. The GUI used metaphors such as the desktop and trashcans to make it simpler for users to explore the capabilities of their computer – increasing the accessibility of computers to a much broader audience than the CLI.
• NUI – In 2007 the Apple iPhone was first introduced popularizing a radically new style for users to interact with their Mobile phones. This style was based on multi-touch support and gestures, enabling much more natural interactions with the device – and forcing the phone to have to interpret what the user was requesting using gestures natural to the user – a major departure from the user having to understand how to interact with the device.

Now it is true that Steve Jobs and Apple weren’t the first inventors of any of these technologies, but they were incredibly adept at timing the commercialization of these technologies and gaining broad adoption – something that I believe our industry will miss the most. So rather than pondering what the iPhone 6 would have looked like had Steve been present, I personally believe one of the greatest losses that we may never realize is around the myriad of mundane experiences that we currently take for granted – any number of which Steve could have chosen to breathe new life into. Best wishes to Steve's family, his friends and everyone at Apple.

You can help. Volunteer and collaborate with community to evolve the Windows PowerShell Survival Guide and help improve other survival guides. Here is how:

1. Join the TechNet Wiki. I am sure all of you are already on it, but just in case, head over to the Wiki and user your Live ID to join.
2. By February 5th, review the Windows PowerShell Survival Guide and share your thoughts in the article itself (the article shows you where). Identify missing sections and scenarios. How is it organized? Does it meet the needs of a PowerShell beginner? How about advanced users?
3. Add missing sections that you would like us to flush out - simply by modifying the ToC
4. Participate each week by identifying great (and missing) content around the given theme.
5. Share your feedback and experiences on the wiki itself or just add a comment on this blog post.

Before we talk about the solution let me give you some recent examples that have frustrated me. Just to ensure you don’t think I am trying to say Microsoft is any better / worse than anyone else I have cited a Microsoft example as well.  

-          I recently purchased an iTunes card for my dad for Christmas. We entered the card id exactly as was printed on the card but kept receiving an invalid card error message. It didn’t say why it was invalid or what we should do to resolve the problem – it just said the id was invalid. We went into the Apple store and asked the support person for help. First he tried to get us to call support instead but finally under duress he started the process of getting us a replacement card. During that time I mentioned it was urgent because dad was returning to Australia – at which point he goes “aha” – that is the problem - US cards do not work with Australian iTunes accounts! Why didn’t the error inside iTunes provide this information?

-          Inside Microsoft we have deployed DirectAccess – which is arguably one of the coolest security innovations in years – allowing us to connect to the Microsoft network remotely without having to use our Smart Cards. However, it doesn’t always work. And when it doesn’t work this is the error you receive “Direct Access Connectivity is not working” – nothing to help you understand what the problem is or how to resolve it. The problem is usually caused by recent security patches not having being installed – but not always.

So how do we as an industry resolve this? In my opinion there are two changes that have to occur:

1.       Add a “User Exception Testing” phase to your development lifecycle – As part of code reviews during development we should investigate every single exception that is thrown and triage the user experience as we would any other user interaction. If the user can’t diagnose the error with the information provided then raise a bug. This would have resolved both of the above issues.

2.       Incorporate links to “Live Troubleshooting Guidance” – In some cases there are legitimate reasons why an exception occurs and occasionally it is possible that it isn’t possible to know all problems and solutions during development and so a more flexible solution is required. A good example of our Information Experience team is now resolving this problem is by allowing certain events from within the Event Viewer to link directly to the TechNet Wiki – for example Event ID 100016 redirects to here where Microsoft support and community members can update the content as new problems + solutions are identified.

I would love to hear your thoughts on what needs to occur – plus feel free to use this blog as a way to rant about any specific exceptions that are driving you nuts at the moment.

There are two ways that we need your help:

1. There’s a regular survey: – which this time around primarily about PowerShell. This should take about ten minutes, and will help us better understand the issues you face every day. Whether you are into PowerShell as an IT Professional or, into it as a Power Tool – any information you can provide helps.
2. We would also like you to join our International Customer Advisory Board. This is where you can tell Microsoft what you think about using and troubleshooting our products? The Microsoft Server & Cloud International Customer Advisory Board wants to hear it. Share your opinions and help shape tomorrow’s Windows Server and System Center guidance. See http://msicab.com for more information and mail icabnom@microsoft.com to join.

The recent discussions about Software + Services and Cloud computing have in my mind reemphasized the critical role that patterns play in helping our industry capture proven practices across all disciplines from software architecture, infrastructure architecture through to business architecture. 

Patterns and the “Cloud”

While many people look at cloud computing as a major paradigm shift requiring us to think completely differently about how we design our applications, I like to think of cloud computing as establishing a new set of design requirements (a different context) that requires us to select a different set of patterns than we might have chosen in the past. 

While the solution design may be different, the patterns you draw from and use in this new solution design have for the most part existed for a long time. For example,  many of the patterns that you must now consider when designing a client application that interacts with remote Services provided by third parties with uncertain availability levels have being used for a long time when creating mobile applications where network connectivity could never be guaranteed. 

Two Audiences

Usually it is about this point in any pattern presentation that I can break the room into two groups of people. Those that are rolling their eyes and claiming that patterns are academic and not useful to folks solving real problems where time is off the essence and the other folks claiming quite the opposite. 

Moving forward with this column on SEInsight I am going to attempt to serve both audiences - using this blog to discuss a number of topics relating to creation, evaluation and application of patterns.

We’ll cover patterns from two main perspectives.

Concepts:

• Patterns vs. guidance. Why is a pattern different from other guidance?
• Vision for patterns. Who is this Christopher Alexander guy anyway and what was his vision for patterns and pattern languages
• Resources. Resources on software patterns.
• Best Practices when writing patterns. Hints for pattern authors
• Visual Notation. We’ll cover a a visual notation for patterns and how it’s useful
• Pattern Combination. Combining patterns together to solve systematic issues
• Reference Architectures. The role that reference architectures play prescribing combinations of patterns for specific scenarios

Application of patterns:

• Draft patterns for feedback. Myself and member of my team are going to start posting "draft" patterns for you to review and provide feedback
• Virtual Workshops. We are going to attempt to host some virtual pattern workshops for members of the field / public to participate in
• Pattern use in p&p. Talk about the role that patterns played in the p&p software factories

Why is a pattern different from other forms of guidance?

For this first weeks post I am going to focus on the topic of why a pattern is different from other guidance. This seems extremely timely because there are a large number of books / white papers / guidance hitting the press most of which will confuse the concepts listed below - and leave you no better off when the next major paradigm shift occurs - and leave you feeling like you have to relearn everything you thought you already knew.

When asked what a pattern is the standard answer you will get from a pattern geek is something along these lines:

     "A pattern is a proven solution to a problem, described in context"

As a one liner this is reasonable - but it doesn't really help you understand what the qualities of a pattern are that separate them from other forms of guidance - nor does it help you discern a good pattern from a bad pattern. 

Considerations when Writing and Reviewing Patterns

Here are a couple of considerations that I look for when writing or reviewing patterns.

• Actual Solution. A pattern describes an actual solution to a problem - it isn't just an abstract principle
• Based on Proven experience. The solution is based on proven experience - ie it is something that has been tried, tested and refined over a number of solutions at a number of different organizations
• Platform Independent. The solution is described in a platform independent manner - ie independent of implementation - hence it is durable. This would allow the same logical solution to be considered regardless of what version of a platform you are running on, or potentially even what platform you are running on.
  • Note that the pattern on its own may not be useful to many folks - which is why many pattern guides will have a separate piece of guidance demonstrating how to implement that pattern on a specific platform - thus increasing the relevance and applicability for that pattern.
  • patterns & practices used to call these implementation patterns - I personally think a "How To" style of document is sufficient.
• Include Tradeoffs. Patterns should include architectural tradeoffs that you must consider when selecting the pattern
  • The forces that steer you towards using the pattern or away from using the pattern
  • Benefits and considerations that you must consider if you do apply the pattern
  • Relationships to other patterns that might be good substitutes or might well be used in addition to this pattern
• Atomic. Patterns are also typically atomic - following the Single Responsibility principle. If you see a pattern solving a number of problems it is usually a sign that the pattern should have been split into multiple patterns.
• Named. And of course the pattern has a name, that if well thought out will establish a vocabulary for our industry.

Getting Feedback – “WorkShopping” Process

Now there is one last and very important point that separates a pattern from any other content and that is the work shopping process that a pattern should go through before publication. In short a pattern workshop is a usability study whereby a pattern author must silently observe (as if behind a one way mirror) a group of peers walking through the draft of a pattern - listening as their peers attempt to reconcile the description of the pattern statement, the solution and associated tradeoffs against their own experience.

Having been through this process a number of times it is amazing how you as an author might think you have captured the perfect pattern - something that is so elegant that it will surely have the same timeliness as famous patterns such as the Model View Controller pattern has - but as you observe your peers struggling to get past the introduction content you soon realize that many assumptions that you have made don't resonate with your peers.

Learn More

If you are interested in learning more about running a pattern writers workshop or in reading more about what the characteristics of a good pattern are take a look at these invaluable resources from the Hillside Group.

Anyway - that’s it for this week. As we progress I am also interested in linking out to patterns that you may be writing and generating discussion. Feel free to post links to your patterns on this blog or email me at jason.hogg(at)microsoft.com.

Patterns Guides

Here is a quick run down on some pattern guides which I refer to constantly. I have tried to provide a cross section of a number of domains so hopefully there is something for everyone in here. I haven't included links but let me know if you have problems finding any and I will post the links...

• Design Patterns: Elements of Reusable Object-Oriented Software - The original...
• Patterns of Software Architecture - Volumes 1 - 5 - Focus in topics such as Architectural Patterns, Patterns for Concurrent Systems, Patterns for Resource Management and Patterns of Distributed Computing
• Enterprise Patterns by Fowler
• Integration Patterns by Hohpe
• Integration Patterns by Trowbridge
• SOA Patterns
• Web Service Security Patterns by Hogg et al (couldn't resist)
• Designing Social Interfaces - Principles and Patterns
• Workflow Patterns
• Ajax Patterns
• Design Patterns in Communications Software
• and the list goes on...