Why would a team and/or organization want an external coach? In previous Daily Process Thoughts we have discussed the attributes of a good coach  and what a coach delivers, all of which may have whetted your whistle. However, it doesn’t answer the question why you would seek out an external coach. An external coach brings new ideas to the table, different perspectives and a shot of energy.

Software development in general, and Agile specifically, is evolving a rapid pace. New techniques and concepts are developed, vetted and deployed across the globe. Some of those ideas may work for your organization, but if you don’t know they exist you can’t try them. External coaches, the hiney bees of agile, are a conduit for new ideas to be introduced into a team or organization. I am using the metaphor of a bumblebee to relecect the itinerant nature of coaches  (Coaching techniques used: training and mentoring).

Teams and projects get stuck. Enter the external coach, who can provide a different perspective and to help define a path forward. Often the ability to see a problem or situation with a fresh set of eyes is all that is needed to identify new options or solutions. (Coaching techniques used: cajoling, arbitrating and mentoring).

After teams or organizations implement Agile (or any major development framework), and have begun to accrue the benefits of the implementation, it is easy to relax and get complacent. Complacency is dangerous. An external coach can provide a fresh shot of energy that can keep the transformation moving. (Coaching techniques used: consulting and mentoring.)

Why would you invest in an external coach? External coaches bring new ideas, perspectives and energy into the mix to keep teams and organizations moving forward. As soon as you stop moving forward entropy will set in, and effectiveness and efficiency will suffer.

Just finished speaking at the delightful Cloud East Conference in Cambridge, England! Glad to say that my velociraptor slide went over well. Bridget and I have been visiting customers in London and Brighton, and are going to Berlin on Monday for DevOps Day! If you’re there, be sure to say hi! The intrepid Kevin Holler and inimitable Slava will also be in attendance.

--Tasha Drew, Product Manager

Engineering Updates

We have a couple fun and useful items in our early access phase! If you go to the dashboard, and from the menu select Tools >> Early Access, you will now find Application Takeover Preference and Ruby 2.0.

Application takeover preference allows you to easily set how you want our automated application takeovers to occur, in case our default behavior isn’t working for you.  Once enabled, you can go to “Edit Environment,” and you will see a new dropdown:

So if you’ve been having any trouble with your specific customizations not booting properly when we are automatically handling application takeover, you can select to instead boot from a new volume; have a takeover occur, but without booting a new application slave to replace the one being promoted; or disable the feature entirely.

As with all our early access features, we would be delighted if you shared your thoughts on these as you use them. Need something additional? Anything not working correctly? Documentation confusing? Love it and want to let us know? Tell us any and everything at our Early Access Forum!

And, also in early access, we have big news for our Rubyists: Engine Yard now has Ruby 2.0! We’ve had Rails 4 for a while now if you want to try them together. The full featured Ruby 2.0 integration in the UI, etc., is still getting some work done, so for now the installation instructions have some unique steps (i.e. not through the dashboard). See our docs for all the details!

Data Data Data

As we continue to enhance our new cluster model, we are in the planning phase for upcoming new data stacks! One of our top priorities is our mySQL database stack and how to make it more awesome as it takes advantage of the new data model. We are in the early stages of re-productizing it, so if you have any wish lists of things you’d like to see from our mySQL offering, please let us know in the feature request forums!

Social Calendar (Come say hi!)

Monday May 27th - Tuesday May 28th: Engine Yard will be participating as a sponsor of DevOps Day Berlin! Kevin Holler will be delivering a 5 minute talk about Engine Yard Cloud, and Tasha Drew and Bridget Gleason will cheer him on from the audience.

Wednesday May 29th: Our Portland office will be hosting the weekly Coder Dojo PDX!

Thursday May 30th: Engine Yard's Dublin office is host to another addition of Node.js Dublin, featuring Dominykas Blyžė, Daniel McKay, and Isaac Schlueter.  Pizza and beer will be served!

Saturday June 1st: Engine Yard Dublin will host an IXDA Prototyping workshop. In this workshop you will learn how to create wireframes and interactive prototypes using the popular tool Axure RP.

Articles of Interest 

Cern launched a public appeal to find the world’s oldest webpage, and this is what they found.

What would the Games of Thrones characters look like if the show was staged in the 1990’s? Now we know.

The post May 24, 2013: This Week at Engine Yard appeared first on Engine Yard Developer Blog.

Alex Russell posted some thoughts today about how he wishes the W3C would architect the next version of the Content Security Policy.

I agree with Alex that designing CSP as a “library” that uses other browser primitives would increase its long-term utility and make it compose better with other platform features.

Alex is advocating the use of extensible web principles in the design of this API, and I wholeheartedly support his approach.

Background

You can skip this section if you already understand CSP.

For the uninitiated, Content Security Policy is a feature that allows web sites to opt into stricter security than what the web platform offers by default. For example, it can restrict which domains to execute scripts from, prevent inline scripts from running altogether, and control which domains the network stack is allowed to make HTTP requests to.

To opt into stricter security using the current version of CSP, a website includes a new header (Content-Security-Policy) which can contain a number of directives.

For example, in order to prevent the browser from making any network requests to cross-domain resources, a server can return this header:

Content-Security-Policy: default-src 'self'

This instructs the browser to restrict all network requests to the current domain. This includes images, stylesheets, and fonts. Essentially, this means that scripts run on your page will be unable to send data to third-party domains, which is a common source of security vulnerabilities.

If you want to allow the browser to make requests to its own domain, plus the Google Ajax CDN, your server can do this:

Content-Security-Policy: default-src 'self' ajax.googleapis.com

Factoring the Network Layer

If you look at what CSP is doing, it’s essentially a syntax for controlling what the network stack is allowed to do.

There are other parts of the web platform that likewise control the network stack, and more all the time. What you’d like is for all of these features to be defined in terms of some lower-level primitive—ideally, one that was also exposed to JavaScript itself for more fine-grained, programmatic tweaks.

Imagine that you had the ability to intercept network requests programmatically, and decide whether to allow the request to continue. You might have an API something like this:

var origin = window.location.origin;
 
page.addEventListener('fetch', function(e) {
  var url = e.request.url;
  if (origin !== url.origin) {
    // block the network request
    e.preventDefault();
  }
 
  // otherwise, allow the network request through
});

You would then be able to describe how the browser interprets CSP in terms of this primitive API.

You could even imagine writing a CSP library purely in JavaScript!

