All software development projects that involve Sitecore are faced with the same problem: how to get the Sitecore items (templates, layouts or content) from development to the other environments in a consistent way.
My work at Tahzoo and the work I do for the Dutch Sitecore user group require me to do a lot of communication in distributed teams. Effective and clear communication is difficult, even more so when the team members are at different locations. Having the right tools in place helps a lot. Since there are so many communication tools out there I want to share my opinion on some of these so perhaps you can make a more informed judgment when deciding which tools to use.
Blogging should be hassle free. With my old blog platform, blogging was far from that.
Party this was due because I deviated from the built-in themes and I hacked something custom into it. I always needed to manipulate the html of a post because the paragraphs tags and white space were off… very annoying.
And when blogging gets tedious because of such things you blog less and less. It’s been almost a year since I posted anything, which is of course unacceptable ;).
This is part two of the “Isolating calls to Sitecore.Context…” series. If you haven’t read the Part I please do so to get the right context (pun intended).
In Part I the GetItem() method from ItemProvider returned an actual Sitecore Item. Because of the IItemProvider interface and Sitecore.FakeDb it is possible to return fake Sitecore items and no dependency to the Sitecore context is required in unit tests.
Although unit testing is now possible there are some (minor) downsides to them due to Sitecore.FakeDb:
So lets look at another way of dealing with Sitecore items to get very lean unit tests.
Over the last years I’ve been involved with quite some Sitecore projects, some were true greenfield projects where a solution is created from scratch and some involved ‘only’ customizing components or extending the existing platform with new functionality. I enjoy both types of projects since they each have their challenges. I do want to share my concern from what I’ve seen in some of the latter solutions. Some things that all of these projects had in common were:
Of course all these three points are related. If maintainability is important it is vital to any software project that code is written in such a way that it is unit testable. Although this post concerns isolating Sitecore, it could as well be about isolating calls to a custom database or to a logging component.
This post is intended as a practical guide for the ones involved with these ‘difficult’ projects and are strongly in favor of improving the code base in order to improve the testability and maintainability without spending many man months up front to make it happen.
Directly after Sitecore Symposium Barcelona had finished the Sitecore MVP Summit started. And it started in style. We were taken to Dry Martini The Academy where a cocktail making workshop was organised. The evening was completed with a excellent dinner at Speakeasy.
Michael Seifert, the CEO of Sitecore, opened the Symposium with an excellent keynote about experiences and its role in the current (and future) digital landscape. Experiences should be collected and can actually be shaped for marketing purposes. Michael showcased how Sitecore 8 can help organisations in shaping experiences for their audience.
This week more than 60 Sitecore MVPs from 10 different countries will attend the first global Sitecore MVP summit. I consider myself very fortunate to be one of them :).
There are quite a few Dutch MVPs and many of them are able to join the summit in Miami. For the non-Dutch MVPs who are attending, I’m pretty sure you’ll be able to recognize us ;). (Make sure to check #sitecoremvpsummit on Twitter the next few days!).
The great Larry Wall (author of Perl) claimed that laziness is one of the greatest virtues a programmer could develop. The best programmers are lazy in the sense that they do not write duplicate code or take pleasure in writing boilerplate code. They are efficient in writing code that follows the DRY, KISS and YAGNI principles.
Using extension methods in Visual Studio can really help to reduce writing boilerplate code. Here’s a simple snippet which can be used to create extension methods.
After importing the snippet via Tools > Code Snippets Manager you can use it by typing exm[TAB].
At a recent TechTalk at my employer I gave a presentation about Sitecore. The presentation was targeted towards developers who have no experience with Sitecore whatsoever. I had 30 minutes to explain and show what Sitecore is and that was the biggest challenge of the presentation, there is just too much to tell! Next time I’ll focus on one topic and go more in depth.
The HTML5 presentation is made with reveal.js and I’ve uploaded it to Azure using Dropbox (super easy!).
Have a look and feel free to share and reuse it!
In the last few years I find myself doing more and more (technical) presentations. I have to admit I even start to like it. I absolutely admire great speakers like Scott Hanselman (Microsoft) and Tim Ward (Sitecore/CluedIn). They speak with such passion about technology that I immediately want to use or do whatever they promote. Although my presentation skills are nowhere near the level of these speakers I do have a good grasp of what makes a great presentation. So before becoming a great speaker lets start with creating great slides.
As mentioned in a previous post, having a clear naming convention for unit test methods is important to keep tests readable and maintainable. Sticking to the convention might be difficult at first and require some discipline but is definitely worth it in the long run.
In order to make it easy for myself (and other developers) to use the <UnitOfWork> _ <StateUnderTest> _ <ExpectedBehaviour> naming convention, I’ve created two code snippets, one for NUnit and one for MSTest.
After importing the snippets (see below) you can use the them by typing:
nutest[TAB] (for NUnit)
or
mstest[TAB] (for MSTest)
The resulting code is displayed at the top of this post. The snippets use three placeholders (marked in yellow) which make up the method name using the suggested convention. In addition I’ve added Arrange, Act, Assert comments in order to help structuring the test.
I’m currently following an online TDD course by Roy Osherove. I’m about half way through and although I have quite a bit of experience writing unit tests and using test frameworks I’ve gained a lot of knowledge from the course already. Here are some highlights about good unit tests and test reviews.
Roy stresses the importance of the three pillars of a good unit test:
If any of these are not taken into account during development developers are likely to drop unit tests all together because it will become a burden to use instead of an aid.
