I’ve been working on a free-to-play MMO Quinine For Sale, which has been “officially” live since last April, and things have been going well – a steady growth of players; the game itself has been well-received, and all the important graphs are “up and to the right.”  Part of my job involves detecting problems before they become serious and fixing problems when they inevitably do.  So, there are two questions.  “Is there a problem in the game?” “What is causing the problem?” 

When trying to debug something on our development and test clusters, typically you can tail log files.  We have a python script that can monitor the communication between various parts of the game and pretty-print it along with color to highlight “this is a problem!”  Attaching a debugger to a running process is also not uncommon.  However, looking at logs and bus traffic in realtime on a production environment gives you this neat “Matrix-y” experience.  Attaching a debugger to a production process (assuming you could, which you can’t) would get you smacked with a rolled-up newspaper.  “Bad Developer!  No treat!”  So, what can you do?

Monitoring

When you’ve got clusters full of machines, using Nagios to monitor things is an obvious solution.  Beyond making sure the power is on and other sysadmin things, we’ve written other checks to see if the login process is working, the parts are working together, and automating typical in-game functions.  For example, if nagios can’t successfully log into the game do basic game activity, then alerts happen.

Metrics for EVERYTHING

Anything that happens in game has metrics reporting tied to it, generating piles of data constantly.  We use Cacti to visualize game activity.  An example metric is concurrent users, or CCU.  We graph how many people are in the game over time, which when things are healthy should be a nice smooth curve climbing to peak game hours, then descending nicely through the night.

We can tell by sight if the game looks healthy or not – if the CCU graph is jaggy, has a sudden drop or spike, or drops to zero then we know that something is wrong.  Typically nagios alerts accompany the graphs, giving more data points on where to look.  But this has also pointed out areas where a nagios check was missing or wasn’t working as intended.

Log Files

When a player gets an error in game, the error dialog box gives them the opportunity to submit the error details back to us.  If we see a spike in user-reported errors through this or other customer service means, we know we have something of interest to look for. 

The game server components make use of log4j and similar logging frameworks.  Anything that you’d want to watch happening in game needs to be aggressively logged.  All components are configured so that operations can change the log level on the fly.  That’s still quite a bit of data across many machines though, so all that information is run through Splunk to be indexed and searchable.  This gives us a great tool for searching through log data, examining trends, or watching selected activity in real time.  Unfortunately it is very expensive so we are selective about the data that passes through it. 

Similar posts: Buy Flonase Without Prescription. Buy Periactin Without Prescription. Buy Armour Without Prescription. Buy Macrobid Without Prescription. Xalatan For Sale. Phenergan wiki. Soma maximum dosage. Zovirax treatment. Cialis price, coupon. Flexeril price.
Trackbacks from: Quinine For Sale. Quinine For Sale. Quinine For Sale. Quinine For Sale. Quinine For Sale. Quinine description. Quinine price, coupon. Online buying Quinine hcl. Quinine from canada. Where to buy Quinine.

I always find it rather interesting when academics try to quantify generalized metrics about software development.

Temovate Cream For Sale, Things like: per lines of code, there will be X number of bugs.

Statements like: it has been empirically proven that “blah” affects the development of software in some way “blah.”

These are all interesting thoughts, but software development will never conform to rigid engineering principles like many other engineering practices.  The longer I work in the field, the more and more I realize that software development has nothing to do with engineering.  We just happen to attend some of the same math classes in school.

Building bridges

One of the main arguments I hear people make about the current state of software development as an engineering practice is based around its relative maturity to other engineering fields.

There is a huge problem with this line of thinking.

The argument goes something like this:  “Engineering has been around for hundreds of years and has matured to the point where it is a measurable science, but software development has only been around in earnest for the last few decades or so, therefore it is relatively immature as an engineering discipline.”

On the surface this argument seems sounds.  And certainly in 50 years software development will be different than it is now.  Heck, it is much more different than it was just 10 years ago.

But, here is the problem.  We build much more software than we do bridges.

Let me give you an example that came to light in another area of my interest… poker.

The poker quickening

An interesting thing happened in the poker community in the last 10 years; poker pros with decades of experience started getting beat time and time again by 19 year old poker prodigies.