page.addEventListener('fetch', function(e) {
  if (e.type === 'navigate') {
    e.respondWith(networkFetch(url).then(function(response) {
      // extract CSP headers and associate them with e.window.id
      // this is a pseudo-API to keep the implementation simple
      CSP.setup(e.window.id, response);
 
      return response;
    });
  } else {
    if (!CSP.isAllowed(e.window.id, e.request)) {
      e.preventDefault();
    }
  }
});

The semantics of CSP itself can be expressed in pure JavaScript, so these primitives are enough to build the entire system ourselves!

I have to confess, I’ve been hiding something from you. There is already a proposal to provide exactly these network layer hooks. It even has exactly the API I showed above.

The Extensible Web

Extensible web principles give us a very simple path forward.

Continue iterating on the declarative form of the Content Security Policy, but describe it in terms of the same primitives that power the Navigation Controller proposal.

When web developers want to tweak or extend the built-in security features, they can write a library that intercepts requests and applies tweaks to the policy by extending the existing header syntax.

If all goes well, those extensions will feed into the next iteration of CSP, giving us a clean way to let platform users inform the next generation of the platform.

This approach also improves the likelihood that other features that involve the network stack will compose well with CSP, since they will also be written in terms of this lower level primitive.

Many of the benefits that Dave Herman outlined in the closing of my last post are brought into concrete terms in this example.

I hope to write more posts that explore how extensible web principles apply to platform APIs, both new and old.

Fellow web developers, let’s persuade Adam Barth, Dan Veditz, Mike West (the CSP specification editors) to factor the next version of CSP in terms of the new Navigation Controller specification.

Then, we will have the tools we need to extend the web’s security model forward.

addthis_url = 'http%3A%2F%2Fyehudakatz.com%2F2013%2F05%2F24%2Fan-extensible-approach-to-browser-security-policy%2F'; addthis_title = 'An+Extensible+Approach+to+Browser+Security+Policy'; addthis_pub = '';

By Scott Knaster, Google Developers Blog Editor

On Fridaygram we love to celebrate amazing new Street View images. This week we announced new panoramic views of the Galapagos Islands, collected with with the Street View Trekker in partnership with the Charles Darwin Foundation (CDF) and the Galapagos National Parks Directorate (GNPD). These images will go live on Google Maps later this year, but you can see a preview below and on the Official Google Blog.


The Maps team’s 10-day adventure included lots of interaction with local wildlife, but didn’t take place entirely on land. The team worked with the Catlin Seaview Survey to collect underwater ocean images too. And in addition to being beautiful and fun, these pictures have a practical use: they act as a visual record that can be compared to changes observed in the future.

Speaking of wildlife, do you have a smart dog? And does your smart dog know 1000+ words, plus have a basic comprehension of grammar? Meet Chaser, a 9-year-old border collie who has been taught to recognize the names of 1000 objects, as well as the meaning of some verbs and prepositions. In tests, Chaser correctly (most of the time) responded to commands such as “take ball to Frisbee”, or even “to Frisbee take ball”. If only our friends and family were that helpful.

Finally, there’s some typically mind-blowing news from the world of quantum physics. We already know that quantum particles can share a connection called entanglement, which allows one particle to reflect the state of another no matter how far apart they are. Now an experimental discovery shows that particles can be entangled even if they don’t exist at the same time. We agree with experimenter Jeremy O'Brien of the University of Bristol, who said “It’s really cool”.


Fridaygram is about randomly cool and nerdy stories that we hope will amuse you and possibly inspire your weekend. Around here we’re still feeling the Google I/O afterglow, so we’re going to recommend you spend some time this weekend watching some of the many session videos from I/O. If that’s not your thing, maybe you’d like this brief but inspiring video that kicked off the conference.

Hey, it's HighScalability time:

(Scaling the Mighty Redwood photograph by Michael Nichols for NatGEO)

 

• ~20K : Netflix AWS instances; 100 million hours per minute: Youtube video upload;
• Quotable Quotes:
  • @sw17ch: Computer Science is thinking about thinking. Software Engineering is thinking about how to avoid thinking.
  • @neha: I am starting a distributed systems reading group at MIT. Suggestions on papers to read? Current list here.
  • John Sheehan: Services are the new process
  • @cheeseplus: Sharding isn’t a scalability strategy, it’s a failure mode in progress.
  • @basharatw: @adrianco Features in days, not months; hw in mins not weeks; incident response in secs not hours … there's a trade off for utopia #gluecon
  • @mgroeninger: @johnsheehan now telling a story about struggling against tools... quit to build a better hammer #gluecon < this is the heart of devops
  • @aneel: "you really have to do a reorg to do devops and you really have to do a reorg to do cloud-native" - @adrianco #gluecon
  • @voodoogeek: scalability. why is it so hard to understand? and please please do NOT tell me it was not foreseeable and the usual BS.
  • @joestump: Celery's queue routing key stuff is pretty swanky. If you don't need low latency messaging, highly recommend celery + SQS. 0 maintenance.


• There are more kinds of programming in heaven and earth than are dreamt of in your data structure books...Cell-Based Computing Goes Analog: designing circuits in Escherichia coli that could perform functions based on a range of inputs, much like the temperature gauge on a thermostat. Specifically, the circuits were sensitive to levels of sugar arabinose or acyl homoserine lactone.


• Startups are the new intentional communities attempting to do right by hacking human nature and founding a utopia. To see this in action take a look at Why I Spent 200 Hours Writing Culture Code Instead of Python Code. A Walden 3.0?


• Horst Simon on Why we need Exascale and why we won’t get there by 2020: You could say that the end of the HPC world as we know it began in 2004, when we hit the inflection point of power use and clock speed. That’s when we realized that we could not keep increasing clock speed due to power demands (and heat), but needed to move to much greater parallelism. In “new” HPC, power is the primary design constraint for future HPC system design; data movement dominates costs, so we need to optimize to minimize data movement; to increase concurrency we look to exponential growth of parallelism within chips. This “new” reality fundamentally breaks our current programming paradigm and computing ecosystem.

Don't miss all that the Internet has to say on Scalability, click below and become eventually consistent with all scalability knowledge...

I truly love my Nest thermostat. I had a thermostat that was supposed to be internet connected, however, it never worked. It was associated with a static IP address and I always had to flip the breaker to get it to work. I was once in Chicago, wanted to turn my A/C on to a comfortable level so that when I got home my home would be nice and cool and I could get to bed. Unfortunately, that was also a day when my thermostat at the time decided that it didn’t want to be accessed through its IP address. (Yes, inanimate objects can make these types of conscious decisions!)

Then came the Nest thermostat. I got it as a gift from my family and I installed it immediately when I got home. The installation was a breeze! I’m not an electrical engineer but I was able to label the wires and put them in the right spots for this new thermostat and finish my installation in 20 minutes (time included to remove the old thermostat from the wall).  The best thing about this thermostat is that it does what it states it should: online management. A big part of the Nest marketing is helping residents cut their electrical bill by having better heat and A/C management. Although I don’t really see that side, I love that I can control it at will through my iPhone, it learns my habits, and the wall system itself is intuitive and easy to use. No more all sorts of buttons and directions that no one can follow in order to program your thermostat. After a month or so of using it, I started raving about it to my friends and family. (By the way, neither I or Seilevel is paid to review this product.)

All Product Managers want to develop products that have a cult-like following. The challenge with Nest will be how they figure out how to get a continuous stream of revenue. Apple does it through updating software which forces people to buy the new phone with the upgraded components. Will Nest do the same? My thermostat works and all I need it to do is manage my home’s temperature. What feature could they develop which would make me want to update the software which would force me to upgrade the product? Most homeowners don’t replace thermostats, or other home appliances, unless their current ones are broken. I’m in this boat. I’m not planning to buy another Nest unless this one breaks (and if it does so within the next couple years, I would be disappointed and potentially go to another brand).

Does anyone have a Nest thermostat? If so, do you like it?

 

Nest thermostat is my favorite product is a post from: http://requirements.seilevel.com/blog

Getting the latest code from all workspaces can be time consuming, forgetting to do so can cause bigger issues…

So, here is the remedy:

There is a hard coded “d” drive to change the drive and navigate to the code source folders. If your code is on c drive you can just remove it…

************************************************

************************************************

I think it will be handy if it has more error handling as a report at the end, but for a quick solution, it is available…

How many legs does a dog have if you call the tail a leg? Four. Calling a tail a leg doesn't make it a leg
- Abraham Lincoln

The notion that we can rename things and then assume they are the same doesn't work, just like Lincoln said. The notion of measuring progress with the passage of time and calling it Earned Value, doesn't mean we're doing Earned Value.

Doing Agile without doing Scrum, XP, Crystal, or DSDM is not doing agile.

I was recently reading an article written by Henry Winter where he mentioned some of the ideas that Sir ALex Ferguson has been covering in some interviews he’s been doing at Harvard and one bit stood out for me:

In a series of interviews in Harvard, Ferguson debated dealing with “fragile” egos in the dressing room, the power of the two simple words “well done” in motivating individuals and the importance of criticising players’ mistakes immediately after the match and then moving on.

I’ve written previously about giving feedback and I think we don’t place enough emphasis on how useful it is to give any feedback close to the time of the event.

My former colleague Ryan Greenhall was particularly good at noticing situations where timely feedback was required and I hadn’t realised how much of an impact doing that had.

As we as the immediate benefit of the event being fresh in people’s minds when they’re talking about it we get an added benefit as well.

The more time that we leave between an event happening and reflecting on it, the more time there is for us to invent a story about what happened that helps to explain it.

In the story we create in our mind we’ll often associate negative traits/motives to the other person and exaggerate the importance of what happened until it doesn’t resemble what actually happened any more.

I tended to veer away from addressing things like this immediately because I thought it seemed like overreacting to believe that it was worth having a conversation but it now seems worthwhile.

In the worst case you just discover there was nothing to reflect on and in the best case you resolve any issues at the source.

By now you’ve heard that Engine Yard is proudly presenting our inaugural developer conference, Distill, on August 8-9. In addition to a lovely Treasure Island venue and a stellar lineup of speakers, we will also be throwing a kickoff party the likes of which you’ve never seen.

In keeping with the theme of distillation, which during the daytime events means learning, best practices and collaboration, we’ve dubbed the sure-to-be-awesome kick-off soiree “Moonshine”  as a nod to the tasty beverages we’ll be providing for you all. World-class DJs will kick out the jams as you enjoy our distillation-themed smorgasboard of hors d'oeuvres and the company of your fellow conference-goers. Throughout the evening, we’ll also be doing a few surprise giveaways (and if you know Engine Yard, you know that we don’t disappoint!)

Moonshine will take place at the Old Mint in San Francisco. We want to thank our partner New Relic for sponsoring. If you haven’t purchased your ticket for Distill yet, hurry and grab your First Batch (early bird discounted) ticket! Tickets will be increasing in cost from $400 to $500 on June 1.

Ernst & Young recently “discovered” that employees will resort to corruption and fraud when they are squeezed by management. Or, in other words, when you treat them unethically they will behave unethically.

Surprise, surprise!

It is hard to count the number of similar discoveries people have made over time. Patrick Hoverstadt, author of The Fractal Organization, wrote that Theory-X managers get constant feedback that their world-view is correct. They treat employees as people who cannot be trusted. Et voilà, the result is indeed that nobody can be trusted! You get what you measure! (Goodheart’s Law). Ralph Stacey, author of Complexity and Management, called it reflexivity. There is no objective observer.

The observer influences the system, and the system influences the observer.

This makes it all the more strange that some complexity thinkers aim to provide a framework for dealing with different kinds of systems. If the observer judges the system to be “complicated” then he should apply “Sense-Analyze-Respond”, and if the observer thinks the system is “complex” then she should use “Probe-Sense-Respond”.

Sorry, but that just doesn’t make much sense to me when I take into account reflexivity and the influence of observers. Because maybe, when I treat a complex system as simple, this is exactly how it will behave to me. Or when I judge the system to be chaotic, this could indeed be how it will respond, but only because that's how I treat it. The way I treat the system will influence how it behaves. The observer influences the system. For example, why bother deciding if the behavior of a system is chaotic? Simply the act of ignoring chaos could make it go away! Problem solved. (It could also blow up in your face. You just can’t predict the cascading effects of your actions.)

It’s much easier just to assume complexity everywhere.

You can always reduce the universe to a few domains or categories later. When you have time, over a cup of coffee. With a delicious slice of Welsh tea cake, as I just enjoyed.

(image by Jonathan Lidbeck)

 

Distributed transactions are costly because they use agreement protocols. Calvin says, surprisingly, that using a deterministic database allows you to avoid the use of agreement protocols. The approach is to use a deterministic transaction layer that does all the hard work before acquiring locks and the beginning of transaction execution. Overview: Many distributed storage systems achieve high data access throughput via partitioning and replication, each system with its own advantages and tradeoffs. In order to achieve high scalability, however, today’s systems generally reduce transactional support, disallowing single transactions from spanning multiple partitions. Calvin is a practical transaction scheduling and data replication layer that uses a deterministic ordering guarantee to significantly reduce the normally prohibitive contention costs associated with distributed transactions. Unlike previous deterministic database system prototypes, Calvin supports disk-based storage, scales near-linearly on a cluster of commodity machines, and has no single point of failure. By replicating transaction inputs rather than effects, Calvin is also able to support multiple consistency levels—including Paxos based strong consistency across geographically distant replicas—at no cost to transactional throughput.

If you are interested Daniel Abadi gives a very accessible overview of Calvin in If all these new DBMS technologies are so scalable, why are Oracle and DB2 still on top of TPC-C? A roadmap to end their dominance.

For the past five years, Microsoft has been working with a diverse group of companies to develop the Advanced Message Queuing Protocol (AMQP) standard. The group of 20+ companies consisted of tech vendors, including Red Hat and VMware, and enterprises like JPMorgan Chase and Credit Suisse. The goal has been to build an open, wire-level protocol standard for messaging that enables easy interoperability between different vendor products. Back in October 2012, the OASIS standards organization announced the approval of AMQP 1.0 as an OASIS Standard and, on the same day, we released a preview implementation of it with Windows Azure Service Bus.

Today, I’m pleased to announce that AMQP 1.0 support in Windows Azure Service Bus has been released as a general availability (GA) feature – and it is ready for production use, and backed by an enterprise SLA.

Interoperable Messaging

This release is a big deal. With support for AMQP 1.0, you can now use Windows Azure Service Bus to build applications using a variety of messaging libraries written using different languages and running on different operating systems – that can now all communicate using an efficient, binary, wire-level protocol.

Because AMQP 1.0 defines a portable data representation, it means that a message sent to Service Bus from a .NET program can be read from a Java program or Python/Ruby/PHP script without losing any of the structure or content of the message. For Java, the standard Java Message Service (JMS) API is supported so it’s straightforward to port an existing Java application to Service Bus from any another JMS provider.

The end result is really powerful middleware that can be used to build distributed systems, and glue together applications that span on-premises/cloud environments or run across multiple cloud providers.

Walkthrough of How to Build a Pub/Sub Solution using AMQP

To highlight how easy it is to use this new messaging support, I’m going to walkthrough how to create a simple .NET console app that sends messages using a publish/subscribe messaging pattern to receiver apps written in Java, Python and PHP.  The Windows Azure Service Bus now provides all of the pub/sub messaging support necessary to facilitate this using the open AMQP protocol and existing messaging frameworks.

The .NET sender app will post the messages to a Service Bus “Topic” – which is a durable messaging intermediary.  Unlike Queues, where each message to a Queue is processed by a single consumer app, Topics provide a one-to-many form of communication using a publish/subscribe pattern.  It is possible to register multiple subscriptions to a topic – and when a message is sent to the topic, it is then made available to each subscription to handle/process independently.

You can think of each subscription as a virtual durable queue that receives copies of the messages that were sent to the topic. You can then optionally register filter rules for a topic on a per-subscription basis, which allows you to filter/restrict which messages to a topic are received by which topic subscriptions.  This enable you to scale to process a very large number of messages across a very large number of users and applications.

 

For this scenario we are going to have the .NET console app post messages to a “scottmessages” topic, and then setup separate subscriptions for three app listeners – one written in Java, Python and PHP – to receive and process the messages.

Step 1: Create a Service Bus Topic and 3 Subscriptions

Our first step will be to create a Service Bus Topic using the Windows Azure portal. 

We’ll create a Topic named “scottmessages” in a “scottgu-ns” namespace.  The Windows Azure Management Portal makes this easy to do – just click the New button and navigate to the App Services->Service Bus->Topic->Quick Create option (you can also create this programmatically and from the command-line):

Once the “scottmessages” topic is created, we can drill into it to see a familiar Windows Azure dashboard monitoring view of it:

We’ll then create three subscriptions for the Topic – one for each of our app listeners.  We’ll name these “java”, “python”, and “php” to correspond to the language that each app is written in (note: we could name them whatever we wanted to – I am using these names just to make it clearer which maps to which). We can do this programmatically, or by clicking the “Create Subscription” button in the portal command bar.  This will launch a dialog that allows us to name the subscription we want to create:

The second screen of the dialog allows us to set custom subscription properties like the default message time to live (how long it will remain queued before being deleted), lock and session settings, etc:

Clicking the ok button will create a subscription for our Topic.  We’ll can then repeat this step to create two more subscriptions so that we have all three we want:

After we’ve done this, whenever a message is posted to the “scottmessages” topic it will be durably queued for each subscription.  Durably queued means that a consumer app doesn’t need to be actively listening on the subscription at the time the message is posted.  The message will be automatically queued up for the subscriber app to process whenever they connect later.  This enables a very robust, loosely coupled application architecture that allows you to scale the processing of a large number of messages across a very large number of users and applications.

Step 2: Writing the .NET Sender App

Now that we have the Service Bus Topic and Subscriptions created, we’ll write a simple .NET program to send messages to the Topic.

The AMQP support is Service Bus is available in the latest version of the Service Bus .NET client library which you can retrieve via NuGet - http://nuget.org/packages/WindowsAzure.ServiceBus/. Version 2.1.0 or later is required.  Just type “Install Package WindowsAzure.ServiceBus” to download and add it to your .NET application.

The code below is a simple .NET console application that prompts users of the console app to type messages, and then the app uses the Service Bus .NET API to post each message the user types to the “scottmessages” Service Bus Topic we created above:

using System;
using System.Configuration;
using Microsoft.ServiceBus.Messaging;

namespace SendToScott
{
    class Program
    {
        static void Main(string[] args)
        {
            string connectionString = ConfigurationManager.AppSettings["Microsoft.ServiceBus.ConnectionString"];

            TopicClient topicClient = TopicClient.CreateFromConnectionString(connectionString, "scottmessages");

            Console.WriteLine("Type messages you wish to post to the Topic:");

            while (true)
            {
                Console.Write("> ");
                string messageText = Console.ReadLine();

                topicClient.Send(new BrokeredMessage(messageText));
            }
        }
    }
}

.csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; }

