Where I work we have a number of ASP.NET web applications that run different parts of our site so that we can have some segregation of code and containment of scope without just having an enormous monolithic project that holds everything intermingled together. It’s nothing too exciting technically, but the marketing department also needs to be able to present the entire site as a whole to visitors, and the Google Bot, for that sweet sweet SEO juice (and easier navigation and other less cynical reasons I’m sure). The way we achieve that is with prodigious use of the IIS URL Rewrite engine, which allows us to create a set of rules that take the incoming HTTP requests and either route them through to different web applications, or different virtual paths, or stop some in their tracks entirely.

There are a two different schools of thought when it comes to deploying to production environments. Well okay, we’re developers, so there are probably 100 different schools of thought but bear with me. One option is to promote the same binaries from testing, through staging, and all the way to production, and the other is to maintain a branch in your source repository for the current state of production, and deploy from that. The general thinking is that with the former you get safety in knowing that your production deployments is exactly what has been through your testing cycles, and with the latter you’re always in a position to hotfix and correct a production issue regardless of what state your testing branch might be in.

I’ve recently starting working on a new project in my spare time, DbUpgrader, and I’m trying to work on it for at least a few minutes every night. I variously use a MacBook Pro or Windows machine, and sometimes I use Visual Studio 2017 but sometimes I’m just using Visual Studio Code and mucking around on the console. I’d like to also try out Visual Studio for Mac sometime soon. All of these different environments have their advantages and features, but I mostly want to make sure that I can work in all of them, on the same project, without issue.

Every dev team has coding standards. Sometimes they’re established through convention, tradition, example and maybe sometimes there is even a formal document outlining them (hopefully in a living format that can be updated!). No matter how its done though, nobody wants to be the bad guy in code reviews or pull requests and pull people up for what are usually minor infractions, however at the same time nobody wants to see a codebase be neglected and let inconsistency creep in, or readability wane.

We use DbUp at work to manage database changes and migrations and for the most part it works fine as long as you have a known schema that you’re coming from. The downside of the current implementation is that changes to stored procedure definitions are not easily reviewable in source control. Fortunately enabling this workflow with DbUp is relatively straightforward.

A friend of mine tweeted this article, and excellent summary today, about a recent production outage at Travis CI:

The headlight stalk on the 2017 Honda CR-V annoys me more than something so simple has any right to annoy anyone. On the surface it follows the well worn path of headlight stalks, and indeed wiper stalks, across the car industry that has become standard for years. You turn the end of the stalk to select what level you want the headlights to be at, you move the stalk up and down to indicate, and forward and back to use the highbeams. So far so good, all is fine.

There are many ways to describe the difference between two types of developers: Junior vs Senior Developers, New vs Experienced Developers, Good vs Bad Developers. I’ve never been comfortable with any of these because its always too easy to find exceptions that prove the rule. I’ve worked with junior developers who really understand what it takes to be a successful well rounded programmer, and with senior developers who have years of experience yet lack a few important skills to really allow them to be successful.

I was lucky enough to have my submission accepted to speak at DDD By Night on Thursday the 15th of March, 2018. DDD By Night is put on by the organisers of DDD Melbourne and usually happens twice a year, consisting of 8 lightening talks of 10 minutes each.

I’ve done PowerPoint Karaoke (PPTK) twice now, and seen it done a bunch of times, and while I certainly enjoy the challenge a lot of people struggle with it and find it unbearable. In this post I thought I’d have a go at writing down what I think should be done to ensure you deliver a good PPTK talk. I must admit though at my last PPTK talk I naturally failed to implement all of these ideas, because nerves, but nobody can expect to be perfect the first time. Or second., Or third.

After dabbling with F# and thinking about the code conventions and style that is idiomatic in that language, or at least in a FizzBuzz sample, it occurred to me that some of the ideals of F# could be seen as a potential code smell in C#.

The Melbourne Alt.Net meetup on the 27th Feb 2018 included a portion of mobbing on some basic F# code, namely FizzBuzz. I had never written a line of F# in anger before, but I certainly knew the concepts and ideals behind functional programming, so I was surprised at how the session went. Whilst I had somewhat of an idea of how I would do it, with currying, partial application, and other such concepts in mind, I couldn’t express those ideas in a mob programming session because I didn’t know the syntax.

So this is new. A Jekyll blog running on GitHub Pages mapped via DNS to my domain name. I’m basically a networking engineer now.

I’ve given lots of talks before, on lots of different topics over the years. From internal after lunch tech talks at work, to flying half way around the world and speaking in front of hundreds of people, and I’ve always enjoyed doing it. I have to admit though most of the time I’m talking about something that I am a Subject Matter Expert in, like this year in July when I gave a talk in Seattle about an SQL-like language that I designed and implemented. I still get a little nervous before each talk but I think that’s probably a good thing because it keeps me from getting complacent and “phoning it in”.