From an outside perspective it looks like the poker world opening up just widened the search for talent and there it was.  But, a closer examination of the evidence leads to the truth.

Before the online poker industry was born, poker was played in card rooms and casinos in states where it was legal and occasionally at small home games throughout the US.

A poker pro might play poker tournaments perhaps 100 times to 150 times a year.  The sum knowledge of the poker community and the meta game around it was based on this base of professional poker players playing tournaments and gaining experience at this mediocre rate.

Once the internet poker rooms started opening up, things changed, and they changed rapidly.  Now anyone could play poker from their home PC.  Not only could they play poker, they could play poker tournaments at all hours of the day.

Here is a list of some of the major changes that took place:

• Hands are dealt at 60-80 hands per hour instead of 10-30
• Players can play in many tournaments at one time, 10 tournaments at once is not unheard of
• Players can analyze hand histories and historical data about their play and opponents play through the use of software
• Age requirements are out the window, technically any one of any age could be playing online
• Players can play 24 hours a day
• The professional online tournament player could easily play over 3000 tournaments in a year, while a brick and mortar pro would be lucky to reach 100 in a year.

So where am I going with all this?

The point is that as a whole more hands were dealt and more poker knowledge and experience was obtained in 1 year of online poker than probably the entire history of poker before that.  We reached such an accelerated pace of play that all previous knowledge of poker became obsolete. 

The strategy of tournament poker completely changed.  The game evolved perhaps 500 years into the future in a matter of 5 years time.

The same has happened with software development.

Back to the bridge building

So let’s take that poker example and look at it through the lens of software development.

Let us compare the engineering maturity to software development to the engineering maturity of the engineering discipline of building bridges.

I think most people would agree that bridge building is a very mature engineering discipline but many people would argue that software development is not.

How many bridges do you think have been built in the world?

Well there are about 600,000 bridges in the United States alone, so the world figure must be at least somewhere around 10 times that number perhaps 20.

How many software programs have been written?

This is a very hard number to estimate, but lets take a rough guess based on how many software developers there are in the world. 

If we say there are about 12 million software developers and each software developer has written approximately 3 programs, we can estimate that a large amount more programs have been written than bridges built.

My point is not to knock bridge building, we are pretty good at it as a whole, but rather to show that collectively, even though we have been building bridges for hundreds of years, we have probably devoted an equivalent amount of time to building software.

This line of thinking may lead you to argue back that software development and bridge building are very different.  Bridge building has a fixed set of requirements that are pretty close to the the same for each bridge you build, but software development is a big open void of whims and ambiguously contradictory statements.

I agree with you 100%!  And in essence that is my point.

Software development is different

And we have had enough time to realize that.  Waiting for software development to gel into some kind of engineering discipline like other engineering disciplines is like waiting for water without gelatin mix to turn into Jello. 

It’s just not going to happen!

In my mind it is clear that the argument that we haven’t given it enough time is just wishful thinking.  The nature of software development, just like online poker, leads itself to rapid evolution.

Consider what direction software development is evolving.  Is it even evolving in the direction of rigid engineering practices or is it evolving in the exact OPPOSITE direction?

Ten years ago, we tried to use UML diagrams and CASE tools to develop software.  Ten years ago waterfall was all the rage.  Ten years ago, we thought that ten years in the future we would have programs that would allow us to build software in the same way that CAD tools allow for building machine parts.

Not only did it not happen.  It went completely the other way.  Now we are all talking about Agile.  Now people don’t even remember what CASE tools are.  Now we are building software without trying to define the whole system in UML diagrams.

The fact of the matter is software systems are unruly beasts!

In my mind it comes down to one simple distinction.  Software is living, bridges aren’t.  When you are done building a bridge, you are done building the bridge. 

Sure someone, probably not you, will have to come along and do some routine maintenance on it.  Sure, some small things might change about it, but for all intents and purposes the work is done.

In most software development scenarios, this is not the case.  In most software development scenarios, releasing V1 is not even close to the end.  Sometimes V1 and V2 don’t even look that same at all.  Software development is about operating on a living breathing thing and all the while keeping it alive.

The truth is, we software developers have more in common with surgeons than with other engineers.

