Allow me to elaborate, but before I do, let me share something with you. I used to be of the camp that believed that specifying software slowed things down. I took to heart the part in the Agile Manifesto that says, working software over comprehensive documentation.

In the old days of making software, a high ranking engineer or business analyst wrote the specifications and then we coded to that spec. It was laborious effort that involved hand written specification followed by hand written code. Over time, the tools for making specifications evolved so that some code generation took place. But you could still drive a truck in the space between writing specification and having working code. When it comes down to spending money, back then, I would take the code every time. But that was then and this is now. What changed my thinking? Swagger.

You can view the Swagger specification project for the application on SwaggerHub.

Everything Emanates from the Spec

At the enterprise level, just having a tool that allows developers to easily create API code and documentation based on a common specification is not enough. You need to have a workflow process to make sure everyone is rowing in the same direction. Otherwise, you are in Development Hell.

Development Hell is a place where a developer adds an endpoint, or changes an API endpoint request/response definition and doesn’t inform those responsible for publishing documentation that the API has changed. Then, one day those depending on the API to get work done wake up to a bunch of broken code and have no idea about how to fix the problem because the endpoints defined in the API do not match the documentation. At best, the company publishing the API is the subject of flame and ridicule on the Internet. At worst, customers flee.

Specification First addresses the need to keep code and documentation in sync always. As mentioned above, the premise of Specification First is that all code and documentation emanates from a common Swagger 2.0 compliant API specification expressed as either YAML or JSON. Thus, when it comes time to update an API, the first place anyone goes is to the specification. (Please see Figure 2.)

Figure 2: The workflow for Specification First is simple and easy to adopt.

Change is made in the spec and then the code is regenerated along with the accompanying documentation. (Please see Figure 3.)

Figure 3: A tool such as SwaggerHub allows you to create interactive API documentation that is derived from the same Swagger specification you’ll use to create your base code.

Now you may ask, when I regenerate, won’t the existing code base be wiped out? The answer is, not if you are careful. The code generated under a tool such as SwaggerHub is the base code only. No implementation logic is generated. Implementation logic is the work of developers. Thus, when you go about Specification First, you need to make sure that the application code is structured in such as way that the operational entry point that is bound to a given endpoint is separate from implementation logic. The way you do this separation will vary according to the language/framework you use. SwaggerHub supports code generation in NodeJS, Spring-MVC (Java), Sinatra (Ruby), Asp.Net 5, and Silex (PHP), to name a few. When you design an application architecture that has a strong separation between API endpoint entry code and implementation logic, you’ll be able to maintain the integrity of your code after any regeneration event with minimal tweaking.

Putting it All Together

As I mentioned at the beginning of this piece, the number of applications that depend on public APIs accessed over HTTP is growing every day. Programming using an API based on REST is a way of life. Thus, the way people program is changing, too. Today, there are a number of software shops that do not write any UI code. Their bread and butter is publishing APIs.

More applications will be consuming more APIs more often. And, as the appetite for an API grows, the need to make modifications to those APIs quickly and communicate those changes accurately to the user base becomes paramount. It’s no longer just about getting the bits out there. You need to get the bits and docs out there at the same time. Specification First is a practice that, if followed vigilantly, will allow you to ensure the synchronous publication of code and documentation. Having API code and documentation emanate synchronously from a single, common specification makes delivering APIs continuously not only possible, but easy. Specification First will not slow you down. It will speed you up, maybe faster than you ever imagined.

The post The Value of Specification First Development Using Swagger appeared first on CodeGuru.

My colleague, Raymond Leung, a respected Quality Assurance Manager in Santa Monica, CA does not have this problem. He sleeps well. Why? Because Raymond learned an approach to API testing that reduces guesswork and increases testing effectiveness. Raymond learned to start with a Service Level Agreement (SLA). To quote Raymond,

“The tests are goal oriented. A test result needs to be better than SLA.”

Raymond learned the SLA First technique during his time when he was Q/A Architect at NFL.com. Here’s how it works: The product group defines a product according to a business scenario. Then, the business scenario gets turned over to the Engineering Architecture Group where the SLA is created. Business use case descriptions get turned into measurable performance metrics.

For example, the business scenario might have a description that says, “10 million people will come to site in an hour, with 2 million people signing up in the peak hour.” The Engineering Architecture Group will translate the description into an SLA that describes behavior in terms of API calls per second.

Raymond points out that a good deal of time is spent coming to a common understanding between Product Speak and Engineering Speak. Both parties have a particular way of talking about business requirements, but the SLA needs to be defined from an engineer’s point of view so that all members of the tech team can work without ambiguity.

Once the Engineering System Group creates the SLA, the first thing to do is to make sure that the physical infrastructure can support the SLA requirements. For example, can the network support the amount of traffic anticipated? Does the data architecture provide adequate DB access to support the SLA? Does the virtual machine(s) configuration specify the amount of RAM and CPU power needed to support application performance dictated by the SLA?

After working through the physical analysis, the group inspects the code to try to determine impact points such as thread allocation and I/O blocking. They want to make sure that the code that is not blatantly out of whack with the SLA in play.

Then, testing begins. Q/A creates the automated tests scripts required. The Q/A team analyzes the SLA to see if they need to use 3rd party services to run the scripts or if they can execute the scripts in house. From Raymond’s point of view, if the SLA calls for supporting more than 10,000 API calls per second, he’ll use a 3rd party service. If the SLA is supposed to achieve performance metrics on a worldwide basis, he’ll use a 3rd party. According to Raymond, it doesn’t make financial sense to implement in-house support for test origination from points in Europe, Asia, and US. 3rd parties can do what needs to be done at less cost.

After the tests are run, results are gathered and the Q/A group analyzes the results to make sure the requirements defined in the SLA are met. If not, all groups gather in a War Room, roll up their sleeves, and try to figure out what’s going on. Some analysis is automated. Some is manual. The War Room session might be a day. It could be weeks. How long it can take to solve the mystery of large scale test failure is always an unknown. The important factor is that everything is analyzed in terms of the SLA.

Also of equal importance is to make sure that all parties test according to the same metrics, using the same testing techniques. To quote Raymond,

“Unlike functional test[ing], performance test[ing] is very abstract; everything is based on numeric measurement.”

Raymond points out that one of the thing he noticed in his years of enterprise level testing is that, without common planning, it’s typical to get different test results from Dev and Q/A. Raymond attributes the disparity to the different measurement techniques used by each group. For example, one group might take a data driven approach using predefined values to exercising an API’s hit tolerance. Another group might take a random value approach. One group might execute the tests using Tool A, whereas the other users Tool B.

In a large organization that might employ hundreds of developers and Q/A personnel, lack of communication is common. People are not willfully uncooperative. It’s just that the size of the organization makes collaboration hard. Management must foster a culture of cooperation. It’s not going to happen by magic. Cooperation must be planned and it must be valued.

Raymond advocates that Dev and Q/A work closely together to agree upon the same tools and techniques used in the process. There must be a firm understanding between groups about how pre-test environments will be provisioned and configured. Both groups should use the same tests, with the same testing tools. And, both groups must test using the same protocols, HTTP vs. HTTPS, for example. (Of course, a well developed SLA will define exactly which protocols are to be use and when.) If the tools and techniques are not standardized, reliable testing is unlikely.

Taking an SLA First approach to API testing will make life easier for all. You’ll have firm criteria to use for testing planning and you’ll have a common definition of system performance that all groups can use as a common point for reference when collaborating. However, using SLA First is not going to happen overnight. Establishing a collaborative environment in which all groups use the same tools and techniques to execute performance testing is going to take time. As Raymond Leung says:

“The lesson I learned is to be patient with Developers and Ops.”

I couldn’t have said it better myself. All good things take time.

The post Load Testing: SLA First appeared first on CodeGuru.

