ALM

Rangers Treasure Map v2.1: Snap re-invented

ScreenGrab (1)As part of my work on the Microsoft ALM Rangers Treasure Map, I want to share about how we changed snap for the 2.1 release.

Why?

The first question, is why do we need to change snap for 2.1? The requirement is that 2.1 is primarily focused on supporting Windows 8.1 & Windows 8.1 does snap a little differently to how Windows 8 handled snap. In short, in Windows 8 you had snap (fixed width), a full screen and third “middle” state – however Windows 8.1, has full screen and then any value between that down to a minimum width.

ScreenGrab (2)Microsoft has written a great document covering what is new at: http://msdn.microsoft.com/en-us/library/windows/apps/hh465371.aspx

Planning

Step one in doing this was to investigate what we had – so I just took the app and ran it on Windows 8.1 and played with the new snap experience. From that I took screenshots, made annotations etc… for us to decide on an approach. You can see these images along the side/bottom of this post.

Decisions

ScreenGrab (3)Since this is a minor release for us, the decision to not invest too much into this release was made. So we decided not to try and build something brand new but rather make sure everything works as it does currently.

To this we chose a minimum of 320 pixels (the default in 8.1 is 500) since that matched what we had in Windows  8.

Code

One of the choices we made in version 1, was to NOT use the out of the box state manager way to change the UI. You can find out more about how we implemented that in a video I did for Channel 9ScreenGrab (4):

ScreenGrab (5)

So what did the code changes look like for with our model? In the image below you can see that rather than ask what state we are in (line 142 on the left) we rather just check the screen width and based on that we load the correct namespace.

This tiny change was all that was needed, and this was made successful because we decoupled the views from the start rather than trying to have one view that does everything using the visual state manager.

image

Robert MacLean Wed, 10/09/2013 - 11:54

Scrum, it is just shorter waterfall?

Submitted by Robert MacLean on Tue, 10/08/2013 - 10:30

When I speak to people about Scrum, I often hear people describe Scrum as: Waterfall but with shorter iterations. That view, imho, is fundamentally wrong and will lead to you not getting any of the benefits from using Scrum.

Waterfall Myths

imageWaterfall provides a structured approach to software development and has a reputation for taking a long time to deliver because each phase must occur and must occur in order. In reality Scrum is very similar and has many of the same steps, in the same order as Waterfall.

So what about the length of time issue? Waterfall seems to be used around massive projects which takes months or years to ship, yet Scrum is great because you have a minimum viable product (mvp) every four weeks. That isn’t true either – a lot of the myth here is because during the scoping of a project using Waterfall, everyone puts the everything in. In reality, nothing stops you having smaller deliverables of a mvp while using Waterfall.

The last myth to dispel is that Scrum is better than Waterfall because it allows the product owner to change the goals as they learn about what is built & the market conditions change. Waterfall does allow that too. In Waterfall it is called change controls and, done right, they work very well.

In addition, if you use smaller iterations with Waterfall, you can use the requirements, design & verification stages as you would sprint planning & retrospectives to adjust the course of the team.

How is Scrum different to Waterfall?

A side thought, is that difference in that ownership could also be why projects using Waterfall seems to fail more than those using Scrum. It isn’t the methodology but rather it is the people doing the work’s commitment which drives the success or failure of the project. For projects using Waterfall where they are successful, I think you will find that they do many things outside the methodology to ensure everyone feels committed to the success.

If Waterfall can offer everything that Scrum does too, how then is Scrum different? The major difference with the two methodologies is around the psychology of the developers involved with the project:

  • Waterfall: Have a single centralised, ownership for the project
  • Scrum: Have a distributed, ownership for the project

That may not make much sense, so let me explain what I mean by ownership of the project. The ownership for the project is made up of a number of things:

  • How much responsibility a person involved has?
  • How much authority a person involved has?
  • How much control and influence a person involved has?

When we look at Waterfall, the developers involved in the project have very little with regards to the above conditions. Those conditions are almost solely handled by the project head and project managers, and because of this lack of authority, responsibility and influence the developers are not invested in the ultimate delivery of the project.

Scrum on the other hand, drives verifying levels of responsibility, authority and influence to everyone involved. For example the product owner has the most responsibility but there is still responsibility shared to the rest of the team. It is impossible in scrum for a developer to bury their head in the sand and say the problems are not their problem.

Conclusion

scrum-pigs-chickensFor me the major difference can easily be summarised using the old fable of The Chicken and the Pig. Waterfall allows developers to be chickens but scrum requires the developers to be pigs.

Choosing between Waterfall and Scrum isn't so much about choosing between methodologies as choosing between designs of ownership and responsibility. That design is vital because how your team is designed directly impacts what you ship.