As always, you can subscribe to this RSS feed to follow my posts on elegant code.  Feel free to check out my main personal blog at http://simpleprogrammer.com, which has a wider range of posts, updated 2-3 times a week.  Also, you can follow me on twitter here.

Similar posts: Bactroban For Sale. Armour For Sale. Buy Estrace Vaginal Cream Without Prescription. Buy Augmentin Without Prescription. Buy Tindamax Without Prescription. Fast shipping Diclofenac. Combivent brand name. Levaquin overnight. Purchase Toradol online. Australia, uk, us, usa.
Trackbacks from: Temovate Cream For Sale. Temovate Cream For Sale. Temovate Cream For Sale. Temovate Cream For Sale. Temovate Cream For Sale. Temovate Cream brand name. Where can i find Temovate Cream online. Generic Temovate Cream. Temovate Cream photos. Order Temovate Cream from mexican pharmacy.

What's the major malfunction with those old, classic Christmas lights? We've all experienced it at some point. When one goes out, all the others go out as well. This is due to the fact that these lights are wired in series. The difference compared with today's Christmas lights is that every bulb has a shunt, which basically prevents this kind of failure caused by one or more lamps. Enough about the Christmas lights for now. Where am I going with this? Back in enterprise IT, I'm seeing the same kind of failures as with those classic, old Christmas lights.

The diagram below shows a classic RPC style architecture, much like those classic, old Christmas lights.

This is all fine and dandy as long as every part of the chain runs without too much hassle. But what happens if for some reason the centralized back-end web service goes down (light bulb goes out). This means that every smart client, website and batch application that uses this web service gets affected by this, like some sort of chain reaction. Parts of these client applications will no longer function correctly or they might even go down entirely. Same thing happens when the database of the centralized back-end web service goes down or any other external system that it depends on. When being confronted with this kind of architecture, how would one go about preventing this doomsday scenario to happen?

Suppose you’re a developer that has to work on the centralized back-end web service. This is usually a complex system as it obviously has to provide features for all kinds of applications. When this centralized back-end web service also has to deal with and depend on other external systems that might expose some unexpected behavior, how could one prevent the sky from falling down when things go awry in production?

Well for starters, you could start building in some stabilization points. Suppose for some reason, the centralized web service needs to incorporate some functionality offered by a highly expensive, super enterprise system that for some reason behaves very unstable and unpredictably on every full moon (expensive enterprise software not behaving correctly sounds ridiculous, but bare with me ;-) ). For example, we could use a message queue as a stabilization point.

This means that we put a message on a queue that is processed by some sort of worker process or service that does the actual communication with the misbehaving system. When the external system goes down, the message is either left on the message queue or put on an error queue for later processing when the external system comes back up again. There are some other things you need to think about like idempotent messaging, consistency, message persistence when the server goes down, etc. … . But if one of these dependencies goes down, the centralized back-end web service is still up-and-running which means that the systems that depend on its functionality can also continue to serve their users as they are able to keep doing their work.

Earlier this week I overheard this conversation that somewhat amazed me. I changed the names of the persons involved as well as the exact words used in order to protect the guilty.

George: We want to incorporate a message queue in order to guarantee stability and  integrity between several non-transactional systems that our system depends on. It will also improve performance as these systems behave very slow at times and become unstable under pressure. This also gives us the opportunity to root out some major points friction that our end-users are experiencing right now.

Stan: But this means that the end-users are not completely sure if their actions are indeed fully carried out by the system.

George: End-users can always check the current state of affairs in their applications. If something goes wrong, their request is not lost and things will get fixed automatically later on as soon as the cause of the error has been fixed.

Stan:  I don’t think that’s a very good idea. End-users have to wait until everything is processed synchronously, even if that means that they’ll need to wait for a long time. And if one of the external systems goes down, they should stop sending in new requests. Everything should come to a halt. They just have to stop doing what they are doing.

George: This means that because you lose the original request, some external systems might be set up correctly while others are not. Then someone has to manually fix these issues.

Stan: Then so be it! 