Everyting is an actor and actors communicate using messages.

Everything Is an Actor

Now, it may seem as I am overstating the obvious. But I am not. My mouth has been saying this for a while, but often my mind thinks otherwise. How, you may ask? Consider the following code. It’s an example of an Actor class, MathActor, and a message that gets sent to the actor, MathOperationMessage. Notice please the Console.Write(....) statement toward the end of the MathActor class, in bold.

using System;
using Akka.Actor;

namespace MessageThinkingLib.Actors
{
   /// <summary>
   /// A simple <see cref="Akka.Actor"/>
   /// </summary>
   public enum MathOperation { Add, Multiply,Subtract, None}
   public class MathActor:UntypedActor
   {
      protected override void OnReceive(object message)
      {
         var op = message as MathOperationMessage;
         if (op != null)
         {
            var answer = 0;

            // seed the answer to not mess up the multiplication
            if (op.Operation.Equals(MathOperation.Multiply)) answer = 1;

            foreach (var number in op.Numbers)
            {
               if (op.Operation.Equals(MathOperation.Add)) answer =
                  answer + number;
               if (op.Operation.Equals(MathOperation.Subtract)) answer =
                  answer - number;
               if (op.Operation.Equals(MathOperation.Multiply))
               {
                  answer = answer * number;
               }

            }

            Console.WriteLine("The operation is [{0}] and the
               answer is [{1}]", op.Operation,answer);
         }
      }
   }

