Creating a SQL Alias

To help standardize the connectionstrings across your team’s development machines. You can all use the same sql alias, database name, username and password. The last three are easily configurable however the sql alias isn’t so obvious. Here’s a simple set of instructions to get it working.

My environment at time of this post is Windows 8.1, SQL Server 2014 Express.

  • First you must find the port your server is using through tcp/ip.
  • Open SQL Server Network Configuration
  • Click on the server in question
  • in the right hand pane, right click TCP/IP and select Properties
  • Hit the IP Addresses tab and scroll all the way to the bottom
  • The TCP Dynamic Ports is the port you need to use in the next section.

sqlalias_portconfig

  • Open up Sql Server Configuration Manager
  • Expand SQL Native Client. Choose 32-bit or 64-bit depending on your setup
  • Expend Aliases and create a new entry
  • The port must match the port you found above

sqlserver_sqlalias

Sources:

Disabling NuGet Package Restore

You’ve enabled NuGet Package Restore and want to reverse that decision? Follow the steps below for every csproj in your solution:

  • Close down the solution
  • Delete the .nuget folder on the solution level
  • Open up each csproj in a text editor
  • Find the following XML tags and delete them:
<RestorePackages>true</RestorePackages>  
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />  
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">  
    <PropertyGroup>
      <ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
    </PropertyGroup>
    <Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
</Target>

AngularJS – Why?

Why Angular?

AngularJS is written in Javascript and is a HTML compiler. It was written by developer, Misko Hevery who originally built AngularJS as a solution for building HTML components with functionality. It is now a fully fledged open source framework. It allows you to build complete applications.

It is very easy to learn and you will find a team of developers will quickly get up to speed. It is extremely popular and backed by Google so there are plenty of blogs, solutions and discussions out there.

Features

Angular reduces time building an application compared to other mvc frameworks and thus saves money.

Two way binding is one of the most important features Angular provides. It enables real time updating of a model as soon as the variable binded to the scope is changed.

Similiar to jQuery, Angular allows you to write code on a higher level than as if you were writing raw Javascript.

Accessibility and locality is also supported. The ngAria module automatically makes most of your site accessible.

Currency, Dates and Number data types are localized out of the box. For the String data type, you will have to manage locals yourself. There are several 3rd party libraries out there that can help you with this.

Testing is what angular is all about. There are several frameworks created by the team at Google that allows you cover all aspects of testing. ngMock is used for unit testing, Protractor is used for end to end testing and Karma is an automation test tool.

Architect – Our Website Branching Strategy @ Marie Curie Cancer Care

What we use

We use a combination of Git, EPiServer and have a fairly small team which makes the challenge of using the standard pattern of Gitflow a little more difficult. So we use a part of it to help us get an excellent balance between being responsive to post production issues and minimal branch maintenance.

Challenges

Due to EPiServer controlling it’s Dynamic Data Store via code, we have to be a little more careful when switching branches on a given environment. This is because EPiServer will hide or show properties depending on what is reflected in the latest code. This could lead to impacting someone else’s work.

We do currently experience this in the Develop environment where one developer may have a code base with a deleted or renamed property. This will cause an issue with another developer who has the original property definition. So both sets of code bases will be fighting each other to set that property on the database which results in some exception behaviour when running the website.

An old colleague James Goldswain messaged me with this:

Check out the enableModelSyncCommit=”true” setting in the Episerver.config file, it enables you to disable the auto updating of properties etc, when developing in a team, found it out the hard way 🙂

We have a limited number of environments due to resources and set up time. In an ideal world we would have a new environment spin up from either a feature or hot fix branch so QA can test in isolation from everything and everyone else.

We cannot deploy hot fix or feature branches to the QA environment because that will create blockers for other members of QA. Our QA environments require all testable features to be merged to the develop branch first before deployment.

Strategy

We adjust our branch strategy from Gitflow so we:

  • Do not block any member of the scrum team from working on any environment.
  • Make the effort to keep feature and hotfix branches as short as possible in order to avoid developer going dark
  • Sync both Master and Develop branches at the end of every sprint to ensure everything is up to date. If we are going Gitflow correctly then we shouldn’t need this. (There is an occasionally extra merge commit that moves from Master to Develop due to hotfixes)
  • Feature and hotfix branches get merged as soon as possible to minimise timeline regression.
  • QA and UAT never test on feature or hotfix branches, only Develop and Master.
  • Our team is small enough to warrant not using the release branch workflow as we rarely get any issues with unfinished work at the end of the sprint.

