Call me Pluralsight

I don't know what to say about this, but that's ok, because this video speaks for itself:



(Also, don't get in my way, I guess.)

Comments

Post a Comment

Popular posts from this blog

TFS to SVN Conversion with History

Recently, the team I was on wanted to move our source code from Team Foundation Server to SVN for reasons that had almost nothing to do with source control directly. This would be a pretty simple operation, but we didn't want to lose access to the history when the operations team turned off the machine running TFS. We couldn't find any direct paths for moving history from TFS to SVN, so instead we chose to use git as an intermediary.

Here's how we did it:

Step 1 - Install the toolsInstall msysgit: http://code.google.com/p/msysgit/
Install git-tfs: https://github.com/git-tfs/git-tfs

Step 2 - Pull TFS history to local git repositorygit tfs clone <tfs-project-url> "$/<tfs-project-name>/<tfs-project-folder>" <localfolder>
example:
git tfs clone http://tfs-001:8080/tfs/projectroot "$/Reference Architecture/ReferenceArchitecture" RefArch

Step 3 - Initialize git-svn* User Lower Case - Caps will make it fail! *
Change directory into newly…
Read more

TDD vs BDD

At a recent Utah Software Craftsmanship group meeting, I was asked to share my experiences using MSpec and explain how TDD is different from BDD. Since I have been using NUnit for years and MSpec since February, I was able to discuss some of the differences in the two styles of testing.

First, A DefinitionTDD is Test Driven Development. This means writing a test that fails because the specified functionality doesn't exist, then writing the simplest code that can make the test pass, then refactoring to remove duplication, etc. You repeat this Red-Green-Refactor loop over and over until you have a complete feature.

BDD is Behavior Driven Development. This means creating an executable specification that fails because the feature doesn't exist, then writing the simplest code that can make the spec pass. You repeat this until a release candidate is ready to ship.

At this point, you should stop reading this post and instead go read Dan North's original article on BDD and, if you fe…
Read more

System Architecture: Bounded Contexts

Originally posted on Dec 2, 2016 at https://www.pluralsight.com/tech-blog/system-architecture-bounded-contexts


Microservices architectures are currently highly fashionable. The question of how small a microservice can be is asked regularly. Is micro even small enough? Can we build pico-services? At Pluralsight, we have chosen to go a different direction. We are focusing on team size.

In order to maximize throughput, how big should a team be? One pair of developers? Ten pairs of developers? For the time being, we have settled on two to three pairs of developers with a Product Manager, a UX Specialist and a DevOps Engineer. Given this team structure, we ask ourselves how big of a chunk of our system can that group truly own?

We expect a team to own the discovery, design, development, delivery, and production support of their part of the overall system. This means that we have to divide the system carefully. If the creation of a new feature requires coordination across multiple teams, th…
Read more