#REST-ish API with #WCF, part 2 Responses

If you thought the headache was over, I’ve got a treat for you. It’s not. But the “solution” isn’t far away though and quite straight forward. This hack is roughly the same like when working with the requests.

There is a built in constraint in WCF that you can only work with basically Json or XML. Or raw. That’s what all this fuzz is about. Too bad they didn’t make it obvious or easy to implement. The short explanation is however that if you request/return a Stream, it forces the WCF framework to abandon all it’s nifty things and smart moves and leaves it up to you to decide. So, set the return type to Stream, do your thing, serialization and what not. And send it out. The response will not get wrapped within the return type.

public Stream Check(Stream request){
  var json = ReadStreamAndDeserialize(request);
  
  //do stuff
  
  var jsonResponse = Serialize(response);
  
  WebOperationContext.Current.OutgoingResponse.ContentType = "application/json; charset=utf-8";
  return new MemoryStream(Encoding.UTF8.GetBytes(jsonResponse));
}

Why do this?

In our case we needed to serialize different types a bit differently and couldn’t get the internal serializer to work quite as we wanted. But also imagine that you could serve images back. You can even stream images back. And what if it is a file service? You could serve back whatever contenttype you like, and make it different depending on the file served. It does add some nice features you can work with to extend your options.

What you should also consider is what it does. In this case we make heavily use of the http protocol as opposed to others, which means it limits your options of just serving data over any protocol. It also takes you closer to the protocol you are working with, which can be both a blessing and a curse. If you don’t know what you are doing, you could end up in a lot of trouble and just having to write hack upon hack upon hack.

Check out the complete working example on GitHub.

Read more

Tagged , , ,

Goals and alignment

This is the third part in a series of posts on goals, picturing a dreamplace and taking a direction. First part was mainly contemplations around the entire thought of goals and directions. The second part was an attempt to describe my utopia, to better understand why I take the actions I do and where they might lead. This post will mainly focus on where, as in area, to set goals and how I would try to formulate them in order to make them successful tools to work with.

When I started thinking about this whole thing it was a big pile of… undefined thoughts. But as I progressed and saw how for example the swedish party Socialdemokraterna had formulated their goals in the past I got an understanding and ideas of how to break it down. There isn’t just one big goal, there are several that makes up a whole picture. I think that we, within the IT industry have a few that are pretty well defined areas that would benefit greatly if we could picture it and get alignment around trying to achieve those goals.

Take USA for example in the fifties and sixties. They really wanted to win the cold war and the Space Race and went from zero to hero and landed a man on the moon within 10 years. That’s an pretty awesome achievement. So how do we win our own space race?

I think if we could start by identifying the different areas we have at hand that would be a start. In my mind we have technology, architecture, infrastructure, work process, environment (the physical space around us) and organization. Then we must picture what it would be like when it all comes together in perfect harmony. If we can’t picture it, who will believe in us? And how do we know what it will be like? And does it seem to match?

The reason I think we need all of these are because they are entangled and dependent on eachother. If one weighs too heavily it will tip over.

I would not formulate rules and guidelines about how to achieve any of these, because in a sense it’s all about the journey. Not the actual goal. Imposing too many rules, or creating a step-by-step guide will take away the fun of discovering. Then you would never know what you are missing out on. Remember, these are just goals, which are tools for improving and pointing out a direction.

What more to keep in mind is that you are not in this alone. There is probably a team and a whole organization behind you as well. This means that part of the goal with these goals, are to create something to gather around and gain momentum from the entire collective working together. This should suggest that you can’t set any of the goals on your own, you need to do it together. Would you buy someone elses dream? You can always describe your utopia, if it’s good and something that many agree on you should go. On the other hand, if there are worlds between dreams that might indicate that not everyone is meant for eachother.

I intentionally left economy and finance out of the goals, but not because it’s not important but rather because it should be part of everything you do. No money in, no money out to you. Simple. At the same time I can easily see that if you have passion and execute what you are doing extremely well I think there is money to be made.