For starters, I was shocked by this conversation. This is just insane. Everything should come to a halt? Think about this scenario for a while: suppose you’re finding yourself in a grocery store with a cart full of food, drinks and other stuff. You come at the cash register where the lady kindly says “Can you put everything back on the shelves please? There are some issues with the cash register software and we are instructed to stop scanning items and serve customers until these issues are fixed. Can you come back tomorrow please?”. Uhm, no! How much money do you think this is going to cost compared to the system that makes use of stabilization points? An end-user that is able to keep doing its work, whether the entire production system is down or not has tremendous business value.

I’m not saying that message queues are a silver bullet. I’m just using these as an example. As always, there is a time and place for using them. There are other things a developer can incorporate in order to increase the stability of the system he’s working on, like the circuit breaker pattern. I’m also not saying that every system should be built using every stabilization point one can think of. This become a business decision depending on the kind of solution. As usual, it depends.

But the point that I’m trying to make here is that we should stop putting software systems into production and just hoping for the best. That’s just wishful thinking. Software systems are going to behave badly and at some point they will go down. It’s just a matter of when this is going to happen and how much damage this is going to make.

The first step to take is awareness. I encourage you to pick up this book titled ‘Release It!’, written by Michael Nygard. This book is all about designing software that can survive this though environment called production. I can only hope that Stan picks up a copy as well along with some common sense.

Till next time.   

My immediate reaction was that this was a terrible idea and that I had been struck down too many times by sealed classes before. But then I started thinking that maybe it was not such a bad idea after all. Maybe it even was a sign of a well designed class and that more developers would be better of by sealing their classes.

Now let me inform you that I am still on the ropes about this, but I would like your thoughts on it. In fact I am hoping that the most interesting part of this post will end up being the discussion in the comment section.

So when you take a moment to think about the S.O.L.I.D principles, most specifically the Open-Closed Principle and Dependency Inversion Principle, a long with the old design principle of ‘Favor object composition over class inheritance’ then maybe it is not such a bad thing after all. Throw in interfaces into the mix and program to an interface and not an implementation, and it will enables you to create different branches if needed. If your classes can flourish while being sealed, chances are that you have some pretty nice structures code in your hands.

There probably are some legit reasons to not seal classes at time, despite the reasoning above, so I am not going to be definitive and say that is never the case. Voice your thoughts in the comments and let us see where this ends up – who knows, I might be left standing as a fool!

As always, you can find me on twitter by the name of @thecodejunkie

I was working on building an automated testing framework for a welfare system in which cases could be added and benefits run for a given month.

A typical scenario might be something like:

1. Create a new case for this month.
2. Add some people, do some things.
3. Run benefits for this month.
4. Run benefits for the next month.  Something should happen because the child on the case is now 19.

Seems pretty straightforward until you consider what happens if someone hard codes dates into the test.

I am sure you can imagine plenty of scenarios in a situation like this where hard coded dates would eventually cause all kinds of problems.

The problem is…

If you create an API which takes in various dates, how do you ensure the dates passed in are calculated and not just hard coded?

Why convention doesn’t work

Your first response might be to create some documentation that describes the importance of making dates “float” forward with time, and not be hard coded.

You might clearly describe how you should not hard code July 7th 1990 to be the birth date of a 20 year old for a test case.

You might give some guidelines of how to properly calculate ages.

But, you have no way of making sure the users of your API will follow those conventions or even read your document.

What if we do the hard work for them?

Why utilities are still not good enough

The next idea you might have is to create utilities that would do date conversions and calculate ages for the user of your API, so that they just have to remember to use them and all will be good.

This solution is better than one relying purely on convention, but still has some major flaws.  Part of the problem of utility methods is that they are not self-discoverable.  I’ve talked about before how DateUtilities like classes can get overlooked if you don’t know the utility class is there.

If you are relying on your users to go out and find your utility methods to make life easier for them, you are putting a large amount of responsibility in the wrong place.  In my experience, it is very unlikely that anyone but yourself will actually use the utility methods.

You really need a way to stop them from being able to hard code dates.

How can you stop someone from hard coding dates?

Don’t accept dates in your API.

It is simple.

What?  What do you mean?  You can’t just stop accepting dates, you need dates.  Not just dates, but integers, or strings.  You can’t just not accept the bad data… or can you?

