HTTP BIN - Developer Tools

One of my favorite tools in my 10 in 1 screwdriver. The appeal is that in a single tool, just by flipping some pieces around you have just what you are looking for. In many minor jobs around the house I can do everything needed just with this single tool.

When writing software you can find similar valuable tools and one such valuable tool is

Like with most tools, the simplicity can be deceptive because how hard could it be to have an API that just echo's back what you sent. But then that is what is so great about httpbin, it's done and it's very robust.

By way of example, when building a front-end you may find that the API isn't complete and thus you want to "stub out" the calls. With httpbin you can send a call such that it echo's back what you want and thus you are wiring up to an actual HTTP call.

On the server side you might have the same need to wire up to a service that isn't something you are allowed to call from your local machine, but with httpbin you have the means of mocking with an actual HTTP call.

Using telnet to troubleshoot connectivity.... and watch Star Wars

So the teaser I'll lead off with is, at the end of this post you'll know how to watch Star Wars A New Hope in ASCII art form (i.e. text based graphics)... So let's begin.

Recently I found myself working on a legacy application such that I had to redeploy the multi-node application into in Infrastructure running in Azure. Two of the models communicate via a WCF binding over net.tcp. While I was operating under the impression that the firewall had been opened up to allow the communication I was a bit stuck on how to validate that the communication was working. So I wandered up to the networking area to chat with our Network Architect. As I often find, chatting with those who have an expertise different than your own requires patience and effort in the area of translation. Even though we both work in the IT field we each have our jargon to deal with, but the price of admission is well worth it.

In just a few minutes of explaining my challenge I had been provided with an excellent means of confirming that, from a networking perspective, communication was possible. Enter telnet. Telnet, if you may not know is a protocol that has come and gone in terms of it's heyday. Also to be clear, telnet is NOT secure and should NOT be left running, but in our case it's helpful as a tool for a short period of time.

As originally stated I need to confirm communication via net.tcp between two nodes in a network was working, so how can one accomplish this "easily", well what we want to do is emulate the communication, so you can use telnet on the same port as the net.tcp listener and if you get a blank screen you've got connectivity. When a telnet client calls out to the target server over a port that is listening for traffic, say for an HTTP or NET.TCP request the response will come back and the telnet client won't know what to do other than show a blank screen. BUT it proves that the communication is working on that port. So the primary question is answered.

So to the example of how this work and on to watching Star Wars.

Enable Telnet Client

- Open a PowerShell command as Admin
- Enter the command
Enable-WindowsOptionalFeature -Online -FeatureName "TelnetClient"
- Close PowerShell
- Open command prompt
- Enter the command replacing your info as needed
Telnet [IP or DNS] [Port for net.tcp listener]
Example: Telnet 443

If you get a blank screen then an application is listening on the target port and communication is possible via NET.TCP (or HTTPS, etc).

if you get the error "Could not open connection to the host, on port xxx: connect faild" then you might need to go back to the Firewall to see if something else is blocking.

What about Star Wars
As promised, if you have enabled telnet and are done troubleshooting you can check out Star Wars via telnet by opening a telnet connection as follows.


Disable Telnet Client
- Open a PowerShell command as Admin
- Enter the command
Disable-WindowsOptionalFeature -Online -FeatureName "TelnetClient"

Talk to the Rubber Duck

*See attribution of image at the bottom.
One of the greatest tricks I have had the pleasure of participating in is that of helping someone solve a problem simply by listening. I'm sure there is a more accurate description of this phenomenon, but in the world of programming it's called Rubber Duck Debugging. I was first introduced to this idea from listening to Jeff Atwood podcasts/interviews as well as reading his blog under he wrote about the topic under the title Ruber Duck Problem Solving.

Why the term Rubber Duck? Really it has nothing to do with the rubber duck, the intent is to encourage someone to solve their own problems by working through the very difficult challenge of describing what the problem actually is. It is often surprising to people when they discover that simply the act of attempting to describe a problem helps them to find the answer they were looking for.

So my approach to assist others is by asking questions that I often ask myself to help them work through the Rubber Duck process. For example if a developer where to ask me to help them with a particular bug the questions I ask them are seemingly obvious, but surprisingly, their answering them can often lead to an answer. 

So what type of questions should you ask? The most obvious is "what is the problem" this question alone can often help you find the root of the issue and resolve the problem. Let's demonstrate this by way of a contrived example.

A developer is having a problem with her application communicating with a third party API service. So that is the "obvious" problem, but now comes the next question, are you ready... "why is that problem occurring?" 
So how can the developer answer this question? Debugging is a great place to start. A great place to start is by attempting to reproduce the issue locally. It's worth noting that in our example this doesn't result in re-producing the issue found on the sever. Now in some cases, such as when the developer isn't permitted to remotely access the server being impacted, there is still much that has been found. How so? We now know that the application is NOT the issue, nor is the API service broken. This points to an environmental issue. So even when you can't reproduce the bug locally you obtain more information. In our derived example the developer now has facts that he can presented to other IT engineers such as networking, security or even server admins to engage with in a meaningful conversation to solve the problem.

Another interesting side effect of engaging in this approach is that you will find you have a broader understanding of how systems connect and interact. Additionally your "Google Fu" is improved as well as you can key in on the specific phrases related to your problem. This is an excellent skill to develop and when you find yourself in the position of the rubber duck you can ask the right questions to help someone else solve their own problem.

So go be a rubber duck.

*By gaetanlee -, CC BY 2.0, Link

Example of using LazyInitializer.EnsureInitialized

When looking at making systems more efficient it's helpful to think about being lazy. A helpful tool in the .NET tool belt is the static class under the System.Threading namespace LazyInitializer. In particular this class contains a method EnsureInitialized

This method is very simple to use and provides a convenient way to ensure that an initialization is called only once based on the value of the target property already being populated.

For example, if you need to load a file as part of the setting of values in an application you can use the EnsureInitialized method.

The following is a derived example of using the class to illustrate the usage pattern.

If you are having trouble viewing the below code you can use this link to view the gist github.