So what about those goals? From where we are right now, I’d set a technology goal around webservices and moving towards RESTful API:s, mostly for their ability to express relations and inherent meaning as well as being technology agnostic for the consumer which opens up for flexibility. Architectural wise I’d aim for small (micro?) services deployed independently and communicating internally via some kind of bus which everything flows through. The teams would be more or less autonomous, and they’d decide between their members how many they see fit and what capabilities they need. The work process and environment are also up to the teams to decide. But when it comes to work processes, remember there are different types of work to be done and they might need different processes. On the topic of environment I’d love to see each employee be able to customize their work station, so just hand over a pile of cash and make them do their priorities of what is important. Same goes with each team, but what do I know? They might choose to work remotely?

All of this said and done. What if you reach the goal? Good job! But sorry to say, the goal should already have moved. You’re on a race to the stars…

Tagged , ,

I have a dream…

This is a follow up on last post on goals and finding a utopia. This is my current vision of what I think would be a nice place to work. Not saying it is perfect or covers everything, but it gives me a direction of where I’d like to drive things.

Woke up at 0730 Monday morning by the largest hug from my daughter and a kiss from my wife. Sun is shining outside, it is -12 degrees and it has been snowing heavily outside, 60cm of fresh powder. Get out of bed and make a cup of mother beautiful coffee. Make some small talk with my family and play a few minutes with our little girl before going in to the office. I start up my computer, put the coffee down, put on The Doors on the HIFI and check in with my team mates.

Nancy is our HR and Finance specialist in our team. She keeps tracks of us, makes sure we get enough money in. We don’t measure cost in the traditional sense, but rather throughput and that we get more money in than we spend which includes our salaries and the tools we use. She knows as much about programming as I do about HR and finance, which produces good enough software. Always on her toes and likes early mornings, so she have most of the nights events covered when the rest of us drops in.

Adelaide has been around longer than any of us. She has been with the company for ages and have been to more companies than years I’ve been alive. As a business analyst she has the intel of what we are doing and knows most of what will happen when we discuss. Having been around for so long and holding so many positions during her career she knows her way around most programming paradigmes, writes code like a godess and has a capability of sharing her knowledge in just the right moment and amount to trigger one and make all of us better. Being a database junkie and seen stuff from the seventies and onwards means she knows what works when. On mostly her recommendations we run different stuff on graph, Hadoop and document stores. We even have some things in a relational database, but it is diminishing. It rarely fit the the needs.

Then we have Alex, our Product Specialist. His programming skills aren’t the best, but on the other hand he has ideas like noone else and a way of visualising and making them tangiable for the rest of us in ways we can only dream of. As a visionary and knowing our product inside out, he has a good way to point out our way forward and making sure the goal is always just out of reach, making it clear enough to know what to do next as well as pushing us to go further.

Pink is our DevOps awesome sauce maker. Always dresses in black and have been around computers and electronics since born. Pink can script anything and makes sure we always deliver in terms of keeping us with the greatest tools and platforms no money can buy, but only the hands of Pink. Though young in age and in the team, never stops to amaze and comes up with the craziest ideas and finds the most peculiar things to do with the strangest pieces of technology. We mainly run our stuff in the cloud, but also keeps some private servers on location with all of which Pink does what seems like magic to the rest of us.

Then there’s me. Happy to be here and blown away by all the fantastic people around making this place special. As a developer I bring general software knowledge to the table and work closely with Alex to realize visions and ideas, but also acting as generalist specialist. Me and Alex are the ones who mainly write “product code”. But we know we couldn’t do without the others. How else would we know if it performs? On what will it run? What do we do if…?

All we need to do is fulfill a “team contract” which means that the product must be deliverable by https, provide a stream of things happening for other teams to take part of, bring in more money than we spend and keep us up for as much as we can. If we experience downtime, we must do what it takes to get us up again ASAP. In a way you could say that we are like a company in the company and the company provides a platform for us to exist within our line of business.

