Don’t Fight The Framework – Further down the rabbit hole optimising Sitecore MVC Performance.

I figured I had put this little mini-series too bed with my posts on Strategies to optimise Sitecore MVC performance and Further strategies to optimise MVC performance, it seems not.

I was recently looking into the effect of the @Html.Sitecore().Controller(“”) @Html.Sitecore().Rendering(“{id}”) on the performance of a Sitecore MVC based solution. Here is what I found:

Continue reading

Don’t Fight The Framework – Proof is in the eating pt 1

It feels like a long time ago when we first started this series and it has been a fantastic journey thus far. This series has really taken me back to basics in considering the decisions we make on Sitecore projects and what the medium to long term impact of those decisions is.

I thought therefore I would cover a real-life use case of an issue that incorporates some of these posts and show what advantages they have given me and on occasion, why it is that I would have cornered myself had a chosen another route. The project in question has taken a few experienced developers around 11 months to develop and has grown semi-organically based on the requirements from the users.

I would prefix this post with saying – no solution is perfect, neither ours nor any other solution I have seen thus far in my development career. As you will see, myself and the wider team have made mistakes along the way, but it has been the ability to change those decisions that has been key.

Continue reading

Don’t Fight The Framework – Further strategies to optimise Sitecore MVC Performance.

Following on from Strategies to optimise Sitecore MVC Performance. I thought I would write an update to continue and show where I have got to with my quest to optimise the performance of our Sitecore MVC implementation.

Since my previous post, Sitecore have acknowledged some of my findings, and provided a couple of potential fixes for us to try out. On first investigation – these look promising (though my tests are ongoing). I also started to consider alternative methods of setting up parameters, data sources, caching following on from my findings.

Continue reading

Don’t Fight The Framework – Strategies to optimise Sitecore MVC Performance

After now a couple of weeks of performance optimisations on Sitecore 7.2, I thought I would detail a little bit about ways you can optimise the performance of your MVC based Sitecore solutions.

Before I go any further with this post, I would like to make it clear that I have actively engaged with Sitecore UK and Sitecore support, sent them all of my findings and made performance improvement suggestions based upon my findings. These will hopefully benefit us all in future updates and if you come to the load testing / performance optimisation phase of your project, I would highly recommend you do the same.

Below you will find a summary of the results of my findings during performance and load analysis on Sitecore. For one of my latest builds for a client, we have pretty much followed as close to best practice as we possibly could (including a site review by Sitecore themselves and actions out of it as such), we underwent load testing on the first generation of the clients new site. The site did perform to the acceptance criteria of approximate 12,000 requests a minute that is required for the site at peak time – but not by much. It also VASTLY outperformed it’s predecessor which was a Sitecore site built by a reputable UK Sitecore partner. Since the results were close to the limit though (and to allow for overhead to allow future growth) I found myself having to analyse the performance of various elements of our solution and subsequently of Sitecore itself in order to gain the maximum out of our build.

Continue reading

Sitecore conventions – build your own pipelines

This post is a follow up the post on using workflow I wrote a little while ago. You can read it here.

When you look deeper under the hood you’ll see that Sitecore does quite a lot of things via pipelines. A brief scan of the web.config will show a wide selection ranging from logging in, begin request, rendering fields and so on. These pipelines make it very simple to define a process and to support customisation and patching of that process. As a consequence its something that can be quite useful to include in our own code when we need to perform our own custom steps.

In the previous article, I wrote about how I was talking with another developer about sending newsletters from Sitecore. The original third party had done this as a publish step and checkbox. So the editor would check the box, publish and then the custom code would uncheck the box, save the item and then send the email. However I discussed how there were a number of issues with this approach. In this article, we’ll build on this and see how using pipelines can help.

Continue reading

Don’t Fight The Framework – Unit Testing On Sitecore Pt I

Before I can proceed on in the Life Through A Lens series of blog posts, I thought I would cover something that has been somewhat of a bug bear of mine since I started working on the Sitecore platform, this is Unit Testing. I wanted in particular to address some of the misconceptions with unit testing and on using Glass Mapper in unit test scenarios. I have been using TDD (and as we all do Test After Development) since around 2007 and have learned a lot in this time. Due to this – I have decided to write this post before continuing with the Life Through A Lens Series to give a backdrop of what I feel is a key idea behind unit testing. I feel it is really important to cover off some of the classic TDD mistakes before I get involved with actually demonstrating how I use Glass Mapper to solve some of these problems.

I will before I go any further give a massive nod of the cap to Simon in his improvement of my knowledge in this area. I did know some things on this subject, but his patience and teaching allowed my knowledge to progress significantly beyond where it was at a rate quicker than it would have done otherwise.

Ok, so with the above in mind, I will move on to some of the most common phrases I hear from developers / managers ( / whomever ), these are usually in response to my first day questioning of ‘What unit test / mocking frameworks do you guys use?’. The answer of ‘none’ ( I don’t know why ) still offends me.

Continue reading

Don’t Fight The Framework – Location, Location, Location

Ok, so here in the UK it is a great show on property development, but for the world of Sitecore I actually mean this (It will be common sense to some, and food for thought with others). This post is more likely to help you if you are new to Sitecore.

References to items in code

