I’ve been playing with WCF since .NET 3 came out. Sometimes I have to be reminded that not everybody is as familiar with all it’s “cob-webby corners” as I am. And that’s OK. Often (too often) I encounter someone who has NEVER used WCF and doesn’t even know where to begin.That’s not so OK.

Usually I encounter these poor souls right when they need to be able to create or deal with WCF services NOW! Since it’s generally too late for them to attend my “Getting Started with WCF” talk by this time, and I can’t always drop what I’m doing to help them, I’ll be devoting several posts to the basics of WCF. While these posts are created with the new user (no previous WCF experience) in mind, even seasoned users may get something out of these posts.

The first post will cover creating your first service. Future posts will demonstrate the various ways to consume services, custom messages, what behaviors are, transports, what channels are, REST vs. SOAP and how to create a REST service in WCF, deployment, what’s coming in .NET 4.0, some entry-level RIA service work and all sorts of other WCF goodness.

Every Journey Begins With yada yada yada…

As mentioned, this post will take you through creating your first service. In this series I will be using Visual Studio 2010 (currently using Beta 2) with the .NET 3.5. You do NOT need VS 2010 for this example, VS 2008 will work fine. At some point I will dedicate a post to what’s new in .NET 4, and having Visual Studio 2010 will be necessary if you want to follow along.

We’ll be creating a simple service and hosting it in the test WCF Server that ships with Visual Studio. In the next post we will create a console application to host our service. Hosting in IIS is a deep topic, and will be covered in a future post. Remember, when starting Visual Studio you will need to run it as an administrator. For information on how to do this, see this post by Jeff Blankenburg.

Away We Go…

In our example we are going to be building a serviced based front end for an internet-based bakery called Web Bagels.

Open the dialog in Visual Studio to create a new project. Open the C# node and select the WCF sub-node.You’ll see a list of available WCF projects. We are going to create a WCF Service Library and call it WebBagels. The resulting dialog should look something like this:

Although we are going to be doing these demos in C# you can easily accomplish the same thing in VB.NET.

Click OK and wait for Visual Studio to perform its magic. When it’s done you’ll have what appears to be a normal class library with a few files in it:

The files IService1.cs and Service1.cs are sample WCF files. Feel free to open them up and look through them if you like, but we’re not going to use them for the demo, so delete them when you’re finished. Unlike most class libraries, this one has an app.config file. We’re going to need this, so make sure you keep it around.

The next step is to create a file for our service. Create a C# class file called BagelOrderService. Your solutions should look like this:

Our First Actual WCF Stuff

The first service we’re going to create is a simple service to allow users to submit bagel orders. They’ll tell us how many dozen bagels they want and what flavor.

WCF services are simple classes; they have public methods that generally take arguments (but don’t have to), do some work and may or may not return values. The difference between WCF services and plain objects is that we must tell WCF that the methods of this class are going to be accessed externally via a channel (Http, TCP, MSMQ, etc.) that is going to send a message to the class to execute an action.

So how do we do this? Turns out with WCF it’s very easy.

The first step is to create an interface that defines our bagel ordering method:

Now I know what some of you are probably saying: “[gasp] He put the interface in the same file as the class! HERETIC!”

Relax. This is a demo. They are in the same file because I am lazy for the sake of clarity. In reality I would not put interfaces for WCF services in the same file as the service. That’s not to say I never put interfaces and classes in the same file, but that’s another post.

Let go ahead and implement our interface in our BagelOrderService class:

We now have a class that will take bagel orders and return an order number! OK, it’s not actually doing that much. But it’s enough to get us going. We’ll be building this service out over the course of this series.

To turn it into a WCF service we need to identify it to the .NET framework as a WCF service. This is done using the ServiceContact and OperationContract attributes:

Notice the new using statement at the top of the class. ServiceContract and OperationContract reside in the System.ServiceModel assembly. Visual Studio was kind enough to include a reference to this assembly for us when we told it we were creating WCF services. If we hadn’t we’d have had to add the reference manually.

ServiceContract identifies the interface as being an interface for a service. When you run a hosting application (one you write or IIS) the .NET runtime knows to look at this interface and build a service mechanism around it. You can set specific attributes about your service here like namespace and session mode as arguments to the ServiceContract attribute. We’ll cover this in a later post, for now the defaults will be find.