   /// <summary>
   /// A message that describes a Math Operation Messsage
   /// </summary>
   public class MathOperationMessage
   {
      public MathOperationMessage(int[] numbers, MathOperation operation)
      {
         Numbers = numbers;
         Operation = operation;
      }
      /// <summary>
      /// An array of numbers to process
      /// </summary>
      public int[] Numbers { get; private set; }
      /// <summary>
      /// The operation to apply to the numbers
      /// </summary>
      public MathOperation Operation { get; private set; }
   }
}

Listing 1: The MathActor does addition, subtraction, or multiplication upon an array of integers

Listing 1 demonstrates that I have failed to really understand that everything is an actor. Take a look at this line of code:

Console.WriteLine("The operation is [{0}] and the answer
   is [{1}]", op.Operation,answer);

Why is this a problem? It’s about the separation of concerns and containment.

Actors Are about the Separation of Concerns and Containment

The concern of the actor, MathActor, is to perform math operations. However, for some reason I am writing to the console in MathActor. Do I have a need to do console writing? Maybe. Is console writing a reasonable activity for an actor that has the purpose of doing math operations? I don’t think so. Remember again, in an Actor model, everything is an actor. Yet, I have a thing in the MathActor that is not an actor. That thing is the Console.

There is a very good case to be made that writing output to the console is the purpose of another actor, not MathActor. Thus, I will do well to create an actor that does console writing and that new actor is the place where Console should live.

Please take a look at the code in Listing 2. It’s a revision of the method, MathActor.OnReceive(object message). Notice please that that Console.WriteLine(...) is commented out and in its place is an actor, ConsoleWriterActor.

      protected override void OnReceive(object message)
      {
         var op = message as MathOperationMessage;
         if (op != null)
         {
            var answer = 0;
            // seed the anwser to not mess up the multiplication
            if (op.Operation.Equals(MathOperation.Multiply))
               answer = 1;
            foreach (var number in op.Numbers)
            {
               if (op.Operation.Equals(MathOperation.Add)) answer =
                  answer + number;
               if (op.Operation.Equals(MathOperation.Subtract)) answer =
                  answer - number;
               if (op.Operation.Equals(MathOperation.Multiply))
               {
                  answer = answer * number;
               }

            }

            var output = String.Format("The operation is [{0}] and
               the answer is [{1}]", op.Operation, answer);

            var writer = Context.ActorOf(Props.Create(() =>
               new ConsoleWriteActor()), "MyWriter");
            var writerMessage = new WriterMessage(CommandType.Custom,
               sConsoleColor.Cyan,output);
            writer.Tell(writerMessage);

            //Console.WriteLine("The operation is [{0}] and
            //the answer is [{1}]", op.Operation,answer);
         }
   }

Listing 2: The ConsoleWriteActor‘s concern is to send output to the console

Listing 3 shows the code for ConsoleWriterActor.

using System;
using Akka.Actor;
using MessageThinkingLib.Messages;

namespace MessageThinkingLib.Actors.Utilities
{
   public class ConsoleWriteActor : ReceiveActor
   {
      public ConsoleWriteActor()
      {
         ReceiveAny(x =>
         {
            CommandType commandType;
            var msg = x as WriterMessage;
            var s = string.Empty;
            if (msg == null)
            {
               Console.ForegroundColor = ConsoleColor.Red;
               s = "Bad Message Format";
               commandType = CommandType.Error;
            }

            else
            {
               s = msg.Output;
               Console.ForegroundColor = msg.OutputColor;
               commandType = CommandType.Ok;
            }
            Console.WriteLine(s);

            Sender.Tell(new WriterMessage(commandType,
               Console.ForegroundColor, s));
            Console.ForegroundColor = DefaultColor;
         });
      }

      public ConsoleColor DefaultColor
      {
         get { return ConsoleColor.White; }
      }
   }
}

Listing 3: The ConsoleWriterActor provides console writing services to other actors

As you can see, I’ve separated the concern of doing math operations from the concern of writing output to the console. Each concern has its own actor. MathActor does math. ConsoleWriterActor does console writing. The way MathActor talks to ConsoleWriterActor is by way of messages, which is a it should be.

The Elephant in the Living Room

But still, the question remains: Why am I writing to the console in the first place? The reason is because I am being evil. I am writing console output to determine that MathActor is working properly. Why is this evil? Because I am, for all intents and purposes, testing my code using visual inspection of console output. This is just fundamentally bad business. I should be writing unit tests.

The good news is that the folks who thought up Akka.NET created a unit testing framework for the platform. So, I have a way to formally test my actors using unit tests under Visual Studio. But, before I can apply the Akka.NET unit testing framework to my code, I need to make my code testable.

Let’s go back to the original MathActor code in Listing 1. Notice, please, that although the actor does computation, it has no capability to report the result of its computation. This is flawed code. What good is a calculator that takes input but provides no output? We need to return the result of a calculation back to the actor that is messaging the MathActor. So, let’s create a message, MathAnswerMessage, that will contain the answer created by the MathActor. The message, MathAnswerMessage, is shown in Listing 4.

namespace MessageThinkingLib.Messages
{
   public class MathAnswerMessage
   {
      public MathAnswerMessage(decimal answer)
      {
         Answer = answer;
      }
      public decimal Answer { get; private set; }

   }
}

Listing 4: The MathAnswerMessage is sent by the MathActor to actors that want the result of calculations

Now that we have a way to notify an actor of a MathActor calculation result, we need to pass the MathAnswerMessage back to the sending actor. Listing 5 shows a revision of MathActor.OnReceive(object message). Notice that the method puts the results of a calculation into a MathAnswerMessage, and the message is returned back to the Sender via Sender.Tell(...).

using Akka.Actor;
using MessageThinkingLib.Messages;

namespace MessageThinkingLib.Actors
{
   /// <summary>
   /// A simple <see cref="Akka.Actor"/>
   /// </summary>
   public enum MathOperation { Add, Multiply,Subtract, None}
   public class MathActor:UntypedActor
   {
      protected override void OnReceive(object message)
      {
         var op = message as MathOperationMessage;
         if (op != null)
         {
            var answer = 0;
            // seed the anwser to not mess up the multiplication
            if (op.Operation.Equals(MathOperation.Multiply)) answer = 1;
            foreach (var number in op.Numbers)
            {
               if (op.Operation.Equals(MathOperation.Add)) answer =
                  answer + number;
               if (op.Operation.Equals(MathOperation.Subtract)) answer =
                  answer - number;
               if (op.Operation.Equals(MathOperation.Multiply))
               {
                   answer = answer * number;
               }

            }

            //Create an answer message and....
            var answerMessage = new MathAnswerMessage(answer);
            //... send it back to the actor that sent the message
            Sender.Tell(answerMessage);
         }
      }
   }
}

Listing 5: The result of a calculation done by MathActoris returned to the sender using a MathAnswerMessage

Now that we have communication going in and out of the MathActor, we need to test the actor. This is where the Akka.NET TestKit comes into play. The Akka.NET TestKit is big and very comprehensive. You can read the details about it in the preceding link.

For now, we are interested in being able create a MathActor and a MathOperationMessage within a unit test. We want to pass the MathOperationMessage to the MathActor using .Tell(). Then, we want to ensure that MathActor sends its MathAnswerMessage and that the answer within MathAnswerMessage is correct.

Here is the test that verifies that the MathOperation.Add works.

      private readonly int[] _numbers = {1, 2, 3, 4};

      [TestMethod]
      public void MathActorAddTest()
      {
         var message = new MathOperationMessage(_numbers,
            MathOperation.Add);

         //Create the ActorSystem
         var system = ActorSystem.Create("MySystem");
         //Create the MathActor
         var actor = system.ActorOf(Props.Create(() => new MathActor()),
            "MyMathActor");
         actor.Tell(message);
         //Let the testing framework get an answer message
         var answer = ExpectMsg<MathAnswerMessage>();
         //Make sure it's correct. (yeah, hardcoding is bad business)
         Assert.AreEqual(answer.Answer, 10);
      }

Listing 6: Testing the MathActor with a MathAnswerMessage using the Akka.NET TestKit

Notice, please, ExpectMsg<T> toward the end of Listing 6. ExpectMsg<T> is provided by the Akka.NET TestKit. The nice thing about the ExpectMsg<T> method in the TestKit is that it will automatically detect when an actor sends a return message and allows you to assign the returned message to a variable. If the desired message is not sent back from the actor, the test fails. When you do get the desired returned message, you can inspect it.

So, What Have We Done?

The first thing we’ve done is to reiterate the fundamental principle of the Actor Model: Everything is an actor and actors communicate using messages. Then, I showed you that I completely ignored this principle by using Console.WriteLine() to do ad hoc visual testing. I showed you how I revised my thinking to be consistent with the Actor Model. I separated concerns. Instead of using Console.WriteLine(...), I created a ConsoleWriterActor and sent messages to it to facilitate sending output to the console.

Lastly, I revealed a bigger problem. I was NOT using unit tests to validate my actor code. To address my shortcoming, instead of visually inspecting console output to ensure proper operation of the actor, I implemented the Akka.NET TestKit to test my code.

What Did I Learn?

• I learned that the fundamental principle of the Actor Model, that everything is an actor, and that actors communicate using messages, is not a nice to have feature. It is an essential concept.
• I learned to catch myself when I start implementing behavior in an actor that is not essential to the actor’s concern.
• I relearned to use unit testing when writing code. Any code that is written should be testable concretely, repeatedly, and beyond visual inspection.

These lessons were important to for me to (re)learn. The Actor Model is not usual Object-Oriented Programming by another name. It is a distinct way of programming and, more importantly, a particular way of thinking. As you move into more advance topics, it is essential that you understand that in the Actor Model, everything is an actor and actors communicate using messages and that you think accordingly. The basic lesson will serve you will as you progress down the road of developing with the Actor Model and Akka.NET.

You can get the code for this article on GitHub here.

Further Reading

How To Unit Test Akka.NET Actors With Akka.TestKit

The post Lessons Learned: Actor Model Thinking in an Actor Model Architecture appeared first on CodeGuru.

Actors created by ActorSystem are top level actors. Actors are objects that inherit from Akka.NET’s UntypedActor. Top level Actors create children Actors. In our little Stock Trading example, the StockBroker actor is a top level actor of the TradingSystem. The FloorTrader is a child of the StockBroker actor. Actors supervise their children. Supervision strategies are an important part of the Akka.NET Actor Model and will be discussed in future articles. For now, the important thing to understand is that once an Actor creates another Actor, that subsequent Actor is a child.

Communicating with Messages

Now that we’ve covered ActorSystem and Actors, let’s take a look at the concept of a message as it applies to Akka.NET. In Akka.NET, a message is a Plain Old CSharp Object (POCO), a class. (The strong type nature of a Message is an essential concept of Akka.NET.) For example, the POCO shown in Listing 1 can be a message:

public namespace Messages
{
   public class AlarmSet
   {
      //Make a constructor so time can be set
      //only when the object is created
      public AlarmSet(DateTime ringTime)
      {
         RingTime = ringTime
      }
      public DateTime RingTime{get; private set:}
   }
}

Listing 1: You define an Akka.NET message using C# classes

AlarmSet is a trivial message, but one can well imagine what to do when receiving such a message. “Oh yeah, I need to set my clock to go off at the value of RingTime.” Unlike full-blown, complex C# classes that do work, a class that defines a message does nothing more than contain information, similar to a structure.

The AkkaNetDemo application has one message, Trade, shown in Figure 4. Trade inherits from the abstract class, AbstractTrade. This inheritance model is of my own doing. It has nothing to do with Akka.NET.

Figure 4: The Trade message describes a stock trade and its state.

The message, Trade, has properties by which an actor will determine behavior. A Trade message will be sent among Actors to perform work. Let’s take a look at details of sending messages.

Sending Messages

As we mentioned above, an Actor sends a message to another Actor to get something done. One of the nice things about Akka.NET is that the framework uses intuative, nature language to describe sending a message. You use Actor.Tell(message) to send a message to an actor on a fire-and-forget basis. You use Actor.Ask(message) when you want to get to the underlying Task object in which the message is sent.

Also, you use Actor.Forward(message) when you want an Actor to forward a received message on to another Actor. When you Forward() a message, information about the originating sender is passed along too.

So, let’s review. There are three ways to pass a message from one Actor to another:

• Actor.Send(message)
• Task task = Actor.Ask<MyReturnMessageType>(message)
• Actor.Forward(message)

Now that we know how to send a message, let’s talk about processing messages in an Actor.

OnReceive(): An Actor’s Message Clearing House

Actors inherit from an abstract class, UntypedActor. UntypedActor defines an abstract method, OnReceive(message. OnReceive(message) needs to be implemented by the class that inherits from UntypedActor. The internals of Akka.NET are smart enough to do all the automagic required for an Actor to receive a message and the pass it on to OnReceive(). OnReceive() is the place where message processing takes place.

When an Actor receives a message in OnReceive(message), the Actor can analyze the message and react to the analysis. That analysis might be to do some processing and then respond to the sender with another message. The Actor might decompose the message and create one or more new messages to send on to other existing actors or child actors it creates. Or, the Actor can simply forward the message onto another Actor.

The important thing to remember is that the OnReceive(message) is the place where processing will happen.

Understanding Context

Akka.NET is designed to be a loosely coupled, distributed, asynchronous system. A lot of the magic of the system is hidden at the programming level. When you send a message, using Tell(message), for example, it might seem as if you are doing nothing more than sending a simple POCO. This is not the case. When you invoke Actor.Tell(message), information about the Sender of the message tags along (no pun intended). Also, within a given Actor, there is an implicit property, Context. You can use Context to determine the parent of the Actor, using Context.Parent. You use Context.System to access the root ActorSystem, under which the Actor resides. You can get a reference to the Actor itself using Context.Self. As you begin to program with Akka.NET, you’ll find yourself working with Context a lot.

Okay, so up to this point we’ve explored a lot of concepts. We’ve covered Actors, Messages, Tell(), Ask(), Forward(), and OnReceive(), as well as taken a glimpse at Context. And, we looked at the specific program flow and actors that are part of the AkkaNetDemo program. Now, let’s move beyond concept into actually programming.

Coding the AkkaNetDemo Program

As mentioned at the beginning of this article, when we introduced the program flow of the AkkaNetDemo, the AkkaNetDemo console application decomposes a comma delimited string that describes a trade. The comma delimited string is sent to the console by the user. The string is split into ticker, share, and B (or S) values. These three values are sent to the TradingSystem by way of the method, TradingSystem.Trade(ticker, share, tradeType). Then, TradingSystem creates a StockBroker object that it will Ask() to do the trade. Listing 2 shows the code:

using System;
using System.Threading.Tasks;
using Akka.Actor;
using AkkaNetDemo.Messages;

namespace AkkaNetDemo
{
   /// <summary>
   /// This class is the root level System for Stock Trading.
   /// </summary>
   public class TradingSystem
   {  {
      /// <summary>
      /// This method starts the trade messaging process. A
      /// top level Akka.NET <see cref="ActorSystem"/> object,
      /// tradingSystem is created. Also, a <see cref="Trade"/>
      /// message is defined. The ActorSystem creates the
      /// <see cref="StockBroker"/> to execute the trade.
      ///      ///
      /// NOTICE: The StockBroker uses
      /// <see cref="UntypedActor"/>.Ask(message) to execute the trade.
      /// <see cref="UntypedActor"/>.Ask(message) returns the underlying
      /// <see cref="Task"/> doing the asking. We'll Task.Wait() for the
      /// ask to complete. The response <see cref="Trade"/> message of
      /// the trade will be reflected in the Task.Result
      /// </summary>
      /// <param name="ticker">The ticker symbol of the stock you want
      ///    to trade</param>
      /// <param name="shares">The number of shares to trade</param>
      /// <param name="tradeType">Describes the trade to
      /// execute.<see cref="TradeType"/>.Buy or TradeType.Sell.</param>
      /// <returns>The response <see cref="Trade"/> message</returns>
      public static Trade Trade(string ticker, int shares, TradeType tradeType)
      {      {

         //Create the ActorSystem
         var tradingSystem = ActorSystem.Create("TradingSystem");
         //Create the StockBroker
         var broker = tradingSystem.ActorOf(Props.Create(() =>
            new StockBroker()), "MyBroker");
         //Create the Trade message
         var trade = new Messages.Trade(ticker, shares,
            tradeType,TradeStatus.Open,Guid.NewGuid());
         //Send the Trade message to the broker by way of an Ask(message).
         //We want the underlying Task.
         //Notice also that in Ask we are providing the Trade message as
         //a generic type. This is how the Task knows how to pass the
         //response Trade message out to the caller.
         var task = broker.Ask<Trade>(trade);
         //Wait for the Task to complete. The task is completed upon
         //the Broker receiving response Trade message.
         task.Wait();
         //Return the response Trade message.
         return task.Result;
      }
   }
}

Listing 2: The TradingSystem code creates a StockBroker and sends the broker a Trade message via Ask()

The broker receives the Trade message and creates either a Buy Or Sell FloorTrader object. Then, the broker calls FloorTrader.Forward(message), passing the message provided by the TradingSystem (see Listing 3).

using Akka.Actor;
using AkkaNetDemo.Messages;

namespace AkkaNetDemo
{
   /// <summary>
   ///     An object the describes a Stock Broker. A StockBroker
   ///     will use an <see cref="FloorTrader" />
   ///     to execute a trade.
   /// </summary>
   public class StockBroker : UntypedActor
   {
      /// <summary>
      ///    This overrideen method provides the behavior a StockBroker
      ///    executes upon receipt of a message. If the
      ///    <see cref="Trade" /> message's <see cref="TradeType" />
      ///    = TradeType.Sell, the StockBroker creates a Sell
      ///    <see cref="FloorTrader" /> and calls
      ///    <see cref="UntypedActor" />.Forward() to pass the Trade
      ///     message on.
      ///    If the Trade is TradeType.Buy, a Buy Floor Trader is created
      ///    and the Trade message is forwarded.
      /// </summary>
      /// <param name="message">The <see cref="Trade" />
      ///    message to process</param>
      protected override void OnReceive(object message)
      {
         var trade = message as AbstractTrade;

         if (trade != null)
         {
            //Make sure you are processing only open trades
            if (trade.TradeStatus.Equals(TradeStatus.Open))
            {
               if (trade.TradeType.Equals(TradeType.Sell))
               {
                  //create the Sell FloorTrader and forward the message
                  var sellTrader = Context.ActorOf(Props.Create(() =>
                     new FloorTrader()), "SellFloorTrader");
                  sellTrader.Forward(trade);
               }
               else
               {
                  //create the Buy FloorTrader and forward the message
                  var buyTrader = Context.ActorOf(Props.Create(() =>
                     new FloorTrader()), "BuyFloorTrader");
                  buyTrader.Forward(trade);
               }
            }
         }
      }
   }
}

Listing 3: The StockBroker forwards a Message on to a FloorTrader

The FloorTrader inspects the message. If Trade.Shares is more than the TradeLimit, the FloorTrader creates a new Trade message, setting the Trade.TradeStatus = TradeStatus.Failure. Otherwise, the FloorTrader creates the new Trade message, setting the Trade.TradeStatus = TradeStatus.Success.

The FloorTrader uses the Sender object, implicit in the Actor object, to send the new Trade message back up the hierarchy (see Listing 4).

using Akka.Actor;
using AkkaNetDemo.Messages;

namespace AkkaNetDemo
{
   /// <summary>
   ///    This class describes a Floor Trader, someone who buys and
   ///    sells stocks on the trading floor of a Stock Exchange
   /// </summary>
   public class FloorTrader : UntypedActor
   {
      private const int TradingLimit = 200;

      /// <summary>
      ///    This overrideen method provides the behavior a
      ///    Floor Trader executes upon receipt of a message.
      ///    If the number of shares in the <see cref="Trade" />
      ///    message is under the TradingLimit, the Floor Trader
      ///    executes the trade, then creates a new Trade message
      ///    with a <see cref="TradeStatus" /> = TradeStatus.Success.
      ///    Otherwise, a new Trade message is created with a
      ///    TradeStatus = TradeStatus.Fail.
      /// </summary>
      /// <param name="message">The message for the Floor Trader
      ///    to process upon receipt</param>
      protected override void OnReceive(object message)
      {      {
         var trade = message as Trade;
         if (trade != null)
         {
            Trade responseTrade;
            if (trade.Shares > TradingLimit)
            {
               var msg =
                  string.Format(
                     "You want to trade {0} Shares. The trade exceeds the
                        trading limit of {1}. The system will not {2} {0}
                        of {3}.",
                     trade.Shares, TradingLimit, trade.TradeType, trade.Ticker);
               responseTrade = new Trade(trade.Ticker, trade.Shares,
                  trade.TradeType, TradeStatus.Fail, trade.TadingSessionId, msg);
            }
            else
            {
               var msg = string.Format("I am {0}ing {1} shares of {2}",
                  trade.TradeType, trade.Shares, trade.Ticker);
               responseTrade = new Trade(trade.Ticker, trade.Shares,
                  trade.TradeType, TradeStatus.Success, trade.TadingSessionId,
                  msg);
            }
            Sender.Tell(responseTrade, Self);
         }
      }
   }
}

Listing 4: The FloorTrader object sends a Message response back to the Sender

The new Trade message is sent to the broker doing the asking. The TradingSystem extracts the Trade message from Task underlying the Ask() method, by way of the Task‘s Result.

            var task = broker.Ask<Trade>(trade);
            //Wait for the Task to complete. The task is completed
            //upon the Broker receiving response Trade message.
            task.Wait();

The TradingSystem returns the response Trade message to the caller.

            //Return the response Trade message.
            return task.Result;

The console converts the Trade message to JSON and dumps the output to the screen.

            //Call the static object, Trading System. TradingSystem will
            //return the response message of the Trade.
            Trade responseTradeMessage = TradingSystem.Trade(ticker,
               shares, tradeType);

            Console.WriteLine("The following is the result of your trade:\n");
            //Convert the response Trade message into a JSON string and show it
            var startColor = Console.ForegroundColor;
            //Make the console text RED upon failure
            if (responseTradeMessage.TradeStatus.Equals(TradeStatus.Fail))
               Console.ForegroundColor = ConsoleColor.Red;
            Console.WriteLine(JsonConvert.SerializeObject
               (responseTradeMessage,Newtonsoft.Json.Formatting.Indented));
            Console.ForegroundColor = startColor;

Listing 5: The AkkaNetDemo application console displays the returned Trade message as JSON.

Console output is shown below in Figures 5 and 6.

Figure 5: The AkkaNetDemo program converts the response Trade message to JSON when rendering on the console.

Figure 6: Failed trades are displayed in red

Putting It All Together

We’ve done a lot in this article. I showed you the very basics of using Actors and Messages to do a simple transactional scenario under Akka.NET. I showed you how to create a root Actor by using ActorSystem. I showed you how to create child actors by using Context. Also, we’ve discussed the three ways of sending a message: Actor.Tell(), Actor.Ask(), and Ask.Forward().

However, as much as we’ve done, we’ve only scratched the surface. Akka.NET is very big framework. Remember, Akka.NET is meant to be run on very big, dynamic, distributed systems in a fault tolerant manner. Actor supervision, monitoring, and routing are but a few of the topics we’ll cover later one in subsequent articles. In the meantime, you might want take a look the Akka.NET bootcamps and video documentation on the GetAkka.Net site. Also, there is an active chat site that has a very helpful community.

As you can see, the Actor Model is well suited to modern distributed computing. Beginning to take the journey to master Akka.NET is a good first step toward being able to do modern programming in the world of dynamic, distributed computing.

The post Actors and Messages: The Building Blocks of Akka.NET appeared first on CodeGuru.

68% of all technology projects fail.

— Michael Krigsman, ZDNET

Ever been on a project that is on the slow death march to failure? I have, more often than I care to remember. And, each of these projects had a Project Manager at the helm. These PMs were not evil. They just seemed to not know any better.

On the other hand, I have been on projects that were amazing. These projects were made up of competent people, having fun, and working in harmony toward a common, meaningful goal. These projects were led by Project Managers who had it down. They led. Their teams performed and their teams shipped. They totally did not suck.

So how do you totally not suck as an IT Project Manager? Well, from where I sit with a developer’s point of view, it comes down to the following 10 items:

1. Understand that Managing Is Not Bossing

If you find yourself bossing me around, it’s a pretty good sign that you can’t manage me. Management is about keeping the pathways open and the team fed—intellectually, emotionally, and gastronomically. It’s about inspiring people to do their best. It’s about making sure birthdays are celebrated and bagels show up on Friday mornings.

Bossing people around is a waste of time and karma. When you find yourself bossing me around as in “do your status report” or “get your coverage numbers up,” there is no management to be had. If I don’t have the basic habits necessary to work on a modern software development team, either find someone who can can inspire me, or get me off of the team and get someone in who has the habits required.

2. Understand that Agile Is a Whole Lot More than Daily Stand-ups

You’d be surprised how many VPs walk around and reassure themselves that if daily morning stand-ups are happening, then Agile is happening. We know otherwise. We know that Agile is a way of life in which stand-ups are but the tip of the iceberg. Unit testing, measuring velocity, backlog management, self-directed teams: These are just a few of the things that are in the stew that is the Agile Methodology. Unless all the parts of Agile are in play, a stand-up is just another meeting. You can’t fool us. A stand-up may look like Agile, but it’s really just a meeting.

3. Be a PM Who Is Not Afraid of Being Fired

There is absolutely nothing that I find more distasteful than a Project Manager who is afraid to stand up to Management when unreasonable demands are being made. Yeah, we, all of us, have to pay the rent and many of us have to feed the kids. But, a Project Manager that lives in fear of being fired sucks. A project turns miserable when we’re always giving into unreasonable behavior on the part of management. Most companies want what they want, when they want it. We get that. But, we also know that many times a senior manager does not really know what he or she wants, other than to meet a date and keep another higher-up happy. So, they make little unreasonable demands that, after time, turn into larger unreasonable demands. And then the project becomes a Death March in which everybody quits on Ship Day. We admire a PM who will push back on unreasonable behavior with no fear of being fired. Every good Project Manager I know that has stood up and been fired; has had no problem finding another job.

4. Don’t Say, “I Am Not Technical, but…”

If you want my respect, show me concretely that you speak my language and understand my landscape. I expect you to be technical. Jeepers willikers, it’s IT, for crying out loud. You cannot manage a team if you don’t know the game. Would Yogi Berra say, “I don’t know baseball, but…?”

5. Don’t Listen to or Accept Techno-babble

When I am feeling anxious or irritated, I will go into techno-babble. Most times I want to obfuscate my own sense of inadequacy, play alpha-dog, or just make the world go away. So, I’ll use terms and concepts I think only cool developers know. If I do, call me on it. Okay, don’t do it in a meeting, causing me to lose face. Rather, take me aside afterward and ask for clarification. If I really know what I am talking about, I can explain my thinking on a whiteboard pretty quickly. If not, I am putting one over on you. Underneath it all, I know that everybody can’t know everything. Take away the audience and I am happy to tell you what’s going on.

6. Don’t Show Meaningless Numbers

Don’t show me a bunch of charts and tables that mean nothing to me. Show me simple, clear project numbers: burndown rate, passing unit test percentage, code coverage numbers, team velocity, and schedule. I expect that you have enough mastery of all the project metrics that you can talk to anybody about the project’s status in concrete, quantitative terms. From Upper Management or developer, I expect your numbers to be right always. I expect Upper Management to have complete faith in their accuracy. I just don’t need to see all the metrics or provide any that are outside my scope of activity. My job is to make code that rocks. Your job is to know your numbers.

7. Don’t Yell, Ever.

I will yell back and then we’ll both be known as drama heads. If I don’t yell back, be assured I will silently be plotting your demise.

8. Don’t Play the Dating Game

When my car is broken, I don’t go to my mechanic and say, “fix it by noon.” And, my mechanic, who is a really good mechanic, does not say to me, “would you take 3 PM?” He’s been working on cars a long time; I trust him enough to come up with a time by which my car will be repaired. I make arrangements to work around his schedule. I expect that when there is a problem with his ETA, that he will call me and let me know. He always does.

So, don’t come to me and tell me when my code is going to be delivered and don’t force me to counter with an alternate date to make you go away. I am the expert. Give me the time to come to an educated ETA. And, if I find I am slipping, I will let you know as soon as a problem comes up. If I do find that I am slipping and I do not let you know as soon as I can, I will understand when you fire me.

PS: I expect also that you will not make promises to Upper Management about dates without consulting with the team first to determine delivery dates that we all agree upon.

PPS: My mechanic’s name is Kenny.

9. Understand That It Is Not Someone Else’s Job to Take Notes; It’s Yours

When I sit in a meeting, I understand that I am there to make a contribution. If I am typing away on my laptop or cell phone, I am being rude and disrespectful. I probably know it, but I am testing you to how much you’ll tolerate. Feel free to call me on it politely.

On the other hand, my job is to not take notes of everything that gets covered. That’s your job. I will admire you if you bring someone else along to do note taking. I will think that you think ahead. If you ask me to take notes, I will think that you are lazy.

10. Don’t Create Surprises; Have Buffers or Contingencies

I hate being surprised unless the surprise ends up with me getting a lot of money. I have a life. I have lots of interests. I have family. My weekend and evening time is allocated already. Yeah, I know that sometimes extra work is required. I won’t get too irked if I have enough time to plan, at least a week in advance. And, make sure that asking for overtime is the exception, not the rule.

I know that project dates slip; they always have; they always will. The PMs whom I respect planned for slips and had time, money, and contingency plans in place to accommodate the delays.

Bonus Item: Don’t Do the Death March

Death March is when we are expected to work all the time, day and night, in miserable conditions, to meet a date that none of us agreed upon. When Death March starts, that’s when I call the recruiters and start to send out resumes. Death March is a sure sign of a PM who totally sucks. Don’t be a PM who totally sucks.

The post Ten Ways to Not Suck as a Project Manager appeared first on CodeGuru.

This is a Down and Dirty article. The goal here is to give you the basics you need to be operational in TPL programming without a lot of theoretical overhead. The article is meant to be fast and simple. You’re going get some basic concepts while looking a lot of code. Then, if you feel inspired, you can look to other references to get the details you need to dive more deeply into TPL.

To get full benefit from reading this article, we expect that you can read and program in C#. Also, we assume that you understand the basics of lambda expressions and generics. If you have these basics, you are ready to get down and dirty.

Understanding a Task

Before you go anywhere with TPL, you need to understand the shortcomings of .NET thread programming. The benefit of using multiple threads is that you to do concurrent programming. Methods in a single threaded environment run sequentially. In a multithreaded environment, methods can run simultaneously (see Figure 1).

Figure 1: Methods run sequentially in a single thread; concurrently in a multithreaded environment

Where threading becomes really powerful is on computers having many cores. (Think of a core as a CPU.) Theoretically, when you create multiple threads, the operating system is supposed to assign each thread to a core. In reality, in .NET when you use a Thread object, sometimes the thread runs on a distinct core and sometimes it doesn’t (see Figure 2).

Figure 2: Sometimes, a .NET Thread will not run on its own thread.

TPL makes it so that you can do reliable multithread programming across multiple cores.

All Cores, All the Time

The Task Parallel Library introduced in .NET 4.5 has automagic that allows you to spawn threads that really do get assigned to a distinct core (see Figure 3).

Figure 3: The Task Parallel Library ensures that threads get assigned to cores, when available.

The way that .NET and the Task Parallel Library fixed this thread issue is to create a thread mechanism called a Task. You can think of Task as an asynchronous operation. Not only do you get the execution isolation that comes with threading, you get functionality that makes programming threads a lot easier.

Working with a Task

As mentioned earlier, a Task describes an asynchronous operation. When you start a Task, you’ll pass the Task a lambda expression that indicates the behavior the Task is to execute. That lambda expression can go to a named method or an anonymous method.

There are a few ways to create and run a Task. One way is to use the static method Task.Run(). The method SendDefaultMethod() in the class DownAndDirtyMessenger shown in Listing 1 illustrates how to use Task.Run. (The class, DownAndDirtyMessenger, is the code example that we’ll use throughout this article.)

The method SendDefaultMessage() uses Task.Run() to start a Task that runs the method SimpleSend(), asynchronously. Task.Run() takes as an argument a lambda expression that goes to SimpleSend(). Also, the Task that is created is returned by the method, SendDefaultMessage(). This Task is passed to any code that calls DownAndDirtyMessenger.SendDefaultMessage(). Working with the Task returned by SendDefaultMessage() is addressed later in this article.

namespace reselbob.demos.tpl
{
   public class DownAndDirtyMessenger
   {

      private string _defaultMessage = "Default Message";

      private void SimpleSend()
      {
         Console.WriteLine(_defaultMessage);
      }


      public Task SendDefaultMessage()
      {
         return Task.Run(() => SimpleSend());
      }

   .
   .
   .
}

Listing 1: You create a Task with a lambda expression.

Using Anonymous Methods in a Task

Another way start a Task is by using a Task.Factory, as shown in Listing 2.

   public Task<string> SendMessage(string message,
      int secondsToWait = 1)
   {

      Task<string> task = Task.Factory.StartNew(() =>
      {    //start anonymous method here
         var msg = message;

         if (string.IsNullOrEmpty(message))
            msg = _defaultMessage;
         var inTime = DateTime.Now;
         Thread.Sleep(secondsToWait * 1000);
         var rtn = string.Format("I am sending this Message:{0}
            from within the Tasks, Time in: {1}, Time out: {2}",
            msg, inTime.ToString(_fmt),
            DateTime.Now.ToString(_fmt));
         Console.WriteLine(rtn);
         return rtn;    //return the string as the TResult
      });
      return task;
   }

Listing 2: You can define the entire behavior of a given Task within the lambda expression argument.

Let take a close look at two parts of Listing 2, the method signature and the execution of an anonymous method that the lambda expression goes to.

First, the method signature.

public Task<string> SendMessage(string message,
   int secondsToWait = 1){......}

Notice, please, that SendMessage() returns a generic, Task<string>. What’s really going here is that .NET is saying that the method SendMessage() is going to return a Task with a TResult of type, string. What is a TResult? Hang tight; we’ll get to TResult shortly.

Let’s move on the second part, the anonymous method used in the lambda expression. Whereas in Listing 1, we created a Task that had a lambda expression that goes to a named method, SimpleSend(), in Listing 2 the lambda expression goes to an anonymous method. Also, the anonymous method returns a string. This returned string is the TResult that is defined as the return type of SendMessage(), the type, Task<string>.

Let’s take a closer look at TResult.

Working with TResult

Let’s look at a simple method signature:

public int AddNumbers(int x, int y){return x +y;};

It’s pretty straightforward. We have a method, AddNumbers(), that returns a simple type, int.

However, when we deal with a method that returns a Task object, we have to do things a bit differently.

The way you define a Task that returns a result is:

Task<TResult>

WHERE TResult is the type returned by the asynchronous operation.

Let’s look again at the method signature for SendMessage().

public Task<string> SendMessage(string message,
   int secondsToWait = 1)

Remember, that a Task represents an asynchronous operation. So, the return from SendMessage() is a reference to the Task it created. But, if we remember back to Listing 2, the anonymous method in SendMessage() returned a string. How can this happen, a method having two return types? Well, not really. Remember, the return type for SendMessage() is: Task<string>. It’s generic in which the string is the TResult of the Task.

So, when we declare a return type of Task<string>, what we are saying is “return a Task with a TResult of type, string.” The property, Task.Result, is where the TResult lives. Listing 3 shows how we can access the TResult of a Task, when used in a ContinueWith() method. (ContinueWith() is a method of a Task that gets executed when the Task completes.)

var messenger = new DownAndDirtyMessenger();
var task = messenger.SendMessage(null);
task.ContinueWith((t) => {
   Console.WriteLine("The TResult value is: " +
      t.Result);
});

Listing 3: TPL automagically passes the Task into the ContinueWith() lambda expression as the parameter, t

One of the nice things about TResult is that can create a custom class to be used as your TResult type. Listing 4 shows a class, MessengerResult, that represents a custom class for the TResult that is used by the demonstration class, DownAndDirtyMessenger.

using System;

namespace reselbob.demos.tpl
{

   public enum SendStatus
   {
      Success,
      Fail
   }

   public class MessengerResult
   {
      public string Message { get; set; }
      public DateTime SendTime { get; set; }
      public DateTime ReceivedTime { get; set; }
      public SendStatus SendStatus { get; set; }
   }
}

Listing 4: You can create a custom class for your TResult

Listing 5 shows you how to use a custom class as TResult. The method, SendMessageEx(), declares a return type of Task<MessengerResult>. The class, MessengerResult, is the TResult of the returned Task.

public Task<MessengerResult> SendMessageEx(string message,
   int secondsToWait = 1)
{
   Task<MessengerResult> task = Task.Factory.StartNew(() =>
   {
      var msg = message;
      if (string.IsNullOrEmpty(message)) msg = _defaultMessage;
      var inTime = DateTime.Now;
      // put in some time-consuming behavior
      Thread.Sleep(secondsToWait * 1000);
      var outTime = DateTime.Now;
      var rtn = string.Format(msg);
      return new MessengerResult { Message = msg, ReceivedTime =
         inTime, SendTime = outTime };
   });
   return task;
}

Listing 5: Using a custom class as a TResult

Let’s take a closer look at Task.ContinueWith() now.

Using Task.ContinueWith()

There are a number of properties and methods that allow you work with a given Task(see Figure 4). The method that allows you to react to a Task once it completes is ContinueWith().

Figure 4: A Task.ContinueWith() allows you to react to a Task’s completion

Task.ContinueWith() is very polymorphic, with a lot of argument permutations. The one that we are interested in is:

public Task ContinueWith(
   Action<Task> continuationAction
)

The variation shown above means that you can use an anonymous method within Task.ContinueWith(). Listing 6 shows an anonymous method within task.ContinueWith((t) => {....}.

var messenger = new DownAndDirtyMessenger();
Task<MessengerResult> task =
   messenger.SendMessageEx("This is a secret message");
task.ContinueWith((t) => {
   var fmt = "H:mm:ss:fff";
   Console.WriteLine("Message:{0} from within the Tasks,
         Time in: {1}, Time out: {2}, Status: {3}",
      t.Result.Message,
      t.Result.ReceivedTime.ToString(fmt),
      t.Result.SendTime.ToString(fmt),
      t.Result.SendStatus.ToString());
   });

Listing 6: Using an anonymous method in Task.ContinueWith();

Notice, please, that the t passed as a parameter in the lambda expression represents the Task associated with the method, ContinueWith(). Because we can get at the Task, we can get the to TResult by way of the property, t.Result.

Now, here is where it gets really interesting. Please remember that, in Listing 6, DownAndDirtyMessenger.SendMessageEx() returns a Task<MessengerResult>. The TResult of the Task returned by the method is type, MessengerResult. Thus, the type of the property, t.Result is MessageResult. We access the properties of the type, MessageResult, as follows:

   t.Result.ReceivedTime.ToString(fmt),
   t.Result.SendTime.ToString(fmt)
   t.Result.SendStatus.ToString());

The important thing to take away from all this is that Task.ContinueWith() allows you to react to a Task upon completion and that we can use a custom class as a TResult to get result information from a Task.

Iteration with Parallel Loops

The Task Parallel Library contains the class, Parallel. Parallel allows you to do asynchronous looping. We’re going to look at three methods of the Parallel class.

• Parallel.Invoke()
• Parallel.For()
• Parallel.ForEach()

Each of these methods is highly polymorphic, with lots of parameterization. So for now, we’re going to take a simple look at using each. After all, this is a Dirty and Dirty article, not a Deep and In-Depth.

Parallel.Invoke()

Parallel.Invoke() allows you to invoke methods asynchronously. Listing 7 shows you how to use Parallel.Invoke() to execute five methods simultaneously. Parallel.Invoke() is wrapped up in a method, SendSpam().

      private string _fmt = "H:mm:ss:fff";
      private void SimpleSend(string message)
      {
         Console.WriteLine(message + " at " +
            DateTime.Now.ToString(_fmt));
      }

      public void SendSpam()
      {
         Parallel.Invoke(
            () => SimpleSend("Moe"),
            () => SimpleSend("Larry"),
            () => SimpleSend("Curly"),
            () => SimpleSend("Shemp"),
            () => SimpleSend("Joe Besser"));
      }

Listing 7: Parallel.Invoke takes an array of lambda expressions asynchronously

We call SendSpam() as follows:

var messenger = new DownAndDirtyMessenger();
messenger.SendSpam();

The return of the call is a series of Console.Write statements, the output of which is shown below.

Moe at 15:34:39:478
Larry at 15:34:39:482
Curly at 15:34:39:482
Shemp at 15:34:39:482
Joe Besser at 15:34:39:483

Notice that the timestamps of the line of output indicate that the run was almost simultaneous. Yes, we have two outliers. The machine that this code is running on is a two-core machine. So, we might chalk up the slowness of the two outliers to have maxed out the capacity of the machine’s CPU.

Parallel.For()

Parallel.For() allows you to run items items in a for loop asynchronously. The syntax of the Parallel.For() statement is similar to a standard for loop, except the incrementer is implied, so that no i++ is needed. Listing 8 shows you Parallel.For() in action.

      public void SendMessages(string[] messages)
      {
         Parallel.For(
            0, messages.Length, i =>
               { SimpleSend(messages[i]); });
      }

Listing 8: Parallel.For() allows you to iterate over an array asynchronously

The Parallel.For() in Listing 8 is wrapped in a method, SendMessages(string[] messages).

Here is an example of calling the Parallel.For() by way of SendMessages(string[] messages).

var messenger = new DownAndDirtyMessenger();
string[] messages = { "Hello There!", "Goodby There!",
   "Do you know the meaning of life?" };
messenger.SendMessages(messages);

The outputs are shown below. Notice again that the method, SimpleSend(…), which is called in the Parallel.For executes almost simultaneously. The lag is probably due to my funky, old, two-core machine.

Hello There! at 15:36:51:401
Goodby There! at 15:36:51:
Do you know the meaning of life? at 15:36:51:405

Parallel.ForEach()

Parallel.ForEach allows you to iterate through collections. Listing 9 shows SendMessages(IEnumerable<string> messages), which is a wrapper for Parallel.ForEach(...).

      public void SendMessages(IEnumerable<string> messages)
      {
         Parallel.ForEach(messages, message =>
         {
            Console.WriteLine(message + " at " +
               DateTime.Now.ToString(_fmt));
         });
      }

Listing 9: Parallel.ForEach(…) iterates over collections.

We call SendMessage like so:

var messenger = new DownAndDirtyMessenger();
IEnumerable<string> messages = new List<string> { "Hi Moe",
   "Hi Larry", "Hi Curly", "Hi Shemp", "Hi Joe Besser" };
messenger.SendMessages(messages);

And the output is shown below:

Hi Moe at 15:39:19:682
Hi Larry at 15:39:19:685
Hi Curly at 15:39:19:686
Hi Shemp at 15:39:19:686
Hi Joe Besser at 15:39:19:686

Again, near simultaneous calls, weirdness due to my machine.

Putting It All Together

This has been a typical Down and Dirty Session. We’ve covered a lot. You learned how to get up and running using the Task object and you looked at using the Parallel class to iterate asynchronously.

There is little doubt about it, the Task Parallel Library makes asynchronous programming in .NET a whole lot easier than it was in years prior. Still, the technology is broad. You’ll need some time get accustomed to it. I hope that you give yourself the time because, once you do, a whole new way of thinking in code will open up to you.

Get the Code

The code for this article consists of a .NET solution that contains the DownAndDirtyMessenger demo project and a unit test project that runs the DownAndDirtyMessenger project discussed in this article. You can get the code from the Download link at the bottom of this article.

Learn More

If you want more about TPL and parallelization, check out Microsoft’s three-part series on Channel 9.

The post Down and Dirty: .NET Task Parallel Library (Multithreading in a Multicore World) appeared first on CodeGuru.

How many times have you sat is a design meeting and wondered, “What the heck is this person talking about?” For me, the number is more than a few. Everybody seems to be using the same words, but they’re all talking about something different. Eric Evans has a way to solve a problem. In his book, Domain Driven Design, Evans is emphatic that a vital part of the software development process is the creation and continuous use of Ubiquitous Language. Evans is no dope. He’s onto something.

Getting Lost in Translation

As I’ve said above, I’ve been on more than one project in which business people and developers use the same words, but in reality are talking about completely different things. Or, they use different words to talk about the same thing. As result, a lot of time gets spent in translation. And, as with any translation, things get lost. Translation costs time and money, and can affect the quality of the product being made. To quote Evans,

“The overhead costs of all the translation, plus the risk of misunderstanding, is just too high. A project needs a common language that is more robust than the lowest common denominator. With conscious effort by the team, the domain model can provide the backbone for that common language, while connecting team communication to the software implementation. That language can be ubiquitous in the team’s work.”

Eric Evans

Domain Driven Design, page 25

Evans’ solution is to create a Ubiquitous Language that is used all the time, by all members of the software development project, from executives to subject matter experts to developers. A Ubiquitous Language is more than just a set of agreed-upon phrases and anagrams. A Ubiquitous Language is the way that the team communicates with one another. The Ubiquitous Language describes exactly the domain that is being modeled. Creating and using a Ubiquitous Language is not some semantic mumbo jumbo. Software that is made in a domain that is well described by a Ubiquitous Language has a better chance of meeting the expectations at hand than software that is made under nebulous circumstances. Using a Ubiquitous Language counts.

Moving Past the Semantic Mumbo Jumbo

Using a Ubiquitous Language is very real world. Let’s look at a case in point. Imagine that we’re a software development company that has been contracted by the US Navy to make some software that registers vessels coming into a seaport. You are a developer in a design meeting and a naval officer says the following,

“The boats arrive on a weekly basis.”

Simple statement, right? Wrong. I’ll wager good money that the developer is thinking of a boat as this thing that travels on water. The naval officer on the other hand is thinking of boat in relationship to a ship, that a boat is a smaller vessel that can be stowed on an ocean-going vessel, a ship (see Figure 1).

Figure 1: Two parties can conceptualize the same work differently

Now, this might seems like an issue of trivial semantics, but it’s not. If my assumption is true, and let’s pretend it is, the result is that the one word, boat, is referring to two different concepts, one by the sailor, one by the developer. Now, here’s the gist. The developer is going to create code that describes his or her concept; at the same time, the sailor is expecting software that conforms to the naval definition. This is only one example of a mismatched conceptualization of a word. A software development project might have thousands of words in play that might have entirely different concepts attached to them among the participating parties. Unless a Ubiquitous Language is used, developers will code to their concepts, Q/A personnel will test to their concepts, and users will expect software that meet their definitions.

Remember, please, this is software. We build software according to the domain model. If the model is well understood and well defined, the software will be accurate. If the model is a collection of amorphous concepts, in which each concept is as different as the mind imagining it, well, you can take the result to the logical conclusion. The software will be fragmented and faulty.

So, what’s to be done? How do we create and implement a Ubiquitous Language?

Talking Won’t Do

There are two parts to implementing a Ubiquitous Language. The first part is getting all members of the development team—Subject Matter Experts, Project Managers, Business Analysts, and Developers—to agree to use the Ubiquitous Language, always. Evans calls the approach, One Team, One Language. The second part is actually using the Ubiquitous Language.

No doubt about it, getting a team to agree to use the Ubiquitous Language is hard. Most people want to go about doing business the way they’ve always done it, whether business as usual produces the desires the desired results or not. And, if you ask people to actually talk differently, well, we’re asking for world of hurt. Evans’ position is that the team needs to use the Ubiquitous Language verbally. Me? I am not so ambitious. I’ve rarely seen a complete adherence to a common verbal language succeed. The depth of historical entrenchment is too deep. However, language is not just about utterance. Written language can provide us the with the starting point for the communication we need. When it comes to having a written component of a Ubiquitous Language, I am a big supporter of using class, use case, and workflow diagrams (see Figure 2).

Figure 2: Using diagrams as the written part of the Ubiquitous Language is a good start

Later on, as the team takes shape, we can migrate to a more comprehensive diagramming language, such as UML. Then, as the the written language becomes entrenched as the way of communicating, using verbal language becomes easier. Analogically, as a novice speaker, it’s a whole lot easier for me to read German with a good dictionary handy than trying to figure out a real-time conversation in a room full of German speakers.

Creating the Domain Dictionary

Before we can use language, we need to establish a vocabulary. That vocabulary is defined in a Domain Dictionary. A Domain Dictionary is a listing of all terms, with definitions, that are used within the domain. The purpose of the Domain Dictionary is to remove any ambiguity about terms that are used to define the parts of the model. A Domain Dictionary is a living document, the accuracy of which is determined by absolute agreement among all members of the team. Will there be conflict when going about the task of defining a term? Yes. Does subject matter expertise matter? Yes. However, conflict when creating a Domain Dictionary is not a bad thing for the team to experience. It’s by conflict that a true, accurate description of the domain is defined.

Working with a Written Ubiquitous Language

As mentioned above, my position for the fastest way get a Ubiquitous Language to be a vital part of the team’s software development practice is take a written approach and start out by using class, use case, and workflow diagrams. Thus, a certain amount of education is going to have to take place. As with any language, you need to learn how to speak it. There is a formal aspect to class, use case, and workflow diagrams that need to be mastered. So, we come to training. Yes, all members of the team need to be able to write proper diagrams. There are a number of ways to facilitate the learning. You can have formal classes led by a person expert in the diagramming techniques. (Yes, team members can share knowledge about diagramming informally. But in terms for formal education, sessions led by an independent professional are best. Using an independent professional keeps the Mr. Know It All Factor down.)

You can use YouTube videos should your enterprise not have the resources to provided professional training sessions. The important thing is that everybody on the team have professional facility with class, use case, and workflow diagrams and that these diagrams serve as the language that defines the domain.

But, what about people who think this is hogwash, that they have neither the time or desire to learn a new language, albeit a diagramming language? Here is Evan’s response:

“A project faces serious problems when its language is fractured. Domain experts use their jargon while technical teams members have their own language tuned for discussing the domain in terms of design.

The terminology of day-to-day discussions is disconnected from the terminology embedded in the code (ultimately the most important product of a software project.)”

Evans, ibid

That most software projects fail is one of the dirty little secrets in the world of software development. If you find you are faced with personnel who do not want to make a commitment to learn the skills required to create accurate, understandable diagrams, you have a fundamental problem at hand that is not going to be solved later on down the line. You are either on the bus or off the bus. If your team doesn’t have the skills to diagram a domain model, the domain is not understood. You cannot code a domain that is not fully understood.

Stay the Course

Committing to using a Ubiquitous Language is not easy. If it were, most teams would do it. However, please keep in mind that shipping software isn’t easy either. The road your team travels will have lots of bumps. Your Ubiquitous Language will change as the domain model is understood more fully. You’ll find inconsistencies in the model that will need to addressed. However, just because the model changes doesn’t mean that we abandon the use of the Ubiquitous Language. Languages evolve as the world evolves. Keep in mind that up until very recently the word, friend, was used primarily as a noun. Then, Facebook can along. Did we stop using English to talk about that how we create relationship with someone on Facebook? No, we extended the language so that friend can be used as a verb. Today it is perfectly accurate, “I friended him.” The same will be true of your team’s Ubiquitous Language

Creating, using, and evolving a Ubiquitous Language will go a long way toward making your team known as a team that ships well integrated software that works and meets the expectations at hand. And, just as importantly, your team will serve as a model to other teams that are looking for a better way to create clarity, cohesion, and consistency in the pursuit of making software that matters. Leading by example is the best way to lead. Using a Ubiquitous Language is the type of leadership that will live on, well after your code ships.

The post Lesson Learned: The Need for a Domain Language appeared first on CodeGuru.