The above code uses NET’s ConnectionManager class to pull in configuration settings from an app.config file. I’m using this approach to retrieve the connection string to our Service Bus Topic (and to avoid hard coding it into the code).  Here’s the App.config file I’m using to specify this:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

 

  <startup>

    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />

  </startup>

  <appSettings>

    <add key="Microsoft.ServiceBus.ConnectionString"

value="Endpoint=sb://scottgu-ns.servicebus.windows.net/;SharedSecretIssuer=owner;SharedSecretValue=sSDdaewGUo3/wsaewtjhELlCi1y3SRwjFMX01tz2c/AXw=;TransportType=Amqp" />

  </appSettings>

 

</configuration>

Note: You can retrieve the connection string of a Service Bus Topic from the Windows Azure Portal by selecting the Topic and then clicking the “Access Key” button in the command bar at the bottom of the portal.  Note that to configure the .NET client library to use AMQP, I appended “;TransportType=Amqp” to the connection string. 

Running the Console App

Now let’s run the .NET console app. Hitting F5 produces a console app and we can now type messages to send to the Topic. Here’s some sample input:

Each message entered above was posted to our Service Bus Topic – which will in turn durably queue a copy of the message for each of the three Subscriptions we’ve setup to process.

Step 3: Writing a Java App Listener