There are a number of fundamental issues I have encountered over my time with various projects, and this has been mirrored by reviews on my own / others work by Sitecore themselves. I find it an increasing source of frustration to find things like:

var myItem = Sitecore.Context.Database.GetItem(new ID("{some-id}"));

This in itself isn’t the greatest sin in the world, but certainly when working on code that was not originally your own it often makes it trickier to find instances in your code. At least in this case, if the user moves the item, then the code still works. In the following case however (which I see WAY too often for my liking), move it, you lose it.

var myItem = Sitecore.Context.Database.GetItem("/sitecore/content/somepathorother");

So, simply put – add your references to a central config, be it class / xml (please don’t) or whatever, that you can reference throughout your site. I personally like the convention of SubClasses to achieve this, such as:

public class SitecoreIds
{
   public class TemplateIds
   {
      public static ID MyTemplateId
      {
         get { return new ID("my id"); }
      }
   }

   public class Paths
   {
      public static string MyPath
      {
         get { return "/sitecore/content/mypath"; } // returning as a static property means assemblies that reference this don't 'bake it in' - personal
      }
   }
}

I still prefer to store IDs rather than Guids / String representations as I find in my experience the api more often requires ID than the guids or strings, it’s no doubt a personal thing.

Template Location
So, we have covered an approach to referencing your items, what about where they actually live.

This of course is subjective, but in my opinion I like to think of a strategy like this:

  • Sitecore has default locations for a reason – User Defined beneath Templates
  • For reusable modules development, Sitecore also has folders dedicated to just such a purpose (look under system for one example)

Rendering / Sublayout location

This is a slightly moot point, but I find it quite frustrating when I am faced with solutions where developers have not isolated the renderings into the site that they belong, this I feel often stems from the belief that either.

a) Everything will be ultimately re-usable (kudos if you can manage it)
or b) They never intended to have more than one site.

Sitecore is a multi-site platform, look up the Billy Crystal style definition of assume 😀

A simple folder structure maybe grouping sitea, siteb and shared will often suffice and make life easier for us.

I personally also find it useful to mimic the structure of the Renderings in the Sitecore database, its a personal thing but I feel it helps me stay sane.

Conclusion

It’s great that you know where your code is, for everybody else it is a learning exercise that can be made so much easier if you follow convention, it also helps a tonne in upgrade.

Don’t Fight The Framework – Question, question, question

Here is something that I have found all too often in my career working with a multitude of CMS systems, and it is this :-

Sitecore is not a product that you can build for a customer and then forget about, customers to get the best from their solutions should be hand held, communicated with, and as developers / vendors – this provides long term work opportunity. It is all to often that (especially in the Digital Media Agency environments) I find Developers blindly following a spec (often written by someone who does not know the framework) and not considering the bigger / long term picture. In my experience, this often leads to a lot of work later that would have been next to no work during the original implementation.

In my post on The parallels between single language and multi-language developments I covered just such a question. It eludes to statements you will often here from clients which could include (but far from limited to), things like:

  • We will only ever have an English site
  • We will only ever run one site on our Sitecore solution
  • We will always use workflow

Our journey in development should always be governed by a mix of knowledge gained through a variety of mediums, the fact you are even reading this post suggests you are eager to learn more about the product(s) you work with. This added to your own experience and the shared experience of your wider team should lead to you making ever increasingly better decisions with each solution you build. So my responses (based on my own experience and in my head) to this are usually something along the lines of:

  • Really…..? Your ‘massive’ brand that you have sold us on since the pitching process has no plans to EVER consider beyond the English market?
  • Ok – so your CEO is going to build your brand and sit on their ass and watch the money fly in without thinking – ‘hey we could make some more by..’
  • You really haven’t thought about basics like – every image, every tiny translation change… well just… EVERY CHANGE! It’s great that some clients have vast content entry teams with the resources to achieve this. Many clients though will end up with an army wanting ammo and a single guy with the keys to the ammo store (chips down – that guy is gonna get a beating).

The above are all examples of me using my experience / knowledge to question whether the decisions that have been made (often in the developers absence and often by sales / accounts folk) will actually hold up.

Continue reading

Don’t Fight The Framework – Sitecore’s built on Sitecore so build your site on Sitecore.

This one will be a relatively quick one ( hopefully before the girlfriend finds out I am working on our holiday 😉 ). Continuing on in the Don’t Fight The Framework series, I thought I would discuss a topic that has kind of formed the more I have worked with Web Content Management Systems such as Sitecore. As me and Simon used to band about in our development exploits (usually in a faux Danish accent) – ‘Sitecore is built on Sitecore’ and it got me thinking…

The basic premise is this – we as developers are often guilty of just opening visual studio and hacking away at our latest interesting issues / projects & crazy solutions to problems. I have found particularly with Sitecore you can sometimes get a feel for how successful a Sitecore solution you have developed by how much time you spend in Visual Studio ( not including Rocks before I get some clever < Insert suitable name for smart person > piping up! ). It is my opinion that the more flexible your Sitecore build is, the less time you should be spending in your development tools, and generally, if you are spending time, its to look up how you have used the rendering parameters / pipelines / data sources etc are controlled by the user interaction and potentially what templates are expected.

Continue reading