There's no I in Interface

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...

Recently, I got the opportunity to start learning BizTalk: first BizTalk 2010 and, more recently, BizTalk 2013. It has been quite an experience. All the things I sorta took for granted (WCF, SOAP message formats, etc.) are now proving to be little nuggets (with deep threads!) of knowledge that, until now, I haven't needed to know.  BizTalk is Microsoft's answer for an Enterprise Service Bus (ESB). It can be used as a mediator/broker between multiple systems in a company infrastructure. It relies heavily on the pub/sub design pattern and uses the concept of  messaging almost exclusively.  BizTalk is designed to be extremely flexible. Which is good. And bad. Good in that it can most likely fill any gap that you may have in your company, but bad in that specificity is difficult to define: there are so many options! We're also in the process of establishing a new approach to the software systems we are responsible for. Along with that, we're implementing the notion of ...

One of the best parts of working in software development is the constant learning curve. This can also be a source of frustration. A long time ago, my physics professor said confusion is fine, but when you get to the point of frustration, that's not. Or something like that. I'm paraphrasing of course - that was {redacted} years ago. I like the process of learning and in the field of software development, there's no end in sight from what I can tell. To a point, sometimes, that it is overwhelming.

The most recent blog post about the newest release of jQuery got me thinking about some of the code I've been writing. In the post, they have this little gem: We don’t expect to get any bug reports on this release, since there have been several betas and a release candidate that everyone has had plenty of opportunities to thoroughly test. Ha ha, that joke never gets old. We know that far too many of you wait for a final release before even trying it with your code. So now there is really no reason to wait, and you can find out if there are any bugs you could have reported earlier. I've been searching high and low for any anomalies in the code and when I see some code that's not "up to code" I reformat and refactor as necessary. Which is to say, a s I find bugs, I've been getting them fixed, but at other times, I'm simply making changes to the codebase to adhere to a particular style that I've been working toward. I suspect I should probably stop so...

I've been working a lot with some copy and pasted legacy code. It's rife with poor coding conventions (read lack of ) and "let's get it working first, then we'll go back and do it right." Unfortunately, as everyone knows (except those who speak those words) those days never come. In Michael Feathers' book Working With Legacy Code , he calls legacy code "code without unit tests." The code I've been working on definitely falls in that category. Due to the nature of the code, I'm finding it very difficult to write unit tests for it. Combine that with the fact that I haven't read all of Michael Feathers' book, it makes for some pretty challenging days spent looking at this debacle. In refactoring some of the code in an effort to better understand what the code is doing, I've found ReSharper to be extremely valuable. I'm so glad I splurged for that software. Hopefully some of the minor changes I've made to the code will ...