Now let’s write a java app that will connect to one of the Subscriptions and process the messages.

The standard API for messaging in Java is JMS - the Java Message Service. JMS doesn’t specify anything about the underlying transport so different JMS products use different protocols under the covers to talk to their respective messaging brokers. I’m going to use a standard JMS Provider from Apache that uses AMQP 1.0 as the underlying protocol. Using this library, Windows Azure Service Bus becomes an open standards JMS Provider!

You can obtain the Apache AMQP provider at http://people.apache.org/~rgodfrey/qpid-java-amqp-1-0-client-jms.html. The following four JAR files from the distribution archive need to be added to your Java CLASSPATH when building and running applications that use it:

• geronimo-jms_1.1_spec-1.0.jar
• qpid-amqp-1-0-client-[version].jar
• qpid-amqp-1-0-client-jms-[version].jar
• qpid-amqp-1-0-common-[version].jar

We can then write the following Java code which uses the standard JMS messaging API to connect to our Service Bus subscription and process messages in it:

// ReceiveScottsMessages.java

 

import javax.jms.*;

import javax.naming.Context;

import javax.naming.InitialContext;

import java.util.Hashtable;

 

public class ReceiveScottsMessages implements MessageListener {

    public static void main(String[] args) {

        try {

            Hashtable<String, String> env = new Hashtable<String, String>();

            env.put(Context.INITIAL_CONTEXT_FACTORY,   

                "org.apache.qpid.amqp_1_0.jms.jndi.PropertiesFileInitialContextFactory");

            env.put(Context.PROVIDER_URL, "servicebus.properties");

            Context context = new InitialContext(env);

 

            ConnectionFactory cf = (ConnectionFactory) context.lookup("SBCF");

            Topic topic = (Topic) context.lookup("EntityName");

            Connection connection = cf.createConnection();

            Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);

            TopicSubscriber subscriber = session.createDurableSubscriber(topic, "java");

            subscriber.setMessageListener(new ReceiveScottsMessages());

            connection.start();

 

            System.out.println("Receiving messages. Press enter to stop.");

            System.in.read();

 

            System.out.println("Shutting down.");

            connection.stop();

            subscriber.close();

            session.close();

            connection.close();

        } catch (Exception e) {

            System.err.println("Caught exception. Exiting.");

            System.exit(1);

        }

    }

 

    @Override

    public void onMessage(Message message) {

        try {

            System.out.println("Message From Scott > " + ((TextMessage) message).getText());

        } catch (JMSException e) {

            System.err.println("Caught exception receiving message: " + e);

        }

    }

}

