Showing posts from September, 2018

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 fr

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 wi

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

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. using System; using System.Collections.Generic; namespace Example.EnsureInitialized { class Program { static void Main(string[] args)