For the most part WCF operates on an “opt-in” model, meaning that just identifying a class of interface as being a WCF object (via the ServiceContact attribute) doesn’t mean that the individual methods or properties are going to be recognized and used by WCF. This can be contrasted with the .NET XML serializer which is an “opt-out” model, meaning that if you decorate a class with the Serializable attribute, all the public properties will be serialized. If you want properties to be ignored you must specify which ones to ignore.

OperationContract is the attribute we use to identify which methods in our interface we want to be exposed as actions on our service. Like ServiceContract there are a variety of attributes we can specify about the action that will be exposed on the service like action name and if the call is a one-way action.

One thing to note, you don’t have to use an interface here. You could add the ServiceContract and OperationContract to your class and things would work just fine. But don’t do this. Tieing your service implementation, or any “service based” class to a concrete implementation is never a good idea.

Actions are basically the service equivalent of methods. More on those in a later post.

It Wouldn’t Be .NET Without a Configuration File…

… and WCF is no exception.

Remember when I said we were going to hold on to that app.config file? Good, because now is when we need it. Open it in Visual Studio. It should look something like this:

There is A LOT of stuff to cover in this file. Today we’re just going to worry about the bare necessities to the our service up and running. The first step is to make sure this configuration file is actually using our service. Find this line in the configuration file:

This is the node in our configuration that tells WCF which concrete implementation of our service we are going to be using. In our case it’s the BagelOrderService class. Change this line to look like this:

We’re almost done! All that’s left is to let WCF know where our service contact is. That’s done by change the contact attribute of our endpoint. The endpoint for our service should like something like this:

We just need to change the contact attribute to point to our service contract:

We’re ready to test!

Let’s Light This Candle

Our WCF class library is a little different than an traditional Visual Studio class library. Normally when you try to debug a class library in Visual Studio you’re given a “gentle reminder” that you can’t actually run libraries. Our WCF library is special though. In order to ease development and testing of WCF services Microsoft has included a small testing service host (think of it as Cassini for services) and a test client. Press F5 in Visual Studio to start debugging. Your solution will compile and Visual Studio will start the test host for you:

This may take a few moment, especially the first time you run the service. Once the service is up and running you’ll be presented with the WCF test client:

On the left side we have a tree view which represents our service. Currently we only have one method (PlaceOrder) in our service, so we only have the one node under our interface. Double click on that node and the right section of the window should present you with a data entry screen to test our service with:

Let’s try it go head and enter some data in the “Value” fields for both arguments and press the Invoke button. It may take several seconds the first time, but you should see a result similar to this:

There are a few more goodies hidden in this test client which we’ll explore in a future post.

Congratulations, you just created a WCF service!

In the next post I’ll explain more about the configuration file and show you how to create a console application to host your new service.

Code on!

It’s been a pretty busy new year for me (Codemash, clients, hockey, holidays, etc.), which is why I’m just now getting a chance to write this post.

A lot people already know, but on January 1st I received an MVP award from Microsoft for my work in the developer community. I’m very proud and honored to receive this award. I would like to thank all the people who nominated me and the community for it’s support. I’m looking forward to 2010 being a great year for the development community and am excited to continue to be a part of it!

I really didn’t expect to receive one this quarter. In fact that only reason I checked that e-mail account that days was because I was looking for an old e-mail from someone else! For those of you who were expecting a funny/witty/insightful post about this, I apologize. To be honest I’m still trying to wrap my head around this very unexpected surprise.

You can view my MVP Profile here.

See you at Codemash!

Thanks to all who came to my talk on F# at the Dogfood conference last week. I had a great time presenting it and hope all who attended enjoyed it as well. The slide deck and demo are attached. If anybody has any questions about it, please feel free to contact me.

This was my first Dogfood conference, and it was unlike any other event I’ve been to. I was able to meet a lot of people who don’t normally come to developer events or user group meetings.

On a related note, The Sophic Group will be holding an F# boot camp on December 14-15 at OCLC in Dublin OH. The cost is $1900 and includes two days of instruction, all class materials and a half-day of on-site (meaning your office) continuing F# education and assessment. If this sounds interesting, please contact me for details.

Next stop, PDC in Los Angeles. See you there!

