There's no I in Interface

I was recently asked to create an API for retrieving multitenant data. The actual implementation requires a LOT more work than I have time to complete, so I thought I would create an API with some faked data. Now, at first, I was tempted to grab some data from one tenant and serialize it into a fake service that essentially hijacks the process, returning pseudo-random data. THEN I remembered working with a class library called Bogus . This is a cool library that "generates" random data of all sorts using a fluent interface. You configure the rules using lambdas and then call methods to generate the classes. This is very straight forward for simple POCOs and works great. However, I was trying to create an object graph, essentially, with hierarchical data. Objects at the second layer need to have a valid reference to objects at the first layer. Third to second, fourth to third. That way, you can query down the chain or get objects at the next-level-lower that have references to...

Overview A couple weeks ago, I had signed off a little early from work as I started a little earlier than normal that day. I get a Teams message shortly after having started my stationary bike session from my manager. He asked if I was going to be around at 4:30. My first impression was, "Why on earth would we need to talk at 4:30 on a Wednesday?" (any work day for that matter). I'm a big believer in a strong work-life balance, so try to keep working hours to 8 per day. This is especially important for remote work: draw those boundaries and stick with them; get away from the keyboard. Life isn't all about work, etc., etc. So I cut my ride a bit short and meet with Ryan at 4:30. He asked if I want to be team lead for the Gatekeepers team. The Gatekeepers team is responsible for, at this time, the Authentication and Authorization Service that was introduced to our ecosystem about a year ago. The architect responsible for introducing it was also acting as team lead for ...

A couple years, I decided that was the year I was going to finally get a website setup. Fast forward to a couple days ago and that's how long it took me to begin executing on that plan. I tend to be afflicted with Paralysis By Analysis when it comes to something that I don't know how to start. Rather than just try, I think of all the ways it could fail. I know this about me and I also know that it's debilitating. Sometimes the debilitation wins. Sometimes I roll up my sleeves and get my hands dirty and break shit. The latter is almost always more rewarding than the former, yet the internal struggle remains.  But enough with the meta-crap, this post is meant to explain my approach to getting my domain name hosted with something. I've had this Blogger account for several years. It's free. It's easy. It's a little too easy to ignore, so I'm thinking I may resurrect it a little bit and start writing about my goings on as a mechanism for growth and learnin...

Intention The Chain of Responsibility pattern is defined as follows in the Gang of Four book: Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. Structure Explain how it works using UML diagram. Example Explain the section of the GitHub repository.

I'm refreshing my memory about software design patterns by watching some videos and taking some notes. I thought I would document them here for future posterity. These are the design patterns as defined by the Gang Of Four (GoF) in their seminal book "Design Patterns: Elements of Reusable Object-Oriented Software" and can be found on Amazon (non-affiliated link) . Some of the things I'll be posting will be related to the various categories of design patterns (as defined by the GoF): Creational, Structural and Behavioral. They are broken down like so: Creational Abstract Factory Builder Factory Method Prototype Singleton Structural Adapter Bridge Composite Decorator Facade Flyweight Proxy Behavioral Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor I will try to break each of these patterns into sections: Intent, Structure, Example. For those following along, I'll have the code for these examples ...

Politics tends to be a dirty word in the common vernacular. However, I think politics is just part of everyday living. Maybe not in the mind of every human, but at least in the mind of every worker. My first job - not even out of high school - was detasseling for the regional farmers through the local coop. Now, I grew up in Iowa, so there's a fair amount of things I need to explain, but let's just cut to the chase and say that all you've ever heard about Iowa is probably true. Corn. It's everywhere. Pioneer was a major business in them parts, and they had enough capital to make it worth your while to work in the heat of the Iowan summer walking miles through paper-cutting corn leaves to make a buck. They paid $5/hour at a time that minimum wage was around $3.15 or $3.25 (memory lapse), so it was a Siren Song of sorts for those of us aspiring to the American Way. A couple summers of that work, though, and one might reflect on their current situation and aspire to some...

