The concept of rinse and repeat is try to keep development very iterative and automate the development process locally. Gulp and Grunt have been huge for task runners for frontend developers when it comes to preprocessors for LESS or SASS. Or, adding a linter for JavaScript development. It helps us get feedback quickly while we are developing. For Sitecore development, Team Development for Sitecore (TDS) has been a great asset by simply 

 in Visual Studio and TDS will deploy your site to a local sandbox.

If the developer does not have TDS, then you need an alternative or perhaps you need a lighter process that only updates assets like JavaScript and StyleSheet files and Views.

In this post, there are a few solutions that can help with development:

This post assumes you have some experience with Node.js and NPM.

Outside your C# project directory, you will want to start a 

 file. Below is an example one that I created:

install task runners for project and use MSBuild for build

blog-post-rinserepeat

Once we have development dependencies defined, we need to run a couple commands to get setup:

 in the same location for managing the different tasks:

With Gulp, the packages we will need are:

Gulp and Gulp CLI is typical, but I will explain why Gulp Copy and Gulp Shell will be used.

There are a couple ways you could go about copying files around. The two ways I will handle that is first with Gulp Copy and the second with MSBuild Extensions Pack particularly RoboCopy. Gulp Copy is useful if I'm managing dependencies to a JavaScript framework like AngularJS.

If I wanted to manage my JavaScript frameworks with NPM, then I can simply add the dependency to the 

. However, I don't like having to reference or copy over dependencies from 

 manually so I can add a task to copy what I need:

. This helps with any upgrades in the future and should be low maintenance to manage it.

Gulp Shell is useful because I will use that to execute any command I need on command line such as 

. To get setup with running MSBuild from Gulp we will need to add another task for 

msbuild MyWebProject.csproj /p:Configuration=Debug

. I also have a dependency to another task I created 

. I may have NuGet packages that are needed prior to build so I can also run 

 which is changing the working directory.

 since we have added the task as a sub task to the 

Now, all we need is a watcher to build our project automatically when we change a file in the project. Gulp comes with a watcher. We can add that as follows:

 task. When we make changes in Visual Studio, we can get a build on the project automatically. This is not huge because we all know we can use a keyboard shortcut with Visual Studio to build the solution. But, it is a good illustration on using a watcher to run msbuild for us.

Yet, this might prove to only enhance development. For example, a 

 process to restart and for Sitecore there is some wait time. If I wanted to limit this to my Views and other static files, this might expedite verifying changes with Sitecore development. We can change which files to watch and deploy.

We can build on this and add a couple more tasks such as deploying the project, starting IIS Express for the site and use Browser Sync to refresh the browser automatically.

Let's add a deployment task with Gulp. To do that, we are going to utilize 

 (at the time of downloading this) from the zip file to 

 file will use RoboCopy from MSBuild ExtensionPack to copy files from the build to the folder 

 files. Looking at this build file, we are copying the following directories, their contents and one file:

Finally, we just need to add a gulp task to initiate the deployment to 

Also, update the watch task to start it after the build:

Starting the server will only need to happen when we initially run the gulp command and not with the watcher. I use IIS Express because it is lightwight and allows us to only need to run the site when we are developing. To keep this task contained, we can start the site with a 

. This allows us to spin off another command window and continue with our other gulp tasks.

Browser Sync takes a little more investment to get setup. There is some setup to get up and running with Browser Sync.

To get Browser Sync setup, you need to first update your 

 to add a reference to the Browser Sync library:

Browser Sync can act as a server and serve your local static files however we need it to work with IIS Express. So, we will set it up as a proxy server.

To do this, we need to setup an initialization task in gulp:

, we should see the browser open up with the address 

. Since IIS Express is starting in a separate command window, you should see the request come in for the server.

The last part we need is to tell Browser Sync to reload the page after the watch detects that we have changed a file, build the project and deploy it.

To do this, we just need to add another gulp task:

And, update the watch task to start the sync task:

 folder. One issue I ran into was that the browser was reloading the page twice. To remove this problem, we use the 

 option. This gives the deployment enough time before Browser Sync reloads the window.

I have just started using these techniques with building out examples of using Sitecore and AngularJS. In my previous blog post, I started a series on getting started with AngularJS in a Sitecore solution. You can see this in action at 

https://github.com/edames/sitecore-angularjs/tree/part-1

Rinse and Repeat with Sitecore

Web Ethics has so much depth and it is difficult to take one idea and have it cover what it really means to be ethical in building and shipping for the web.