We have four types of branches we use. The Master and Develop branches are static. Hotfix and features branches can be created any number of times and typically have short life spans before being dumped or merged into one of the static branches.

Master branch

According to Gitflow this branch represents our production ready code. We should be able to push code from this branch into production at any time.

However due to our challenges, we also use this branch to deploy to both Staging and Production. This effectively makes it our UAT and Release environments. We push to Production at the end of every sprint and also when hot fixes are merged in.

Develop branch

This is the bucket branch for any development changes that are not post production issues and not significant enough to have their own feature branch.

The branch is also used for both the develop and QA environments. This allows for QA to test singular user stories and provide feedback during the sprint.

Hotfix/xxx branches

Bugs and issues discovered during post production are worked on hot fix branches created from Master. Completed hot fix branches are then moved into both Master and Develop. Once the work is approved we then delete the branch.

Feature/xxx branches

Significant features that can be worked on in isolation are done in their own branch. We create this off Develop. Good examples include a blog or a newsletter sign up. These branches are then worked on by the developers and then must be merged into Develop once they are ready for testing.

These branches should only exist for the length of a sprint. If it needs to exist into the next sprint then ‘commits’ on the Develop branch is merged up into the Feature branch in order to keep it up to date.

Architect – Technical Design Workflow for Creating New Fundraising Page using JustGiving API

JustGiving provides an API that allows charities to create fundraising pages from their own website. Charities benefit from this by being able to integrate this functionality into their own user journeys.

I designed a user journey workflow for a user to create a JustGiving Fundraising Page in remembrance of someone for where I currently work.

From a technical perspective I worked on this taking into consideration the capability and limitations of the JustGiving API. This is so I could empower our UX guys with the right information in order to make the user journey as efficient at possible and not to get hindered by technical limitations later on in the process.

My initial thought was I needed to create a journey that allowed the user to take a minimum amount of actions to get to the end goal of creating a fundraising page. Anything after that could be included as an enhancement or additional requirements from the business that hold value else where.


This what I took into consideration is:

  • You require an active Just Giving account to create a fundraising page. The workflow supports users who do and do not have a pre-existing account.
  • At this point (as standard with any account functionality) the workflow it forks out and forks back in again ending up with the user that is logged in with an account.
  • We then describe the required fields we must expose and the optionals ones that we could take advantage of.
  • Each relevant step also mentions the correct API call that is needed.

Architect - Design Workflow for Creating New Fundraising Page using JustGiving API

Manipulating an EPiServer Page Programmatically

Creating a Page

Here’s how you can create a page in code from a page type you’ve already defined.

First create a new instance of the page type under another page in the form of a link:

var newBlogPost = ContentRepository.GetDefault<BlogPostPage>(parentLink);

Then set whatever properties you wish to the newBlogPost object.

newBlogPost.Subject = "Creating an EPiServer Page Programmactically";
newBlogPost.Content = "Meta";

Finally call the Save method on EPiServer’s content repository.

ContentRepository.Save(newBlogPost, SaveAction.Publish)


Updating a page

The structure to updating a page is thankfully very similar to creating one.

Load the page you wish to update from the Content Repository. 5 is the id of the page.

var contentReference = new ContentReference(5)
ContentRepository.Get<BlogPostPage>(contentReference);

Create a writeable clone of the update. This allows you to update it’s properties:

var clone = (BlogPostPage)page.CreateWritableClone();

Update a properties of the cloned page

clone.Subject = "Creating an EPiServer Page Programmactically";

Call the Content Repository to Save the page and public it at the same time:

ContentRepository.Save(clone, SaveAction.Publish);


Troubleshooting

When creating a new page and / or block you may get the following exception:

The INSERT statement conflicted with the FOREIGN KEY constraint 'FK_tblContent_tblContentType'. The conflict occurred in database ' ', table 'dbo.tblContentType', column 'pkID'.

This commonly gets throw when there are two developers working against the same database but have different versions of the page / block you are trying to save.