LightSwitch: Passing data between screens - Example 5: Passing information to an "add" screen

For other posts in this series, see our series list.

In the previous examples, we have always passed data to a simple browse screen. Passing to a screen where you add an item is a little more complex so we will look at how to solve that. It may also seem that what we did in example 3, wasn’t useful since example 4 showed a better way – however there are times you can’t do that so we will also look at that. Finally we will end with a better way to do this, using a b

This posts, and the rest in the series will be a bit shorter as we are covering the same theme but applied in different ways – so make sure you read the preceding parts or you may feel a bit lost.

As with each part of this series, the code can be found on GitHub.

Example 5a: Passing information to an “add” screen with JavaScript

1. On our add screen we start by adding a data item. We will name it Animal and we will set the Type to Integer. The point of using Integer is to show that the type of the property doesn’t matter to JavaScript. Setting it to a different type than we expect, only affects the tooling.  Lastly we set this to be a parameter.

image

2. Now we will do the code for the create event, and here we need to do two things. As this is a “add” screen, the first bit of code is to make sure we have an object defined. AnimalInfo is the object that the screen monitors and will persist to the backend – so if it is not defined (null) we must create our own.  We do that with:

if (screen.AnimalInfo == null){<br>&nbsp;&nbsp;&nbsp; screen.AnimalInfo = new myapp.AnimalInfo(); <br>}

And then we follow that up with the simple line of of assigning the name of the animal from our data item: screen.AnimalInfo.AnimalName = screen.Animal;

Note: even though we set the property which is of type string, to an integer – it just works.

image

3. I mentioned the tooling becomes a problem if we do not use the right types, so to see how that occurs – we add a button to the browse screen (that we used in the last example) and try to open it up our screen and set the name, however Visual Studio doesn’t let us.

image

4. We can just work around this in code, and we start off on the browse screen by adding a button with the method named ShowAnimalInfo

image

5. The code we use in the button is very simple: myapp.showAddAdnimalInfo(null, screen.AnimalsSet.selectedItem.Name);

This should look very similar to example 4, except we have a null in the first parameter (since we want the add screen to create the object associated with the screen – which we covered in step 2). The second parameter is passing the selected items name to the screen. Once again, the tooling is expecting an integer but JavaScript is dynamic so it will accept a string.

image

6. That’s it! It all just works!

Example 5b: Passing information to an “add” screen – working with the tooling

This final example, is to show you just how nice the tooling is when you pass the right types around and how you can do the same as above without JavaScript. If you are looking at the demo code, this is in the AddAnimalsInfoSmart screen.

1. The major different here is the type of the data item we add as a parameter. So for this we set the type to the Animals (Entity).

image

2. Now we need to write a bit of code again on the create event. Since we are only going to use the tooling to launch this screen, we do not need the check to see if the object for the screen is set. All we need to do is set the values.

image

3. Finally the button on the browse screen is just added using VS without JavaScript & we can use the IntelliSense to select the right things:

image

This second route is WAY better and what I recommend using, but it is great to know if you find yourself in a situation with two types that don’t match up you can work around it with a trivial amount of code.

Robert MacLean Tue, 09/24/2013 - 13:19
LightSwitch: Passing data between screens - Example 4: Passing a database item without JavaScript

For other posts in this series, see our series list.

In our last example, we passed data from one screen to another using a bit of JavaScript. However there is two issues:

  • If you do not select an item before clicking the button – it errors
  • It needs code, and LightSwitch is about making the drudge work easier so how can it help here?

This posts, and the rest in the series will be a bit shorter as we are covering the same theme but applied in different ways – so make sure you read the preceding parts or you may feel a bit lost.

As with each part of this series, the code can be found on GitHub.

Example 4: Passing a database item without JavaScript

1. On the BrowseAnimals screen we already have, we once again add a button to the screen in the command bar with the following properties:

  • Choose an existing method: showWeasel
  • data: AnimalsSet.selectedItem.Name

What we are doing here, is having the Weasel screen shown & because we added a parameter we can use the build in tools to set that parameter to a data item on the screen.

image

(in the above image the parameter is labelled myData – for our example it will be data).

This is it! It is far simpler than example 3, it also doesn’t have the issues we mentioned at the start – so you should always use this option if you can.

Robert MacLean Fri, 09/20/2013 - 15:43
LightSwitch: Passing data between screens - Example 3: Passing a database item with JavaScript

For other posts in this series, see our series list.

In the first example we looked at the core concept behind passing data and we followed that by understanding the power that having a dynamic language in LightSwitch offers us. In both examples, we passed a string we hard coded – what about if we want to pass something from our database layer?

This posts, and the rest in the series will be a bit shorter as we are covering the same theme but applied in different ways – so make sure you read the preceding parts or you may feel a bit lost.