When we work we collaborate on all we do, we just happen to be different kinds of specialists mostly based on our past experience and interests. We don’t do several things at a time. We do one thing at a time and we ship it. Usually shipping means a day or two, sometimes a week if it is something really large, but regardless of feature size we put things in production 4-5 times a day so we get the heads up if we’re about to hit a snag. Something might not turn out the way we thought, there might be something we can’t really solve in a good enough way or something else we didn’t foresee. But since we don’t buy in with more than a few days at a time, it is never a big loss. And if something new, The Thing Of The Day comes up, it is never far away, like a few days or so.

The way our team choose to work is that we don’t keep a backlog, just a well defined goal which we just can’t reach with this next feature. We try to keep two things in the pipeline at a time, one to work on and one coming up next. When it is time for getting something new in there we just brainstorm for 30mins or so, have a poll and take the one we agree on. Sometimes if something has resurfaced enough times we pick that one anyway because we’ve seen it so many times that there is something in there making it important for some reason.

After that we do some kind of design meeting for lack of a better description where we set some general guidelines on input and output, what to measure and how aswell as defining when it is done and what we must achieve in order to call it success. There’s not really any architecture to consider, most of it is in place already and the parts we put in production every two hours or so are so small they don’t need much architecturing in themselves. When it comes to tech decisions it is mostly a decision of what we see fit or if we want to try somethings new. Since the parts are small it is easy to write something in one language and if it turns out to be a bad idea it is mearly a couple of hours to replace it. During this meeting we also setup the basic contracts we will use and deploy them right away. That means we all know and understand why every propery exists and the purpose of every attribute.

If something, god forbid, would go down. We know the drill. We all drop what we are doing and collaborate on the issue. We usually keep a Skype call or Hangout open to discuss loud and clear, exactly what we are doing and looking at. Last time that happened was last month when a service went down because of a bug we had created. But it was minor and didn’t really effect anything but we treat them all equally. Those kind of things happen maybe once a month or every two months, while a real outage is extremely rare. We run on AWS and a new cloud player based in northern Sweden and can fall between them at any time. Usually we run a few days on one and then switching just to make sure the switch is seamless and that they run equally good. Sometimes we run on both at the same time, some services on one and some on the other just to see that they play nicely together.

We don’t have any QA in the team, yet. Simply because we haven’t seen the need in the common sense. We do testing ourselves in different manners. Unit testing, “firedrills” (we thought Amazon seemed to be doing quite well with the chaos monkey so we implemented one as well), and different integration testing through our endpoints and such. But mostly we rely on the dashboards that mostly Nancy, Adelaide and Pink have created which shows us in pretty much real time exactly what is going on with our product. Are orders declining after a release? Do we have any deviances? Are things running slow? Is there something not responding?

We are however thinking of getting another person on the team which would be some kind of UX specialist, or as we see it, an Experience specialist. This guy would know more about interactions and perception of things. Both of what we produce for external customers, but also for us and our tools as well which would make us even quicker and better.

But, today is monday and there is all this fresh powder outside! I tell the team I need today and tomorrow off since the skiing will be off the charts. Noone has any objections since there is always stuff to do and we are not dependent on one another really since everyone can do eveything more or less. Knowing this and that we have free vacation and just work under the “team contract” gives a special kind of freedom and easy to keep things in balance and feel we have enough time for what we hold dear too.

Though the company is based in Tokyo, this team is located in Europe. Adelaide is in the countryside of England, Pink doesn’t really live anywhere but travel around the world most of the time but use Amsterdam as a base, Nancy in Stockholm aswell as Alex. When I got this opportunity me and my family were in Stockholm but decided to relocate given the opportunity. So now we live in the french alpes just a couple of hours north of the french riviera. My wife took the opportunity to start a business where she can work with the environment.