Consider wrapping the data type in another data type which creates your desired data type, but only using the convention or rules you desire.

Let me show you an example with the dates:

   1: public void CreateCase(DateTime applicationDate)

   2: {

   3:    DoSomethingWithTheDate(applicationDate);

   4: }

   5:  

   6: CreateCase(new DateTime(1990, 7, 8));

In the above example, you can see that I am directly taking a .NET DateTime object.  You can also see that I am directly hard coding a date when calling this method.

Let’s see if we can fix that.

   1: public void CreateCase(CaseDate applicationDate)

   2: {

   3:     DoSomethingWithTheDate(CaseDate.ToDateTime());

   4: }

   5:  

   6: CreateCase(CaseDate.YearsAgo(20));

What happened?

Here is what we did:

1. We created a custom type called CaseDate.
2. We replaced all the external usages of DateTime with CaseDate.
3. We provided methods on CaseDate which allow the creation of dates, only through the way we want to allow them to be created.

Now we can easily prevent users of the API from being able to create hard coded dates.  The API only will take CaseDate objects and internally creates DateTime objects from the CaseDate objects.

We can add other methods to CaseDate to allow the creation of dates from x number of months ago or in the future, or any other valid creation method we want.

By doing this, we are restricting the valid set of inputs to our methods at compile time, not throwing exceptions at run time.

We are achieving the same kind of valuable input constrictions that we have been able to achieve with enumerations, except we are adding more complex restrictions than a simple list of selections.

Where can I use this?

Not just dates.  There are many places where restricting the input to your method or API is going to simplify logic, protect against error conditions, and enforce constraints.

Consider using this pattern in some of these scenarios:

• You want to use an enumeration, but your list of possible choices is too large, or repetitive.
• Anywhere you are using a primitive type and that primitive type represents some more complex concept.
• Anywhere you have parameter validation or manipulation repeated in multiple methods.
• Anytime you process some input or repeat a series of steps to transform it before sending it as input.

Every time you are about to make a primitive type a parameter to a method you should ask yourself if it makes sense to wrap the primitive type into an class.

Remember, especially when creating an API, any time your method takes a primitive type, you lose the ability to constrain that input, and are forced to validate it instead.

Should you always wrap all primitive types?  No, but it is another tool you can use to provide an extra layer of indirection between the logic of your API and your callers use of it.

As always, you can subscribe to this RSS feed to follow my posts on elegant code.  Feel free to check out my main personal blog at http://simpleprogrammer.com, which has a wider range of posts, updated 2-3 times a week.  Also, you can follow me on twitter here.

Most of us write code for the purpose of achieving a goal.  If we practice writing elegant code, we are conscious of making that code as readable and terse as possible.

Seldom do we think about the use of our code from an API standpoint.

There is a subtle difference between designing your code in a way that will make it easier for someone else to maintain, and designing your code in a way that will make it easier for someone else to use.

Intellisenselessness

How often are you working against some API and you type a method name you want to use only to have intellisense present you with 5 overloads for the method all with several different parameters choices?

Which one do you use?  It is hard to be sure, you end up having to read through the long lists of parameters to figure out what method you should call and what parameters you should pass it.

Wouldn’t it be better if you were presented with what the method does in the method name rather than guessing what it does in the parameter list?  Something like this?

Perspective

From the perspective of the person writing the Login method(s), overloads probably seem like the most efficient and correct way to implement the multiple ways the method can be called.

From the perspective of the person using the Login method(s), additional methods are much preferred, because they are easier to understand and know what you are looking for.

Try to think from the perspective of someone using your code when writing your code.

Extract boolean parameter to two methods

I want to take a look at a very specific example that can be of great benefit to the readability and use of your code.

Take a look at this code below.

   1: public void Login()

   2: {

   3: }

   4:  

   5: public void Login(bool rememberMe)

   6: {

   7: }

Unfortunately, by adding this overload, we have added some complexity to our API, because now the user of that code has to see that there is an additional overload that take a bool parameter called rememberMe.

Consider this longer alternative.

   1: public void LoginRememberMe()

   2: {

   3: }

   4:  

   5: public void LoginDoNotRememberMe()

   6: {

   7: }