As a consultant, I work with a lot of clients of varying backgrounds, skill levels and willingness to explore new techniques and tools. In addition to my development/architecture duties, nowadays I’m often brought into a team to provide mentoring and perform assessments. This takes a variety of forms but there is almost always some effort needed to “evangelize” new ideas and approaches to clients.

Some clients are very open to this. They recognize that I’m there for a reason and that my advice can help them get from where they are to where they need to be. Sometimes the ideas I provide and the steps needed to implement them are difficult and scary, but in the end they will be better off.

Then, there are clients who are a little more resistant. This is almost always based on fear. Mostly fear of the unknown. They’ve been doing things they way they do them for years.  They feel pain but it’s the pain they know. They’ve noticed all the changes in development in the past several years, but haven’t been able to keep up on all of them. Usually they’re in a situation were an tool/technology/technique needs to be vetted before it is used. In the meantime they need to continue supporting their business users with what’s available to them. They find themselves behind the technology wave and getting back on top seems like an impossible task.

Additionally, they know how to be “successful” with the tools and techniques they have now. It’s what they know. Introducing new tools and techniques increases the chance of failure. People tend to put too much emphasis on the negative side of failure without acknowledging the learning experience it provides.

So, how do you win these people over?

The Wrong Approach

As a passionate technologist, sometimes my first inclination is to come in and try to get them to change everything. Right now. This takes fear and turns it into outright panic. From their point of view you’re asking them to throw out everything they know and start over. This isn’t like asking someone to move from Java to .NET or from Visual Basic to C#. The jumps we’re asking people to make are much more difficult. Introducing new developers to concepts and practices like TDD or Inversion of Control require them to make a significant leap in abstract thought. Making a change from Web Forms to MVC, or from Remoting to REST based services takes a major change in the way we think about designing and building applications.

But that’s just what’s on the surface. When you walk into a situation were a team has already been working diligently on an application, which is usually the case, you’re in an indirect way leveling criticism against their development skills. And the more you insist the it must be thrown out and re-done your way and dig your heels in, the more biting that criticism is. No one likes to be told their baby is ugly.

What I’ve Learned

When I was in the third grade I remember reading a book called “Stone Soup.” It was the story about three soldiers who were on their was somewhere and stopped in a small town. The soldiers were hungry, and proceeded to knock on every door in the town asking for food. The townspeople knowing that the soldiers would be very hungry and not wanting to share their food decided to tell the soldiers that they don’t even have enough food for themselves, let alone anyone else. The soldiers are able to see through the ruse however and come up with a plan. The tell the townspeople that they can teach them how to make soup using nothing but stones. The set a large cauldron of boiling water, containing one stone, in the center of town. The townspeople begin to gather, curious about how they are going to make soup out of a stone.

The soldiers make a big show of tasting the soup and claiming it to be, almost, the best soup they’ve ever had, remarking that the only thing is needs to make it perfect is a few carrots.Still curious, a farmer runs to his root seller and returns with some carrots which the soldiers add to the soup. The soldiers go through the same “tasting ritual” this time claiming that if they only had a few potatoes, then the soup would be perfect. Next celery. After that cream. Then meat. You get the idea.

I have found that this approach works well with developers too. We’ve all heard the phrase “Don’t boil the ocean” this is a great technique on how to avoid getting into that trap. Instead of asking a client to take on a dozen new tools, frameworks and techniques, introduce them one at a time. Let the client see the value and point out that by taking another step (when the clients team is ready) will yield even better results. Don’t get hung up on going back and re-doing their existing application. If it’s working now, it’s probably good enough. The benefits you gain by introducing these techniques for new development are not necessarily going to provide an equivalent when used to refactor an existing code base. If there is a benefit to be had, and you’ve used this technique correctly, the clients developers will be the ones who start to champion that cause.

This technique is not an overnight solution, but it is a lasting one. Take your time. Convey your excitement, but also remember to be patient. Keep your changes small and manageable. And enjoy your soup.

Better late than never…

Seriously, sorry to everyone who’s been waiting for these.

I had a great time speaking in Cincinnati last week and meet a lot of great people. I hope to see you all again soon.

I had the luck of being able to participate in a “Community Summit” the day before DevLink in Nashville. In addition to other activities, and some (GREAT BBQ!) there was an open space on how to be a better speaker. A couple people were surprised when I suggested a practice I employ.