We meet up with the team IRL about once a month, usually at someones home, but sometimes we decide on some resort or similar, we are like a family more or less. The company thinks that it is important to be able to, within the team, work together at the same time. So the same timezone is what we strive for. And it seems true, though with Pink travelling a lot we don’t see we couldn’t solve it should the problem arise. This has helped the company tremendously in recruiting, since we aren’t blocked to a location. And, we get the perk of all going to Japan about 3-4 times a year to meetup and share our thoughts and insights with the other teams.

I take our daughter to kindergarden and go off hiking to get some good lines. Knowing I can both have the cake and eat it.

I love my work. I love my family. I love life.

Tagged , ,

What goal? Where are we going?

This year is election year in Sweden. That means a lot of promises from all involved. What comes out in the end we don’t know. But where will we actually be heading, as a society?

There was a great documentary on Swedish National television last week called “Politics without a goal“. This is not just something local for Sweden, it is something that is in effect all over the world.

For the past two election periods we have had the right wing ruling sweden after about 10 years of left wing ruling. To be honest I can barely see any difference in the direction they want to take. The nuances are so small and short sighted that either left or right sound so similar. But what is their goal? Where does either want to be in 30, 50 or 100 years from now? This was very clear in the past and got us to this point, but where do we go next? We have 8 hour work days, 40 hour work week, 4 consecutive weeks of vacation during summer month, common right to vote, we’re fairly equal even though we could get even better.

Is it all so good that we can’t envision what could be even better? We only look so far as for next election period to see what will happen to our own pockets in that time frame? From where we are today, what is our Utopia?

If we don’t have a vision, a Utopia, how do we know what to aim for? In politics it’s not hard for me to see why the far and ultra wings on either side are gaining ground. They have a clear picture of what they want which is easy to grasp for many people and identify with. The established parties and very much of the western world is nowadays very short sighted and focused on making money today. Is their, the established parties, path only visible through knowing their history? Even though they have a direction through history, do they know what they aim for? Or is it just shooting from the hip? What does their future Sweden, in this case, look like?

This short sightedness shows clearly in the environmental area where we are not making any substantial progress. The energy sector is also moving slowly. Work time and work load is almost going backwards. Equality both in gender and classes is also going backwards. It took less than a decade to put a man on the moon when they really wanted it, then what? Is everything so established around money and large corporations with their lobbies that we are moving back toward a world similar to pre WW1 where a few dictate the conditions for the rest of us?

What happened to our Utopia, no matter what it was? Where are we going now?

Do you know where you want to go or be? What can you do to either accelerate our current short sighted (my opinion) path or change it for [your own] better path?

Perhaps it is not the politicians who should nor can fix all of this, but you, by shaping your work place and surroundings. What is your Utopia?

What kind of work place do you dream of? How does work flow? What do you work on? Where do you work? For how long? How much vacation and when? How would you balance life? How equal is it? Or what are your values that you hold dear? What is your Utopia?

Tagged , ,

How to make a #REST-ish API with #WCF

Where I work we integrate a lot with external partners where they sometimes dictate the conditions. At the same time we have our technology, architecture and environment to deal with and solve it as good we can. This put us in a bit of a position recently when we were tasked with “make a REST API that conformes to this document”. We use WCF. And then there was headache.

But, since WCF is carrier agnostic, this shouldn’t be any problem right?! You can deliver via HTTP, TCP, you name it. It’s just the flick of a switch in some config. Turns out it wasn’t quite that easy. The document stated that the request will be sent as content-type “application/json”, it also stated that it will be a POST request and furthermore that the actual JSON request will be a payload in the BODY of the message. WCF don’t give you access to the body. Since it is by design to be protocol agnostic and not all protocols have a body or they differ from eachother.

This is all very well documented if you enter the correct search terms. Read more on both the problem and solution here, here (this is where most paths lead) and here.

