Umbraco Preview: Are my changes live or not?

This post is based on the following Umbraco setup.

• Umbraco v7.2
• Azure Sql Server - Web Edition

Background

Preview in Umbraco lets you quickly see how your page will look on different devices. It allows content editors to switch between different devices previews and see how their content will display on a number of common device sized before making their changes live. Recently I had a client raise a few concerns about how the preview functionality worked and so this post is for all those who have to do the same in the future.

Where's my preview button?

The first problem the client had was not being able to see a preview button on their newly created pages. In order to preview content, the content must first be saved. Once saved (but not necessarily published) the preview button will appear in Umbraco.

Is it live or not!

When a content editor clicks preview they are able to see what the website will look like before it is published and available to all website members. Umbraco does this by setting a cookie in the user’s browser which is persisted until they log out of the CMS. This caused great confusion with my client who was concerned the preview functionality was broken. They had made changes and previewed them in the cms. They had then visited the main site as a member, while still logged in to the CMS. As the preview cookie had not been cleared they could see their unpublished changes on the live site. Of course the changes were not live, and once they logged out of Umbraco, normal service was resumed. However, we now always advise....

Once content editors have finished previewing content, they should always logout of Umbraco to ensure they are seeing live content rather than preview content.

Talking with tech leads: James Gaisford

At the end of last year I was offered the role of Head of development at my company. Having been a reluctant senior developer, I was a little reluctant to take the role, but after some careful consideration I accepted the offer. As with previous career challenges, I sought advice and guidance from the internet. But the best steer came from an unlikely source - a tweet from Martin Fowler

.@wilpannell The book on being a tech lead is by @patkua https://t.co/BoyWVS6F0e

— Martin Fowler (@martinfowler) December 20, 2014

The book referred to in the tweet is called "Talking with tech leads" and it is a must read for all developers thrust into the strange and unfamiliar world of leading a technical team. The book takes the form of interviews with a number of tech leads, asking a core set of questions particularly around significant challenges faced and how they balance the technical and non-technical worlds.

So, after my first six months as a tech lead, I present my answers to those same core questions asked in the book.

What should a Tech Lead focus on and why?

Solving problems without coding. As a developer your core skill is to be able to solve problems by coding. This is a skill that has been honed over many years. It is very tempting as a developer, new to the tech lead role, to offer only code based solutions to customer problems, but stop. and think if there could be a non-code based solution to the problem presented. Pushing back on client requirements? Negotiating with project managers to get additional resource? Scrutinizing client requirement documents? Writing tight functional specifications. All of these and other non-code based solutions can come to your rescue. Expand you toolbox. 

What has been your biggest challenge as a Tech Lead?

Don't over-commit.... and delegate. With a new role comes a lot of new responsibility. This means a lot more work. Depending on the set up in your company, there may be an expectation that you still perform some or all of your previous role's responsibilities as well. You will be asked to do a lot, but don't be afraid to push back, to say no. You may have a team to whom you can delegate some of your work to. Don't be afraid to use them. No one will think you are incapable, slacking off, or being lazy. In fact, if the team is good, they will relish the challenge.... just don't over do it.

Any time-management tips?

Get in early. Process emails. Work out a plan of attack for the day. Create a simple list using a pen and paper - I know, it's pretty revolutionary - in priority order to work through. Close the inbox. Cross through items on your list. Its amazing how that simple process can help feel like you are "winning" t the day. Decline any meetings invites that aren't relevant. And for those meetings you have to go to, make sure there is an agenda with a clear purpose, and any actions noted.

How do you strike the right balance between writing code and dealing with other issues?

This is really tough. The thing that makes this easier, is knowing you have a team of people who are as good, if not better, than you at coding. So, there is no need to worry that the code will get written. Of course you should always try and devote at least some time in your week to writing code, but nothing that will take longer than a day and nothing that would jeopardise the project if you had to drop it.... which you most likely will.

Getting started with Dialogue for Umbraco

Following a great talk at the 2014 UK Umbraco Festival by Lee Messenger from Aptitude I've was inspired to try Dialogue. Dialogue is an forum package for Umbraco 7 based on MVCForum. The current version is a port into Umbraco, with plans to add new features and functionality as the package evolves. This post details the experience I had trying to get up and running with Dialogue and the pitfalls I encountered.

RTFM!

My first attempt at an install went fine......at first. When I spun the application up in the browser however I encountered the error message

The specified table does not exist [DialogueTopic]

Turns out I had furiously clicked all the defaults when installing Umbraco and was running the site against Sql CE rather than SQL Express. The package has only been tested with Sql Server Express and Sql CE is not supported as detailed here. 

No post for me?