Occasionally I’ll take a presentation (slides, demo, etc.) that I’ve given several times and just “throw it out.” Even if it’s a popular talk. Even if I am comfortable giving it. Even if I think it’s perfect. Especially if I think it’s perfect! I throw it out and start over from scratch.

Why?

Probably the biggest reason I do this is that technology and attitudes change. They change very quickly. I’ve noticed a lot of speakers/presenters/whatever try to address these changes by adding “appendixes” to their talks. You’ve probably seen this; a well put together albeit dated talk suddenly veers off in an unexpected direction to accommodate a point release that came out a month ago. It’s jarring. It’s awkward. It feels “bolted on” (probably because it was) and I’m not a fan. I understand that sometimes, especially if you’re talking about “bleeding edge” technology or tools there are going to be last minute changes and patches that you might want to address. That’s fine. But if we’re talking about the delta between a “.0” and a “.5” release you should have (and take) the time to incorporate those changes in a way that keeps the flow of the talk smooth.

But I’ll throw out presentations sometimes even if this isn’t the case. Especially if it’s one I’ve given several times. Re-building a presentation causes you (like it or not) to re-think your approach to the topic. You can’t escape it. If you’re re-building a one year old presentation you have another year of knowledge and experience to put into the presentation. Not just in the topic you’re speaking on but in speaking in general. I’ve been speaking for over two years. In that time I’ve only used one slide deck and demo that wasn’t mine and I wasn’t allowed to alter. I did that presentation under protest. In those two years I’ve put many slide decks and many demos together. I can tell you without a doubt in my mind the presentation I put together last week is more than 100 times better than the first presentation I created.

The last reason is that when I give the same presentation again and again it can get boring. After awhile I start to feel like I’m going through the motions. When I feel like I could sleep walk through a presentation, I take that as a bad sign. Re-building is a way for me to re-capture that inspiration to speak on the topic in the first place. I’m a fan of the XBox game “Civilization Revolution.” I like the whole game, but one of my favorite parts is the beginning where I create my cities and kind of “mark out” my territory. I think it’s exciting trying to beat my opponents and lock up key strategic positions and resources. Once my territory is established and my cities well defended, it’s still fun, but not as much fun. I think it’s a creative thing. Good developers are like this too; we get excited about creating new things. That’s why most of the developers I know will jump at the chance to do some “green field” development and would fake their own deaths if they though it would get them out of maintenance. Presentations are the same way.

Again, this is what works for me.Your mileage may vary. But if the circumstance allow give it a try and let me know how it worked out.

Later.

You might thing you’re special, but your not. And sooner or later it’s gonna happen to you too. Your WCF Service is going to encounter a *gasp* Exception. Do you know what to do when it does happen?

Scott Hanselman wrote a terriffic blog post on exceptions. It’s a great place to start and if you haven’t read it you should. I wrote a post last year about working with the WCF Fault Contract. But there’s more than one way to skin this cat. What I’m going to be focusing on in this series of posts are the ways you can deal with exceptions in WCF and how to communicate what’s happened to your client.

In the first installment we’re going to look at how exceptions get received by a WCF client and how the WCF channel reacts to exceptions. Let’s start with what happens if you just throw a normal .NET exception. For this example we’ll be looking at a mock up of a service to return prices for stocks based on a ticker symbol.

The service contact:

   1:      [ServiceContract]

   2:      public interface IMyWcfService

   3:      {

   4:          [OperationContract]

   5:          decimal GetStockPrice(string symbol);

   6:      }

And the implementation:

   1:      public class MyWcfService : IMyWcfService

   2:      {

   3:          public decimal GetStockPrice(string symbol)

   4:          {

   5:              switch (symbol)

   6:              {

   7:                  case "MSFT":

   8:                      return (decimal) 1.41;

   9:                  case "IBM":

  10:                      return (decimal).89;

  11:                  case "JAVA":

  12:                      return (decimal).10;

  13:                  default:

  14:                      throw new ArgumentOutOfRangeException("symbol", "bad symbol");                   

  15:              }

  16:          }

  17:      }

