Interfaces are more or less basic stuff in programming and in Episerver development. You probably have seen these guys (IThisAndThat, IEtc..) all over the reference solutions (AlloyDemoKit, Quicksilver, …). In this blogpost, I’ll be taking a concrete approach how to make one of the AlloyDemoKit’s content blocks more compatible with other content elements using an Interface.
I have had the privilege to participate in couple of Episerver’s trainings. Both for the CMS and for the Commerce. CMS training was a 3-day CMS fundamentals course and the Commerce was a 5-day online boot camp session.
For those who are thinking about participating, and wondering will these trainings give you any useful insights, or you are just interested in the topic, I would recommend keep on reading.
In the previous post, I wrote about profiling your Episerver site and how important it is to spot bugs and performance issues early on. Now it’s time to create some traffic in your development environment and analyse how well your site performs under load.
We all know that bug happens. They are inevitable during development, and basically in every step-in software lifecycle. The thing that makes a difference, is to catch them as early as you can. You do not want to be in a situation where production site is suffering huge performance issues with only handful of requests.
Ever had a problem where you would like to open or get the full public address of a page from the editor view in Episerver? Or is it a problem at all?