Note that the Apache JMS provider uses a simple file based JNDI provider to configure the JMS “Administered Objects”, including the connection details and the logical to physical name mappings of the messaging entities. Here’s the servicebus.properties file I’m using to embed the connection string details to our Windows Azure Service Bus Topic:

connectionfactory.SBCF = amqps://owner:sSDdaYGUo3%2FwpewtjhELlCi1y4SSwjFGX01tz2c%2FAXw%3D@scottgu-ns.servicebus.windows.net

topic.EntityName = scottmessages

This properties file defines a ConnectionFactory called “SBCF” which contains the constituent parts from the Service Bus connection string. The format is as follows:

amqps://[username]:[password]@[namespace].servicebus.windows.net

In the format above, the [username] corresponds to the issuer name, [password] is a URL-encoded form of the issuer key. You must URL-encode the issuer key manually. A useful URL-encoding utility is available at http://www.w3schools.com/tags/ref_urlencode.asp.

Running the Java App

When we run this Java app it will connect to the “Java” subscription on our Service Bus Topic and produce the output below:

Receiving messages. Press enter to stop.

Message From Scott > Red Shirts are cool

Message From Scott > Cross-platform messaging is so simple with AMQP and Service Bus

Message From Scott > Windows Azure Rocks!

 

Shutting down.

Note how the messages we sent to the Topic using .NET were seamlessly consumed from the Java app!

Popular Java frameworks like Spring and JEE use JMS to integrate different messaging systems – you can now write components using these frameworks and have the messaging system powered by the Windows Service Bus, and seamlessly interoperate and integrate with other languages and frameworks as well.

Step 4: Creating a Python App Listener

Let’s now write a Python app that will connect to another of the Subscriptions and process the messages.  We’ll host this Python app in a Linux VM.

We can create the Linux VM very easily using Windows Azure.  Just select the New command in the portal and use the Compute->Virtual Machine->Quick Create option to create a CentOS virtual machine:

Once the VM is provisioned we can SSH into it to configure and setup.

Installing the Proton Library on our Linux VM

For both the Python and PHP apps, we’ll use the Proton client libraries from Apache which are available for download from http://qpid.apache.org/proton/download.html. The Proton library provides a AMQP 1.0 compliant library that we’ll be able to use to communicate with the Windows Azure Service Bus.  The README file in the Proton distribution details the steps required to install the dependencies and build Proton. Here’s a summary of the steps I took using the command-line of the Linux VM:

1) Edit the yum config file (/etc/yum.conf) and comment out the exclusion for updates to kernel headers (# exclude=kernel*). This is necessary to install the gcc compiler

2) Install the various pre-requisite packages:

>> yum install gcc cmake libuuid-devel

>> yum install openssl-devel

>> yum install swig python-devel ruby-devel php-devel java-1.6.0-openjdk

>> yum install epydoc

3) Download the Proton library

>> wget http://www.bizdirusa.com/mirrors/apache/qpid/proton/0.4/qpid-proton-0.4.tar.gz

4) Extract the Proton code from the distribution archive

>> tar -xvf qpid-proton-0.4.tar.gz

5) Build and install the code using the following steps, taken from the README file

From the directory where you found this README file:

mkdir build

cd build

# Set the install prefix. You may need to adjust depending on your

# system.

cmake -DCMAKE_INSTALL_PREFIX=/usr ..

# Omit the docs target if you do not wish to build or install

# documentation.

make all docs

# Note that this step will require root privileges.

sudo make install

Following all this, Proton will be installed on the machine and ready for you to use. Here’s the Python code I wrote to receive messages from the “python” subscription on our Windows Azure Service Bus Topic:

import sys

from proton import Messenger, Message

 

broker = "amqps://owner:sSDdaYHUo3/wpewtjhEDlCi1y6SRwjFMX01tz2c/AXw=@scottgu-ns.servicebus.windows.net"

entityName = "scottmessages/Subscriptions/python"

 

messenger = Messenger()

messenger.subscribe("%s/%s" % (broker, entityName))

messenger.start()

 

msg = Message()

while True:

  messenger.recv(10)

  while messenger.incoming:

    try:

      messenger.get(msg)

    except Exception, e:

      print e

    else:

      print "Message From Scott > %s" % msg.body

 

messenger.stop()

print "Done"

A couple of things to note above:

• The connection string for the broker is of the form
  amqps://[issuer-name]:[issuer-key]@[namespace].servicebus.windows.net
• The entityName that we’re receiving messages from is of the form
  [topic-name]/Subscriptions/[subscription-name].

And now when we run the above python script (from our Linux VM) we will connect to the Windows Azure Service Bus using AMQP and see the messages we published from our .NET app:

One of the really cool things about the app above is that it is running in a Linux VM using Python, and leverages an open source AMQP library that communicates with the Windows Azure Service Bus messaging system using only the open AMQP protocol.

Step 5: Creating a PHP App Listener

Let’s now finish by writing a PHP app that connects to our final topic subscription and processes the messages.  We’ll host this PHP app in the same Linux VM we used above, and use the same Proton library that we used with Python.  Here is the code to use it from PHP:

<?php

 

include("proton.php");

 

$broker = "amqps://owner:sSDdaGGUo3/cpewtjhELlCi1y5SRwjFMX01tz2c/AXw=@scottgu-ns.servicebus.windows.net";

$entityName = "scottmessages/Subscriptions/php";

 

$messenger = new Messenger();

$messenger->start();

$messenger->subscribe("$broker/$entityName");

 

$msg = new Message();

while (true) {

  $messenger->recv(10);

  while ($messenger->incoming) {

    try {

      $messenger->get($msg);

    } catch (Exception $e) {

      print "$e\n";

      continue;

    }

    print "Message From Scott > $msg->body\n";

  }

}

 

$messenger->stop();

?>

And here is the output when we run it from the command-line in our Linux VM:

.

Summary

