Jeremy Davis
Sitecore, C# and web development
My first time having to configure Solr for Sitecore recently taught me a variety of new things. (I know – how have I managed to avoid it this long?) Most of the basics of the setup have been well documented elsewhere, so I won't repeat any of that. However setting up the site to use the Ninject DI container wasn't as smooth as the documentation suggested, so here are some notes on the issues I hit in case you find yourself stuck:
There's been a bit of a theme in my recent posts about scripting stuff, and that continues this week. I've been looking at some ideas for automating tasks for developers recently, and one of the things I was interested in was being able to get stuff downloaded from dev.sitecore.net without having to do it manually. So, here's some PowerShell that can help you with that...
Last time out I was looking at scripting installs of Solr using plain old PowerShell. Since the Sitecore world is getting to grips with a new PowerShell based install approach with the Sitecore Install Framework (SIF), it seemed like a sensible idea to try porting my ideas to SIF so see how that would work...
I'm sure I've said before that any task you have to do more than once is worth automating. Well recently I've found myself needing to install Solr in a variety of places – so obviously my mind turned to automation. There are lots of ways this can be approached, and some people have already had a go at it for their own needs, but here's my take.
I've spent the last week or so working on the config changes necessary to migrate a client site running Sitecore v8.1 from using Lucene to Solr for its search infrastructure. I've not worked much with Solr before, so this has been a good opportunity for me to learn about how it works and how it gets configured. But when I deployed my changes from my local development environment to a central testing server I discovered some odd behavior which Google didn't help with. So, for the good of search indexes everywhere, here's what happened...
I got the chance to speak at the Manchester Sitecore user group recently, introducing some tools and tricks that can be used to measure site performance while you're developing your Sitecore code. For anyone who wasn't there (and those who were but, want to refer back to what I said) here's a summary of the important bits of content from that talk...
I spent some time working with some code recently, which had some annoying habits of failing oddly in scenarios where nulls got passed into constructors. While I was trying to work around some of these issues, it struck me that tests for parameter handling for constructors are one of those annoying things that tend to make unit testing frustrating. They're annoying boiler-plate to write if you need them, and then a constructor signature changes, you end up with a lot of make-work test changes to do.
So as an exercise in "learning something new", wondered whether I could automate them in a reasonable way...
Recently I've spent some time debugging some issues with a client site. One problem that came up during this work (which, sadly wasn't actually the problem I was looking for) was a set of errors from SQL Replication appearing in the Sitecore logs. In keeping with my previous ranting about keeping your Sitecore logs as error free as possible I spent some time working out how to solve this.
Since I'd not looked at databases at this sort of level for some considerable time, I'm writing down some notes for my future self, next time I have to worry about this sort of thing...
Following on from my previous post about things to think about if you're new to upgrading a Sitecore project in your development environment, there was another side of the issue of upgrading I wanted to point out – some of your deployment choices...
Every so often I get asked to look at existing Sitecore installs and write up reports on what's good and what's not so good about them. I spend time looking at lots of stuff, like the infrastructure, the databases, the code and security. But time after time I find myself writing up a similar issue...
