When looking for a new job, or your first job, in software engineering, there’s several types of company you can choose to pursue. I started out in what we would call Enterprise, sojourned in a Product company, then went into Consulting with Capax Global, then back to a Product Company and now am back into Consulting with Capax Global. Even during my Enterprise days, many of my projects were actually Products in that they were software solutions sold to customers. In a nutshell, I’ve been doing product work for a good part of my career, yet here I am in consulting and wondering why it took so long. What are the advantages I see? Warning: Opinions Ahead
Please don’t mind the dust while I move providers. I am moving from my WordPress based site to a Jekyll based site. This will simplify content management for me because I like to use a plain text editor. WordPress was just a bit much and the hosted WordPress didn’t give me the control I wanted over the site layout. So, here we go…
One of my favorite things about cloud services in general and Azure (my world) in particular is the wealth of options for quickly creating message based architectures. In Azure we can use Service Bus, Event Hubs, Event Grid, and more to manage our messages and easily consume them using our traditional sorts of applications or easy to use services like Azure Logic Apps or Azure Functions.
Azure Resource Manager (ARM) templates are often looked upon as some sort of magic voodoo. People who use them every day often have a limited understanding of them and this leads to doing things the hard way. The users aren’t always to blame, the documentation is often terse (at best) and features change quickly. In particular, mid-2017 saw a few critical features appear that really improve their usability in a few cases. I’m not going to try to completely solve the knowledge gap or try to create a comprehensive set of guidelines. Instead, I’ll point you to a few things that have been useful for me or helped me get to that “click” moment where they stopped looking like a blob of json and started looking like a language.
Don’t Repeat Yourself. DRY. It’s an oft repeated axiom among software developers but do we apply it broadly enough? Where we do apply it, do we apply it too aggressively? Today I’ll look at this fine old acronym three different ways: Avoid repeating code, Avoid making the same decisions, and avoid doing work over again.
subscribe via RSS