• Blitz.CSharp: A Nuget package for Blitz.io

    Since the Blitz folks lacked a C# library to interact with their API, I took the task upon myself. I've spun up a Github repository for it as well as a Nuget package.

    To take it for a test drive, create a new project, run "Install-Package Blitz.CSharp" from the Package Manager console, and paste the following code:

    Code Snippet
    1. using System;
    2. using Blitz.CSharp;
    3.  
    4. namespace Blitz.Console
    5. {
    6.     public class Program
    7.     {
    8.         private const string apiKey = "xxx-xxx-xxx-xxx";
    9.         private const string userName = "jon.doe@foo.com";
    10.         const string url = "http://foo.com";
    11.  
    12.         private static void Main()
    13.         {
    14.             var sprintRequest = new SprintBuilder()
    15.                 .FromRegion("virginia")
    16.                 .WithStep(url)
    17.                 .AsSprintRequest();
    18.  
    19.             var rushRequest = new RushBuilder()
    20.                 .FromRegion("oregon")
    21.                 .WithStep(url)
    22.                 .WithInterval(1, 10, TimeSpan.FromSeconds(10))
    23.                 .WithInterval(10, 250, TimeSpan.FromSeconds(50))
    24.                 .AsRushRequest();
    25.  
    26.             var sprint = new Sprint(userName, apiKey);
    27.             sprint.SprintStatusChanged += (s, sprintStatus) =>
    28.             {
    29.                 System.Console.Out.WriteLine(sprintStatus.status);
    30.             };
    31.             sprint.Execute(sprintRequest);
    32.  
    33.             var rush = new Rush(userName, apiKey);
    34.             rush.RushStatusChanged += (r, rushStatus) =>
    35.             {
    36.                 System.Console.Out.WriteLine(rushStatus.status);
    37.             };
    38.             rush.Execute(rushRequest);
    39.         }
    40.  
    41.     }
    42. }

    Feedback warmly welcomed.

     

    Leave your comment

    Show more

  • Blitz.io – Load testing made easy

    By Bryan Wheeler

    If you haven’t taken AppHarbor for a test drive, you should. While you’re there, check out the various 3rd party add-ons. Without fail, they are useful, easy to use, and have free usage tiers that allow you to do interesting things without divulging your credit card number. This is how I stumbled upon Blitz.io.

    What is Blitz?

    Load testing is a strange addiction to develop but many would be load testing junkies are turned off by the complexities of simply hammering a server with a bunch of requests. Blitz.io makes this as easy as clicking a button. Seriously. Within seconds, you can have an army of load agents at your disposal, ready to pound your servers from Amazon’s public cloud.

    What will Blitz.io do for me?

    Glad you asked. Blitz isn’t going to solve all of your performance problems. In fact, it’s beauty lies in its simplicity, so don’t expect an “enterprise” product with thousands of features. However, in the last couple of weeks, I’ve used it to: 

    • Verify my basic CDN configuration is working
    • Verify my load balancer is working as expected
    • Verify my application cache performance is decent
    • Verify application performance is tolerable in general
    • Find and fix a performance issue

    What Blitz hasn’t done for me:

    • Collected perf counters from my server – you should be doing this anyway, right?
    • Told me how to fix my problems  

    Blitz makes load testing fun

    As odd as it sounds, watching production servers sweat as they get pummeled by Blitz is pretty entertaining. One of my new office past times involves having Blitz on one monitor and Splunk on another and watching how well the latest build performs in production.  The Blitz UI is easy on the eyes. See the screenshot below. Better yet, take 5 minutes and try it out yourself.

     

     

  • Dear Azure Santa Claus, all I want for Christmas is....

    To know my account balance in 5 seconds or less. Seriously. 

    My billing statements from AWS and Azure arrived in my inbox a mere 9 minutes apart today. That's sort of uncanny. Here's what the first two seconds of my Amazon email look like:

    Greetings from Amazon Web Services,

    This e-mail confirms that your latest billing statement is available on the AWS web site. Your account will be charged the following:

    Total: $4.18

     

    I actually dread getting the Azure email. Why? I get a bunch of free Azure stuff via an MSDN subscription (+1 Azure), but I'm always paranoid that I'll leave something on and get charged a lot (actual been there and done that with AWS, -1 Amazon). Forgetting to turn stuff off is not anobody's fault but mine (a reminder email would be nice, though). What really peeves me is this:

    Dear Bryan Wheeler,

    Your Microsoft Online Services statement is ready.

    To view your statement:

    1. Sign in to the Microsoft Online Services Customer Portal with the following Windows Live ID: foo@bar.com
    2. On the Home page, click View my bills.

     

    Now I have to burn 5 minutes remembering how to find my account balance in the Online Services Customer Portal. Grrrr. Please, please, please Azure Santa Claus. Send me my account balance in the email.

  • Using Kanban for deployment scheduling

    By Bryan Wheeler

    Six weeks ago, we started using Kanban to manage our product deployments. Although our primary motivation was to improve deployment lead time (defined as the time from when code was “done” until it was released on the production site), the results have been more far reaching. In fact, given how little we actually changed about the way work gets done, the outcomes are downright surprising.

    The problem

    For the past 18 months, we’ve been pushing releases to production twice a day. Although this sounds good on paper, our lead times were pretty bad. Once a team was ready, they would often wait for 5 business days before seeing their code go live.

    A source of waste

    Under our old deployment regime, we managed our releases via a release calendar. Each day had an AM and PM slot. In practice, teams would predict when they’d be done and snag a slot. If a team wasn’t ready when their release slot came around, nobody released during that time frame. Historical analysis revealed that roughly 20% of our release capacity was wasted by teams walking away from slots.

    A solution

    Two months ago, I started reading David Anderson’s Kanban: Successful Evolutionary Change for Your Technology Business. Tired of hearing me wax eloquent about YANI (yet another new idea), Yan Philippe, one of our group managers, suggested we apply it to our code deployments. On Oct 10th, we retired the old release calendar and replaced it with a very simple Kanban board.

    Kanban board for code deployments at msnbc.com

     

    The results

    Here are some of the improvements we've experienced thus far. In another post, I'll pontificate as to why we saw some of these improvements:

    • Lead time – Average lead time decreased from 5 business days to 1.5 business days
    • Release slot utilization – increased from 80% to 100%; basically, a release slot is never wasted anymore
    • Readiness – after a few weeks of adjustment, teams are completely buttoned up and ready to go as they put the sticky on the board. If things aren’t ready when it’s their turn, they simply lose their slot and the next team immediately releases.
    • Collaboration – Although the release queue is mostly FIFO, teams can switch order based on business priorities. The best part about it is that the release engineer doesn’t have to get in the middle of the conversation. The discussion happens between business stakeholders.
    • Releases per day – Sometimes, the release team squeezes in 3 releases per day. This never happened under the old regime. This is possible because anybody in the queue is ready to go on a moment’s notice. Also, the release team feels accountable for their lead time metric and works pretty aggressively to keep the “ready to release” queue small
    • Continuous improvement – The release team is more in tune with the process bottlenecks and takes small steps to improve flow.

  • Feedback Loops

    By Ben Lakey

    Are you familiar with feedback loops? A feedback loop is a loop in which information encountered by the system is fed back into the system, and the system can then respond to it. You've probably seen a diagram similar to this:

     

    Feedback loops are very important for a system since they allow the system to evolve and adapt to change. A great example of this seen in nature is the human body's temperature regulation:

     

    Without feedback, the body would have no way of making the minor adjustments it needs.

    Feedback loops turn out to be extremely valuable in software development as well. Agile development practices all relate to the notion of a feedback loop:

    • Unit tests
    • Pair Programming
    • Sprints
    • Stand-up meetings
    • Code reviews

    You may notice something about these practices; The feedback loops are very fast. Feedback loops that are slow are of little value, because by the time you respond to one set of feedback, the next may have already arrived, which would render your initial response meaningless.

    In the example of body temperature regulation, it would be pretty useless to have the body react with sweat hours after a temperature change occurs.

    We want feedback loops to be as fast as possible so that we can find out whats working, whats not working, and what needs to change right now.

          1. Change something
          2. Find out how it went
          3. Learn from it and adjust
          4. Rinse and repeat

    Automation is a great way to achieve our feedback loop goals in software development. In addition to the agile practices above, we can also try to implement the following whenever possible:

    • Continuous integration
    • Increasing the frequency at which code is released
    • Automated acceptance tests
    • Automated code analysis

    A set of tight feedback loops like these can allow us to respond to change rapidly. Every time someone checks in code, the automation can tell us immediately whether we are in a healthy state, which will allow us to immediately correct any problems if they occur.

  • NinjectMVC3: Dependency Injection in 30 seconds or less

    I'm frequently baffled by the hoops one must go through in order to setup things like dependency injection in a web app. While browsing through Ayende's Raccoon Blog source code, I noticed he avoided using IoC and instead created a helper class to manage store/session lifetimes. Seemed like more work than I wanted to do.
    Instead of spending time avoid the IoC setup pain, I took Ninject.MVC3 for a test drive. It went something like:
    1. Use Nuget to get Ninject.MVC3
    2. Edit RegisterServices -- the Nuget package conveniently adds some code in the App_Start folder so you don't have to worry about the boiler plate.  In this case, I wanted to pass a controller an instance of IDocumentStore for RavenDB:
    Code Snippet
    1. private static void RegisterServices(IKernel kernel)
    2.         {
    3.             kernel
    4.                 .Bind()
    5.                 .To()
    6.                 .InSingletonScope()
    7.                 .WithPropertyValue("Url", "http://localhost:8080")
    8.                 .OnActivation(store => store.Initialize());
    9.         }
     
    3. Use IDocumentStore in my controllers.
      
    Code Snippet
    1. IDocumentStore store;
    2.  
    3. public AdminController(IDocumentStore store)
    4. {
    5.     this.store = store;
    6. }
    By Bryan Wheeler

     

    Pretty slick.

  • Field notes from Agile 2011: The battle is over but the war continues

    By Bryan Wheeler

    The battle is over

    The foregone conclusion at many sessions at Agile 2011 was that Lean/Agile methods at the team level work. Really well. People want to get better at it, but whether or not to use these methods at the team level is no longer a point of debate.

    But the war continues

    Agility at the enterprise level continues to elude most organizations. Initial adoption of agile at the team level can bring tangible results very quickly. However, the long term success of individual agile teams will be limited until the entire organization can move beyond some closely held assumptions. At the highest level, these detrimental assumptions are what Steven Denning describes as the 5 interlocking principles of 20th century command-and-control management:

    • Purpose of the firm is to make money
    • Managers act as controllers of individuals
    • Work is coordinated by hierarchy and bureaucracy
    • The main thing is efficiency
    • Communicate by directives (command and control)

     He proposes a replacement set of interlocking principles for the 21st century:

    • The purpose of the firm is to delight customers
    • Managers are enablers of teams and individuals
    • From bureaucracy to dynamic linking
    • From value to values
    • From command to conversations

    Yikes. We won’t get there overnight.  Fortunately, others (including Alan Shalloway) shared a vision of enterprise agility that is much more within our grasp. More on that later.

  • Bryan hearts Raven DB

    By Bryan Wheeler

    I’ll start with the punch line. RavenDB just rocked my world. Two things stick out: 

    1. It combines a database with an ORM – It’s as if Ayende said “I’m tired of working on the whole ORM thing. They only exist because SQL databases aren’t solving the right problems. Let’s just combine SQL  and the ORM and simplify everybody’s life.”
    2. It’s extremely approachable, even for non-database guys – It took me less than 30 minutes to get up and running.

    How did I jump to those conclusions?

    I have a confession to make. I’m not a database guy. In fact, when I’m prototyping, I tend to go to great lengths to avoid using databases. Sometimes, these workarounds are sane.  Using a disk based key/value store isn’t so bad.  Tonight, however, I was going down an insane path.

    Some background

    Our blog content is created in a CMS built by our colleagues at Newsvine. All of our other content is in our custom CMS (named Workbench). As you might expect, our editors don’t care which CMS their content is in. They just want to use their content however they wish.

    Tonight, I prototyped a process that consumes blog feeds from Newsvine and creates stubs in Workbench for each blog post. In Workbench lingo, these stubs are called “teases.”  So far so good.

    It started to get more interesting I wanted to make sure that:

    1. I didn’t create more than one tease for each blog post
    2. When blog posts are updated, the teases are updated

    I’m guessing the average developer would create a link table in a database to maintain a mapping between the two systems. Not me. Instead I charged down a path of great difficulty. In a nutshell, I relied upon a very fragile folder path and naming convention in Workbench to infer a mapping between Workbench and Newsvine. My approach was fraught with peril since:

    1. Humans can change the names and folders of things (and they do!)
    2. There was really no way for me to track changes to posts and appropriately update the teases

    Raven to the rescue

    Ninety minutes into the madness, I decided to give Raven a whirl (a couple of other folks here have been doing some really great stuff with it). Within 30 minutes, my stuff was working. Most impressive (not me, Raven). For the truly interested, here’s the Raven stuff from my prototype. It was incredibly easy. 

     

    Code Snippet
    1.  
    2. public class NewsvineBlogPostLink
    3. {
    4.     public string Id { get; set; }
    5.     public int WorkbenchId { get; set; }
    6.     public DateTimeOffset PublishDateTime { get; set; }
    7. }
    8.  
    9. class RavenNewsvineBlogPostToTeaseLinkManager : INewsvineBlogPostToTeaseLinkManager
    10. {
    11.  
    12.     private DocumentStore store;
    13.  
    14.     public RavenNewsvineBlogPostToTeaseLinkManager(DocumentStore store)
    15.     {
    16.         this.store = store;
    17.     }
    18.  
    19.     public bool IsInWorkbench(NewsvineBlogPost post)
    20.     {
    21.         var link = LoadLink(post);
    22.         return link != null ? true : false;
    23.     }
    24.  
    25.     private NewsvineBlogPostLink LoadLink(NewsvineBlogPost post)
    26.     {
    27.         using (var session = store.OpenSession())
    28.         {
    29.             var link = session.Load<NewsvineBlogPostLink>("newsvinepostlinks/" + post.NewsvineId);
    30.             return link;
    31.         }
    32.     }
    33.  
    34.     public bool HasPostBeenUpdated(NewsvineBlogPost post)
    35.     {
    36.         var link = LoadLink(post);
    37.         return link != null ? true : false;
    38.     }
    39.  
    40.     public int GetTeaseIdForPost(NewsvineBlogPost post)
    41.     {
    42.         var link = LoadLink(post);
    43.         return link != null ? link.WorkbenchId : -1;
    44.     }
    45.  
    46.     public void LinkPostToTease(NewsvineBlogPost post, int teaseId)
    47.     {
    48.         using (var session = store.OpenSession())
    49.         {
    50.             var link = new NewsvineBlogPostLink
    51.             {
    52.                 Id = "newsvinepostlinks/" + post.NewsvineId.ToString(),
    53.                 WorkbenchId = teaseId,
    54.                 PublishDateTime = post.PublishDateTime
    55.             };
    56.             session.Store(link);
    57.             session.SaveChanges();
    58.         }
    59.     }
    60. }

  • Organization Wide Adoption of Scrum

    By Bryan Wheeler

    A couple of weeks ago, I was deeply impressed by a talk given by Steve McConnell entitled “Organization Wide Adoption of Scrum.”  Before the talk, I naively assumed that Construx was having a hard time getting behind the Agile/Lean movement. Over the course of 90 minutes, Steve gave one of the most cogent presentations on Agile that I’ve ever heard. Here are the highlights that I walked away with (filtered through my own biases and prejudices):

    Why did it take so long for Construx to openly advocate Scrum?

    Construx is in the business of recommending best practices*.  At the beginning of the Agile era (10 years ago!), there wasn’t enough empirical evidence to advocate Scrum as a best practice. In the decade since, however, the case for Scrum has grown exceedingly strong. 

    Learning from the failures

    After gaining a lot of experience on various consulting engagements, McConnell asserts that Scrum is a great practice for 80% of the situations he’s encountered.  The vast majority of these adoptions are successful.

    Success is great, but more learning occurs through failures. Here are some common failure themes:

    Assuming your executive team wants agility at the expense of predictability

    Sadly, there are a few organizations where CEO’s have banned the words Scrum or Agile. It usually happens when a development team assumes that agility (interpreted as quickly delivering the highest micro priority) is more important than predictability (being able to predict when we can go to market with a product). These aren’t mutually exclusive, but bad Scrum adoptions tend to kill predictability. Don’t do it. 

    Failing to cross the adoption chasm

    In many organizations, a single team will adopt Scrum and subsequently enjoy a lot of success. The organization eagerly finds a couple more teams to try it out with. These teams try it, don’t see any benefit, and go back to their old ways.

    This type of failure is best understood by applying the tech adoption lifecyle thinking Geoffrey Moore’s Crossing the Chasm. With respect to Scrum adoption, every organization is a mixture of Innovators, Early Adopters, Early Majorities, Late Majorities, and Laggards. Innovators and Early Adopters are the type of folks that can read a book or a blog and start running with it. They are typically on the first team that enjoys success with Scrum.

    For any organization, the real challenge is crossing the chasm between the early adopters and early majority. This is not an easy task. It can lead to cargo cult adoption and worse performance. Don’t underestimate the challenge with crossing the chasm. Invest appropriately.

    Thinking that Scrum can free you from a need for vision/requirements

    Imagine a team that bypasses any upfront planning and dutifully delivers the next highest priority every two weeks for the next 6 months. If the team (including business folks) has neglected the real work associated with product vision and requirements, all of those done-done user stories delivered every two weeks will not add up to a compelling product.

    Scrum does not mean you can create a product without a plan. Instead, it frees you to change and adapt the plan as business conditions change. I think Eisenhower said it best:

    Plans are worthless, but planning is everything.

    Confusing Scrum with XP

    McConnell described Scrum as the minimal (in a good way) set of practices needed to manage product development workflow. At many organizations, Scrum is complemented by XP development techniques. Don’t confuse the two. XP practices may not be appropriate for every team or project, but that shouldn’t invalidate Scrum’s applicability for the same team or project.

    Hoping that Scrum will solve your problems

    It won’t. But it will shine a really bright flashlight on them. If you lack product vision, Scrum will make it clear. If team members lack development skill, they won’t have anywhere to hide. If people don’t like each other, they will either need to figure out how to get along or find another home.

     

     *“Best practices” in general make me uneasy.  In too many cases, best practices are really just ploys by products and services companies to increase sales.

  • Microsoft starts putting the M into MVC

    By Bryan Wheeler

    We're pretty big ASP.NET MVC fans here. For a long time, however, I've felt that the ASP.NET MVC framework lacked the crack-open-an-editor-and-get-stuff-done-ness found in Rails or Django.  Although I (and Kevin Pang) don't agree with some of the conclusions drawn by Simon Tokumine in .NET MVC vs Ruby on Rails, I agree with this observation:

    .NET MVC is actually .NET VC. It is an attempt to replicate the Actionpack components of Rails. There is nothing included aside from a folder labeled “Models” to help you with your persistence later and domain modeling. As others have mentioned, there are other ORM tools out there, but bear in mind these are not integrated into the framework as with Rails. There are good and bad points to this, but it does mean you’ll be writing more boilerplate code and setup for your model layer than you are used to with any of the Ruby ORMs.

    In Scott Guthrie's latest update on ASP.NET MVC 3 tools, I noticed that creating a new project template automatically includes a reference to EntityFramework 4.1. For the uninitiated, this means you can immediately start using the newest Code First goodness to handle persistence concerns for your Model layer.

    In my mind, this option means the framework has evolved from "VC" to "mVC." Two things are still lacking before I'd capitalize the "M": 

    1. Entity Framework Code First needs a data migration story -- it's sort of a show stopper when a Model change requires the DB to be wiped clean
    2. I'd like the whole experience to be a little slicker than it currently is -- it's pretty good today, but I feel that Rails and Django still have a shorter path to getting stuff done  

      3. 

    *msnbc.com is a joint venture of Microsoft and NBC Universal 

     

  • Principles vs. Methods

    By Paul Kearney (pk)

    Ralph Waldo Emerson once said:

    As to methods there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble.

    - Ralph Waldo Emerson (1803-1882)

    I like this quote in the context of software engineering. Bryan wrote a while back about Patterners vs Customizers, and Emerson's quote is along the same lines. 

    As developers we have a lot of methods to write software. We can use ASP.Net, SQL Server, LINQ, MSMQ, ORM... there's a long list of things we can use to accomplish our tasks. We even have other tools to support the process: TFS, Mercurial, BaseCamp, code reviews...

    What is more important is to understand the *why* behind these methods. *Why* do we do code reviews, or write unit tests, or use a source control system. It's not just to be able to check off a box. These activities are just manifestations of underlying principles that we believe to be true and good and virtuous.

    If we seek to understand the principles behind these methods, we stop performing rote tasks just because we "have" to, and we can begin to apply situational judgment and understanding. If we understand things like test driven development, or SRP, or SOLID, or avoiding premature generalization, it becomes much simpler to select the correct methods that match a given situation.

    Our principles should focus on providing business value at high quality. They should drive us to excellence in our designs and implementations. They should make us strive to do things right.

    If we focus only on the methods, we stay focused on just checking off boxes. As software engineers, we can provide much more value than that.

     

  • Doing work in a property? Back away from the keyboard....

    By Bryan Wheeler

    and spend some time reading the Framework Design Guidelines (FDG).

    Yesterday, I was perusing a profiling report* trying to pinpoint an obscure performance issue. What I found startled me. A single property getter was consuming a fifth of all CPU cycles. Twenty percent!

    The code itself *looked* innocuous. In fact, it was a single line of code performing a straightforward regular expression. The only problem was that this particular property was getting accessed all the time (there were some other design flaws that exacerbated the problem). The real shame is that this particular Boolean property could have been set once in the constructor. Sigh.

    Perhaps the Framework Design Guidelines need better iconography. Next to the statement "properties should not be computationally complex" I'd put the icon that signifies "fool me once, no more checkin rights for whomever reviewed your code. Fool me twice, no more checkin rights for you." Suggestions for what that icon looks like are warmly welcomed.

    *Props to the Visual Studio 2010 for making performance profiling super easy in 64 bit VMs. This was a huge pain in VS2008. In VS2010, it's as simple as "Analyze -> Profiler -> Attach".

Older posts