Instead of overloading Login and making the user have to decide which overload to call and pass in a parameter, we have elected to create two differently named methods which take 0 parameters and clearly state what they are going to do.

I’m not saying you should never write overloads, but anytime you see an overload in your code base, you should stop and think if it would be more clear to make that overloaded method into two different methods that can eliminate one or more of the parameters.

Any time you are restricting the number of choices someone using your code has to make, you are making that code simpler to use.

If you don’t believe me, consider why the iPhone has only one button.

As always, you can subscribe to this RSS feed to follow my posts on elegant code.  Feel free to check out my main personal blog at http://simpleprogrammer.com, which has a wider range of posts, updated 2-3 times a week.  Also, you can follow me on twitter here.

Nothing, I don’t handle nulls in code that I control the use of.

How well do you handle null right now?

Avoiding null in the code you “own”

• Checking for null
• Not ever passing null

The more elegant solution is to focus on never passing null.  By doing this you will end up writing less code and avoid decisions about how to handle null inside of a method that doesn’t have enough context to decide what to do.

public string TransmographyThreeStrings(string first, string second, string third)
{
     if(string.isNull(first) || string.isNull(second) || string.isNull(third))
    {
           // hmm, I donno, what should I do?  Should I throw an exception?
           // should I return an empty string?
           // what if the first string wasn't null, can we still do something meaningful?
           // how will the caller of the method know what I will do?
    }

}

What about accidentally passing in null?

TransmographyThreeStrings("Hello", "World", mysteryObject.Text);

• Always initialize variables when they are declared.
• Use a builder pattern to ensure that objects are always fully constructed before being created.
• Use properties to provide default values or lazy initialize.
• Make your objects immutable as much as possible.

Exceptions

As always, you can subscribe to this RSS feed to follow my posts on elegant code.  Feel free to check out my main personal blog at http://simpleprogrammer.com, which has a wider range of posts, updated 2-3 times a week.  Also, you can follow me on twitter here.

Something that is simple yet effective, delivered with grace.

Bringing the dead to life

Unit tests tell us why and how our code is effective

i = 5;  // Widget count defaults to five.

widgetCount = DEFAULT_WIDGET_COUNT;

1.1.5 When a new widget is created, the widget count should be increased by one.

public void When_NewWidgetIsCreated_Then_WidgetCountIsIncreasedByOne()
{
     WidgetFactory.Count = 3;
     WidgetFactory.CreateNew();
     assertEquals(4, WidgetFactory.Count);
}

What exactly are we replacing?

As always, you can subscribe to this RSS feed to follow my posts on elegant code.  Feel free to check out my main personal blog at http://simpleprogrammer.com, which has a wider range of posts, updated 2-3 times a week.  Also, you can follow me on twitter here.

Resources

Resources are at the heart of REST.  You are already used to resources as a web browsing consumer.  A resource is not something specific to REST, instead it is the first thing you probably want to consider when architecting a RESTful application.  A resource is simply the entity, item, or thing you want to expose.

Perhaps you have approached application architecture using one or many of several modeling and design techniques.  Data First practitioners typically begin with databases and data models.  DDD proponents like to begin by modeling around business entities and interactions, while their cousins in the BDD camp model around business activities.

When you decide to apply REST you will need to think a lot more about data entities and domain objects as resources.  Your existing models may or may not closely map to resources.  The shift in thinking may appear slight, but is very important.  It centers around making things  addressable.  Each resources must by uniquely identifiable as we will see in the next section.  We are used to identity with most data entities, but our domain objects may not always be as easily identifiable.  Likewise, our data entites may have identity, but not map to a resource. 

Consider the classic customer and order scenario for example.  If each customer and each order can be identified then it will be easy to design RESTful systems around them.  However, if the model requires a lot of context then our challenge is a little bit larger.  Perhaps we must first identify a partner, then a year, then a customer, and finally the order.  Yes, that is a design smell in general.  It makes fetching an order very difficult.  Developing RESTfuly would only further expose that difficulty.  Identifying your resources up front will help you reduce the possible impedance mismatches you might end up with between what you want to expose and your data or domain models.