Since this is a contrived demo, we only handle three symbols and return a static value. This does however provide us with an opportunity to see how .NET exceptions work in WCF. If we receive a symbol that is not in our list, we are throwing an ArgumentOtOfRangeException. If we were using this as just a .NET object we wouldn’t have a problem; either our code would catch the exception and do something with it, or it would bubble up to the user.

Our client is a winform application. The important part is the call to our service (via a proxy of course):

   1:  public partial class Form1 : Form

   2:  {

   3:      private readonly MyWcfServiceClient _proxy;

   4:   

   5:      public Form1()

   6:      {

   7:          InitializeComponent();

   8:          btnCallService.Click += CallService;

   9:          _proxy = new MyWcfServiceClient();

  10:      }

  11:   

  12:      public void CallService(object sender, EventArgs e)

  13:      {

  14:          lblResult.Text = _proxy.GetStockPrice(txtSymbol.Text).ToString();            

  15:      }

  16:  }

So all we’re doing is grabbing a value (the ticker symbol) from a text box and passing it as an argument to the service. The result is used to set the value of a label control. When we run this and feed one of the three symbols that our service uses, the expected happens: a value is returned and set to the text of the label. When we provide an unsupported symbol, we get an error:

The exception text should look familiar to anyone who has worked with ASP.NET…

System.ServiceModel.FaultException: The server was unable to process the request due to an internal error.  For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs.

Like ASP.NET, WCF will not return detailed exception information to clients as a security measure. Like ASP.NET we have the ability to change the configuration to return more detailed exception information. One line nine below, we have set the includeExceptionDetailInFaults value to “True”:

   1:  <?xml version="1.0" encoding="utf-8" ?>

   2:  <configuration>

   3:    <system.serviceModel>

   4:  ...

   5:      <behaviors>

   6:        <serviceBehaviors>

   7:          <behavior name="Service1Behavior">

   8:            <serviceMetadata httpGetEnabled="True"/>

   9:            <serviceDebug includeExceptionDetailInFaults="True" />         

  10:          </behavior>

  11:        </serviceBehaviors>

  12:      </behaviors>

  13:    </system.serviceModel>

  14:  </configuration>

This results in the details of the error message being passed back to us:

Like ASP.NET, this can be OK for development, but is not a good idea for production.

Let’s make a few changes to our client application:

   1:  public void CallService(object sender, EventArgs e)

   2:  {

   3:      try

   4:      {

   5:          lblResult.Text = _proxy.GetStockPrice(txtSymbol.Text).ToString();            

   6:      }

   7:      catch

   8:      {

   9:          MessageBox.Show("Service call failed");

  10:      }            

  11:  }

By catching the exception we can let the user know that something happened and handle it gracefully. Running the application and use the symbol “ORCL” causes the exception, which is handled:

So, we can just re-submit a supported symbol right…?

Uh-oh.

Turns out that when a WCF service throws a normal .NET exception, it faults the channel. Any subsequent calls to the channel results in a CommunicationObjectFaultedExcption being thrown immediately. The channel cannot be salvaged; your only option is to throw it out and recreate it. The proxy implements an interface called ICommunicatioObject that has a Faulted event that we can subscribe to.A few more changes to our client…:

   1:  private MyWcfServiceClient _proxy;

   2:   

   3:  public Form1()

   4:  {

   5:      InitializeComponent();

   6:      btnCallService.Click += CallService;

   7:      _proxy = new MyWcfServiceClient();

   8:      ((ICommunicationObject)_proxy).Faulted += RecreateProxy;

   9:  }

  10:   

  11:  void RecreateProxy(object sender, EventArgs e)

  12:  {

  13:      _proxy = new MyWcfServiceClient();

  14:  }

… and now our client is able to recreate the proxy if a communication fault occurs.

This way of dealing with exceptions in WCF works well if you are a client of a service that you may not control or have the metadata needed to create a fault contract for. Otherwise, using the FaultException class and/or WCF fault contracts are a better way to go. I’ll be covering them more in detail in the next couple posts.

Code on!

I recently had a conversation with a friend and fellow developer who was very excited. His company recently welcomed a new CIO to the organization, who had some, comparatively, progressive idea. One of his first actions was to increase IT development spending by several million dollars to tackle some projects that had had to be put off over the past few years, including renovating several applications that we’re quite performing up to expectations.