The above sample demonstrates how easy it is to connect to the Windows Azure Service Bus using the open AMQP protocol and the existing AMQP 1.0 libraries already supported by various communities. 

The new AMQP support in the Windows Azure Service Bus will make it even easier to build powerful distributed applications that can span and interoperate across multiple systems.  One cool thing to note with the same above is how the message has been preserved as it is exchanged between the different languages. This example used a simple text string for the body but the same is true for more complex message formats including lists and maps. This is achievable due to the portable data representation of AMQP 1.0. 

Here are a few links to some more information on the Service Bus support for AMQP 1.0:

• Windows Azure Service Bus
• Latest Service Bus .NET client library on NuGet
• AMQP 1.0 support in Windows Azure Service Bus
• How to use AMQP 1.0 with the Service Bus .NET API
• Service Bus AMQP 1.0 Developer's Guide
• David Ingham’s presentation on Service Bus and AMQP 1.0 from the 2012 //build/ conference
• Apache Qpid AMQP 1.0 JMS library
• Apache Qpid Proton

If you don’t already have a Windows Azure account, you can sign-up for a free trial and start using all of the above features today. 

Hope this helps,

Scott

P.S. In addition to blogging, I am also now using Twitter for quick updates and to share links. Follow me at: twitter.com/scottgu

One of the most useful models we have here at Seilevel, at least in my opinion, is the Feature Tree. It allows you to show a high-level view of all the features in a project (ideally on one page) so that stakeholders, analysts and developers alike can ensure a complete set of features and see the link between the business objectives of the project and the requirements (see the Feature Tree example below). However, one thing that I’ve found through my projects is that you can add dimensions to your Feature Trees, showing stakeholders more information at a glance than just a list of features using color coding.

I’ve personally done this several ways. The first and perhaps most obvious is to color code for releases of a project. Say you’re working a multi-year/release project and want to focus the stakeholders’ attention on the requirements for a specific release. This information would of course live in the requirements tables, but it can also live in the Feature Trees by coloring the Release 1 or whatever release you’re looking at in a different color from the rest (I prefer green, given the usual connotation of green meaning “go”). See the Feature Tree below as an example.

You could, however, color code as many releases as you wanted with distinct colors. I’ve also used two other mechanisms for color coding Feature Trees that both revolved around comparisons; specifically capability gap analysis. For this, if you are comparing one company to another or one product to another, you can use a simple 3 color scheme to denote which features belong distinctly to one company/product, which to the other and which overlap (I use green, blue and red, where red are capability gaps, blue are overlapping features and green belong to the first company/product being investigated). See the Feature Tree below as an example.

 

Finally, if you are comparing multiple companies/products, you can color code with what I liked to call “skittles,” small colored dots on features where each one denotes that a specific company or product utilizes that feature. These work great if you want to prioritize the features that are utilized by the most companies/products or to just get an idea of the features that each company/product has. See the Feature Tree below as an example.

Of course, with all of these mechanisms, you have to clearly explain the color scheme to your stakeholders and include a key on every page. Additionally, you do have to think about people printing in black and white and/or who are color-blind. To work around this, if you are using the skittles, you can make sure that each company/product has its own place on the feature branch so that people can look at the same spot every time to find the dot. If you are color coding the text itself, you could make sure that the features in a certain release are grouped together and put a box around them or something to indicate they belong together or do some sort of bolding, italicizing, etc. to show capability gaps/overlaps.

All in all, I’ve seen great success with using color coding to enhance my Feature Trees. Try it out and let us know about your experiences!

 

Adding More Dimensions to Your Feature Trees is a post from: http://requirements.seilevel.com/blog

Agile Coaches help teams and organizations embrace Agile and help maximize the delivery of business value.  We use terms like enable and facilitate to describe how they help organizations and teams transform.  But what does an Agile Coach actually do?  If we unpack enable and facilitate what do we actually find?  We actually mean a variable mix of activities that includes: consulting, cajoling, training, arbitration and mentoring.

Coaches sometimes act as consultants.  A consultant will actively involve him or herself in the game. Sometimes an Agile Coach will have to actively involve themselves in performing a task or activity so that the team can see the technique in action.

Coaches cajole, with gentle urging or coaxing, the team or organization to change behaviors that don’t live up to Agile principles and values. In many cases this cajoling is underscored by the war stories a Coach can deliver about the trials and tribulations that will ensue if the behavior is not corrected. The experiential base is important for the Coach to be able to hold the moral (metaphorically speaking)  high ground needed to persuade the team or organization.

Coaches deliver training.  Training comes in many shapes and sizes.  Coaches will be able to deliver training on a just-in-time or ad-hoc basis based on their own observations of how work is being done.  The goal of ad-hoc training is to ensure the team or teams understand how to apply specific techniques as they are applying them. I liken this to a form of just-in-time training, which leverages a principle from adult learning, that holds that adults retain knowledge better when it can be immediately applied.  This does not exclude leading and organizing training as part of more formal organizational change program.

Coaches arbitrate conflicts and difficult decisions.  Projects, whether to transform whole organizations or to implement a set of simple user reports, always include the need to make decisions. Coaches help organizations make decisions so that they can move forward with a minimal loss of inertia.  Facilitation for an Agile organization is a skill that is part art and part science – think emotive negotiation (or as a friend of mine calls it “family counseling for teams”).  The best Coaches teach the team or organizations they are working with these skills.

Coaches mentor.  A mentor is a trusted counselor who provides guidance, advice and training usually at an intimate (one-on-one) level.  A mentor needs to be dependable, engaged, authentic, and tuned into the needs of the mentee, so that the transfer of guidance is safe and efficient.

When an Agile Coach enables and facilitates, they really  consult, cajole, train, arbitrate and mentor. The art of being a good Coach is knowing what the mix of these activities are appropriate for any specific situation.

I strongly believe that coaches are not managers and they are not Scrum Masters.  Coaches reflect a unique mixture of attributes, including being a listener, a learner, a mediator and an evangelist. A deficit in any these attributes will reduce a coach’s effectiveness.

A good coach is a listener.  A coach listens by making a conscious effort to hear not only the words that the other person is saying but, more importantly, trying to understand the complete message being sent. A coach listens to obtain information, to understand and to learn.

A good coach is a learner.  There are two related reasons that being a learner is important.  Agile is continually evolving, therefore the value of what you know now will erode quickly. Secondly, a coach is much like a honey bee, transferring ideas and techniques from one project or organization to another. A coach must actively seek out and learn new techniques and concepts to pollinate new teams and organizations. Without the ability to continually learn, the utility a coach can provide will also continue erode.

A good coach is a mediator. Conflict that leads to decisions is part and parcel of team life.  Sometimes these decisions and interactions are hard.  A coach plays the role of a mediator who facilitates negotiation to help team members reach a mutually satisfactory solution to their problems, without compulsion. Coaches that can’t mediate tend to revert to management compulsion, which will not only reduce the effectiveness of the coach, but may also injure the team.

 A good coach has to be an evangelist. Lean and Agile focus on doing the work that delivers business value; only the work that is needed to deliver that value. Helping a team or an organization embrace Agile techniques effectively means personally embracing and helping the organization embrace the underlying philosophy of Agile.  A coach needs believe in the philosophy so that they can champion and shepherd the journey along the “new way.”  Not being willing to evangelize for the underlying philosophies of Agile will lead to crappy Agile.

 Each of the attributes of a good coach – listening, learning, mediation and evangelism – are all required.  Deficits in any will hurt the coaches ability to coach and will reduce the effectiveness of the team.  The attributes that good coaches acquire and foster will increase the ability of teams and organizations ability to deliver value.