Ethics is the "defending and recommending concepts of right and wrong conduct."1

I like this part of the definition because we can write a topic on web ethics that we feel strongly about.

 tweeted a wonderful resource on ethics for the web, 

Web applications should work for everyone

Web applications should respect a user's privacy and security

Web developers should be considerate of their peers

There are many events in my life as a web developer I felt strongly about in each of these areas and with experience you begin to understand how important each of these are in how you approach building and shipping for the web.

"Am I leaving these people or this project in a better place than when I first started? Did I make an impact?"

I've always asked myself with any engagement, "Am I leaving these people or this project in a better place than when I first started? Did I make an impact?" Source control has always been one of those areas I've felt strongly about. This area I've focused on to grow in and how I serve my peer developers in leaving them in a better place.

Source Control is just one of those things you just can't do without. If you don't have one, start one. Source control allows you to document how the software has changed over time. It is one way you can serve your peers and yourself to have some track record especially when issues show up.

Source Control facilitates good workflow for development

Source control should facilitate a good workflow for promoting and isolating units of work. If you are working on a fire and need to quickly shift gears, you need a good way to isolate that work from any hotfixes you may have to do.

Branching and merging should be painless.

If your source control is hindering you from branching and merging, it is time to find a different source control. I didn't realize how much a disservice I was providing my team when we were using TFS version control (this was prior to TFS supporting Git). And I had accepted that branching and merging was something you try to avoid. A few years ago at the Rocky Mountain Tech Trifecta conference in Denver, I remember a speaker in his session talk about source control and TFS stating "Avoid branching and merging whenever possible". This was easy to believe why he would say this because TFS branching and merging took a lot of effort and pain.

Git was a breath of fresh air. My productivity as a developer increased when I was introduced to feature branching with 

. Branching and merging with Git became painless and really provided great control in delivering features through QA to production.

Understand what you are committing to source control.

 to understand what I've changed especially if the team is working on one branch. Is there something in my commit that I didn't intend? Feature branching has always helped isolate work. Before the branch can integrated into a develop branch, a good code review process will help reduce conflicts for the entire team. Github has a great concept for review with pull requests. I've been on teams when everyone is working on one branch. One developer would check in their major change and it would blow up my local sandbox to do work. Here you have to get creative to stay productive. This is where I feel strongly about feature branches and a good review process before it gets introduced to the entire team. Also, having someone else review your work and pulling your branch to validate that it works on another machine will provide a good check to make sure you have checked in everything to make your feature functional.

It is important to stay in sync with the develop branch. I would always bring changes from develop back to my feature branch before I would think to propose it to be merged with the develop branch.

Try to think atomically with changes you are introducing with source control. A great article to read on atomic commits is 

Find a standard in documenting your commits. Another great read is 

. When it comes to reviewing work or investigating issues, providing a great commit message and that is consistent throughout source control will really help the team.

Web Ethics and Source Control

AngularJS is a great framework for a couple reasons:

Data binding which is fantastic for working with JSON

I wanted to provide a simple example for anyone to get started with incorporating AngularJS into a Sitecore implementation. This article will go over creating:

a service class for retriving albums from Sitecore

a very simple AngularJS module for listing albums

For this example, we are building a music store. The store needs to display albums and this page will have filtering such as display albums whose release date is between two dates. The next post will cover more on filtering, but for this example, we will start some implementation.

Let's start by building the AlbumService class. Also, this assumes you are using Glass Mapper for interacting with Sitecore items and search index.

Albums will be retrived from a Sitecore index. We will build a method 

 that will query the index for items as the index will hold the release date field from the Sitecore item for Album.

 will be used to transfer the range of dates that an album release date will fall between.

 will use the AlbumService and accept the object that represents the date range. We can use the start date and the end date to pass to 

To start building out the client side, we need to build the Album module. As mentioned before, AngulurJS has a concept of modules so we want to encapulate any logic that will be used for managing albums.

 that will be responsible for creating the DTO and post to the API controller we just created.

Notice how the DTO is created by creating an object that will have 

Here we place the listing of albums in a partial view and for the sake of simplicty we have added the initialization of the app and the controller here. If AngularJS was going to be used throughout the site, we will probably put a little bit more planning on how AngularJS is introduced in an ASP.NET MVC site under Sitecore.

We can see a mocked version of this on JSFiddle:

In further posting, we can start to tackle other aspects of AngularJS and how that might change what we put together so far.