I was asked recently what makes REST scalable. I wasn’t quite sure how to answer because all I knew about it (other than CRUD-type HTTP verbs) was that it was stateless. Before the question was asked, I had mentally mapped that CRUD concept to REST. Because I wasn’t totally sure, I figured I should dig in and learn more about REST. While there can be methods on the exposed API that take HTTP verbs like PUT, GET, DELETE, etc., there’s more to the story than that. Plus, what gives, brain? REST == CRUD?? WTF? So what is REST? REST stands for REpresentational State Transfer. It’s an architectural style for a standard communication scheme between computer systems. Most of the time, the protocol standard is HTTP, a stateless communication standard used ubiquitously across the Internet. Due to the stateless nature of the communication, as long as the message between the two systems doesn't change, the code on either side of the communication can be changed without is...

Recently, I had the opportunity to interview at a place that really excited me. The software they were creating (software for managing various systems), the technologies they were using (.NET, WebAPI, PWA, etc.), the methodology (CI/CD using AppVeyor, Octopus, git) and the learning environment were all just what I was looking for. The interview went pretty well, but the way I prepared for it was totally different than what I was expecting. The answers to the interviewers' questions, even as they were coming out of my mouth, were not my best work. I was trying too hard. This is the first job I was really excited about in a long time. I thought it would be a great fit, but I was sabotaging myself at every turn, it seemed, because I was trying so hard to do and say the right things. This interview process made me stop and reflect on what I really do know - those technologies and methodologies that I could explain to someone not in the software space. It's what prompted the REST ...

Recently, my first contracting job ended rather abruptly. My recruiter had mentioned a couple weeks before the notice that my contract was going to be extended by six months, so I was of the impression that I could take my time finding my next gig. Fortunately, the company gave my a (close to) 30 day notice, so I had some time to prepare for interviewing and all the work that goes with that. 30 days to find a new gig, though, isn't much time when you factor in all the processes that go along with finding and securing a new job. I saw a statistic recently that said the majority of new jobs are secured through people you know. Working remotely does have the disadvantage of not getting out and seeing/meeting new people, but then again, you'd really only be seeing/meeting the people you work with, which you do the same with remote without the morning ritual of water-cooler/coffee talk. Having worked 100% remote for the last 3 years or so, I'm ready to get into the office again...

In some ways, I feel like I've done a disservice to myself for taking a year away from .NET development to work on the Java stack. And then to take a job at a large bank in a group whose sole purpose is to put out fires it seems. The disservice sentiment occurs to me as I try to figure out what I want to be when I grow up. When I see some of the cool things people are doing in the software development scene, it occurs to me that I am on the healing edge of development. The bleeding edge has already went through days/weeks/months/years ago, and the healing is all but complete. I want to learn React. I start working through a class on Pluralsight, and realize I should learn how to use these task runners. Then I realize I should learn how to be more proficient with JavaScript. It's been a few years since I worked in pure JavaScript, so that seems like a reasonable building block to nourish. Then there's TypeScript. Whoa. Wut? Statically typed JavaScript? That seems pretty sw...

So, I was recently asked to look into a custom BizTalk solution whereby we could have a single receive location that takes a particular operation of type T. For example, DistributedOperation<OrderHold> .  The DistributedOperation would have a few properties that are common across all the messages that would be sent to this generic receive location, and T, of course, would be the specifics - the guts of the message for the most part. I guess you could think of the DistributedOperation properties as those that are "auditable" properties (timestamp, originating application, originating user, etc.), ubiquitous across all messages. I suppose the idea is that these things could be persisted, and then later queried for a traceable path of operations. The design, as explained to me, would be that a custom pipeline would take those DistributedOperation properties and make them distinguished fields of the message. Then take the payload ( OrderHold in our example) and make that t...