This is mostly for me to remember for the future since I know now that I’ve gone through it I did it once before but forgot all about it until it was right there in front of me.

While it all sounds complicated it really isn’t. It’s as easy as 1-2-3, like David points out in his blog post on the subject.

1. Add a new WebContentTypeMapper, like so:

public class RawContentTypeMapper : WebContentTypeMapper
{
  public override WebContentFormat GetMessageFormatForContentType(string contentType)
  {
    //Make if-else statements here if you want to respond differently to different contentTypes. This one will always return Raw regardless of what you attack it with.
    return WebContentFormat.Raw;
  }
}

2. Make your new content type mapper available for use:

<bindings>
  <customBinding>
    <binding name="RawMapper">
      <webMessageEncoding webContentTypeMapperType="Your.Namespace.RawContentTypeMapper, Your.Assembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
    </binding>
  </customBinding>
</bindings>

3. Put the new available content type mapper to use:

<endpoint contract="MyContract" behaviorConfiguration="MyEndpointBehavior" binding="customBinding" bindingConfiguration="RawMapper" />

(4.) When working with a Raw content type, your usual way of working with WCF will be put slightly out of order. Instead of using your standard contracts, your method will need to take in a Stream. After that you are free to work as you like. Here is what we did.

public string Check(Stream request)
{
  var json = new StreamReader(request, Encoding.UTF8).ReadToEnd();
  var internalRequest = JsonConvert.DeserializeObject(json);
  var querystring = HttpContext.Current.Request.QueryString; //perhaps some additional data in here?

  //Do stuff

  return string.Empty;
}

The above will give you everything you wanted from the start. Almost.

Now you are thinking “NICE! And then I just use the UrlTemplate(…) to get a descent way of finding the methods!”. Well, not quite. It won’t turn out like http://mydomain.ext/api/check, but rather http://mydomain.ext/path/endpoint.svt/api/check. While I haven’t tried, I’d go with some URL rewriting in IIS or something. Perhaps you have a loadbalancer who can do it for you, or some other mechanism.

Tagged , , , ,

Friday coding contemplation

I haven’t really been to roads end with this one, so bear with me if it doesn’t quite make sense.

When coding, I usually like to keep my objects as immutable. But on the other hand I really like the verbose way of initializing objects with Object Initialization. Of course there are ways around this, like named parameters, or just the good old naming variables correctly.


  var p1 = new Person {
    FirstName = "Monkey",
    LastName = "Business",
    Age = 42
  };

  var p2 = new Person(
    firstName: "Monkey", 
    lastName: "Business", 
    age: 42
  );

  var p3 = new Person()
    .SetFirstName("Monkey")
    .SetLastName("Business")
    .SetAge(42);

Where the Set-methods looks like the following.


  public Person SetFirstName(string firstName)
  {
    FirstName = firstName;

    return this;
  }

  public Person SetLastName(string lastName)
  {
    LastName = lastName;

    return this;
  }

  public Person SetAge(int age)
  {
    Age = age;

    return this;
  }

While this doesn’t make the objects immutable at all, it does open some other benefits. From time to time I tend to really dislike properties because they are easy to misuse. I myself don’t have a right or wrong answer, but to me they should be lightweight accessors and not perform a whole slew of stuff. If you are in that position a method might be good.

I guess the gist of this is that there are ways of doing things which we might forget. And while we love our fluent APIs, we are quite crappy at actually creating and using them for ourselves when not served via a library, framework or something. But all we really have to do is return this;.

What’s your flavour?

Tagged , ,

Friday afternoon #coding #goodie

After our code retreat a couple of months ago I got some inspiration for improving code and specifically number of parameters. So instead of passing parameters all over the place and polluting methods creating long long long long long long long lines of unreadable stuff, there are now just 2 params for this particular method.

Before:

_contentRepository.List(request, marketFilter, showExtended, paging);
...
List(ReadMarketContents request, IEnumerable marketFilter, bool showExtended, IPage paging) {
  //do stuff
}

