Recently we have been involved in a bit of Java development, using the CMS ‘MagnoliaCMS’. We have not found using this CMS the most enjoyable of experiences.  One point of frustration for us was the deployment process. If you are unfamiliar with MagnoliaCMS, it operates with at least 2 instances: 1 author site (where you input the content and test it) and at least 1 public site. The environmental setup we had for this instance was 1 pre production author site, 2 load balanced pre production public sites, 1 live author site, and 2 load balanced live public sites. Because each of these instances has a different repository and SQL server connection they all need to have separate builds made for them. In our setup, we had create build scripts for each of these instances which produced WAR files which could be deployed onto a Tomcat server. Unfortunately each of these builds took about 5 minutes to complete and then after those were created we had to copy them to the off site servers where the preproduction and live sites are hosted. This would take at least a few minutes for the couple hundred MB large WAR files each. Then, if there was a mistake made in the code or a problem with the WAR file we would be in the middle of this long manual process and have to begin from the start again. Not a very enjoyable experience.

Here is what we did to make it better: Used the power of cruise control.

We created a couple of targets for our cruise control project.

1. Build
2. Deploy
3. Build and deploy (just depends on the previous 2)

I will go over our requirements in each step:

1. Build

We needed to be able to get the solution to build on the Cruise Control server. So, what we had to do was install Java JDK and Maven on the CC server as that is the build manager for MagnoliaCMS. We created a batch file which built all the instances:

cd C:\CruiseControlWorkingDirs\JavaSolution\cms
call C:\Maven\bin\mvn clean install -P stageAuthor
call C:\Maven\bin\mvn clean install -P stagePublic1
call C:\Maven\bin\mvn clean install -P stagePublic2
call C:\Maven\bin\mvn clean install -P prodAuthor
call C:\Maven\bin\mvn clean install -P prodPublic1
call C:\Maven\bin\mvn clean install -P prodPublic2

Then, we had to call that batch file from cruise control:

<target name=”build”>
<echo message=”Build All” />
<exec program=”cmd.exe” commandline=”/C C:\CruiseControlWorkingDirs\JavaSolution\builds.bat” />
</target>

What we noticed by building like this rather than through Eclipse, the builds actually took a lot less time (about half)  and obviously we didn’t have to click a button to start the next build but it would just rattle through all of them.

2. Deploy

Our next step was to deploy these. However, when I say deploy. It was not actually deploy completely because of the setup of MagnoliaCMS. You can’t deploy MagnoliaCMS through Tomcat like you would another Java site as there are some serious memory leaks in MagnoliaCMS which stay in memory by doing it like this. So, you need to stop the Tomcat service, put the WAR file in the webapps folder, and then start the service again. Because of this needed process and the fact that our client might be working in the author instance and we needed to limit the times when we actually stopped the Tomcat service. We decided that the cruise control deploy process could just upload the files to the servers and then from there it could be a manual process to move the WAR file around and stop and start the Tomcat service.

Our connection to the external servers where preproduction and live instances are deployed are password protected. So, we had to map the drives so that we could put in the username and password. However, we couldn’t always assume that it was going to be connected because of server restarts, etc. So, we created another batch file to do this:

if exist M: net use M: /d
call net use M: \\111.111.111.111\c$ password /user:username
if exist Z: net use Z: /d
call net use Z: \\111.111.111.112\c$ password /user:username

Next, we had to call this batch file and then copy the war files out (I am only showing 3 of the war files being copied as they are all basically the same):

<target name=”deploy”>
<echo message=”Map Drives” />
<exec program=”cmd.exe” commandline=”/C C:\CruiseControlWorkingDirs\JavaSolution\mapDrives.bat” />
<echo message=”Copy Stage Author” />
<copy
file=”C:\MAVEN_TARGET\stage\cms-stage.war”
tofile=”M:\Uploads\stage\cms-stage.war”
overwrite=”true”    />

<echo message=”Copy Stage Public 1″ />
<copy
file=”C:\MAVEN_TARGET\stage\magnoliaPublicStage1.war”
tofile=”M:\Uploads\stage\magnoliaPublicStage1.war”
overwrite=”true”    />

<echo message=”Copy Prod Author” />
<copy
file=”C:\MAVEN_TARGET\prod\cms.war”
tofile=”Z:\Uploads\prod\cms.war”
overwrite=”true”    />

3. Build and Deploy

Cruise control makes it easy to use other targets. The Build and Deploy just combines the previous 2 targets:

<target name=”builddeploy” depends=”build,deploy”>
<echo message=”Built and deployed” />
</target>