REST is about interacting with Resources!

URI’s

REST defines the identity of a resource via URI.  Each resources has a unique address in URL form (ie. using the http protocol).  Interaction with a resource will take place at its URI.  As an example, my twitter status feed resource URI is http://twitter.com/optionstrict.  That URI is unique to my feed and that is what you expect to find at that URI.  In the Twitter databases or domain models my account may be referred to by the string optionstrict, or perhaps as some random number or guid.

To consume my status history via a service interface twitter provides another URI at http://api.twitter.com/1/statuses/user_timeline.json?screen_name=optionstrict.  I would actually prefer to have access at the same URI for html, json, and xml formats.  Twitter probably has its reasons for distinguishing API access from HTML rendering, but they have actually complicated their architecture by doing so.  When designing the URI’s for your resources, make them easy for your users to work with. 

Representation

Lets continue with the twitter example to describe what is meant by Representation.  Given a URI and a Resource, what will your consumers receive when they issue a GET request to the URI?  Twitter chose a representation of my account and included status history and profile for the response at http://twitter.com/optionstrict.  They decided to put a representation of my profile photo at http://twitter.com/account/profile_image/optionstrict.  In your REST solutions you will need to consider how you want to represent a resource at its URI.  Each representation will have a unique URI. 

Representations are also important for manipulating resources.  You must define the representation required to create and update resources.  Twitter status updates require a text representation with a maximum of 140 characters.  They allow additional values in the status representation, such as latitude and longitude.  Your REST solutions similarly must define representations for Requests and Responses.

I hope that this short introduction has helped you to see that the core essence of REST is simple and fairly obvious.  As you look at your current solutions what are the resources you are exposing?  Could you make those resources identifiable by URI?  What representation would you place at each URI?  What representation would you require for manipulating a given resource?

Also, notice I did not mention much about data formats, Content Type, Mime, etc.  Those details can cloud your design if you try to start with them. If you can’t wait for my post about how REST handles html, json, xml from the same URI, then start googling Content Negotiation, Accept header, and Content-Type header.

I always find it rather interesting when academics try to quantify generalized metrics about software development.

Temovate Cream For Sale, Things like: per lines of code, there will be X number of bugs.

Statements like: it has been empirically proven that “blah” affects the development of software in some way “blah.”

These are all interesting thoughts, but software development will never conform to rigid engineering principles like many other engineering practices.  The longer I work in the field, the more and more I realize that software development has nothing to do with engineering.  We just happen to attend some of the same math classes in school.

Building bridges

One of the main arguments I hear people make about the current state of software development as an engineering practice is based around its relative maturity to other engineering fields.

There is a huge problem with this line of thinking.

The argument goes something like this:  “Engineering has been around for hundreds of years and has matured to the point where it is a measurable science, but software development has only been around in earnest for the last few decades or so, therefore it is relatively immature as an engineering discipline.”

On the surface this argument seems sounds.  And certainly in 50 years software development will be different than it is now.  Heck, it is much more different than it was just 10 years ago.

But, here is the problem.  We build much more software than we do bridges.

Let me give you an example that came to light in another area of my interest… poker.

The poker quickening

An interesting thing happened in the poker community in the last 10 years; poker pros with decades of experience started getting beat time and time again by 19 year old poker prodigies.

From an outside perspective it looks like the poker world opening up just widened the search for talent and there it was.  But, a closer examination of the evidence leads to the truth.

Before the online poker industry was born, poker was played in card rooms and casinos in states where it was legal and occasionally at small home games throughout the US.

A poker pro might play poker tournaments perhaps 100 times to 150 times a year.  The sum knowledge of the poker community and the meta game around it was based on this base of professional poker players playing tournaments and gaining experience at this mediocre rate.

Once the internet poker rooms started opening up, things changed, and they changed rapidly.  Now anyone could play poker from their home PC.  Not only could they play poker, they could play poker tournaments at all hours of the day.

Here is a list of some of the major changes that took place:

• Hands are dealt at 60-80 hands per hour instead of 10-30
• Players can play in many tournaments at one time, 10 tournaments at once is not unheard of
• Players can analyze hand histories and historical data about their play and opponents play through the use of software
• Age requirements are out the window, technically any one of any age could be playing online
• Players can play 24 hours a day
• The professional online tournament player could easily play over 3000 tournaments in a year, while a brick and mortar pro would be lucky to reach 100 in a year.

So where am I going with all this?

The point is that as a whole more hands were dealt and more poker knowledge and experience was obtained in 1 year of online poker than probably the entire history of poker before that.  We reached such an accelerated pace of play that all previous knowledge of poker became obsolete. 

The strategy of tournament poker completely changed.  The game evolved perhaps 500 years into the future in a matter of 5 years time.

The same has happened with software development.

Back to the bridge building

So let’s take that poker example and look at it through the lens of software development.

Let us compare the engineering maturity to software development to the engineering maturity of the engineering discipline of building bridges.

I think most people would agree that bridge building is a very mature engineering discipline but many people would argue that software development is not.

How many bridges do you think have been built in the world?

Well there are about 600,000 bridges in the United States alone, so the world figure must be at least somewhere around 10 times that number perhaps 20.

How many software programs have been written?

This is a very hard number to estimate, but lets take a rough guess based on how many software developers there are in the world. 

If we say there are about 12 million software developers and each software developer has written approximately 3 programs, we can estimate that a large amount more programs have been written than bridges built.

My point is not to knock bridge building, we are pretty good at it as a whole, but rather to show that collectively, even though we have been building bridges for hundreds of years, we have probably devoted an equivalent amount of time to building software.

This line of thinking may lead you to argue back that software development and bridge building are very different.  Bridge building has a fixed set of requirements that are pretty close to the the same for each bridge you build, but software development is a big open void of whims and ambiguously contradictory statements.

I agree with you 100%!  And in essence that is my point.

Software development is different

And we have had enough time to realize that.  Waiting for software development to gel into some kind of engineering discipline like other engineering disciplines is like waiting for water without gelatin mix to turn into Jello. 

It’s just not going to happen!

In my mind it is clear that the argument that we haven’t given it enough time is just wishful thinking.  The nature of software development, just like online poker, leads itself to rapid evolution.

Consider what direction software development is evolving.  Is it even evolving in the direction of rigid engineering practices or is it evolving in the exact OPPOSITE direction?

Ten years ago, we tried to use UML diagrams and CASE tools to develop software.  Ten years ago waterfall was all the rage.  Ten years ago, we thought that ten years in the future we would have programs that would allow us to build software in the same way that CAD tools allow for building machine parts.

Not only did it not happen.  It went completely the other way.  Now we are all talking about Agile.  Now people don’t even remember what CASE tools are.  Now we are building software without trying to define the whole system in UML diagrams.

The fact of the matter is software systems are unruly beasts!

In my mind it comes down to one simple distinction.  Software is living, bridges aren’t.  When you are done building a bridge, you are done building the bridge. 

Sure someone, probably not you, will have to come along and do some routine maintenance on it.  Sure, some small things might change about it, but for all intents and purposes the work is done.

In most software development scenarios, this is not the case.  In most software development scenarios, releasing V1 is not even close to the end.  Sometimes V1 and V2 don’t even look that same at all.  Software development is about operating on a living breathing thing and all the while keeping it alive.

The truth is, we software developers have more in common with surgeons than with other engineers.

As always, you can subscribe to this RSS feed to follow my posts on elegant code.  Feel free to check out my main personal blog at http://simpleprogrammer.com, which has a wider range of posts, updated 2-3 times a week.  Also, you can follow me on twitter here.

Similar posts: Bactroban For Sale. Armour For Sale. Buy Estrace Vaginal Cream Without Prescription. Buy Augmentin Without Prescription. Buy Tindamax Without Prescription. Fast shipping Diclofenac. Combivent brand name. Levaquin overnight. Purchase Toradol online. Australia, uk, us, usa.
Trackbacks from: Temovate Cream For Sale. Temovate Cream For Sale. Temovate Cream For Sale. Temovate Cream For Sale. Temovate Cream For Sale. Temovate Cream brand name. Where can i find Temovate Cream online. Generic Temovate Cream. Temovate Cream photos. Order Temovate Cream from mexican pharmacy.