We are proud to sponsor Chris Hartjes and Ed Finkler's Development Hell podcast series where they record their freewheeling, uncensored discussions on programming the web, so future generations can learn from their failures.

Read on to get the low down on different testing tools and their relative merits--check it out as Ed and Chris weep for the future, come to some interesting conclusions and get their hands dirty so you don't have to.

To hear more from Chris and Ed tune in to their podcast, /dev/hell

Ed and Chris had a little chat about testing in PHP.

Chris: Okay, so today's topic is PHP testing

Ed: Word up

Chris: Now, Ed, I know that for the most part you are not a big fan of the mainstream PHP testing tools

Ed: Yes, that's true

Chris: So what is it that you don't like about them

Ed: I guess realistically my complaints are aimed at PHPUnit . It's very powerful and very complete from what I can tell, but I think it's difficult to pick up and I think that difficulty makes people less likely to use it. Because it's by far the best known testing tool, I think that tends to limit the use of unit testing, period, in PHP. That's not necessarily PHPUnit's fault per se. I just think it's the situation we're in. I think the documentation, the setup, and just obtaining PHPUnit is a challenge, particularly when compared to unit testing options I've seen in other languages. Python, for example, has a simple but effective unit testing library built into the core.

Chris: So, when you say "difficult to pick up", is it because tests look like this?

<?php 
class Labels
{
    public $db;

    /**
     * @param GrumpyDb $db
     */
    public function __construct($db)
    {
        $this->db = $db;
    }

    /**
     * Turns label values like codingStandardsSuck into
     * CODING_STANDARDS_SUCK
     */
    public function screamingSnakeLabels()
    {
        $results = $db->query("SELECT name FROM labels");
        $labels = array();
        foreach ($results as $result) {
            $labels[] = $this->_camelToScreamingSnake($result);
        }
        return $labels;
    }

    /**
     * Method that takes a camelCase string into SCREAMING_SNAKE_CASE
     *
     * @param string $value
     */
    protected function _camelToScreamingSnake($value)
    {
        $result = preg_replace_callback(
            '/[A-Z]/',
            function ($match) {
                return "_" . strtolower($match[0]);
            },
            $value
        );
        return strtoupper($result);
    }
}

class DevhellTest extends PHPUnit_Framework_TestCase
{
    public function testShowEdHow()
    {
        $db = $this->getMockBuilder('Foo')
            ->disableOriginalConstructor()
            ->setMethods(array('query'))
            ->getMock();
        $db->expects($this->once())
            ->method('query')
            ->will($this->returnValue(array('devHell', 'camelCase'));
        $label = new Label($db);
        $expectedResults = array('DEV_HELL', 'CAMEL_CASE');
        $testResults = $label->screamingSnakeLabels();
        $this->assertEquals(
            $expectedResults,
            $testResults,
            "Labels were not correctly coverted to screaming snake case"
        );
    }
}

Chris: Maybe it's because I've worked with it a lot, all I see is some boilerplate and then a few statements that seem pretty intuitive to me.

Ed: I think boilerplate is part of the issue. I think that's intimidating. Tools can mitigate that to some extent, but I don't think it eliminates the problem entirely. I just don't think writing a simple test should be anything more than a couple lines of code. Then you can build upon that iteratively as you need. I think that approach of starting simply and building up your set of tests really helps you understand what's going on, and I think it makes testing a lot more accessible to people who haven't done it before. A lot of testing framework docs I see throw a ton of nomenclature out at the reader. I think if you don't already understand that nomenclature, you won't understand what's up.

Chris: So when you say 'nomenclature', you're talking about things like what exactly? Assertions and mocks?

Ed: Knowing how to mock that stuff up is pretty complex. In my experience the majority of people who work with PHP don't have a lot of formal training and even if they do, it often doesn't cover testing concepts. Like, what's a "unit?" What's an assertion? What's a mock or a stub?

Chris: I weep for the future, Ed. A unit is a small amount of code that you're trying to test

In PHP, that's usually one object, An assertion is simply a statement that "I am saying that the following is true", whatever that assertion happens to be. I do agree that there is lots of confusion about what a mock or a stub is so in my book I devote a chapter to explaining those things.

Ed: So I know what that stuff is (although I get confused about the diff between a mock and stub). But the real problem is that in order to write tests, you have to already know how to program, and that in itself is super-intimidating for people. PHP has a very shallow learning curve: the time between learning and becoming productive in some way is very short. That's certainly one of the reasons PHP is so popular. We need, I think, to mirror that in how we present testing, and make it easy to get into. It shouldn't be something that is terribly complex to set-up and do.

Chris: In that light, I understand the motivation to develop your own testing tools, but I still think PHPUnit is the way to go. So many people use it and there are so many resources available to learn it, that picking it up isn't as difficult as I think you're making it out to be. Alternately, I think the Behavior-Driven Development (BDD) model that Behat offers is appealing, and easier to pick up than the xUnit style. Behat combined with Mink is a solid alternative to PHPUnit.

Ed: If you are doing acceptance testing (meaning that you only care that the application as a whole is working) I don't
think you can go wrong with being able to write tests that look like this:

Feature:
    Scenario: Main page loads
    Given I am on "/index.php"
    Then I should see "Lies I Told My Kids"

    Scenario: Empty form fields trigger errors
    Given I am on "/index.php"
    When I press "submitButton"
    Then I should see "You submitted an invalid e-mail address"

