Over the next couple of months I’m going to dig into the .Net Threading Library. This is meant to be an intro to
System.Threading. Using the .Net ThreadPool incurs overhead, but I wanted to measure how much we’d need to process before that overhead paid off, and when exactly it paid off big. This experiment involves a WebApi project, the .Net 4.5
async/await syntax, and a scalable Azure VM. The code is available on my GitHub account, in the ConcurrencySandbox repository.
The Software Development Evolution Conference (SDEC) is a local Winnipeg Agile con. Given some of my previous roles, I was asked to propose a talk this year on Continuous Delivery, centering on how and why a team might gradually shorten its release cycle. These ideas all sat comfortably in my head at the time, but they were about to get ground into dust. It would be up to me to rebuild them, challenge them, and share.
I’m proud to admit that my love of software has lead to a better understanding of the world in general. Life can be very chaotic, so abstracting parts of it can lead to a kind of peace. However, I find that my habits of cleaning can lead to tension. Sometimes I’ll leave clothes piled up and unsorted until laundry day, but I’m very protective of my kitchen’s organization. What does software have to say about that?
You’ve decided to automate a system. Software delivery, report creation, CPU threshold e-mails, whatever. Excellent! But beware: automation itself is not a solution, but a procedure for creating solutions. This nuance is so often overlooked that it has its own paradox named after it. Being ever original, it’s known as The Paradox of Automation.
Pneumatic tube delivery systems are as awesome as they are comical. I tried my best to find The Simpsons’s parody of the tube scene from Stolen Kisses, but couldn’t. I did, however, find this pneumatic-tube-themed Heineken commercial. This is what software delivery should be: push-button, stuff happens, ecstatic customers. So where do you start, and where are the easy wins?
‘The Gambler’ is one catchy song. I used to work with a guy who felt compelled to finish the chorus if you prompted him with the first line. This post is not about that song, nor is it about him. This post is about trying to solve an algorithm in a purely functional way, and it’s about the subtle differences between reduce and fold.
The magician’s mastery of sleight of hand can be enthralling. A magician can take what you know (input), combine it with flourish and props (externals), and give you a result you may not have expected (output). If you’re my target audience though, you’re more likely to be reading code. Sleight of hand in source code is simply frustrating. Removing the external dependencies until functions operate solely on input is called Referential Transparency. It can reduce surprise, and less surprise leads to more productivity.
A firefighter doesn’t tie his boots while he’s holding the hose. A president doesn’t write her speech while she’s orating. A Winnipeg Jet doesn’t sharpen his skates while splitting the defense. Why the heck was I fiddling around with the S3 management console after I completed a post? Here’s a story of the difficulties and triumphs experienced while making sure I don’t get slowed down while delivering my content.
Over a year ago, a colleague recommended that I try learning F#. A few tools and algorithms later, and I was hooked on functional programming. The first key concept is in the name. Functions build relationships between inputs and outputs. The benefits are unlocked when the software development paradigm shifts from programming a sequence of instructions to designing a programmatic workflow.
Software Engineers are often put in situations that pull them in different directions. Situations where too many priorities vie for top spot, and attempts to reconcile the chaotic situation are not met with constructive results. And old song I was taught called ‘My Name is Joe’ is tragically applicable.