This has made our lives so much easier and enjoyable. It turned a 40 minute manual process into the click of a button and then about 20 minutes later we could just remote onto the server and all the WAR files were there ready to be used on Tomcat. Our deployment time was reduced significantly and so was our frustration with the deployment process.

These same techniques could be used in any technologies where you can build the solution by command line and then you can copy to your server, using the built in copy of cruise control or you can use Robocopy as we do for our IIS website deployments from CruiseControl.

First Umbraco Glasgow Meet Up – Equator hosting

We at Equator have been using Umbraco as our primary open source CMS for several years now. Why? Easy to work with, very extendable and suits our core technical resource skill set perfectly.

The community behind Umbraco is the thing that really makes it work and the fact that updates, bug fixes and new versions are released more regularly that any licensed CMS I have used, is testament to that.

We are however guilty of perhaps not giving enough back to the community so we are super pleased to be hosting the first ever Glasgow Umbraco meet up. I’m not sure what will happen or who will turn up but I will blog about it after it has taken place this Monday (5th Dec 2011).

I am very much looking forward to hearing from a couple of key Umbraco folks, but also just looking forward to meeting up with other developers who use the CMS regularly.

All for now!

In this post I’m continuing my showcase of the packages that have made their way into our in-house Umbraco starter. This is simply a efficient solution we have set-up to quickly kick start projects with our favourite packages pre-installed.

Standard Values in Umbraco

Another godsend to website administrators is the simple yet effective, Standard Values in Umbraco from Umbraco HQ’s newest employee, Morten Christensen. This allows you to give a doctype some default values so on creating a new node some of the work may already be done for you. Bonus. Maybe that’s setting the default checkbox value for a question to true or the a node picker value.

One area where we use this most is setting the title and meta title of a page to the name of the node using a predefined $name$  key. We keep this separate from the name of the node as it allows us to change the h1 tag without reflecting the URL while avoiding the setting up any redirects. More often than not though the title and the node names are the same so this saves the admin the bother. A #h5yr to Morten for this gem.

I’ve been writing a load of Selenium tests that run on regular intervals on our Cruise Control box. At present the CI instance of the site shares the same database as the one I’m developing on.

I found that my tests where running just fine locally but failing on the remote box. This was due to changes to some node data that weren’t being carried over since the umbraco.config is not checked in. To get around simply add a prebuild task to delete the umbraco.config before running the test.

<prebuild>
  <exec>
      <executable>cmd.exe</executable>
      <buildArgs>/c "if exist "C:\CruiseControlWorkingDirs\MyProject\WebsiteDir\App_Data\umbraco.config" del 
          "C:\CruiseControlWorkingDirs\MyProject\WebsiteDir\App_Data\umbraco.config" "</buildArgs>
  </exec>
</prebuild>

I’ve personally never worked with WatiN or other alternatives to Selenium but I’m pretty sure the same idea would apply.

Here are Equator we churn out a lot of Umbraco website’s. Hardly a week goes by when we’re not pressing the big red go live button. Because of this it is important for us to get a project kick started as efficiently as possible. To do this we have setup our own, constantly evolving starter kit containing our favourite datatypes, sections and tools. At the start of every project we simply take a copy of the files and database and get to work.

In this series of posts I’ll cover some of the packages that have made their way into our white label. Starting with the simplest but easily one of the best for improving webmaster usability…

FamFamFam Icons

Admin panel usability is key to a good CMS – less mistakes and fresher content since the webmaster won’t grudge using the system. Out of the box, Umbraco doesn’t come with too many icons for your nodes. The FamFamFam icon pack includes literally hundreds of extra icons to apply to your nodes from a simple  for the home node to a  for the shopping basket node. Spotting the node you want from the content tree now becomes so much fasterwhen you have a specific icon to help you.

Now sifting through 700+ icons to pick the best one becomes a bit of a pain when you create that new doctype so we’ve cut that number down by a few hundred. The icons in the drop down is automatically generated from all images in the your website’s /umbraco/images/umbraco/ directory so you can simply delete all those you don’t need without any other changes necessary. For example I can’t see any projects in the near future where we’ll need a bomb icon  but if we do I’ll be sure to add it back in.

Extending what FamFamFam has done is pretty simple too. Simply add any 16 by 16 pixel icon into the folder. For example we’ve added in a bunch of social media icons for use with say a Facebook page or Twitter sidebar widget.