Unfortunately, while the CIO’s spirit was in the right place it became clear that his money was not.

The various development groups began developing applications the way they had always done, but made no effort to update their tools, techniques or practices. Instead of spending part of their substantial investment to introduce things like Agile methodologies, Test Driven Development, Web Standards, Source Control policies or automated builds, they proceeded to develop a whole new collection of applications like they had been developing them for years.

The group knew that these old practices had led them to a lot of pain in the past and needed to be revamped. But the organization placed value on raw lines of code and not the quality of what was being produced. As a result, those applications that needed “renovation” were simply ported from .NET 2.0 (and in some cases 1.1) to 3.5. Management was surprised when “upgrading” these applications did not result in large performance and stability increases.

Making a lot of changes to the way we work as developers can be scary. There’s a lot to learn, it seems complicated at the start, and no one wants to risk looking stupid. But it’s also important for us as individuals and software development in general to be willing to examine and investigate new techniques and tools that will make it easier to develop higher-quality code more efficiently. Keeping an open mind will unlock a lot of doors to improvement.

Companies need to understand that their code is an asset just like a building, vehicle fleet or piece of manufacturing equipment. You wouldn’t dream of letting those things fall into disrepair, so why are companies OK with their code base rot? When making an investment in IT, it’s important to understand where that money is going, and what it’s going to buy you in the long run. If you have a code base of dubious quality and pay for large teams to simply “plough ahead” you will just end up with a larger base of low quality code.

… and it was a tremendous experience!

The goal of a Give Camp is to unite non-profits that need technical assistance, be it a new web site, help with a CRM or making changes to an existing line of business application with passionate geeks in the area who are willing to give a weekend to help these non-profits accomplish their goals.

This year, in Columbus, about 45 software professionals came together to help eight non-profits. The results were amazing. In about 48 hours, eight full scale applications were either completed, or nearly completed. Most starting from scratch. It was great to see the variety of technologies and talents in one place and one time. It was also great to see the results a small but committed team of developers could create in a short period of time. Truly amazing! I want to thank all the volunteers who came out to help. A weekend can be a big thing to give up, and the Give Camp organizers and non-profits are extremely thankful of your efforts.

I would also like to thank all the non-profits that participated. We had a great time getting together and learning from each other while helping you.

I would also like to thank our sponsors. Quick Solutions for providing us with a great workspace, and soda and coffee through the weekend. Discount ASP.NET for providing hosting for the non-profit applications. Tech Smith for providing funds and licenses of their amazing products. Telerik provided us with licenses for some of their products and swag. Microsoft for providing funds and swag. eRubycon for providing a free pass to eRubycon 2009. And The Sophic Group for sponsoring dinner on Saturday night. Please remember the support these sponsors provided.

I would like to single out two sponsors who went above and beyond for us: Potbelly and Pei Wei. One of the most difficult things about organizing an event that lasts all day is feeding people. When that even spans multiple days AND encourages participants to stay over-night, that task is even harder. Potbelly and Pei Wei made some of those meals a whole lot easier for us! Please remember them if you’re in the Polaris area at lunch or dinner time (Potbelly is here, Pei Wei is here)

See you all at Give Camp 2010!

Codestock is this weekend in Knoxville. You can check out the agenda page here and see that there are some great, very smart people speaking there. With seven tracks over two days, plus open spaces, there’s something for everyone at this great event. I was honored to speak at the first Codestock event last year, and I’m thrilled to be back!

I’ll be presenting “How to make your application awesome with JSON, REST and WCF” in which I’ll explain why REST is the “new” hotness (turns out it’s not that new) and how to take advantage of it with WCF. You’ll also get to see some cool JQuery and ASP.NET MVC stuff as part of the talk. It’s the first time I’ve given this talk, so I’m very excited!

Turns out I’m following Rod Paddock. Yeah, that Rod Paddock. Editor in Chief of CoDe Magazine, author of many books, international speaker and Microsoft MVP. By contrast, I was all excited this morning because I found a $5.00 bill in my pocket that I forgot I had.

Ron Paddock followed by James Bender. Kinda like…

	followed by
	followed by
	followed by

In all seriousness, I’m really looking forward and VERY happy to be speaking at Codestock. It’s a must-attend event and if you’re not going, well, you should go!