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.

Automate Work and Life with IFTTT and Office 365 Flow

I'm a huge fan of automation for situations where I find myself doing something mindlessly over and over again, like punching a clock. The way I approach these problems is to find a way to eliminate some portion of the task and iterate till it just happens on it's own.

To avoid confusion, when I say punching a clock what I mean is knowing a rough approximation of how long I worked on a given day so that when I need to put in my "billable vs. non-billable" time at the end of the week I have a rough idea of how much time I spent on working each day. As such the way I "manually" accomplished this was putting the time I arrived at work and the time I left into a spread sheet.

So, step one, avoid having to open excel to enter the information. This was easy using a feature of Office 365 called Flow. It's an application that smells very similar to the populate If This Then That site (a.k.a. Flow makes it easy to setup operations that interact with other parts of Office 365, such as creating files in OneDrive based off of attachments in an e-mail, creating reminders in Outlook, even putting info into a spreadsheet.

Quick aside, Microsoft is bad at naming things, like really bad. In the case of Flow it's both the application as well as an instance of an activity that you create. So going forward when I say I created a "Flow" I mean I created an activity within the application Flow... right, bad at naming things... but I digress.

All flows are comprised of at least two parts. An event/trigger and an action. For example, I could create a flow which would be described as follows...

Every time I receive an e-mail (i.e. trigger/event) take all attachments on the e-mail and place them in OneDrive under a folder with the same name as the "from" e-mail address (i.e. action taken).

Pretty handy. 

So in my case, the action was pretty easy, put a row of data in a spread sheet. But what would be my trigger? After some digging I landed on an interesting feature of Flow the application. Along with the Web Site/App up in the Office 365 subscription there is a mobile application you can install on any mobile device. Along with that you can create a "button" which can act as a trigger, so right from your phone you just tap and the trigger is fired. It has the added bonus of providing GPS data, if you chose, which can also be embedded in the flow for use in the action. So now my flow could be described as..

Every time I press a button in the mobile Flow App on my device (i.e. trigger/event) put a row of data in a spread sheet I specify that includes the time the flow started to represent when I start/end work along with the GPS of where I pressed the button (i.e. action taken)

At first I thought this was great and wonderful and was impressed that I had done all of this in the course of a few hours. However, after the novelty wore off I found that often I would forgot to press the button, and per my original goal I was still mindlessly doing something, even if it was a much smaller process.

Enter IFTTT. IFTTT is probably also something that an enterprise could use; however, I most often think of it as a consumer service. IFTTT has a much easier way to describe creating activities, which they refer to as recipes. These recipes have the same "ingredients" as a flow. A trigger followed by an action. I should mention that Flow seems to be easier to customize as well as to support more extensive chained activities, but I digress. IFTTT also has a mobile app and, unlike flow, it supports GEO-Fencing, or the idea of a trigger based on entering or exiting a set of geo coordinates.

I had already been using IFTTT for my "personal" automation projects. As such I had already had been using IFTTT to trigger an SMS to my lovely wife when I arrived at work or when I was heading out. In hindsight I'm wondering why this didn't hit me right away, but simply forwarding the SMS I sent to my spouse as an e-mail to my work address could be the I needed for the FLOW.

So by "coupling" IFTTT and FLOW I was able to get the best of all worlds. I just go about my business and my spread sheet is updated for me. I even left the button flow in place so that when I work remote I can still keeping things down to a single button press and move on.

What type of activities would like to automate in your day to day routine?