One last thing. It’s important you remember to add max-expiry caching to this icons directory otherwise every hit of a doctype section will include hundreds of extra requests to the server to check the freshness of the icons in your browser cache. It may not be a big deal if your working on the same machine as the files but you’ll definitely notice it otherwise.

Have your own starter kit? Have an idea how we could improve it? Leave a comment.

In the early days of umbraco, it could be said that to create complex sites you would end up needing to have many many nodes. A common thing you encounter on a website is a list and being that we are developing in Umbraco we want to make that list CMS’able. Your options were to create  individual nodes or to give the user free reign and use a rich text editor. Teh rich text editor is just a bad idea because I have found that if you do give the power to the user, then they will find a way to mess it up. If each item in the list is only a line of text, then you end up creating a node for each line of text which just becomes messy and overkill. There is a package out there for this problem. It is the repeatable custom content package. http://our.umbraco.org/projects/backoffice-extensions/repeatable-custom-content

This package is quite excellent in being able to repeat pieces of information from as simple as a single line of text in the example above or as complex as a table with multiple text inputs and booleans. What I have found to be the most helpful with these repeatable custom content elements that I have created is to put them into an object (or a predefined object, if avaible) and then attach them to a repeater on a usercontrol to display them.

In the single line of text example, I am just using a string as my object and then I create a List of strings which I load with the content from my umbraco node:

public static List<string> GetValuesFromListing(int nodeId, string propertyAlias)
{
List<string> values = new List<string>();

// Get the XML for the umbraco node
XPathNodeIterator xpathIterator = umbraco.library.GetXmlNodeById(nodeId.ToString());
XElement node = XElement.Parse(xpathIterator.Current.OuterXml);

// Get the linked list node
var list = node.Descendants(propertyAlias).FirstOrDefault();

if (list != null)
{

// Loop over all the nodes in the linked list
foreach (var value in list.Descendants(“data”))
{
if (!string.IsNullOrEmpty(value.Value))
{
values.Add(value.Value.ToString());
}

}

}
return values;
}

Then, on my user control, I create a Repeater control and use my List<string> of items from my repeatable custom content as my datasource in order to have my HTML separated from logic.

One area where I have found repeatable custom content lacking is in the media picker as once the piece of media is selected, the preview of the image is not shown which makes it a bit difficult for the user to know what has been previously selected. Fortunately, there is another great package out there for this purpose. The Digibiz Advanced Media Picker: http://our.umbraco.org/projects/backoffice-extensions/digibiz-advanced-media-picker

This works on the same idea but just with media items. They have just released a new version and it is full of great features such as restricting which types of media can be uploaded in addition to their other features of restricting how many pieces of media you want to use and getting to choose how to export the data. You would get the data out in the same was as above in traversing the XML (obviously the code will be a bit different from above because the XML will be laid out differently) and parsing it into an object which can then be used in a repeater.

So, there are a couple of options in repeating content in Umbraco which is a real boost to keeping things clean in your back end in addition to proper restrictions on the CMS editor.

This week I had the chance to try out Ninject as a dependency injector for .NET. The revised Ninject platform is pitched as the simple way to perform dependency injection and get rid of the lines and lines of XML usually required for configuration. For the purposes of this post we’ll go through a simple example of constructor injection, as the simplest and most useful method.

At the top level we need a Kernel object, which stores all our bindings and from which we request any of our dependent objects.

  IKernel kernel =  new StandardKernel(new ShapeModule());

The constructor for a StandardKernel will take any number of Ninject Modules, which define the dependency bindings. Construction of a basic module requires only for the class to extend NinjectModule and override the Load() method which will be called when the module is passed to our Kernel. In the example below we have the ShapeModule which is binding either the Circle class or the Square class to the IShape interface, depending on the contents of the application configuration file.

  public class ShapeModule : NinjectModule
  {
    public override void Load()
    {
      if (ConfigurationManager.AppSettings["Shape"] == "Circle")
        Bind<IShape>().To<Circle>();
      else
        Bind<IShape>().To<Square>();
    }
  }

Lastly, all we have to do is define our interfaces (IShape) and classes (Circle & Square) and provide some suitable methods. Let’s assume that we’ve done this and defined the Print() method which prints a string to the console. We then get our IShape object from the Kernel and call the Print() method like so:

  IShape unknownShape = kernel.Get<IShape>();
  unknownShape.Print();

Depending on the contents of our configuration file, the output will differ as shown below:

Configuration File – Shape = “Circle”

Output: I'm a circle

Configuration File – Shape = “Square”

Output: I'm a square