As with each part of this series, the code can be found on GitHub.

Example 3: Passing a database item with JavaScript

1. We start off by creating a table, Animals which just had a Name column for the name of the animal we will capture. 

image

2. Next we will create a simple screen to add an animal and a second screen to browse the list of animals.

3. On the new Animals browse screen we will add a button named ShowWeaselCodeWay – the idea here is you will select an animal from the list of animals and click the button. That will launch the same Weasel screen from part 1. For this example I am adding it to the command bar.

image

4. Next we need to edit the code to pass the parameter – so we use the execute event again and put in:

myapp.showWeasel(screen.AnimalsSet.selectedItem.Name);

The only new code we are seeing here is the screen.AnimalsSet.selectedItem.Name part – which is as it sounds: for this screen, give the AnimalsSet data item (which powers the list), then give me the selectedItem in that and lastly, give me the Name property of the selected item.

image

That’s it! Nice and simple, but not without it’s issues – which we will discuss & solve in the fourth example.

Robert MacLean Wed, 09/18/2013 - 23:39
LightSwitch: Passing data between screens - Example 2: Passing an object and avoiding ugly global variables

For other posts in this series, see our series list.

In part 1, we did the simplest solution – passing a string to a screen. In this post, we will do two changes on the same idea.

As with each part of this series, the code can be found on GitHub.

Example 2: Passing a objects and avoiding ugly global variables

The core to learn in this example is that JavaScript is a dynamic language – it is FUNDERMENTALLY different to a static language like C# and those differences allow us produce much cleaner code.

1. We start off again, with a button which we will name Crackle.

image

2. We will also create a new screen, named Rice. On the new screen add a data item with the following properties:

  • Screen Member Type: Local Property
  • Type: String
  • Is Required: True
  • Name: data

image

3. And, the important part, we change the data item we added, named data, properties and set it to be a parameter.

image

4. So that we have a way to see the data, we will use a custom control again – with it’s data set to Screen. We are not renaming this new custom control – so it will be named ScreenContent. We can see this on the property pane of the custom control.

image

5. Next we add some code to the create event for the new screen:  screen.findContentItem(“ScreenContent”).tag = screen.data;

Let’s break that code down:

  • screen.findContentItem(“ScreenContent”) – this method allows you find a control on the screen by passing in the controls name. So here we pass in the control we added in step 4 and that method returns it.
  • .tag – here is the first example of using JavaScript as a dynamic language. The custom control doesn’t have a property named tag, but since we referenced the property, it gets added.
  • screen.data – here we are referencing the parameter we added back in step 3.

Using the tag here, allows us to pass data to the control that needs it without the global variable in the first example.

6. Now on to the code to do the rendering of the data. Rather than just using a simple string, as in example one, I want to use a object with properties. The code for that:

var data = contentItem.tag;

element.innerText = “first name” + data.firstname;

If we break that code down, we access the tag property of the control (here passed as the parameter contentItem) which we created in step 5 above. We assign the value of that to a variable named data. Note: this isn’t the same data as the data item we created in step 2.

Next we set the innerText of our control, so it renders something, and we access the property firstname from our new variable.

image

7. Last we need to launch the screen, so we go back to the button we created in step 1 and edit the execute code for it. The code we add there is: myapp.showRice({ firstname: “Robert”, surname: “MacLean” });

This is the same as the last example, except we are passing in an object with two properties. This highlights the dynamic nature of the JavaScript again because you will remember this is “defined” as a string but we pass in a object which is perfectly legit code in JavaScript, and because this is a real object we can access the properties for the rendering in step 6. This is different from the inheritance we are used to in static languages where you cast objects – this is actually changing the type.

 image

All done!

image

Robert MacLean Tue, 09/17/2013 - 20:44
LightSwitch: Passing data between screens - Example 1: Passing a string

For other posts in this series, see our series list.

Recently I saw a question about how you can pass data between screens, which is something we do a lot of in our system – so I thought I would share details on how we do it. There is a number of ways to do this, so we will start this series with a simple way of passing a string.

As with each part of this series, the code can be found on GitHub.

Example 1: Passing a string

1. For the first example what we will do is pass a hard coded string from a button on screen to a second screen. We start off by adding a button (called Pop) to a screen.

image

2. We then create a screen for it, in our example the screen is called Weasel.

image

3. On the new screen we add a custom control and set the data to be Screen.

image

4. The core of this method is first to add a new data item. For this example we will specify it as follows

  • Screen Member Type: Local Property
  • Type: String
  • Is Required: True
  • Name: data

image

5. After you click OK, click on the data item in the right hand side and go to the properties and tick the check box: Is Parameter

image

6. For the execute event for the Pop button we add the following code: myapp.showWeasel(“pop goes the weasel”);

We are using the out of the box JavaScript here to launch the code, but if you have never done this before let us look into what that simple line has:

  • myapp: This is the namespace for our app. This is the same in every LightSwitch app.
  • showWeasel: This is the method to launch the window. LightSwitch uses the pattern of show followed by the screen name.
  • “pop…”: This is the data we want to pass across. We get this property on the method as we created the data item above and set it to be a parameter.

image

7. Finally we just need to show the string on the Weasel screen. To do that we need to add two events – first we will add the created event for the screen. The code we add here is to first put a variable outside the event (named d) and then in the event we add the following: d = screen.data;

In short, when the screen is created, we read the data property from the screen and set a global variable d to be that result.

image

8. Secondly, we select the custom control we added in step 3 and edit its render code.

In the render code we just set element.innerText = d;

This just renders the string, it isn’t important for passing the data other than to show what we got.

image

9. The final code will look like the following. One note, in the example below, it says screen.myData – but that should be screen.data as out data item is named data.

image

And that’s it! That is how to pass a simple string.

image

Robert MacLean Mon, 09/16/2013 - 22:02
Creating Web Pages Using the LightSwitch HTML Client in Visual Studio 2012

imageMy friend and fellow MVP Michael Washington runs THE LightSwitch website, and recently he published a book, Creating Web Pages Using the LightSwitch HTML Client in Visual Studio 2012, with and I decided to buy a physical copy to show my apparition of his great work. I thought I would take some time to write a brief review of thebook.

The question I always ask for a review, is this the book for me – the answer is YES! This book is for EVERYONE! However, let us dig into some more details on the book.

Newbies to LightSwitch

If you are new to LightSwitch, or new to the HTML client, then the book covers a lot of the things you need to think of. Each chapter covers in a very practical way how to implement what it showing and it is very visual in how it covers the material. What is great is this book doesn’t shy away from the developer aspects, and there is plenty of coverage on the JavaScript development models and how to put it together.

This is so good for newbies, that I think Michael should license this to Microsoft so they can build training material around it!

LightSwitch Professionals

I have done LightSwitch for years from the smallest projects to massive things and everything in between – and even I saw & learnt things. A lot of what I personally gain was ideas of how to put content together and ideas on JavaScript libraries. I literally went to work the next day after the book, and submitted a list of ideas inspired by the book!

Where the book is weak

The book isn’t perfect though – where it falls down is the later bits, most glaringly a section on using a WCF RIA Service with it. RIA Services, with the death zombie-ness of Silverlight (in my view) and LightSwitch does support WebAPI which is what ASP.NET is pushing & is the future (in my view) & there is no Web API material. 

The only other problem, is that the images are in grey scale. While reading it didn’t annoy me but when I closed it, and realised the final example image is the image on cover… I realised how much I lost not having colour images.

Robert MacLean Mon, 09/16/2013 - 21:12

How to build a Mobile API or HTML 5 app in 5 minutes

Submitted by Robert MacLean on Wed, 08/14/2013 - 07:44

Last night I had the absolute joy of spending a little more than an hour taking about Visual Studio 2013 & (more importantly) Visual Studio LightSwitch at the Developer User Group. It was great to have a standing room only session with loads of participation and hopefully I got to show off why I love LightSwitch.

This talk was mostly just me doing massive demo fun and running ALL OVER the place, we covered:

  • LightSwitch 101 (create forms, add data etc…)
  • Some more advance layout tricks in LightSwitch
  • How LightSwitch works under the covers
  • Visual Studio 2013 profile & notification features
  • Visual Studio extensions
  • Visual Studio Code Lens
  • Building custom clients with OData
  • Wrapping data in Web API

and so much more. This really was a session driven by the audience so it was great fun for me. The slides (which likely won’t be of much use) are below & after that is the download for the demos!

Thank you everyone for making it a super special evening for me!

Use Strict... in Visual Studio

Submitted by Robert MacLean on Wed, 08/07/2013 - 18:55

bloggif_5200134a412f8Visual Studio is The Best IDE For JavaScript. I’ve said that many times before & it remains true that as JavaScript developer on ANY platform Visual Studio will make you life easier than any other IDE. So all good JavaScript developers know that fact now and those same good JavaScript developers also know you ALWAYS Use Strict in your code.

While it is trivial to type the thirteen key strokes (I just did that to count how many it was – *sigh* thirteen less from my allotment of keystrokes), you may want to make it even easier by using a great feature in Visual Studio called snippets and since Visual Studio 2010, we have had support for JavaScript snippets.

So I have created a simple free snippet for you to use: the use strict snippet. Once added to Visual Studio, the snippet will let you type us and hit tab & get the use strict line in your JavaScript! Yay for simple things!

Download the snippet!