Once over that hurdle, the next issue I encountered was being unable to create a discussion, or post...... or topic (the UI is a little ambiguous about it's terms). No matter how much I searched I could not find a setting in the default forum created by the package. No settings in the forum to enable posting. No settings against the member. This was all the UI presented;

........and so, to the code

Turns out the display of the "create topic" button is controlled by the following clause in one of the views;

@if (Model.LoggedOnUser != null && Model.LoggedOnUser.DisablePosting != true && Model.UserCanPostTopics)

The test user I created met the first two conditions, but UserCanPostTopics was set to false. A quick post in the Umbraco community forum and a swift response from Dan Lister pointed out that the UserCanPostTopics setting is set against the category.

Each category allows for fine grained permissions. Each member group can have distinct permissions, as you can just about see in the screenshot above. One of these permissions is "Create Topics". Once enabled on the "Dialogue Standard" group the button appeared in the UI and I could create topics. As a suggestion, it might be worth adding this permission by default to the initial category created by the install. 

So far, the package looks great and I'm looking forward to exploring it further in te ecoming weeks.

Paper prototyping HTML layout

TL;DR

Paper prototyping is good. It saves you time. So why not extend the principle to other areas of your build, like your layout, and save more time?

On the last few projects at work we have trialled paper prototyping. For the uninitiated, paper prototyping involves using pencils and paper to sketch out user interface ideas and quickly iterate on those ideas, getting closer to the final UI much earlier in the project. On the whole it has worked very well, and from a developer perspective a lot of UI issues which often only get considered during the build are resolved before a single development key has been stroked.

So on our latest project, I brought the concept of paper prototyping to another area of development which, like UI, can be ambiguous, contentious and time consuming. The HTML structure of a site. This post is a quick how to for paper-prototyping your next HTML layout.

How to paper prototype your HTML

Ingredients

1. Print outs of key pages of the final site design.
2. Tracing paper
   - If speaking to a designer ask for a "layout pad" for added kudos
3. A lightbox (not required). 
4. More than one developer.

Method

1. Place your printed site design on the lightbox.

2. Place a sheet from your layout pad over the top of your site design.

3. Now start sketching and debating your proposed layouts with your fellow devs.

4. Rinse and repeat.

Sounds simple? It is. A fellow developer and I sat over the lightbox, drawing out our ideas, suggesting layouts and annotating them with simple style attributes to remind us of our initial thoughts on CSS when we came to develop the front end, for example, "float this left", "container with fixed width". Some ideas were quickly dismissed, while others were explore. Some even made it in to the final layout. In under half an hour we had a pretty solid layout which would have taken possibly half a day (if not longer) with just one of us sat in Visual Studio. 

Here are some pictures showing the paper prototypes of the layout my colleague and I created as we thought through and discussed the available options for a recent project. 

Attempt 1

Attempt 2

Attempt 3 with design print out beneath.

Ok, but what's in it for me?

This really was just an experiment to see if we could extend the principles of paper prototyping to other areas of the development process to reduce the time spent developing. 

By getting out from behind the keyboard, picking up a pencil and discussing ideas, we got to a solid layout in a comparatively short space of time, collaborating and sharing ideas along the way. 

I would urge other developers to give it a try. Even without the lightbox, just sit around the table and discuss how you would lay a site out. You may even save time and produce a finished site quicker.

A testement to this methods success is that since comitting the initial paper protoptype in to the project's MVC layout, it has only been altered a few times. 

Creating a better developer test

Hate is a strong word. Its a word that should be used sparingly. A word only wheeled out in times of desperation. A word reserved for the things in life you would prefer never to see again.

I hate developer tests. Let me be unequivocal here for a moment. I really hate developer tests. As a developer of 13 or so years I have sat my fair share of these things, some better than others, but I doubt any of them were the deciding factor in me getting the job or not.

Haters gonna hate

One of my main gripes is that most developer tests prove nothing. 

"What is the name of the Nuget scaffolding package for Asp.Net MVC3?"
"List the events in page life cycle."
"List all templates of the Repeater control"

If you can answer the three questions above, congratulations, you can obviously Google with the best of them. Every developer test will have a few questions like those above. Questions like this prove nothing. So you can remember that there is a SeparatorTemplate in a repeater. What has this told your prospective employer? Precisely nothing. Having Google has abstracted away this requirement in a developer. When it took 30 mins to scour the weighty tomes on the office shelf for an answer to a technical question, the ability to recall obscure facts and figures was essential. As developers in 2013 we all have access to all the information, all the time. The need for us to remember dusty corners of our chosen frameworks has gone. Get over it.

More important than CODE?!

It a well known phenomenon that the bar for developer tests is low. But why is this the case? Is it perhaps because a developer's ability to write code is secondary? When hiring a developer, there are criteria that should be ranked higher than their ability to code. What could be more important than your code? Your ability to explain your code? Your ability to share your ideas with your colleagues? Are you excited by new developments in your chosen field? Your fit with the wider organisation culture? Your ability to plan your workload and prioritise? While a developers ability to write code is clearly a core skill, it is not the only one which should be considered when hiring. 

Take a sad song and make it better

I was recently asked to write a developer test as my organisation is looking to expand the current team and the existing test needed a little refresh. I wanted my developer test to not only test if the candidate could write code, but if the could read code and understand requirements. I also wanted my developer test to contain a variety of questions from simple programming ones - to make sure they understand general programming constructs like object-orientation - to tasks which our developers do everyday, like writing a LINQ query to filter a list of objects, or writing some JQuery to wire up click handlers. I included a few bug spotting questions to test candidates code reading abilities.

Finally, there was a section asking candidates to write a web page, showing a list of orders and the products contained within each order. A very low bar indeed, but this simple task tells me if the prospective candidate can structure their code, and write code which is reusable. Their ability to read and understand (albeit simple) instructions is also tested as well as their attention to detail.

Below are two sample questions to give a flavour of what I ended up with.

Define a Orange as a c# object. Include any object hierarchy and properties you see fit.

The following code contains some bugs. Please list below the code snippet any bugs you can see.

Hopefully my developer test will test more that just the candidates ability to retain information. Hopefully it will tell me more about the prospective candidates than other tests full of obscure framework related questions. Hopefully it will go some way to recruiting a better developer. Hopefully.

Entity Framework 5 and ValidateOnSaveEnabled

I have just started a new project and having had previous happy times with Entity Framework, I Nuget'ed in the latest version. All was going well until I tried to update an entity. I have the following code;

using (var c = new EFContext()) 
{       
    Data.User u = new Data.User() { UserId = UserId };       
    c.Users.Attach(u);       
    u.FailedPasswordAttemptCount = newFailedPasswordAttemptCount;       
    c.SaveChanges(); 
}

In EF4, my understanding is that this would send an update statement to the database and only the FailedPasswordAttemptCount would be incremented for the user with the corresponding UserId.

In EF5, this craps out with a DbEntityValidationException as I have a non-nullable field in the user table (UserName).

I could solve this by creating my Data.User object with an empty UserName,

using (var c = new EFContext())
{
      Data.User u = new Data.User() { UserId = UserId, UserName = "" };
      ...
      c.Entry(u).Property("FailedPasswordAttemptCount ").IsModified = true;
      ...
}

but this doesn't seem particularly manageable as more non-nullable fields are added to this and numerous other tables.

It turns out there is now a property in EF called ValidateOnSaveEnabled ValidateOnSaveEnabled is a boolean which determines if entities should be validated automatically when SaveChanges() is invoked. It is set to true by default. Setting this to false got the code working again!

using (var c = new EFContext()) 
{       
    c.Configuration.ValidateOnSaveEnabled = false; 
    Data.User u = new Data.User() { UserId = UserId };       
    c.Users.Attach(u);       
    u.FailedPasswordAttemptCount = newFailedPasswordAttemptCount;       
    c.SaveChanges(); 
} 

MSTest and the DeploymentItem Attribute

I was writing Unit Tests today with MsTest and came across what I thought was a straightforward problem. My test needed to load an Xml document from the file system. Easy, right?

Wrong.

Here is the part of the code that was causing the problem - two lines that I've written in applications, a hundred times before without any issue.

XmlDocument testXmlDocument = new XmlDocument(); testXmlDocument.Load(@".\TestXml\SWHNewFormat.xml");

But when the test ran, it threw the following error

System.IO.DirectoryNotFoundException: Could not find a part of the path 'D:[Path to test project]\bin\Debug\TestXml\SWHNewFormat.xml'.

Turns out that when you run your tests they are deployed to a folder (the path of which is configurable). Any files you want to be deployed with the tests (for example xml files which your tests may need to read) have to be flagged up on the test method (or test class) with the DeploymentItem attribute.

Finding that out was the easy part. Actually getting the fire to deploy to the folder was another matter.

Google. Rinse. Repeat.

Firstly, in Visual Studio I had to set the "Copy to Output Folder" property to "Copy Always" on the files I wanted to deploy with your my tests. Once that was set I then needed to set the DeploymentItem attribute.

The attribute accepts two parameters. The first is the path to the folder that contains the file(s) you want to deploy and the second is optional and the name of the folder that will be created in the deployed folder.

But with both parameters set on the attribute, still my file did not appear in the deploy folder.

Gotcha!

The thing that caught me out was the path in the first parameter is relative to the bin\[CONFIGURATIONNAME] of the test project, so in my case the path I specified in the attribute was

• @".\XmlMangerTests\TestXml"

This translated to the file path 

• "D:[Path to test project]\bin\Debug\XmlMangerTests\TestXml"

The second parameter is the folder name within the test run folder for the copied files. Again in my case I set

• "TestXml"

which translated to the folder path

• D:\[Path to Solution]\TestResults\Deploy_CompName 2012-10-25 11_10_16\Out\TestXml

Once this was set (and if I'm honest after correcting the odd type of two!) the test ran as expected. Of course it failed, but that's a whole other post.