After:

_contentRepository.List(request, options);
 
List(ReadMarketContents request, dynamic options) {
  //do stuff
}

Since “options” is a dynamic expandoobject I can assign and read data from it as I please with the usual dot-notation without the reflection-crap making things unreadable, since the compiler handles it for me.

dynamic options = new ExpandoObject();
options.MarketFilter = base.Request.GetMarketFilter();
...
var marketFilter = options.MarketFilter as IEnumerable;

And all this goodness without getting a class explosion for each and every request case like in this example. Think it might be a good fit for these kind of optional parameters where scope is limited, since knowledge is required.

Tagged , ,

#CodeRetreat at the office!

About a week ago we hosted the first ever Code Retreat at the office! We were about 15 happy devs who sat for an entire day contemplating over good code and good practices. To help us out we had Adrian Bolboaca who flew in to facilitate the sessions for the day and guide us.

We had before hand decided to split the day in two; the first part being deliberate practice for clean code, and the other part on refactoring legacy code fast and safe.

In the coding dojo before lunch we sat down with the very basics of coding. Doing things from scratch, thinking deliberately about why we do something, how we do it and how to name it. The purpose was not to finish, but to come up with something really good and try to work in a way that might not be what everyone is used to doing daily. Think. Deliberate. Leave nothing for coincidence.

One of the things that I think most of us took away from this part was “The Boyscout Rule”. It states that whereever you go, leave the place in a better state than when you got there. It applies to code as well. “It works, so don’t touch it” is not a good solution, that does not evolve and improve the code meaning it will go stale and fragile in time. Constant change improves and hardenes it along with the change of time.

In the second part we got to work with an existing piece of code where the objective to be able to change it without some of the risks involved when there are no unit tests and the code might be fragile. So we focused on end-to-end testing, and getting a feel for how to write these tests without impacting the code first. Then, when some basics are in place, refactor the code to be able to write more and better tests, always improving in small steps and see how it all evolves from a pile of crap into something not that bad.

So why did we do this again? Sit down for an entire day and not getting anything *real* done? Well, in order to constantly improve you must practice, like any other professional athlete. For us this was a test shot to see whether we liked the form as a group and see how we can go further with it, making sure that we all get better at what we do and strive for a better place for ourselves.

Really felt like a retreat due to the use of external conference room, reinvigorated the feeling of being an actual coder” -Participant

Tagged , ,

Today let’s celebrate #endregions!

Yes, I do have an issue with them. They are extremely annoying and they rarely add anything, but on the contrary obscures and hide things. I’ve seen uses range from empty ones, to wrap one method or sometimes several classes, but also the creative use of collapsible commenting to explain steps 1-2-3 within a method. WHY?! What is wrong with methods?!

Anyway, this post lays it our very well why we should #endregions. And there is even an action group – The Anti-Region Legion! Get involved.

Tagged

Obey your rules #cleancode

What are your rules? What makes your code good and readable? What you leave to the ones after you is quite important depending on the app you are writing.

I have a few simple rules I try to follow, to keep the code quite clean and understandable:

  • 10 loc per method
  • Only 1 statement (if, loop..) per method
  • 2 parameters in a method
  • Max 5 methods in a class, after that it gets messy and harder to get a quick overview. It also increases the risk of handling to much in a single class
  • Always program against an abstraction, never an implementation

There are some nice benefits that comes out of this. It is easier to structure the entire code base when things aren’t entangled and does lots of things. Naming is so much simpler. Even if you don’t do TDD or write your tests, your code (almost) automatically becomes testable. If something sneaks up from behind and attacks you, just sit back, check the code, write a couple of tests which proves the scenario and you shall see it will surface if you can’t spot it right away.

Heaps of other benefits there are too. Can you figure them out?

I’d love to hear what you constrain yourself with to not get carried away with large pieces of code at the end of the day! Tell me on twitter already.

Further reading

Tagged