    Scenario: Missing description triggers errors
    Given I am on "/index.php"
    When I fill in "email" with "test@domain.com"
    And I press "submitButton"
    Then I should see "You submitted a blank description"

Chris: The Behat and Mink combo can let you create some very interesting acceptance tests, and it even provides you with tools that will tell you when you when you will have to write your own helpers to supplement what they can provide you. It took me a few days to figure out Behat's own way of doing things but once I did I was able to create some very interesting tests, even ones where JavaScript (long the bane of automated acceptance testing) was being used.

If your mind doesn't align well with unit testing, then something like Behat is definitely the way to go. There's something neat about watching PHP run Behat which in turn opens up a browser and starts acting like a user and hopefully using your application correctly.

Ed: Ultimately, though, a lot of the problem with testing in PHP is that PHP's insane flexibility makes it super easy to write code that you cannot test. That and PHP is almost always working in concert with other systems, like a web server, so it can be tough to know what you can easily test inside the CLI and what you'd need to use a different approach.

To write testable code, you really have to be thinking about testing when you write your code. It takes a bit of time to get used to that, but I think it's very doable. In much the same way, it's taken us a long time to make security a first-order concern in PHP development, but I think we've done a decent job of that. We need to do that for testing as well.

Chris: If only, Ed. If only.

One of the challenges my General Manager put on my plate, was to tell a simple story, as simply as possible, about the essence of doing Enterprise Strategy. 

Here is what I ended up with:

The way I told the story is …

• We use scenarios to scope meaningful chunks of change (vs. boil the ocean)
• Big scenarios are actually chunks of organizational change.
• We drive a program of change using a repeatable formula: Current State, the desired Future State, the Gaps, the ROI, and the Roadmap for Business Capabilities, People Capabilities, and Technology Capabilities.
• The value is in the change, and this connects business and IT in a significant and meaningful way.

He loved it.

I elaborated.  

I shared a simple Workstream Frame to show how when we drive Enterprise Strategy, we can use the following canvas as our backdrop:

It’s a simple map but it helps chunk up and think about how you are making the changes:

• Program Governance – This is the space of operational excellence and governance.
• Business Value – This is where the business-led conversations and business-led changes flow.
• IT People/Process – From a pragmatic perspective, this is where IT-led conversations, and changes to IT people and process happen.
• Technology – This is where the fundamental technology changes happen – the IT platform for the business.  Again, dominantly IT-led conversations.

To fully appreciate the simplicity above, below is what I first walked my General Manager through, and he said, while he could appreciate the essence of it, it was too complex:

 

At the end of the day, I think he was right, and I was glad that he pushed me to find a simpler story and to be able to tell it quickly at the whiteboard.

When people see that it’s all about driving a chunk of organizational change, and that it’s by changing the business, people, and technology capabilities, light-bulbs go off, and people get excited by how they can reshape the future of their Enterprise story, through Enterprise Strategy.

You Might Also Like

Xbox One

Microsoft Secret Stuff

The Microsoft Story

Microsoft Explained: Making Sense of the Microsoft Platform Story

Microsoft Developer Platform at a Glance

Office 365 at a Glance

Windows Azure at a Glance

The LinkedIn forum The Project Manager Network - #1 Group for Project Managers which I sometimes wonder if that is actually the case, has a conversation going on around project failure. A Master's student asked about project failure modes. That led to the use of Earned Value. One participants made some pretty boneheaded statement around EV:

1. (EV) It's a tool and anyone who thinks it is an actual depiction of real progress is fooling themselves.
2. Percent complete, unless 100%, is at best an educated guess.
3. I've heard of the 0/100 and the 0/50/100 methodologies. I disagree with the 0/100. If you are trying to accurately portray progress, it is best to develop a set of standard credits, for example when doing drawings or, actual measurement such as in construction. Each activity has a value from which percent complete can be derived. 
4. An equipment general arrangement drawing is a good example (percentages shown are individual contributions) - using 40 hrs/drawing as the allowance (we get)...

5% (2 hrs)for applying the border and title
20% (8 hrs) for defining the area - boundaries and overall dimensions
30% (12 hrs) for showing all the equipment
5% (2 hrs) for the drawing being checked
10% (4 hrs) for it being Issued for Approval
15% (6 hrs) for it being Issued for Bid
15% (6 hrs) for it being Issued for Construction.
100% = 40 hrs. 

So, silly me, I responded that determining physical percent complete was a straight forward process once you have Quantifiable Backup Data or measures of Physical Percent Complete, or even better, Technical Performance Measures. Let's look at each concept

1. EV, when percent complete is measured in tangible units of physical percent complete is a depiction of real progress. Why because the progress is physical percent complete. It's a tautology.
2. Percent complete is NOT an educated guess, it is tangible proof. This is call Quantifiable Backup Data. Bring the number of drawings to the table you said you were going to do on the day you said you were going to do them, and you'll get the prorated share of the earned value for the total drawing package. Bring 8 of the planned 10 on the day you planned to produce 8 and you'll get 80% of the total work package for producing 10 drawings.
3. 0/100 is best, all others skew the performance. The last piece of that concept is actually correct. For a 10 drawing package, with each drawing weighted the same, that is 10%, 5 drawings, completed on the planned day, gets you 50% physical percent complete.
4. No we go straight into the ditch. Progress is NEVER measured with the passage of time except in Level of Effort work. The actual costs (ACWP) is interesting to cost accounting, but it tells us nothing about the progress of the project except how much money we have spent compared to our budget. If the assigned (apportioned) value were all there was, then OK. But the conversation included the number of hours, and there where the problem starts.

Then the final come back from the OP.

If you're doing a drawing and it takes 40 hours to do the drawing and no two drawings are alike, how do you determine what percentage complete you are? When estimates of the work to be completed are put together, they will estimate X drawings at 40 hrs/drawing. They will have different standards by discipline. Will a person ever report 41% complete on a drawing? Most likely not. It will be shown as 40%. Collectively all the drawings may be 41%, but not individual. No matter how you look at it, it is still an estimate.

First measuring progress to plan by the number of hours consumed is called Level of Effort. Second LOE is a very poor measure of anything other than the passage of time and consumption of resources.

In the end the poster was insistent that ANSI-748-B is just a guide, and doing EV was a local issue. No doubt that is true in his domain. But as a practitioner of EVM using ANSI-748-B for programs subject to DCMA Validation, as well as engagements with the DOD office that own the Earned Value Management processes for the DOD, I'd be laughed out of the room with an approach like that.

For a summary Earned Value in a Nutshell using a similar drawing example.

So Here's The Way TO Do Earned Value

1. Using the WBS define the Work Packages that produce the deliverables for the program
2. Assign an Earned Value Technique to each of these Work Packages - 0/100 for the individual tasks inside the Work Package is the absolute best. You're either done with the task or you are not. Weight the tasks if you want, but sum up the "done ones" and compare that to the total work and compute a percent complete.
3. Sequence these Work Packages in an Integrated Master Schedule
4. Assign budget (BCWS) to each of the Work Packages
5. Collect the actual costs to perform the work (ACWP)
6. Compute the Earned Value (BCWP) using a simple formula BCWP = BCWS x Physical Percent Complete.
7. Compute Cost and Schedule variance. Make management decisions based on these and take corrective actions to get back to GREEN.
8. Repeat step 5, 6, and 7 every month at a minimum, more often if possible.

That's all there is - essentially - for doing Earned Value Management. Of course if you read ANSI-748-B, the NDIA Earned Value Management Intent Guide, and the DCMA Intent Guide, there is a lot more.

You Can't Make Stuff Up

OK, you can. But if you do, it makes having a conversation about EV much harder. 

Related articles What is Earned Value? Definitions, Yes They Are Important In Earned Value, Money Spent is Not a Measure of Progress! Rings of Success Earned Value says its Name Issues with Deploying Earned Value Management

What data structure is more sacred than the link list? If we get rid of it what silly interview questions would we use instead? But not using linked-lists is exactly what Aater Suleman recommends in Should you ever use Linked-Lists?

In The Secret To 10 Million Concurrent Connections one of the important strategies is not scribbling data all over memory via pointers because following pointers increases cache misses which reduces performance. And there’s nothing more iconic of pointers than the link list.

Here are Aeter's reasons to be anti-linked-list: