Genuine Juice

I had a conversation with Fitzpaul Reid, an application developer who has been with Genuine since 2007 about some of the ins and outs of Sitecore, one of the many content management systems we specialize in. Fitz has been busy working on a few upcoming projects that are releasing in the near future.

What are some common misperceptions of Sitecore?

• Sitecore is light weight – Often times, clients will try to slim down the server architecture of a Sitecore implementation. While there are several other factors involved (amount of pages, using lucene to cut down database strain, server memory), more often than not, the Sitecore database should be kept separate from the production server, Especially if Online Marketing Suite (OMS) is involved.
• Never use XSLT in a Sitecore deployment, and never use Sitecore query in xslt. Genuine believes this is an untrue mandate. Limited Sitecore query isn’t a huge performance strain. Genuine never uses Sitecore Query, however we utilize XML/XSLT. We believe once XSLT is handling just the presentation layer, and all logic has been handled prior to building an XML object, performance is acceptable.
• Push it up then forget it – Once a Sitecore deployment has occurred, that is where the REAL fun begins from a development and IT point of view. Once live, logs and performance should be monitored for a month or two after, to make sure everything is working, and to see if any improvements can be made, from IIS all the way to code revision.

What type of question would you ask a developer to see if they really know Sitecore and what kind of answer would you hope to hear?

Q: What is the heaviest (performance wise) action that is performed constantly when developing a Sitecore project, and how can you minimize this call?

A: Sitecore’s GetItem call. No matter how optimized your logic is, if you have to retrieve a complex Sitecore item, there is performance strain. Genuine minimizes these calls by using lucene to build indexes of the common fields per item, and query the index for data first. If the data is not available, THEN we utilize that call.

What’s the newest plugin you’ve written and why?

Code Generation.

Most big agencies that are serious about using Sitecore use their own version of code generation,which helps cut down development time and cost. At Genuine, we have created our own version of this, with three main priorities:

• Site performance
• Creative design flexibility
• Development flexibility

Genuine’s needs for this push some boundaries, and we needed to make sure we had the tools to implement whatever our design/creative teams came up with. Our code generation also allows us to keep a true separation between FED’s (front end developers)and BED’s (back end developers), allowing both to work independently, and at the same time. This can cut the time in half. And by leveraging Genuine’s approach to caching and getting only the data we need from Sitecore when we need it, performance is optimal.