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.
This actually should be a fairly quick post, but one that I have seen a few times over now. It is simply a quick answer to the following question – ‘how can I get a POCO (object) given the Sitecore item?’. Before you question too much, I will also explain why the answer is (mostly) not GlassCast(this Item item). This question crops up reasonably regularly, especially given the number of pipelines / commands where we are presented with the item as an argument. There are actually a few considerations when looking at this question and some better and worse ways of achieving this. This post covers many of the common mistakes I have seen when using Glass Mapper in my implementations.
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.
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.
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.
Ok, so I am sitting in the lobby of the Palau de Congressos de Catalunya for Sitecore Symposium, I guess I should be writing about my experience, my views on the fantastic marketing features and technical innovations that have been presented to us during the event. However I find myself equally struck by the ease in which developers, marketers and other staff have communicated at a large European event with so many different cultures and how welcoming it has all been.
It got me thinking about something I have had on the back burner for a while and it’s time I sorted it out. I will start with this statement; ‘It is my belief that in the majority of respects, building a great Sitecore solution is almost completely the same regardless of whether you are building for single language, or building for multiple languages’. There are also of course a few important differences but that will be outside of the scope of this post, let’s focus on the basics.
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.
So, continuing on the theme of the previous posts, in particular Don’t fight the framework part I I thought it would be a good idea to cover the presentation side of Sitecore in a little more depth, with a particular focus on how bad decisions can affect implementation in the future. I chose this topic because from day 1 (as an umbraco and e-commerce developer and beforehand) it has been my belief that one of the most important part of any system is the users (lets face it – fantastic architecture with a crumby user interface means its only the dev’s that use the software – did someone say Oracle).
I could probably write another 10 – 20 posts just on the subject of the presentation side of Sitecore, but I have tried to distil some of the key points for this series and in particular the common pitfalls and/or lack of knowledge that leads us to make bad decisions (as with all these sorts of posts – of course – I too have been guilty).
Something I’ve been involved with quite a lot is making multi-lingual sites work in Sitecore. Building a multi-lingual site touches on quite a lot of parts of Sitecore and really pushes your understanding. So lets start with the basics:
- Items – versions and specific attention to shared, versioned and unversioned fields
- Deciding whether to have separate trees per language or blend them together in one tree (or even a mix)
- Translating content and whether you need to fall back to a language if a version in the current language isn’t available
- Other niggles we’ll come to
Following on in this series, I found another topic I thought I would cover off from my travels. I guess the theme for this is that ‘just cause its the normal way, doesn’t mean it’s the ONLY way’ with a particular focus on choosing the right tooling from the options that Sitecore ships with. The following is an example of a consistent trend I have encountered and goes a little something like this.
Tree Traversal vs Lucene (or Lucinq or SC7 Search)
Firstly on this point, I will say this – Why are developers so scared of Lucene?? its an amazingly fast solution to a raft of problems and hyper fast to boot. People are quite quick to be jumping up and down about NoSql solutions (which I also love), but as developers you can solve similar problems with Lucene, it is in essence a form of unstructured data store and very mature.