One of the biggest struggles I faced with using AngularJS was how to structure and provide good separation. So far we have:

As more modules are created and dependencies need to be managed, the 

 folder will become complex. For example, you notice that I declare the module for albums and the app in 

. Much of this should be moved to a new file 

. As more modules are created, this file will be a good place to manage them and how they are dependent on each other.

One resource that was very helpful was John Papa's 

 on AngularJS. I constantly referenced this document in order to have some good practices and consistency with AngularJS.

We have not built out how the filter form is wired up and how that interacts with the 

The next post we can cover working with filtering the results with the start and end dates and adding on additional concepts in AngularJS such as:

enforcing some better separation and responsiblity

Sitecore with Angular JS

Balancing project needs requires 100% commitment throughout the project. It would be as if we created our product backlog, prioritized it and called it good. For anyone that has worked on a Scrum team knows that this is not possible.

When internal ideals get ahead of the project needs, they can be costly to the project timeline and to the price tag. On the other hand, internal ideals can provide value if it is an opportunity being missed. Scrum has been a methodology that has provided mechanisms to balancing the project needs and facilitating new ideas to work through the process in providing value.

Here are some quick tips to consider in keeping that balance:

Know your project, window to deliver and end goal.

Keep a product backlog groomed and prioritized.

Recognize when gold-plating is happening by the team.

Get continuous feedback such as providing a demo with the client.

Embrace a facilitator and the negotiator.

BRDs is what they called them. Business Requirements Documents. It was great for waterfall and where I worked at the time was very very detailed. It was seen as a contract. The stakeholders signed off on it and used it to every detail.

When the project began and sometimes much later from when the BRD was drafted, the development team would pick up the requirements and head into development for a couple months or longer. When the development team said they were done and it was the end of the project, the progress was good however the expectations changed or some things were missed in the project. We did the Agile thing. Iterations were planned that broke down the enormous BRD.

What did we do wrong? How did the project needs become less represented? Or, why did the needs change?

In a new era of development at the company, Scrum was the new buzz word. It brought:

delivering the best value first with cost in mind

continuous feedback to maintain proper scope

Scrum was helpful and it provided the mechanisms for everyone to be transparent and collaborate on a project. However, there is no one size fits all. Even with Scrum, there are internal ideals that can get ahead of the project needs. And, sometimes internal ideals that should be considered as part of the project needs provide more value.

Here are few things that might be worth considering when you head into your next project:

Know your project. Be sure to understand where your client is coming from and make sure there is a plan for going to market. Is there a short window to get to market in order for the client to take advantage of an opportunity? This can be very important information as it will determine what can be built for the amount of time and cost. It will also help the team establish how the project will get built.

Adopt a cadence and keep it. Sprints are there to keep the lines of communication going for continuous feedback in where the project team is heading. Never put off a sprint and avoid extending sprints especially if the sprints are failing. A team starting out will fail 50% of the time and should improve as the project progresses. Knowing that the team is failing will drive the team to complete a successful sprint and one that is realistic.

Keep a product backlog groomed and prioritized. Priority should always be re-evaluated on a sprint to sprint basis. It is important for keeping project needs first. The priority will help the development team bring the most value first. Grooming and re-evaluating with the client's interests and with the team's feedback allows for the project to adjust to change.

Recognize when gold-plating is happening. The development team will have some internal ideals. Great ideas can come out of the development team. The client should be able to determine if it is what the project needs, would it be better suited for a later release, or not at all. There are some common traps for teams. Some examples may be arguments for reusability or design that suggests too much functionality.

If scope creep is an issue or things are feeling a bit ambiguous. Get the product owner and client involved to help make the decisions. Get some time with the client to quickly prototype to help with decision making. Demos should be an integral part of the sprint schedule and be adventurous to let the client drive. Give them the keys and find out what is not working or what is working.

Make data driven decisions. It can be easy to fall into the trap that the client or the development team can assume what the end user wants. Be sure to use mechanisms that will let the end user tell you how a feature should work. There are lots of ways to collect this data for example hallway usability testing, canary testing, feature toggling and A/B testing. Be sure to get the right mechanisms in place to collect information especially with analytic services like Google Analytics. Also, consider ways you can ask the end user to provide some feedback on their experience. Keep in mind that there might be features that may never or rarely be used by the end user. Find out what works and what doesn't work.

