Remote desktop to a Service Fabric Node

Another in my series of, “oh how do you do that again?”

  1. Grab your Service Fabric (SF) address; e.g. http://mydomain.northeurope.cloudapp.azure.com
  2. Open the explorer and find the node that contains the service you want to examine
  3. Open Remote Desktop and use the address from (1) but, now for the easy to forget bit, use the port number of 3389 + the node Id. E.g. for node 2, 3391
  4. Use the Admin user name/password you used to create the SF in the first place and you should be now be on that machine
Posted in Uncategorized | Leave a comment

Setting the default Connection Limit

Every time I want to set this I can never remember what it’s called, so I’m posting it.

ServicePointManager.DefaultConnectionLimit

Posted in Uncategorized | Leave a comment

Powershell telnet alternative

Just a quick note that you can use a Powershell cmdlet to test a network connection;

Test-NetConnection -ComputerName <name> -Port <port>

 

Posted in Uncategorized | Leave a comment

Beware Backlog Tunnel Vision

Many Agile techniques rely on a backlog of items to work upon. Ideally everyone would know all the items that are in the backlog, but practically this is not always possible. A typically process is to have a handful of team members groom the backlog to prioritise the order the items. The very real danger is that when a team starts working on an item they do not have a holistic picture of the backlog. Without acknowledging (rather than needing to fully understand) the future requirements the team risk making choices that will need to be redone.

The Tour Bus Example

One of my favourite Agile examples is the Band Tour Bus. A band has struck it big overnight and they need to go on tour quickly, so they need a tour bus. A waterfall model would dictate that all the requirements for the bus are fully specified, costed, prototyped, etc. When the bus is ready everyone’s forgotten about the band and many new groups have replaced them. There is no money to pay for the bus – sad times. Enter Agile, a backlog of all the features for the bus are created and it’s deemed that a basic bus will be delivered first. Hurray the band make it to their first gig, granted not in style, but they get there. Now, let’s say that part of the bands master plan requires a long tour and they need to take their families. The occupancy requirement goes from 4 to 12. Upon grooming the backlog it is decide that feature will be done 6 sprints into the development. However, the development team haven’t been told and create a lovely in-bus bathroom. Sprint 6 arrives and there is no real-estate to create the additional living quarters, disaster. How can we avoid this problem?

How to clear the blinkers

As with most things in Agile the simple solutions are often the best;

a) Grooming team review the start of the work. The grooming team have the facts, they should review the start of work to ensure there are no obvious clashes or dependencies on items in the backlog

b) Items are categorised to allow all team members to quickly search for potential dependencies. When a new item is examined the team run a quick search over the backlog.

Whilst (b) is a useful mechanism, especially for longer running projects (e.g. products) where the grooming team changes, I would always recommend at least (a). If your team only considers the narrow view of the next Sprint or the next set of work items then the project will be at a real risk of expensive re-writes.

Posted in Agile | Tagged | Leave a comment

Why TFS Online Task board is Anti-Agile