Recently I was asked to add full page background images to website. The only requirement was that the image filled the entire screen from top to bottom – even if the window size changes. After investigating ways to do this (many of which rely on JavaScript), I discovered a good way to achieve this effect is to use the background-size property in CSS3.

Various factors need considered when adding full size background images to a website which include:

Image style

Keep in mind that most of the image will be covered with page content and (depending on the design) often the edges are the only section the user will see.

Image dimensions

I recommend 1024px as an in-between – although media queries could serve more suitable sizes for smaller devices.

File size

For the 1024px version I would recommend aiming for between 50k and 80k – remember this is a background image.

The code

html {
        background: url(background.jpg) no-repeat center center fixed;
        -webkit-background-size: cover;
        -moz-background-size: cover;
        -o-background-size: cover;
        background-size: cover;
}

More information: You will notice some vendor specific properties are needed for now until the background-size property reaches candidate recommendation status. This approach allows any vendor-specific extension to coexist with any future (or current) CSS properties without causing conflicts because, according to the W3C specifications, a CSS property name will never begin with a dash or an underscore.

Browser support

This lightweight technique works in all modern browsers including IE9 onward and depending on the site requirements can be served for IE8 and below using the following…

html
     {
        -ms-filter:"progid:DXImageTransform.Microsoft.AlphaImageLoader(src='', sizingMethod='scale')";
        filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='', sizingMethod='scale');
     }

If you have been living in a cave for the last year you may have missed the news that there is a new kid in town: Responsive Web Design.  The days of building separate ‘mobile’ versions of your web site are fast disappearing.  Using the principles of responsive web design you can build a single site that can cleverly morph and adapt its layout to optimally display itself on a variety of screen sizes.  But wait, don’t run off and start Google searching just yet! Often people get excited about responsive web design and forget that building a web site for mobile devices is about more than just optimising the display.  Not everyone has an unlimited data plan and not everyone likes having their hand slowly cooked by overheating mobile device that are being forced to work their socks off to display ‘heavy’ web pages.  So what should you be doing?  Well the exact answer depends on the design of your pages but there are some simple rules of thumb:

• Optimise your image resolutions for each display,
• If content is initially hosted in some invisible container then load it via Ajax if/when required or adopt a lazy loading technique,
• Minimise the number of requests and the number of bytes transmitted to your users.

In actual fact, these are things you should be doing for the majority of your sites regardless of whether you are targeting mobile devices or not.  Yeah, yeah you have heard all this before, but before you hit the back button on your browser pause for a second and ask yourself these questions:

• Be honest, do you actually do this for the web sites you build?
• Is it a relatively smooth and hassle free process?
• Does the process work for both ASP.Net Web forms and ASP.Net MVC?
• Does your process scale for large development teams?

Most artists will tell you that a painting is never ‘finished’ and the same applies to web sites especially when it comes to optimisation.  You need to consider the return on investment.  Can you justify spending weeks investigating and implementing every optimisation you can think of?  Probably not but thankfully, like most things in life, 10% of the effort will yield 90% of the benefit.  There are a large number of tools out there so which ones should you use?  Well, that depends on your requirements.  Here are mine:

• It has to work as an automated and seamless part of the build process,
• The process has to work well if you are working by yourself on a project or with a team of developers,
• It has to produce version-able output,
• It has to work on ASP.Net Web Forms and ASP.Net MVC projects.

In this series of blog posts I plan to investigate some of the options that are out there and see if anything fits the bill.

Here’s a wee introduction to some basic best practice techniques resulting in easier to maintain CSS.

Define default Typography styling

Headings H1 – H6

Define default styling for headings h1 – h6. The default styling should be defined at the top of the CSS file and modified as necessary for variations in styling i.e Styling specific to a page component.

Headings should always show a hierarchy indicating levels of importance, so your h1 should be in the largest font-size and h6 being the smallest.

Links and other common content elements

The same approach mentioned above should also be applied to common content elements such links, paragraphs, numbered lists, unordered list etc. Default styling for each common element should be defined at the top for the CSS file and overridden as necessary.

For links, make sure to define styling for each of the states – link, visited, hover, active, focus.

The selectors for each state is explained below…

• :link – this state can be used to define styling for when the link is not in use.
• :visited – this state indicates the link has been used before, the link has already been clicked on.
• :hover – this state indicates the link currently has the cursor/pointer hovering over it.
• :active – indicates the link is in the process of being clicked.
• :focus – same idea as :active but is used for when a user has tabbed to the link using the keyboard.

a:link,a:visited {
color:#ec008c;
}
a:hover,a:active,a:focus {
color:#ff8cd1;
}