Embrace a facilitator and the negotiator for the team. The roles of a Product Owner and Scrum Master are very important. It allows for the communication between the client and the team to happen in a productive way. There is going to be a need for someone to help facilitate and negotiate the needs and priorities between parties for everything to work effectively and realistically.

Balancing project needs with internal needs requires everyone to be committed to work together to self organize. Scrum helps us realize the transparency that is needed for teams to get work done and for change to be accommodated. Every project is at the mercy of cost, scope and time. And the product backlog could merely be seen as one big long wish list which some items that consists of project needs and internal ideals. But value should be provided quickly, proven with a plan and data to make informed decisions, and hopefully with return on investment.

These are really observations I've made over the years moving from a Waterfall/Agile environment to a Scrum environment. It is difficult to do any methodology 100% and I've ran into teams that do things a little bit different. Teams find approaches that work and there are different ways to get leaner and compromise to get to the end goal. Don't worry if your team is not doing Scrum a 100%. It comes with experience, willing to change and working together to strive to provide the best value.

Balancing Project Needs

 made it much easier to work with Sitecore's Lucene indexes. It made a similified way to create custom indexes and query those indexes. It included a helpful tool to rebuild those indexes on content delivery instances if needed. The Sitecore Support Toolbox additionally had a tool to rebuild indexes.

Otherwise an index needed to be rebuilt programmatically, a developer could simply call the following:

Of course, rebuilding was relatively pretty simple with Sitecore's API for version 6.x.

Since then, Sitecore 7 brought more robust featues for managing Lucene indexes. and changed the way a developer interacts with these indexes.

To access an index in Sitecore 6.x, a developer would do the following:

In Sitecore 7.x, the Sitecore API has introduced a 

 namespace and within that is defined a manager called 

. Getting access to the index is still as easy as it was in Sitecore 6.x:

The above example is with a custom index if one was defined. With Sitecore 7, it may not be necessary to define a custom index as Sitecore already maintains three indexes:

To access one of these indexes, a developer could do the following:

If the index needed to be rebuilt, it could be done with:

Though, this procedure takes a long time so the client may give up before it receives a confirmation that the index has been rebuilt. The recommendation would be to wrap this call with a Sitecore Job.

To setup a job for Sitecore, we'll create a service class that will be responsible for setting up the job and starting. It may be benefical to add some logging as an index may take some time to complete. A developer could go as far as creating a view into what jobs are running or queued with Sitecore if necessary. But the logs should be sufficient.

First step is to create the interface and class:

We will add two methods. One to start to setup and start the job and the other to start the rebuild of the index.

The second step is to complete the logic to setup and start the job:

 object requires the constructor to provide these parameters:

Instance of object (that contains the method to call)

Method name (that will execute for the job)

Any passing parameters (in this case we are passing the index to be rebuilt)

Job status is updated so any job viewer can see its status and Sitecore knows when it is done.

Much of what is needed to rebuild an index in a job is ready. What is probably left is handling pre-conditions and/or post-conditions with these methods and allow this logic to be called from a ASP.NET Web Form, MVC route, subscribe to a Sitecore event, or create a Sitecore scheduled task.

Sitecore 7 Indexing with Code

For the South Colorado .NET User Group meeting, we had Rudy Lacovara speak on 

. SpecFlow follows much of the Behavior Driven Development model. Other examples of this in the wild are 

SpecFlow allows developers to write automated tests in a "natural language that can be understood and written by anyone".

To install SpecFlow, you need the NuGet package and the extension manager. (

SpecFlow creates integration tests. Basically, you are executing parts of the system that run in some part of the environment. Hitting the database and saving real data. Getting and cleaning up real data.

Below is an example Feature File (Gerkin)


You can also use a table to reduce the number of scenarios written for validation. Above three scenarios were written for Company Address, City and State.

Next, we generate a Definition File which will contain our C# code for our steps in our scenarios.

To do this, you can use "Generate Step Definitions" to stub out the steps in the feature. Part of this process to generate the required methods uses regular expressions to wire up these definitions from the feature file.

Rudy uses a TestHelper class to better manage setting up a company for the tests. He also recommends using an AuthTokenClass for credential management.


If you notice in the code sample above each method relates to a step in the scenarios. You will also we have simple tear down and setup per run. BeforeScenario method allows us to clean out the company.

Posts

Rinse and Repeat with Sitecore

Web Ethics and Source Control

Sitecore with Angular JS

Balancing Project Needs

Sitecore 7 Indexing with Code

South Colorado .NET User Group - SpecFlow