I like Visual Studio, and I like a number of things about Visual Studio Online (VSO). However, there is one part of VSO that I think I very dangerous and can easily put your Agile project at risk. What is this terrible evil? Well I’m guessing you’ve read the title so it will be of no surprise when I say, the Scrum Work Item Task Board (see https://msdn.microsoft.com/en-us/Library/vs/alm/Work/scrum/task-board?f=255&MSPPError=-2147217396).

My experience of this task board is that it leads to a complete disintegration of the Agile practice. But it looks fine, how can such an innocent artefact lead to such problems? A number of Agile practices rely on a set of key overlapping points; 1. Transparency of the work 2. Collaboration and trust 3. Exiting with completed work. When you work on an Agile solution you will have a group of people with a set of specific skills, or at least wear the hat of a specific skill. Let’s assume we have a project owner, tester and developer. I firmly believe these are the minimum roles, even if you chose to only employ one person for all of them.

When you use a non-electronic task board you will, typically, go though a process that encourages collaboration. A note representing the ‘task’ will be placed on the board and those involved will discuss the issues around it. At first the team will agree what will be delivered and, crucially, how you prove that it has been successful. A common strategy here will be that at least the owner and test team will be responsibly for delivering an automated acceptance test for the task. The development team will be involved but perhaps not so hands-on, their main interest is to ensure the task is available for them work on. I.e. it is in the developers interest to track the progress of the owner/test team. Next the roles switch, the developers will implement the task to meet the acceptance criteria. The owner/test team play a lesser role but now they are interested in ensuring that the progress of the development is kept on track. Once development finish the owner/test team will then give the final yes/no on the result. Even without a Limited Work In Progress (WIP) strategy the team are always aware of the progress of the task and that it is their collective responsibility to collaboratively complete the task. Various process methods are used to help re-enforce this but the majority come down to a simple level of communication and, importantly, participation. So back to the topic, what is the problem with the VSO (Scrum) task board?

The first problem is that VSO wants you to separate out responsibility by creating a task per person. So rather than a task move through the team members hands, each person has their own task. Now when the team meet up each person has their own, pardon the overused term, story to tell. As their individual tasks progress it is an unfortunate human trait that the teams interest in individuals tasks wanes. Worse still, when a task completes in simply finishes and is really only of interest to that person. One task finishing does not trigger the start of another. What we have now is a system that purports to be agile but is really just a system crying out for a Gantt chart.  This is not VSOs problem per se. The task board is based, or bolted onto, old Team Foundation Server (TFS) non-agile templates. I.e. the agile processes, in this case Scrum, has be coerced onto a platform that doesn’t really support it. Happily the VSO team have working hard and have recently allowed more customisations that may offer a way out. Also this blog has been focused solely on VSOs Scrum process, you could choose Kanban instead. Whatever you choose, you should consider what are the human ramifications. Also try to keep the team, as a whole, focused on the progress of the work. It is everyone’s responsibility to deliver the work, that only ends when it is delivered. Ok, even that’s not strictly true, but lets keep those worms in the tin for now.

Be very careful of VSO Work Items, don’t be fooled into thinking you have an out-of-the-box agile process. Or just don’t use Scrum…

Posted in Agile | Tagged , , | Leave a comment

The mystery of when to add that extra property path junk

This is a note post since I know I will want to come back to this again;

From: http://stackoverflow.com/questions/4640573/round-brackets-in-xaml-syntax

The parentheses indicate that this property in a PropertyPath should be constructed using a partial qualification. It can use an XML namespace to find the type with an appropriate mapping. The ownerType searches types that a XAML processor has access to, through the XmlnsDefinitionAttribute declarations in each assembly. Most applications have the default XML namespace mapped to the http://schemas.microsoft.com/winfx/2006/xaml/presentation namespace, so a prefix is usually only necessary for custom types or types otherwise outside that namespace. propertyName must resolve to be the name of a property existing on the ownerType. This syntax is generally used for one of the following cases:

  • The path is specified in XAML that is in a style or template that does not have a specified Target Type. A qualified usage is generally not valid for cases other than this, because in non-style, non-template cases, the property exists on an instance, not a type.
  • The property is an attached property.
  • You are binding to a static property.

 

 

Posted in Uncategorized | Leave a comment

Trick to see if you have a soft Steering Wheel in use

I’m sure there are some people that love the soft Steering Wheel. But sometimes, very rarely, they cause a problem when you are trying to arrange your page. One little trick you could use is to utilize the fact that the Bottom App Bar will be pushed up the screen to make room for the Steering Wheel. If we can compare the top position of the App Bar then we can assume that the Steering Wheel is in play;

GeneralTransform bottomAppBarTransform = this.TransformToVisual(this.BottomCommandBar);

Point appBarPosition = bottomAppBarTransform.TransformPoint(new Point(0, 0));

var pageHeight = this.ActualHeight;
var appbarHeight = this.BottomCommandBar.ActualHeight;

if (pageHeight - Math.Abs(appBarPosition.Y) > appbarHeight)
{
      // Hello Steering Wheel
}

Hopefully someone out there will reply with a, “no just use this simple API”. That would be nice.

Posted in Uncategorized | 1 Comment